Julie Dugdale Julie.Dugdale@upmf-grenoble.fr Génie Logiciel 2 Julie Dugdale Julie.Dugdale@upmf-grenoble.fr.

Présentation au sujet: "Julie Dugdale Julie.Dugdale@upmf-grenoble.fr Génie Logiciel 2 Julie Dugdale Julie.Dugdale@upmf-grenoble.fr."— Transcription de la présentation:

1 Julie Dugdale Julie.Dugdale@upmf-grenoble.fr
Génie Logiciel 2 Julie Dugdale

2 Introduction et information pratique
Suite de Génie Logiciel 1 Je couvre différents aspects d'UML, mais il peut y avoir des recoupements avec GL1 Si vous avez besoin de me contacter : Tous les cours seront sur le Bureau Virtuelle (cours, TDs, etc.) Master ICA

3 Ressources / Références (livres, articles, sites web, etc.)
Quelques ressources générales : « The Complete UML Training Course » Grady Booch, James Rumbaugh, Ivar Jacobson. Prentice Hall (contains CD ROM) « Using UML. Software Engineering with Objects and Components » Stevens et Pooley. Addison Wesley Master ICA

4 Page sur UML du CETUS (des centaines de liens!):
Page sur UML du Object Management Group (OMG) (nombreux liens vers tutoriels et autre ressources) : Page sur UML du CETUS (des centaines de liens!): Master ICA

5 Ressources en Français
Un site utile en Français! : « UML, le langage de modélisation objet unifié » Un autre site Français (avec un lien en haut de la page vers des livres utiles en Français) Le site Wikipedia français sur UML a aussi des détails sur des livres sur UML en Français : Master ICA

6 Examen & Contrôle Continu
C'est un exercice de groupe. Vous devez former des groupes de 4 étudiants maximum. Vous êtes libres de choisir avec qui vous voulez travailler. Pourquoi: Quelque soit votre emploi après l’université, vous travaillerez en équipe. Bon entrainement pour le travail en équipe. Travail sur un projet non-trivial. UML est une collection de diagrammes de modélisation pour la description d’un système. Voir comment ces diagrammes se supplémentent les uns les autres. Master ICA

7 Contrôle Continu Le contrôle continu est évalué de deux manières :
Présentation de groupe (50% de la note du contrôle continu) Durée : 20 minutes plus 5 minutes de questions. Les présentations auront lieu pendant le dernière semaine du cours. Rapport de groupe de 20 pages maximum (50% de la note du contrôle continu) Master ICA

8 Génie Logiciel 1 & 2 Partie: GL 1 Partie: GL 2 1 — Introduction
2 — L’Objet dans le développement du logiciel 3 — UML - Modélisation statique 3.1 — Concepts fondamentaux 3.2 — Concepts avancés 4 — UML - Modélisation dynamique 5 — UML - Modèle des Use Cases 6 — Démarche - Aperçu du processus unifié Julie Partie: GL 2

9 4 — UML Modélisation dynamique
Génie Logiciel 4 — UML Modélisation dynamique

10 Sommaire - Modélisation dynamique
Introduction Diagrammes dynamiques de description “générique” notions fondamentales diagrammes d'états diagrammes d'activités Diagrammes de description de scénarios Notion de scénario diagrammes de séquence diagrammes de collaboration Master ICA

11 Introduction Master ICA

12 Modèle dynamique Le modèle dynamique (ou encore vue comportementale) décrit comment le système change au cours du temps. Basé sur l’idée que, quand le temps passe et des évènements surviennent, les objets changent Il décrit plus précisément : les relations temporelles et événementielles entre les objets du système, les modifications internes des objets (cycle de vie d’un objet), les actions et les réactions des objets (au sein du système et vis à vis des systèmes extérieurs). Master ICA

13 Modèle dynamique UML propose quatre types de diagramme pour établir le modèle dynamique d'un système : 2 types de diagramme pour la description “générique” : les diagrammes d'états, les diagrammes d'activités, 2 types de diagramme pour la description de scénarios : les diagrammes de séquence les diagrammes de collaboration. Master ICA

14 Diagrammes dynamiques de description “générique”
Master ICA

15 Diagrammes dynamiques de description “générique”
Diagrammes d'états : Les objets d’un système changent leur état en réponse à des évènements et au temps qui passe. Exemples simples : Quand vous activez un interrupteur, une lumière change son état de Off à On Après un certain temps, une machine à laver change son état de Lavage à Rinçage ils décrivent le cycle de vie d'un objet (ou du système), qui participe éventuellement à plusieurs activités, on associe généralement un diagramme d'états à une classe. Diagrammes d'activités : ils décrivent le déroulement d'une activité, qui concerne éventuellement plusieurs objets. Exemple simple : Une activité matinale est constituée d’une séquence d’activités (se lever, se doucher, manger le petit-déjeuner, aller au travail) qui implique de nombreux objets (par exemple un lit, une douche, un grille-pain, une voiture, etc.) Master ICA

16 Diagrammes d'états Two important aspects: Notion d'état
Notion d'événement Master ICA

17 Notion d'état Un état est une situation remarquable de la vie d'un objet (du système) durant laquelle il satisfait certaines conditions, effectue une activité, ou attend un événement. On regroupe dans la notion d'état l'ensemble des valeurs, des liens et des conditions qui impliquent pour l'objet un comportement particulier. Un objet peut changer d'état … donc l'état est aussi une mesure de temps entre deux changements Master ICA

18 Exemples d'états Autres exemples :
notation d'un état Employé Retraité DemandeurDEmploi Les instances de la classe Personne peuvent être dans l'un des trois états ci-dessus Autres exemples : transmission automatique : Démarrage, PointMort, Avant, AvantRapide, MarcheArrière. appareil quelconque : Marche, Arrêt. Master ICA

19 Etat Par exemple, l’objet StaffMember a un attribut startDate qui détermine si un objet StaffMember est dans l'état 'période d'essai'. Notez: staffName et staffNo (autres attributs de l’objet StaffMember) n’ont pas d’impact sur son état. L’objet StaffMember peut être dans l’état ‘période d’essai’ pendant les 6 premiers mois de contrat. The current state of an object is a result of the events that have occurred to the object, and is determined by the current value of the object’s attributes and the links that it has with other objects. Some attributes and links of an object are significant for the determination of its state while others are not. For example, in the Agate case study staffName and staffNo attributes of a StaffMember object have no impact upon its state, whereas the date that a staff member started his or her employment at Agate determines when the probationary period of employment ends (after six months, say). The StaffMember object is in the Probationary state for the first six months of employment. While in this state, a staff member has different employment rights and is not eligible for redundancy pay in the event that they are dismissed by the company. Master ICA

20 Diagrammes d'états Two important aspects: Notion d'état
Notion d'événement Master ICA

21 Notion d'événement Les événements sont des stimuli destinés aux objets. Ils sont localisés dans le temps (ils n'ont pas de durée) et dans l'espace (entre plusieurs intervenants). Exemples : “l'utilisateur insère la carte de crédit dans le distributeur automatique de billets”, “le vol UA123 part de Chicago”. Master ICA

22 Notion d'événement Entre des événements, il peut y avoir :
une succession logique, “le vol UA123 part de Chicago” précède “le vol UA123 arrive à San Francisco” ou aucune relation de causalité. “le vol UA123 part de Chicago” n'est pas lié à “le vol UA456 part de Seattle” Master ICA

23 Événements et Objets Au niveau d'un objet, un événement peut provoquer : un changement d'état un Employé devient DemandeurDEmploi suite à une démission une réaction qui conduit à de nouveaux événements l'appui sur l'accélérateur a pour réaction une augmentation de la puissance délivrée par le moteur, ce qui conduit à l'augmentation de la vitesse les deux, ni l'un, ni l'autre. Master ICA

24 Événements et Objets La manière dont un objet réagit à un événement dépend de son état On distingue événement et message : tous les envois de message sont des événements, tous les événements ne sont pas des envois de message (interface avec l'extérieur du systèmes, exceptions, signaux, …). Master ICA

25 Diagramme d'états Un diagramme d'états est un graphe orienté dont les nœuds sont des états et les arcs des transitions entre ces états. Un diagramme d'états peut servir à décrire la dynamique de l'ensemble ou d'une partie du système, mais il est souvent associé à une classe. Associé à une classe : un diagramme d'états permet de décrire les états et les transitions possibles pour les instances, il est partagé par les instances, deux instances peuvent être dans des états différents à un instant donné Master ICA

26 Diagramme d'états l'état initial transition sur événement
transition implicite blanc joue TourDesBlancs TourDesNoirs noir joue [ PAT ] garde [ MAT ] [ MAT ] un état final noir gagne partie nulle blanc gagne Un diagramme d'états modélisant une partie d'échecs Master ICA

27 Exemple de modélisation dynamique d'un climatiseur
? Diagramme d'états Sous-état mise sous tension Veille mise hors tension sous-état [ trop froid ] [ trop chaud ] Chauffage Chauffage [ bonne temp.] [ bonne temp.] Activation événement / action Refroidissement prêt / activerVent() [ trop chaud ] [ trop froid ] Actif Exemple de modélisation dynamique d'un climatiseur Master ICA

28 Diagramme d'états Vide NonVide embranchement conditionnel
détruire détruire / détruireElts() [nbElts=nbMax] / send exception empiler(e) / empiler(e) Vide NonVide empiler(e) dépiler [nbElts=1] / dépiler() [nbElts<nbMax] / empiler(e) dépiler [nbElts>1] / dépiler() dépiler / send exception embranchement conditionnel Exemple de modélisation dynamique d'une pile bornée Master ICA

29 Transition Une transition est une relation orientée entre 2 états, qui indique qu'un objet dans le premier état effectuera certaines actions avant de passer dans le deuxième état. Cette action prend place en réaction à un événement particulier et/ou à des conditions particulières. Événement [garde] / action1(); action2() État1 État2 Forme générale de la notation d'une transition Master ICA

30 Développement d’un système pour une agence de publicité.
Les clients de l’agence ont des campagnes publicitaires Ce déclenchement (évènement) doit correspondre à une opération dans la classe Campagne Commissionné Autorisé (codeAutorisation) [contratSigné] /set CampagneActive action paramètre Condition de garde. La transition se passe seulement si la condition est évaluée à TRUE Active Fragment d’un diagramme d’état pour la classe Campagne Master ICA

31 Transition gardée la transition est franchie quand survient l’événement et que la condition est vérifiée condition = expression booléenne en attente insérer carte [lisible] en attente de code en vérification carte illisible de compte insérer carte [illisible]

32 Activités internes Il est aussi utile de modéliser les activités internes associées à un état Compartiment d'activités internes Compartiment de Nom Nom de l'état entry/expression-activité exit/expression-activité do/activité Activités Entry et Exit NE PEUVENT PAS avoir de conditions de garde Activités d’états peuvent avoir une condition de garde Master ICA

33 Etat Menu Visible pour un objet DropDownMenu.
Action d'entrée résulte en l'affichage du menu Sortir de l'état déclenche cacheMenu() Menu Visible Compartiment Nom entry/ afficheMenu do/joueClipSonore itemSélectionné / surligneItem exit / cacheMenu Compartiment Activités internes Pendant que l'objet reste dans l'état Menu Visible, l'activité résulte en la diffusion d'un clip sonore. L'événement itemSelectionné() déclenche l'action surligneItem() In this example, the entry action causes the menu to be displayed. While the object remains in the Menu Visible state, the activity causes a sound clip to be played and, if the event itemSelected() occurs, the action highlightItem() is invoked. It is important to note that when the event itemSelected() occurs the Menu Visible state is not exited and entered and as a result the exit and entry actions are not invoked. When the state is actually exited the menu is hidden. Master ICA

34 { Transitions internes SaisieMotDePasse transition d'entrée
entry / motDeP.raz() exit / motDeP.test() imprime / defer do / supprimeEcho() chiffre / gestionChiffre() annul / motDeP.raz() aide /afficherAide() transition de sortie transitions internes { événement différé activité Exemple de saisie d'un mot de passe à chiffres. entry, exit, defer et do sont des mots réservés. Une transition interne sur événement n'a pas le même effet qu'une transition externe sur le même événement (on ne passe pas par les transitions de sortie et d'entrée. Master ICA

35 État composite et sous-états concurrents
DemandeurDEmploi prospection ANPE proposition ANPE InscritANPE EnCoursDIns- criptionANPE inscription validée EnPhase- DEmbauche sortie en OU logique prospection personnelle proposition entreprise CandidatSpontané prospection ANPE et prospection personnelle sont 2 sous-états concurrents de DemandeurDEmploi Master ICA

36 État composite et sous-états concurrents
EtudiantMaster EtudiantMaster [n<10] [n<10] Master échoué CoursCon- troleContinu Rattrapage [n10] CoursCon- troleContinu Rattrapage [n10] [n<10] validé [n10] UE1 validé Master obtenu UE2 … autres modules ... sortie en ET logique Stage validé Stage Il faut valider tous les modules et le stage pour réussir Master ICA

37 État composite et sous-états concurrents
EtudiantMaster EtudiantMaster validé validé validé validé validé validé notations équivalentes EtudiantMaster également valable sans sous-états concurrents Il y a plusieurs notations possibles. Master ICA EtudiantMaster CoursCon- troleContinu Rattrapage [n<10] Projet UE1 Stage [n10] UE2 validé … autres modules ...

38 État historique Si un état composite est atteint puis abandonné prématurément, il peut être utile de recommencer un état composite par le sous-état qui était actif en dernier Un état historique et un état historique profond sont utilisés pour représenter ceci. Master ICA

39 état historique profond
ÉtatEnglobant SousÉtat1 interruption ÉtatExtérieur SousÉtat2 H SousÉtat3 état historique état historique profond H* L'état historique permet de revenir au dernier sous-état visité lors du retour à un état englobant. Master ICA

40 Pseudo-états d'historique
Pseudo-état d'historique profond Superficiel Fonctionne de manière similaire à l’historique superficiel, mais permet à un état composite de recommencer au dernier état actif dans chaque machine emboitée, à n’importe quelle profondeur d’emboitement Master ICA

41 Préparer les machines d'états
Master ICA

42 Différentes approches :
Regarder chaque classe dans le diagramme de classe Identifier les différents états pour chaque classe Regarder les évènements majeurs du système. Identifier chaque classe qui pourrait réagir à ces évènements différemment selon son état. Un groupe de différents diagrammes UML est utilisé pour concevoir un système (use case, diagrammes d’interaction, etc.) On peut utiliser ces autres diagrammes pour s’aider pendant le développement des diagrammes d’états Plus de détails sur les slides sur le BV Master ICA

43 Préparer les machines d'états
Deux approches peuvent être utilisées: Approche de cycle de vie Approche comportementale Allen and Frost (1998) Master ICA

44 Approche de cycle de vie
Master ICA

45 Approche de cycle de vie
Considérons les cycles de vie pour des objets de chaque classe. Les événements et états sont identifiés directement grâce à des cas d‘utilisation et grâce à toute documentation de spécification disponible. D'abord, les évènements principaux du système sont listés. Chaque évènement est alors étudié pour déterminer quels objets pourraient réagir à cet évènement de manière différente selon son état. Master ICA

46 Les étapes de l'approche de cycle de vie
Identifier les évènements majeurs du système. Identifier chaque classe qui pourrait réagir à ces évènements différemment selon son état. Pour chacune de ces classes, produire une première version d'une machine d'état en considérant le cycle de vie typique d'une instance de cette classe. Etudier la machine d'état et la sophistiquer pour gérer des comportements aux évènements plus détaillés. Master ICA

47 Les étapes de l'approche de cycle de vie
Améliorer la machine d'état pour inclure des scénarios différents. S'assurer que la machine d'état est consistante avec les cas d‘utilisation. En particulier, vérifier que les contraintes que la machine d'état implique sont appropriées. Itérer les étapes 4, 5 et 6 jusqu'à ce que la machine d'état représente le niveau de détail nécessaire. S'assurer de la consistance avec le diagramme de classe et les diagrammes d'interaction et les autres machines d'état. Master ICA

48 Approche comportementale
Master ICA

49 Approche comportementale
Basé sur les diagrammes d’interactions Diagrammes d’interactions montrent les messages reçus par un objet Détails sur les diagrammes d’interactions -> prochain cours Notez: la réception d’un message par un objet ne correspond pas nécessairement à un évènement qui résulte en un changement d’état Master ICA

50 Approche comportementale
Par exemple: simples messages ‘get’ (par exemple getTitle) et messages query (par exemple listAdverts) ne sont pas des évènements dans ce sens Pourquoi? Ils ne changent pas les valeurs des attributs des objets Ne modifient aucuns liens avec d’autres objets Master ICA

51 Diagramme de séquence avec états
:Client :Campaign listCampaigns :CampaignManager sd Record completion of a campaign loop :CompleteCampaignUI :CompleteCampaign getClient selectClient getCampaignDetails() startInterface [For all clients] showClientCampaigns completeCampaign [For all client’s campaigns] Active state Completed state Active Completed Diagramme de séquence avec états Réception d’un msg résulte en une opération provoquant un changement d’état Note that getCampaignDetails() does not change the state as this message only queries aspects of the objects state. However, campaignCompleted() does cause a state change and changes the values of some attributes of the object. getCampaignDetails() ne change pas l’état car le message demande seulement des aspects sur l’état de l’objet Master ICA

52 Approche comportementale
Pour identifier tous les messages entrant qui pourraient déclencher un changement d’état, tous les diagrammes de séquence d’interaction pour cet objet doivent être examinés. Ceci produit une première tentative de liste d’évènements et d’états Master ICA

53 Approche comportementale
Examiner tous les diagrammes d'interaction qui impliquent chaque classe qui a un fort "messaging". Identifier les messages entrant sur chaque diagramme d'interaction qui pourraient correspondre à des évènements. Identifier aussi les états résultants possibles. Documenter ces évènements et états dans une machine d'états. Sophistiquer la machine d'états tant que nécessaire pour incorporer les interactions additionnelles lorsqu'elles deviennent évidentes, et ajouter les exceptions éventuelles. Master ICA

54 Approche comportementale
Développer toute machines d'états éventuellement imbriquées (à moins que cela n'ait déjà été fait dans une étape précédente). S'assurer que la machine d'état est consistante avec les cas d’utilisation. En particulier, vérifier que les contraintes que la machine d'état implique sont appropriées. Master ICA

55 Approche comportementale
Itérer les étapes 4, 5 et 6 jusqu'à ce que la machine d'état représente le niveau de détail nécessaire. S'assurer de la consistance avec le diagramme de classe et les diagrammes d'interaction et les autres machines d'état et autres modèles. Master ICA

56 Commissioned authorized(authorizationCode) [contract signed] /setCampaignActive /assignManager; assignStaff Advert Preparation Completed Paid campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment > zero] [paymentDue - payment = zero] archiveCampaign /unassignStaff; unassignManager [paymentDue - payment < zero] /generateRefund Running Adverts Scheduling confirmSchedule extendCampaign /modify Budget advertsApproved /authorize sm Campaign Version 1 Première tentative de diagramme d’état pour la classe Campagne – une approche comportementale. Master ICA

57 Préparer les machines d'états
Approche de cycle de vie: Moins formelle que l'approche comportementale dans son identification initiale des évènements et des classes adéquates. Souvent utiles pour utiliser une combinaison des deux, puisque chacune procure des vérifications sur l'autre. Master ICA

58 Vérifications de consistance
Un ensemble de diagrammes d’UML (Diagrammes d’état, Diagrammes de séquences, Diagrammes de Use Case, etc.) décrit la conception d’un système. Chaque type de diagramme est utilisé pour montrer différents aspects du système. Il y a des liens entre les diagrammes! Ce qui apparait sur un type de diagramme devrait apparaitre sur un autre type de diagramme. Par exemple une action (sur un diagramme d’état) devrait apparaitre comme une opération (sur le diagramme de classe). Master ICA

59 Vérifications de consistance
Sur les slides du cours (sur le BV) j’ai mis de l’information sur des manières de vérifier la consistance entre les diagrammes. Je vais revenir sur ce point plus tard quand on aura couvert tous les différents types de diagrammes! Master ICA

60 Vérifications de consistance
Les vérifications de consistance sont une tâche importante dans la préparation d'un ensemble complet de modèles. Pourquoi? Souligne les oublis et les erreurs, et encourage la clarification de toute ambigüité ou incomplétude dans les spécifications. Master ICA

61 Vérifications de consistance
Tout évènement devrait apparaître comme un message entrant pour l'objet approprié sur un diagramme d'interaction. Chaque action devrait correspondre à l'exécution d'une opération sur la classe appropriée, et peut-être aussi à l'envoi d'un message à un autre objet. Chaque évènement devrait correspondre à un opération sur la classe appropriée (mais noter que toutes les opérations ne doivent pas correspondre aux évènements). Chaque message sortant envoyé par une machine d'état doit correspondre à une opération sur une autre classe. ·     Every event should appear as an incoming message for the appropriate object on an interaction diagram. ·     Every action should correspond to the execution of an operation on the appropriate class, and perhaps also to the despatch of a message to another object. ·     Every event should correspond to an operation on the appropriate class (but note that not all operations correspond to events). ·     Every outgoing message sent from a state machine must correspond to an operation on another class. Consistency checks are an important task in the preparation of a complete set of models. This process highlights omissions and errors, and encourages the clarification of any ambiguity or incompleteness in the requirements. Master ICA

62 Commissioned authorized(authorizationCode) [contract signed] /setCampaignActive /assignManager; assignStaff Advert Preparation Completed Paid campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment > zero] [paymentDue - payment = zero] archiveCampaign /unassignStaff; unassignManager [paymentDue - payment < zero] /generateRefund Running Adverts Scheduling confirmSchedule extendCampaign /modify Budget advertsApproved /authorize sm Campaign Version 1 Première tentative de diagramme d’état pour la classe Campagne – une approche comportementale. Tout évènement devrait apparaître comme un message entrant pour l'objet approprié sur un diagramme d'interaction. Master ICA

63 Commissioned authorized(authorizationCode) [contract signed] /setCampaignActive /assignManager; assignStaff Advert Preparation Completed Paid campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment > zero] [paymentDue - payment = zero] archiveCampaign /unassignStaff; unassignManager [paymentDue - payment < zero] /generateRefund Running Adverts Scheduling confirmSchedule extendCampaign /modify Budget advertsApproved /authorize sm Campaign Version 1 Première tentative de diagramme d’état pour la classe Campagne – une approche comportementale. Chaque action devrait correspondre à l'exécution d'une opération sur la classe appropriée, et peut-être aussi à l'envoi d'un message à un autre objet. Master ICA

64 Initial state machine for the Campaign class—a behavioural approach.
Commissioned authorized(authorizationCode) [contract signed] /setCampaignActive /assignManager; assignStaff Advert Preparation Completed Paid campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment > zero] [paymentDue - payment = zero] archiveCampaign /unassignStaff; unassignManager [paymentDue - payment < zero] /generateRefund Running Adverts Scheduling confirmSchedule extendCampaign /modify Budget advertsApproved /authorize sm Campaign Version 1 Initial state machine for the Campaign class—a behavioural approach. Chaque évènement devrait correspondre à un opération sur la classe appropriée (mais noter que toutes les opérations ne doivent pas correspondre aux évènements). Master ICA

65 Diagramme d’état 1 (décrit la classe x) Diagramme d’état 2
(décrit la classe y) Chaque message sortant envoyé par une machine d'état doit correspondre à une opération sur une autre classe. Master ICA