Uml PDF

Méthodologies de conception
Adel KHALFALLAH
Institut Supérieur d’Informatique
Adel.Khalfallah@fst.rnu.tn
Adel_Khalfallah@yahoo.fr
Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 1
Introduction
1
Historique
• Années 30-40 : Programmeur = Utilisateur; Problèmes
bien définis
• 1950 : Langages de haut niveau; Profession

programmeur qui reste une activité individuelle
• 1960 : ‘Grands systèmes’ : OS de l’IBM 360, constatation

des difficultés : crise du logiciel, apparition du terme «
Génie logiciel »
Historique
Décennie Matériel Logiciel
40-50 Coûteux et spécialisé Binaire, code machine
50-60 Règne d’IBM, Assembleur
Recherche Scientifique
60-70 Mainframe, IBM 1401 COBOL, FORTRAN, Compilateurs
70-80 Intel, Apple, TRS-80, C, Smalltalk, BASIC, Pascal, Unix
DEC PDP
80-90 IBM PC, Macintosh DOS, dBase, Lotus 1-2-3, GUI
90-00 Laptop, Palm, PC Windows, OS/2, Java, C++, Visual
Servers Basic, Linux, Web, ASP, Perl
00-07 Pocket PC, Mobile, Web services, C#, Microsoft .NET
Tablet PC
2
Des chiffres
• Système de réservation de KLM 2 Millions de LOC
(assembleur)
• UNIX System V +X11+XNews 3 700 000 LOC (source)
• Space Shuttle 40 Millions LOC (objet)
Définitions
• Parnas
« Développement en équipe de logiciels multi-versions »
• NATO
« La définition et l’utilisation de principes d’ingénierie
cohérents afin d’obtenir du logiciel à coût bas, fiable et
efficace sur les machines existantes
• IEEE
« Le génie logiciel est l’approche systématique du
développement, de l’exploitation, de la maintenance et du
retrait du logiciel »
3
Concepts de base
• Le génie logiciel s’intéresse à
– des projets : les activités effectives qui se déroule pour aboutir à
un logiciel fini
– des produits : les différents artefacts (modèles, composants,
documentations, code source,...) fabriqués au cours d’un projet
– des personnes : l’organisation des équipes, de leurs
collaborations; exécutent le projet
– des processus : la façon avec laquelle le logiciel est fabriqué;
contrôlent le projet
Les processus logiciels

• La définition du processus de production du logiciel
permet de :
– Le rendre « répétable »
– L’analyser (le mesurer)
– L’automatiser
– Le standardiser
– Le rendre prévisible
• ‘Best practices’: comportements considérés par la
communauté des industriels e des chercheurs comme
étant éprouvées
4
Modèles du cycle de vie
Code and Fix

Coder • Correspond en réalité à l’absence
de modèle
Oui • Le code devient rapidement
déstructuré
• Ne peut plus s’appliquer aux
Corrections ? projets post années 70
– Taille
– La complexité
Non
– Spécifications changeantes
– Turnover
• « Crise du logiciel »
5
Modèle en cascade (Waterfall model)
Etude de faisabilité
Analyse des besoins

et spécifications
Conception architecturale
et détaillée
Codage et Test unitaire
Intégration et Test système
Mise en exploitation et
Maintenance
Modèle en cascade
• Etude de Faisabilité (concept analysis) : Définir le
problème, définir et étudier les alternatives, définir les
coûts et les délais
• Analyse des besoins et spécifications : Définir les

attendus du système, aboutir à un document de
spécification lisible, précis, complet, consistant et non
ambigu. Aboutit aux besoins fonctionnels et non
fonctionnels ainsi qu’à un plan du développement
6
Modèle en cascade
• Conception architecturale et détaillée : Définir les
modules qui constituent le système et leurs relations.
Selon le contexte la conception détaillée correspond à :
– Définir les interfaces des modules
– Définir les unités du langage de programmation
– Définir les types et les algorithmes
• Codage et test unitaire : écriture du code source, tester
les modules séparément
• Intégration et Test système : Assembler les modules
(gérer les versions) , tester le système (de façon
incrémentale). Alpha testing : mettre l’application entre les
mains d’utilisateurs « compréhensifs ». Beta test : élargir
la base des utilisateurs
Modèle en cascade
• Mise en exploitation et maintenance : Le système est
installé sur site à large diffusion. On distingue 3 sortes de
maintenance :
– Maintenance corrective : corriger les erreurs
– Maintenance adaptative : adapter le système aux évolutions de

son environnement
– Maintenance perfective : améliorer le système
7
Modèle en cascade (Waterfall model)
• Chaque étape possède des critères de lancement de fin
et de validations (Inspections)
• plusieurs déliverables intermédiaires avant le produit final
• Plusieurs variations sur ce modèle :
– Modèle en V, W,...
– Collecte des besoins, test composants, test produit,...
An. B &Sp C. Arch. C &TU F1

Conc. H. Niv. F1 C. Dét. F1
Conc. H. Niv. F2 C. Dét. F2 C &TU F2

Parallélisme
Conc. H. Niv. F3 C. Dét. F3 C &TU F3
Modèle en cascade
• Avantages
– Discipline
– Planification
– Marche bien pour des projets non innovants impliquant des
développeurs expérimentés
• Inconvénients
– Linéaire, piloté par les documents : bureaucratie
– Monolithique : Tout est basé sur la date de production
– Rigidité : n’anticipe pas les changements : la maintenance est
rejetée à la fin
– « Effet tunnel »
– Inadapté aux projets innovants, offrants des interfaces complexes
8
Modèle par prototypage
Collecte et analyse
des besoins
Conception
simplifié
Raffinement de Construction
la conception et du prototype
du prototype
Non Client Evaluation

satisfait ? client
Développement à grande échelle

• Basé sur « throw away prototype » : 1ère version prototype
bâclé qui sert à obtenir un feedback de la part de
l’utilisateur. 2ème version modèle en cascade
• Facilité par les langages et les environnements RAD
• Variation « modèle incrémental » : Le système est fourni
au client par incréments successifs, après la fourniture
d’un incrément il y a une phase d’évaluation qui influence
le développement de l’incrément suivant
9
• Avantages
– Visibilité du produit final (le choix de la ‘taille’ d’un incrément est
important)
– Adapté pour des projets innovants
– Les changements sont anticipé : la maintenance est incluse tout
au long du processus
• Inconvénients
– Risque de déstructuration du code (on revient à code & fix)
– Difficultés de planifier et de gérer le développement
Modèle transformationnel
• La spécification est exprimée formellement.
• Puis elle est transformée en implantation (éventuellement
automatiquement)
• Avantages :
– Preuve formelles de propriétés désirables
– Les changements sont maîtrisés
– Adapté aux systèmes temps réel et sûrs de fonctionnements
• Inconvénients
– Difficulté de la tache de spécification
– L’implantation n’est pas optimisée
10
Modèle en spirale
Déterminer Evaluer alternatives
objectifs Ident. et résoudre
alternatives Analyse risques
contraintes risques
Analyse
risques
Analyse
risques Proto
Proto 3 Opérationnel
Analyse Proto 2
risques Proto 1
Revue
Plan A. Besoins Simulation, modèles bancs d’essais
Plan CV Faisabilité
Spéc.
Plan Besoins
Validation
développement Conception Conc.
Spécification
détaillée
Plan intégration Validation
Codage
Planifier et test Conception
Intégration
Test Développer
Unitaire vérifier produit
et test
Le modèle en spirale
• Chaque phase correspond à un cycle de la spirale qui voit
se répéter le même type d’activités.
• Focalisation sur la gestion des risques
• Plusieurs spirales (une par fonction ou composant)
peuvent se dérouler en même temps
11
Le modèle en spirale
• Avantages :
– Permet de combiner les modèles antérieurs
– La réutilisation est encouragée par l’identification des alternatives
– Permet d’incorporer le plan qualité
• Inconvénients :
– La flexibilité rend la planification difficile
– L’analyse des risques requière une équipe expérimentée
Introduction à UP
• Modèles à base de phase # Modèles Agile (Extreme
programming)
• Procédés lourds (Rigidités , contrôles, séquences) # Procédés
légers (itératifs)
• Planification élaborée à long terme # Planification à court terme
• Fortement prédictif # Fortement adaptatif
• Lutte contre le changement # incorpore le changement
12
Introduction à UP
UP est
• Itératif
• Incrémental
• Conduit par les Use Cases
• Piloté par les risques
• Centré sur l’architecture
• RUP : UP + outils de Rational
Phases du cycle de vie
Inception Elaboration Construction Transition
Temps
• Inception (Initialisation/Pré-étude): Définir le contexte du

projet
• Elaboration : Construire le noyau architectural
• Construction : Construire le produit
• Transition : Mise en exploitation
13
Disciplines et modèles
Besoins Modèle
Use Case
Analyse Modèle
D’Analyse
Conception Modèle Modèle

D’arch. De dépl.
Implantation Modèle
D’impl.
Modèle
Test
De Test
Autres disciplines
• Modélisation de l’existant
• Gestion des configurations
• Gestion du projet
• Définition de l’environnement de développement
14
Phases et Itérations
Itér. ... Itér. ... Itér. Itér. ... Itér. ...

Prélim Arch. Dév. Dév. Trans.
Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable
•Une itération est une séquence d’activités basées sur un plan, un

critère d’évaluation résultant en un prototype délivrable
•Une itération a une durée approximative de 2 à 6 Semaines
•Une itération a une durée non tractable (« time boxed »)
Itérations et disciplines
Besoins
Une itération
Analyse
Conception
Implantation
Test
Itér. ite r.1 iter. 2 ite r. n ite r. ite r. it e r. ite r.

Prélim. n+1 n +2 m m +1
15
RUP définit 9 Workflows : 6 d’ingénierie et de 3
de support
Workflows d’ingénierie :
• Modélisation métier
• Analyse des besoins et Spécification
• Conception
• Implantation
• Test
• Déploiement
Workflows de support
• Gestion de projet
• Gestion des configurations et de évolutions
• Environnement développement
16
A chaque itération :
• Evaluation de l’itération précédente
• Gestion des risques
• Planification de l’itération suivante
U.C. Contrôlent le déroulement

• Pilotent les activités
– Création et validation de l’architecture du système
– Définition des jeux de tests et des procédures
– Planning des itérations
– Création de la documentation utilisateur
– Déploiement du système
• Synchronisation des différents modèles
17
Spécificités
• RUP n’est pas cascade car:
• Rien n’est figé
• Toutes les disciplines à chaque itération
• Noyau architectural développé et fourni au client dés les
premières itérations
• RUP n’est pas prototypage ou RAD car:

• Rien n’est « throw away»
• Evolution par incrément du prototype initial au produit final
Inception (Pré-étude)
Analyse des
Effort besoins
et spécifications
Conception Gestion de
Projet Environnement
Modél. Implantation
Existant Test
Discipline
18
Inception (Pré-étude)
Objectifs
• Développer une vision globale du produit
• Accorder les points de vue des différents partenaires
• Montrer la faisabilité technique
• Fournir des critères de décision pour décider de l’intérêt
du projet
Artefacts
Principaux
• Document «Vision »
• Dictionnaire de données
• Modèle Use Case
• Document : spécification supplémentaires
• Plan de phase
• Plan de l’itération suivante
19
Artefacts
Secondaires
• Modèle U.C. de l’existant (« Business case »)
• Liste des risques
• Prototypes de preuves de faisabilités
• Prototypes de l’interface
• Recommandations Développement/Achat
• Liste des outils
Vision
• Historique des révisions
• Positionnement
– Opportunité : Justification en termes du marché
– Expression du problème: Description du problème à résoudre
– Positionnement du produit: Public concerné, Caractéristiques
majeures, Plus par rapport aux compétiteurs
• Description des interlocuteurs
– Statistiques du marché
– Interlocuteurs (non utilisateurs)
– Interlocuteurs (Utilisateurs)
20
Vision
• Description des interlocuteurs (Suite)
– Objectifs Principaux et problèmes des non utilisateurs
But abstrait Priorité Problèmes et préoccupations Solutions actuelles
– Objectifs par utilisateur
Utilisateur Objectif Priorité Effort Risque
– Environnement Utilisateurs
• Vue d’ensemble du produit
– Perspective (lieux, matériels, collaborations)
– Résumé des apports
Caractéristique Apport aux interlocuteurs
– Hypothèses et dépendances
Vision
• Vue d’ensemble du produit (Suite)
– Coûts et Prix
– Licences et installations
• Résumé des caractéristiques du système
• Autres besoins et contraintes
Conception, usabilité, fiabilité, performance,documentation,…
21
Spécifications supplémentaires
• Historique des révisions
• Introduction
• Fonctionnalités
– Log et gestion des erreurs
– Sécurité
• Usabilité
– Facteurs Humains
– Autres facteurs
• Fiabilité
– Récupération des crash
– …
• Performances
• Maintenabilité
– Adaptabilité : Introduction de nouvelles règles de gestion
– Configurabilité
• Contraintes d’implantation
• Composants achetés
• Composants Open Source
• Interfaces
– Hardware
– Software
22
• Règles de gestion
No Règle StabilitéSource
• Questions juridiques
• Informations supplémentaires sur le domaine
Dictionnaire de données
Terme Définition et Informations Synonymes
Définition et informations
– Format
– Domaines
– Unités
– Termes composés
– Règles de validations
23
Modèle U. C.
• Forme d’un U. C.
– Bref : énumération des objectifs
– Résumé :
• Un paragraphe décrivant le déroulement aboutissant au
succès (l’objectif principal est atteint).
• 2 ou 3 variations majeurs
– Détaillé : Acteurs, Pré/post, variations,…
Modèle U. C.
Proposition de D.U.C. Stabilisation de D.U.C. Réalisés
U.C.
Décrits
Découverts
Construction
Inception Elaboration Itérations
24
Planification modèle des U.C.
• Semaine 1 : 2 Jours workshop (Inception It. 1)
– Majorités des U.C. identifiés par leurs nom et résumés
– 10 % (les plus importants) détaillés
– 10 % des 10% réalisés
• Semaine 5 : 2 Jours workshop (Elaboration It. 1)
– 10% des 10% réalisés
– Feedback de l’implantation
– 30 % Détaillés
– 50 % détaillés
Planification modèle des U.C.

– 70 % détailles
– Environ 10 % du système réalisés
– Objectif : 90% détaillés
• Le reste pour la construction
25
Développement Agile
Approche Agile Lien Web
Extreme Programming (XP) http://www.xprogramming.com

http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Feature Driven Development http://www.togethercommunity.com/

(FDD)
Scrum http://www.controlchaos.com/
Crystal Light http://crystalmethodologies.org/
Adaptive Software Development http://www.adaptivesd.com/

(ASD)
Dynamic Systems Development http://www.dsdm.org/
Methodology (DSDM)
eXtreme Programming
Exploration
Planning
Itérations
Production
Maintenance
26
eXtreme Programming
• Phases
– Exploration : Vision (20 ~ 30 mots), métaphore du système
(domaine), user stories (~ cas d’utilisation quelques 5 phrases ),
exploration (prototypage) de choix technologiques
– Planning: Le client définit les utilisations, les classifie par rapport à
son métier, détermine les utilisations qui seront prototypées dans
la première release, le développeur estime les durées de
développement, identifie les risques technologiques et suit la
progression du développement. Calendrier des releases
– Itérations
– Production
– Maintenance
eXtreme Programming : Itérations

Début
Itération
Choix des Estimer les durées Tester et
utilisations et établir les priorité Construire
Release
27
eXtreme Programming
• Itérations:
– chaque release est développée en plusieurs itérations. Elles ont
de durées non négociables (1-4 semaines). Les premières
itérations portent sur l’architecture et les aspects technologiques
les itérations suivantes sont orientées par les choix du client qui
peuvent évoluer d’une itération à l’autre
– Un WBS est déduit à partir d’une utilisation. Des tâches (3 J/H)
sont classées par priorité et exécutées
– Les tâches sont assignés à des paires de programmeurs qui se
relaient au clavier. Le développement commence par la définition
des tests
– A la fin de l’itération le client exécute les tests d’acceptation qu’il a
définis. Les corrections éventuelles sont reportées à l’itération
suivante
XP : Déroulement d’une tâche

Établissement Assignation Conception
d’une paire d’une tâche rapide
Définition Trouver un test qui

échoue
des test
Juste le nécessaire pour Simplifier et

Coder Refactor améliorer le code
que le test passe
Intégrer
28
eXtreme Programming
• Production
– Lorsqu’une release est prête, elle est déployée chez le client qui
exécute des tests d’acceptation. En particulier, il vérifie que les
enchaînements des IU contribuent à la productivité des
utilisateurs
– Types de déploiements: Big Bang, Incrémental, Parallèle, Green
field (Environnement vierge)
• Maintenance:
– Se déroule en parallèle avec les itérations de construction (une
release est maintenue alors qu’une autre est en cours de
construction)
– La philosophie de l’approche facilite la maintenance: une ou
plusieurs modifications correspondent simplement à des tests qui
ont échoués et qu’il faut corriger
eXtreme Programming : ?Unit

.NET http://nunit.sourceforge.net/
C http://check.sourceforge.net/
C++ Builder http://groups.yahoo.com/group/extremeprogrammi
ng/files/CppUnit17BCB30Pro.zip
C++ http://www.xprogramming.com/ftp/TestingFramewo
rk/CppUnit/CppUnit15.zip
Delphi http://dunit.sourceforge.net/
Eiffel http://w3.one.net/ jweirich/software/eiffelunit/
Haskell http://hunit.sourceforge.net/
HTML http://sourceforge.net/projects/htmlunit
Java http://www.junit.org/
JavaScript http://www.jsunit.net/
Oracle http://oracle.oreilly.com/utplsql/
Visual Basic http://tiniunit.sourceforge.net/
29
XP : JUnit
• Un jeu de Test se matérialise par une sous classe de
junit.framework.TestCase
• La méthode setUp() assure l’initialisation
• Les tests correspondent à des méthodes nommées
testXxxx
• La méthode tearDown() permet de libérer d’éventuelles
ressources aprés l’éxécution des tests
Modélisation du processus
logiciel
30
Introduction
• Un logiciel est le résultat d’un procédé de développement
• La qualité du logiciel est liée étroitement au PDL
• Améliorer la qualité requière l’analyse du PDL
• L’analyse du PDL requière sa modélisation
• Un modèle de PDL est une représentation purement
descriptive du PDL. Un MPDL doit permettre de
représenter les attributs d’un ensemble de PDL et être
suffisamment spécifique pour permettre de raisonner à
leur propos
• La recherche sur la modélisation du PDL date de 1984
Langages pour la modélisation du PDL

• 3 sortes de PDL :
– Les PDL qui ne sont coordonnés par aucun modèle
– Les PDL qui obéissent à un MPDL définit informellement
– Les PDL contrôlés par un MPDL définit formel (i.e. un interprète
‘exécute’ (enact) le MPDL au sein de l’environnement de
développement)
• Modélisation procédurale: Il n’y a pas de différence
fondamentale entre un MPDL et un programme. APPL-A :
Ada étendu par la gestion de la persistance et les
triggers (1987)
• Modélisation fonctionnelle : Le MPDL est exprimé sous
forme de fonctions de transformations. HFSP
31
Langages pour la modélisation du PDL
• Modélisation déclarative : le MPDL est décrit sous la
forme de règles Pré/Action/Post. Permet la prise
d’initiative : lorsque une pré devient vraie l’action est
déclenchée et permet la génération de plan pour atteindre
une post vue comme un but. Marvel, Merlin
• Modélisation basée sur les diagrammes états/transitions :
La dimension contrôle prime. Utilisation de réseaux de
Petri de haut niveaux: les jetons sont typés et peuvent
persister. FUNSOFT Nets
• Modélisation multi-paradigme
• Prototypes : SPADE, Inscape, Arcadia, Oikos, APEL,
ALF, ESF, Melmac,...
Business process
• En parallèle la modélisation des activités de l’entreprise
ont conduit à la gestion de workflows
• Les workflows sont utilisés pour décrire les MPDL
• ‘L’éxécutabilté’ du MPDL n’est pas encore atteinte et ne
sera pas atteinte rapidement
• L’approche MDA a déplacé la focalisation sur les produits
32
le workflow ‘Requirements’ dans RUP
[new system] [existing system] [new input]
Analyse pbm Understand

Stakeholders needs
Manage changing
requirements
[incorrect pbm]
[can’t do
[adressing correct pbm]
all the work]
Manage scope
Define system
of system [work in scope]
[More iterations]
Refine system
definition
[Requirements definition complete]
CMM
• CMM : Capability Maturity Model
• Cadre pour l’évaluation de la maturité du procédé de
développement
• 5 niveaux de maturité :
– Niveau 1 – Initial: le procédé est ad hoc ou chaotique. Peu
d’éléments du procédé sont définis et le succès dépend de
l’initiative des développeurs
– Niveau 2 – Répétable : Les coûts, délais et fonctionnalités sont
suivies par le management. Il existe une discipline qui permet de
répéter des activités similaires avec succès d’un projet à l’autre
– Niveau 3 – Défini : Aussi bien les activités d’ingénieries que les
activités de management sont documentées, standardisées et
intégrées au procédé global de l’entreprise. Il existe un procédé
bien défini
33
CMM
– Niveau 4 – Géré : Un ensemble détaillés de mesure sur le
processus et les produits sont collectées. Ces mesures sont
utilisées pour comprendre et contrôler le procédé et les produits
– Niveau 5 – Optimisé : Le processus est amélioré de façon
continue grâce à l’exploitation des données collectées et
l’expérimentation d’idées ou de technologies innovantes
• Chaque niveau est associé à des domaines de procédé
clé (KPA : Key process Area).
• En tout 80 KPA. Chaque KPA est défini par:
– Les objectifs que le KPA doit atteindre
– Les obligations auxquelles doit s’astreindre l’organisation pour
atteindre les objectifs
CMM
– Les aptitudes qui doivent être mises en place pour atteindre les
objectifs
– Les activités qui doivent être faite pour atteindre les objectifs
– Les méthodes à mettre en place pour le suivi de la mise en œuvre
– Les méthodes à mettre en place pour vérifier la réalisation
• Le cadre définit aussi les méthodes à mettre en place

pour changer de niveaux
• Il existe un mécanisme de certification voir
www.sei.cmu.edu pour plus d’informations
34
CMM
• Exemple KPA : Gestion des configuration
– But : Établir et maintenir l’intégrité des produits en s’appuyant sur
des identités de configuration, du contrôle des configurations,
l’historique des statuts de configuration et sur l’audit des
configurations
– Obligations : Définir une stratégie organisationnelle pour la
planification et la mise en place du procédé de gestion des
configurations
– Aptitudes : Définir le plan pour la réalisation de la GC, Fournir les
ressources, Assigner les responsabilités, Former les participants
KPA Gestion des configuration

– Activités : Identifier les items qui vont faire l’objet de la GC,
Introduire un système de GC, Créer la ‘baseline’ (i.e. Version 0
des items), Suivre les demandes de modifications, Contrôler les
modifications, Maintenir l’historique des révisions, Effectuer des
audits pour vérifier le bon usage
– Suivi : Mettre les items sous la GC; identifier et impliquer les
intéréssés au procédé de GC; Mesurer le procédé (Nombre de
changement, d’audit,...);
– Validation : Évaluer la conformation de la définition du procédé au
procédé et traiter les discordances; Transmettre un feedback aux
décisionnaires
35
Méthodes et méthodologies
Préliminaires : Modélisation
Analyse des besoins et Spécification
Comprendre le système et définir ses attendus : LE
QUOI
Conception Architecturale et détaillée

Identifier les alternatives et Etablir les choix : LE
COMMENT
Codage et Test
Choix techniques de bas niveau : LA REALISATION
36
Modélisation
• Vue fonctionnelle
• Vue comportementale
• Vue structurelle
• Approche transversale : modélisation objet
• Autres : temps, sûreté de fonctionnement, répartition,

performances,…
Structure d’une méthode
• Langage de Modélisation
• Démarche
37
Structure de méthodes : Modélisation
Formelle
Ax2+Bx+C
A,B,C, x  [-,+]
Sémantique
Informelle
Association: Lien
structurel entre …
Concepts
Textuelle
Z=F(x,y)
Notations
Graphique
Structure de méthodes : Modélisation

• Langage
– Syntaxe concrète (textuelle – graphique)
– Syntaxe abstraite (BNF, Arbre, métamodèle)
– Sémantique (sémantique dénotationnelle, Action sémantique,

pré/post conditions, point fixe,…)
38
Structure de méthodes : Démarche
Démarche : Les étapes et leur séquencements
1. Calculer delta 1. Collecter les informations

2. Lorsque Delta > 0 2. Identifier les synonymes
Calculer Racines doubles et les poly sèmes
3. … 3. …
Algorithme Actions abstraites

Support automatisé Interprétation humaine
Structure de méthodes : Assistance

• Heuristiques portant sur les modèles ou la démarche:
– Choisir les noms d’associations de sorte que la combinaison du
nom des entités et de l’association lu de gauche à droite constitue
une phrase
– Vérifier que A, B et C ne sont pas les développements d’un carré
parfait et dans ce cas déterminer directement la racine double
• Caractérisation par des exemples et des critères
– Lorsqu’une information ne prend que des valeurs discrètes, il
s’agit potentiellement d’un événement, par exemple la décision
d’accord de crédit
 L’aspect le moins bien défini des méthodes
39
Le Langage de Modélisation
UML
Adel KHALFALLAH
Institut Supérieur d’Informatique – El Manar
Adel.Khalfallah@fst.rnu.tn
Adel_Khalfallah@yahoo.fr
Introduction
40
UML : Historique
Août 02
OMT UML UML
(Rumbaugh) 1.4 2.0
1996 Sept. 2001
BOOD UML UML

0.9 1.1
Nov. 1997
OOSE
(Jacobson)
Catalysis ROOM etc.
UML : Un synopsis
• Modèles : 15 types de diagrammes informels et
graphiques
– Diagrammes structurels : diagramme de classes, diagramme
d’objets, diagramme de structures composites, diagramme de
composants, diagramme de déploiements, diagramme combiné
composant/déploiement
– Diagrammes comportementaux:
• diagramme d’activités
• Diagrammes d’interactions : diagramme de séquences,
diagramme de communications, diagramme global
d’interactions, diagramme de temps,
• diagramme d’états, diagramme de protocole d’états
– Diagramme fonctionnel : diagramme des cas d’utilisations
41
UML : Un synopsis
– Diagramme de gestion des modèles : diagramme de paquetages
• Démarche : UML n’en fournit pas, des propositions sont

faites indépendamment (RUP,2TUP,…)
Diagramme des cas

d’utilisation
42
Les cas d’utilisations
• Introduits par I. Jacobson
• vue fonctionnelle, correspond à un comportement type
du système
• Une manière spécifique d’utiliser le système selon le
point de vue de l’utilisateur
• Fixe les limites entre le système et son environnement
• Elément du cahier des charges
• Outil de communication avec le client / Référence pour la
suite
Cas d’utilisation : Exemple

Système : DAB
Retirer de l ’argent
Client
Déposer de l ’argent
Transfert entre comptes
Administrateur
Maintenir le distributeur
43
Use case : Les concepts
Acteur Cas
m d'utilisation
n
Acteur
Limites du système
Acteur: toute entité externe

Intéractions (Associations)
Au système et échangeant des Chaque cas d’utilisation
informations avec lui. Exemple: correspond à un ensemble de
Professeur, Capteur, BD, TCP/IP,… transactions effectuées au cours
d’une interaction entre l’acteur et
le système. Éventuellement
précisé par des diagrammes
d’interaction

• Acteur : Source ou destination finale d’une interaction
(émission/réception de données, ordres, événements,…).
Lors de l’analyse décrivent des roles de personnes, des
systèmes ou des composants puis évoluent vers des
interfaces (utilisateurs, API,…). Traçabilité.
• Un acteur principal pour chaque cas d’utilisation et
éventuellement quelques acteurs secondaires
• Cas d’utilisation : Interaction ayant une valeur ajoutée
pour au moins un acteur. Lors de l’analyse les acteurs
principaux sont essentiellement considérés. Il peut
évoluer vers un C.U technique. Exprime un besoin et non
une solution. CRUD (CCMS)
44
• Syndrome de l’acteur monopolisant le système :
mauvaise identification des rôles joués par l’acteur
• Un Diagramme est une partie de modèle correspondant à
une décomposition ici il regroupe des cas d’utilisation et
des acteurs
• Un cas d’utilisation a au moins deux catégories de
lecteurs : Le client final et l’informaticien
Relations entre use cases
• Relation <<include>> : Factorisation
• Relation <<extend>> : Optionalité
• Relation de spécialisation : Substitution
45
Relation Include
« include »
C1 C2
• Permet d’identifier un sous ensemble commun à plusieurs

cas
• C1 utilise C2  toute activation de C1 entraîne une
activation de C2, C1 est incomplet sans C2, le
déroulement de C1 sans C2 correspond à une situation
exceptionnelle
• Définit implicitement une hiérarchisation
• Parfois, dans le cadre de la factorisation, C2 ne définit
pas un usage ‘complet’ du système, il est considéré
comme abstrait
Relation Include
• Lorsque un C.U. correspond à une factorisation, son
déclenchement n’est pas précisé et sa terminaison
explicite les informations disponibles au C. U. de base
• Le C.U de base ne doit dépendre que du résultat du C.U.
inclut et pas de la façon d’obtenir le résultat
• Le C.U. inclut ne doit pas dépendre du C.U. de base
• Le C.U. inclut reçoit-il des paramètres ? À traiter au cas
par cas
46
Exemple Include
« include »
« include »
Recouvrement
Passer Commande Facturation
Exemple Include
« include » « include »
Vérifier abonnement
Emprunter un livre
Consulter prêts
47
Relation Extend
Extension points
« extend »
ext 1
Extension
ext 2 C2
Condition
… …
Extension point
Base C1 ext 1
• Permet d’identifier les comportements alternatifs ou

exceptionnels, i.e. conditionnels (erreurs,…)
• C2 étend C1  C2 est un complément à C1, C1 peut se
dérouler sans le complément
• C2 n’est pas activable directement, C2 s’impose à C1
• Définit implicitement une hiérarchisation
• <extension point> ::= <nom> [: <Explication/Localisation>]
Relation Extend
Condition 1
Condition 2 C1
C2
48
Relation Extend
C1
C2
Exemple : Extend
Passer Commande
Resaisir
Réapprovisonner
« extend » « extend »
Condition Condition
Client inexistant qté sous seuil
Extension point Extension point
Resaisir Réapprovisonner
Itérer saisie Réapprovisionner stock
49
Example : Extend
• Passer commande
1. Entrer le nom et le numéro de compte
2. Vérifier qu’ils sont valides
Extension: itérer la saisie si client inexistant
3. Saisir l’article commandé et la quantité
4. Vérifier la quantité en stock
Extension : réapprovisionner si la quantité en stock n’est pas
suffisante
5. Enregistrer la commande
Example : Extend
Condition
Livre réservé
Retour livre Extension point
…
Enregistrer livre
Condition
Livre réservé
Extension point
…
Traiter réservation
50
Relation Extend
• Extend peut être utilisée pour séparer des points de vue
Facturer
Appel téléphonique
« extend »
Condition
toujours
Extension point
Facturer
Calcul coût
Relation Extend
• La description d’un U.C. d’extension doit faire référence à
tous les U.C. de base qu’elle étend et préciser pour
chacun, le point et la condition d’extension et la continuité
du flot de contrôle à la fin du U.C. d’extension.
• Lorsque plusieurs U.C. font référence au même point
d’extension d’un U.C. de base cela sous entend que
l’ordre de déroulement est indéterminé
51
Transitivité, Acteurs et Include
Gestion Commande « include »

Client
Facturation
Transitivité, Extend et Include

« include »
C1 C3
« extend »
« include » ?
C2
C1 C3
« extend »
« extend » ?
C2
52
Extend et include
• Inclusion versus extension
U.C. base incomplet U.C. base complet
U.C. Inclut ne dépend pas de la base U.C. ext. Dépend de la base
• Include, extend et la généralisation doivent être utilisées

avec modération car leur sémantique reste ambiguë et
elle rendent les modèles difficiles à comprendre
• Ces relations ne doivent être introduire que lorsque les
descriptions textuelles commencent à être stabilisées
Contrôle des accès
« include »
Modifier fond Vérifier droits
• La vérification des droits peut aussi être exprimé par une

précondition ce qui permet de conserver un niveau
d’abstraction uniforme
• Dans les deux cas redondance: la pré condition ou
include
53
Recherche
Recherche Recherche
« include »
traitement Traitement1 Traitement1
La recherche est factorisée

le résultat de la recherche Le résultat de la recherche est
est utilisé dans le traitement traité de 2 façons différentes
Login/Logout
« include »
Traitement Login/Logout
• L’identification doit être effectuée à chaque traitement

• En général, il n’y pas de relations entre Login et les autres
U.C.
54
Use case et généralisation
Valider utilisateur
Protocole de transport
Vérifier mot de passe

TCP/IP
Le cas d’utilisation spécialisé
L’acteur spécialisé hérite des
est substituable au cas
interactions de l’acteur père
d’utilisation père
Qté > Seuil
Qté < Seuil Passer Commande
Réapprovisionner
55
Vérifier utilisateur
Vérifier mot de passe

• Le C.U fils remplit la même fonctionnalité, il spécialise
certaines parties du C.U père. Les transactions effectuées
par le père sont soit héritées directement soit redéfinies
au niveau du fils, i.e la description du fils peut se référer à
des parties du père
• Le C.U. peut être considéré comme abstrait i.e. ne
donnant pas lieu directement des instances, il définit la
fonctionnalité sans donner une façon de la remplir
• Le père est hérité avec ses flots alternatifs et inclus
56
Détails d’un cas d’utilisation
• Diagramme de cas d’utilisation à lui tout seul est
insuffisant
• Il faut :
1. établir la traçabilité entre le cahier des charges et le modèle des
cas d’utilisations
2. Expliciter le comportement du système pour chacun des cas
d’utilisations par
– Description textuelle
– Prototype des interfaces
– Un ou plusieurs diagrammes de séquences/scénarios
– Un ou plusieurs diagrammes Etats/transitions

• Différents niveaux de description :
– Description boite noire : échanges entre le client et l’interface DAB
et conséquences sur le compte du client
– Description boite grise: les traitements de log sont décrits
– Description boite blanche : les détails d’interfaçage avec le réseau
sont décrits
• Le diagramme des C.U. est destiné à plusieurs lecteurs
• Le C.U. peut référencer un dictionnaire de données, un
glossaire ou des règles de gestion
• Un paragraphe peut être commun à plusieurs C.U
57
• Lorsque la description est longue le texte peut être
organisé en niveaux : le premier niveau fait référence à
des titres de paragraphes
• La description peut éventuellement préciser
l’enchaînement du déroulement dans le cas des relations
include et extend
• A partir de la description du C.U on déduit des objets et
des diagrammes d’interactions
Modèle de la description textuelle

• Résumé :
Titre, But, Résumé, Dates, Version, Responsables, Acteurs,…
• Préconditions :
Ce qui doit être vérifié avant que le C.U. ne commence
• Enchaînements :
– Evènements de déclenchement
– Séquence nominale/C.U. référencés
– Séquences Exceptionnelles/Exceptions
• Postconditions
ce qui est vrai après que le C.U. se soit déroulé
58
Modèle de la description textuelle
• Besoins d’IHM
Expression de contraintes liées à l’interface
• Contraintes non fonctionnelles

– Fréquences
– Volumétries
– QoS: Disponibilité, fiabilité, Performances
– Concurrence
Règles de gestion
• Exemple : Une commande contient au moins un article,
un commande urgente est une commande passée le jour
j et qui doit être livrée le jour j+1
• Chaque règle de gestion doit être identifiée de façon
unique
• Les règles de gestion se réfèrent au domaine et ne sont
pas nécessairement automatisable
• Les R.G de gestion sont référencés à partir de différents
U.C. et éventuellement par plusieurs systèmes, leurs
pérennité doit être assurée
59
Construction des cas d’utilisation
Identifier Acteurs
Identifier Messages Identifier fonctionnalités
S’appuyer sur des scénarios
Construction des cas d’utilisation

• Quelles sont les fonctions principales et secondaires du
système ?  C.U./Messages
• Qui est le source/récipiendaire d’un message ? 
Acteurs
• Détails d’un C.U  Acteurs/Messages/C.U.
• Variations d’un C.U.  C.U.
• Comment un acteur utilise le système  C.U/Messages
• Quels fonctions sont nécessaires à la gestion d’un
message ou ses données  C.U.
60
Erreurs usuelles
« include »
Déterminer marges
« include »
Saisir Commande
« include »
Vendeur
« include » Créer ligne commande
Créer Commande
« include » Consulter Client
Editer client
Erreurs usuelles
• La relation « include » cantonnée à une décomposition
fonctionnelle : aucune factorisation n’est présentée
• Le niveau de granularité n’est pas uniforme  rester à
un niveau de discours équilibré: ni trop général ni trop
spécifique, ne pas rechercher l’exhaustivité
• Créer ligne de commande correspond au COMMENT de
la création de commande
61
Erreurs usuelles
<<include>>
Saisir Commande
<<include>>
Vendeur
Chercher Client
Consulter Client
<<include>>
Editer client
Erreurs usuelles
1. Afficher la liste des clients à partir de la base de
données centralisées
2. L’acteur choisit un de ces clients.
3. Le système présente l’écran de saisie de commandes
4. Tant qu’il reste des articles pour cette commande
l’acteur entre la clé de l’article et la quantité
5. Le système met à jour le total courant
Fin Tant que
6. Valider la commande
62
Erreurs usuelles
• Les cas d’utilisations correspondent à descriptions de
haut niveau orientées utilisateurs
• L’effort (temps, ressources humaines et matérielles) pour

leur mise au point doit être négligeable par rapport au
temps nécessaire pour le développement de l’ensemble
du système
Erreurs usuelles
1. Le vendeur sélectionne un client
2. Le système guide le vendeur dans la saisie des détails
de la commande (références des articles et quantités
commandées) il calcule au fur et à mesure le total de la
commande.
3. Lorsque le vendeur à terminé la commande, il la valide
et le système l’enregistre
63
Erreurs usuelles
client Gérer réveil
• Le client fixe l’heure de réveil

• Le système réveille le client à l’heure sélectionné
Mémoriser
réveil
client
Réveiller client
Gestion des Surveillances

Acteurs
• Enseignant
• Resp. Plan
• Resp.
Personnel
• Administrateur
• Ecran Entités externes communicantes avec le système ?
–Dans cet exemple : Non relais uniquement
• Clavier
–Dans le cas d’une borne interactive tactile: Oui
64
Quelles sont les fonctions majeures du système ?
« include »
Resp. Plan Gestion des plans

« include »
Calcul statistiques
Gestion des enseignants

Resp. Personnel
Gestion des utilisateurs
Administrateur
Maintenance des informations

Cas d’utilisations
Comment l’enseignant utilise le système ?
• Consultation des plans hebdomadaires
– N’est pas spécifique aux enseignants : Tous les utilisateurs peuvent
consulter les plans
– Connexion comme préalable à la consultation
• Consultation de ses propres surveillances durant une période
– Connexion préalable
65
• Connexion cas d’utilisation ?
• Dans ce contexte: oui
• Système : non
• Tous les utilisateurs peuvent consulter les plans mais cela requiert une
connexion préalable :
<<include>>
Connexion
Consultation Plan
Enseignant
Administrateur
Resp. Plan Resp. Personnel

<<include>>
Toute consultation
comprend une Connexion
Consultation Plan
connexion, aucune
information sur la
chronologie
Utilisateur Consultation ciblée
Resp. Personnel
Administrateur Resp. Plan Enseignant
66
L’utilisateur dispose
d’une fonction de
Consultation Plan
connexion
OU ?
Connexion
Utilisateur Consultation ciblée
Resp. Personnel
Resp. Plan Enseignant

<<extend>>
Modification de plan
Gestion des plans
<<extend>>
Resp. Plan
Connexion
Création de plan
Consultation de plan
Utilisateur
Consultation ciblée
Resp. Personnel Administrateur Enseignant
67
• Définir les informations de base (cour, semaine,…) est en
soi une gestion de plan
• Créer le plan, le modifier, le supprimer sont des additions
à la gestion de plan

Création de plan
Resp. Plan
Gestion des plans
Connexion
Utilisateur
68
• La gestion de plan est abstraite, elle spécifie la définition
des informations de base (cour, semaine,…) puis un
traitement abstrait sur ces informations de base
• Créer le plan, le modifier, le supprimer,… héritent de la
définition des informations de base et implantent chacun
un traitement spécifique de ces informations

• Erreur de login  Paquetage Gestion de sécurité
• Modification d’un plan ‘passé’?
• Plan incomplet ?
• Jours fériés?
• …
1. Autres diagrammes dans le paquetage gestion des
plans
2. Attention à la surenchère des fonctionnalités !
69
Gestion des surveillances

• Résumé :
Titre : Création d’un plan de surveillance hebdomadaire
But : Création d’un nouveau plan hebdomadaire pour une cour et une semaine pré-
établies.
Résumé : Affectation des enseignants aux différentes plages horaires pour
constituer un plan de surveillance.
Acteurs : Responsable Plan (Principal)
Responsable : Adel KHALFALLAH
Date Création : 3 Janvier 2002 Version : 1.1
Date Modification : 10 Janvier 2002

Modification : Prise en compte de l’enregistrement de plans incomplet
70
• Préconditions :
1. Il n’existe pas déjà un plan pour la même cour et la même semaine
2. Le responsable plan s’est authentifié au travers de la procédure de
connexion
• Enchaînements :
Ce cas d’utilisation commence lorsque le responsable plan demande la création
d’un nouveau plan au système.
1 – Affectation d’un enseignant à une plage horaire : le responsable plan choisit un
enseignant dans une liste des enseignants triées par ordre de nombre de
surveillances croissant. Ensuite, il choisit une plage horaire, le système visualise les
initiales de l’enseignant dans la plage et met à jour l’ordre de la liste des
enseignants ainsi que les statistiques de l’enseignant. Lorsque l’enseignant ne peut
pas assurer la surveillance soit parce qu’il a une contrainte soit parce qu’il a atteint
son nombre de surveillances maximum soit parce qu’il est affecté à une autre
surveillance durant la même plage horaire il faut exécuter l’extension : violation de
contrainte.

• Enchaînements (Suite):
2 – Modification de l’affectation d’une plage : Après avoir choisit un enseignant, le
responsable peut choisir une plage horaire qui a déjà été affectée, le système
modifiera la plage pour visualiser les initiales du nouvel enseignant. Le système
mettra aussi à jour l’ordre de la liste des enseignants et les statistiques des
enseignants concernés . Lorsque le nouvel enseignant ne peut pas assurer la
surveillance soit parce qu’il a une contrainte soit parce qu’il a atteint son nombre de
surveillances maximum soit parce qu’il est affecté à une autre surveillance durant la
même plage horaire il faut exécuter l’extension : violation de contrainte.
3 – Enregistrement de plan : A tout moment le responsable de plan peut enregistrer
un plan (éventuellement incomplet). Il pourra alors retrouver le plan dans l’état au
cours de sessions ultérieures. Lorsque le responsable de plan tente d’enregistrer un
plan comportant une violation de contraintes il faut exécuter l’extension :
enregistrement de plan incohérent. Lorsque le responsable tente d’enregistrer un
plan vide, il faut exécuter l’extension: enregistrement de plan vide
71
• Enchaînements (Suite):
4 – Annulation de plan : A tout moment le responsable de plan peut annuler les
modifications qu’il a effectué, il se retrouve alors avec un plan vide. Les statistiques
des enseignants ainsi que leur ordre dans la liste sont mis à jour en conséquence
5 – Impression de plan : A tout moment, le responsable de plan peut imprimer un

plan. Il obtient alors un tableau à deux dimensions selon le format défini par le
document… conforme au plan en cours de création.
• Postconditions
– Le plan enregistré n’est pas vide
– Le plan enregistré respecte les disponibilités des enseignants.
– Un enseignant ne se retrouve jamais affecté simultanément à deux
surveillances
– Un enseignant ne dépasse jamais sa charge de surveillance

• De nouveaux C.U. ont étés découverts
• L’étude de gestion des statistiques doit commencer
• La création de plan comprend deux aspects :
1. Création d’un plan vide
2. Edition de ce plan (affectation, modification d’affectation,
enregistrement, impression, annulation)
• La modification de plan comprend aussi deux aspects :
1. Recherche du plan à modifier
2. Edition de ce plan
72
<<extend>>
Resp. Plan <<include>>
Gestion des plans
Connexion <<extend>>
<<include>>Edition de Plan
Consultation de plan Création de plan

Utilisateur
<<extend>> <<extend>>
<<extend>>
Enreg. de plan incohérent

Resp. PersonnelAdministrateur Enseignant Violation de contraintes Enreg. de plan vide
Gestion des surveillances final
CUD Plan
Édition plan
<<include>>
Resp. Plan
Connexion Recherche plan

<<include>>
Utilisateur
73
Stéréotypes issus des Business Process
Travailleur Interne (Directeur commercial,…)
Travailleur d’interface (Vendeur,…)
Quelques heuristiques finales

• Définir un niveau d’abstraction par diagramme
• Ne pas présenter plus d’une dizaine de U.C. et d’acteurs
par diagramme
• Une seule hiérarchie de généralisation par diagramme
• Un U.C. peut se transformer en acteur suit à des
orientations stratégiques
• Développer par incréments: Les U.C. principaux et les
U.C. inclus d’abord
74
• Un Use Case par Processus métier
• Processus métier : processus du domaine fournissant une
valeur ajoutée notable pour le métier
– Exemples : Créer des commandes , effectuer des livraisons
– Contre exemple : se connecter

• Pour certains système pas de U. C. (Compilateurs)
• Nommer Les U. C. sous la forme Verbe + Nom en se référant à
l’objectif du U. C.
• Créer / Modifier / Supprimer … X  Gérer X
• Rechercher l’« essence » :
– Intention de l’acteur / Responsabilité du système.
Acteur: Login  S’identifier  Eviter le vol
Système : Mot de passe  Valider Identité  Protéger Ressource
• Diagrammes U. C. Sont très secondaires, 90 % de l’effort
doit être orienté vers la description textuelle
• Placer l’acteur principal à gauche du U. C. Le reste à
droite
75
Diagramme d’activités
Introduction
• Inspirés des organigrammes
• Différence substantielle entre UML 1.4 et UML 2.0
• Considérés parfois comme faisant partie de la vue
fonctionnelle car il décrit la logique des
fonctions/processus
• Permet différents niveau de granularité:
– Opération : correspond à un algorithme, offre toutes les
constructions logiques habituelles, la traduction en
algorithme/langage est immédiate
– Cas d’utilisation : correspond à un processus décrit, les règles, les
échanges d’information, les décisions et les résultats nécessaire
au cas pour atteindre son objectif
– Plusieurs cas d’utilisation : correspond à un workflow décrit le
contrôle et l’enchaînement
76
Diagramme d’activité : Exemple
Transition
Départ
Recevoir commande
Activité
Fork
Décision Créer BL Émettre Facture
[prioritaire] [ordinaire]
Expédition Expédition
Garde Rapid poste Colis postal Encaisser paiement
Point de Join
jonction
Clôturer commande
Fin
Diagramme d’activité
• Activité : Etape d’un processus, calcul, manipulation de données,…
• Transition : définit l’enchaînement des activités, la transition à lieu
lorsque son activité source se termine
• Condition (ou garde) : Une transition n’est franchissable que lorsque
sa garde éventuelle est vraie
• Décision : décrit un choix dans la transition à franchir. Chaque choix
est décrit par une garde, elles doivent être mutuellement exclusives
(if-else/case)
• Point de jonction : matérialise la rencontre de 2 chemins alternatifs
• Départ et fin : Une entrée plusieurs sorties
• Concurrence : fork génération de tâches concurrentes, join
synchronisation
77
Diagramme d’activités (UML 2.0)
• Une activité est décomposable en actions atomiques
• Les actions peuvent consommer ou produire des objets
• Le flot entre actions est décrit en utilisant des ‘arcs’
(activity edge) et des nœuds de contrôle
• Il y a 2 sortes d’arcs représentés par une flèche
– Les flots de contrôle : correspondent à une transition
– Les flots d’objets : correspondent à une transition qui matérialise
le passage de données produites par une action et consommée
par l’action suivante
• Un arc peut être décoré par : le nom d’un événement, un
objet, une interruption ou un connecteur (simplifie la
présentation)

• Le passage d’une action à l’autre est déclenché par
– La fin d’une action
– Des données (attendues par une action) sont produites
– Un événement externe se produit
• Le départ et l’arrivée sont des nœuds de contrôle (nœud
initial et noeud final). Quand le déroulement atteint un
nœud final l’activité se termine et toutes ses données sont
perdues
• Les décisions et les points de jonction sont des nœuds de
contrôle. Ils peuvent être unifiés
78
• Les données en entrées d’un nœud fork sont dupliquées
sur tous les arcs en sorties
• Un nœud fork et un nœud join peuvent être unifiés pour
décrire une synchronisation suivie d’une génération
• Un join peut être décoré par une condition booléenne
pour la synchronisation des taches ou une condition
booléenne sur des valeurs
DA : Représentation graphique
Gestion de plan
Connecteur
Afficher les cancel
A
Choix + Plans existants
Préparer Encaisser
articles paiement jonction [Recommencer]
fork + join [Nouveau] [Existant]
A
Créer plan Lire plan
Confirmation
Editer plan Enregistrer
save
[Non] [Terminer]
Livrer Réapprovisionner
Evénement
[Oui]
79
• Les données transférés par un flot d’objet sont contenues dans un
nœud objet
• Les nœuds objets sont de trois types: objet, ensemble d’objet, signal
• Un objet qui est en donnée d’une action est un ‘input pin’. Un objet
qui est en résultat d’une action est un ‘output pin. La fusion d’un input
pin et d’un output pin correspond à un nœud objet
• Un flot d’objet ou un pin peut être labellisé par l’action CRUD
effectuée sur l’objet ou par un filtre pour limiter les objets qui passent
à travers le flot
• Des contraintes d’ordre ou de taille maximale peuvent être décrite
pour un flot d’objet qui est alors considéré comme un buffer
• L’état d’un objet peut être mentionné pour un nœud objet pour définir
un filtre
• Un objet résultat d’une activité peut être une exception, l’activité est
interrompue et l’exception est propagée à l’activité suivante
Commande B. de livraison
Afficher les Input pin Traiter
Plans existants Commande Output pin
Set of Plan Ensemble B. L.
d’objets Commande
Traiter
{read}
Livrer
Commande {create}
Créer plan Lire plan
OU
Flot
d’objet B. de livraison
Nouveau Plan Traiter
plan {create} {read} Livrer
Commande
Objet OU
Objet exception Traiter B. De
Livrer
Commande {create} Livraison {read}
80
• Un objet ‘central buffer’ modélise une queue d’objets
partagée entre un producteur et un consommateur
asynchrones
• Les partitions d’activités permettent d’associer un
responsable à une activité. Une partition pourra être
décomposée en sous partition
• Les partitions d’activités peuvent être organisés par
rapport à une 2ème dimension qui décrit une perspective
particulière sur l’activité
• Une nœud fin de flot décrit la fin d’un flot dans une activité
composée de plusieurs flots concurrents
commande
Gestion des
commandes web
<<Central buffer>> Gestion
Commande des B.L
Gestion des
Commandes
magasin commande
Ou
(Comptable)
Magasinier
Gestion Gestion Livrer Clôturer Gestion

Commande BL Commande Commande Facture
Facture
Comptable
Gestion Encaisser
Facture
Facture Paiement (Comptable)
Encaisser
Paiement
Partition
81
Partition
Sous partition Sous partition
…
… …
Fin de flot
ou
Partition::Sous partition
Action
Seconde perspective
Tunis Sousse
Magasinier
<<class>>
Gestion Gestion Livrer Clôturer

Commande BL Commande Commande
<<external>> <<class>>
Caissier
Gestion Encaisser
Facture
Facture Paiement
Payer
Client
82
• Une activité peut avoir une ou plusieurs instances
• Une activité peut avoir une pré et une post-condition
exprimées sous forme d’annotations ou apparaissant a
coté de l’intitulé
• Un objet peut être un ‘data store’, les lectures ne sont pas
destructives, les écritures sont des mises à jour le cas
échéant
Diagramme de classes
83
Introduction
• Le diagramme le plus exploité pour la génération de code
• Roundtrip engineering :
Modéliser  Générer  Modifier  Modéliser ...
• Maintenir la cohérence entre le modèle et le source est un
problème difficile
• Veillez à respecter les règles du langage au niveau du
modèle (nom de classe, constructeurs, types de bases,...)
Rappels
• Objet
– Identité
– Etat
– Comportement
• Encapsulation
• Abstraction
• Classes
• Héritage
• Polymorphisme
– Surcharge
– Généricité
– Liaison dynamique
84
Classes
Personne Personne Personne Personne

Nom CalculerAge Nom
NeLe : Date
CalculerAge
Un objet ne peut
pas être un attribut
Diagrammes de classes : Classes

Nom
{propriétés}
Vis Nom Attribut[Multip]: Type=Valeur {propriétés}
Stéréotype Vis Opération(Paramètres) : Type Retour {propriétés}
‘::’ : opérateur de portée

Propriété : Attribut valué ( au métamodèle) {Auteur=A. K} ou
description; contraintes (OCL), pre/post conditions; Exceptions...
Visibilité: Public (+) Protégé (#) Privé(-) Paquetage (~)
Multiplicité : 0..N {Propriété: ordered, unique, required, ...}
Les attributs et opérations de classes sont soulignés
Stéréotype : « create », « request », ...
Paramètres : [in | out | inout] Nom : Type=Valeur Défaut
Attribut ou association dérivé : /Age
85
Classes
• D’autres compartiments peuvent être ajoutés
Nom
Attributs
Opérations
Exceptions
• Une classe peut contenir une autre classe
Stéréotypes issus des Business Process

Entité (Commande, Article,…)
Élément du domaine, état important
Gère sa propre intégrité
Peu de connaissance sur son entourage(réutilisable)
Classe contrôleur
État très simple
régit le comportement de son entourage
Classe correspondant à une interface
« Entité »
Nom_classel
86
Classes
• Les notions de classe et d’ensemble sont

proches
• La spécification d’une classe est analogue à la

description en compréhension d’un ensemble
Classes
X
Propriété caractéristique de X
:X :X P(x)
:X
:X :X :X :X
:X :X
:X :X
87
classe utilitaire
• Stéréotype <<utilitaire>> (« utility »)
• Tous les membres (donnés et opérations) sont statiques
• Correspond à une bibliothèque de fonctions
<<utilitaire>>
Math
sin(x:réel):réel
cos(x:réel):réel
classe énumération
• Stéréotype <<enumeration>>
• Les attributs ne sont définies que par des valeurs
correspondant à des constantes
• Il n’y a pas de comportement
• Correspond au type enum
<<enumeration>>
Feu
Rouge
Jaune
vert
88
Classes génériques
Type,Variable
Une Classe
« bind »
(UnType,Unevaleur)
LaClasse
classes d’interface
« Interface »
Nom Interface Nom Interface
Nom Interface
Client Implantation
Le client requière l’interface

‘Nom Interface’ qui lui est
fournie
Implantation
Implantation
• UML 2.0 autorise des ‘attributs abstraits’ (non implantés)

• Les interfaces peuvent être imbriquées
• Par la Exemple : Interface de pile avec multiple réalisation
• Notation DCOM
89
Associations
Relations structurelles entre objets
Association binaire
Emploie
Société Personne
Association : Rôle
Employeur Employés
Société Personne
Le rôle est particulièrement utile lorsque

l’association est réflexive
Père de
Personne
Fils de
90
Association : Rôle (UML 1.4)
•Le rôle peut avoir une visibilité +,- ou #
•Le rôle peut avoir un type, dans ce cas la classe réalise
plusieurs interfaces et le type limite celle qui est utilisée
Souris Clavier
+Gest : Souris
Fenêtre Gestionnaire
Association : Cardinalités
1..*
Société Personne
• 0..1
• M..N Combien d’occurrences de
• *  0..N personne peuvent être
• V1, V2, V3 associées à une occurrence
de Société ?
Réponse : Au minimum 1
au maximum N
91
Associations : contraintes sur les cardinalités
1..*
Hiérarchie Grade
{ordred}
•Il existe une relation d’ordre sur les grades

•Les opérations d’insertion de suppression, etc...
doivent préserver cette relation
•Plus généralement différentes contraintes peuvent être
exprimées
Association : Qualificateur
*
Société Directeur : bool Personne
Société N° CNSS Personne
• Réduit la cardinalité, permet un accès indexé, société

requière l’accès indexé
• Le qualificateur est un attribut de la classe qui va faire
l’objet de l’accès indexé
• Lorsque la cardinalité réduite équivalent à une clé
• Implantation : table de hashage, map, ...
92
Association : Contraintes
Organise
Personne Concours
{xor}
Participe
• On ne peut pas avoir simultanément le lien ‘Organise’ et

le lien ‘Participe’ entre un objet personne et un objet
concours
• Une contrainte sur plusieurs lien passe par une
annotation
Association dérivée
1..* 1..*
Société Personne Pointage
1..*
/Les pointages
• Correspond à une association transitive
93
Association : Navigation
Société Personne
Société x Personne
• Dans le premier cas la navigation société vers personne

doit être supportée, la navigation de personne vers
société est indéfinie
• Dans le deuxième cas la navigation de personne vers
société ne sera pas supportée
Associations porteuses d’information
* 1..*
Commande Article
LigneCmde
QuantitéCmdée
• L’information portée par l’information est représentée

dans une classe ‘LigneCmde’
• La classe représente un couple (Commande, Article)
94
Classe association
* 1..*
Commande Article
LigneCmde *
Quantité * Récapitulatif
Ajout()
Suppression()
• L’association a un comportement et participe à d’autres

associations
• Une ligne de commande peut-elle partagée par plusieurs
commandes ?
Réification
u v * 1..*
C1 C2 Cmde Article
C3
LigneCmde
1 1..*
1 v Cmde LigneCmde
C1 C3
*
u
1 1
C2 Article
95
Associations n-aires
Relations structurelles entre objets
* *
Professeur Etudiant
Salle
Agrégation
1 *
Paragraphe Ligne
* 2..*
Droite Point
• Composé – composant
• Interfaçage, coordination des composants
• Propagation
96
Composition
1 5 1..*
Voiture Roue Vol Dossier
Voiture Voiture
LesRoues[5] : Roue
5 UML 1.4
Roue
• Forme forte d’agrégation physique

• Le composite joue le rôle d’interface pour les éléments agrégés
• L’élément agrégé n’est pas partagé par plusieurs composite (0..1)
• L’élément agrégé n’existe pas en dehors du composite
(création/destruction)
Généralisation
Article Article
Textile Luxe Alimentaire

Textile Luxe ...
•Héritage de propriétés et d’attributs
publiques ou protégés
•Extension, Redéfinition
•Héritage/Redéfinition des associations
97
Sous-classes
X
Propriété caractéristique de X
Y Z
Propriété caractéristique de Y Propriété caractéristique de Z
:X :X
:X
:X :Y :z :z
:y
:Y
:y
:z
P(x)
P(y) y z P(z)
X
Généralisation : discriminant
« PowerType » Véhicule
Motorisation
Milieu
VVoile VMoteur VTerrestre VMarin
Le discriminant (ou powertype) explicite le(s) critère(s) qui

ont permis de dériver une spécialisation
98
Généralisation
VMarin VAérien VTerrestre
Hovercraft
Héritage multiple
Généralisation
X
P ropriété caractéristique de X
Y Z
Propr iété cara ctérist iq ue de Y Propriété caractéristique de Z
T T P(T)  P(Y)  P(z)

Propriété caractéristique de T
:X
:X :X
:X :Y :Z :Z
:Y :T
:Y
:Z P(x)
P(Y) Y z
P(z)
X
99
Collision de noms
T
A
X Y X Y
A A A de T A de T
Z Z
A de X A de T par X
A de Y A de T par Y
Classe abstraite
Le nom des
Classe abstraite classes abstraites
est en italique
Classe concrète A Classe concrète B
:Y :z :z
:y
:Y
:y
:z
P(x)
P(y) y z P(z)
X
100
Généralisation
Liste Tableau
<<implémentation>>
Liste Fixe
Liste Fixe ne publie pas l’interface de Tableau, elle s’en

sert uniquement pour l’implantation de la liste
Généralisation : Contraintes
Article
{disjoint}
Luxe Alimentaire
{overlapping, incomplete}
Unité Pack Pâtes Conserves
• Overlapping, disjoint, complete, incomplete
101
Autres
• Port : moyen de communication entre Deux classes
indépendamment de leurs technologies d’implantation, 2
classes si elles ont des ports compatibles pourront
communiquer même si elles sont implantées dans des
langages différents
Covariance
A nim al
B ipède Quadrupède
Herbivore Carnivore Herbivore Carnivore
Anim al
Covar ian c e
Carnivore Herbivore
Bipède Quadrupède Bipède Quadrupè de
Covariance
102
Délégation
• Elimination de la covariance
A nimal
S tation Nourriture
B ipède Quadrupède Herbivore Carnivore
De la difficulté de classer
• Dépendant du point de
vue
• Bien discriminer les objets
• Des exceptions
• Stables et extensibles
• Covariance
103
Principe de substitution (1)
• Classification ou non ?
« Il doit être possible de substituer n’importe
quel objet instance d’une sous-classe à
n’importe quel objet instance d’une super-
classe sans que la sémantique du programme
écrit dans les termes de la super-classe ne soit
affectée. » (Barbara Liskov)
Principe de substitution (2)
CP
:CP :CP
:CP :CP
:CP
:CE :CP
CE
104
Non respect du principe de substitution
Oiseau
P lumes
B ec V oler()
{
V oler() M ettre la tête dans le sable Le m oineau
} s'envole
Mésange Moineau A ut ruche

: Moineau
1: V oler La m ésange
s 'envole
2: V oler
: S auve teur : M ésan ge
3: V oler
L'autruche se
c ac he la tête
: Autruche
Implantation (1)
Class Classe {
Classe private:
Attributs Attributs
Public:
Méthodes Méthodes
}
SousClasse
Class SousClasse : public Classe {…}
Répertoire
105
Implantation (2)
C1 C2
class C2 {
Class C1 { private:
private: …
C2 LeC2 }
}
Implantation (3)
C1 C2
Class C1 { class C2 {
private: private:
C2 LeC2 C1 LeC1
} }
106
Implantation (4)
0,1
C1 C2
private: private:
C2 *LeC2 C1 LeC1
} }
Implantation (5)
*
C1 C2
private: private:
Collection<C2> LesC2 C1 LeC1
} }
ordered unique structure de données
false true Ensemble
true true Ensemble ordonné
false false Multi-ensemble (bag)
true false Séquence
107
Implantation
• La composition s’implante par une classe interne privée
en Java
Implantation (6)
C1 Collection<C2>
C2
UnType
Collection
108
Implantation (7)
<<persistant>> <<persistant>>
C1 C2
<<persistant>>
C3
Implantation (7)
Comme dans E/A :
• C1, C2, C3 Relations
•Associations suivants cardinalités
•Héritage : Reférentiation ou Propagation ou les deux
• Méthodes deviennent des procédures stockées ou des
traitements
 Plus aucun lien avec l’objet
109
Implantation (8)
SGBDR + Langage Objet
<<persistant>> C1
C1
ProxyC1
SGBDR
Diagramme d’objets
110
Introduction
• Le diagramme d’objets est utilisé pour :
– Illustrer une situation spécifique
– Illustrer un diagramme de classes
– Aider à la construction d’un diagramme de classe
– Explorer des structures de données complexes
• Correspond à une ‘vue instantanée’ de l’application
Objets
D1 : Disque D2
: Hanoi
No = 1
• Le nom est souligné

• Les méthodes n’apparaissent que dans le diagramme des
classes
111
Liens
A1 : Article
C1 : Commande
N° : 123
A1 : Article
• Il y a éventuellement d’autres articles, l’information sur la

commande et les articles est éventuellement incomplète
• Association (diagramme de classe) # Lien (diagramme
d’objets)
Liens
D1:Disque
• Un objet est toujours implicitement lié à lui même
112
liens n-aires
:Professeur :Elève
:Salle
Composition (UML 1.4)
:Voiture
:Roue :Roue
:Roue :Roue
113
Diagramme de structures
composites
Introduction
• Permet d’expliciter la structure d’une configuration
(classe, composant, collaboration,...) en explicitant les
rôles des composants de la structure
114
Structure d’une classe
V: Voiture
:Roue[5] V: Voiture
Une seule imbrication :Injection
:Moteur :Transmission
• Le port est un mécanisme d’encapsulation, il définit un

point d’interaction
• Il permet de spécifier les interfaces requises ou offertes
• Un port ‘signal’ spécifie les signaux relayés, un port
‘service’ spécifie des services offerts
Collaboration (UML 20)

Nom collaboration
• Une collaboration décrit comment des éléments (attributs,

objets, classes, U.C., ...), coopèrent pour réaliser un
comportement (U.C., une ou plusieurs opérations,...)
• La structure d’une collaboration est définie par un
diagramme de structures composites, le comportement
est défini par des diagrammes d’interactions
• L’occurrence d’une collaboration est définie par un
diagramme de classe ou une/plusieurs opérations d’une
classe
115
Collaboration et Design patterns
• Les Design pattern sont typiquement décrits par des
collaborations
– Un DP introduits des rôles (ensemble de caractéristiques) qui
doivent être joués par des objets
– La combinaison du nom de l’objet, du nom du rôle, du nom de la
classe et du soulignement définit une interprétation spécifique.
Exemples :
 ‘: UneClasse’ : Une instance anonyme d’une classe
 ‘: UneClasse’ : N’importe qu’elle instance d’une classe
 ‘Objet / Role : Classe’ : Un objet de la classe qui joue le rôle
 ‘/Role’ : Le rôle attendu
 ...
Collaboration et Design patterns

Collaboration
2..*
/Composant
Composite
*
/Feuille /Composite
Occurrence de collaboration
2..*
Composant Réservation
Composite
Composite
Feuille
*
ResIndividuelle ResGroupe
116
Diagrammes d’interaction :
diagrammes de séquences,
diagrammes de collaboration et
diagrammes de communication
Introduction
• Permettent de modéliser le comportement du système
• Examinent une petite partie du système isolée de son
contexte (scénario, opération,...)
• Servent à clarifier, analyser, expliquer un comportement
complexe
• Ne modélisent pas tous les comportements possibles du
système
• Permettent d’analyser le couplage
117
Diagramme de séquence
• Le diagramme de séquences et le diagramme de
collaboration sont très similaires : ils permettent tous les
deux de décrire des échanges de message entre objets
• Le diagramme de séquences met en avant la dimension
chronologique
• Permettent d’illustrer les scénarios définis pour les cas
d’utilisations, peut être vu comme un déroulement d’un
cas d’utilisation
Exemple
« acteur » « contrôleur » « entité » « entité » « acteur »
:Resp. Plan :SelectionnerPlage :Plan :Plage SGBD
Reserver(NoPlage,IdP) GetPlage(NoPlage)
return plage
Pers=GetPers (idP)
Reserver(Pers)
Temps
• Les objets ne sont pas nécessairement attachés à des classes
• Les messages échangés correspondent à tous stimulus (appel,
signal, exception,...)
• Permet d’explorer les responsabilités respectives
118
Diagrammes de séquences (SSD)
: Système
Ali Salah
Décroche
Emet ‘La’
*[nbr]Compose chiffre
Sonnerie
Décroche
Connexion Connexion
Diagrammes de séquences
Sélecteur
: Hanoi : Disque : Disque : Disque

... (suivant=null)
Résoudre()
Déplacer( ) Déplacer( )
...
Possession
du contrôle
119
Messages et Stimulus
• Forme générale: préd / No Itér Cond Resultat:=opération
• Un message est la spécification d’un stimulus, UML 2.0
ne distingue pas entre message et stimulus
• Un stimulus est défini par: les objets émetteurs et
récepteurs, un lien de communication (sauf pour
l’autoréférence). Il peut invoquer une opération sur l’objet
récepteur, créer ou détruire un objet,... Il est associé à la
procédure qui l’a généré
• Un signal est un message qui n’attend pas de résultat de
la part de l’opération invoquée, une exception est une
forme particulière de signal qui véhicule un objet lors de
sa propagation
Messages et Stimulus
• Message synchrone : l’appelant attend la fin du traitement
par le récepteur, il y a un retour (parfois implicite) associé
Message : Retour :
• Message asynchrone : l’appelant n’est pas bloqué par
l’envoi du message, ne peut pas avoir de retour
Message : (ou UML 1.3 )
120
Résultats
X Y X Y
Résultat=Msg(Données) Msg(Données)
ou
Résultat
• Données prend la forme de paramètres effectifs habituels ou (UML

2.0) de paramètres effectifs nommés :
par1 = val1, par2 = val3, par3 = -
Messages
X Y
Résoudre()
Délai
*[cd] Msg
t1 Itération
{t2-t1 <2s} [cd1] Msg
t2 Conditionnelle : il est préférable
Un message peut être désigné [cd2] Msg de traiter un chemin à la fois
par son N° ou par un nom
symbolique, on peut référencer
les attributs date émission,
date réception
121
Création / Destruction
Ou (UML 2.0) X Y
X
Créer
Y
Détruire
Autoréférence
X
X
Msg
Message Msg
retour
Récursivité
Auto référence :
l’opération invoquée est
en général privée
122
Contraintes (UML 2.0)
« acteur » « contrôleur » « entité »

:Resp. Plan :SelectionnerPlage :Plage
Actif
Reserver(NoPlage,IdP) Reserver(Pers)
{Plage::Réservée}
• L’objet ne traitera le message que si la propriété est valide (ici l’objet

est dans l’état actif) ou la propriété devient vraie une fois que le
message est traité (la plage devient réservée)
• Un contrainte peut aussi être exprimée sous forme de propriété
Suspension (UML 2.0)
« contrôleur » « entité »
:SelectionnerPlage :Plage
Annuler
return OK
• Le contrôleur est suspendu jusqu’à la fin de l’annulation

(équivalent à message synchrone ?)
123
Diagramme de collaboration (UML 1.4)
• Met en avant la structure (associations) du diagramme
des classes
• permet de valider la structure, d’identifier de nouvelles
associations ou de déterminer les responsabilités
• La chronologie est déduite de la numérotation
1: Résoudre()
1.1: Déplacer(1,3 )
1.1.1: Déplacer( 1,2)
: Hanoi : Disque : Disque : Disque
...
1.1.2: Déplacer( 2,3)
124
*[tous]Touver(NoImmatricultion)
:sociéte :Employé
return Emp
:Emp
Diagramme de communication
1:M(A)
O A
« Local »
Les liens qui apparaissent dans le diagramme sont soit

des instances d’associations soit des liens de visibilité
spécifiques au contexte
125
:Société :Employé
1:*[Age>40] Augmenter
Objet Actif Objet Actif
X A.1, B.1 /M3 Y
A:M1 U B:M2
Z T
A.1:… B.1:…
126
Cadre (UML 2.0)
sd Entête
Corps
• Permet l’imbrication, la réutilisation d’une intéraction, peut

aussi être utilisé pour un diagramme de class (cd),
l’entête peut préciser des paramètres
Diagramme de machines à
états
127
Diagramme de machines à états
• Inspirés des statecharts de D. Harel et incluent des
concepts issus des machines de moore et de mealy
• Modélisation des aspects contrôle et temps du système
• Se rapprochent du MCT de MERISE
• Secondaires pour les SI primordiaux pour les STR
• Un (ou plusieurs) diagrammes E/T décrivent le
comportement d’une classe, mais ils peuvent aussi
décrire le comportement d’un U.C, d’un acteur, d’un
sous-système ou d’une méthode
• Un objet fournit un contexte pour l’exécution de la
machine définissant sa classe

• Certains systèmes (ou parties de systèmes) sont
purement fonctionnels (sans mémoire : fonction sinus)
d’autres ont un mode de fonctionnement continu (sans
états: filtre digital)
• Les machines à états sont utiles pour décrire des
objets/classes exhibant un comportement complexe,
réactif et ayant plusieurs interactions avec
l’environnement.
128
E1
entry/ Action 1
exit/ Action 2
on Ev( Info )[ Cd ]/ Action 3
do/ Activité
Evnmt( info )[ Garde ] / Action,Objet.Événement
E2
État
Nom état
Nom état Nom état
• Abstraction d’un ensemble de valeurs. Exemples:

– Four : Marche, Arrêt, Chaud, froid, Pile : vide, pleine
– Personne : Active, Au chômage
• Caractérisation d’un comportement. Exemples:
– Pile : Attente, Empilement
– Four : Chauffage
• Durable et stable, le système est observable, il effectue
une activité
• Mémorise un historique. Exemple: Marche
129
États
• Simple : caractérisé par un invariant (condition sur les
attributs ou caractérisation d’un comportement qui est
vraie pendant tout le temps que la machine passe dans
cet état)
• Composite : État constitué de plusieurs machines
appartenant à plusieurs régions
• État sous machine : l’état spécifie un point d’entrée et un
point de sortie d’une sous machine réutilisable
États
Etat initial Etat final
• Pseudo-états
• Un seul état initial par niveau hiérarchique
• 0, 1 ou Plusieurs états finaux par niveaux hiérarchique
• Lorsque un objet est dans un état final il ne réagit plus à
aucun événement
130
Transitions
Marche
OuverturePorte()/LumiereOn ()
• Relie 2 états (non nécessairement distinct) et matérialise

un changement d’état possible du système
• Le changement d’état est instantané
• Une transition non étiquetée (transition automatique) est
déclenchée automatiquement à la fin du traitement de son
état source
• Transition interne : Traitement pouvant entraîner une
réponse de la machine mais pas un changement d’état,
traité éventuellement au niveau d’une sous machine
Transitions composites (UML 1.4)

• Regroupent des gardes alternatives pour un événement
Lecture Carrefour
Envoi Changement(Feu)
[NbrElem = 1] [Feu = Rouge] [Feu = Vert]

[NbrElem > 1]
Copier Trier Arrêter Traverser
Jonction statique Jonction dynamique
131
Triggers (Événements UML 1.4)
Empilement(val:ent)
Vide Occupée
• Un événement est associé à une transition, son émetteur

n’est pas spécifié, le traitement de l’événement est lié à
l’état courant
• Occurrence d’une situation dans le domaine du problème
• Instantané et porteur d’informations :
NomTrigger(par1: type1,…parn: typen)
• Peut correspondre à un message du diagramme de
séquences
Types de triggers
Allumage() après(3s)
Arrêt Marche Demande Serv. occupé
• Appel : appel d’opération(message du D.S.). Stéréotypes:

<<Crée>> et <<Détruit>>. La création provoque la
transition initiale
• La détection d’une situation particulière dans
l’environnement
– Une certaine condition devient vraie : Persiste lorsque
l’expression redevient fausse. Syntaxe : quand (Expression
booléenne)
– Temporel : écoulement d’un instant temporel relatif ou absolu.
Syntaxe : après (x secondes) : x secondes après l’accès à l’état
courant. après (x secondes à partir de y). quand (date= un
instant)
132
Types de triggers
• Trigger <<signal>>: provoque une réaction asynchrone
sans réponse
– Peut correspondre à une classe, l’information portée fait alors
partie de l’état. Les exceptions sont des signaux
– Les événements <<signal>> peuvent être organisés en
hiérarchies de classe  transitions polymorphes
<<signal>>
Entrée Util.
<<signal>> <<signal>>
Click souris Entrée Clavier
Où : point Caractère
Garde
• Expression booléenne qui conditionne le
déclenchement d’une transition. La transition est
franchie lorsque son événement se produit et que
sa garde est vraie
• Lève l’indéterminisme
• [Expression1] par rapport à quand(Expression2)
– Expression1 est évaluée à chaque fois que
l’événement se produit, Un événement est déclenché à
chaque fois que expression2 devient vraie
– Lorsque Expression1 est fausse l’événement est perdu
133
Actions
traitement atomique instantané (ininterruptible – run-to-
completion semantic) pouvant manipuler l’état, étiquetant
une transition (Génération de signaux, création
d’objet,appel de méthodes, manipulation de propriétés ou
de liens,…) ,
HausseT°(t)/EteindreBruleur() Evnt(info) / A
Chaud Surchauffe

…/A1 …/A1 E
…/A1
…/A2
E  Entry/ A1
…/A2 …/A2 Exit/ A2
Evnmt(info) / A
Actions
• Action Deffered
– Permet de différer le traitement d’un événement
Etat1 e1 e2 Etat3
e2 /deffered Etat2
e3
•Lorsque la séquence e2,e1 se produit le système se
retrouve dans l’état 3 (en passant par l’état 2)
•Lorsque la séquence e2,e3 se produit e2 est perdu
134
Activités
• Traitement associé à un état et ayant une durée
• Lorsque le traitement n’est pas terminé et qu’un
événement validant une transition se produit, il est
interrompu
• Lorsque le traitement se termine sans occurrence
d’événements, le système reste en attente dans l’état.
• Lorsque la transition n’est pas étiqueté le système quitte
l’état à la fin du traitement
• Ne peuvent pas changer l’état de l’objet concerné par la
machine
Do Activité
Liens avec le diagramme de séquences

X
Msg1
Etat
Msg2
Événement
• Diagramme de séquence peut se voir comme un chemin

dans un diagramme état/transition
135
Liens avec le diagramme de séquences
: Système
Ali
Attente
Décroche Décroche
Emet ‘La’ Tonalité
Compose
*[nbr]Compose chiffre Composition
Compose
Recherche
Connexion
Communication
Exemple
Affecter(Periode) [Periode  Contraintes] Affecter[Période Contraintes]
Contrainte Affectation
Désaffecter(Periode) [Période  Contraintes] Désaffecter
136
États composites
• Un état peut se décomposer en sous états disjoints (ou) à
leurs tours décomposables
• À tout moment le système est dans un seul état
Etat composite
E1
E1 E2
E2
 E5
E5
E3
E4 E3
E4
Etat souche
• permet d’abstraire un sous-état source ou destination
• Les actions d’entrée sont exécutées séquentiellement du
niveau hiérarchique le plus élevé au plus faible et
inversement pour les actions de sortie
• Les transitions automatiques sont franchies lorsque le
sous diagrammes atteint un état final
SM1
SM2
137
Example
Régalage Minutes
Réglage H Clignot. M Appui B2
B1 Attente
DO Clignoter
Minutes Relache B2/Min=Min+1
B1 Relâche B2
Affichage B1 Défilement
DO Inc. Min Délai
DO Affiche Tous les 0.1 s
Heure/Min/Sec
Concurrence
• décomposition conjonctive (et), les sous-états sont groupés en régions
• Le système est dans plusieurs sous-état simultanément
• une garde peut prendre la forme [in state X] (synchronisation)
• L’entrée dans un état conjonctif correspond à l’entrée vers tous les états
initiaux, la sortie fait sortir de toutes les régions
• Les transitions automatiques sont franchies lorsque les sous diagrammes
des différentes régions ont atteint un état final
A B C
U V W
138
Forme conjonctive et forme disjonctive
• Une décomposition conjonctive peut être transformée en
décomposition disjonctive
e1
Z,A Z,B
X e1 e4
A
e3 e3
e3 Y e1 e4[in state Z]
e2 B X,A X,B
Z e1
e1
Y,B e2
Diagrammes Etats / Transitions

• Transitions entre états concurrents
139
Diagrammes Etats / Transitions
• Etat historique : permet de mémoriser le dernier sous état visité.
L’entrée dans un état ne se fait pas au niveau de l’état initial mais du
dernier état visité lors d’une entrée précédente.
• La transition de H vers un
état permet de préciser l’état
d’entrée si H n’est pas
initialisé (première visite)
•H* : mémorisation pour tous
H les sous niveaux
Porte ouverte
Lavage Rinçage Séchage Attente
H Porte fermée
140

Uml PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml PDF

Transféré par

Droits d'auteur :

Formats disponibles

Méthodologies de conception

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 1

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 2

• 1950 : Langages de haut niveau; Profession

• 1960 : ‘Grands systèmes’ : OS de l’IBM 360, constatation

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 3

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 4

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 5

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 6

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 7

Les processus logiciels

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 8

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 9

Code and Fix

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 10

Analyse des besoins

Codage et Test unitaire

Intégration et Test système

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 11

• Analyse des besoins et spécifications : Définir les

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 12

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 13

– Maintenance adaptative : adapter le système aux évolutions de

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 14

An. B &Sp C. Arch. C &TU F1

Conc. H. Niv. F2 C. Dét. F2 C &TU F2

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 15

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 16

Non Client Evaluation

Développement à grande échelle

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 17

Modèle par prototypage

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 18

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 19

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 20

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 21

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 22

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 23

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 24

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 25

Phases du cycle de vie

Inception Elaboration Construction Transition

• Inception (Initialisation/Pré-étude): Définir le contexte du

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 26

Conception Modèle Modèle

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 27

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 28

Itér. ... Itér. ... Itér. Itér. ... Itér. ...

Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable Délivrable

•Une itération est une séquence d’activités basées sur un plan, un

Itér. ite r.1 iter. 2 ite r. n ite r. ite r. it e r. ite r.

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 30

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 31

• Gestion des configurations et de évolutions

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 32

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 33

U.C. Contrôlent le déroulement

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 34

• RUP n’est pas prototypage ou RAD car:

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 35

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 37

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 38

Adel KHALFALLAH - Génie logiciel - Méthodologies de conception - Institut Supérieur d’Informatique - 39