analyse et modélisation objetenjoythepunk.free.fr/docs/itin/cours/uml/cours/analyse... · web...

Analyse et modélisation ObjetUML

G. Vieillechaizeuml modeles UML v6_______________________________________________________

Analyse et modélisation Objet avec UML

1. DÉFINITION D'UML 5

2. LE DIAGRAMME DE DÉPLOIEMENT 12

3. LE DIAGRAMME DE CONTEXTE 13

4. LES CAS D’UTILISATION 14

5. DIAGRAMMES D’INSTANCES (OU D'OBJETS) 18

6. DIAGRAMME DE CLASSES 19

7. DIAGRAMMES D’ACTIVITÉ 28

8. DIAGRAMMES D'INTERACTION, DÉFINITION DES OPÉRATIONS 32

9. LES DIAGRAMMES ÉTATS - TRANSITIONS 41

10. DIAGRAMME DE PACKAGES 46

11. Récapitulation 47

Par quoi commencermême réduit à l'essentiel, UML reste vastepour commencer votre 1ère analyse, vous pouvez peut-être vous limiter à lire

le chapitre 1 Définition d'UML le début du chapitre 4 Les cas d'utilisation, paragraphes 1 et 2 le début du chapitre 6 Diagramme de classes, paragraphes 1 à 3 le début du chapitre 7 Diagramme d'activités, paragraphes 1 à 3 le début du chapitre 9 Diagramme d'états, paragraphes 1 et 2

jetez un coup d'oeil aux chapitres 2 (Diagramme de déploiement) et 5 (Les diagrammes d'instances) qui sont très courts

gardez le reste pour plus tard…

Bibliographie pour commencerpour de bons conseils sur la façon d'utiliser UML

UML2.0, Fowler, Campus PressUML2 en action, Roques et Vallée, Eyrolles

pour des exercices d'utilisationUML2 par la pratique, Roques, Eyrolles

pour une présentation plus complète des modèlesModélisation objet avec UML, Muller et Gaertner, Eyrolles

__________________________________________________________________________Page UML 1



Table détaillée

1. DÉFINITION D'UML 5

1.1. Qu'est-ce qu'UML 5

1.2. Objectif et place d'UML dans un projet logiciel 5

1.3. Approche retenue dans le présent support 6

1.4. UML en fait trop 7

1.5. UML ne fait pas tout 7

1.6. Références, outils 7

1.7. Première définition des principaux modèles 8

1.8. L'enchaînement des principaux diagrammes 11

2. LE DIAGRAMME DE DÉPLOIEMENT 12

3. LE DIAGRAMME DE CONTEXTE 13

4. LES CAS D’UTILISATION 14

4.1. Concepts et construction 14

4.2. Documentation 15

4.3. Enrichissements possibles 16

4.4. Rôle et place des cas d'utilisation 16

4.5. Pièges et conseils 17

5. DIAGRAMMES D’INSTANCES (OU D'OBJETS) 18

5.1. Concepts et construction 18

5.2. Rôle et place des diagrammes d'instance 18

6. DIAGRAMME DE CLASSES 19

6.1. Première définition d'une classe 19

6.2. L'ébauche du diagramme de classes 206.2.1. Règles et étapes de construction 20

6.2.1.1. Première définition des associations 21

6.3. Pièges et conseils 22

6.4. L'enrichissement du diagramme de classes 23

__________________________________________________________________________Page UML 2


G. Vieillechaizeuml modeles UML v6_______________________________________________________6.5. Le diagramme de classes finalisé 23

6.5.1. Finalisation des attributs 246.5.2. Compléments sur les associations 24

6.5.2.1. L’agrégation 246.5.2.2. Attributs d’associations 256.5.2.3. Multiplicités 25

6.5.3. L'héritage 27

6.6. Plusieurs diagrammes de classe 27

7. DIAGRAMMES D’ACTIVITÉ 28

7.1. Rôle et place des diagrammes d’activité 28

7.2. Concepts de base du diagramme d’activité 28

7.3. Diagramme d'activité pour représenter un algorithme 29

7.4. Diagramme d'activités à couloirs d'activités 29

7.5. Représentation avec les objets utilisés 30

7.6. Quelques précisions 317.6.1. Activité ou état? 317.6.2. Synchronisation 31

8. DIAGRAMMES D'INTERACTION, DÉFINITION DES OPÉRATIONS 32

8.1. Deux formes de diagrammes d’interaction 32

8.2. Diagrammes de séquence (scénarios) 338.2.1. Premiers concepts et construction 338.2.2. Passage des messages aux opérations 35

8.2.2.1. Enrichissement du diagrammes de classes 368.2.3. Naissance et disparition d’un objet 368.2.4. Documentation des opérations 37

8.3. Diagrammes de collaboration 38

8.4. Pièges et conseils 398.4.1. "bons" et "mauvais" scénarios 398.4.2. Comparaison de deux solutions plus globales 40

9. LES DIAGRAMMES ÉTATS - TRANSITIONS 41

9.1. Premiers concepts et construction 41

9.2. La logique et la signification du diagramme d'états 42

9.3. Quelques éléments de modélisation complémentaires 439.3.1. Sous-états 439.3.2. Condition sur une transition 439.3.3. Transition sans changement d'état 43

9.4. Enrichissement du diagramme de classes 44

9.5. Rôle et place des diagrammes d'états 44

__________________________________________________________________________Page UML 3


G. Vieillechaizeuml modeles UML v6_______________________________________________________9.6. Pièges et conseils 45

10. DIAGRAMME DE PACKAGES 46

11. Récapitulation 47

__________________________________________________________________________Page UML 4



1. Définition d'UML

1.1. Qu'est-ce qu'UMLUML : Unified Modeling Language

né en 1995 définie comme norme par l’OMG (Object Management Group)

UML est une méthode de modélisation: UML définit comment représenter visuellement un logiciel

comment dessiner un modèleet surtout quoi représenter sur chaque modèle

UML ne définit pas quand ni pourquoi modélisercela est le rôle de la méthode de conduite de projet

Version courante: UML2 (adoptée en 2004)- définit de nouveaux modèles- apporte quelques améliorations aux modèles existants

Extensions: les "profils" sont destinés à adapter UML à un contexte spécifiqueUML Real TimeUML pour les services web

1.2. Objectif et place d'UML dans un projet logicielL'objectif et la place d'UML dépendent de la méthode de conduite de projet adoptée

à l'extrême la plus ambitieuse, UML modélise tous les détails du futur logicielapproche MOA (Model Driven Architecture)approche actuellement à un stade expérimental

à l'extrême la plus modeste, UML (s'il est utilisé) ne servira qu'à clarifier quelques points difficiles du projet

approche du RAD (Rapid Application Development) et des méthodes "agiles" (par exemple Extreme Programming)la modélisation, lorsqu'elle est utilisée, est limitée aux points qui nécessitent une clarification

dans une approche intermédiaire, UML sert à réaliser le dossier d'analyse et de conception, sans prétendre modéliser tous les détails

c'est l'approche présentée par exemple dans "UML en action", mentionné dans la bibliographie

__________________________________________________________________________Page UML 5



1.3. Approche retenue dans le présent supportC'est la 3ème approche qui est retenue dans le présent support

Dans cette approche, on va voir l'utilisation d'UML- dans l'étude de besoinsdans l'analyse métier- dans la conception technique générale (l'architecture)- dans la conception technique détaillée (les objets)

L'enchaînement des étapes sera probablement

définition des termesétude de besoins

dans l'approche traditionnelle, c'est ce qui aboutit au "cahier des charges"dans les approches modernes, c'est ce qui est destiné à formaliser les besoins et à suivre leur prise en compte et leur évolution ("requirement management")

analyse métier (analysis en anglais)en général- part de la définition des besoins fonctionnels- ignore les contraintes techniques et l'environnement d'exécutionen conception objet- se concentre sur les "objets métier", dits aussi "objets du domain"- ignore les objets techniques (objets applicatifs, objets d'IHM, etc.)

La conception techniqueconception technique générale (system design en anglais)

définit les choix d'architecture: langage(s) utilisé(s), bases de données, protocoles réseau, répartition physique du logiciel, choix d'outils d'implémentation …

conception technique détaillée (object design en anglais)détaille l'implémentation des objets métierajoute les objets techniques

__________________________________________________________________________Page UML 6



1.4. UML en fait tropL'objectif d'UML est d'aller jusqu'à la génération du code (MDA, vu plus haut) et de couvrir tous les types de projets logiciels

UML propose 9 types de diagrammesUML2 en propose 13

il y a plus de modèles dans UML que ce qui est nécessaire dans la plupart des projets

l'objectif n'est pas d'utiliser tous les modèles mais de choisir ceux qui sont utiles selon le type de projet

1.5. UML ne fait pas toutUML concerne seulement la modélisation, on l'a déjà dit; mais UML ne contient pas tous les modèles qui peuvent être utilespar exemple UML ne donne aucun outil pour modéliser une Interface Homme-Machine (le dessin des

pages ou des écrans de l'IHM, et surtout leur enchaînement – la cinématique de l'IHM) la représentation d'un document XML sous forme d'un arbre d'objets UML est bien

moins lisible que sous la forme proposée par Altova (XMLSpy) la représentation des données peut être plus lisible en modèle entités-associations (le

modèle conceptuel de Merise) qu'en modèle relationnel la représentation d'un processus est plus riche dans les modélisations spécialisées

(BPMN, BPSS…) qu'en UML

UML n'interdit pas d'utiliser d'autres modèles en complément.

1.6. Références, outils

Si l'on veut mieux comprendre UMl, on peut en étudier les ancêtres :OMT: Object Modeling Technique (Rumbaugh)Booch Objectory ou OOSE (Jacobson)UML est né de la fusion de ces 3 méthodes et s'est inspirée de beaucoup d'autres (Schlaer et Mellor, Coad et Yourdon…)

Quelques AGLs de conception objet

et aussi les plugins des outils de développement(en particulier Eclipse)

__________________________________________________________________________Page UML 7

Rational RosePoseidonPower designer et AMC designerMegaTogetherArgo UML…



1.7. Première définition des principaux modèles

Sur les 13 types de diagrammes, 8 ou 9 au maximum sont importants dans l'immédiat

Il y a beaucoup e choses dans la norme UML, mais, selon les pères de la méthode eux-mêmes, on peut analyser 80% des problèmes avec 20% de la normeCe sont ces 20% qui sont détaillés ici; le reste est seulement mentionné en conclusion ( voir le cours "UML avancé" )

Cas d’utilisation

décrit les interactions entre le futur système et ses utilisateurs

Classes

représente les types d'objets qui existeront dans le système

Diagramme d'activités

__________________________________________________________________________Page UML 8

AnnuairePrincipal

AnnuaireSecondaire

Journal



décrit un algorithme de traitement ou un processus

__________________________________________________________________________Page UML 9



Etats-Transitions

montre les états successfs d'un objet

Diagramme de déploiement

représente les machines (ou les types de machines) sur lesquels le logiciel sera déployé

diagramme d'instances (ou d'objets)

représente des instances d'objets qui existent à un moment donné dans le système

retour sur les définitions:"objet"

"classe"

"instance"

Séquence ( appelés aussi scénarios)

montre un enchaînement d'opérations entre des objets du système

__________________________________________________________________________Page UML 10

activé désactivé

Serveur d' annuaire

annuaire1 :AnnuaireSecondaire annuaire2 :

AnnuaireSecondaire

annuaire_A :AnnuairePrincipal

journal_A :Journal



__________________________________________________________________________Page UML 11



Diagramme de communication (UML2) ou de collaboration (UML1)

combine la représentation des objets (instances), celle de leur relation, et la circulation des appels de méthodes

Packages

sert simplement à regrouper des classes qui appartiennent à une même famille

Vocabulaire: on distingue souvent, du point de vue des types de modèles

les modèles dynamiques, qui représentent l’expression d'un comportementdiagrammes de séquence, de collaboration, d'états...

les modèles statiques, qui représentent une structurediagrammes de classes, de composants, de déploiement...

__________________________________________________________________________Page UML 12



1.8. L'enchaînement des principaux diagrammes

A l'intérieur d'une phase de l'analyse (et aussi de la conception technique) on retrouve toujours le même enchaînement entre les modèles

Les cas d’utilisation représentent le lien avec les étapes qui ont précédé l'analyse, un point de départ pour l'analyse

Le diagramme de classes représente l'autre point de départ, et le point d'arrivée

Les diagrammes d'activités et de séquence représentent l'implémentation des cas d'utilisation et l'utilisation des objets.

Les diagrammes d'états représentent tous les états possibles des objets d'une classe donnée.

Les mêmes modèles se retrouveront en conception technique, avec toutefois une importance relative différente. les objets identifiés en analyse se retrouvent (avec d'autres ajoutés entre temps...) dans

l'implémentation.

__________________________________________________________________________Page UML 13



2. Le diagramme de déploiement

Il décrit l'implantation physique du logiciel

il représente les "processeurs": matériels sur lesquels sont implantées les différentes parties du logiciel

process: les principaux programmes exécutés sur le processeur

unités passives ("devices"): matériels qui n'hébergent pas le logiciel développé dans le

projet (par exemple des routeurs, des multiplexeurs…)

connexions: liens entre les processeurs et les devices

protocoles: les principaux protocoles utilisés sur une connexion

Un exemple de diagramme de déploiement:

processors et devices sont appelés aussi nœuds

des stéréotypes peuvent être utilisés pour définir des types particuliers de processeurs ou de devices

__________________________________________________________________________Page UML 14

une configuration bien connue

browser

java script

serveur web

servletspages JSP

stockage<<disque>

<<http>>



3. Le diagramme de contexte

C'est une forme particulière des diagrammes de use cases ou des diagrammes de classes, qui seront vus plus loin.

But: montrer en introduction au dossier d'analyse une vue très globale du rôle et de la place de l'application

Contenu: on représente la future application comme une boite noire, et on représente les principaux échanges enter l'application et les utilisateurs (ou les autres applications)

Exemple

application comptable

adhérent

gestion des adhérents et activités

cotisations reçues

demande d'adh'ésion

inscription à une activité

club

définition des activités

tableaux de bord

__________________________________________________________________________Page UML 15



4. Les cas d’utilisation

4.1. Concepts et construction

Notion définie par Jacobson

ConceptsCas d’utilisation:un service (une fonctionnalité) attendu du système“ une fraction du comportement du système, réunie en une transaction, en réponse à un évenement déclencheur venant d’un acteur ”

Acteur:- c’est un objet extérieur au système

- c'est une entité physique (le service Comptabilité, le chef comptable) ou un rôle (le rédacteur, le vérificateur)

Noter: un acteur n'est pas forcément un acteur humain, mais peut être une autre application

Message ou événementle message en entrée déclenche un casle message en sortie est le résultat du déroulement du cas

Construction du diagramme=> un cas d’utilisation comporte un acteur initiateur, et éventuellement un ou n acteurs participants

__________________________________________________________________________Page UML 16



ici Adhérer est initialisé par le (futur) adhérent

=> le cas d’utilisation figure l’ensemble des interactions qui peuvent survenir entre les acteurs et le système, à partir de l’évenement déclencheur

=> le système est vu comme une boite noire

pour chaque cas d’utilisation, il y a un ensemble d’événements qui peuvent survenir entre les acteurs participants et le système.

__________________________________________________________________________Page UML 17



4.2. Documentation

Le diagramme de cas d'utilisation ne suffit pas; les cas doivent impérativement être décrits.

UML ne définit pas le mode de documentation des cas d'utilisation. Si la démarche d'analyse attache de l'importance aux use cases, le chef de projet doit définir le mode de documentation choisi: documentation peu formelle

une description informelle peut "raconter" en quelques phrases le déroulement habituel du use case (voir l'exemple donné par Rumbaugh dans son livre sur OMT)

fiche de cascertains proposent d'établir une fiche de cas

Cas n° xxxCatégorie les cas peuvent être classés par familles

Libellé du casPar ex.: retirer de l'argent dans un distributeur automatique

Acteur principal: celui qui initie la transaction; ici le porteur de la carte bancaireActeurs secondaires: ceux qui participent à la réalisation du cas; ici, le système central de gestion des cartes voléesDescription du casdécrire sous forme textuelle le déroulement du cas (de quelques lignes à une page ou plus)1. introduire la carte2. entrer le code d'identification3. …4. …Règles de gestionquelles sont les règles qui doivent être appliquées à ce caspar ex.: limiter le montant distribuéPréconditionsdans quel état le système doit-il se trouver au début du cas?par ex., le distributeur a terminé le traitement du client précédent ou de l'opération précédentePostconditiondans quel état le système doit-il se trouver à la fin du cas?par ex., le distributeur est prêt à traiter la demande suivante du client, ou le client suivantExceptionsquelles sont les erreurs qui peuvent être déclenchées?par ex.: "transaction non autorisée", "réserve de billets épuisée", etc.Extensions et variantes extensions (quels sont les cas qui étendent le cas décrit ici?); par ex. retirer de l'argent en

choisissant la devise ou les coupures variantes; déroulements (normaux) possibles autres que celui décrit; par ex.le distributeur

peut proposer plusieurs devises différentesCompléments, questions en suspenscommentaires, observations, questions en attente…

__________________________________________________________________________Page UML 18



4.3. Enrichissements possibles

relation "utilise" ("uses" ou "includes") ou relation "étend" ("extends")

un cas d’utilisation peut inclure (“ uses ”) d’autres cas

relation d'héritage

un cas dérivé hérite de la signification et du contenu ( les opérations ) de son super-cas

4.4. Rôle et place des cas d'utilisationSuivi de l'évolution des besoinsdans certaines approches actuelles, on considère que les besoins ne peuvent pas être figés

l'inventaire des cas d'utilisation sert alors à tenir à jour la liste des besoins pris en compte et leur description (requirement management)

Structuration de l'analyse par les cas d'utilisationcertaines méthodes font jouer un rôle d'organisation du projet aux cas d'utilisation ("use case driven analysis")dans cette approche1. les cas listent les besoins à analyser, à implémenter et à tester

2. on en tire la liste des scénarios à analyser.analyser le ou les scénario(s) correspondant au déroulement normal du casanalyser les scénarios correspondant au déroulement anormal du cas

3. on s'en sert comme référence lors de la validation par les utilisateurs

4. on définit une itération en termes de use cases implémentés par celle-ci

5. on mesure l'avancement du projet en terme de nombre de use cases implémentés

__________________________________________________________________________Page UML 19

enregistrer une adhésion

enregistrer un paiement

<<include>>

planifier une activité

planifier une activité répétitive



4.5. Pièges et conseilsProcéder par itérations

Combien de cas d'utilisation?

ne pas tomber dans un découpage trop fin (dit "découpage fonctionnel")

Documenterchaque caschaque acteurchaque message

Les acteursdéfinir les acteurs logiques ou les rôles, plutôt que les acteurs physiquesne pas définir comme acteurs des objets internes au systèmele temps peut-il être modélisé en tant qu'acteur?

Ignorer les messages entre les acteurs externes

Comment choisir les cas à analyser d'abord?commencer par les cas fréquents?ou par les cas difficiles?

__________________________________________________________________________Page UML 20



5. Diagrammes d’instances (ou d'objets)

5.1. Concepts et construction

: Activité

échecs : Activité

judo

Un objet est représenté par un rectangle qui contient soit le nom de la classe et celui de l'instance (séparés par un double point)

soit le nom de la classe seulement

soit le nom de l'objet, dont la classe n'est pas encore définie

judo : Activité

toto : Adhérent pratique

5.2. Rôle et place des diagrammes d'instancedans l'étape d'initialisation de l'analyse- pour identifier les objets et ébaucher le diagramme de classes

__________________________________________________________________________Page UML 21

Instance anonyme

Classe anonyme

On peut faire figurer les relations entre objets

On peut faire figurer la multiplicité ("il y a plusieurs instances de Activité pour une de Animateur")et / ou les attributs significatifs



- pour valider le diagramme de classes (attributs, multiplicités...)

- pour construire les diagrammes de séquence et d’interaction

dans les étapes ultérieures- pour montrer les interactions entre les objets=> diagramme de collaboration, plus loin dans ce chapitre, et dans la conception technique

- pour montrer la configuration d'un programmeen conception technique et en rétroconception

__________________________________________________________________________Page UML 22



6. Diagramme de classes

Le diagramme de classes est le: diagramme central de la modélisation objet; il est construit par itérations pendant l'étape d'analyse

1. ébauche du diagramme de classestrouver les classes que l'on utilisera pour construire les diagrammes de séquence

2. enrichissement à partir des diagrammes de séquence et des diagrammes d'étatreporter les opérations et attributs découverts en construisant ces diagrammes

3. finalisation (multiplicités, héritage, etc.)

l' "ébauche de diagramme de classes" est une notion de méthode définie par exemple dans OMT (Rumbaugh), ou "UML en action" (Roques et Vallée), mais pas dans le guide d'utilidation d'UML

6.1. Première définition d'une classe

Chaque classe est représentée sous la forme d’un rectangle divisé en 3 compartiments. Le 1er compartiment contient le nom de la classe, le second les attributs et le 3ème les opérations

AdhérentnomprénomnuméroAdhérent

ajouterActivité()calculerCotisation()

Une classe comporte - un nom- des attributs- des comportements (les opérations)- éventuellement des règles ou contraintes.

habitudes d'écriture:majuscule au nom de classe Adherentminuscule au nom d'attribut nom, prenomminuscule et parenthèse pour d'une opération valider()majuscule à l'intérieur des noms composés calculerCotisation ()

Identifiants: - distinction entre l'identifiant fonctionnel (n° de client, n° de facture… connus des utilisateurs) et l'identifiant technique (adresse mémoire, OID, ignorés pendant l'analyse)- l'identifiant fonctionnel est facultatif en conception objet

__________________________________________________________________________Page UML 23



- pas de formalisme pour représenter les identifiants.

Un attribut: une information décrivant les objets de la classe.

unicité des noms d'attributs: à l'intérieur de la classe, non entre les classes.

Une opération ou méthode implémente un comportement des objets de la classe.

Le même nom dans différentes classes doit (ou devrait) désigner la même nature d'opération (la même signification pour les utilisateurs du système).

Autre terme utilisés: propriété, terme générique regroupant attribut ou opération

6.2. L'ébauche du diagramme de classes

Une ébauche de diagramme de classes

Sallenumero : int

activitenom : String

Club

utilise

propose

Animateurnom

emploie

encadre

adherentnumeronom

pratique

Adresse

possède

6.2.1. Règles et étapes de construction

Objets métier et objets techniquesl'analyse doit être faite indépendamment des futurs choix techniques l'analyse se limite donc aux objets métier, et ignore les objets techniques

les objets d'IHM (et les objets applicatifs en général) sont ignorésles objets techniques sont ignorés

__________________________________________________________________________Page UML 24



Dans un premier temps, on ne représente généralement pas les opérations; elles vont être ajoutées dans la seconde phase de l'analyse, après avoir analysé les comportements (diagrammes d'activités, diagrammes de séquence…)

Les contraintes liées aux outils ne sont pas prises en compte à ce stadela localisation physique des objets est ignoréeles objets sont persistants autant que nécessairepas de contraintes liées au langage

Règles de simplification pour l'étape d'analyse

on fait des hypothèses simplificatrices concernant la manipulation des objetsles attributs sont "publics en lecture"il est toujours possible d'accéder à un objet par la valeur de ses attributsil est toujours possible de parcourir la liste des instances d'une classe, et de choisir dans cette liste

toutes ces simplifications seront bien sûr abandonnées lors de la conception techniqueet des compléments seront ajoutés au modèle:

visibilité des propriétés (privé, public, ...)mode d'implémentation des associations (pointeurs?...)etc.

6.2.1.1. Première définition des associations

membreAdhérent Club

Association:

un lien entre les objets de deux classes:un adhérent est membre du clubl'animateur encadre une activitéun adhérent peut être l'enfant d'un autre adhérent (et cela a une importance pour notre analyse )...

du point de vue de la signification ou du contenu ("sémantique")une assocoation est un lien durable, "structurel" entre deux objetsdu point de vue techniqueune association est un chemin d’accès entre les instances d’une classe et les instances de l’autre

__________________________________________________________________________Page UML 25



Nommer les associations:ce n'est pas obligatoire si la signification est claireplusieurs associations (entre des paires d'objets différents) peuvent porter le même nomessayer de donner un nom qui se réfère à la durée, non à une action

par ex. Adherent "participe à" Activité, plutôt que Adherent "s'inscrit à" Activité

Animateur

Activité

encadre

planifie

Il peut y avoir plusieurs associations

différentes entre deux mêmes classes

vérifier au niveau des instances qu'il s'agit bien de deux associations différentes

AdherentnuméroAdhérent

famille+parent

+enfant

Une association peut être réflexived'une instance vers une autre, dans la même classe

Un rôle décrit la part prise par une classe dans une association

Associations ternaires:

(ou n-aire): relie plus de deux classes.

toujours vérifier si l'association ne peut pas être décomposée.

Quelques exemples de ternaires

__________________________________________________________________________Page UML 26



un véhicule appartient au titulaire de la carte grise

plusieurs conducteurs habituels peuvent être déclarés pour un véhicule

un véhicule est couvert par un contrat d'assurance, qui doit couvrir tous les conducteurs habituels

les développeurs sont affectés aux projets en cours

les développeurs utilisent les AGLs pour réaliser les projets

6.3. Pièges et conseils

Découverte des objetsun objet possède des états et des comportements

Une classe est une abstraction qui regroupe les objets semblablestous les objets d’une classe partagent le même comportement et les mêmes attributs

Par rapport aux entités, pour les "merisiens", - une entité peut se décomposer en plusieurs classes (classe Adhérent et classe Adresse)- une classe peut regrouper plusieurs entités (relation maitre-détail par exemple)- une classe peut être créée pour structurer des comportements...

Candidats objets:plutôt trop de candidats objets, pour éliminer ensuite, que pas assez pour éclater ensuite un objet en deux objets distincts

Attention aux objets cachés

et aux associations cachées

Ne pas confondre l'acteur et l'objet qui le représente: par ex. l'acteur "utilisateur" et l'image de l'utilisateur dans le système.

__________________________________________________________________________Page UML 27

ou



6.4. L'enrichissement du diagramme de classesL'enrichissement peut se faire de 2 façons- on génère les squelettes de classes à partir du diagramme de classes et on commence à coderplus tard, on pourra générer le diagramme de classes complété à partir de ce qu'on aura codé (rétro-conception)

- on continue l'analyse avec les diagrammes d'activité, d'états, de séquencepuis on enrichit les classes à partir de ce qu'on a découvert en élaborant ces diagrammes

6.5. Le diagramme de classes finalisé

Qu'est-ce qu'un diagramme de classes "finalisé"?

en fin d'analyse

les attributs d'instance sont définis les opérations sont définies et documentéesles associations sont définies, avec leurs attributs éventuels et les multiplicitéshéritages définis

Question de présentation:on peut faire plusieurs diagrammes pour représenter plusieurs points de vue sur les classes:- arbre d'héritage des classes- associations entre classes- arbre d'agrégation - liste des classes avec le détail de leurs propriétés- etc.

en fin de conception techniqueon trouvera en plus- des attributs et méthodes statiques- des classes abstraites, des interfaces (java), des méthodes abstrtaites pures (C++)- des classes techniques (classes d'accès au réseau, à la base de données…)- etc.

6.5.1. Finalisation des attributs

Les types des attributs:un type de base (numérique, caractère...)un type défini pour les besoins du modèleune liste, un tableau...etc.

__________________________________________________________________________Page UML 28



Détail d'un attribut:- son type- sa valeur par défaut

par exemple:prix: décimal = 100

Attribut dérivé: attribut calculable à partir des autres attributs de l'objet.

6.5.2. Compléments sur les associations

6.5.2.1. L’agrégation

Relation composé-composant entre des objetsla classe d'assemblage contient les objets composés la classe de composant contient les objets composés.

Par ex.: un véhicule, un ordinateur, etc. est composé d'éléments

Parfois désignée par "has a" (par opposition à "is a" pour l'héritage).

Par rapport à une association, ici- la durée de vie des composants est souvent dépendante de celle du composé.

- les propriétés des composés ont un sens pour les composants

- les opérations sur le composé affecteront souvent les composants.

Récursivité:

Element

contient+composé

+composant

une agrégation peut être récursive.

Dans ce cas, il est indispensable de donner un no de rôle à chaque extrémité de l'association

6.5.2.2. Attributs d’associations

Les attributs de lien décrivent l'association:

__________________________________________________________________________Page UML 29



exemple: Les utilisateurs manipulent des fichiers; les droits sont définis pour un type d'utilisateur et pour un type de fichier

Choix entre attributs de lien et attributs des objets liés:Attention : selon que l'information dépend de l'un des objets (ce sera un attribut de l'objet), ou que l'information dépend de l'association entre deux objets (ce sera un attribut de l'association)

la signification du modèle est différentesi les droits sont un attribut du fichieret s'ils sont un attribut de l'association fichier <-> utilisateur

6.5.2.3. Multiplicités

Multiplicité: définit combien d'instances de la classe peuvent être connectées à une seule instance de la classe associée=> la notation est placée à l'opposé de celle des cardinalités dans Merise.

Symboles utilisés par la méthode unifiée:

il y a 0 ou 1 animateur pour une activité

il y a 0 à n animateur(s) pour une activité

__________________________________________________________________________Page UML 30



il y a 1 à n animateur(s) pour une activité, et une seule activité pour un animateur

il y a 1 à 3 animateur(s) pour une activité, et 1 à 2 activité(s) pour un animateur

__________________________________________________________________________Page UML 31



6.5.3. L'héritage

Définition: dépendance entre deux classes selon laquelle une classe (la sous-classe) possède les mêmes propriétés qu'une autre (la super-classe), avec des particularités modifiant ou complétant ces propriétés.

Plusieurs niveaux d'héritage sont possibles.

ne pas oublier: la relation d'héritage transmet les associations, comme les attributs et opérations

Exemple

AdhérentnuméroAdhérent

calculerCotisation()ajouterActivité()

Activiténomdescription

participe

PersonnenomprénométatCivil

majEtatCivil()

EnfanttauxRéduction

calculerCotisation()

un adhérent possède les attributs

- nom, prénom, état civil, parce qu'il hérite de Personne- et, en propre, un numéro

un adhérent possède en plus un attribut taux de réduction

la méthode calculerCotisation() figure dans Adhérent et dans Enfant

la méthode de calcul sera différente dans la super-classe (Adhérent) et dans la sous-classe

Rappels:

__________________________________________________________________________Page UML 32



la généralisation/spécialisation est le mécanisme de conception par lequel on rattache une sous-classe à une super-classe.

L'héritage multiple: cas où un objet appartient à plusieurs arbres d'héritage simultanément.

6.6. Plusieurs diagrammes de classeRôle central: le diagramme de classes centralise toutes les informations il n'est pas question de montrer toutes les informations sur un seul diagramme on construira des diagrammes pour montrer un aspect ou un autre des classes.

arborescence des classes (relations d'héritage) et opérations les classes et leurs associations l'ensemble des classes d'une catégorie etc.

__________________________________________________________________________Page UML 33



7. Diagrammes d’activité

7.1. Rôle et place des diagrammes d’activité

Rôle:un diagramme d'activité présente le déroulement logique et chronologique d'un processus (informatique ou non)

Utilisation:les diagrammes d'activité peuvent être utilisés à des étapes diverses de l'analyse- pour modéliser un processus administratif

- représentation de l'organisation administrative actuelle ou future et de l'impact du projet sur l'organisation du travail des utilisateurs

- BPM (business process modeling), BPR (business process reengineering)- pour décrire le déroulement d'un use case

représentation des étapes d'exécution du use case et des différents enchaînements possibles

- dans la documentation d'une classe, pour expliciter l'algorithme d'une méthode complexe

Les diagrammes d'activité peuvent prendre des formes variées- pour représenter un algorithme- pour représenter le rôle des différents acteurs dans le processus (diagramme d'activités à couloirs d'activités)- pour représenter l'action du processus sur les objets- pour représenter les activités parallèles et les synchronisations

7.2. Concepts de base du diagramme d’activité

- l’activité et la transitionest un traitement est instantanée (pas de durée) est interruptible est automatique (déclenchée

par la fin de l'activité)

- le début

- et la fin du processus

- les conditions :(appelées aussi gardes)

avec le losange ou sans

7.3. Diagramme d'activité pour représenter un algorithme

__________________________________________________________________________Page UML 34



c'est la forme la plus simple du diagramme d'activité

c'est la même chose qu'un ordinogramme cela permet par exemple de dessiner l'algorithme d'un

use case ou d'une opération

Important:

le diagramme d'activité est le seul modèle dynamique qui permette facilement de zoomer

il permet de donner une vue d'ensemble d'un processus (avec des macro-activités) puis de détailler chaque macro-activité dans un sous-diagramme

Il est beaucoup plus difficile de donner une vue d'ensemble dans les diagrammes d'états ou de séquences

7.4. Diagramme d'activités à couloirs d'activités

dans la modélisation d'un processus , un couloir d'activité (swimlane) est souvent utilisé pour représenter un acteur responsable d'une activité

on peut utiliser un couloir pour représenter le logiciel, et les autres couloirs pour représenter les acteurs (utilisateurs, départements de l'entreprise…) qui interagissent avec le logiciel

2 couloirs peuvent représenter 2 parties de l'application qui dialoguent (le client et le serveur par exemple)

chaque couloir peut aussi représenter un objet

__________________________________________________________________________Page UML 35

établir chèque

vérifier

mettre à l'encaissement

: compta club : accueil cluble candidat : adhérent



c'est une forme adapté à la représentation de l'organisation administrative et de l'impact du projet sur cette organisation

7.5. Représentation avec les objets utilisés

comme dans le diagramme d'objets, les rectangles représentent des objets ou instances (pas des classes)les objets peuvent être des instances des "candidats objets" définis dans l'ébauche du diagramme de classes

les flèches continues représentent le "flot de contrôle" (la logique d'enchaînement des opérations)

les flèches pointillées représentent les "flots de données" (création, modification, lecture du contenu des objets)

il n'est pas nécessaire de faire figurer tous les objets

l'état des objets peut être précisé

ce peut être une préparation aux diagrammes de séquenceet aussi une façon de commencer à analyser les états (que l'on va voir à l'étape suivante avec les diagrammes d'état-transition.

__________________________________________________________________________Page UML 36

début de l'enregistrement

enregistrer les infos sur l'adhérent

: Adhesion[complète]

compléter

[ données incomplètes ]

: Adhesion[incomplète]

calculer la cotisation

montant selon catég

[ ok ]

: Tarif

montant selon catég



7.6. Quelques précisions

7.6.1. Activité ou état?

une activité est instantanée (pas de durée, à l'échelle de temps du logiciel modélisé)

par opposition à une activité, un état a une durée

un état peut être actif: - l'objet qui est dans cet état peut faire un traitement pendant le temps où il est dans l'état représenté (par exemple envoyer des messages périodiques pour savoir si une liaison n'est pas tombée)

- ou bien il peut être à l'écoute et réagir lorsqu'un événement se produit (par exemple un socket serveur, en attente de demande de connexion par les clients)la réaction à l'événement peut être la sortie de l'état, ou simplement la production d'un message ou événement en réponse.

7.6.2. Synchronisation

appelées aussi "fork et "join", ils représentent des conditions "et"

Ils peuvent servir - au niveau de l'analyse des processus, à modéliser des processus administratifs qui s'exécutent simultanément

- au niveau de la modélisation d'un programme, à représenter un programme multithread

__________________________________________________________________________Page UML 37

enregistrer les infos sur l'adhérent

calculer la cotisation

[ ok ]attente infos complémentaires

do/ relancer

[ données incomplètes ]

abandon

expiration délai réception infos manquantes

un état

une activité



8. Diagrammes d'interaction, définition des opérations

8.1. Deux formes de diagrammes d’interactionObjectif des diagrammes d’interaction: montrer les échanges de messages ou les appels de méthodes entre les objets

toto : adhérent

: Adherent activité demandée : Activite

1: demande de participation

2: place disponible?

3: oui

4: demande acceptée

Formes:

chronologique: diagramme de séquence (ou scénario)=> pour visualiser l’enchainement des événements à partir d’un événement déclencheur

toto : adhérent

: Adherent

activité demandée : Activite

1: demande de participation

4: demande acceptée

2: place disponible?

3: oui

topologique: diagramme de collaboration=> pour montrer la place et le rôle de chaque objet

Place des diagrammes d'interaction

__________________________________________________________________________Page UML 38

Un diagramme de séquence

Un diagramme de collaboration



Les diagrammes de séquence ou de communication sont plus difficiles à élaborer qu les diagrammes d'activitésils sont aussi moins intuitifs (me semble-t-il)ils supposent que les objets aient déjà été définis avec précision

Pour toutes ces raisons, il est sans doute préférable de commencer par les diagrammes d'activités, et de réserver les diagrammes d'interaction à la fin de l'analyse ou à la conception technique.

__________________________________________________________________________Page UML 39



8.2. Diagrammes de séquence (scénarios)Le but des diagrammes de séquence:

Un diagramme de séquence représente un déroulement possible d'un cas d'utilisation.

Le scénario représente une des séquences possibles à partir de l'événement déclencheur du cas d'utilisation, et les réponses du système

on ne prétend pas construire une liste exhaustive des scénarios

Un exemple (simplifié) :un adhérent demande à s'inscrire à une activité supplémentaire

8.2.1. Premiers concepts et construction

Acteur extérieur et événement déclencheurun scénario est généralement déclenché par un acteur extérieur (voir les cas d’utilisation);il peut faire intervenir d'autres acteurs pendant son déroulementil peut se terminer par un envoi de réponse (ou plusieurs) aux acteurs

Instances d’objets=> un scénario représente des occurences d’objets, pas des classes=> une même classe peut être représentée par plusieurs instances

Evénements (ou messages)l’acteur et les objets communiquent par une succession de messages

Opérationl'arrivée d'un message vers une instance d'objet déclenche une opération

Chronologiele diagramme de séquence présente les événements dans leur ordre d’apparition.

__________________________________________________________________________Page UML 40



Structures de contrôle

Les “ structure de contrôle ”: alternative: if... then... else... endif

répétititve: while... do... enddo

et toutes les structures équivalentes

Exemples de méthodes pour représenter des conditions ou des branchements:(seulement si c’est nécessaire à la bonne compréhension du modèle)

une alternative (condition)

exemplel'adhérent veut s'inscrire à une activitéselon qu'il y a de la place disponible ou non, la suite est différente

UML 2 propose d'utiliser des "cadres d'interaction" pour faire ressortir ainsi les choix (appelés "alt" pour alternative) et les boucles (loop)

une répétitive (boucle)

envoyer une convocation à chaque adhérent pqui participe à l’activité

noter la représentation de plusieurs instances d’Adhérent

Valeurs retournéeson peut distinguer les questions (par ex. "demande de participation") par un trait continuet les réponses (par ex. "demande acceptée") par un trait pointillé

ContraintesDans tous les modèles, une contrainte se représente par un texte {entre accolades} ou [entre crochets]

__________________________________________________________________________Page UML 41



8.2.2. Passage des messages aux opérations

Définition des opérations

Pour exploiter les diagrammes de séquence, il faut définir les opérations déclenchées sur chaque classe dans le cas le plus simple, il s'agit de remplacer les messages par les opérations

déclenchées par ces messages et de distinguer les messages déclencheurs d'opérations des messages retournés en résultat

Paramètres des opérations et valeur retournée

Les paramètres décrivant l’événement peuvent être portés sur le diagramme

Le nom et/ou la valeur du message en retour peuvent être ajoutés à l’événement envoyé.

Retour sur le polymorphisme

un événement peut comporter différentes séries de paramètres :

par ex. une demande d’adhésion1. avec nom, adresse2. avec nom, adresse, date de naissance, chèque joint3. etc.

__________________________________________________________________________Page UML 42



8.2.2.1. Enrichissement du diagrammes de classes

Une fois les opérations définies, l'enrichissement du diagramme de classes consiste à reporter dans chaque classe les opérations définies trouver les attributs nécessaires à l'exécution de ces opérations valider le résultat, du point de vue des classes et non plus des scénarios

Notation dans le diagramme de classes

le détail d'une opération (appelé sa signature) peut comporter

- les arguments attendus et le type de la valeur retournéepar exempleajouter(terme1: réel, terme2: réel) : réel

- les valeurs par défaut des argumentspar exempledessiner(CouleurFond: couleur = blanc, CouleurTrait: couleur = noir)

: booléen=> permet des appels à la même méthode avec un nombre variable d’arguments.

8.2.3. Naissance et disparition d’un objet

le diagramme peut représenter la durée de vie de l’objet (du début d’une ligne verticale à sa fin)

l’arrivée du paiement de l’adhérent provoque

- la création d’une instance de paiement

- la suppression de l’appel de cotisation correspondant

__________________________________________________________________________Page UML 43

Une classe avec l'affichage des opérations et de leur signature



8.2.4. Documentation des opérations

Les diagrammes de séquence ne donnent que le squelette d’une séquence d’opérations, il faut documenter chaque opération.

Forme da la documentation:

- un commentaire attaché au scénario

- ou un commentaire attaché à l'opération dans le diagramme de classes

l'AGL peut créer la documentation du code généré à partir de ce commentaire

- ou le pseudo-code de l'opération

- ou un diagramme d'activités

__________________________________________________________________________Page UML 44



8.3. Diagrammes de collaboration

Diagrammes de séquence et diagrammes de collaboration sont équivalents:les deux types de diagrammes représentent la même information.

Les diagrammes de collaboration, comme les diagrammes de séquence,

- se basent sur la représentation des instances d’objets (les diagrammes d’instances)- et représentent les évenements ou messages entre ces objets.

un scénario peut être facilement transformé en diagramme de collaboration

un diagramme de collaboration montre le flot des messages entre les instances d’objets

plusieurs messages peuvent figurer sur un lien entre deux objets

RemarquesReprésentation de la chronologiece n’est en principe pas le but du diagramme de collaboration.Cependant une notation est prévue (à consommer avec modération : on préférera pour cela les diagrammes de séquence )

Représentation générale des contraintesUne contrainte peut être représentée par un texte libre entre accolades, comme dans les autres modèles

Création et destruction d’instances d’objets:la création ou la destruction d’une nouvelle instance d’objet est notée comme une contrainte

__________________________________________________________________________Page UML 45




Jusqu'à quel niveau détailler les scénarios?

Faire des variantes d'un scénario, ou utiliser les structures de contrôle (si… sinon…) dans un scénario unique?

Comment montrer l'appel d'un scénario par un autre?

8.4.1. "bons" et "mauvais" scénarios

Il y a plusieurs façons de traiter le même cas d'utilisation

Le but: fabriquer des objets utilisables

Exempleenregistrement d'une demande d'adhésion

placer les opérations sur les bons objets

il y a probablement des diagrammes plus justes que d’autres

__________________________________________________________________________Page UML 46

ou : adhérent

: Club : Adherent

1: demande d'adhésion

2: recherche prochain numéro

3: créer

4: numéro attribué

: adhérent

: Adherent

1: créer

3: numéro attribué

2: affecter numéro



8.4.2. Comparaison de deux solutions plus globales

un scénario “ centralisateur ”

un scénario “ décentralisateur ”

__________________________________________________________________________Page UML 47



9. Les diagrammes états - transitions

9.1. Premiers concepts et construction

Définition: le modèle dynamique représente les modifications des objets dans le temps

Un diagramme appartient à une classe et une seule définit les états possibles pour les instances de la classe

le diagramme peut représenter aussi les interactions entre les objets de classes différentes.

Concepts utilisés

Etat: configuration d'un objet, conditionnant le type de réponse de l'objet à un certain événement

exemples

actif

résilié

résiliation

- demander la fermeture d'une fenêtre, selon que son contenu a été

modifié ou non- renouveler l'adhésion d'un membre du club à l'échéance annuelle, selon qu'il est membre actif ou résilié

la matérialisation d'un état: la valeur d'un attribut, ou d'un ensemble d'attributs, la présence ou le contenu d'une association

Transition: passage d'un état à un autre

Evénement: modification intervenue dans l'environnement et que l'objet doit prendre en compte L'événement déclenche la transition

durée:un événement est "instantané"un état est durable; en fait permanent jusqu'à l'arrivée d'un nouvel événement.

__________________________________________________________________________Page UML 48

Un état

Une transition

Un événement



demande d'adhésion actif

Création d'une instance

résilié

clôture exercice

Suppression d'une instance

__________________________________________________________________________Page UML 49



9.2. La logique et la signification du diagramme d'états

un exemple: les états possibles d'un adhérent

noter: les transitions sont orientées

(des flèches, non de simples traits): ce n'est pas parce que la transition est possible dans un sens qu'elle l'est dans l'autre

un diagramme d'états ne définit pas une séquence unique il peut y avoir des boucles, plusieurs circuits, plusieurs points de création et / ou

suppression des instances il n'y a pas toujours des points de création et / ou suppression des instances

un diagramme d'états représente tous les états possibles des instances de la classe toutes les instances ne passeront pas par tous les états

__________________________________________________________________________Page UML 50



9.3. Quelques éléments de modélisation complémentaires9.3.1. Sous-états

A l'intérieur d'un état, l'objet peut être dans deux ou plusieurs sous-états

le super-état définit une partie du comportement

le sous-état précise ce comportement

La transition peut se faire de ou vers le super-état, ou bien de ou vers le sous-état

9.3.2. Condition sur une transition

Un même événement peut déclencher deux transitions différentes en fonction d'une condition la condition est notée sur la transition (transition gardée)

9.3.3. Transition sans changement d'état

Si cela éclaire l'analyse, on peut noter des transitions d'un état vers lui-même

dehors à la troisième faute:

__________________________________________________________________________Page UML 51

surle terrain sur la touche

faute[ moins de 3 ]

faute[ troisième ]



9.4. Enrichissement du diagramme de classes

Conséquence des états sur la définition des opérationsdeux états deux comportements une condition dans la définition d'une opération

Conséquence sur la définition des attributsl'état doit être matérialisé:- plage de valeurs d'un attribut- combinaison d'attributs- valeur d'une association- code état

9.5. Rôle et place des diagrammes d'états

Quels diagrammes d'états faut-il faire?- en théorie, les objets de toutes les classes possèdent des états- en pratique seules les classes où au moins 3 états sont identifiables méritent un diagramme

Quand faire les diagrammes d'états?

les diagrammes d'états ont un rôle de validation:- ils peuvent être discutés avec les utilisateurs (pour les objets que ces derniers connaissent)- ils servent au moins à vérifier l'exhaustivité et la cohérence de l'analyse

ils peuvent avoir un rôle de découverte et de structuration:certains objets ont des états connus des utilisateurs, états qui servent même à organiser le travail (le "workflow"); par ex. les états successifs d'une facture, pour un processus de facturation et d'encaissement modéliser ces états tôt dans l'analyse le diagramme d'états peut servir à structurer le reste de l'analyse

__________________________________________________________________________Page UML 52




Jusqu'où aller dans la modélisation des états?il y a beaucoup de choses qui peuvent être représentées dans un diagramme d'état se limiter à ce qui est nécessaire pour le but recherché et à ce qui est compréhensible de tous

Pas (ou pas toujours ) de "code état" pour représenter les états d'un objet

Limite entre les états et l'héritage:le même objet dans deux états, ou deux sous-classes de la même classe?par ex. - bon client / client douteux : deux états ou deux sous-classes avec des règles de

gestion différentes ?- et gros domestique / client étranger?

L'héritage du diagramme d'états n'est pas automatiqueles états des objets de la sous-classe ne sont pas forcément ceux de la super-classe

les états sont implémentés dabs les opérations,et, dans l'implémentation, les objets de la sous-classe héritent des opérations de la super-classe, sauf si on les surcharge en pratique, les états sont hérités par défaut

__________________________________________________________________________Page UML 53



10. Diagramme de packages

Les packages servent à regrouper les éléments par famille quand le projet grossit

- regrouper les cas d'utilisationpar exemple les regrouper selon l'utilisateur principal concerné, ou par domaine

- regrouper les classes par problème traitévoir l'usage des packages dans le JDK de java

Exemple

les packages sont le plus souvent hiérarchisés:ici

logistiquelogistique.stocks

les packages dépendent d'autres packages (ils utilisent les éléments définis dans d'autres packages

ici stocks utilise fournisseurs

__________________________________________________________________________Page UML 54



11. Récapitulation

On essaie ici de récapituler l'utilisation d'UML dans chaque phase du projetCeci est largement une question d'opinion personnelleCeci dépend aussi beaucoup de la nature du projet

Dans la définition des besoins et l'étude préalable

Définition des besoins

UML intervient peu à ce stadeson rôle se limite la plupart du temps au diagramme de cas d'utilisation

on peut aussi utiliser un outil pour répertorier les besoins une feuille de tableur suffira la plupart du temps pour lister les besoins, leur statut actuel, la référence des documents de descriptionil existe aussi des outils spécialisés (par exempleRequisite Pro de Rational)

Etude préalable:

- définition du domaine (définition du périmètre du projet)- étude de faisabilité et/ou d'opportunité

on peut utiliser pour cette étape un diagramme de contexte pour dessiner le périmètre du projet

UML dans la conception technique générale

on précise dans cette étape les choix techniques (langages, modes de stockage…)

on définit l'implantation physique dans un diagramme de déploiement

on peut montrer le découpage en domaines par des diagrammes de packages (packages de cas d'utilisations et/ou packages de classes)

lorsqu'on utilisera des standards (frameworks d'objets, modèles de conception –design patterns-, conceptions génériques du 2 tracks process…) on pourra utiliser des diagrammes (de classes, d'activité, de séquence…) pour présenter ces standards; on rentre là dans l'utilisation avancée d'UML

__________________________________________________________________________Page UML 55



UML dans l'analyse métier

Avant d'entrer dans le détail de la démarche d'analyse avec UML, on va prendre une vue générale des modèles utilisés pour l'analyse des phases de l'analyse et de l'enchaînement entre ces modèles à l'intérieur d'une phase

Les diagrammes que l'on utilisera le plus souvent serontle diagramme de classes, impérativement, pour définir les classesle diagramme de use cases et la documentation des use casesles diagrammes d'activité et/ou les diagrammes de séquenceles diagrammes d'états

Les phases de l'analyse

L'analyse est en général un processus itératif; ceci est particulièrement vrai en conception objet et avec UML:L'analyse centrée sur l'élaboration et l'enrichissement progressif d'un diagramme de classes, qui synthétise l'essentiel du dossier d'analyse

Dans un cycle d'analyse simple (un petit projet) on distinguera probablement trois étapes:

__________________________________________________________________________Page UML 56



L'initialisation de l'analyse

Quand?lorsque les objectifs sont clairs- les besoins fonctionnels sont répertoriés- le périmètre du projet est défini

et lorsque la phase d'étude de faisabilité / d'opportunité apparaît terminée:le projet est réalisable (dans les enveloppes de temps et de budget) et rentable

Quoi?donner une première description des fonctionnalités prévueset des objets qui y concourront

Comment?en définissant les cas d'utilisationéventuellement en décrivant ces cas dans des diagrammes d'activitésen recherchant les classes métier possibles (ébauche du diagramme de classes)

Les itérations d'analyse

Quand?lorsque la phase d'initialisation apparaît terminée:- on ne découvre plus de nouveaux use casesles use cases sont compris et décrits (textuellement, ou par des diagrammes d'activité, etc.)

Quoi?définir la responsabilité et le contenu de chaque classe (opérations, attributs)à travers la réalisation de chaque use case sous la forme d'un scénario

Comment?Dans une approche formalisée (type méthode Unified Process)- prendre un à un tous les cas d'utilisation

pour chaque cas d'utilisation:- dessiner un diagramme d'activité (si le cas est complexe, comporte des variantes, etc.) et/ou des diagrammes de séquences (un par enchaînement possible)

- prendre une à une toutes les classespour chaque classe qui semble posséder plus de 2 états: - définir le diagramme d'états- vérifier que les opérations définies (probablement dans les diagrammes de séquences) implémentent bien toutes les transitions figurant sur le diagramme d'états

__________________________________________________________________________Page UML 57



Dans les approches agileson codera directement à partir des squelettes de classes, en croisant les doigts,ou bien- on définira les responsabilités des objets- on fera si nécessaire une maquette d'architecture- on choisira une solution d'implémentation (si possible un design pattern éprouvé)ceci sera abordé dans le cours UML avancé

Dans notre approche intermédiaire - choisir les use cases à analyser en priorité- construire les diagrammes de séquence (scénarios) pour - décrire la réalisation de ces use cases- enrichir le diagramme de classes à partir des scénarios

La finalisation de l'analyseQuand?lorsque le cycle d'analyse apparaît terminée:

Quoi?vérifier la cohérence de l'analysecompléter la définition des classes et des associationsdéfinir les relations d'héritagecompléter la documentation du dossier

Comment?pas de nouveaux diagrammesmais une révision générale

Cohérence entre les diagrammes

Principe de la cohérence: - les modèles dynamiques doivent reprendre les cascades d’événements définies dans les scénarios.

- la spécification des opérations doit être cohérente avec les contraintes découlant du diagramme d’états

- les états doivent être décrits par les attributs des objets (ou leurs associations, ou les attributs de leurs objets associés)

Vérifications:

- amont: où sont générés les événements qui provoquent les transitions décrites dans le modèle en cours d’examen?

__________________________________________________________________________Page UML 58



- aval: les événements émis par le modèle à destination d’autres objets sont-ils repris dans le modèle dynamique des objets concernés?

Cohérence entre diagrammes de séquence et diagrammes d'états

Représentent deux vues de la vie des objets doivent s'appuyer sur la même logique, le même enchaînement

Les événements des diagrammes d'états doivent se retrouver dans les diagrammes de séquences

Les conditions posées au déroulement des opérations dans les diagrammes d'états doivent se retrouver dans la documentation des opérations

exemple

UML dans la conception technique détaillée et la réalisation

Dans la conception technique détaillée, on établit le diagramme de classes finalisé

On peut l'établir en ajoutant des détails au modèle d'analyse, avant de générer les squelettes de classesOn peut aussi l'établir par rétro-conception à partir du code, pendant l'implémentationCertains outils permettent de synchroniser automatiquement le code que l'on développe et le diagramme que l'on enrichit.

__________________________________________________________________________Page UML 59

analyse et modélisation objetenjoythepunk.free.fr/docs/itin/cours/uml/cours/analyse... · web...

Documents