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

Slides:



Advertisements
Présentations similaires
Possibilités de Facebook dans votre club Toastmasters Samedi, le 12 juin 2010 Michel Beaulieu
Advertisements

Le moteur
LA QUALITE LOGICIELLE Plan du cours La modélisation d’activité 1 h ½
6 — Aperçu du processus unifié
Génie Logiciel 2 Julie Dugdale
Julie Dugdale Génie Logiciel 2 Julie Dugdale
Génie Logiciel 1 & 2 Partie: GL 1 Partie: GL 2 1 — Introduction
Classe : …………… Nom : …………………………………… Date : ………………..
Les Prepositions.
Systèmes en temps réel Modélisation du comportement en temps réel avec UML.
Projet n°4 : Objecteering
XML - Henry Boccon-Gibod 1 XML, Langage de description La question du choix de formalismes Les entités et leur représentations modalités de modèles et.
Les cas d’utilisation (use cases)
Module d’Enseignement à Distance pour l’Architecture Logicielle
ANALYSE DES TRAITEMENTS
Modules Spécifiques Programme GENIE Atelier 3 Intégration méthodologique des Ressources Numériques dans des situations dapprentissage.
ESIEE Paris © Denis BUREAU I N Initiation à la programmation avec le langage Java.
Introduction à UML NFE108 CNAM – LILLE Madame DELECLUSE
UML (Unified Modeling Langage)
Interface Homme Machine IHM Pro
1 Théorie des Graphes Cycle Eulérien. 2 Rappels de définitions On dit qu'une chaîne est un chemin passant par toutes les arêtes du graphe. On dit qu'un.
PARTIE 3 : Le SYSTEME D’INFORMATION FUTUR
Le Modèle Dynamique 1. EADS Matra Datavision - Confidentiel
UML : DIAGRAMME D’ACTIVITES
28 Les Repas. 1. le repas complet 2. le petit déjeuner.
le profil UML en temps réel MARTE
Analyse et Conception des Systèmes d’Informations
1 Guide de lenseignant-concepteur Vincent Riff 27 mai 2003.
Modélisation E/R des Données
Chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent d’introduire et/ou de compléter les diagrammes des catégories.
UML F. Laperruque INRA – SAGA CATI SICPA.
1 Introduction : Management des systèmes dinformation version 1.1 du 13 Novembre 2001 Introduction : Management des systèmes dinformation ENSGI Cours MSI.
Static modeling, Thu G. Falquet, L. Nerima.
Projet poker 1/56. Introduction Présentation de léquipe Cadre du projet Enjeux Choix du sujet 2.
Outils pour la modélisation des systèmes distribués
Département de génie logiciel et des TI Université du Québec École de technologie supérieure Systèmes dinformation dans les entreprises Systèmes dinformation.
Chercher et trouver Module 1 Déroulement : Souhaiter la bienvenue
Unified Modeling Langage
1. 2 PLAN DE LA PRÉSENTATION - SECTION 1 : Code HTML - SECTION 2.1. : CSS (Méthode 1) - SECTION 2.2. : CSS (Méthode 2) - SECTION 3 : JavaScript - SECTION.
Cours de Base de Données & Langage SQL
Ecaterina Giacomini Pacurar
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
SYSTEMES MIXTES MOBILES ET COLLABORATIFS
Chapitre 3 La cinématique à une dimension
Veuillez trouver ci-joint
Initiation à la conception des systèmes d'informations
Le diagramme de séquences
Le diagramme d’activités
Sensibilisation a la modelisation
Architecture et développement Web
Page 1 © Jean Elias Gagner en agilité numérique. Page 2 © Jean Elias Les fournisseurs.
Langage de modélisation graphique de systèmes
ECOLE DES HAUTES ETUDES COMMERCIALES MARKETING FONDAMENTAL
Page 1 © Jean Elias Recherche et veille. Page 2 © Jean Elias Les fournisseurs.
Modélisation Objet UML avec Rational Rose 2000
ECOLE DES HAUTES ETUDES COMMERCIALES MARKETING FONDAMENTAL
Projet NavInc Florian Bastien Fabien Cornic Antoine Després
Centre d’échange d’informations sur la Convention sur la Diversité Biologique Bienvenue dans le cours sur l’ajout d’une page web sur un site web développé.
Relevez le numéro de votre logo préféré et adressez-le à : En cas d’hésitation, vous pouvez choisir jusqu’à 3 logos. Seront pris.
Le diagramme d’états-transitions
UML : un peu d’histoire H. Lounis.
Nouvelles Technologies Internet & Mobile
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Préambule Hiver 2002 Petko Valtchev.
Unified Modeling Language
Hiver 2004SEG2501 Chapître 41 Chapître 4 SDL – structure d’un système et son comportement.
Machines à états finis.
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Chapitre 2 Rappels objet et Présentation des diagrammes UML
UML : méthode Processus. Introduction(1) ● Cycles ● Spécification par cas d'utilisation ● Identifier les besoins ● Analyse par cas d'utilisation ● Affiner.
Transcription de la présentation:

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

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 : Julie.Dugdale@upmf-grenoble.fr Tous les cours seront sur le Bureau Virtuelle (cours, TDs, etc.) Master ICA

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

Page sur UML du CETUS (des centaines de liens!): Page sur UML du Object Management Group (OMG) (nombreux liens vers tutoriels et autre ressources) : http://www.uml.org/ Page sur UML du CETUS (des centaines de liens!): http://www.cetus-links.org/oo_uml.html#oo_uml_utilities_tools Master ICA

Ressources en Français Un site utile en Français! : « UML, le langage de modélisation objet unifié » http://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours/ Un autre site Français (avec un lien en haut de la page vers des livres utiles en Français) http://uml.free.fr/ Le site Wikipedia français sur UML a aussi des détails sur des livres sur UML en Français : http://fr.wikipedia.org/wiki/Unified_Modeling_Language Master ICA

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

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

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 Dugdale@upmf-grenoble.fr Daniel.Bardou@upmf-grenoble.fr Partie: GL 2

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

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

Introduction Master ICA

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

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

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

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

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

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

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

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

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

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

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

É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

É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

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

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

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

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

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

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

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]

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

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

{ 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

É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

É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

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

É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

é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

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

Préparer les machines d'états Master ICA

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

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

Approche de cycle de vie Master ICA

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

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

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

Approche comportementale Master ICA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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