Le processus unifié et la notation UML Notes personnelles...

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM UML1 : L'approche orientée objet: Principes ......................................................................................... 3

L'objet ...................................................................................................................................................... 3 Identité ................................................................................................................................................. 3 Les attributs et l'état ............................................................................................................................. 3 Comportement ..................................................................................................................................... 3 Les liens entre les objets ...................................................................................................................... 3 L'encapsulation .................................................................................................................................... 3

Les classes: La démarche d’abstraction .................................................................................................... 3 Description ........................................................................................................................................... 4 Les objets, instances de classes ............................................................................................................ 4 Les relations entre les classes:l’association .......................................................................................... 4 Les relations entre les classes:L’agrégation ......................................................................................... 4 Les hiérarchies de classes:L'héritage .................................................................................................... 4

Généralisation et spécialisation ................................................................................................................ 4 Généralisation ...................................................................................................................................... 4 Des ensembles aux classes ................................................................................................................... 4 Le polymorphisme, principe général .................................................................................................... 4 Le polymorphisme, Influence du typage .............................................................................................. 5

UML 2 : La notation unifiée UML et processus unifié ............................................................................ 6 Processus de développement: principes .................................................................................................... 6 Processus de développement: activités ..................................................................................................... 6 Diagrammes d'UML ................................................................................................................................. 6 La capture des besoins: l’acquisition, la spécification .............................................................................. 7 Diagramme de cas d’utilisation ................................................................................................................ 7 Intérêt ...................................................................................................................................................... 7 Les concepts ............................................................................................................................................. 7 L’acteur .................................................................................................................................................... 7 Les cas d’utilisation .................................................................................................................................. 7 Le modèle de cas d'utilisation .................................................................................................................. 7 Raffinement des cas d'utilisation : la relation « include », la relation «extend » ....................................... 7 Les cas d'utilisation .................................................................................................................................. 7 Description des cas d'utilisation ............................................................................................................... 7 Règles de mise en oeuvre des cas d'utilisation ......................................................................................... 7 Construction des cas d'utilisation ............................................................................................................. 7 Processus d'élaboration des cas d'utilisation ............................................................................................. 7 Résumé .................................................................................................................................................... 7

UML 3 : De l’analyse des besoins à la conception .................................................................................... 8 Des cas d’utilisation aux diagrammes de classes ...................................................................................... 8 Diagrammes de classes ............................................................................................................................. 8 Stéréotypes des classes d’analyse ............................................................................................................. 8 Classe ....................................................................................................................................................... 8 Instance de classe : objet .......................................................................................................................... 8 Attributs ................................................................................................................................................... 8 Associations ............................................................................................................................................. 8 Multiplicité ............................................................................................................................................... 8 Opérations ................................................................................................................................................ 9 Du besoin aux classes ............................................................................................................................... 9 Contraintes sur les associations ................................................................................................................ 9 Restriction (qualification pour UML) d’une association - ...................................................................... 9 Agrégation - ......................................................................................................................................... 9 Composition - ..................................................................................................................................... 10

Félix BERNARD 1/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM

agrégation vs. composition .................................................................................................................... 10 Classe & objet composite ....................................................................................................................... 10 Diagramme d’objet ................................................................................................................................. 10 Navigation .............................................................................................................................................. 10 Relation et navigation ............................................................................................................................. 10 Généralisation ........................................................................................................................................ 10 Résumé ................................................................................................................................................... 11 Exercice de cours ................................................................................................................................... 11

UML 4 : Les interactions entre les objets Diagramme de séquence & Diagrammes de collaboration .................................................................... 12

Envoi de message ................................................................................................................................... 12 Interaction et collaboration ..................................................................................................................... 12 Diagramme de séquence ........................................................................................................................ 12 Classes interface, contrôle (toujours séparer les 2) et entité ................................................................... 12 Création et destruction des objets ........................................................................................................... 12 Message synchrone / asynchrone ........................................................................................................... 13 Messages réflexifs ou récursif objet simple ou objet composite ............................................................. 13 Branchements conditionnels ................................................................................................................... 13 Notes ...................................................................................................................................................... 13 Arguments .............................................................................................................................................. 13 Diagramme de collaboration .................................................................................................................. 14

{local} {nouveau} {détruit} {provisoire} créé et détruit dans la même action .................................. 14 Représentation condensée de famille de lien (= plusieurs instances) ................................................. 14 Acteur ................................................................................................................................................ 14 Objets actifs ....................................................................................................................................... 14

Représentation des messages .................................................................................................................. 15 Point de synchronisation ................................................................................................................... 15 Séquences .......................................................................................................................................... 15 Arguments .......................................................................................................................................... 15

Vérifier la cohérence des modèles .......................................................................................................... 15 Résumé ................................................................................................................................................... 15

UML 4 : Spécifier les opérations et les contrôles Diagramme d’activités & Diagrammes d’état transition ...................................................................... 16

Pourquoi spécifier .............................................................................................................................. 16 Service entre objets ............................................................................................................................ 16 Spécifier une opération comme un contrat ......................................................................................... 16 Spécifier la logique de l‘opération .................................................................................................... 16 Table de décision ............................................................................................................................... 16 pré conditions: /post-conditions: ........................................................................................................ 16 Langage naturel structuré .................................................................................................................. 16

Flots d‘objets .......................................................................................................................................... 17 Diagramme d’activités ........................................................................................................................... 17

Gardes Synchronisation Couloir d’activité ....................................................................................... 17 Diagramme d’état transition ................................................................................................................... 17

Etat ..................................................................................................................................................... 17 Diagramme ........................................................................................................................................ 18 Evénement ........................................................................................................................................ 18 Opération, action activité ................................................................................................................... 18 Généralisation d’états ......................................................................................................................... 19

Félix BERNARD 2/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM UML1 : L'approche orientée objet: Principes

L'objetUnité formée de l’union d’un état interne (des attributs) et d’un comportement (des opérations) qui a une origine dans le monde réel et a sa propre identité.

IdentitéImmuable ; Permanente ; Egalité, Deux objets peuvent être égaux (attributs et associations) et correspondre à deux objets différents ayant chacun son identité.

Les attributs et l'étatLes attributs représentent les caractéristiques d'un objet ; Un attribut est constitué du couple (nom, valeur)Les valeurs prises par les attributs les associations déterminent l'état d'un objet à un instant donné.

ComportementConcept d'opérations (méthodes) ; Une opération est déclenchée suite à une stimulation externe: message envoyé par un autre objet.

Les liens entre les objetsLes associations représentent les liens d'un objets vers les autres objets ; Les association peuvent être des agrégations (composition) ou des références ; Liens statiques ou dynamiques ; auteur, serveur agent (auteur et serveur à la fois)

L'encapsulation"L'encapsulation est le processus qui consiste à compartimenter des éléments d'une abstraction pour constituer sa structure et son comportement" (Booch 1995)

Les classes: La démarche d’abstractionIdentification des caractéristiques (structure et comportement) communes à un ensemble d'éléments ; Description condensée de ces caractéristiques.

DescriptionSpécification : décrit le domaine de définition et les propriétés des instances de cette classe (notion de type dans les langages de programmation classiques).Réalisation : décrit comment la spécification est réalisée et qui contient le corps des opérations et les données nécessaires à leur fonctionnement.

Les objets, instances de classesOn invoque une classe quand on instance un objet, on instance les attributs mais pas les opérations

Félix BERNARD 3/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM Les relations entre les classes:l’associationConnexion sémantique bidirectionnelle entre classes ; message

Les relations entre les classes:L’agrégationConnexion bidirectionnelle dissymétrique

Les hiérarchies de classes:L'héritageLa spécialisation et la généralisation conduisent à définir des relations de sous typage et à mettre en évidence l’héritage

Généralisation et spécialisation

Généralisation« est un ou est une sorte de ». permet la création de l’ancêtreRelation non réflexive ; non symétrique, transitive

Des ensembles aux classesLes objets instances d’une classe partagent des caractéristiques générales, exprimées sous forme d’attribut, d’opération et de contrainte. C’est la propriété caractéristique de l’ensemble des instances.La propriété caractéristique de X est notée P(X). L’ensemble X peut être divisé en sous-ensembles.

Notion de classe abstraite: Tous les objets instances d’une classe abstraite donnée appartiennent à l’une de ses sous-classes ; Une classe abstraite ne donne pas directement des objets.

Le polymorphisme, principe généralLes interactions entre objets sont écrites selon les termes des spécifications définies dans leurs superclasses.Dans ce cas, on parle de polymorphisme d’opération: déclencher des opérations différentes en réponse à un même message. Une sous-classe peut modifier localement le comportement d’une opération héritée d’une superclasse.

Le polymorphisme, Influence du typageLe polymorphisme existe dans des environnements typés et non typés. Seuls les environnements typés garantissent une exécution sans surprise des programmes.Ne pas confondre le polymorphisme (mêmes variables de même type) avec la surcharge des opérations (seul le nom de la méthode est identique). Rien à voir avec la liaison dynamique: résolue statiquement par les compilateurs.

Félix BERNARD 4/18


UML 2 : La notation unifiée UML et processus unifié

Processus de développement: principesLe processus unifié (USDP Jacobson et al;99) est censé regrouper les pratiques de conception de SI les plus reconnus impliquant un développement:

• itératif et incrémental;• fondé sur les composants;• orienté par les besoins;• Configurable;• Centré sur l’architecture;• Utilisant des techniques visuelles de modélisation.

Processus de développement: activitésPhases du projet et activité de développement

• Capture et modélisation des besoins• Analyse des besoins• Conception du système• Conception détaillée des classes• Conception des interfaces utilisateur• Conception de la gestion des données• Implémentation• Tests

Diagrammes d'UMLStatiques : Cas d’utilisation ; Classes; Objets; Composants; Déploiement Dynamiques : Séquence; États –Transitions; Activité; Collaboration• Diagramme de cas d’utilisation: fonctions du système du point de vue de l’utilisateur• Diagramme de classes: structure statique en termes de classes et de relations• Diagramme de séquence: représentation temporelle des objets et de leurs interactions• Diagramme de collaboration: représentation spatiale des objets, des liens et des interactions• Diagramme d’objets : Objets et leurs relations. Diagrammes de collaboration simplifiés, sans représentation des envois de message• Diagramme d’états transitions: comportement d’une classe en termes d’états• Diagramme d’activités: comportement d’une opération en termes d’actions• Diagramme de déploiement: déploiement des composants sur les dispositifs matériels• Diagrammes de composants: composants physiques d’une application.

Félix BERNARD 5/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM La capture des besoins: l’acquisition, la spécification

Diagramme de cas d’utilisation

Intérêt

Les conceptsIl comprend les acteurs, le système et les cas d'utilisation eux mêmes.

L’acteur

Les cas d’utilisation

Le modèle de cas d'utilisation

Raffinement des cas d'utilisation : la relation « include », la relation «extend »

Les cas d'utilisationCas d’utilisation ; scénario

Description des cas d'utilisation

Règles de mise en oeuvre des cas d'utilisation

Construction des cas d'utilisation

Processus d'élaboration des cas d'utilisation

Résumé • L’objectif des diagrammes de cas d’utilisation• La notation des diagrammes de cas d’utilisation• Comment les dessiner• Comment les décrire• Comment les construire.

Félix BERNARD 6/18


UML 3 : De l’analyse des besoins à la conception

Des cas d’utilisation aux diagrammes de classesPourquoi analyser les besoins ?Finalité d’un modèle d’analyseComment construire un modèle d’analyse ?

Diagrammes de classesStructure statique – classe & relation (objet & lien)

Stéréotypes des classes d’analyse« Interface » |-O « control » O^ « entity » _O_

ClasseNom de classeattributsopérations

Ou Nom de classe

Instance de classe : objetNom d’objet : Nom de classe ou : Nom de classeAttribut: Valeur de l’attributPas de compartiment opération

AttributsPas d’identification! Pas d’id! Différence avec Merise !

AssociationsRelation structurelle (et non comportementale) durable dans le temps à l’échelle du systèmeC’est une association (et non classe) si son existence dépend des autres entitésNotation Nom d’association (verbe, italique)

Rôle d’association (ex personne- avion on a 2 rôles pilote passager)Flèche de lecture (►)

Association n-aire Classe associative ex : pour un couple joker, course, on n’associe qu’un cheval donc cardinalité vers cheval = 1Association réflexive : lien sur 2 instances différentes ou sur un même objet

Multiplicité1 / 0..1 / M..N / * = 0..* / 1..*Si >1 → collection Affinage entre l’analyse (valeur multiplicité) et la conception (structure : pile, file…)

Placement des attributs selon la multiplicité :Si 1 vers 1 (objets ayant leur propre existence) pas de classe associativeSi 1 vers N les attributs migrent vers la classe à multiplicité NSi N vers N réification ?

Félix BERNARD 7/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM OpérationsDéfinissent les fonctions appliquées à des objets d’une classeAttributs dérivés (ou calculés ?) /attribut en analyse deviendra une fonction en conceptionVisibilité (attributs & opérations) + public # protégé - privéVariables & opérations de classe sont soulignées

Du besoin aux classesDémarche

1 point de départ : un cas d’utilisation2 réalisation du cas d’utilisation (on fait apparaître les objets)3 construire le diagramme de collaboration4 identifier les classes candidates5 itération

Vérifier la pertinence des classes identifiées si un oui, alors à reconsidérer• Est ce qu‘elle est en dehors de la problématique du système?• Est ce qu‘elle répète ce qui est déjà représenté dans d‘autres classes? • Est ce qu‘elle est vague? • Est ce qu‘elle est trop liée à des choix techniques ou d‘implantation?• Est ce qu‘elle ne serait pas un attribut, une opération ou une association?

Contraintes sur les associationsMultiplicité{ordered} : relation d’ordre dans les objets de la collection{include} : collection incluse dans une autre collection{XOR} : pour un objet donné, une seule association parmi le groupe proposé est valideAssociation réflexives : le nommage des rôles est essentiel à la clarté du diagrammeAssociation représentée comme classe associative, classe comme les autres - - - -

Restriction (qualification pour UML) d’une association -sélection d’un sous-ensemble d’objets parmi les objets qui participent à une association. Réalisée au moyen d‘une clé, ensemble d‘attributs particuliers et utilisé avec un objet de la classe de départ. La clé appartient pleinement à l‘association et non aux classes associées. Chaque instance de la classe A accompagnée de la valeur de la clé, identifie un sous-ensemble des instances de B qui participent à l‘association

Agrégation -Représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l‘autre extrémité. Quelle que soit l‘arité, l‘agrégation ne concerne qu‘un seul rôle d‘une association. Les critères suivants impliquent une agrégation:

• une classe fait partie d‘une autre classe; • les valeurs d‘attributs d‘une classe se propagent dans les valeurs d‘attributs d‘une autre

classe• une action sur une classe implique une action sur une autre classe

Félix BERNARD 8/18


• les objets d‘une classe sont subordonnés aux objets d‘une autre classe

Composition -Agrégation réalisée par valeur sur des attributs: composition. Ils sont physiquement contenus dans l‘agrégat. La composition implique une contrainte sur la valeur de la multiplicité du côté de l‘agrégat: elle ne peut prendre que les valeurs 0 ou 1. Le composant a le droit d’exister à lui tout seul. La valeur 0 du côté du composant correspond à un attribut non renseigné.

agrégation vs. composition L‘agrégation représente une relation de partie-de. La sémantique peut être imprécise La composition est une relation plus « forte »:

• Chaque partie peut appartenir à un et un seul tout à un instant donné. • Lorsque le tout est détruit (n‘a plus d‘existence) il en est de même pour toutes les parties

qui le composent.

Classe & objet composite Classes fournissent une abstraction de leurs composants. Un objet composé de sous objets ou instance de classes composites

Diagramme d’objetGrande similitude avec les diagrammes de classes

NavigationLes liens, instances des associations, peuvent être vus comme des canaux de navigation entre les objets, instance des classes.Par défaut, les associations sont navigables dans les deux directions. –Si une seule direction est utile, flèche A → B, de A, on peut remonter vers B, mais pas l’inverse

Relation et navigationUML définit un pseudo langage pour représenter les chemins au sein des diagrammes de classes (OCL). Syntaxe donnée par 4 règles:

• cible :: = ensemble ” . ‘ sélecteur sélecteur (ex : parent)• cible :: = ensemble ” . ‘ ” ~ ‘sélecteur inverse (ex : enfant)• cible :: = ensemble ” [ ‘ expression_booléenne ” ] ‘ restriction(booléen)• cible :: = ensemble ” . ‘ sélecteur ” [ ‘ valeur_de_clé ” ] restriction(clé)

GénéralisationLa généralisation s‘applique principalement aux classes, aux paquetages et aux cas d'utilisation. Dans le cas des classes, la relation de généralisation signifie est un ou est une sorte de.

Félix BERNARD 9/18

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM RésuméA quoi sert l‘analyse des besoins Les concepts du diagramme de classes Comment passer des besoins au diagramme de classes Comment réaliser un cas d‘utilisation par un diagramme de collaboration et un diagramme de classes

Exercice de cours1er : quelle est la classe principale ? ici commande2èm : que connaît-on de la commande ?Aller du simple au plus compliqué

Félix BERNARD 10/18


UML 4 : Les interactions entre les objets Diagramme de séquence & Diagrammes de collaboration

Envoi de messageLes objets communiquent par des messages (couplage) qui vont devenir des fonctions

Interaction et collaborationCollaboration : ensemble formée par la structure des instances participant à un comportement et par les liens qui les lient.Interaction : contient un ensemble de messages partiellement ordonné.

Diagramme de séquence Les interactions entre objets selon un point de vue temporel.Dimension verticale est le temps, objet, messages, activation

Classes interface, contrôle (toujours séparer les 2) et entité

Création et destruction des objets


Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM Message synchrone / asynchrone

Synchrone (retour implicite)

Asynchrone (retour explicite)

Messages réflexifs ou récursif objet simple ou objet composite

Objet simple (meilleur lisibilité) ou objet composite

Branchements conditionnels

Notes

ArgumentsPseudo code, langage de programmationou représentation graphique



Diagramme de collaborationLes interactions entre objets, en insistant sur la structure spatiale statique qui permet la mise en collaboration d'un groupe d'objets. Extension des diagrammes d'objets. Représentation des interactions :Le contexte d'une interaction comprend les arguments, les variables locales créées pendant l'exécution, ainsi que les liens entre les objets qui participent à l'interaction. Les messages sont numérotés pour indiquer l’ordre des envois (l’agencement organisationnel des taches)Les diagrammes de collaboration montrent simultanément les interactions entre les objets et les relations structurelles qui permettent ces interactions

{local} {nouveau} {détruit} {provisoire} créé et détruit dans la même action

Représentation condensée de famille de lien (= plusieurs instances)

Acteur

Objets actifsObjets qui possèdent un flot de contrôle. Objet actif peut activer un objet passif pour le temps d’une opération, en lui envoyant un message. Une fois le message traité, le flot de contrôle est restitué à l’objet actif.


Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM Représentation des messagesSyntaxe synchronisation séquence ':' résultat ':=' nom arguments

Point de synchronisation synchronisation :: = rang {',' synchronisation } '/' rang ::= [entier|nom du flot d’exécution] {'.' Rang}

SéquencesRécurrence, itération, condition, résultatLes expressions suivantes donnent quelques exemples de la syntaxe d'envoi des messages:

4 : Afficher (X, Y) --message simple3.3.1 : Afficher (X, Y) --message imbriqué4.2 : âge := Soustraire (Aujourd'hui, DateDeNaissance)[Age>= 18 ans] 6.2 : Voter () --message conditionnel4.a, b.6 / c.1 : Allumer (Lampe) --synchronisation1 * : Laver () --itération3.a, 3.b / 4*||[i:= 1..n] : Éteindre () --itération parallèle

ArgumentsPseudo code, langage de programmation ou représentation graphique

Vérifier la cohérence des modèlesLa définition des opérations dans les classes doit être cohérente avec les massages et les signatures de ces opérations avec les arguments des messages. Tout objet à l‘origine d‘un message doit avoir la référence de l‘objet destination du message

• à travers une association, ou un chemin d‘associations • cette étape est importante pour la définition des associations dans le diagramme de classe

(essentiellement celui de la conception) • Il est nécessaire de bien vérifier tous les chemins des messages.

Les diagrammes de séquence et de collaboration doivent être cohérents entre eux. Les diagrammes de séquence et de collaboration doivent être cohérents avec les diagrammes d‘état transition des objets impliqués.Ex de navigabilité : A-B bidirectionnelle, A→B on ne doit pas avoir de message de B vers A

RésuméComment développer des collaborations à partir des cas d‘utilisation Comment modéliser des collaborations avec des diagrammes de séquence Comment développer des collaborations avec des diagrammes de collaboration Comment vérifier la cohérence des diagrammes.



UML 4 : Spécifier les opérations et les contrôles Diagramme d’activités & Diagrammes d’état transition

Pourquoi spécifierAnalyse / conception / tests

Service entre objets

Spécifier une opération comme un contratLe contrat se focalise uniquement sur les entrées et les sorties.Ce qui importe c‘est ce qui doit être livré et non le comment.La spécification comporte :

• L‘objectif de l‘opération• Sa signature (paramètres transmis et retournés)• Une description de sa logique œ les éventuels opérations appelées• Les attributs modifiés• La réponse aux exceptions

Spécifier la logique de l‘opération Deux types de spécifications:Non algorithmique

• technique de boite noire • à utiliser quand l‘arrivée à des résultats corrects importe plus que la manière de les obtenir • arbres de décision, tables de décision, pré et post conditions

Algorithmique • Convient lorsque l‘on a une bonne compréhension de la manière d‘atteindre le résultat • Applique des techniques descendante pour maîtriser la complexité des opérations • Pseudo langage structuré, diagrammes d‘activités

Table de décision

pré conditions: /post-conditions:

Langage naturel structuré • Séquences d‘instructions - Les instructions sont exécutées les unes après les autres• Choix parmi un ensemble d‘instructions (ou de groupes d‘instructions) alternatives si …

sinon…



• Itération (répétition) d‘instructions (ou de groupes d‘instructions) tant que…fin…

Flots d‘objetsUn concept qui permet de représenter la disponibilité d‘un objet dans un état donné. Ne correspond pas à l‘invocation d‘une action et le contrôle passe à l‘étape suivante. Il permet de représenter des contraintes sur les entrée/sorties des activités.

Les pointillés ont la même sémantique que la transitionOrdonnancement des étapes

Etat initial État final Fork et join

Diagramme d’activitésLes activités sont reliées par des transitions automatiques. Lorsqu'une activité se termine, la transition est déclenchée et l'activité suivante démarre. Les activités ne possèdent ni transitions internes, ni transitions déclenchées par des événements.

Gardes Synchronisation Couloir d’activité

Et spécifier les contrôles textuellement.

Diagramme d’état transition

Etat« Un état est une condition durant la vie d‘un objet ou d‘une interaction pendant laquelle il remplie une certaine condition, accomplie une action ou attend un évènement… Conceptuellement, un objet reste dans un état durant un intervalle de temps. … »OMG, 2001 Notion de duré et de stabilité ; image de la conjonction de liens et de valeurs d’attributs.


Commander Commande (passée)

Facturer Commander Facturer=

Le processus unifié et la notation UML Notes personnelles d’après cours de méthodologie des systèmes d’information - CNAM DiagrammeUn seul Ei / zéro, un ou + Ef (conditions de fin différentes) /plusieurs état intermédiairesTransition états distincts ou non

Evénement syntaxe : Nom_De_L_Événement (Nom_De_Paramètre : Type, …)Spécification complète Nom de l'événement / liste des paramètres / l'objet expéditeur / l'objet destinataire / la description de la signification de l'événement. Types d‘événements Événement-changement( change event) survient lorsqu‘une condition devient vraie. Événement-appel (call event) survient lorsque l‘objet reçoit un appel à l‘une de ces méthodes d‘un autre objet ou de lui même. Événement-signal( signal event) survient lorsque l‘objet reçoit un signal ( communication asynchrone). Temps-écoulé(elapsed-event) is caused by the passage of a designated period of time after a specified event (frequently the entry to the current state) La communication par événement est de type asynchrone, atomique, et unidirectionnelle. Un objet peut envoyer un événement à un autre objet qui doit toujours être à même de l'interpréter. Les besoins de communication par événements synchrones ou les échanges bidirectionnels peuvent se représenter au moyen de deux échanges asynchrones de direction opposée.

Garde

Opération, action activitéPoints d‘exécution des opérations 6 points pour spécifier les opérations, dans l'ordre d'exécution



œ l'action associée à la transitiond'entrée (Op1);œ l'action d'entrée de l'état (Op2);œ l'activité dans l'état (Op3);œ l'action de sortie de l'état (Op4);œ l'action associée aux événementsinternes (Op5);œ l'action associée à la transition desortie de l'état (Op6). 46

Généralisation d’états• Principe de généralisation d'états: les états plus généraux sont appelés super-états, les états plus spécifiques sous-états. • Un état peut être décomposé en plusieurs sous-états disjoints; les sous-états héritent des caractéristiques de leur super-état. • Décomposition disjonctive: l'objet doit être dans un seul et un seul sous-état à la fois.


Le processus unifié et la notation UML Notes personnelles...

Documents

Transcript of Le processus unifié et la notation UML Notes personnelles...