F. Schlienger 2004.

F. Schlienger 2004

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

Plan de la première partie
Les méthodes d’analyse de 1960 à Les méthodes Objet UML : généralités Les diagrammes d ’UML 17 Les mécanismes communs 19 Les diagrammes de classes 31 Les diagrammes d ’objets 61

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

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

Méthodes d’analyse (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 ...) F. Schlienger 2004

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

Méthodes d’analyse (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). F. Schlienger 2004

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

Les méthodes objet (1)

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. Je préciserai oralement qu ’OMT a été la première méthode à définir une notation précis. Elle était elle même inspirée du modèle entité-association pour les classes, de la notation de Harel pour la dynamique et des travaux de De Marco-Coad et Ypurdon pour les flots de données. Grady Booch de son coté avait présentée une méthode orientée « Ada ». F. Schlienger 2004

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 1.3 2000 : UML 1.4 2004 : UML 2 Sites officiels : J ’en profite pour dire qu ’il y a différents sites sur lesquels ils peuvent faire des recherches. Je leur signale qu ’ils peuvent télécharger gratuitement une version du « Modeler » d ’Objecteering qui peut leur permettre de faire toute la modélisation. Il peuvent aussi installer pour le tester Rational Rose mais que la version d ’évaluation n ’est utilisable qu ’un mois. F. Schlienger 2004

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 Si j ’ai d ’autres titres au moment du cours je complèterai. F. Schlienger 2004

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 Comme tout langage d ’analyse F. Schlienger 2004

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. F. Schlienger 2004

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. F. Schlienger 2004

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 F. Schlienger 2004

Les notes Ceci est une note qui peut être reliée à tout élément de
Elles permettent d’ajouter 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. F. Schlienger 2004

Les étiquettes Nommées également « Tagged values », elles permettent la création de nouvelles informations dans la spécification d’un é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. F. Schlienger 2004

Les contraintes PERSONNE SonMari 0..1 -Nom -Genre 0..1 SaFemme
Elles permettent d’étendre la sémantique d’un élément d’UML 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: PERSONNE -Nom -Genre SonMari 0..1 0..1 SaFemme ETUDIANT Nom : string SPECIALITE Libellé : string sesSpé * {ordonné} * F. Schlienger 2004

Limite des contraintes informelles
PERSONNE -Nom -Genre 0..1 SaFemme SonMari P1:PERSONNE Nom = ‘Paul’ Genre = ‘Masculin’ P2:PERSONNE Nom = ‘Marie’ Genre =‘Féminin’ P3:PERSONNE Nom = ‘Anne’ P4:PERSONNE Nom = ‘Pierre’ SonMari SaFemme SaFemme SonMari 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 F. Schlienger 2004

Les relations de dépendances (1)
Une dépendance est une relation sémantique entre deux éléments tels qu’un changement apporté à l’un (élément source) peut affecter la sémantique de l’autre (é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 »

Les relations de dépendances (2)
Une contrainte peut être associée à plusieurs éléments par une relation de dépendance. Participe * * PERSONNE {sous-ensemble} PROJET - nom - prénom - - nom - durée - dateDébut ‘ Responsabl e’ dépend de ‘ participe ’ La suppression d ’un participant peut entraîner la suppression du responsable. 1 Responsable 0..2 F. Schlienger 2004

Les stéréotypes Ce sont des mécanismes d’extensibilité, permettant aux utilisateurs d’ajouter 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 d’opérations. Lorsqu’un stéréotype est utilisé fréquemment, on peut lui associer une notation particulière. CLIENT <<create>> CLIENT() <<destroy>> Détruire() Dans une classe on peut ajouter « constructeur », « destructeur », pour distinguer les différentes opérations F. Schlienger 2004

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

Interface (1) Une interface est un ensemble d’opé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 d’attributs) ni aucune implémentation (elle ne peut donc pas inclure de méthodes qui fournissent l’implémentation d’une 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 d’une interface commence généralement par un I. PERSONNE I-PERSONNE F. Schlienger 2004

Interface (2) 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» I-PERSONNE getHistoEmploi() getRémunération() getPrestation() « realize » PERSONNE F. Schlienger 2004

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

Diagrammes de classes / Diagrammes d’objets
F. Schlienger 2004

Notation des classes Il existe plusieurs niveaux de notation :
a) niveau sans détail b) niveau détail d'analyse PERSONNE Nom Prénom Adresse ModifierAdresse PERSONNE c) niveau de détail de conception 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) F. Schlienger 2004

Notation des attributs et opérations
NOMDECLASSE Opération() Attributs SEGMENT -Longueur :integer =5 +EstSur(in p :POINT): boolean Attribut [ visibilité ] NomAttribut [: type] [= <valeur par défaut>] 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) F. Schlienger 2004

Opérations / méthodes Une opération définit un service qui peut être demandé à n’importe quel objet de la classe. Une méthode est une implémentation d’une 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é. F. Schlienger 2004

Association entre classes
Nom d’association rôle-1 rôle-2 PERSONNE APPARTEMENT Loue > SonPropriétaire SesPropriétés Propose > SonLocataire SaLocation PERSONNE EstEnfantDe Mère Fils ^ F. Schlienger 2004

Cardinalité d’une association
PERSONNE APPARTEMENT Propose > 1 * Nombre de propriétaires Nombre d ’appartements proposés Exactement 1 1 Exactement n n Plusieurs (0 ou plus) * Au plus 1 ou plus * Cardinalité spécifiée F. Schlienger 2004

Association : un exemple (1)
Un appartement n’a qu’un propriétaire et une personne peut proposer à la location plusieurs appartements (sous-entendu, elle peut aussi ne pas proposer d’appartement). Remarque : on précisera toujours les noms des rôles. Le nom de l ’association est facultatif. PERSONNE APPARTEMENT Propose > 1 0..* SonPropriétaire SesPropriétés F. Schlienger 2004

Association : un exemple (2)
Propose > PERSONNE 1 APPARTEMENT 0..* SonPropriétaire SesPropriétés -Code -Adresse -Surface -MontantLoyer APPARTEMENT a un attribut implicite SonPropriétaire : PERSONNE Un constructeur « complet » d’appartement 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. F. Schlienger 2004

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

Les associations qualifiées (2)
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 : * ACTE-MEDICAL 1 MEDECIN CodeType Les actes médicaux sont rattachés au médecin par type. 1 MEDECIN CodeType * ACTE-MEDICAL

Attribut dérivé Un attribut dérivé est un attribut calculé. Cela signifie qu’il peut être calculé à partir d ’autres informations du système à n’importe quel moment. (et non pas qu’il a été calculé à un moment donné). Exemple : pour une personne, l’attribut 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 l’historique des mouvements, alors QuantitéEnStock n’est pas une rubrique calculée. L’attribut 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. Attention : pour qu ’une rubrique soit considérée comme calculée, il faut qu ’on dispose à chaque instant des éléments qui permettent de la recalculer (âge, nb d ’éléments qui entrent dans une association) mais pas un prix même si on le calcule à partir d ’un autre en appliquant une hausse de 10% Autre exemple : dateDébut, DateFin, Durée Au moment de l ’analyse l ’attribut calculé est mentionné en le faisant précéder d ’un / Au moment de la conception, l ’attribut dérivé est transformé en opération. Cette transformation est assez souvent effectuées sans attendre la conception. F. Schlienger 2004

Le nom de l’association est précédé d’un /
Association dérivée Une association dérivée est une association déduite d’une autre. Une association dérivée ne se justifie que pour faciliter des traitements. ENTREPRISE SesServices SERVICE EMPLOYE SesEmployés SonService SesEmployés /Emploi Le nom de l’association est précédé d’un / F. Schlienger 2004

Remarques sur les classes
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 à l’aide d’une note. On peut représenter des « paramètres » (Merise) par le biais de variables de classe. {identifier} F. Schlienger 2004

+AjouterPersonne(in P : PERSONNE)
Exemple Contrairement à Merise ... Emploie> ENTREPRISE -Nom -Adresse +ModifierAdresse() +AjouterPersonne() 1 PERSONNE -Prénoms -DateDeNaissance /-Age +CréerPersonne() +GetCoordonnées() +CalculerAge 0..* SesEmployés SonEntreprise . {Age=DateCourante - DateNaissance} Passer du temps sur Ajouter Personne Parler des paramètres Un attribut calculé indique seulement une contrainte entre 2 propriétés. Il ne précise pas encore ce qui doit être calculé par rapport à ce qui doit être stocké : ce sera un choix de conception. +AjouterPersonne(in P : PERSONNE) F. Schlienger 2004

Agrégation-Composition
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 * SesParticipants SonEquipe L ’agrégation simple est uniquement conceptuelle et ne fait rien d ’autre que distinguer un tout d ’une partie. Je maintiens ma phrase : « un objet ne fait partie que d ’un composite à la fois » cf « la bible » p 157 Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000 Le processus unifié de développement logiciel * * SesParticipants SesEquipes Un objet peut faire partie de plusieurs composites à la fois. F. Schlienger 2004

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

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

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

Relations de généralisation-spécialisation
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() Généralisation Spécialisation A la page 73 de mon document de référence il est dit que les classes les plus spécifiques héritent des classes les plus générales. Le mot héritage est employé. Catherine aurait préféré que je dise classe spécialisée sous-ensemble de la classe générale. COMPTE-EPARGNE -Taux : float +CalculerIntérêts() F. Schlienger 2004

Navigabilité d’une association
Qualité d’une association qui permet le passage d’une classe vers une autre. En général, on peut naviguer dans les 2 sens. On peut cependant limiter la navigabilité : CLASSE-1 CLASSE-2 Nom d’association Exemple : PRODUIT -QttéRéappro +Commander() 1..* 1 FABRIQUANT -Adresse +GetAdresse() SonRéalisateur SesProduits L ’orientation d ’une association a une signification: *conceptuelle : un concept s ’appuie sur un autre dans sa définition et pas l ’inverse *logique : les opérations de classe exploitent les opérations d ’une autre classe SonRéalisateur.GetAdresse * physique : on implémente le moyen d ’accès des représentants d ’une classe vers les représentants de la classe liée. SonRéalisateur : FABRICANT REMARQUE : les noms des rôles sont indispensables lorsqu ’il y a navigabilité. Dans l ’exemple ci-dessus SesProduits peut être omis. Il doit être facile de passer directement d’un produit à son fabriquant. La commande d’un produit fait référence à l ’adresse de « SonRéalisateur » Il y a demande de service (GetAdresse) de PRODUIT à FABRIQUANT. F. Schlienger 2004

Attributs et opérations de classes
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 statiques F. Schlienger 2004

Application au design pattern ‘ singleton ’
Un ‘ singleton ’ permet de référencer l’instance 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 à l’appelant la référence de l objet unique. Utilisation fréquente dans le cas d ’objets centralisateurs tels que ‘superviseur’, ‘contrôleur’, SINGLETON Instance : SINGLETON = null getInstance() : SINGLETON if (instance == null) instance := newSingleton() return instance; Attributs statiques Le singleton se charge de construire l’objet lors du premier appel. F. Schlienger 2004

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 d’implémentation qu’au travers d’une instance d’une 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() F. Schlienger 2004

Classe et Opération abstraites / Polymorphisme
FORME -Couleur : string +CalcSurface() +Type() RECTANGLE CERCLE - Long : float - Larg : float +CalcSurface() + Type() - Rayon : float +CalcSurface() + Type() return PI * Rayon * Rayon return ’rectangle’ Opérations polymorphes return ’cercle’ return Long * Larg F. Schlienger 2004

Attributs et opérations implicites (1)
ETUDIANT Nom : string <constructeur> Etudiant () <destructeur> ~Etudiant() <sélecteur ou accesseur> GetNom () : string <modificateur> SetNom (N:string) : bool ETUDIANT Nom : string Pour la classe on ajoute implicitement : Pour chaque attribut on ajoute implicitement : Ces opérations ne sont pas obligatoirement publiques. SetNom peut ne pas exister.

ETUDIANT Nom : string GROUPE Numéro : int SonGroupe 0..1 ETUDIANT Nom : string SonGroupe : GROUPE <sélecteur ou accesseur> GetSonGroupe () :GROUPE <modificateur> SetSonGroupe(G:GROUPE) RetirerSonGroupe() … si le minimum est à 0 Pour chaque association navigable de cardinalité 0..1, 1..1 on ajoute : un attribut … et les opérations correspondantes

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

ETUDIANT Nom : string OPTION Libellé : string SesOptions 0..* ETUDIANT Nom : string SesOptions : ensemble(OPTION) <modificateur> AjouterOption(O:OPTION):bool RetirerOption(O:OPTION):bool GetSesOptions() : ensemble(OPTION) 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.

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 d’une option. En ajoutant une flèche vers SesEtudiants, on ajoute implicitement SesEtudiants : ensemble (ETUDIANT) dans OPTION et les opérations correspondantes.

REPERTOIRE NomFichier FICHIER 1 Dans répertoire on trouvera une opération : Chercher (NomFichier : string) : FICHIER

Diagrammes d’objets 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 NomInstance:NOMCLASSE Bouton1:RECTANGLE :CERCLE :NOMCLASSE Bouton2:RECTANGLE Longueur : float = 13.5 Nom : string = “bouton-poussoir” Largeur : float = 3.2 F. Schlienger 2004

Diagramme d’objets (exemple)
ENSEIGNANT nom : string enseigne > MATIERE libellé : string * 1..* E1:ENSEIGNANT nom = ‘Dupont’ M1:MATIERE libellé = ‘Génie logiciel’ M2:MATIERE libellé = ‘Réseau’ E2:ENSEIGNANT nom = ‘Martin’ E3:ENSEIGNANT nom = ‘Duval’ M3:MATIERE libellé = ‘Système’ F. Schlienger 2004

Diagramme d’objets (nécessité de préciser l’association)
enseigne > 1..* * ENSEIGNANT nom : string MATIERE libellé : string estResponsable > 0..1 * E1:ENSEIGNANT nom = ‘Dupont’ enseigne M1:MATIERE libellé = ‘Génie logiciel’ estResponsable > E2:ENSEIGNANT nom = ‘Martin’ M2:MATIERE libellé = ‘Réseau’ enseigne estResponsable > E3:ENSEIGNANT nom = ‘Duval’ M3:MATIERE libellé = ‘Système’ enseigne F. Schlienger 2004

F. Schlienger 2004

(2ème partie) Françoise Schlienger 4ème année F. Schlienger 2004

Plan de la deuxième partie
Les diagrammes de cas d’utilisation (Use-Case) 69 Les diagrammes d’interactions Les diagrammes de séquences Les diagrammes de collaboration 102 Les diagrammes d’états Les diagrammes d’activités Les diagrammes de composants Les diagrammes de déploiement

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

Les cas d ’utilisation (2)
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 d’un cas d’utilisation en décrivant les flots d ’événements à l’aide d’un texte. Puis au fur et à mesure que l’on affine sa compréhension des exigences du système, on utilise des diagrammes d’interaction pour préciser graphiquement ces flots.

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

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

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

Relation d’inclusion « include »
Permet d’incorporer le comportement d’un autre cas d’utilisation. Le cas d’utilisation inclus n’est jamais exécuté seul, mais seulement en tant que partie d’un cas de base plus vaste. Le système voiture Garagiste Faire la vidange Réparer <<include>> Activer pont élévateur Remarque : Il est préférable de développer les cas factorisés (« include ») avant ceux qui les utilisent. F. Schlienger 2004

Relation d’extension « extend »
Permet de modéliser la partie d’un cas d’utilisation considérée comme conditionnelle dans le comportement du système. Le système voiture Faire la vidange Garagiste Réparer <<extend>> Il ext préférable de développer les cas qui étendent après les cas de base. Commander pièce F. Schlienger 2004

Spécialisation Le système voiture Réparer Réparer Diesel
Les cas d’utilisation peuvent être hiérarchisés par généralisation/spécialisation. Les cas d’utilisation 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. Le système voiture Réparer Garagiste Il ext préférable de développer les cas qui étendent après les cas de base. Réparer essence Réparer Diesel F. Schlienger 2004

Le cas d’une coopérative de libraires
Ce cas peut être Enregistrer une commande considéré comme exceptionnel. <<extend>> <<include>> Passer une commande urgente Employé <<extend>> Vérifier solvabilité client On peut factoriser des comportements Créer Nouveau Client 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)

Spécification sous forme textuelle (rédigée avec l’aide de l ’utilisateur)
Système : coopérative Acteur primaire : l’employé 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 l’existence du livre (à partir de l ’ISBN) 3 - précision de la quantité Exception : 1a - le libraire n’est pas solvable (l ’employé est informé) 2a - le livre n’existe pas

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

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é

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

Diagrammes d’interaction

Diagramme d’interaction
Les diagrammes d’interaction représentent les objets les uns par rapport aux autres et montrent comment ces objets communiquent au cours d’une interaction. Il existe deux sortes de diagrammes d’interaction : 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.

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.

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

Diagramme de séquence : notation
Inst.1:Acteur CallAction() Inst.3:Class-B Créer() Inst.4:CLASSE-C Détruire() Inst.2:CLASSE-A - une ligne de vie par objet ou par acteur - distinguer le message synchrone du message asynchrone - le message de retour peut ne pas apparaître sur le diagramme - on peut ajouter des contraintes temporelles - on peut aussi ajouter des conditions (des gardes) devant les messages F. Schlienger 2004

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

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

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

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

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

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

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

Diagramme de séquence : branchement conditionnel
(2 objets différents) Instance:CLASSE1 Instance1:CLASSE2 Instance2:CLASSE3 [X] CallAction1() [non X] CallAction2()

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

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

Diagramme de séquence en escalier (décentralisé)
On parle aussi de délégation ou propagation des messages . Instance:A Instance1:B Instance2:C Instance3:D Instance4:E CallAction()

Diagramme de séquence en fourche (centralisé)
On parle aussi de supervision (un objet envoie tous les messages) Instance:A Instance1:B Instance2:E Instance3:C Instance4:D CallAction()

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

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

Spécification sous forme de diagramme de séquence (trop centralisé)
Monsieut TRUC:LeResponsable C :COMMANDE-LIB L :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é}}

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.

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

Diagramme de classe CATALOGUE LIVRE LIGNE-COMMANDE COMMANDE-LIB
LIBRAIRE REGISTRE-LIBRAIRE +Solvable?():boolean -NumLib : integer -NomLib : string -AdresLib : string -Etat : string +GetSesCommandes() +GetDétailCommandes() -SesLivres * -NumCom : integer -SesCommandes +SolvableLibraire?(In Numéro:integer):boolean +GetSesLibraires() SonCatalogue 1 +TrouverLivre(In numéro:integer):LIVRE +AjouterLivre(In L:LIVRE) +TrouverLibraire(In Numéro:integer):LIBRAIRE SonRegistre -SesLibraires -SonDemandeur -NumISBN : integer -Titre : string -DateEdition : Date +GetTitre():string +Créer(In Numéro:integer ,In Titre:string ,In DateEdit:Date) +GetNumISBN():integer -Quantité : integer +MajQtté(In Nb:integer) +GetQuantité():integer +GetInfoLigne() +GetSonLivre():LIVRE -DateCom : Date -SaCommande -SesLignes -SonLivre -SesDemandes +Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Qtt:integer) +Créer() +GetDateCom():Date +GetDétailCommande() +GetSesLignes(): Set (n)LIGNE-COMMANDE +AjouterLigne(In L:LIGNE-COMMANDE) EDITEUR -Nom : string -Adresse : string SesLivres SonEditeur

Diagrammes d’états

Le diagramme d’états Un diagramme d’état modélise l’existence (cycle de vie) d’un 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.

Les états Un état correspond à la manière d’être d’un objet pendant un intervalle de temps plus ou moins long. Un état se compose de plusieurs parties : le nom les actions d’entré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 n’occasionnent aucun changement d’état). F. Schlienger 2004

Transitions et Evénements
Une transition indique le passage d’un é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ée En veille Mise sous tension Evénement

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 d’un événement qui se produit alors on peut mentionner l’action : « defer ». Cela permet d’insister sur le fait que l’événement peut arriver mais qu’il 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.

Forme générale d’un é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 F. Schlienger 2004

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/action2m 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. J’ai repris le guide de notation fourni par Rational ( j ’ai celui de la version 1) dans lequel il est dit qu ’il y avait un / entre entry et action et non pas 2 points. J ’ai verifié sur les logiciels : Rational met : et Objecteering met / F. Schlienger 2004

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

Diagramme d’états 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 qu’un livre est enregistré il est mis à disposition ENREGISTREMENT do / enregistrer A DISPOSITION entry / placer When 15 heures En général on utilise ce type de transition lorsqu’il y a une activité qui s’interrompt d’elle même. L’événement implicite est « fin d’activité ». ENREGISTREMENT do / enregistrer A DISPOSITION entry / placer F. Schlienger 2004

É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- 3 Event-2 Event-4 F. Schlienger 2004

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. EN FONCTION Event-1 EN-ENREGISTREMENT HORS FONCTION Event-5 Cet exemple peut être repris en TD en le compliquant. Les noms des événements peuvent être précisés et on peut ajouter des états car il est peu probable qu ’on entre directement en phase d ’enregistrement. Event-2 Event- 3 Event-6 Event-4 EN-DIFFUSION EN VEILLE Event-7 F. Schlienger 2004

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

É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é. Point d’entrée pour la première fois. Etat1 Etat2 Etat3 Etat4 Event-1 Event-5 Event- 3 Event-2 Event-4 H F. Schlienger 2004

É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. H En lavage Mise en fonctionnement Arrêtée Arrêt En rinçage Fin du cycle En essorage F. Schlienger 2004

Diagramme d’états : exemple de la montre
Une montre digitale simple possède un cadran et 2 boutons que l’on nomme A et B, pour la mettre à l’heure. La montre a deux modes d’opération : affichage de l’heure et mise à l’heure. Le mode de mise à l’heure a deux sous-modes, heures et minutes. Le bouton A s’utilise pour les modes. A chaque fois que l’on 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 s’emploie pour avancer les heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement. F. Schlienger 2004

Diagramme d’états EnModification AppuyerA on AppuyerB/IncrémenterH()
EnAffichageHeure AppuyerA EnModificationH on AppuyerB/IncrémenterH() EnModificationM on AppuyerB/IncrémenterM() EnModification F. Schlienger 2004

La montre : diagramme de classes
-Heures : integer -Minutes : integer +AppuyerA() +AppuyerB() -IncrémenterH() -IncrémenterM() L ’événement sur le diagramme d ’état est une demande de service dont la réponse est une méthode de même nom (méthode publique puisque l ’événement vient de l ’extérieur. Les méthodes d ’incrémentation sont par contre privées. Seul l ’objet montre peut les activer. F. Schlienger 2004

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

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 l’opé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

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 SetLumière(‘faux’) Eteindre Allumer

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 à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).

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

Les événements temporels
Les événements temporels sont causés par l’expiration d ’une temporisation. Ils peuvent être : absolus ( spécification d’une date ou d’une 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 francs Monnaie en euros when date = 1/01/02

Les événements temporels
relatifs (spécification d’une 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 consommable when date du jour >= date limite Ouverture flacon Médicament consommé after 10 jours Médicament périmé

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 SetLumière(‘faux’) Eteindre Allumer

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 à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).

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

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. L’association représentée par une ligne continue qui peut être fléchée (navigation). L’agré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. Il ext préférable de développer les cas qui étendent après les cas de base. F. Schlienger 2004

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

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:Classe objet: [état] [cond.1] [cond.2] F. Schlienger 2004

Commander produit Traiter commande Sortir article Expédier commande
Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture Attention on n ’a pas tout à fait la même vision qu ’en Merise. On regarde ce qui se passe du coté des acteurs. Il n ’est pas obligatoire de préciser le flots d ’objets (facture) Recevoir paiement Clôturer commande F. Schlienger 2004

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 d’activité divisé en travées, chaque activité appartient à une seule travée, même si les transitions peuvent passer d’une travée à l’autre. Les travées sont délimitées par des barres verticales. Chaque travée a un nom.

Client Service ventes Entrepôt
Commander produit Traiter commande Sortir article Expédier commande Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture Attention on n ’a pas tout à fait la même vision qu ’en Merise. On regarde ce qui se passe du coté des acteurs. Il n ’est pas obligatoire de préciser le flots d ’objets (facture) Recevoir paiement Clôturer commande F. Schlienger 2004

Client Service ventes Entrepôt
Commander produit Traiter commande Sortir article Expédier commande Recevoir commande Facturer commande Recevoir facture Expédier facture Payer facture f: facture[due] Attention on n ’a pas tout à fait la même vision qu ’en Merise. On regarde ce qui se passe du coté des acteurs. Il n ’est pas obligatoire de préciser le flots d ’objets (facture) Recevoir paiement f: facture[payée] Clôturer commande F. Schlienger 2004

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

Les composants (2) Composant1 Composant1 Class1 Class2 Class2 Class1
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 qu’implémente un composant par une liaison : Composant1 Class1 Class2 Composant1 Class1 Class2 F. Schlienger 2004

<<interface>>
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 <<interface>> F. Schlienger 2004

Composants standards UML définit 5 stéréotypes standard qui s’appliquent 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, d’installation, document d’aide …) F. Schlienger 2004

Les diagrammes de composants
Ils montrent l’organisation et les dépendances au sein d’un 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 d’association de réalisation F. Schlienger 2004

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

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

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. F. Schlienger 2004

Les diagrammes de déploiement
Ils permettent de représenter l’architecture physique d’un système en visualisant les classes de nœuds (ou des instances de nœuds) et les relations de dépendances et d’associations 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 F. Schlienger 2004

Les diagrammes de déploiement avec des icônes
F. Schlienger 2004

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

Diagramme de déploiement : diagramme d’instances
k1:kiosque s:Serveur vitesseProcesseur = 2Ghz mémoire=256Mo t:tour de disques RAID k2:kiosque c1:console

De l’analyse … à la conception
Analyse des besoins L’analyse des besoins est l’activité essentielle au début du processus de développement d’un logiciel. Le futur utilisateur exprime ses besoins sous une forme textuelle informelle, parfois accompagnée de modèles d’IHM permettant de mieux préciser des souhaits.

Le cas bibliothèque. La bibliothèque d’une école d’ingé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.

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.

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

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

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

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

Le cas bibliothèque : cas d’utilisation
Enregistrer Retour EnregistrerRetourAnonyme Bibliothécaire EnregistrerRetourEtudiant

Spécification globale (2)
Il s’agit 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 d’analyse ne mettant en évidence que peu d’opérations. Par contre les attributs évoqués (caractéristiques d’un livre, d’un emprunteur, etc.) dans les cas d’utilisation ainsi que toutes les associations suggérées (emprunt caractérisé comme une association entre LIVRE et PERSONNE) devront y figurer.

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

Spécification détaillée des exigences
Une fiche de description textuelle de chaque cas d’utilisation 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 d’utilisation pour que celui-ci puisse démarrer. Les post conditions qui définissent ce qui doit être vrai lorsque le cas d’utilisation se termine.

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 qu’il 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.

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 n’est pas déjà empruntée. Il existe une instance de Personne avec numéro NumP. post : not Valide implies echec.sent() Valide implies L’instance de Livre avec numéro NumL a comme emprunteur la Personne avec numéro NumP. L’instance de Livre avec numéro NumL figure dans les emprunts de la Personne avec numéro NumP.

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)

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 L’instance de Livre avec numéro NumL n’a pas d’emprunteur L’instance de Livre avec numéro NumL ne figure pas dans les emprunts de la Personne qui l’avait avant l’enregistrement de retour.

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)

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

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

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

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 l’organisation d’une entreprise, appelées classes « métier ». Elles sont souvent permanentes. Les classes qui contiennent la cinématique de l’application, 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.

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 l’application. Métier MM donnée1 donnée2 donnée3 opér1() opér2()

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 l’attribut dérivé. Les opérations représentent des actions de l’utilisateur sur l’ IHM, ou des actions de la classe de contrôle. Dialogue DD champ1 champ2 /résultat action1() action2() saisir ou afficher

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

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

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

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

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

La conception Elle vise principalement à préciser le modèle d’analyse de telle sorte qu’il puisse être implémenté avec les éléments d’architecture 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 s’ils 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.

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

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

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

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

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 s’y rapportant en recto-verso. Ne JAMAIS présenter des diagrammes se rapportant au même problème sur des pages recto-verso.

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 d’attributs, d’opé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.

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 l’objet qui contient l’opé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)

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

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

Règles de définition des diagrammes de séquence (suite)
Lorsqu’un message est adressé à plusieurs instances I d’une 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 l’ensemble 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.

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 d’opérations publiques de l’objet pour lequel est fait le diagramme d’état. Les opérations effectuées en entrée ou en sortie d’un état, et les opérations effectuées au sein d’une activité sont des opérations privées de l’objet 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.

ETUDIANT Nom : string OPTION Libellé : string SesVoeuxDOptions 0..* {ordonné} ETUDIANT Nom : string SesVoeuxDOptions : liste(OPTION) <modificateur> AjouterOption(OPTION):bool EnleverOption(OPTION):bool GetSesOptions() : liste(OPTION) L’introduction de la contrainte {ordonné} permet de traiter SesVoeuxDOption comme une liste

Diagramme de déploiement : exemple des portes (diagramme de spécification)
Serveur SGBD PC Pilote Portes TX RNIS 1 * TCP/IP Console 3 Maître 1..10 Imprimante Ce diagramme représente des classes de nœuds. On peut y ajouter des informations de multiplicité. On ne connaît pas le nombre de PC. Par contre chaque PC est le maître de 10 portes. On dispose de 3 terminaux X qui jouent le rôle de consoles. Une imprimante est reliée au serveur. F. Schlienger 2004

Diagramme de déploiement : exemple des portes (diagramme d’instances)
PC4 : PC P2 :Porte P3 : Porte P1 : Porte Ce diagramme représente des classes de nœuds. On peut y ajouter des informations de multiplicité. On ne connaît pas le nombre de PC. Par contre chaque PC est le maître de 10 portes. On dispose de 3 terminaux X qui jouent le rôle de consoles. Une imprimante est reliée au serveur. Remarque : les instances sont soulignées. F. Schlienger 2004

Exemple de base F. Schlienger 2004

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

F. Schlienger 2004

(3ème partie) Françoise Schlienger FIIFO F. Schlienger 2004

Plan de la troisième partie
Les diagrammes d’activités Les diagrammes de composants Les diagrammes de déploiement De l’analyse … à la conception

F. Schlienger 2004.

Présentations similaires

Présentation au sujet: "F. Schlienger 2004."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

F. Schlienger 2004.

Présentations similaires

Présentation au sujet: "F. Schlienger 2004."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back