La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.

Présentations similaires


Présentation au sujet: "1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005."— Transcription de la présentation:

1 1

2 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année

3 3 Plan de la première partie Les méthodes danalyse de 1960 à Les méthodes Objet 9 UML : généralités16 Les diagrammes d UML17 Les mécanismes communs19 Les diagrammes de classes31 Les diagrammes d objets61

4 4 Booch Unified Method 0.8 etc... OOSE (Jacobson et al.) UML etc. ROOM Catalysis OMG UML 1.1 Nov UML 1.3 UML 1.4 UML 2.0 Juin 1999 Fin 2001 … HOOD OMT (Rumbaugh et al.) 1995 Rational ROOM Classe-Relation Fusion OOSE Booch OMT Fin 1990

5 5 Méthodes d analyse (60-80) MERISE (1962) PETRI (1962) HIPO (1970) SD (1974) Idef-0 (1974) LCS (1974) HDM (1979) SADT (1976) SA (1978) E-R (1976) SDS (1977) HOS (1975) MACH (1980) DREAM (1978) SARA (1978) IA-NIAM (1975)

6 6 Méthodes danalyse (60-80) HIPO : Hierarchy plus Input Process Output (IBM/USA). PETRI : les réseaux de Petri ; outil pour la synchronisation (Allemagne) LCS : Lois de Construction de Systèmes (Warnier - France). SD : Structured Design (IBM : Stevens, Myer, Constantine, USA). Idef-0 : Icam definition-0 (DoD, US air force) IA-NIAM : Niijsen Information Analysis Methodologie, modèle relationnel binaire (Pays Bas). E-R : Entity-Relationship model (P. Chen, USA). SADT : Structured Analysis Design Technique (D.T. Ross, USA). SA : Structured Analysis (F. Yourdon, T. Demarco, USA). MERISE : méthode mise au point dans le cadre du ministère de l'industrie (Tardieu, Rochfeld...)

7 7 Méthodes d analyse (80-90) HOOD (1987) OOD-86 (1986) SA-RT-2 (1986) OOA (C&Y) (1989) TOCATTA (1987) MASCOT3 (1986) STATEMATE1 (1987) MACH-2 (1987) JSD (1981) SASD (1981) MAIA (1984) OOD-83 (1983) SA-RT-1 (1984) CORE (1983) AXIAL (1984) SSADM (1982)

8 8 Méthodes danalyse (80-90) JSD : Jackson System Development (Michael Jackson, USA). SASD : Structured Analysis and Structured Design (L. Constantine, USA). SSADM : Structured Systems Analysis and Design Method (UK) OOD-83 : Object Oriented Design (G. Booch, USA). SA-RT-1 : Structured Analysis Real Time (P. Ward, S. Mellor, USA). AXIAL : (P. Pellaumail, IBM-France) OOA : Object Oriented Analysis (P. Coad, E. Yourdon, USA). SA-RT-2 : Structured Analysis Real Time (D. Hatley, I. Pirbaï, USA). HOOD : Hierarchical Object Oriented Design (Agence spatiale européenne). TOCCATA : Techniques d'Organisation de la Conception par Comportements Abstraits et Types Abstraits (CGE Alsthom, France).

9 9 Les méthodes objet OBJECTORY (1992) FUSION (1994) CLASSE RELATION (1991) OOA(S&M) (1991) OMT (1991) G. BOOCH (1991) OOM (1991) OBJETS NATURELS (1991) MERISE 2 (1993) EURO METHODE UML MERISE Actuellement ? UML 2

10 10 Les méthodes objet (1)

11 11 Les méthodes objet (2)

12 12 Les méthodes objet (3)

13 13 UML : Unified Modeling Language octobre 94 : Grady Booch (Méthode Booch) et James Rumbaugh (OMT) commencent à unifier leurs 2 méthodes. --> Unified Method 0.8 fin 1995 : Ivar Jacobson introduit certains concepts de sa méthode (OOSE) Langage de modélisation unifié avec pour objectifs de : - ne plus faire évoluer les méthodes de manière indépendante les unes des autres, - unifier la sémantique et les notations et amener ainsi une stabilité sur le marché "orienté-objet " - rassembler leurs efforts pour résoudre des problèmes qu'aucune des trois méthodes ne peut bien résoudre.

14 14 UML : Unified Modeling Language octobre 1996 : UML 0.9 (Unified Modeling Language) diffusion au sein de la "communauté informatique" et intégration des remarques. 16 janvier 1997 : le document UML a été soumis à l'OMG (Object Management Group).. 14 novembre 1997 : adoption d'UML 1.1 comme standard par l'OMG. Novembre 1998 : UML : UML : UML 2 Sites officiels :

15 15 Bibliographie Modélisation objet avec UML Pierre-Alain Muller, Eyrolles 1997, Eyrolles 2000 Pierre-Alain Muller, Nathalie Gaertner, Eyrolles 2003 Intégrer UML dans vos projets N. Lopez, J. Migueis, E. Pichon, Eyrolles 1997 UML pour l'analyse d'un système d'information Chantal Morley, Jean Hugues, Bernard Leblanc, Dunod 2000 Le guide de l'Utilisateur UML Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000 nouvelle version prévue pour UML 2 en mai 2005 (en anglais) Le processus unifié de développement logiciel Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000

16 16 UML : Unified Modeling Language UML propose : des éléments de modélisation qui représentent les abstractions du système en cours de modélisation des éléments de visualisation qui procurent des projections textuelles ou graphiques permettant la manipulation des éléments de modélisation

17 17 Diagrammes d UML les diagrammes de cas d'utilisation qui représentent les fonctions du système du point de vue de l'utilisateur, les diagrammes de classes qui représentent la structure statique en termes de classes et de relations, les diagrammes d'objets qui représentent les objets et leurs relations. les diagrammes d'états-transitions qui représentent le comportement des classes en termes d'états, les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets. les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.

18 18 Diagrammes d UML les diagrammes d'activités qui représentent le comportement d'une opération en termes d'actions (proches des organigrammes). les diagrammes de composants qui représentent les composants physiques d'une application. les diagrammes de déploiement qui représentent le déploiement des composants sur des dispositifs matériels.

19 19 Les mécanismes communs Sont applicables sur chaque modèle : les notes les étiquettes les contraintes les relations de dépendances les stéréotypes

20 20 Les notes Elles permettent dajouter des informations à un modèle comme des commentaires (sans contenu sémantique) mais aussi des exigences, des observations, des révisions ou des explications. Ceci est une note qui peut être reliée à tout élément de modélisation par des pointillés.

21 21 Les étiquettes Nommées également « Tagged values », elles permettent la création de nouvelles informations dans la spécification dun élément. Elles se présentent sous la forme de paires {nom, valeur} {version, 3.2} peut être ajouté sur un modèle Dans les AGL, elles sont souvent utilisées pour indiquer des propriétés relatives à la génération de code.

22 22 Les contraintes Elles permettent détendre la sémantique dun élément dUML en ajoutant de nouvelles règles ou en modifiant celles qui existent déjà. Elles sont placées entre accolades sans syntaxe particulière. { la femme d'une personne est de genre 'féminin'} { la mari d'une personne est de genre 'masculin'} Souhaits de spécialités dans l'ordre de préférence: ETUDIANT Nom : string SPECIALITE Libellé : string sesSpé * {ordonné} * 0..1 SaFemme PERSONNE -Nom -Genre SonMari 0..1

23 23 Limite des contraintes informelles PERSONNE -Nom -Genre 0..1 SaFemme SonMari 0..1 P1:PERSONNE Nom = Paul Genre = Masculin P2:PERSONNE Nom = Marie Genre =Féminin P3:PERSONNE Nom = Anne Genre =Féminin P4:PERSONNE Nom = Pierre Genre = Masculin SonMari SaFemme Il faudrait ajouter : Si une personne est mariée, lépouse du mari de cette personne est elle-même. Si une personne est mariée, lépoux de la femme de cette personne est lui-même. Besoin de contraintes formelles : OCL

24 24 Les relations de dépendances (1) Une dépendance est une relation sémantique entre deux éléments tels quun changement apporté à lun (élément source) peut affecter la sémantique de lautre (élément cible). Elle est représentée par une ligne en pointillés avec une flèche du coté de lélément cible. Elle peut être stéréotypée à l'aide d'un stéréotype standard. E1:ENSEIGNANT nom = Dupont M1:MATIERE libellé = Génie logiciel MATIERE libellé : string enseigne > * 1..* ENSEIGNANT nom : string « instantiates »

25 25 Les relations de dépendances (2) PERSONNE PROJET Participe Responsable {sous-ensemble} Une contrainte peut être associée à plusieurs éléments par une relation de dépendance * * - nom - prénom - - nom - durée - dateDébut

26 26 Les stéréotypes Ce sont des mécanismes dextensibilité, permettant aux utilisateurs dajouter de nouveaux éléments de modélisation. Les noms des stéréotypes sont mis entre « …. » Dans une définition de classe on peut préciser les constructeurs « create » et les destructeur « destroy », pour distinguer les différents types dopérations. Lorsquun stéréotype est utilisé fréquemment, on peut lui associer une notation particulière. CLIENT > CLIENT() > Détruire()

27 27 Le stéréotype paquetage (« package ») Les packages permettent de regrouper des classes, des associations et éventuellement dautres packages. On parle de PRODUIT :: Article PRODUIT ARTICLE LOCALISATION FABRICANT 1..* * 1 *

28 28 Interface (1) Une interface est un ensemble dopérations utilisées pour décrire un service d une classe. Contrairement à une classe, elle ne décrit aucune structure (elle ne peut donc pas inclure dattributs) ni aucune implémentation (elle ne peut donc pas inclure de méthodes qui fournissent limplémentation dune opération). Une interface est en général liée (liaison de réalisation) à la classe qui la réalise. Une interface est représentée par un cercle et son nom. Le nom dune interface commence généralement par un I. PERSONNE I-PERSONNE

29 29 On peut également représenter une interface par une classe stéréotypée, en indiquant les opérations qu elle fournit. Quand un objet joue un rôle spécifique, il présente un aspect particulier et les clients attendent un certain comportement. Interface (2) PERSONNE «interface» I-PERSONNE getHistoEmploi() getRémunération() getPrestation() « realize »

30 30 Le stéréotype « interface » Une interface Une classe « use » Une classe « interface » Vue A Un utilisateur X « interface » Vue B Un utilisateur Y « use » « use » caractérise une relation de dépendance « realize »

31 31 Diagrammes de classes / Diagrammes dobjets

32 32 Il existe plusieurs niveaux de notation : a) niveau sans détail PERSONNE Nom Prénom Adresse ModifierAdresse b) niveau détail d'analyse On y précise : le type des variables (integer, string, date …) les valeurs par défaut les signatures des opérations éventuellement, le niveau de visibilité : + public(accessible par tout utilisateur) par défaut - privé(accessible seulement par la classe elle-même) # protégé(accessible par les descendants) c) niveau de détail de conception Notation des classes

33 33 Attribut [ visibilité ] NomAttribut [: type] [= ] Opération [ visibilité ] NomOpération [(liste Paramètres)] [: typeRetour] Paramètre [direction] Nom : type[ = valeur par défaut] direction : in | out | inout (par défaut : in) Notation des attributs et opérations NOMDECLASSE Opération() Attributs +EstSur(in p :POINT): boolean -Longueur :integer =5 SEGMENT

34 34 Opérations / méthodes Une opération définit un service qui peut être demandé à nimporte quel objet de la classe. Une méthode est une implémentation dune opération. La méthode associée à une opération fournit un algorithme exécutable. Cet algorithme est donné dans un langage de programmation ou dans du texte structuré.

35 35 Classe-1 Classe-2 Nom dassociation rôle-1 rôle-2 PERSONNE EstEnfantDe Mère Fils PERSONNEAPPARTEMENT Loue > SonPropriétaire SesPropriétés Propose > SonLocataire SaLocation Association entre classes ^

36 36 Exactement 11 Exactement nn Plusieurs (0 ou plus)* Au plus ou plus 1..* Cardinalité spécifiée Nombre de propriétairesNombre d appartements proposés Cardinalité dune association PERSONNEAPPARTEMENT Propose > 1 *

37 37 Association : un exemple (1) Un appartement na quun propriétaire et une personne peut proposer à la location plusieurs appartements (sous-entendu, elle peut aussi ne pas proposer dappartement). Remarque : on précisera toujours les noms des rôles. Le nom de l association est facultatif. PERSONNEAPPARTEMENT Propose > 1 0..* SonPropriétaire SesPropriétés

38 38 Association : un exemple (2) PERSONNEAPPARTEMENT Propose > 1 0..* SonPropriétaire SesPropriétés -Code -Adresse -Surface -MontantLoyer APPARTEMENT a un attribut implicite SonPropriétaire : PERSONNE Un constructeur « complet » dappartement doit avoir en paramètres le Code, l Adresse, la Surface, le MontantLoyer d un nouvel appartement mais aussi une instance de la classe PERSONNE.

39 39 Un qualificatif est un attribut dont les valeurs permettent de partitionner lensemble des objets reliés par la même association à un autre objet. Il permet de réduire la multiplicité effective dune association Ex1 : à un nom de fichier dans un répertoire ne correspond qu'un fichier Les associations qualifiées (1) REPERTOIRE NomFichierFICHIER 11 1 REPERTOIRE ** 1 FICHIER NomFichier

40 40 Ex2 : dans un cabinet médical, chaque médecin peut effectuer des actes de 3 types : visite,consultation, petite chirurgie. On peut représenter le problème de 2 manières : Les associations qualifiées (2) Les actes médicaux sont rattachés au médecin par type. MEDECIN CodeType ACTE-MEDICAL MEDECIN * ACTE-MEDICAL 1 CodeType 1 *

41 41 Un attribut dérivé est un attribut calculé. Cela signifie quil peut être calculé à partir d autres informations du système à nimporte quel moment. (et non pas quil a été calculé à un moment donné). Exemple : pour une personne, lattribut Age est un attribut calculé à condition que sa DateDeNaissance ait été enregistrée. Un attribut calculé est noté /Attribut Par contre : si on met à jour une QuantitéEnStock par ajout ou suppression, sans conserver tout lhistorique des mouvements, alors QuantitéEnStock nest pas une rubrique calculée. Lattribut QuantitéEnStock est dit « modifiable » (par défaut tout attribut est « modifiable ») « gelé » (« frozen ») est réservé aux attributs qui, une fois initialisés, ne peuvent être modifiés. Attribut dérivé

42 42 Une association dérivée est une association déduite dune autre. Une association dérivée ne se justifie que pour faciliter des traitements. Association dérivée ENTREPRISESERVICEEMPLOYE SesServices SesEmployés SonService /Emploi Le nom de lassociation est précédé dun /

43 43 Contrairement à Merise, UML autorise : Une classe avec une seule instance et des attributs multivalués. Les attributs calculés (attributs dérivés) précédés par un / On précise alors, dans une note, la règle de calcul. Les associations dérivées (stéréotype « derive ») qui faciliteront un traitement. Les identificateurs explicites (identifiants) ne sont pas indispensables. Ils ne sont pas soulignés (seuls les attributs de classe sont soulignés). On peut les préciser à laide dune note. On peut représenter des « paramètres » (Merise) par le biais de variables de classe. Remarques sur les classes {identifier}

44 44 Contrairement à Merise... Exemple Emploie> ENTREPRISE -Nom -Adresse +ModifierAdresse() +AjouterPersonne() 1 PERSONNE -Nom -Prénoms -Adresse -DateDeNaissance /-Age +CréerPersonne() +GetCoordonnées() +CalculerAge 0..* SesEmployés SonEntreprise. {Age=DateCourante - DateNaissance} +AjouterPersonne(in P : PERSONNE)

45 45 C est un type particulier d association "composé-composant" ou "partie de" Agrégation (par référence) : 0..1 EQUIPE SPORT JOUEUR Un joueur peut faire partie de plusieurs équipes EQUIPE SPORT JOUEUR Agrégation-Composition SesParticipants SonEquipe * SesParticipants SesEquipes * * Un objet peut faire partie de plusieurs composites à la fois.

46 46 Agrégation-Composition La destruction du composite entraîne la destruction des composants. Un objet ne fait partie que dun seul composite à la fois. Composition (par valeur) 1 * SaCommande SesLignes COMMANDE LIGNE-COM La durée de vie dune ligne (de commande) est incluse dans celle de sa commande Commande Ligne annulée Ligne ajoutée Ligne non modifiée Temps

47 47 Exercice Réaliser un diagramme de classes permettant : de représenter un train composé dun ensemble de wagons de représenter les sièges répartis dans les différents wagons

48 48 APPARTEMENT Propose > Classe-Association (Classe associative) AGENCE 0..* LOCATION Prix : real SetPrix(P:real) GetPrix() : real AGENCE 1 LOCATION Prix : real SetPrix(P:real) GetPrix() : real APPARTEMENT 0..* 1

49 49 Elles permettent de regrouper des opérations et des attributs communs à une ou plusieurs classes données et de préciser que les classes les plus spécifiques héritent des classes les plus générales. COMPTE-BANCAIRE -Crédit : integer -Débit : integer …. +Déposer(S:integer) +Retirer(S:integer) +GetSolde() COMPTE-EPARGNE -Taux : float +CalculerIntérêts() GénéralisationSpécialisation Relations de généralisation-spécialisation

50 50 Qualité dune association qui permet le passage dune classe vers une autre. En général, on peut naviguer dans les 2 sens. On peut cependant limiter la navigabilité : Exemple : CLASSE-1 CLASSE-2 Nom dassociation Il doit être facile de passer directement dun produit à son fabriquant. La commande dun produit fait référence à l adresse de « SonRéalisateur » Il y a demande de service (GetAdresse) de PRODUIT à FABRIQUANT. Navigabilité dune association 1..* 1 SonRéalisateur SesProduits FABRIQUANT -Adresse +GetAdresse() PRODUIT -QttéRéappro +Commander()

51 51 Un attribut de classe décrit une valeur commune à une classe d'objets dans son ensemble. Une opération de classe est une opération sur la classe elle- même. La plus commune est celle destinée à créer des nouvelles instances de classe. Attributs et opérations de classe sont soulignés. (Attention : ne pas les confondre avec les identifiants de Merise.) ARTICLE -Référence -PrixHT -NbInstances +CalculerPrixTTC() +Créer() +CompterInstances() Attributs et opérations de classes

52 52 Un singleton permet de référencer linstance d une classe, unique par construction. Forme générique d une classe implémentant un singleton. L opération getInstance() est chargée de rapporter à lappelant la référence de l objet unique. Utilisation fréquente dans le cas d objets centralisateurs tels que superviseur, contrôleur, Application au design pattern singleton SINGLETON Instance : SINGLETON = null getInstance() : SINGLETON if (instance == null) instance := newSingleton() return instance; Le singleton se charge de construire lobjet lors du premier appel.

53 53 Classe et Opération abstraites / Polymorphisme Classe qui ne peut avoir aucune instance directe ; on écrit son nom en italique. Une opération abstraite ne fournit dimplémentation quau travers dune instance dune classe fille de celle qui la contient. Remarque : les noms des éléments abstraits sont écrits en italique ou préfixés par Abs. FORME -Nom : string +CalcSurface() +GetNom()

54 54 RECTANGLE - Long : float - Larg : float +CalcSurface() + Type() CERCLE - Rayon : float +CalcSurface() + Type() Opérations polymorphes Classe et Opération abstraites / Polymorphisme FORME -Couleur : string +CalcSurface() +Type() return rectanglereturn cercle return Long * Larg return PI * Rayon * Rayon

55 55 Attributs et opérations implicites (1) ETUDIANT Nom : string Pour chaque attribut on ajoute implicitement : Ces opérations ne sont pas obligatoirement publiques. SetNom peut ne pas exister. ETUDIANT Nom : string Etudiant () ~Etudiant() GetNom () : string SetNom (N:string) : bool Pour la classe on ajoute implicitement :

56 56 Attributs et opérations implicites (2) ETUDIANT Nom : string ETUDIANT Nom : string SonGroupe : GROUPE GetSonGroupe () :GROUPE SetSonGroupe(G:GROUPE) RetirerSonGroupe() … si le minimum est à 0 GROUPE Numéro : int SonGroupe 0..1 Pour chaque association navigable de cardinalité 0..1, 1..1 on ajoute : un attribut … et les opérations correspondantes

57 57 Remarque concernant la navigation ETUDIANT Nom : string GROUPE Numéro : integer SonGroupe 0..1 Pour un étudiant on peut obtenir son groupe, mais il nest pas prévu dobtenir la liste des étudiants à partir du groupe. SesEtudiants 0..*

58 58 Attributs et opérations implicites (3) ETUDIANT Nom : string ETUDIANT Nom : string SesOptions : ensemble(OPTION) AjouterOption(O:OPTION):bool RetirerOption(O:OPTION):bool GetSesOptions() : ensemble(OPTION) OPTION Libellé : string SesOptions 0..* Pour chaque association navigable de cardinalité 0..*, 1..* on ajoute : un attribut de type ensemble, … et les opérations pour gérer ce type ensemble.

59 59 Remarque concernant la navigation ETUDIANT Nom : string OPTION Libellé : string SesEtudiants SesOptions 0..* Nouvelle hypothèse : Pour un étudiant on peut obtenir ses options et on veut pouvoir obtenir la liste des étudiants à partir dune option. En ajoutant une flèche vers SesEtudiants, on ajoute implicitement SesEtudiants : ensemble (ETUDIANT) dans OPTION et les opérations correspondantes.

60 60 Attributs et opérations implicites (4) REPERTOIRE NomFichierFICHIER 11 1 Dans répertoire on trouvera une opération : Chercher (NomFichier : string) : FICHIER

61 61 Diagrammes dobjets Ils modélisent les instances déléments qui apparaissent sur les diagrammes de classe. Ils montrent un ensemble d objets et leurs relations à un moment donné. –Instances nommées –Instances anonymes –Instances avec valeurs d attributs Bouton2:RECTANGLE Longueur : float = 13.5 Nom : string = bouton-poussoir Largeur : float = 3.2 :CERCLE Bouton1:RECTANGLE NomInstance:NOMCLASSE :NOMCLASSE

62 62 MATIERE libellé : string Diagramme dobjets (exemple) E1:ENSEIGNANT nom = Dupont E2:ENSEIGNANT nom = Martin E3:ENSEIGNANT nom = Duval M3:MATIERE libellé = Système M1:MATIERE libellé = Génie logiciel M2:MATIERE libellé = Réseau enseigne > * 1..* ENSEIGNANT nom : string

63 63 MATIERE libellé : string Diagramme dobjets (nécessité de préciser lassociation) enseigne enseigne > * 1..* ENSEIGNANT nom : string 0..1 * estResponsable > E1:ENSEIGNANT nom = Dupont E2:ENSEIGNANT nom = Martin E3:ENSEIGNANT nom = Duval M3:MATIERE libellé = Système M1:MATIERE libellé = Génie logiciel M2:MATIERE libellé = Réseau

64 64

65 65

66 66 U.M.L. Unified Modeling Language (2ème partie) Françoise Schlienger 4 ème année

67 67 Plan de la deuxième partie Les diagrammes de cas dutilisation (Use-Case) 69 Les diagrammes dinteractions 82 Les diagrammes de séquences 84 Les diagrammes de collaboration102 Les diagrammes détats105 Les diagrammes dactivités134 Les diagrammes de composants143 Les diagrammes de déploiement147

68 68 Booch Unified Method 0.8 etc... OOSE (Jacobson et al.) UML etc. ROOM Catalysis OMG UML 1.1 Nov UML 1.3 UML 1.4 UML 2.0 Juin 1999 Fin 2001 … HOOD OMT (Rumbaugh et al.) 1995 Rational ROOM Classe-Relation Fusion OOSE Booch OMT Fin 1990

69 69 Les cas d utilisation (1) Un cas d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au système. L'acteur représente un rôle joué par une personne (ou un autre système) qui interagit avec le système en cours de modélisation. La même personne physique peut jouer le rôle de plusieurs acteurs (enseignant, responsable) Plusieurs personnes peuvent également jouer le même rôle, et donc agir comme le même acteur (tous les clients) Acteur Cas d'utilisation

70 70 Les cas d'utilisations permettent d'exprimer les désirs des utilisateurs du logiciel en cours de modélisation. Les cas d utilisation décrivent le comportement du système, du point de vue d'un utilisateur, sous la forme d'une séquence d'actions et de réactions. On peut préciser le comportement dun cas dutilisation en décrivant les flots d événements à laide dun texte. Puis au fur et à mesure que lon affine sa compréhension des exigences du système, on utilise des diagrammes dinteraction pour préciser graphiquement ces flots. Les cas d utilisation (2)

71 71 Achat sur site Internet Les acteurs : propriétés Une relation de généralisation/spécialisation peut être appliquée aux acteurs. Internaute Consulter info. Client Acheter livre

72 72 Un cas dutilisation modélise un ensemble de séquences dans lequel chaque séquence représente une variation possible dun même type dinteraction. Chaque séquence est un scénario. –Scénario : cas dutilisation spécifique (exemple : « Le client Pierre retire 100 euros avec sa carte VISA à partir du distributeur installé 5 rue du château ») –Cas dutilisation : modélise le cas général, donne une vision synthétique de scénarios similaires. (exemple : « un client retire de largent à partir dun distributeur ») flot dévénements principal On peut avoir dautres scénarios : carte VISA périmée flot dévénements exceptionnel Cas d utilisation et scénarios

73 73 Le système voiture Garagiste Conducteur Se déplacer Écouter de la musique Faire la vidange Réparer Exemple de cas d utilisation

74 74 Relation dinclusion « include » Le système voiture Garagiste Faire la vidange Réparer > Activer pont élévateur > Permet dincorporer le comportement dun autre cas dutilisation. Le cas dutilisation inclus nest jamais exécuté seul, mais seulement en tant que partie dun cas de base plus vaste.

75 75 Relation dextension « extend » Le système voiture Garagiste Faire la vidange Réparer Commander pièce > Permet de modéliser la partie dun cas dutilisation considérée comme conditionnelle dans le comportement du système.

76 76 Spécialisation Le système voiture Garagiste Réparer Réparer Diesel Les cas dutilisation peuvent être hiérarchisés par généralisation/spécialisation. Les cas dutilisation descendants héritent de la sémantique de leurs parents. Ils peuvent comprendre des interactions spécifiques supplémentaires ou modifier des interactions héritées. Réparer essence

77 77 Le cas dune coopérative de libraires Pour chacun des cas d'utilisation, on fournira une spécification sous forme de texte ou d'un diagramme d'interaction (séquence ou collaboration) Créer Nouveau Client Vérifier solvabilité client Employé Passer une commande urgente Enregistrer une commande > Ce cas peut être considéré comme exceptionnel. On peut factoriser des comportements >

78 78 Spécification sous forme textuelle (rédigée avec laide de l utilisateur) Système : coopérative Acteur primaire : lemployé de la coopérative Objectif : enregistrer une commande « normale » de livres Précondition : le libraire existe Scénarios : 1 - vérification de sa solvabilité (à partir de son numéro) Pour chaque livre : 2 - vérification de lexistence du livre (à partir de l ISBN) 3 - précision de la quantité Exception : 1a - le libraire nest pas solvable (l employé est informé) 2a - le livre nexiste pas (l employé est informé)

79 79 Diagramme de classe (version de base) CATALOGUE LIVRE LIGNE-COMMANDE COMMANDE-LIBLIBRAIRE REGISTRE-LIBRAIRE -SesDemandes -SesLignes * 1 -SesCommandes-SonDemandeur -SonCatalogue -SesLivres * 1 -SonLivre 1 -SesLibraires 1 * -SonRegistre -SaCommande * 1 * EDITEUR -SesLivres -SonEditeur * 1

80 80 Spécification sous forme textuelle (proposition technique) Système : coopérative Acteur primaire : l employé de la coopérative Objectif : enregistrer une commande de livres Précondition : le libraire existe Scénarios : 1 - vérification de la solvabilité du libraire (à partir de son numéro) * une instance de commande est créée Pour chaque livre : 2 - vérification de l existence du livre * une instance de ligne de commande est créée * l instance est reliée à la commande 3 - précision de la quantité * la quantité est ajoutée Exceptions : 1a - le libraire n est pas solvable * un message est renvoyé 2a - le livre n existe pas * un message est renvoyé

81 81 Diagramme de classe (version 2) CATALOGUE LIVRE LIGNE-COMMANDE COMMANDE-LIB LIBRAIRE REGISTRE-LIBRAIRE -NumISBN : integer -Titre : string -DateEdition : Date -SesCommandes +TrouverLibraire(In Numéro:integer):LIBRAIRE +TrouverLivre(In numéro:integer):LIVRE -SonRegistre 1 -SonCatalogue -SesLivres 1 * +Solvable?():boolean -SonDemandeur 1 -NumLib : integer -NomLib : string -AdresLib : string -Etat : string -SesLibraires* +Créer(In Lib:LIBRAIRE,In NumCom:integer, In DateCom:Date) * -NumCom : integer -DateCom : Date -SaCommande 1 +SetQuantité(In Nb:integer) -Quantité : integer -SesDemandes -SonLivre * 1 +Créer(In Liv:LIVRE,In Com:COMMANDE-LIB,In Quantité:integer) * -SesLignes EDITEUR -Nom : string -Adresse : string -SesLivres -SonEditeur * 1

82 82 Diagrammes dinteraction

83 83 Diagramme dinteraction Les diagrammes dinteraction représentent les objets les uns par rapport aux autres et montrent comment ces objets communiquent au cours dune interaction. Il existe deux sortes de diagrammes dinteraction : les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets. les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.

84 84 Diagramme de séquence Un diagramme de séquence permet de décrire une simulation du fonctionnement d un cas d utilisation. Il met en jeu : un acteur un ensemble d objets la chronologie des échanges entre les objets (messages avec leurs paramètres et leur valeur de retour) les contraintes de temps.

85 85 Diagrammes de séquence : principes généraux nom2:Classe1 objet du diagramme de classes ligne de vie (durée de linteraction) activation nom3:Classe2 message nom (…) retour nom1:Acteur nom(…) acteur

86 86 Diagramme de séquence : notation Inst.1:Acteur CallAction() Inst.3:Class-B Créer() CallAction() Inst.4:CLASSE-C Détruire() CallAction() Inst.2:CLASSE-A

87 87 Diagramme de séquence « système » Il permet de décrire le fonctionnement du système. C est une reformulation du texte du cas d utilisation. Il met en jeu : un acteur l objet de la classe SYSTEME la chronologie des échanges entre les objets les contraintes de temps

88 88 Diagramme de séquence « système » : exemple Le système est traité comme une boîte noire. Pour chaque livre commandé SolvableLibraire (num) TrouverLivre (ISBN) SetQuantité (n) : Système Livre réponse Ou réponse négative

89 89 Diagramme de séquence : message avec retour Monsieut TRUC:LeResponsable Unlivre:LIVRE GetTitre() Titre

90 90 Diagramme de séquence : création et message sans retour UnLivre:LIVRE Créer( NumISBN, Titre, DateEdition ) LeCatalogue:CATALOGUE AjouterLivre(self) Monsieut TRUC:LeResponsable self ou this

91 91 Ajouter un nouveau livre : autre manière Monsieut TRUC:LeResponsable L:LIVRE Créer(Numéro, Titre, AnnéeEdition) L LeCatalogue:CATALOGUE AjouterLivre(L)

92 92 Ajouter un nouveau livre : solution préférable LeCatalogue:CATALOGUE NouveauLivre( NumISBN, Titre, DateEdition ) Monsieut TRUC:LeResponsable UnLivre:LIVRE Créer( NumISBN, Titre, DateEdition ) UnLivre AjouterLivre (UnLivre)

93 93 Ajouter un nouveau livre en lui attribuant un numéro L:LIVRE Monsieut TRUC:LeResponsable LeCatalogue:CATALOGUE NouveauLivre(Titre, AnnéeEdition) Créer(Numéro, Titre, AnnéeEdition) L AjouterLivre(L) CalculerNuméro() Numéro Cela suppose que lon conserve le dernier numéro attribué

94 94 Diagramme de séquence : branchement conditionnel (2 objets différents) Instance:CLASSE1Instance1:CLASSE2Instance2:CLASSE3 [X] CallAction1() [non X] CallAction2()

95 95 Diagramme de séquence : branchement conditionnel (même objet) Instance:CLASS1Instance1:CLASSE [X] CallAction1() [non X] CallAction2()

96 96 Diagramme de séquence (exemple) Monsieut TRUC:Responsable LeRegistre:REG-LIBRAIRE UnLibraire:LIBRAIRE SolvableLibraire? b Solvable?() b TrouverLibraire UnLibraire Vérification de la solvabilité dun libraire identifié par un numéro. (numéro)

97 97 Diagramme de séquence en escalier (décentralisé) On parle aussi de délégation ou propagation des messages. Instance:AInstance1:BInstance2:CInstance3:DInstance4:E CallAction()

98 98 Diagramme de séquence en fourche (centralisé) On parle aussi de supervision (un objet envoie tous les messages) Instance:AInstance1:BInstance2:EInstance3:CInstance4:D CallAction()

99 99 Monsieut TRUC:Responsable UnLibraire:LIBRAIREC :COMMANDE-LIBL:LIGNE-COMMANDE SonLivre:LIVRE GetDétailCommandes() { Date + { Titre,Quantité } } GetDétailCommande() Date + { Titre,Quantité } GetInfoLigne() Titre,Quantité GetTitre() Titre GetDate() Date GetLivre() SonLivre GetSesLignes() SesLignes GetQuantité() GetSesCommandes() Spécification sous forme de diagramme de séquence Pour chaque commande C prise dans SesCommandes Pour chaque ligne L prise dans SesLignes SesCommandes

100 100 Monsieut TRUC:Responsable UnLibraire:LIBRAIREC :COMMANDE-LIBL:LIGNE-COMMANDE SonLivre:LIVRE GetDétailCommandes () GetDétailCommande() GetInfoLigne() Titre,Quantité GetTitre() Titre Spécification sous forme de diagramme de séquence Pour chaque commande C prise dans SesCommandes Pour chaque ligne L prise dans SesLignes Date + { Titre,Quantité } { Date + { Titre,Quantité } }

101 101 Spécification sous forme de diagramme de séquence (trop centralisé) Monsieut TRUC:LeResponsable C :COMMANDE-LIBL :LIGNE-COMMANDE unLivre:LIVRE UnLibraire:LIBRAIRE GetSesLignes() GetQuantité() Quantité GetLivre() unLivre GetTitre() Titre GetDateCom() Date GetDétailCommandes() GetSesCommandes() SesCommandes Pour chaque commande C prise dans SesCommandes Pour chaque ligne prise dans SesLignes SesLignes { Date + { Titre,Quantité } }

102 102 Diagramme de collaboration Un diagramme de collaboration est une extension du diagramme d objets. Il permet de décrire : * un aspect structurel : un ensemble d objets, les liens entre ces objets, les rôles de ces objets dans la collaboration * un aspect de communication : les messages et les numéros de séquence des échanges entre les objets de cette collaboration.

103 103 Spécification sous forme de diagramme de collaboration MonsieurTRUC: Responsable UnLibraire: Libraire C: CommandeLib L: LigneCommande SonLivre : Livre 2: GetSesCommandes ( ) 4: GetDate ( ) 5: GetSesLignes ( ) 7: GetLivre ( ) 9: GetQuantité ( ) 1: GetDétailCommandes ( ) 3: GetDétailCommande ( ) 6: GetInfoLigne ( ) 8: GetTitre ( )

104 104 Diagramme de classe

105 105 Diagrammes détats

106 106 Le diagramme détats Un diagramme détat modélise lexistence (cycle de vie) dun objet, que ce soit une instance de classe ou un système pris dans son ensemble. Il repose sur différents concepts : les états les transitions les événements.

107 107 Les états Un état correspond à la manière dêtre dun objet pendant un intervalle de temps plus ou moins long. Un état se compose de plusieurs parties : le nom les actions dentrée/sortie : ce sont des actions effectuées au moment de l entrée ou de la sortie de létat les activités les actions liées aux transitions internes ( ces transitions noccasionnent aucun changement détat).

108 108 Transitions et Evénements Une transition indique le passage dun état (état source) dans un autre (état cible). Elle est représentée par une flèche. Un événement représente quelque chose qui arrive à un moment précis. Il peut déclencher un changement d état. Exemple : une télévision. Etat Transition ArrêtéeEn veille Mise sous tension Evénement

109 109 Activités - Actions Une activité représente une opération qui nécessite un certain temps d exécution. Une activité peut être interrompue à chaque instant par un événement générant une transition. Une activité est associée à un état. Un état peut ne pas avoir d activité. Une action représente une opération instantanée ; sa durée est insignifiante. Une action est toujours intégralement réalisée. Une action est associée à un événement. Si aucune action ne résulte dun événement qui se produit alors on peut mentionner laction : « defer ». Cela permet dinsister sur le fait que lévénement peut arriver mais quil est sans effet dans létat où l objet se trouve. Lévénement sera traité par le même objet, dans un autre état, sans avoir besoin de se reproduire.

110 110 Forme générale dun état NOM D ETAT entry / action-entrée do : activité on Evénement-1/action-1 … on Evénement-n / action-n exit / action-sortie Début Fin

111 111 Forme générale d une transition Etat1 entry/action-entrée1 do : activité1 on Event-11/action-11 … on Event-1n /action-1n exit/action-sortie1 Etat2 entry / action-entrée2 do : activité2 on Event-21/action-21 … on Event-2m/action 2m exit/action-sortie2 Événement [garde] / action Actions et activités sont exprimées avec des verbes. Remarque : suivant les cas, événement, garde (condition), action peuvent être omis.

112 112 Diagramme détats : système dalarme EN-VEILLE do : garder détecteur sous tension EN-ALERTE entry / mettre sonnerie Détection-Pb / envoyer message poste de surveillance Événement Activité Action

113 113 Dans une bibliothèque on enregistre tous les nouveaux livres avant de les mettre à disposition des lecteurs. Cas 1 : les livres enregistrés sont mis à disposition à 15h. Dès quun livre est enregistré il est mis à disposition Diagramme détats ENREGISTREMENT do / enregistrer A DISPOSITION entry / placer When 15 heures ENREGISTREMENT do / enregistrer A DISPOSITION entry / placer

114 114 États composés / Sous-états Un sous-état est un état emboîté dans un autre état (état composé). Forme générale : Etat1 Etat2 Etat3 Etat4 Event-1 Event-5 Event- 3Event-2 Event-4

115 115 Exemple détats composés Un magnétoscope peut être * en fonctionnement * hors fonctionnement. * en veille En fonction, il peut être * en enregistrement * en diffusion. HORS FONCTION EN-ENREGISTREMENT EN-DIFFUSION EN VEILLE Event-1 Event-5 Event- 3Event-2 Event-4 EN FONCTION Event-6 Event-7

116 116 États composés / Sous-états Etat1 Etat2 Etat3 Etat4 Event-1 Event-5 Event- 3 Event-2 Event-4 Autre forme de modélisation équivalente Point d entrée de létat composé.

117 117 États à historique Un état à historique permet à un état composé qui contient des sous-états de se souvenir du dernier sous-état actif avant la transition réalisée depuis létat composé. Etat1 Etat2 Etat3 Etat4 Event-1 Event-5 Event- 3 Event-2 Event-4 H Point dentrée pour la première fois.

118 118 États à historique (exemple) Exemple : une machine à laver peut être arrêtée dans un état (lavage, rinçage, essorage). Elle redémarrera du même état. Arrêtée En lavage En rinçage En essorage Mise en fonctionnement H Fin du cycle Arrêt

119 119 Diagramme détats : exemple de la montre Une montre digitale simple possède un cadran et 2 boutons que lon nomme A et B, pour la mettre à lheure. La montre a deux modes dopération : affichage de lheure et mise à lheure. Le mode de mise à lheure a deux sous-modes, heures et minutes. Le bouton A sutilise pour les modes. A chaque fois que lon appuie dessus le mode change suivant la séquence : affichage, configurer heures, configurer minutes, affichage, etc. Dans un des 2 sous-modes configurer heures, configurer minutes, le bouton B semploie pour avancer les heures ou les minutes à chaque fois que lon appuie dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement.

120 120 Diagramme détats EnAffichageHeure AppuyerA EnModificationH on AppuyerB/IncrémenterH() EnModificationM on AppuyerB/IncrémenterM() AppuyerA EnModification

121 121 La montre : diagramme de classes MONTRE -Heures : integer -Minutes : integer +AppuyerA() +AppuyerB() -IncrémenterH() -IncrémenterM()

122 122 La montre : diagramme de classes ModifierHeures + EtatSuivant() +avance() Montre -heures : Type-heure -minutes : Type-minute +AppuyerA() +AppuyerB() +IncH() +IncM() AffichageHeure + EtatSuivant() ModifierMinutes + EtatSuivant() +avance() EtatMontre +EtatSuivant() +avance() état * 1 AffichageHeure: EtatMontre ModifierHeure: EtatMontre AffichageMinutes : EtatMontre

123 123 Les événements « appel » Un événement « appel » est un événement interne (il survient entre les objets du système). Il représente le déclenchement d une opération. Un événement « appel » implique au moins 2 objets : –celui qui invoque lopération –celui vers lequel lévénement est dirigé. Ce dernier devra contenir une opération de même nom que lévénement. Notation : ^objet-destinataire.événement-appel

124 124 Les événements « appel » : exemple Autoradio : Voyant lumineux EN FONCTION Entry : ^Voyant.Allumer do : DiffuserSon HORS FONCTION Entry : ^Voyant.Eteindre MettreBouton (off ) MettreBouton (on) ALLUME Entry : SetLumière(vrai) ETEINT Entry : SetLumière(faux) Eteindre Allumer

125 125 Opérations publiques - Opérations privées Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet). Les opérations effectuées à lintérieur d un état correspondent à des opérations privées (opérations d un objet sur lui-même).

126 126 Opérations publiques - Opérations privées : exemple Lutilisateur peut activer MettreBouton(off ), MettreBouton(on) mais cest lautoradio qui active lopération DiffuserSon() suivant létat dans lequel il est. Lautoradio envoie un message Allumer(), Eteindre() au voyant mais cest le voyant qui active lopération setLumière en fonction de son état. SonVoyant SonAutoradio VOYANT -Lumière : booléen + Allumer() + Eteindre() - SetLumière(b:bool) AUTORADIO + MettreBouton(e: string) - DiffuserSon()

127 127 Les événements temporels Les événements temporels sont causés par lexpiration d une temporisation. Ils peuvent être : absolus ( spécification dune date ou dune heure) et sont traduits par le mot clef when. ex : when date = 1/01/02, pour indiquer le passage de l état où la monnaie était en francs à l état où la monnaie est en euros. Monnaie en francsMonnaie en euros when date = 1/01/02

128 128 Les événements temporels relatifs (spécification dune durée par rapport à un état) et sont traduits par le mot clef after ex : after 10 jours, pour indiquer le passage de létat consommé à un état périmé dans le cas de produits qui se détériorent rapidement. Médicament consomméMédicament périmé Médicament consommable Ouverture flacon after 10 jours when date du jour >= date limite

129 129 Les événements « appel » : exemple Autoradio : Voyant lumineux EN FONCTION Entry : ^Voyant.Allumer do : DiffuserSon HORS FONCTION Entry : ^Voyant.Eteindre MettreBouton (off ) MettreBouton (on) ALLUME Entry : SetLumière(vrai) ETEINT Entry : SetLumière(faux) Eteindre Allumer

130 130 Opérations publiques - Opérations privées Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet). Les opérations effectuées à lintérieur d un état correspondent à des opérations privées (opérations d un objet sur lui-même).

131 131 Opérations publiques - Opérations privées : exemple Lutilisateur peut activer MettreBouton(off ), MettreBouton(on) mais cest lautoradio qui active lopération DiffuserSon() suivant létat dans lequel il est. Lautoradio envoie un message Allumer(), Eteindre() au voyant mais cest le voyant qui active lopération setLumière en fonction de son état. SonVoyant SonAutoradio VOYANT -Lumière : booléen + Allumer() + Eteindre() - SetLumière(b:bool) AUTORADIO + MettreBouton(e: string) - DiffuserSon()

132 132 Petit rappel sur les relations Il existe 4 types de relations dans UML : la dépendance représentée par une ligne en pointillés, fléchée. Lassociation représentée par une ligne continue qui peut être fléchée (navigation). Lagrégation est une association particulière. La généralisation représentée par une ligne continue fléchée avec une pointe creuse. La réalisation représentée par une ligne en pointillés fléchée avec une pointe creuse.

133 133 Les diagrammes d activités Un diagramme dactivités est essentiellement un organigramme qui représente l activité au cours du temps. Il peut sutiliser : pour préciser un cas d utilisation en indiquant les flux, les synchronisations, les conditions dexécution des activités. (on peut représenter éventuellement qui est responsable dune activité) pour spécifier un algorithme associé à une opération.

134 134 Les diagrammes d activités (formalisme) –Activité (traitement) –Transition –Synchronisation –Flots de données –Flots de données dans un état particulier –Production et consommation de flot de données –Branchement conditionnel [garde] Faire... objet:Classeobjet: [état] [cond.1] [cond.2]

135 135 Commander produit Traiter commande Sortir article Expédier commande Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture Clôturer commande Recevoir paiement

136 136 Les travées Une travée permet de diviser les activités en groupes, chaque groupe représentant le département responsable de ces activités. (niveau organisationnel de Merise) Dans un diagramme dactivité divisé en travées, chaque activité appartient à une seule travée, même si les transitions peuvent passer dune travée à lautre. Les travées sont délimitées par des barres verticales. Chaque travée a un nom.

137 137 Commander produit Traiter commande Sortir article Expédier commande Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture Clôturer commande ClientService ventes Entrepôt Recevoir paiement

138 138 Commander produit Traiter commande Sortir article Expédier commande Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture Clôturer commande ClientService ventes Entrepôt f: facture[due] f: facture[payée] Recevoir paiement

139 139 Les composants (1) Un composant est une partie physique remplaçable dun système qui fournit la réalisation dun ensemble dinterfaces. Un composant existe rarement indépendamment des autres. Un composant donné collabore avec dautres composants. Un composant est représenté par un rectangle avec des onglets : Composant1

140 140 Un composant représente en général le regroupement physique déléments habituellement logiques tels que les classes et leurs interfaces en tenant compte de leurs collaborations. On peut préciser les classes quimplémente un composant par une liaison : Les composants (2) Composant1 Class1 Class2 Composant1 Class1 Class2

141 141 Les composants (3) De la même manière que pour les classes on peut représenter les composants qui réalisent des interfaces, et les autres composants qui ont accès aux services à travers les interfaces. Composant1 Class Composant Lien de dépendance (accès au service) Réalisation Composant1 > Class Composant

142 142 Composants standards UML définit 5 stéréotypes standard qui sappliquent aux composants : « file » précise un composant qui représente un document contenant du code source ou des données « executable » précise un composant qui peut être exécuté « table » précise un composant qui représente une table de base de données « library » précise une bibliothèque objet statique ou dynamique « document » correspond à un document quelconque (fichier de données, dinstallation, document daide …)

143 143 Les diagrammes de composants Ils montrent lorganisation et les dépendances au sein dun groupe de composants. En règle générale les diagrammes de composants contiennent des composants de interfaces des relations –de dépendances –de généralisation –dassociation –de réalisation

144 144 Les diagrammes de composants (exemple de fichiers) signal.h {version = 3.5} signal.h {version = 4.1} signal.h {version = 4.0} « parent » irq.h interp.cpp device.cpp signal.cpp {version = 4.1}

145 145 Les nœuds Un nœud est un élément physique qui intervient lors dune phase dexécution ; il représente une ressource de calcul et dispose généralement au moins dun peu de mémoire et souvent dune capacité de traitement. Un nœud est en général représenté par un cube. « mémoire » Disque « processeur » PC « dispositif » Modem

146 146 Les nœuds Les nœuds sont probablement les briques de base les plus stéréotypés en UML. Des icônes sont souvent associées aux stéréotypes, pour fournir des repères visuels explicites pour le public auquel ils sont destinés.

147 147 Les diagrammes de déploiement Ils permettent de représenter larchitecture physique dun système en visualisant les classes de nœuds (ou des instances de nœuds) et les relations de dépendances et dassociations entre ceux-ci. Ils peuvent également comporter les composants qui doivent résider sur un nœud. Remarque : si on développe un logiciel sur une seule machine avec en interfaces des périphériques standards, on peut se passer de diagrammes de déploiement. Nœud Composant Nœud Composant

148 148 Les diagrammes de déploiement avec des icônes

149 149 Diagramme de déploiement : diagramme de spécification Modélisation de la répartition des composants kiosque console tour de disques RAID 10-T Ethernet RS-232 > user > admin > config serveur > dbadmin > tktmstr vitesseProcesseur mémoire

150 150 Diagramme de déploiement : diagramme dinstances s:Serveurk1:kiosque k2:kiosque c1:console t:tour de disques RAID vitesseProcesseur = 2Ghz mémoire=256Mo

151 151

152 152

153 153 De lanalyse … à la conception Lanalyse des besoins est lactivité essentielle au début du processus de développement dun logiciel. Le futur utilisateur exprime ses besoins sous une forme textuelle informelle, parfois accompagnée de modèles dIHM permettant de mieux préciser des souhaits. Analyse des besoins

154 154 Le cas bibliothèque. La bibliothèque dune école dingénieurs met à disposition des élèves et des enseignants des livres techniques qui peuvent être empruntés. Chaque emprunteur dispose d'un badge, comportant un numéro, son nom et son prénom, qu'il doit présenter pour accéder à la bibliothèque. Il peut emprunter autant de livres qu'il le désire. La durée de l'emprunt n'est pas limitée. Chaque livre est repéré par un numéro, un titre, le nom de l'auteur principal, l'année d'édition.

155 155 Le cas bibliothèque. On ne cherche pas à faire d'historique des emprunts. On veut seulement savoir quelle personne détient un livre de manière à pouvoir la contacter si une autre souhaite consulter l'ouvrage. Pour cela, on dispose pour chaque personne de son e- mail. Il est nécessaire de pouvoir enregistrer un nouveau livre, un nouvel emprunteur. On voudrait pouvoir éditer des statistiques.

156 156 Le cas bibliothèque : IHM - retour anonyme Retour anonyme : Entrer le numéro du livre : (RC) Le génie logiciel orienté Objet

157 157 Le cas bibliothèque : IHM - retour dun étudiant Retour dun étudiant : Retour d étudiant Entrer le numéro de lemprunteur : 456 (RC) Jean Dupuy Livres empruntés : Le génie logiciel orienté Objet OCL pour les nuls

158 158 Spécification globale Le but de cette activité est d'établir une première description du futur système. Lexpression préliminaire des besoins donne lieu à une modélisation par des Cas dutilisation et à une maquette dIHM. Il faudra donc : identifier les acteurs identifier les cas dutilisation ajouter si besoin des relations entre cas dutilisation. Il sera utile détablir une priorité entre les cas dutilisation de manière à aider le chef de projet à planifier ses itérations (modèle de la spirale).

159 159 Le cas bibliothèque : cas dutilisation Enregistrer Retour Enregistrer Emprunt Bibliothécaire Enregistrer Nouveau Livre Priorité 2 Enregistrer Nouvel Emprunteur Éditer Statistiques

160 160 EnregistrerRetourAnonyme Enregistrer Retour Bibliothécaire Le cas bibliothèque : cas dutilisation EnregistrerRetourEtudiant

161 161 Spécification globale (2) Il sagit ensuite de créer une représentation visuelle des objets du monde réel dans un domaine donné. Ils seront représentées dans un Diagramme de classes danalyse ne mettant en évidence que peu dopérations. Par contre les attributs évoqués (caractéristiques dun livre, dun emprunteur, etc.) dans les cas dutilisation ainsi que toutes les associations suggérées (emprunt caractérisé comme une association entre LIVRE et PERSONNE) devront y figurer.

162 162 Le cas bibliothèque : diagramme de classes danalyse 1 * SaBiblio BIBLIOTHEQUE SesLivres SaBiblio * 1 SesEmprunteurs PERSONNE LIVRE SesEmprunts Numero Nom Prénom SonEmprunteur 0..1 * Professeur Numéro Titre Auteur AnnéeEdition Dans la phase danalyse il nest pas indispensable de faire apparaître la classe du domaine.

163 163 Spécification détaillée des exigences Une fiche de description textuelle de chaque cas dutilisation doit être fournie. Il est nécessaire de fournir : le scénario qui permet de satisfaire les objectifs des acteurs par le chemin le plus direct de succès. les extensions qui comprennent tous les scénarios de succès ou déchec. Il faut également préciser : les pré conditions qui définissent ce qui doit être vrai en amont du cas dutilisation pour que celui-ci puisse démarrer. Les post conditions qui définissent ce qui doit être vrai lorsque le cas dutilisation se termine.

164 164 Le cas bibliothèque : scénario Système : la Bibliothèque Acteur Primaire : un bibliothécaire Objectif : enregistrer les retours de livres d'un étudiant qui présente sa carte. Scénario : 1 - Rechercher à partir d'un numéro de carte, le nom de létudiant et la liste des titres des livres quil a empruntés. 2 - Pour chaque livre sélectionné, enregistrer le retour. Exception : 1a -le numéro saisi est inconnu --> demander de recommencer. Pré condition : le livre retourné figure dans la liste des livres empruntés.

165 165 Spécifications OCL context EnregistrerEmprunt( NumL, NumP : integer) {signals echec} pre : Valide : boolean = Il existe une instance de Livre avec numéro Numl. Cette instance nest pas déjà empruntée. Il existe une instance de Personne avec numéro NumP. post : not Valide implies echec.sent() Valide implies Linstance de Livre avec numéro NumL a comme emprunteur la Personne avec numéro NumP. Linstance de Livre avec numéro NumL figure dans les emprunts de la Personne avec numéro NumP.

166 166 Spécifications OCL context EnregistrerEmprunt( NumL, NumP : integer) {signals echec} pre : Valide : boolean = Livre.allInstances exists ( L | L.Numéro =NumL) Personne.allInstances exists ( P | P.Numéro =NumP) let L1 : Livre | L1.Numéro = NumL in L1.sonEmprunteur isEmpty() post : not Valide implies echec.sent() Valide implies let L1 : Livre | L1.Numéro = NumL P1 : Personne | P1.Numéro = NumP in L1.SonEmprunteur = P1 P1.SesEmprunts = including (L1)

167 167 Spécifications OCL context EnregistrerRetour( NumL : integer) {signals echec} pre : Valide : boolean = Il existe une instance de Livre avec numéro Numl. Cette instance est empruntée par une Personne. post : not Valide implies echec.sent() Valide implies Linstance de Livre avec numéro NumL na pas demprunteur Linstance de Livre avec numéro NumL ne figure pas dans les emprunts de la Personne qui lavait avant lenregistrement de retour.

168 168 Spécifications OCL context EnregistrerRetour( NumL : integer) {signals echec} pre : Valide : boolean = Livre.allInstances exists ( L | L.Numéro =NumL) let L1 : Livre | L1.Numéro = NumL in L1.sonEmprunteur notEmpty() post : not Valide implies echec.sent() Valide implies let L1 : Livre | L1.Numéro = NumL P1 : Personne | P1= in L1.SonEmprunteur isEmpty P1.SesEmprunts = excluding (L1)

169 169 Spécification détaillée des exigences Les cas dutilisation décrivent les interactions des acteurs avec le système. On peut représenter ces échanges à laide de Diagrammes de séquence système. Le comportement du système est décrit vu de lextérieur, sans préjuger de comment il sera réalisé.

170 170 Le cas bibliothèque : diag de séquence système - retour étudiant :LeSystème :Bibliothécaire TrouverLivres(NumEtu) NomEtu +{titre} EnregistrerRetour(titre)

171 171 Spécification détaillée (suite) Il est nécessaire de contrôler la validité du texte des cas dutilisation par rapport aux informations définies dans le diagramme de classes conceptuelles. Afin de pouvoir relier les diagrammes de cas dutilisation au diagramme de classes conceptuelles, il est nécessaire didentifier les principales classes dIHM ainsi que les opérations qui vont montrer la logique de lapplication. On va définir un diagramme supplémentaire appelé Diagramme de classes de conception

172 172 Typologie des classes de conception Les classes qui modélisent les interactions entre le système et les utilisateurs, appelées classes « dialogue ». Les classes qui représentent les processus, les ressources et lorganisation dune entreprise, appelées classes « métier ». Elles sont souvent permanentes. Les classes qui contiennent la cinématique de lapplication, appelées classes « contrôle ». Elles font la transition entre les classes dialogues et les classes métiers et contiennent les règles métiers.

173 173 Les classes « métier » Ce sont les classes étudiées jusquà présent. Celles-ci représentent en général des informations persistantes de lapplication. Métier MM donnée1 donnée2 donnée3 opér1() opér2()

174 174 Les classes « dialogue » Elles possèdent des attributs et des opérations. Les attributs vont représenter des champs de saisie ou des résultats. Les résultats sont distingués en utilisant la notation de lattribut dérivé. Les opérations représentent des actions de lutilisateur sur l IHM, ou des actions de la classe de contrôle. Dialogue DD champ1 champ2 /résultat action1() action2() saisir ou afficher

175 175 Les classes « contrôle » Elles possèdent uniquement des opérations. Elles montrent : la logique de lapplication, les règles métier, les comportements du système informatique. Contrôle CC opération1() opération2()

176 176 Règles de composition des diagrammes de classes de conception Les « dialogues » ne peuvent être reliés quaux « contrôles ». Les « métiers » ne peuvent être reliées quaux « contrôles » ou autres « métiers ». Les « contrôles » ont accès à tout type de classes, y compris dautres contrôles. Contrôle CC opération1() opération2() Dialogue DD champ1 champ2 /résultat action1() action2() Métier MM donnée1 donnée2 donnée3 opér1() opér2()

177 177 Un exemple simple Écran de saisie Nouveau Livre Créer Nouveau Livre Livre CtrCréation créerLivre (titre, auteur) Saisie Livre titre auteur saisir(titre, auteur) Livre numéro titre Auteur +Livre (titre, auteur) - nouveauNuméro()

178 178 RetourAnonyme NumLivre /titre +AfficherTitre() + EnregRetour() CtrRetourAnonyme +EnregRetour (NumLivre) -AfficherTitre(NumLivre) -TrouverLivre (NumLivre) Livre -numéro -titre -auteur +RetirerEmprunteur(P:Personne) Le cas bibliothèque : diag de classes danalyse - retour anonyme Personne -numéro -nom -prénom +RetirerLivre(L:Livre) SonEmprunteur 0..1 * SesEmprunts

179 179 RetourEtudiant NumEtud /nom +AfficherNom(N:string) +AffTitreLivre() CtrRetourEtudiant +AffTitreLivre(NumEtud) -AfficherNom(NumEtud) -AfficherTitre(T:sting) +EnregRetour (L:Livre) Livre -numéro -titre -auteur Livre-Dialogue /titre +Créer() +sélectionner() Le cas bibliothèque : diag de classes danalyse - retour étudiant Etudiant -numéro -nom -prénom SonEmprunteur 0..1 * SesEmprunts

180 180 La conception Elle vise principalement à préciser le modèle danalyse de telle sorte quil puisse être implémenté avec les éléments darchitecture dont on dispose. Les classes deviennent plus précises, avec des attributs typés. Au niveau des « ensembles », il est nécessaire de préciser sils seront implémentés sous forme de listes, de tableaux … Les opérations sont complètement qualifiées ; on précise leur visibilité. La navigation doit être mentionnée. Pour ces 2 derniers points, il est nécessaire de répartir les responsabilités entre les différents objets. On a recours aux diagrammes de séquence.

181 181 Diagrammes de séquence. :LeSystème :Acteur Action1() retour :Acteur Action1() retour :Dialogue :Contrôle :Métier Opération1() GetDonnées()

182 182 Le cas bibliothèque : diag de séquence - retour Anonyme :Bibliothécaire EnregistrerRetour(Num)) RetourAnonyme CtrRetourAnonyme L: Livre SonEmp:Personne EnregistrerRetour(Num) Afficher(Titre) TrouverLivres(Num) SupprimerEmprunt() getTitre() Titre RetirerLivre(self) RetirerEmprunteur() L

183 183 Le cas bibliothèque : diag de séquence - retour Étudiant :Bibliothécaire AffTitreLivre(num) RetourEtudiant CtrRetourEtudiant P : Personne L:Livre AffTitreLivre(Num) TrouverEtud(num) getNom() getTitre() Livre-dial Titre Nom {Titre} Afficher(Nom) AffTitreLivre() Créer(Titre) Pour chaque livre L... Pour chaque livre de la liste établie. P

184 184 Le cas bibliothèque : diag de séquence - retour Étudiant :Bibliothécaire Sélectionner(L:Livre) CtrRetourEtudiant L: Livre SonEmp:Personne Sélectionner() Livre-dial RetirerLivre(self) RetirerEmprunteur() SupprimerEmprunt()

185 185 Quelques règles générales de présentation des diagrammes Disposer les éléments de façon à éviter que les lignes se croisent. Organiser les éléments de façon à ce que les éléments proches du point de vue sémantique soient également proches du point de vue physique. Ne JAMAIS présenter un diagramme et les commentaires sy rapportant en recto-verso. Ne JAMAIS présenter des diagrammes se rapportant au même problème sur des pages recto-verso.

186 186 Quelques règles de définition du diagramme de classes Nommer les attributs avec des noms courts ou des petites expressions nominales qui représentent une des propriétés de la classe. Nommer les opérations avec des verbes courts ou de petites expressions verbales qui représentent certains comportements de leur classe englobante. Les noms de classes sont notés en majuscules : PERSONNE. Les noms dattributs, dopérations, de rôles commencent par une majuscule et les noms composés sont accolés, chacun commençant par une majuscule : DateDeNaissance. En règle générale les attributs sont privés et les opérations publiques.

187 187 Règles de définition du diagramme de classes (suite) Les opérations seront notées sous la forme : NomOpération(liste de paramètres) : type résultat Ex : RechercherProduit(Code : integer) : PRODUIT Sauf consigne particulière on précisera paramètres et type de retour. On ne met JAMAIS en paramètre lobjet qui contient lopération. Les opérations qui permettent d accéder aux attributs sont de la forme GetAttribut(). Ex : GetNom() : string (… mais CalcPrixTTC() : real ) Les opérations qui permettent de modifier un attribut sont de la forme SetAttribut(paramètre). Ex : SetAdresse (A : string)

188 188 Règles de définition du diagramme de classes (suite) Les noms des rôles avec cardinalité 0..1 ou 1 commencent par Son ou Sa (Ex : SonPropriétaire, SaForme). Les noms des rôles avec cardinalité 0..* ou 1..* commencent par Ses (Ex : SesPropriétés). La navigabilité sera explicitée (flèche dans un ou deux sens).

189 189 Règles de définition des diagrammes de séquence Les opérations mises en évidence sur les diagrammes de séquence doivent figurer sur le diagramme de classes. On vérifiera que les paramètres sont cohérents entre les deux diagrammes. Les opérations seront précisées avec les paramètres (noms de variable plutôt que types de variables). Les messages de retour seront précisés dans la mesure du possible. Notation : la répétition d information sera indiquée avec des accolades {date + { titre + quantité }}

190 190 Règles de définition des diagrammes de séquence (suite) Lorsquun message est adressé à plusieurs instances I dune même classe, on le mentionne dans une note associée au message. Cette note est de la forme : Pour chaque instance I prise dans lensemble des instances et le message est adressé à une instance nommée I. On privilégie les diagrammes de séquence de type décentralisé ou en escalier. On évite les conditions ; si besoin on fait 2 diagrammes de séquence.

191 191 Règles de définition des diagrammes détats Les noms des événements de transition et les noms des événements internes (derrière le mot clef on ) sont des noms dopérations publiques de lobjet pour lequel est fait le diagramme détat. Les opérations effectuées en entrée ou en sortie dun état, et les opérations effectuées au sein dune activité sont des opérations privées de lobjet pour lequel est fait le diagramme détat. Toutes ces opérations doivent figurer sur le diagramme de classes avec visibilité (public/privé) et paramètres cohérents entre les deux diagrammes.

192 192 Attributs et opérations implicites (4) ETUDIANT Nom : string ETUDIANT Nom : string SesVoeuxDOptions : liste(OPTION) AjouterOption(OPTION):bool EnleverOption(OPTION):bool GetSesOptions() : liste(OPTION) OPTION Libellé : string SesVoeuxDOptions 0..* {ordonné} Lintroduction de la contrainte {ordonné} permet de traiter SesVoeuxDOption comme une liste

193 193 Diagramme de déploiement : exemple des portes (diagramme de spécification) Serveur SGBD PC Pilote Portes TX RNIS 1 * TCP/IP Console 3 1 Maître Imprimante 1 1

194 194 Diagramme de déploiement : exemple des portes (diagramme dinstances) PC4 : PC P2 :PorteP3 : Porte P1 : Porte Remarque : les instances sont soulignées.

195 195 Exemple de base

196 196 Le design pattern : State ConcreteStateB +Handle() Context +request(…) ConcreteStateA +Handle() état * State +Handle() 1

197 197

198 198

199 199

200 200 U.M.L. Unified Modeling Language (3 ème partie) Françoise Schlienger FIIFO

201 201 Plan de la troisième partie Les diagrammes dactivités139 Les diagrammes de composants149 Les diagrammes de déploiement153 De lanalyse … à la conception159

202 202 Booch Unified Method 0.8 etc... OOSE (Jacobson et al.) UML etc. ROOM Catalysis OMG UML 1.1 Nov UML 1.3 UML 1.4 UML 2.0 Juin 1999 Fin 2001 … HOOD OMT (Rumbaugh et al.) 1995 Rational ROOM Classe-Relation Fusion OOSE Booch OMT Fin 1990


Télécharger ppt "1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005."

Présentations similaires


Annonces Google