Modélisation et Construction d’un Système d’Information UML 2.0

Bibliographie [005.117FOW] [005.117VAL] « UML 2.0 », Martin FOWLER, ed. Campus Press [005.117VAL] « UML pour les débutants », Franck VALLEE, ed. Eyrolles

Introduction Bref historique UML proposée en 1995 par BOOCH, RUMBAUGH et JACOBSON L’OMG adopte UML 1.1 en 1997 UML 2.0 déposée à l’OMG en 2003

Introduction Spécifier Concevoir Construire Documenter Caractéristiques d’UML C’est un langage avec des notations graphiques pour: Spécifier Concevoir Construire Documenter Ce n’est pas une méthode ou un processus C’est un standard stable (OMG) Facilite l’utilisation d’outils d’aide à la modélisation Ne résoud pas tous les problèmes !!!

Introduction Les diagrammes

Diagramme de classes Diagramme centrale du modèle du SI Montre les classes et leurs relations statiques Le plus riche en notations Équivalent du modèle E-A Les erreurs dans ce diagramme ont souvent un impact sur les autres diagrammes

Diagramme de classes Concepts fondamentaux Classe

Diagramme de classes Commentaires

Diagramme de classes Attributs Visibilité nom:type multiplicité=valDefaut {contrainte} Visibilité : + public, - privé, # protégé Nom : eq. nom d’un champ Type : eq. type d’un champ Multiplicité : indique la nature du champ ([0..1] pointeur, [1] valeur, [x..*] conteneur) valDefaut : valeur par défaut… Contrainte : information supplémentaire sur l’attribut Exemple : -insee:string[1]="" {readOnly}

Diagramme de classes Multiplicité Équivalent aux cardinalités du modèle E-A Attention au sens de lecture! 0..x : optionnel 1 : unique et obligatoire x..* : multiple A..B : borné

Diagramme de classes Opérations Visibilité nom(liste param):type_retour{propriété} Liste param : chaque paramètre peut être détaillé comme un attribut On ne modélise que les opérations qui correspondent à des responsabilités particulières de la classe (pas d’accesseurs, etc.) Exemple : +fact(n:int):int {récursive}

Diagramme de classes Représentation détaillée (conception)

Diagramme de classes Associations unidirectionnelles Permet de représenter les attributs dont le type est une classe du problème Supporte les mêmes informations qu’un attribut (cardinalités, visibilité, contraintes, etc.)

Diagramme de classes Associations bidirectionnelles Lien structurel fort Nécessite la synchronisation des deux classes Ou bien

Diagramme de classes Possibilité de ne nommer que l’association Utilisation d’un verbe accompagné d’un sens de lecture

Diagramme de classes Composition Exprime « une partie de » Une classe composant peut faire l’objet de plusieurs compositions Un objet de la classe composant ne peut appartenir qu’à un seul objet d’un composé Cycles interdits! Durées de vie identiques (destructions synchronisées) La « navigabilité » peut être bidirectionnelle ou non

Diagramme de classes Agrégation Sémantique identique à la composition Le partage des objets composants est autorisé Durées de vie différentes

Diagramme de classes Identification d’une composition (ou agrégation) Assemblage-parties Collection-membres Contenant-contenu Modéliser autant que possible les compositions/agrégations Augmente la lisibilité du modèle Simplifie l’implémentation

Diagramme de classes Généralisation = héritage

Diagramme de classes Attention à ne pas confondre héritage et instanciation NON!

Diagramme de classes Concepts avancés Attributs et opérations statiques Correspondent aux membres static en C++ ou Java Indiqué par un souligné

Diagramme de classes Classes utilitaires Structuration des variables (et constantes) globales Représentées par des classes stéréotypées Les données membres sont statiques

Diagramme de classes Opérations et classes abstraites Notés en italique Les classes abstraites ont les mêmes relations que les autres classes

Diagramme de classes Concrétisation = héritage

Diagramme de classes Interfaces « Sorte » de classe définie exclusivement par des fonctions abstraites Sert à l’implémentation d’autres classes et non à leur structure Deux notations :

Diagramme de classes Une interface ne peut avoir d’association Elle peut avoir: Des implémentations

Diagramme de classes Des dépendances

Diagramme de classes Association qualifiée Assimilable à une table associative Le qualificateur (ex: produit) permet d’identifier 0 ou une ligne de la commande Pour manipuler (ajouter, consulter, etc.) une ligne d’une commande, il faut obligatoirement un produit

Diagramme de classes Classes-associations Permet d’ajouter des attributs, des opérations, etc. sur des liens

Diagramme de classes Implémentation équivalente à :

Diagramme de classes Association n-aire

Diagramme de classes Contraintes Information supplémentaire sur un élément Placée entre accolade Peut être un texte en langage naturel Ou bien OCL (Object Constraint Language) Repose sur la logique propositionnelle Évite les ambiguïtés du langage naturel Il existe des outils pour OCL Permet de décrire les pré et post-conditions, ainsi que les invariants sur un élément du modèle (attribut, rôle, opération, etc.)

Diagramme de classes Exemples : soit le diagramme de classes

Diagramme de classes On peut exprimer les contraintes : // Jamais de treizième étage context Chambre inv:  self.étage <> 13 // Pas plus de résidents que de lits sauf s’il y a un enfant de moins de 4 ans context Chambre inv:  lesRésidents->size <= nbLits or  (lesRésidents>size = nbLits + 1 and   lesRésidents->exists(p : Personne | p.âge < 4))

Diagramme de classes Contraintes entre associations

Diagramme de classes Contraintes de l’héritage {incomplete} : les classes dérivées ne couvrent pas toute la classe de base {complete} : les classes dérivées couvrent toutes les possibilités de la classe de base {disjoint} : les classes dérivées sont disjointes donc pas d’héritage multiple {overlapping} : l’héritage multiple est possible

Diagramme de classes Exemples

Diagramme de classes Dépendances Relation sémantique mais non structurelle La modification de la cible peut avoir des répercussions sur la source À éviter en analyse car faible intérêt sémantique

Diagramme de classes Plusieurs stéréotypes : « call » : la source appelle une opération de la cible « create » : la source crée une instance de la cible « permit » : le source est amie de la cible « use » : la source a besoin de la cible pour être implémentée

Diagramme de classes Classe paramétrable Le type d’un champ est un paramètre de la classe Doit être liée (bind) avec une classe qui instancie le paramètre

Diagramme de classes Attributs dérivés Attribut dont la valeur est calculée à partir d’autres attributs Souvent associé à une contrainte qui donne la règle de calcul

Diagramme de classes Quelques anomalies Classes sans relations Classes sans attribut Classes sans opérations Relation 1-1 Pas forcément à supprimer, mais toujours se poser la question

Diagramme de classes La pratique Ne pas utiliser systématiquement toutes les notations En phase d’analyse : concepts fondamentaux En phase de conception/implémentation : concepts avancés Bien utiliser UML ne veut pas dire bien modéliser! La théorie ne remplace pas l’expérience Les design pattern peuvent améliorer le modèle de conception

Diagramme de classes Exemple : Un contrat d’édition est un accord entre un auteur (éventuellement collectif) et un éditeur. Les conditions générales d’un contrat sont stipulées dans un contrat type. Les clauses particulières sont ajoutées au contrat. Le contrat ne concerne qu’un ouvrage, qui ne peut être édité chez un autre éditeur.

Diagramme de classes

Diagramme d’objets Montre les objets et leurs relations L’état des objets est indiqué Utile lorsque les structures de classe sont complexes

Diagramme d’objets

Diagramme de paquets Paquet = regroupement d’éléments Paquet de classes, de cas d’utilisation, de paquets, etc. Parfois appelé paquetage, ou package Renforce la modularité et la cohérence du modèle global Un élément ne peut appartenir qu’à un seul paquet

Diagramme de paquets Diagramme de paquet = dépendances entre les paquets Un paquet A dépend d’un paquet B si au moins un élément de A dépend d’un élément de B La modification du paquet utilisé peut entraîner la modification du paquet utilisateur  mises à jour synchronisées

Diagramme de paquets Intérêts: Conserver une vue synthétique Plus d’une douzaine d’éléments dans un diagramme  décomposition en paquets = découpage ascendant Organiser l’analyse d’un problème Montrer les parties (paquets) cohérentes Chaque partie est ensuite raffinée = découpage descendant

Diagramme de paquets Isoler des parties réutilisables Contribue à la vue architecturale Les paquets représentent les couches logicielles Ont parfois une traduction directe dans les LOO (package en JAVA, espace de noms en C++, etc.)

Diagramme de paquets Décomposer n’est pas simple Conserver la logique métier Les structures d’un modèle guident la décomposition. Par exemple: Un arbre d’héritage Une arborescence de composition de classes

Diagramme de paquets Éviter les dépendances circulaires  couplage fort entre les paquets

Diagramme de transitions d’états Montre l’évolution du comportement d’un objet Un diagramme de T.E. par classe Le fonctionnement de certaines opérations dépend de l’état de l’objet

Diagramme de transitions d’états Un état représente une situation caractéristique d’un objet à laquelle correspond un comportement donné Nom État initial État final

Diagramme de transitions d’états Action Opération atomique instantanée non interruptible Peut être associé à l'entrée ou à la sortie d'un état Transition interne Identique à une auto-transition (voir ci-après) Ne déclenche pas les actions « entry » et « exit » État entry: Action exit : Action Transition interne

Diagramme de transitions d’états Une transition est provoquée par un événement (une opération) La durée d’une transition est considérée comme nulle donc non interruptible 4 catégories d'événements Les appels d'opérations Les signaux (clic de souris, etc.) Les conditions (quand x>10) Les délais (après 5 sec.)

Diagramme de transitions d’états L’étiquette d’une transition est composée de: un événement = opération qui provoque la transition une condition = indique s’il faut accepter la transition ou pas une action = fonction non interruptible exécutée au moment de la transition Les "auto-transitions" sont possibles Utiles pour répéter les actions associées [Cond]Evénement/Action

Diagramme de transitions d’états Exemple : alarme de voiture

Diagramme de transitions d’états Super état État A B Disjoints Parallèle Un seul sous-état est actif Tous les sous-états sont actifs A et B peuvent être des super états

Diagramme de transitions d’états État historique Lorsqu’une transition s’arrête à la frontière d’un super état, l’objet revient dans le dernier sous-état considéré Pseudo-état historique : indique l’état lors de la première transition (lorsqu’il n’y avait pas d’historique)

Diagramme de transitions d’états Exemple Pseudo-état historique

Diagramme de cas d’utilisation Donne une vue externe du comportement du système Décomposition du système en termes de cas d’utilisation et d’acteurs Utile pour inventorier les fonctionnalités du système

Diagramme de cas d’utilisation Acteur Ne fait pas partie du système Quelqu’un ou quelque chose qui interagit avec le système En relation avec au moins un cas d’utilisation Un acteur peut jouer plusieurs rôles Cas d’utilisation Représente une fonctionnalité du système

Diagramme de cas d’utilisation Relation « Communique » Relation non directionnelle entre un acteur et un cas d’utilisation Exprime les fonctionnalités primaires du système

Diagramme de cas d’utilisation Relation « Utilise » Le comportement de B est inclus dans le comportement de A La fonctionnalité B est nécessaire pour réaliser la fonctionnalité A Permet d’exprimer une fonctionnalité commune à plusieurs fonctionnalités (factorisation) A B « uses »

Diagramme de cas d’utilisation Relation « Étend » Équivalent à l’héritage entre classes B hérite du comportement de A, et le spécialise B hérite des relations de communication décrites pour A A B « extends » Rq : certains auteurs déconseillent d’employer « uses » et « extends ». Moi aussi !

Diagramme de cas d’utilisation Description textuelle d’un cas d’utilisation : <titre> Intention générale Résumé, acteurs concerné Description détaillée Pré-conditions Scénario principal Étape 1 : description Étape 2 : description Etc. Extensions Étape 2.1 : description Étape 2.2 : description Post-conditions Contraintes non fonctionnelles Exigences de persistance Exigences d’IHM Exigences de performances Les descriptions textuelles sont plus utiles que les diagrammes !!!

Diagramme d’activités Logique procédurale, enchaînement des activités (flot) Concepts principaux: Activité : peut correspondre à un message ou un cas d’utilisation selon le niveau de détail Arc : matérialise le flot Débranchement : séparation d’un flot en flots parallèles Jonction : synchronisation de flots parallèles Décision : aiguillage conditionnel du flot Fusion : marque la fin d’un comportement conditionnel

Diagramme d’activités

Diagramme d’activités Partition : montre qui est responsable de quelle activité

Diagramme d’activités Les signaux La réception d’un signal déclenche une activité Lors du déroulement d’un flot, un signal peut être émis Un délai est un signal émis automatiquement

Diagramme de séquence Montre la collaboration des objets impliqués dans un cas d’utilisation Insiste sur la chronologie Permet de décrire le scénario principal et ses extensions Attention à conserver la lisibilité du diagramme!

Diagramme de séquence Concepts principaux : Les participants (le plus souvent des objets) Une ligne de vie Des zones d’activation Les messages L’opération et éventuellement ses paramètres Éventuellement son résultat Des structures de contrôle Alt : conditionnelle Loop : boucle Réf : référence à un autre diagramme de séquence (=appel de fonction) Etc.

Diagramme de séquence

Diagramme de séquence Création et destruction de participants

Diagramme de communication Idem diagramme de séquence Insiste sur les relations entre les objets Permet de montrer un scénario particulier Chronologie indiquée par la numérotation des messages Possibilité de faire apparaître des boucle, des conditions (à éviter)

Diagramme de communication Les objets Pas de ligne de vie associé à d'autres objets La nature de l'association est décrite par un stéréotype « association » : l'objet est un attribut « global » : l'objet est une variable globale « local » : l'objet est une variable locale « paramètre » : l'objet est un paramètre d'un message Les messages Un message ne peut être envoyé que si une association existe

Diagramme de communication

Diagramme de composants Montre la répartition physique du code Souvent répartis dans des packages Les relations s’expriment à travers leurs interfaces et des dépendances

Diagramme de composants

Diagramme de composants Minimiser les dépendances augmente la réutilisabilité Des dépendances hiérarchiques facilitent le développement Les feuilles peuvent être développées en parallèle Permet de déduire le makefile

Diagramme de déploiement Montre la répartition des processus qui composent le système Important dans le cas d’architecture distribuée Concepts fondamentaux: Les nœuds : dispositifs capables d’héberger une partie du logiciel Les arcs : liens physiques connectant les noeuds

Diagramme de déploiement

Diagramme de timing Montre l’évolution de l’état d’un objet ou d’un groupe d’objets en fonction d’évènements temporels

Diagramme de vue d’ensemble des interactions Mélange du diagramme d’activités et du diagramme de séquence