Modélisation de Systèmes
Informatiques par UML
Mastère spécialisée : NTICE
Slim KANOUN
Maître Assistant à l’ENIS
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
Il une grande différence entre :
– un développeur passionné qui réalise son
logiciel dans son coin
– le développement industriel d’une application
de grande taille qui peut rassembler quelques
centaines de développeurs sur plusieurs
années.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
Cas d’un développeur isolé
- La méthodologie est affaire d’habitudes
personnelles et se constitue au fil de
l’expérience.
- A chacun de trouver ses propres recettes pour
développer vite et bien.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
Cas d’un développeur isolé
- Le développeur isolé se constitue son
propre style de programmation, son
répertoire d’astuces pour résoudre des
problèmes de codage et limiter au
maximum la fastidieuse chasse aux bugs.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
Dans l’industrie : équipes de
développeurs
- soucis d’efficacité, de réutilisation de
solutions connues, ou de programmation
sans erreur sont bien sûr pris en charge
- partage du travail.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
Dans l’industrie : équipes de développeurs
- les projets informatiques sont devenus de
plus en plus complexes et de grandes tailles
- Les équipes de conception deviennent donc
de plus en plus importantes, entraînant un
besoin croissant de communication entre
les divers spécialistes.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
- le besoin exprimé par le client – souvent
incompétent dans le domaine de la conception
informatique – est généralement flou et
incomplet.
- le concepteur est étranger au monde du
client.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
- la non disponibilité d’un langage
commun entre ces deux mondes pour
instaurer un dialogue et identifier les
clauses contractuelles de manière
satisfaisante pour les deux parties.
- malgré tous les efforts déployés –
l’évolution du cahier des charges au
cours du développement est quasiment
inévitable.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
- le développement est effectué à plusieurs,
- les différentes parties d’un logiciel sont
toujours plus ou moins interdépendantes,
- à tout moment du cycle de vie d’un projet,
de la spécification à la validation finale, les
développeurs et concepteurs doivent pouvoir
se mettre d’accord sur les fonctionnalités en
interaction.
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
– limiter
l’évolution du cahier des charges
- réduire le risque de malentendu entre
clients et concepteurs ainsi qu’entre
équipes de concepteurs en s’appuyant sur
un langage de modélisation standard et
non ambigu ;
- répondre le plus rapidement possible à une
modification du cahier des charges en
réduisant le temps du cycle de conception
des spécifications à la réalisation ;
La méthodologie : pourquoi faire ?
• Problèmes et contraintes du génie logiciel
- automatiser le passage de la spécification
à l’implémentation et la validation (AGL);
- limiter au maximum les répercussions
d’une modification dans une phase du
développement sur les autres phases.
Processus de développement de
logiciel
• Expression des besoins : Etude
d’opportunité et de faisabilité
• Spécification : informelle, formelle
• Analyse et conception : choix d’une
méthode :
– Fonctionnelle
– Systémique
– Orientée objet
Processus de développement de
logiciel
- Fonctionnelle (SADT, Castellani, …) : modéliser
que les traitements dépendance forte Données /
Traitements (C, Pascal, …) et SGF
- Systémique (MERISE, …) : modéliser les données
et les traitements indépendance Données /
Traitements (SQL, PL/SQL, PRO*C) et SGBDR
- Orientée objet (OMT,…) : modéliser des objets
encapsulation Données / Traitements (C++, Java,
…) et SGF, JDBC et SGBDR, SGBDOO
Processus de développement de
logiciel
• Implémentation : choix d’un environnement
de développement
• Test de vérification et validation
• Maintenance et évolution
• Documentation et archivage
Processus de développement de
logiciel
Une méthode d’analyse et de conception
=
une démarche en plusieurs étapes
+
un formalisme de représentation ou
un langage de modélisation ou
un ensemble de notification
Processus de développement de
logiciel
MERISE
=
Etude préalable, Analyse détaillée, analyse
technique, réalisation et maintenance
+
Un langage pour élaborer les modèles :
MCT, MCD, MOT, MLD, MOpT, MPD
Processus de développement de logiciel
• OMT de James RUMBAUGH :
Langage de modélisation 1 + Démarche 1
• BOOCH de Grady BOOCH :
Langage de modélisation 2 + Démarche 2
• OOSE de Ivar JACOBSON :
Langage de modélisation 3 + Démarche 3
• Autres méthodes :
Autres langages de modélisation + Autres démarche
Processus de développement de logiciel
Prolifération des langages de modélisation
Les concepts de l’approche objet sont
représentés différemment dans les modèles
proposés par les différentes méthodes
Processus de développement de logiciel
Apparition de problèmes comme :
- l’échange de modèles entre équipes de
concepteurs et entre autres les clients
- la fusion de modèles pour une même
application développée par différentes équipes
de concepteurs utilisant des méthodes
différentes
Solution : Unified Modeling Language
(UML)
Conclusion sur la méthodologie
Issus de l’expérience des développeurs,
concepteurs et chefs de projets, la
méthodologie est en constante évolution,
parallèlement à l’évolution des techniques
informatiques et du savoir-faire des équipes.
Les méthodologies ont parfois souffert d’une
formalisation excessive, imposant aux
développeurs des contraintes parfois contre-
productives sur leur façon de travailler.
Conclusion sur la méthodologie
Avec la mise en commun de l’expérience et
la maturation des savoir-faire, on voit se
développer à présent des méthodologies plus
proches de la pratique réelle des experts, et
moins contraignantes.
Conclusion sur la méthodologie
UML, qui se veut un instrument de
capitalisation des savoir-faire puisqu’il
propose un langage qui soit commun à tous
les experts du logiciel, va dans le sens de cet
assouplissement des contraintes
méthodologiques.
Unified : historique des méthodes de
conception
Depuis les années 80, de nombreuses
méthodes d’analyse et de conception de
logiciel ont été développées, chacune plus ou
moins :
- spécialisée
- adaptée à une démarche particulière, voire
à un secteur industriel particulier (bases de
données, matériel embarqué, ...)
Unified : historique des méthodes de
conception
Ces méthodes ayant été développées
indépendamment les unes des autres, elles
sont souvent :
- partiellement redondantes
- incompatibles entre elles (notations ou
terminologies différentes, voire faux-
amis...).
Unified : historique des méthodes de
conception
Dans les années 90, un certain nombre de
méthodes orientées objets ont émergé, en
particulier les méthodes :
– OMT de James RUMBAUGH [Rum96],
– BOOCH de Grady BOOCH [Boo94],
– OOSE (Object Oriented Software
Engineering) de Ivar JACOBSON à qui l’on
doit les Use cases (cas d’utilisations)
Unified : historique des méthodes de
conception
En 1994, on recensait plus de 50
méthodologies orientées objets : dans le but
de remédier à cette dispersion que les « poids-
lourds » de la méthodologie orientée objets ont
entrepris de se rassembler.
Unified : historique des méthodes de
conception
En octobre 1994, Grady Booch et James
Rumbaugh se sont réunis au sein de la société
RATIONAL dans le but de travailler à
l’élaboration d’une méthode commune qui
intègre les avantages de l’ensemble des
méthodes reconnues, en corrigeant les
défauts et en comblant les déficits.
Unified : historique des méthodes de
conception
OOPSLA’95 (Object Oriented Programming
Systems, Languages and Applications) la
grande conférence de la programmation
orientée objets), ils présentent UNIFIED
METHOD V0.8.
En 1996, Ivar Jacobson les rejoint.
Les travaux ne visent plus à constituer une
méthodologie, mais un langage
Unified : historique des méthodes de
conception
Leur initiative a été soutenue par de
nombreuses sociétés :
- des sociétés de développement (dont
Microsoft, Oracle, Hewlet-Packard, IBM – qui
a apporté son langage de contraintes OCL
–, ...)
- des sociétés de conception d’ateliers
logiciels.
Unified : historique des méthodes de
conception
Un projet a été déposé en janvier 1997 à
l’OMG (Object Management Group, qui s’est
rendu célèbre pour la norme CORBA) en vue
de la normalisation d’un langage de
modélisation.
Après amendement, celui-ci a été accepté en
novembre 97 par l’OMG sous la référence
UML-1.1.
Début 2000, UML 1.3 est disponible.
Modeling : analyse et conception
L’analyse :
- répond à la question « que faut-il faire ? »,
- a pour but de se doter une vision claire et
rigoureuse du problème posé et du système à
réaliser en déterminant ses éléments et leurs
interactions.
- son résultat est un modèle représentant le
problème et les principaux éléments du
système à réaliser.
Modeling : analyse et conception
Il est important d’insister sur les caractéristiques
suivantes de l’analyse :
– elle nécessite de comprendre en détail les
problèmes et concepts de l’utilisateur,
– elle doit être (en principe) indépendante des
aspects techniques,
– les choix portant sur les modèles résultants
doivent être justifiés (simplification du modèle,
explicitation des hypothèses, etc.),
Modeling : analyse et conception
Les éléments du système complet peuvent alors être
décrits selon trois points de vue plus ou moins
dépendants les uns des autres :
– la vue fonctionnelle, qui indique ce que doivent
faire les objets du programme,
– la vue structurelle (ou statique), qui fait apparaître
la composition hiérarchique des objets et leur
agencement
–
Modeling : analyse et conception
– la vue dynamique, qui prend en compte le
déroulement de l’application sous forme
d’événements, d’émission de messages, et
d’évolution des états.
Modeling : analyse et conception
La conception, menée à la suite de l’analyse :
- répond à la question « comment faire ce qu’il faut
faire » ?
- Le processus de conception a pour but de figer les
choix techniques (un ou plusieurs langages de
programmation, bibliothèques, etc.).
- fixe les performances
- définit la stratégie de programmation :
choix des structures de données (et de leur
persistance),
choix des algorithmes à utiliser.
Modeling : analyse et conception
Le résultat de la conception est une ébauche
d’implémentation, décrite par un modèle précis du
système à réaliser.
Modeling : analyse et conception
Modélisation :
Il faut donc s’efforcer de ne pas fixer les choix de
conception pendant l’analyse.
En pratique, cependant, il apparaît que l’analyse est
toujours orientée par des contraintes de faisabilité
qui relèvent de la conception.
En raison de cette perméabilité entre les deux
phases, le choix du terme de « modélisation »
(modeling) montre que les auteurs n’ont pas
voulu se restreindre à la prise en charge d’une
seule phase du cycle de développement.
Language : méthodologie ou langage
de modélisation
Il s’agit de bien faire la distinction entre une
méthode qui est une démarche d’analyse et
de conception en vue de résoudre un
problème informatique, et le formalisme dont
elle peut user pour exprimer le résultat
Language : méthodologie ou langage
de modélisation
Les grandes entreprises :
- ont souvent leurs propres méthodes de
conception ou de réalisation de projets
informatiques.
- sont liées à des raisons historiques,
d’organisation administrative interne ou encore
à d’autres contraintes d’environnement et il n’est
pas facile d’en changer.
Il n’était donc pas réaliste de tenter de
standardiser une méthodologie d’analyse et de
conception au niveau mondial.
Language : méthodologie ou langage
de modélisation
UML n’est pas une méthode, mais un
langage.
Il peut donc être utilisé sans remettre en
cause les procédés habituels d’analyse et de
conception de l’entreprise et, en particulier,
les méthodes plus anciennes telles que celle
proposée par OMT sont tout à fait
utilisables.
Language : méthodologie ou langage
de modélisation
D’ailleurs, la société RATIONAL (principale
actrice de UML) propose son propre
processus de conception appelé
OBJECTORY et entièrement basé sur UML.
Language : méthodologie ou langage
de modélisation
UML facilite la communication entre
clients et concepteurs, ainsi qu’entre
équipes de concepteurs.
Sa sémantique étant formellement définie
(sous forme de diagramme UML) : cela
accélère le développement des outils
graphiques d’atelier de génie logiciel
permettant ainsi d’aller de la spécification
(haut niveau) en UML vers la génération de
code (JAVA, C++, ADA, ...).
Language : méthodologie ou langage
de modélisation
UML ne se contente pas d’homogénéiser des
formalismes existants, mais apporte
également un certain nombre de nouveautés
telles que :
- la modélisation d’architectures
distribuées
- la modélisation d’applications temps-réel
avec gestion du multi-tâches,
- la modélisation de systèmes multi-agents,
- la modélisation d’application web
Différentes vues et diagrammes
d’UML
Vue fonctionnelle :
- interactive,
- représentée à l’aide de diagrammes de cas
d’utilisation et de diagrammes des
séquences,
- cherche à appréhender les interactions entre
les différents acteurs/utilisateurs et le
système, sous forme d’objectif à atteindre
d’un côté et sous forme chronologique de
scénarios typiques d’interaction de l’autre.
Différentes vues et diagrammes
d’UML
Vue structurelle, ou statique représentée à
l’aide de :
diagrammes de classes : favorisent la
structuration des données et tentent
d’identifier les objets constituant le système,
leurs attributs et opérations ainsi que les
liens ou associations qui les unissent.
Différentes vues et diagrammes
d’UML
Vue structurelle, ou statique représentée à
l’aide de :
diagrammes de packages : s’attachent à
regrouper les classes fortement liées entre
elles en des composants les plus autonomes
possibles.
A l’intérieur de chaque package, on trouve
un diagramme de classes.
Différentes vues et diagrammes d’UML
Vue dynamique :
- est exprimée par les diagrammes
d’états et le diagramme d’activités
- vise à décrire l’évolution (la
dynamique) des objets complexes du
système tout au long de leur cycle de vie.
De leur naissance à leur mort, les
objets voient leurs changement d’états
guidés par les interactions avec les autres
objets.
Différentes vues et diagrammes
d’UML
Vue fonctionnelle et statique exprimée par
les diagrammes de collaboration :
- proches des scénarios ou diagrammes
de séquences
- insistent moins sur le séquencement
chronologique des événements en se
focalisant plutôt sur les relations qui
existent entre les objets
Différentes vues et diagrammes
d’UML
En numérotant les messages pour conserver
l’ordre, ils insistent sur :
- les liens entre objets émetteurs et
récepteurs de messages,
- sur des informations supplémentaires
comme des conditions d’envoi ou des
comportements en boucle, ce que ne
permettent pas les diagrammes de séquences,
trop linéaires.
Les cas d’utilisation
Le diagramme des cas est un apport d’Ivar
Jacobson à UML.
Son rôle essentiel est d’inciter les analystes et
concepteurs à conceptualiser le problème du
point de vue du client dès la phase initiale du
projet.
Les cas d’utilisation doivent être considérés
comme des fonctionnalités requises par les
utilisateurs du système à développer.
Les cas d’utilisation
Commencer par établir le diagramme des cas
permet de mener un développement orienté
utilisateur et de découper le système global en
grandes tâches qui pourront être réparties entre
les équipes de développement.
Une fois obtenu, le diagramme des cas
d’utilisation est un support privilégié de
communication entre les équipes, ainsi qu’avec
les clients.
Les cas d’utilisation
Un cas d’utilisation (use case) modélise une
interaction entre le système informatique à
développer et un utilisateur ou acteur
interagissant avec le système.
Un cas d’utilisation décrit un ensemble
d’actions réalisées par le système qui produit
un résultat observable pour un acteur.
Les cas d’utilisation
Les cas d’utilisation engagent le système
envers le respect d’un cahier des charges
décliné pour chaque classe d’utilisateurs.
Il y a en général deux types de description des
use cases :
– une description textuelle de chaque cas ;
– le diagramme des cas, constituant une
synthèse de l’ensemble des cas ;
Les cas d’utilisation
Les cas d’utilisation
Il n’existe pas de norme établie pour la description
textuelle des cas.
On y trouve généralement pour chaque cas :
- son nom,
- un bref résumé de son déroulement,
- le contexte dans lequel il s’applique,
- les acteurs qu’il met en jeu,
- une description détaillée, faisant apparaître le
déroulement nominal de toutes les interactions, les cas
nécessitant des traitements d’exceptions, les effets du
déroulement sur l’ensemble du système, etc.
Les cas d’utilisation
Toute la difficulté consiste à s’arrêter au bon
niveau de détail pour ne pas trop empiéter sur le
travail associé aux autres vues.
Chaque cas d’utilisation spécifie un comportement
attendu du système considéré comme un tout, sans
imposer le mode de réalisation de ce
comportement. Il permet de décrire ce que le futur
système devra faire, sans spécifier comment il le
fera
Les cas d’utilisation
Comment les identifier ?
L’ensemble des cas d’utilisation doit décrire
exhaustivement les exigences fonctionnelles du
système.
Chaque cas d’utilisation correspond donc à une
fonction métier du système, selon le point de vue
d’un de ses acteurs
Les cas d’utilisation
Pour chaque acteur il convient de :
- rechercher les différents intentions métiers avec
lesquelles il utilise le système
- déterminer dans le cahier des charges les services
fonctionnels attendus du système
Les cas d’utilisation
La description textuelle est particulièrement utile
dans le cas où une société de service en informatique
non spécialiste du domaine d’application (ou toute
équipe remplissant ce rôle) est chargée
d’informatiser un processus réalisé par des humains.
Le premier travail de conceptualisation consiste à
interviewer les différents acteurs pour
comprendre les processus, si bien que la
description textuelle se trouve adaptée au recueil et à
la mise en forme des résultats de ces interviews.
Les cas d’utilisation
La description textuelle est l’un des
documents les plus adaptés à la discussion
avec le client au moment où l’on s’assure
que l’on a correctement capturé l’ensemble
des exigences fonctionnelles du système à
réaliser.
Les cas d’utilisation
Il permet de s’assurer d’un seul coup d’œil que
l’ensemble des exigences fonctionnelles du
système ont bien été prises en compte.
Pour le dessiner, on s’attache dans un premier
temps à identifier les principales familles d’acteurs,
en fonction de leur rôle vis-à-vis du système.
Les cas d’utilisation
Un acteur représente un rôle joué par une entité
externe (utilisateur humain, dispositif matériel,
ou autre système) qui interagit directement avec le
système étudié
Un acteur peut consulter et / ou modifier
directement l’état du système, en émettant et / ou
en recevant des messages susceptibles d’être
porteurs de données
Les cas d’utilisation
Un acteur :
- Humains : les utilisateurs du logiciel à
travers son interface graphique par exemple
- Logiciels : déjà disponibles qui
communiquent avec le système grâce à une
interface logiciel
- Matériels : robots et automates qui
exploitent les données du système ou qui sont
pilotés par le système
Les cas d’utilisation
Pourquoi des acteurs ?
- délimiter le système.
- avoir une vue orientée utilisateur du système.
Avant de se lancer dans l’analyse et la conception
interne du système, il est bon d’en avoir une vue
externe qui correspond à toutes les fonctionnalités
attendues par les différents acteurs
Les cas d’utilisation
Il est parfois intéressant d’utiliser des liens
entre cas (sans acteur), UML en fournit de
trois types :
la relation utilise (uses) ensuite (include)
la relation étend (extends)
la relation de généralisation
Les cas d’utilisation
La relation utilise (uses) est employée quand
deux cas d’utilisation ont en commun une
même fonctionnalité et que l’on souhaite
factoriser celle-ci en créant un sous-cas, ou
cas intermédiaire, afin de marquer les
différences d’utilisation.
Il faut noter que dans la version 1.3, la
relation « uses » a été remplacée par
« include »
Les cas d’utilisation
Nous dirons qu’il y a extension d’un cas
d’utilisation quand un cas est globalement
similaire à un autre, tout en effectuant un peu
plus de travail (voire un travail plus spécifique).
Cette notion permet d’identifier des cas
particuliers (comme des procédures à suivre en
cas d’incident) dès le début ou lorsque l’attitude
face à un utilisateur spécifique du système doit
être spécialisée ou adaptée.
Les cas d’utilisation
Pour faire la distinction entre des liens de type
extends ou de type uses, il suffit de considérer
qu’un cas utilisé résulte d’une décomposition
effectuée par le concepteur à des fins de
factorisation.
Il en va différemment du cas étendu qui ajoute des
fonctionnalités à un cas existant mais englobe ce
cas. En général, le cas normal est utilisé par une
famille d’acteurs, le cas qui l’étend est destiné à
une autre famille d’acteurs.
Les cas d’utilisation
Il faudra définir pour chaque cas d’utilisation :
- une description textuelle de toutes les interactions
avec les acteurs du système
- un début et une fin clairement identifiés
- les variantes possibles :
- cas nominaux
- cas alternatifs
- cas d’erreurs
Définitions
Un objet est un concept, une abstraction, ou une
chose qui a un sens dans le contexte du système à
modéliser.
Chaque objet a une identité et peut être distingué
des autres sans considérer a priori les valeurs de ses
propriétés
exemple d’objets physiques : une chaise, une
voiture, une personne, un vélo…
exemple d’objets de gestion : commande n°3, le
client durant…
Définitions
L’état d’un objet est définie, à la fois par les valeurs
de ses variables d’instance et par les valeurs de ses
liens avec d’autres objets. L’état d’un objet
représente une durée, un intervalle de temps
quantifiable à l’échelle du système, un espace de
temps séparé par deux événements
Un événement est un stimulus pouvant transporter
des informations (sous la forme de paramètres), il se
produit à un instant donné : un événement n’a pas
de durée contrairement à un état
Définitions
Un événement peut être émis par un objet du
système ou par un objet externe au système : cela
correspond à l’appel d’une méthode.
Un message est un événement particulier, issu de
l’interaction entre deux objets : un objet appelle
une méthode d’un autre objet
Règles
Tout message est un événement impliqué dans
l’interaction entre deux objets
Tout événement n’est pas un message, car il
n’est pas forcément émis par un objet
La réponse d’un objet à un événement dépend
de l’état dans lequel se trouve l’objet qui le
reçoit
Les diagrammes de séquences
Les diagrammes de séquences ont pour objet
de décrire des scénarios particuliers de
comportement des acteurs vis-à-vis du
système.
On y cherche à mettre en valeur les passages
de messages (déclenchant des événements)
entre acteurs et objets (ou entre objets et
objets) de manière chronologique, l’évolution
du temps se lisant de haut en bas.
Les diagrammes de séquences
Un scénario est une série d’événements
ordonnés dans le temps, simulant un
fonctionnement particulier du système
Un cas d’utilisation peut donner lieu à un
ensemble de scénarios. Les scénarios
représentent des instances de cas d’utilisation
Les diagrammes de séquences
Les objets intervenant dans les scénarios sont des
instances et il est donc nécessaire de spécifier leur
nom et leur classe ; il sont représentés par des barres
verticales. Les interactions entre ces objets sont des
événements précis et spécifiques. Un événement est
représenté par une flèche horizontale reliant l’objet
émetteur à l’objet récepteur
Un diagramme de séquences est un moyen semi-
formel de capturer le comportement de tous les
objets et acteurs impliqués dans un cas d’utilisation.
Le diagramme des classes
Cas d’utilisation : vue fonctionnelle du système
La principale difficulté du diagramme de classes est de
passer de cette vue fonctionnelle vers une vue objet
du problème
La vue fonctionnelle, bien que plus naturelle, ne
permet pas de dégager les entités intrinsèques liées au
domaine d’application mais exprime simplement un
besoin à un moment précis : elle ne permet pas la
construction d’un logiciel qui résiste aux changements
de besoins
Le diagramme des classes
Une vue objet a donc pour but de déterminer les
objets utiles pour la vue dynamique ainsi que
pour les phases de conception et
d’implémentation
Le diagramme des classes
Une classe décrit un groupe d’objets ayant les mêmes
propriétés (attributs), un même comportement
(opérations), et une sémantique commune (domaine
de définition)
Un objet est une instance d’une classe. La classe
représente l’abstraction de ses objets.
Le diagramme des classes
Un attribut est une propriété élémentaire d’une
classe. Pour chaque objet d’une classe, l’attribut
prend une valeur
Une opération est une fonction applicable aux objets
d’une classe. Une opération permet de décrire le
comportement d’un objet.
Une méthode est l’implémentation d’une opération
Le diagramme des classes
La visibilité (ou degré de protection) indique qui
peut avoir accès à l’attribut (ou aux opérations dans le
cas des opérations).
Elle est symbolisée par un opérateur :
« + » pour une opération publique, c’est-à-dire
accessible à toutes les classes (a priori associée à la
classe propriétaire) ;
« # » pour les opérations protégées, autrement dit
accessibles uniquement par les sous-classes de la
classe propriétaire ;
« - » pour les opérations privées, inaccessibles à tout
objet hors de la classe.
Le diagramme des classes
Un lien est une connexion physique ou
conceptuelle entre instances de classes donc entre
objets
Une association décrit un groupe de liens ayant
une même structure et une même sémantique. Un
lien est une instance d’une association.
Chaque association peut être identifiée par son nom
Une association entre classes représente les liens
qui existent entre les instances de ces classes
Une association a deux rôles, selon le sens dans
lequel on la regarde.
Le diagramme des classes
À un rôle peut être ajoutée une indication de
navigabilité, qui exprime une obligation de la part de
l’objet source à identifier le ou les objets cibles,
c’est-à-dire en connaître la ou les références.
Quand une navigabilité n’existe que dans un seul
sens de l’association, l’association est dite
Monodirectionnelle. On place généralement une
flèche sur le lien qui la représente graphiquement,
mais ce lien peut être omis quand il n’y a pas
d’ambiguïté.
Le diagramme des classes
Une association est bidirectionnelle quand il y a
navigabilité dans les deux sens, et induit la
contrainte supplémentaire que les deux rôles sont
inverses l’un de l’autre.
Un rôle est doté d’une multiplicité qui fournit une
indication sur le nombre d’objets d’une même classe
participant à l’association.
La notation est la suivante :
Les termes que l’on retrouve le plus souvent sont :
1,*, 1..* et 0..1
Mais on peut imaginer d’autres cardinalités comme
2, pour les extrémités d’une arête d’un graphe.
Le diagramme des classes
Il faut noter que les cardinalités se lisent en
UML dans le sens inverse du sens utilisé
dans MERISE.
Par ailleurs, le choix des cardinalités a des
répercussions importantes sur la conception,
en particulier si l’on utilise un générateur
automatique de squelette de code
Le diagramme des classes
Il est fréquent qu’un lien sémantique entre
deux classes soit porteur de données qui le
caractérisent. On utilise alors des attributs
d’association,
Le diagramme des classes
Lorsque le lien sémantique est porteur de
données qui constituent une classe du modèle,
on utilise des classes d’association
On peut aussi avoir à utiliser des associations
n-aires, lorsque les liens sémantiques sont
intrinsèquement partagés entre plusieurs
objets.
Le diagramme des classes
Le diagramme des classes
Une interface est une classe particulière qui ne
contient que des opérations. Elle ne présuppose
rien de l’implémentation de ces opérations, mais
spécifie leur sémantique. Une interface permet
donc de décrire certaines caractéristiques de classe
en dehors de toute hiérarchie
L’interface est matérialisée par un petit cercle
associé à la classe source. La classe utilisatrice de
l’interface est reliée au symbole de l’interface par
une flèche en pointillé
Le diagramme des classes
Les interfaces définissent souvent des
comportements génériques qui ne peuvent pas être
encapsulés dans des classes mères car ils ne font
pas partie de la sémantique propre aux objets.
Les noms des interfaces se terminent souvent par le
suffixe « able » , ce qui signifie que des interfaces
représentent seulement certaines aptitudes de
classes. Ces aptitudes caractérisent des potentialités
de classes qui ne font pas partie des caractéristiques
intrinsèques de la classe
Le diagramme des classes
Une interface est une spécification et non une
classe réelle.
Une interface peut s’assimiler à une classe
abstraite.
Une classe abstraite est une classe qui n’a pas
d’instance directe mais dont les classes
descendantes ont des instances. Son rôle est de
factoriser un certain nombre de caractéristiques
dans le but de la spécifier par la suite. Une classe
abstraite sans classes dérivées est a priori inutile
Le diagramme des classes
L’agrégation est une association qui permet de
représenter un lien de type « ensemble »
comprenant des « éléments ». Il s’agit d’une
relation entre une classe représentant le niveau
ensemble et 1 à n classes de niveau « éléments ».
L’agrégation modélise un lien structurel entre une
classe et une ou plusieurs autres classes.
La composition est une relation d’agrégation dans
laquelle il existe une contrainte de durée de vie
entre la classe « composant » et la ou les classes
« composé ». Autrement dit la suppression de la
classe « composé » implique la suppression de la
ou des classes « composant »
Le diagramme des classes
La généralisation est la relation entre une classe et
une , deux autres classes ou plus partageant un
sous-ensemble commun d’attributs et / ou
d’opérations
Le diagramme des classes
Selon l’activité de l’ingénieur, qu’il s’agisse
d’analyse, de conception ou
d’implémentation, le niveau de détail avec
lequel est représenté le diagramme des classes
change énormément.
Avant de dessiner un diagramme des classes,
il est crucial de savoir à partir duquel des trois
points de vues l’on décide de se placer :
Le diagramme des classes
– le point de vue de l’analyse, qui en général se
doit d’oublier tout aspect de mise en œuvre et, en
ce sens, est complètement indépendant du logiciel
(on n’y parlera pas de structuration des données :
tableaux, pointeurs, listes, ...) ;
– le point de vue de la conception, qui cherche à
identifier les interfaces, les types des objets, leur
comportement externe et la façon interne de les
mettre en oeuvre, sans être encore fixé sur un
langage ;
Le diagramme des classes
- le point de vue de l’implémentation, qui
cherche à décrire une classe, ses attributs et
ses méthodes en pensant déjà au code qui les
implémentera et prend en compte les
contraintes matérielles de temps d’exécution,
d’architecture, etc.
Le diagramme des classes
Dans le cadre d’une analyse, seuls les noms des
attributs et les principales méthodes de la classe ont
à être mentionnées.
Dans le cadre d’une conception et, à plus forte
raison, d’une implémentation, la description des
classes devra être exhaustive.
De nombreuses classes spécifiques seront ajoutées
lorsque l’on passe de l’analyse à la conception,
l’organisation des diagrammes peut évoluer, etc.
Le diagramme des packages
Il n’est pas toujours facile de décomposer
proprement un grand projet logiciel en sous-
systèmes cohérents.
Pratiquement, il s’agit de regrouper entre elles des
classes liées les unes aux autres de manière à
faciliter la maintenance ou l’évolution du projet.
L’art de la conception de grands projets réside dans
la division ou modularisation en « paquetage »
(package en JAVA), de faible dimension,
minimisant les liens interpackages tout en
favorisant les regroupements sémantiques.
Le diagramme des packages
Minimiser les liens inter-packages permet
de confier la conception et le
développement à des équipes séparées
en évitant leurs interactions, donc
l’éventuel cumul des délais, chaque équipe
attendant qu’une autre ait terminé son
travail.
Les liens entre paquets sont exprimés par
des relations de dépendance et sont
Le diagramme des packages
À un niveau d’analyse très général, on aura
tendance à effectuer un regroupement en packages
qui suit plus ou moins le découpage en cas
d’utilisations.
Mais certaines classes plus centrales que d’autres
seront présentes dans de nombreux cas
d’utilisations.
On cherche alors à identifier et regrouper des
ensembles de classes qui ont une forte connectivité.
Le diagramme des classes
Seule l’expérience pratique permet de
déterminer des méthodes conduisant à des
bons découpages.
Le diagramme des classes
Comment construire un diagramme de classes ?
Jusqu’à présent, aucune méthode ne permet de
trouver automatiquement et donc facilement les
classes et les associations d’un modèle.
Une analyse linguistique de ce que l’équipe
d’informaticiens a pu rédiger pendant les deux
phases d’expression des besoins et de de
spécification (cas d’utilisation) pourra aider à
identifier un diagramme de classes préliminaire
Diagramme d’états
La modélisation dynamique est une réelle
nouveauté apportée par les méthodes objet par
rapport aux autres types de méthodes et en
particulier par rapport aux méthodes systémiques
telle que MERISE.
Une grande partie de la modélisation systémique
vise à décrire la structure et les relations des entités
du système dans des modèles dits « entités-
relations » qui ressemblent très nettement aux
modèles objet d’UML même si, ils n’utilisent pas
les concepts de la technologie objet
Diagramme d’états
Aucune étude du cycle de vie des entités au cours
du déroulement de l’application n’est proposée.
C’est ce type d’analyse que propose UML avec la
modélisation dynamique
Cette modélisation nécessite une réelle
compréhension du fonctionnement globale du
système (rôles et activités des objets dans le
fonctionnement du système, événements provenant
de l’extérieur du système)
Diagramme d’états
L’état d’un objet est définie, à la fois par les valeurs
de ses variables d’instance et par les valeurs de ses
liens avec d’autres objets.
Au cours du déroulement d’une application, en
fonction des options choisies par les utilisateurs , un
objet peut passer par plusieurs états ou rester dans son
état initial
L’état d’un objet représente une durée, un intervalle de
temps quantifiable à l’échelle du système, un espace
de temps séparé par deux événements
Diagramme d’états
Un événement est un stimulus pouvant transporter
des informations (sous la forme de paramètres), il
se produit à un instant donné : un événement n’a
pas de durée contrairement à un état
Une transition est le changement d’état d’un objet
causé par un événement. Les transitions sont
représentées par des flèches portant le nom et les
paramètres des événements associés
Diagramme d’états
Deux types d’éléments permettent de préciser une
transition :
- les attributs qui correspondent à des informations
ou des paramètres portés par des événements ; ils sont
représentés entre parenthèses après le nom de
l’événement. Une transition peut porter une liste
d’attributs
- les gardiens ou conditions qui sont des fonctions
booléennes ; ils sont représentés entre crochets après
la liste des attribut. Une transition portant un gardien
ne peut être effectuée que si le gardien est vérifié, elle
peut éventuellement porter plusieurs gardiens
Diagramme d’états
Opérations : généralement lorsqu’un objet réagit à
un événement, il déclenche en réponse à cet
événement une ou plusieurs opérations. Une
opération correspond à une méthode. Deux types
d’opérations peuvent être impliquées dans un
diagramme dynamique : les activités et les actions
Diagramme d’états
Une activité est une opération continue dans le
temps, elle prend un certain temps pour se réaliser.
Elle est forcément associée à un état.
Une action est une opération instantanée, elle est
réalisée de façon immédiate, et peut être associée
aussi bien à l’état d’un objet qu’à une transition
Diagramme d’états
Un diagramme d’états fait intervenir des
événements et des états, il est donc composé d’un
ensemble de transitions
Un diagramme d’états est en quelque sorte un
graphe constitué de nœuds représentant des états
ainsi que des flèches représentant des transitions
portant des paramètres et des noms d’événements
La représentation graphique d’un diagramme d’états
est similaire à celle d’un automate à état finis
Diagramme d’états
Un diagramme d’états est propre à une classe donné : il
décrit les états des objets de cette classe, les événements
auxquels ils réagissent et les transitions qu’ils effectuent.
Il faut donc toujours préciser, lors de l’élaboration d’un
tel diagramme, la classe de l’objet que l’on souhaite
décrire de manière dynamique.
Un diagramme d’états ne permet pas de représenter les
relations d’interaction entre les objets intervenant dans
un système, mais bien le cycle de vie des objets d’une
classe
Diagramme de collaboration
Un diagramme de collaboration entre objets vise à
représenter du point de vue statique et fonctionnelle
les objets impliqués dans la mise en place d’une
fonction applicative. L’objectif est de construire un
modèle expliquant la coopération entre les objets
utilisés pour la réalisation d’une fonctionnalité
Les interactions entre objets décrites dans un
diagramme de collaboration sont des séquences de
messages échangés par les objets dans le cadre de
la réalisation d’une opération. Il est d’abord
nécessaire de mettre en place le contexte avant de
définir les interactions
Diagramme de collaboration
Le formalisme utilisé est celui des scénarios ; les
messages qui se déroulent de façon séquentielle sont
numérotés.
Les diagrammes de collaboration entre objets sont
souvent chargés en notations et parfois moins lisibles
que les scénarios.
Ils sont incontournable dans le processus de
modélisation objet car ils permettent de gérer et de
comprendre les relations entre le diagramme de
classes et les diagrammes de séquences.
Diagramme de collaboration
Ils représentent un moyen indispensable de
vérifier la cohérence globale et la
consistance d’une analyse objet, et donc de
valider l’adéquation entre la vue objet et la
vue fonctionnelle
