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

Présentation au sujet: "Modélisation et Construction d’un Système d’Information"— Transcription de la présentation:

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

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

3 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

4 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 !!!

5 Introduction Les diagrammes

6 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

7 Diagramme de classes Concepts fondamentaux Classe

8 Diagramme de classes Commentaires

9 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}

10 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é

11 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}

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

13 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.)

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

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

16 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

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

18 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

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

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

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

22 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

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

24 Diagramme de classes Concrétisation = héritage

25 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 :

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

27 Diagramme de classes Des dépendances

28 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

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

30 Diagramme de classes Implémentation équivalente à :

31 Diagramme de classes Association n-aire

32 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.)

33 Diagramme de classes Exemples : soit le diagramme de classes

34 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))

35 Diagramme de classes Contraintes entre associations

36 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

37 Diagramme de classes Exemples

38 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

39 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

40 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

41 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

42 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

43 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

44 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.

45 Diagramme de classes

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

47 Diagramme d’objets

48 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

49 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

50 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

51 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.)

52 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

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

54 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

55 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

56 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

57 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.)

58 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

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

60 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

61 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)

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

63 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

64 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

65 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

66 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 »

67 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 !

68 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 !!!

69 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

70 Diagramme d’activités

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

72 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

73 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!

74 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.

75 Diagramme de séquence

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

77 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)

78 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

79 Diagramme de communication

80 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

81 Diagramme de composants

82 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

83 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

84 Diagramme de déploiement

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

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