Analyse Orientée Objet - Modélisation Objet avec ... - Examen corrige
DEV061 ? Analyse et conception par objet avec UML et RUP. L'orienté objet (OO
) est maintenant un incontournable. Pour un bon développement OO, que vous ...
part of the document
EPFC Bachelier en Informatique
Cours d'Analyse Principes et Méthodes
Analyse Orientée Objet - Modélisation Objet avec UML
(Unified Modeling Language)
Brigitte Herpigny Bruno Lacroix
Sommaire
Modélisation Objet avec UML
1. Introduction générale
2. Approche objet
2.1. Les objets
2.1.1. Diagrammes dobjets
2.1.2. Diagrammes de collaborations
2.1.3. Diagrammes de séquences
2.2. Les classes
-Classes entités, interfaces, contrôles - stéréotypes
2.2.1. Diagrammes de classes
- Associations
- Agrégations - Qualifications
- Classes associations
- Généralisations / Spécialisations
- Contraintes sur associations
- Classes abstraites
2.2.2. Règles de bonne modélisation
3. Modèle de cas dutilisation
3.1. Les acteurs
3.2. Les cas dutilisation
3.3. Les diagrammes de cas dutilisation
3.4. La transition vers les objets
3.5. Règles de bonne modélisation
4. Modèle dynamique
4.1. Introduction
4.2. Les automates
4.3. Les états
4.4. Diagrammes détats-transitions
4.5. Opérations, actions et activités
4.6. Diagrammes détats imbriqués Généralisations
4.7. Concurrence et Agrégation détats
4.8. Diagrammes dinteractions versus Diagrammes détats
4.9. Règles de bonne modélisation
4.10. Diagrammes dactivités
+ TP ponctuels
+ TP études de cas
Bibliographie Analyse Orientée Objet - UML
Ian Graham, Méthodes Orientées Objet, 2ème édition, 1997, Thomson Publishing
Pierre-Alain Muller, Modélisation Objet avec UML, 2ème édition 2000, Eyrolles
N. Lopez, J. Migueis, E. Pichon, Intéger UML dans vos Projets, 1998, Eyrolles
G. Booch, J. Rumbaugh, I. Jacobson, Le Guide de l'Utilisateur UML, 2000, Eyrolles
T. Quatrani, Modélisation UML avec Rational Rose 2000, 2000, Eyrolles
J. Rumbaugh et al. , OMT, Modélisation et Conception Orientées Objet, 1995, Masson
Pascal Roques, UML par la pratique 2001 Eyrolles
Craig Larman, UML2 et les design patterns -2005 Pearson Education
1. Introduction
Les systèmes logiciels actuels sont devenus d'une complexité telle qu'ils nécessitent de véritables méthodes d'élaboration. Celles-ci doivent permettre de modéliser et de construire ces systèmes logiciels de manière fiable et reproductible. Elles permettent également un travail en équipe en facilitant la communication entre tous ses membres, informaticiens et non informaticiens, via un langage commun.
Les méthodes structurées et fonctionnelles se sont imposées les premières. Dans celles-ci, les sous-programmes constituent les éléments structurants.
D'une manière générale, la construction d'un logiciel peut être vue comme une suite d'itérations du genre "divisions/réunions". En effet, l'étude du système doit progresser à différents niveaux d'abstraction et s'intéresser aux détails comme à l'ordonnancement de l'ensemble de manière à faire émerger le comportement macroscopique complexe du système à réaliser.
Il s'agira donc de décomposer pour comprendre (divisions) et de composer pour construire (réunions).
Les décompositions sont traditionnellement dirigées par un critère fonctionnel: décomposer en une hiérarchie de nombreux sous-programmes les plus simples possibles s'appelant les uns les autres. Ces fonctions les plus simples sont alors facilement implémentables dans les langages de programmation.
Ce procédé donne en effet des résultats satisfaisants quand les fonctions peuvent être bien identifiées et qu'elles sont stables dans le temps.
Lorsqu'il n'en est pas ainsi (les fonctionnalités du problème ont changé!), les évolutions des fonctions peuvent impliquer des modifications structurelles très lourdes dans les programmes dues au couplage statique entre l'architecture du programme et les fonctions. Plusieurs études ont d'ailleurs montré que la maintenance adaptative d'un logiciel était la plus grande source d'injection d'erreurs dans un logiciel. (Ainsi, des versions ultérieures de logiciels possèdent souvent certains bugs que les versions précédentes ne possédaient pas!)
Les méthodes objets commencent à émerger dans les années 80. Dans celles-ci les élément structurants seront des objets collaborants entre eux.
Il est à noter que pendant longtemps, on a constaté un mélange des 2 paradigmes (approche fonctionnelle et approche objet) au cours du cycle de vie des logiciels. Ainsi, il était habituel de réaliser une analyse (description du problème) fonctionnelle suivie d'une conception (description de la solution au problème) et d'une programmation objets. Les conséquences en étaient un manque d'abstraction, abstraction limitée à l'encapsulation des objets de bas niveaux.
Les années 90 ont vu une prolifération de méthodes objet (+/- 50). Durant ces années de discussions afin de déterminer ce qui était "objet" et ce qui ne l'était pas, les utilisateurs ont préféré attendre.
Certaines idées dominantes communes animaient néanmoins les divers groupes de chercheurs:
notions de classes et associations : James Rumbaugh et sa méthode OMT (object modeling technique)
notions de partitions en sous-systèmes : Grady Booch
notions de "cas d'utilisations" (interactions entre utilisateur et système): Ivar Jacobson et ses use cases
Fin 1994, Rumbaugh et Booch décident d'unifier leurs méthodes; un an plus tard Jacobson les rejoint.
Ils fixent ainsi des objectifs communs:
représenter des systèmes entiers par des concepts O.
créer un langage de modélisation utilisable à la fois par les humains et par des machines (besoin d'un véritable "langage de modélisation")
La standardisation d'UML, Unified Modeling Language date de 1997. La définition de la version 1.0 est due à un consortium de partenaires regroupant DEC, HP, i-Logix, IntelliCorp, IBM, ICON, MCI, Microsoft, Oracle, Rational Software, TI, Unisys.
Remarque: UML 1.3, juin 1999
La notation UML est conçue pour servir de langage de modélisation O, indépendamment de la méthode mise en oeuvre (Booch, OMT, ...). En fait, elle sous-tend la méthode.
Le langage UML est composé d'éléments graphiques, chacun avec une sémantique clairement définie. Il peut être utilisé dans tous les domaines informatiques.
La représentation des sytèmes ne se contente habituellement pas d'un seul élément de modèle.
Ces différents modèles proposés peuvent se comparer à des "vues" différents d'une même chose, chacune insistant sur des caractéristiques différentes.
On trouve une comparaison facile dans la construction d'une maison. Celle-ci réclame une série de plans différents selon qu'ils sont destinés au plombier, à l'électricien, au menuisier... Pourtant, il s'agit toujours des plans de la même maison. Parfois, on remarque des informations permettant de naviguer d'une vue à une autre (de manière à ne pas placer les conduites d'eau là où passent les gaines électriques).
De la même manière, UML définit plusieurs modèles pour la représentation des systèmes:
un modèle de classes qui capture la structure statique
un modèle de cas d'utilisation décrivant les besoins des utilisateurs
un modèle d'interactions représentant les scénarios et les flots de messages
un modèle de réalisation montrant les unités de travail
un modèle de déploiement précisant la répartition des processus
Ceux-ci s'appuient sur 9 diagrammes différents:
diagrammes de classes: représentent la structure statique en termes de classes et de relations
diagrammes d'objets: représentent la structure statique en termes d'objets et de relations
diagrammes de séquence: sont une représentation temporelle des objets et de leurs interactions
diagrammes de collaboration: sont une représentation spatiale des objets, des liens et de leurs interactions
diagrammes de cas d'utilisation : représentent les fonctions du système du point de vue de l'utilisateur
diagrammes d'états-transitions: représentent le comportement d'une classe en termes d'états
diagrammes d'activités: représentent le comportement d'une opération en termes d'actions.
diagrammes de composants: représentent les composants physiques d'une application
diagrammes de déploiement: représentent le déploiement des composants sur les dispositifs matériels
La modélisation de tous les systèmes ne comporte pas nécessairement ces 9 vues.
2. Approche Objet
Avantages:
Stabilité de la modélisation par rapport aux entités du monde réel
Construction itérative facilitée par un faible couplage statique entre les différents composants (( approche fonctionnelle)
possibilité de réutiliser des éléments d'un développement à un autre
simplicité du modèle basé sur 5 concepts de base : objets, messages, classes, héritage, polymorphisme)
L'approche O est basée sur une démarche cartésienne rationnelle ainsi que sur une démarche "systémique" qui considère un système comme une totalité organisée dont les éléments solidaires ne peuvent être définis que les uns par rapport aux autres.
Ici, la méthode de décomposition sera basée sur l'intégration de ce que le système est et fait.
exemple: Système d'ascenseur
Les objets qui sont des abstractions du monde réel intègrent une structure et un comportement.
La modélisation est donc une modélisation statique et dynamique de l'environnement (le "domaine") dans lequel sont définis les besoins.
Les fonctionnalités se représentent comme des formes de collaborations entre les objets qui composent le système et ce couplage devient dynamique.
Si les fonctionnalités changent, l'architecture du système n'est pas modifiée: il suffira d'ajouter les composants nécessaires et de modifier la collaboration entre les composants existants.
2.1 Les objets
Les objets informatiques sont des images simplifiées des objets du monde réel, objets matériels de toutes sortes (chaises, livres,...) ou objets "sans masse" ou même virtuels (comptes en banque, déplacements virtuels d'argent, équations, fenêtres d'un environnement Windows, ...).
Ils sont des unités atomiques réunissant un état (ce qu'il "est") et un comportement (ce qu'il "fait").
L'objet va révéler son rôle dans l'environnement en envoyant des messages à d'autres objets et en s'insérant ainsi dans un scénario de communication.
Notation UML d'un objet:
Un objet est représenté par un rectangle. On en souligne le nom.
Les traits entre les objets symbolisent les liens.
Les rectangles avec coin supérieur droit replié sont des annotations explicatives. Les liens avec ces notes sont alors des traits discontinus.
2.1.1. Diagrammes d'objets : = Vues statiques
représentent les objets participant à une interaction et leurs liens. Les diagrammes d'objets sont toujours des fragments d'un immense diagramme qui indiquerait les relations entre tous les objets.
exemple: Clients d'une banque et leurs comptes
La notation permet d'indiquer un nom générique plutôt que leur nom individuel.
On peut également représenter des objets anonymes avec un ":nom "
exemple : Un objet du "genre" Etudiant
La plupart des liens sont binaires. Néanmoins on peut rencontrer des liens d'arité supérieure.
Un objet = 1 état + 1 comportement + 1 identité
l'état : représente les valeurs instantanées de tous les "attributs" d'un objet. Ceux-ci peuvent prendre des valeurs dans un domaine de définition donné. L'état peut évoluer dans le temps en conséquence de ses comportements passés.
le comportement: regroupe les "compétences" d'un objet et décrit les actions et les réactions de cet objet.
Le comportement d'un objet regroupe donc une série d'opérations qui peuvent être déclenchées en réponse à un stimulus externe = un message envoyé par un autre objet.
Pour recevoir un message d'un autre objet, il faut que celui-ci soit "vu". On représentera cette reconnaissance mutuelle par un lien entre les objets. Les messages voyagent le long des liens, à priori dans les 2 directions. Ils sont représentés par des flèches au dessus des liens et accompagnés d'un nom décrivant le message.
2.1.2. Diagrammes de collaboration :
= Diagrammes des interactions (messages) entre objets en plus de la structure statique (objets, liens).
Paul demande à Nicolas d'étudier. Nicolas demande à Hélène de cuisiner.
Ceci sous-entend bien sûr que Nicolas a la faculté d'étudier (une des ses opérations est "étudier") et que Hélène sait faire la cuisine. L'ordre d'envoi des messages est précisé par un n° placé en tête de message.
D'autre part, le comportement à un instant donné dépend de l'état courant qui lui-même peut être modifié par le comportement. Ainsi pour pouvoir étudier, il faut être dans un état "éveillé", sinon l'opération "étudier" n'a pas de sens. Et lorsque l'on reçoit le message de dormir, on passe dans l'état "endormi".
l'identité: En plus de son état, tout objet possède une identité de manière à le distinguer de manière non ambiguë de tous les autres objets, même s'il possède les mêmes valeurs d'attributs.
En phase de modélisation, l'identité ne se représentera pas de manière spécifique mais restera implicite.
3 catégories de comportement: Les acteurs, les serveurs et les agents
Les systèmes informatiques à objets sont donc des collections d'objets qui travaillent en synergie pour réaliser les fonctionnalités de l'application informatique.
En fonction de la direction des messages échangés, on peut dès lors regrouper les objets en 3 grandes catégories.
les acteurs sont à l'origine d'une interaction (ils envoient les messages)
les serveurs sont uniquement destinataires de messages. Ce sont des objets passifs qui attendent qu'un autre objet ait besoin de leurs services. Automatiquement, le flot de contrôle passé au serveur est récupéré par l'objet actif après exécution du service.
les agents peuvent émettre et recevoir des messages et peuvent servir d'intermédiaire entre un client et un serveur que le client ne connaît pas directement.
Remarque: Souvent agent ou acteur dépend de l'angle sous lequel on se place, ou du niveau d'abstraction envisagé.
Dans une école secondaire, une sonnerie signale le changement d'heure de cours. Celle-ci est en réalité reliée à une horloge. En conséquence de la sonnerie, les élèves se déplacent vers d'autres classes.
L'horloge apparaît donc comme un acteur envoyant un message à l'agent sonnerie qui transmet le message aux élèves (serveurs) de se déplacer.
Le concierge pourtant peut considérer l'horloge comme un agent puisqu'il la coupe le WE.
Les élèves eux peuvent considérer la sonnerie comme un acteur qui s'auto-déclenche toutes les heures.
Le concept de message
Les messages vont donc permettre aux objets de communiquer. Ils vont relier dynamiquement ces objets séparés par le processus de décomposition.
Ils regroupent les flots de contrôle et les flots de données au sein d'un concept unique (qui sera mis en oeuvre selon de nombreuses variantes (appel de procédures, événement discret, interruption, ...)). Ils représentent conceptuellement les actions effectuées dans le cadre du Use Case étudié (cf plus loin). Souvent les messages portent le nom d'une opération définie dans la classe (cf + loin) de l'objet destinataire du message.
La notation UML permet de différencier les flots de contrôle (flèches simples) des flots de données (flèches + petits cercles)
De manière générale, UML offre une syntaxe extrêmement complète pour les messages:
synchronisation sequence ':' résultat ':=' nom arguments
L'expression de synchronisation permet de préciser les envois d'autres messages qui doivent avoir été satisfaits préalablement.
La séquence indique le niveau d'emboîtement de l'envoi du message au sein de l'interaction et contient des notations d'itérations éventuelles et de conditions.
Le résultat est constitué d'une liste de valeurs retournés par le message.
Le nom du message (une opération de l'objet destinataire bien souvent)
les arguments= liste des paramètres du message.
exemples:
4: Afficher(x,y) -- msg simple
3.3.1 : Afficher (x,y) --msg imbriqué
4.2 age:=soustraire(aujourd'hui,ddn)
[age >=18 ans] 6.2 : voter() --msg conditionnel
4.a,b.6/c.1 : allumer(lampe) --synchro avec d'autres flots d'exécution
1* : laver() --itération
5 catégories principales de messages
les constructeurs : créent des objets
les destructeurs : détruisent des objets
les sélecteurs : renvoient tout ou une partie de l'état d'un objet
les modificateurs : modifient tout ou une partie de l'état d'un objet
les itérateurs : visitent l'état d'un objet
Remarque : Un objet est dit actif quand il possède le flot de contrôle. Il peut alors activer des objets passifs pendant le temps d'un opération en leur envoyant un message. Une fois le message traité, le flot de contrôle est rendu à l'objet actif. Dans un environnment multitâche, plusieurs objets peuvent être actifs simultanément.
Lorsque plusieurs objets communiquent simultanément, il est important de discuter la notion de synchronisation afin entre autres de protéger l'accès à des objets partagés (exemple une imprimante)
2 grandes catégories d'envoi de messages
envoi de message synchrone : ne déclenche une opération que quand le destinataire accepte le message. Avec un tel envoi, l'expéditeur accepte d'attendre. Notation UML : flèche barré d'une croix - UML2 Exemple: Un "expéditeur" téléphone à un destinataire. Il attend que le destinataire décroche pour lui transmettre le message.
envoi de message asynchrone : n'interrompt en rien l'activité de l'expéditeur. Celui-ci envoie le message et ne se préoccupe plus de rien. Il ne sait pas quand ni même si le message sera traité par le destinataire. Notation UML : demi flèche - UML2 Exemple: Un expéditeur envoie une lettre par la poste à un destinataire.
On distingue également:
envoi de message simple : convient quand un seul objet est actif à la fois (un seul flot d'exécution). Le passage du contrôle s'effectue lors de l'envoi du message d'un objet actif vers un objet passif. Notation UML : flèche simple
envoi de message dérobant : ne déclenche une opération que si le destinataire s'est préalablement mis en attente du message. Le destinataire accepte d'attendre. Notation UML : flèche qui se retourne vers l'expéditeur
envoi de message minuté : bloque l'expéditeur pendant un temps donné en attendant la réception par le destinataire. Au bout du temps spécifié, si le destinataire ne s'est pas manifesté, l'expéditeur est libéré. Notation UML: flèche surmontée d'un petit cercle symbolisant une montre. Exemple: Un expéditeur téléphone à un destinataire. Il décide de patienter 5 sonneries que le destinataire décroche. Après cela, il raccroche.
Les diagrammes de collaboration qui représentent bien spatialement des situations avec un nombre de messages réduit deviennent extrêment confus lorsque les messages se multiplient:
Ici nous avons en plus illustré un message réflexif (8:) d'un objet à lui-même. De tels messages peuvent également indiquer un point d'entrée dans une activité de plus bas niveau qui s'exerce au sein de l'objet.
2.1.3. Diagrammes de séquence
Les diagrammes de séquence présentent la même sorte d'information que les diagrammes de collaboration mais l'accent est mis sur la communication au détriment de la structure spatiale. On n'aura plus besoin de numéroter les messages qui se succéderont à la verticale sur une échelle du temps représenté de haut en bas.
Ces diagrammes sont indispensables quand les interactions sont complexes.
Remarque: On peut parfois commencer en pratique par un diagramme de collaboration et ensuite quand les objets sont bien identifiés passer à un diagramme de séquence.
Le diagramme de séquence de l'exemple précédent serait:
Les messages sont représentés par des flèches horizontales.
Les petits rectangles verticaux indiquent la distribution du flot de contrôle parmi les différents objets (périodes d'activité des objets).
Pour un tel dessin, la période d'activité de A recouvre celle de B.
Typiquement, dans le cas d'un appel de procédure, le flot d'exécution est passé par l'objet A à l'objet B. A est bloqué jusqu'à ce que B lui redonne la main, ce qui est d'ailleurs implicite en fin d'exécution de l'action de B pour tous les envois synchrones.
Les lignes verticales pointillées sont appelées les lignes de vie des différents objets.
Les retours d'exécution d'une action (return) ne sont donc généralement pas indiqués (ils sont implicites). S'ils sont illustrés, ce sera au moyen d'une flèche inverse pointillée et peuvent être accompagnés également d'une valeur de retour.
Autre exemple:
La marge de gauche peut être utilisée pour des descriptions textuelles de ce qui est fait et également pour des indications temporelles placées conventionnellement entre accolades.
Des branchements peuvent être représentés sur un diagramme de séquence pour représenter des alternatives ou un parallélisme. Les messages de branchement partent alors du même point de la ligne de vie de l'objet et sont marqués par une condition de garde entre crochets (si conditions mutuellement exclusives ( alternative sinon parallélisme)
Rappel : Si un message doit être envoyé un certain nombre de fois, on peut indiquer une marque d'itération "*" sur celui-ci. Une condition de garde entre crochets indiquant jusque quand le message doit être envoyé peut alors suivre l'astérisque.
L'objet A envoie le msg à B tant que X est vraie:
On peut également utiliser un pseudo code pour la structure de boucle et même y inclure un groupe de messages
Création et destruction d'objets
Si un objet est créé durant l'interaction, on le représentera par une flèche (un message) pointant sur l'objet et par l'indication "new". Si en cours d'interaction, un objet est détruit, on marque la fin de sa ligne de vie par une croix. L'objet peut être détruit parce qu'il termine normalement ou parce qu'un autre objet a provoqué sa destruction par l'envoi d'un message approprié.
Exemple: Gestion de commandes (correspondra à un "use case" cf + loin)
Objet de la GUI Objets du domaine
Une fenêtre d'entrée de commande envoie un message "préparer" à une commande
Cette commande envoie un message "préparer" à chaque ligne de commande qui la compose
Chaque ligne de commande vérifie l'état du stock pour l'article concerné
Si la vérification renvoie "OK", la ligne de commande retire du stock la quantité appropriée de l'article
Sinon, la quantité en stock est trop basse et il faut recommander l'article.
Le diagramme de collaboration du même problème aurait été:
Ici on précise la contrainte {nouveau} (notation conventionnelle).
Remarque importante : Standard UML2
Le standard UML2 a apporté des améliorations substancielles au niveau des diagrammes de séquence et des notations denvoi de messages. Vous trouverez toutes les nouvelles notations entre autres dans le document suivant : http://cian.developpez.com/uml2/tutoriel/sequence/
2.2. Les classes
Le monde étant constitué de très nombreux objets en interaction, il est souhaitable de pouvoir regrouper les objets qui se "ressemblent" et de distinguer des structures de plus haut niveau d'abstraction sans détails inutiles.
Les démarches d'abstraction sont à priori arbitraires: On décide de concentrer la réflexion sur un certain élément d'une représentation et d'en négliger les autres.
La classe est donc une description abstraite d'un ensemble d'objets du domaine d'application. Chaque objet appartient à une classe. Les généralités sont contenues dans la classe, les particularités dans les objets.
Ainsi, si l'on considère les 2 objets suivants:
on peut décider de les faire appartenir à une même classe (la classe des Biens) si seuls leur prix et leur âge importent. Par contre si on veut pouvoir considérer que le cheval mange et que la maison est repeinte, il faudra considérer 2 classes différentes prenant en compte ces comportements différents.
Les objets informatiques sont construits à partir de la classe par un processus appelé instanciation. Tout objet est une instance d'une classe.
Les langages O réduisent la distance entre notre façon abstraite de raisonner et le langage compris par les ordinateurs.
Représentation UML des classes
Rectangles divisés en 3 compartiments.
Par défaut, les attributs (dont l'ensemble des valeurs prises représente l'état des objets de la classe) sont cachés et les opérations (spécifiant le comportement des objets de la classe) sont visibles de l'extérieur.
Certains attributs peuvent être dérivés d'autres (cf "champs calculés"). On met un "/" devant.
exemple:
serait transformé en conception en
UML prévoit d'ailleurs des représentations des classes selon 3 perspectives:
conceptuelle : avec des diagrammes totalement indépendants du langage d'implémentation.
de spécification : on y précise les interfaces pour le langage de programmation qui sera utilisé
d'implémentation: on y indique comment les interfaces seront implémentées.
Les 3 compartiments n'apparaissent pas toujours au niveau conceptuel.
exemple 1:
Un téléviseur peut être vu comme un équipement électronique très complexe ou comme un jeu utilisable par de très jeunes enfants. Ici il offre une abstraction au travers de quelques opérations simples.
exemple 2: représentation d'une partie du domaine bancaire.
Les détails techniques de la transaction ne sont naturellement pas connus du client. L'abstraction dissimule la complexité de la gestion des comptes.
Remarque: Les "types de données abstraits" (piles, files, listes,...) manipulés par les informaticiens sont des abstractions appartenant typiquement à la conception et n'apparaissent pas au niveau de l'analyse.
Remarques générales sur la Programmation O et les perspectives de spécification et d'implémentation:
La description d'une classe se fait en 2 parties: sa spécification (qui décrit le domaine de définition et les propriétés des instances de cette classe) et sa réalisation (qui décrit comment la spécification est réalisée et qui comprend le corps des opérations et les données nécessaires à leur fonctionnement).
Une classe passe un contrat avec d'autres classes: elle fournit les services publiés dans sa spécification (et les autres classes s'engagent à ne pas faire usage des connaissances autres que celles décrites dans cette spécification). Il y a encapsulation càd occultation des détails de réalisation.
Ainsi, les données encapsulées sont protégées de tout accès intempestif et les utilisateurs d'une abstraction ne dépendent pas de sa réalisation.
Par défaut, les valeurs d'attributs d'un objet sont encapsulées dans l'objet et ne peuvent être manipulées directement par les autres objets. Les interactions entre les objets sont effectuées en déclenchant des opérations.
Il ya généralement 3 niveaux d'encapsulation (ex en C++):
niveau privé : totalement opaque: seules les "amies" peuvent y accéder
niveau protégé : les éléments placés là sont visibles par les amies et par les classes dérivées de cette classe
niveau public : les éléments placés là sont visibles par toutes les classes
UML fournit une notation afin de préciser ces niveaux d'encapsulation
+ public, # protégé, - privé
exemple: Nombres complexes.
La spécification des nombres (opération d'addition, de soustraction,...) ne dépend pas de leur notation polaire ou cartésienne. Il peut donc y avoir 2 représentations avec des parties publiques identiques:
Dans le cadre de ce cours, nous abandonnerons ici notre intérêt pour le point de vue des réalisations (qui n'apparaitra plus que dans des remarques sporadiques) et nous nous limiterons à la perspective conceptuelle.
Stéréotypes de classe
Définition: Un stéréotype est un mécanisme qui permet aux utilisateurs du langage UML de rajouter des nouveaux éléments de modélisation en plus du noyau prédéfini. En effet, UML se veut une notation ouverte, générique et extensible par l'utilisateur.
Dans le domaine des classes, UML prédéfinit entre autres les stéréotypes suivants: (chacun pourra en définir d'autres à sa convenance)
, pour spécifier une classe qui modélise des informations et des comportements durables. Les classes entité correspondent directement à des entités du monde réel et sont indépendantes de la manière dont le système communique avec l'environnement. Elles peuvent donc être réutilisées. Ce sont les "classes du domaine".
, pour spécifier une classe qui fournit une vue totale ou partielle d'un ensemble de services offerts dans une autre classe Les classes interface prennent en charge la communication entre le système et ses utilisateurs. Elles constituent la partie du système qui dépend de l'environnement et modélisent donc les interfaces système.
Dans une classe interface, aucune opération n'est implémentée.
Graphiquement, on se contente souvent pour poser une interface sur une classe (qui fournit les services décrits par l'interface) de joindre celle-ci à un petit cercle (variante plus compacte)
exemple : Une classe Compte en Banque peut fournir 2 interfaces, une interface Client et une interface Banquier
, pour spécifier une classe qui regroupe des éléments (ex fonctions de librairie mathématique) au sein d'un module qui ne pourra pas être instancié mais se manipulera graphiquement comme une classe conventionnelle
pour modéliser le comportement séquenciel d'un cas d'utilisation. Les classes de contôle coordonnent les événements nécessiares à la réalisation du comportement spécifié dans un cas d'utilisation (voir plus loin). Par définition une classe de contrôle est totalement dépendante de l'application.
Diagrammes de classes:
Les relations entre les classes
Les liens qui relient les objets peuvent être vus de manière abstraite dans le monde des classes. A chaque famille de liens entre objets correspond une relation entre les classes de ces mêmes objets.
Les liens entre objets seront des instances des relations entre classes.
R1. L'association:
représente une relation structurelle (durable) bidirectionnelle entre classes.
Notation UML : identique aux liens dans diagrammes d'objets.
La plupart des associations sont binaires.
Quand on est vraiment amené à considérer des relations de plus grande arité, on représentera un losange central
exemple de relation ternaire qui matérialise un cours
Généralement, on fait disparaître les relations d'arité > 2 en créant une classe munie d'une contrainte qui exprime que les multiples branches de l'association s'instancient toutes simultanément en un même lien.
Les extrémités d'une association sont appelées les rôles
2 manières de nommer une association
directement: le nom de l'association apparaît en italique au dessus du lien. Dans ce cas, on recommande un verbe d'action ex
On nomme les rôles de manière à ce qu'ils décrivent comment une classe voit une autre classe au travers d'une association. ex
"La personne voit la société en temps qu'employé".
Cette solution est à priori meilleure car plus respectueuse du côté statique des diagrammes de classes (le verbe d'action, lui, tendrait à évoquer un "comportement")
Remarque: Ne pas confondre association et messages!
Ici une seule association est suffisante pour permettre à une personne de conduire, démarrer, laver et arrêter sa moto.
Les rôles ont une multiplicité (nombre d'instances de la classe considérée qui participent à l'association)
Multiplicités conventionnelles:
1 : 1 et 1 seul
0..1 : 0 ou 1
m..n : de m à n
*: de 0 àplusieurs
0..* : idem
1..* : de 1 à plusieurs
Remarque: les multiplicités fonctionnent exactement à l'inverse des cardinalités du modèle Merise.
Les associations peuvent posséder des attributs (associations "attribuées")
Lorsque une association attribuée participe elle-même à des relations avec d'autres classes, on la représente par une "classe association". On utilise toujours une ligne pointillée pour la lier.
Contraintes sur les associations: expressions placées entre accolades:
Contrainte {sous-ensemble}
Contrainte {ou exclusif}
Associations réflexives
Dans ce cas, le nommage des rôles sera crucial:
Toute personne possède de 0 à 2 parents et possède de 0 à n enfants.
Association qualifiée
Une association met en relation 2 classes et 1 « qualificatif » (forme dassociation « ternaire »).
Le qualificatif est un attribut spécial qui réduit la multiplicité effective dune association.
Les associations 1 à n et n à n pourront être qualifiées.
Exemple1 :
Un répertoire possède plusieurs fichiers
Un fichier appartient à un seul répertoire
Répertoire et Fichier seront 2 classes. Nom_fichier pourrait être un qualificatif . Il spécifie un fichier unique dans le contexte dun répertoire. On le représentera dans une boîte contiguë à la classe Répertoire
SHAPE \* MERGEFORMAT
La multiplicité est maintenant de 1 à 1.
La qualification améliore la précision sémantique et augmente la visibilité des chemins de navigation. Il es plus explicite de dire « Un répertoire + un nom de fichier se combinent pour identifier un fichier » que « Un répertoire contient plusieurs fichiers »
Exemple2 :
Un parking de 5 étages pouvant accueillir chacun 50 voitures
SHAPE \* MERGEFORMAT
Exercice : Placer siège comme un qualificatif dans lassociation ternaire de lexercice sur le Transport aérien
Restriction navigabilité dune association
On peut restreindre la navigabilité dune association en y indiquant un sens. Ainsi on permettra que les objets dune des 2 classes voient les objets de lautre classe sans que linverse ne soit possible.
Exemple : SHAPE \* MERGEFORMAT
Lobjet user verra le password, le password ne verra pas les users
La dépendance
Rappel : une association est une relation structurelle stable. La durée de vie des liens dépasse le temps dexécution des messages sur les instances liées.
Exemple : Un employé, à tout instant, peut sidentifier grâce à son badge :
SHAPE \* MERGEFORMAT
La dépendance est une relation entre classes qui nest pas de nature structurelle. Une dépendance ne possèdera pas dinstances (liens). Elle indique une diffusion unidirectionnelle de messages. Elle précise quune classe nécessite la présence dune autre pour son implémentation ou son fonctionnement.
Dans lexemple ci-dessous, la présence dune dépendance indiquerait que la classe Employé pourrait avoir comme méthode une fonction « sidentifier » qui aurait comme attribut 1 badge quon lui aurait remis à laccueil et quil pourrait jeter une fois le sas dentrée franchi. La dépendance en UML se dessine par une flèche pointillée, éventuellement décorée du stéréotype :
SHAPE \* MERGEFORMAT
R2. L'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é.
Ici on a donc une forme d'association avec un couplage plus fort entre les classes (il faut donc être sûr de son existence, dans le doute, on se contente d'une association!). L'agrégation favorisera la propagation des valeurs d'attributs et des opérations de l'agrégat vers les composants.
L'agrégation permet de représenter des relations de type
maître/esclave
tout et parties
composé et composants
Elle se représente par un petit losange placé du côté de l'agrégat
L'agrégat est sémantiquement un objet traité comme un tout dans beaucoup d'opérations bien qu'il soit physiquement constitué de plusieurs petits objets.
La multiplicité du côté de l'agrégat est généralement de 1. Néanmoins, on peut rencontrer une multiplicité > 1 :
Ainsi, le diagramme de classes:
correspondrait au diagramme d'objets suivant:
exemple d'agrégat multiple: Des personnes sont propriétaires (éventuellement en copropriété) d'immeubles:
Remarque d'implémentation: Dans ce cas, plusieurs pointeurs référencent le même objet tout en se synchronisant pour désallouer l'objet au moment où il ne sera plus référencé par aucun pointeur ("Smart Pointers")
La contenance physique est un cas particulier de l'agrégation, appelé la composition: (notation : losange noir)
Les parties vivent et meurent avec le tout et font partie de lui. Une partie ne peut faire partie que d'un seul tout. Cela implique la suppression en cascade des parties avec le tout.
La composition et les attributs (qui sont en effet physiquement contenus dans l'agrégat) sont donc sémantiquement équivalents. La notation par composition s'emploie dans un diagramme de classes lorsqu'un attribut participe à d'autres relations dans le modèle.
SHAPE \* MERGEFORMAT
La multiplicité du côté de l'agrégat est toujours 0 ou 1.
Une multiplicité du côté du composant de 0 correspond à un attribut non renseigné.
R.3. La généralisation et la spécialisation
On réalise grâce à ce genre de relation une hiérarchie de classes = "classification".
Généralisation:
On factorise les éléments communs (attributs, opérations et contraintes) d'un ensemble de classes dans une classe plus générale appelée super-classe.
On réalise ainsi un arbre de classes dont les feuilles appartiennent au monde réel tandis que les niveaux supérieurs (super-classes) sont des abstractions construites pour ordonner et comprendre.
Les attributs, opérations et contraintes définis dans les super-classes seront hérités intégralement par les sous-classes.
Remarque: en programmation, la relation de généralisation est très souvent réalisée en utilisant la relation d'héritage entre classes proposée par les langages O.
Notation UML : flèches triangulaires qui pointent vers les super-classes
exemple:
La généralisation signifie toujours "est un". Il n'y a donc pas de multiplicité.
Une généralisation est un relation antiréflexive, antisymétrique et transitive.
Cette remarque nous aidera à différencier les vraies généralisations de simples associations où l'on peut avoir identifié des relations "est un" trop rapidement.
exemple:
Un siamois est un chat (généralisation)
Un chat est un animal (généralisation)
Le siamois est une race (simple association)
Le chat est une espèce (simple association)
Les classes peuvent avoir plusieurs super-classes. Il s'agit de généralisation multiple.
Elle se rencontre souvent lorsqu'une classe peut être généralisée selon plusieurs critères simultanément. On ajoute alors sur le diagramme un discriminant.
exemple 1 : sans généralisation multiple
Classification d'animaux selon un critère de station puis de type d'alimentation:
Le phénomène de "covariance" induit ainsi des points de maintenance multiples dans le modèle.
exemple 2 : toujours sans généralisation multiple
Classification d'animaux selon un critère de type d'alimentation puis de station:
exemple 3: la généralisation multiple apporte une solution élégante lorsque les critères indépendants sont difficiles à ordonner et supprime les problèmes de covariance:
Contraintes sur généralisations
= expressions entre accolades
Par défaut, la généralisation symbolise une décomposition exclusive : Un objet est au plus une instance d'une des sous-classes.
Contrainte {disjoint} = {exclusif} : Une classe descendante d'une classe A ne peut être descendante que d'une seule sous-classe de A. Il n'y a pas de mélange des dimensions.
Contrainte {chevauchement} ou {inclusif}: Une classe descendante d'une classe A appartient au produit cartésien des sous-classes de A. Un objet concret est construit à partir d'une classe obtenue par mélange de plusieurs super-classes.
Contrainte {incomplète} / {complète} {incomplète}: la gnéralisation est extensible {complète}: la généralisation est telle qu'il n'est pas possible de rajouter des sous-classes Attention: contrainte {incomplète} ( vue incomplète: La contrainte transporte un contenu sémantique qui affecte le modèle.
Spécialisation
On capture les particularités d'un ensemble d'objets. Les nouvellles caractéristiques sont représentées par une nouvelle classe, sous-classe d'une des classes existantes.
Les dispositifs concrets sont donc ajoutés dans la hiérarchie par dérivation du parent le plus proche.
exemple:
Généralisations versus Spécialisations
Les généralisations sont plutôt utilisées une fois que les éléments du domaine ont été identifiés tandis que les spécialisations sont à la base de la programmation par extension et de la réutilisation (les nouveaux besoins sont emprisonnés dans des nouvelles sous-classes).
Remarques sur la réalisation des classifications:
En programmation O, la technique la plus utilisée est l'héritage de classes.
On construit une classe à partir d'une ou plusieurs autres classes en partageant des attributs, des opérations et parfois des contraintes (ceux de la classe parent) au sein d'une hiérarchie de classes, et ceci dans un but de classification mais aussi parfois de simple construction de nouveaux composants (en profitant de l'héritage pour faire une économie d'expression).
L'héritage est entâché de contingences de réalisation. Ainsi certaines caractéristiques peuvent être indûment dupliquées dans les sous-classes, conséquence d'une réalisation d'héritage multiple réalisée par copie
ex: Les super-classes A et B définissent toutes les 2 un attribut "nom" de telle sorte que la classe C possède 2 attributs nom.
Si nom représente la même notion dans les 2 super-classes alors il n'y a pas de raison de dupliquer l'attribut dans C.
Par contre si nom désigne 2 propriétés différentes, il faudra renommer une des deux.
En conséquence, certains langages comme Java ou Ada 95 n'offrent pas d'héritage multiple.
En réalité, l'héritage n'est pas une nécessité absolue et peut toujours être remplacée par la délégation qui réduit le couplage dans le modèle. Ici, le "client" ne connaît pas le "fournisseur" mais communique avec une interface qui propage les questions à un ou plusieurs délégués.
et cette délégation permettra elle aussi d'éliminer le problème de covariance au détriment cependant de la propagation automatique des caractères des super-classes vers les sous-classes.
Le principe de substitution doit être vérifié en cas d'héritage. "Il doit être possible de substituer n'importe quelle instance d'une sous-classe à n'importe quel objet instance d'une super-classe sans que la sémantique du programme en soit affecté". Ainsi la classification propagera l'état, le comportement et même les contraintes sans demi-mesure.
Le respect de ce principe permet alors de mettre en oeuvre le polymorphisme: caractéristique d'un élément à pouvoir prendre plusieurs formes.
Ici, ce sont donc les interactions entre objets qui sont écrites selon les termes des spécifications définies non dans les classes des objets, mais dans leurs super-classes. En d'autres termes, on invoque l'opération de la super-classe et il y a exécution de l'opération (spécialisée) de la sous-classe adéquate (les opérations sont donc "polymorphes" puisque leurs réalisations peuvent prendre plusieurs formes).
La recherche automatique du code à exécuter est le fruit de la liaison dynamique.
Les classes abstraites (liées à généralisations)
sont des classes qui ne sont pas instanciables (ne donnent pas naissance à des objets mais servent de spécification plus générale -de type- pour manipuler les objets instances d'une (ou plusieurs) de leurs sous-classes afin d'y diminuer le niveau de détails.
éléments généraux fournis par classes abstraites
spécificités et extensions encapsulées par sous-classes concrètes.
Notation UML : nom de la classe en italique ou stéréotype
2.3.Conclusions:
Différentes relations et couplage statique
Rappel : Plus faible sera le couplage statique entre entités (classes), plus faciles seront les modulations dans le programme à la demande.
Du couplage faible au couplage fort :
association : une classe « voit » une autre classe et vice versa
agrégation : une classe est une partie dune autre classe
composition : une classe vit et meurt avec une autre classe
dépendance : une classe a besoin dune autre classe pour son fonctionnement
généralisation / spécialisation : une classe est une sous classe dune autre classe : x% de ses attributs et méthodes se trouvent dans la classe mère
Les méthodes Objet se subdivisent d'habitude en 3 perspectives.
Un modèle objet qui décrit la structure statique des objets et leurs relations dans le système
Un modèle dynamique qui décrit les aspects du système qui se modifient avec le temps
Un modèle fonctionnel qui décrit les fonctions du système du point de vue des utilisateurs
A ce stade, l'approche objet nous a permis de recouvrir l'aspect statique des choses et de les illustrer via des diagrammes d'objets et des diagrammes de classes.
Nous avons également ébauché l'aspect dynamique dans des diagrammes de collaboration et des diagrammes de séquence. Les méthodes objet et UML en particulier développent cet aspect à travers d'autres diagrammes (d'états/transitions et d'activités) que nous verrons dans la suite.
Ce sont bien sûr les besoins des utilisateurs qui mettront en évidence les fonctions attendues du système et qui aideront à identifier les objets, les classes et les interactions entre les objets requises pour réaliser ces fonctionnalités.
Le chapitre suivant aborde dans ce but le modèle de cas d'utilisation.
Recettes pratiques pour une bonne modélisation Objet (statique)
Bien comprendre le modèle à résoudre Examen du cahier des charges provenant du client. Poser le problème : ce qu'il faut faire (pas comment) cf analyse fonctionnelle et use cases.
Garder le modèle simple
Choisir les noms avec soin
Eviter si possible les associations naires (>2) (décomposer si possible en binaires avec qualificatif ou attribut d'association)
Garder les multiplicités pour plus tard
Utiliser les associations qualifiées quand c'est possible
Pas de généralisations trop imbriquées
Regarder si les associations 1 à 1 ne sont pas plutôt des 0-1 à 0-1
Par ordre chronologique:
Identification des classes et des objets présumés. Eliminer les classes redondantes, non pertinentes, vagues, celles qui ne sont que des attributs, celles qui sont des opérations (ex: appel téléphonique), celles qui sont des rôles.
Préparation d'un dictionnaire de données (paragraphes explicatifs sur chacune des classes)
Identification des associations et agrégations. Une association doit décrire une propriété structurelle du domaine d'application et non un événement transitoire Spécifier les associations avec un nom bien choisi ou mieux des noms de rôle
Identification des attributs Ils ne doivent pas être des objets
Organisation et simplification des classes grâce à généralisation
Ensuite soumettre le modèle à de multiples révisions via des itérations pour clarifier le modèle, réparer les erreurs, ajouter des détails.
Un modèle subit souvent 5 ou 6 itérations.
Soumettre le modèle à des avis extérieurs - Documenter systématiquement
UML - Exercices
Modèle Statique
Réaliser un diagramme de classes à partir du diagramme dobjets suivant :
Réaliser un diagramme de classes à partir du diagramme dobjets suivant :
Réaliser un diagramme de classes à partir du diagramme dobjets suivant :
Réaliser un diagramme de classes à partir du diagramme dobjets suivant :
Voici un diagramme de classes partiellement terminé pour un système de transport aérien :
Ajouter des noms de rôles ou dassociations
Ajouter les multiplicités
Concevoir un diagramme dobjets pour un voyage imaginaire aller-retour que vous avez fait le week-end dernier à Londres.
Inclure au moins un objet de chaque classe.
Heureusement pour vous, il y avait des vols directs Bruxelles-Londres sans devoir passer par Moscou.
Un de vos amis est venu avec vous mais a décidé de rester là-bas encore un peu. Il y est dailleurs encore.
Le commandant Corniau était votre pilote sur les deux vols.
Vous avez eu une place différente dans chaque vol mais, grâce à votre incroyable sens de lobservation, vous avez remarqué quil sagissait du même avion.
Ajouter les opérations suivantes au diagramme de classes : chauffer, licencier, remplir (réservoirs), nettoyer, dégivrer, décoller, réparer, engager, annuler, retarder, atterrir, réserver.
Classer les relations suivantes en généralisation, agrégation ou association.
Un pays possède une capitale.
Un philosophe qui dîne utilise une fourchette.
Un fichier est un fichier ordinaire ou un fichier répertoire.
Les fichiers contiennent des enregistrements.
Un polygone se compose dun ensemble ordonné de points.
Un objet de schéma est un texte, un objet géométrique ou un groupe.
Une personne emploie un langage informatique sur un projet.
Les modems et les claviers sont des périphériques dentrée-sortie.
Les classes dobjets peuvent avoir plusieurs attributs.
Une personne joue dans une équipe une certaine année.
Une route relie deux villes.
Un étudiant suit le cours dun professeur.
Un répertoire contient des fichiers.
Une pièce contient des murs.
Une transaction boursière est un achat ou une vente.
Un compte bancaire peut appartenir à une personne physique ou morale.
Deux personnes peuvent être mariées.
La relation de composition est un cas particulier de lagrégation. Vérifiez que les relations dagrégation identifiées dans lexercice 6 ne sont pas en réalité des relations de composition.
3. Modèle de cas d'utilisation
Les "use cases" ont été formalisés par Ivar Jacobson. Ils décrivent sous la forme d'actions et de réactions le comportement d'un système du point de vue de l'utilisateur.
Un cas d'utilisation est donc une manière spécifique d'utiliser un système.
Les besoins des utilisateurs sont souvent noyés à l'intérieur d'une grande quantité d'informations se contredisant en apparence ou pour le moins imprécises. La structuration de la démarche s'impose donc très naturellement.
Le modèle de cas d'utilisation propose de partitionner l'ensemble des besoins en fonction de différentes catégories d'utilisateurs.
On traitera donc les interactions par rapport à une seule catégorie d'utilisateurs à la fois.
Le langage des cas d'utilisation est un langage proche de l'utilisateur afin de faciliter la communication avec les informaticiens.
Le comportement attendu d'un système sera illustré par un modèle de cas d'utilisation qui met en évidence les fonctions attendues du système, un environnement constitué d'acteurs et les relations entre les cas d'utilisation et les acteurs au sein de diagrammes de cas d'utilisation.
3.1. Les acteurs
Un acteur représente un rôle joué par toute personne ou entité interagissant avec le système et n'en faisant nécessairement pas partie.
Remarque: Une même personne physique peut jouer le rôle de plusieurs acteurs et à l'inverse, plusieurs personnes peuvent jouer le même rôle et donc agir comme le même acteur.
On identifie les candidats acteurs parmi les utilisateurs, les clients, les partenaires, les fournisseurs, les vendeurs, les autres systèmes, en un mot ceux qui donnent ou reçoivent des informations au/du système.
Notation UML: Un acteur sera représenté comme un petit personnage:
Ou en notation classe avec un stéréotype
SHAPE \* MERGEFORMAT
4 grandes catégories d'acteurs
les acteurs principaux (ceux qui utilisent les fonctions principales du système) ex: pour un distributeur de billets = clients
les acteurs secondaires (ceux qui effectuent des tâches administratives ou de maintenance. Leur aide est nécessaire pour réaliser les objectifs des acteurs principaux) ex: la personne qui recharge le distributeur
le matériel externe (=les dispositifs matériels incontournables qui font partie du domaine de l'application et qui doivent être utilisés) ex: l'imprimante de reçus du distributeur de billets
les autres systèmes (qui interagissent avec le système) ex: BANKSYS qui gère le parc de distributeurs.
Il faudra toujours rajouter au modèle une description précise de chacun des acteurs identifiés.
3.2. Les cas d'utilisation
Ils se déterminent en observant acteur par acteur les séquences possibles d'interaction du point de vue de l'utilisateur et en termes d'informations échangées. Ces séquences possibles sont appelées des scénarios.
Les scénarios sont donc des instances des cas d'utilisation correspondant au flot de messages échangés par les objets durant l'interaction particulière de ce scénario.
Chaque cas d'utilisation est un faisceau de scénarios, certains principaux correspondront au déroulement dit normal, d'autres secondaires décriront les traitements exceptionnels. Ces derniers sont habituellement décrits dans un stade ultérieur de l'analyse.
Notation UML : Un use case sera représenté par une ellipse dans laquelle on écrit son nom.
Chaque cas d'utilisation est aussi décrit (textuellement) par un flot d'événements.
Celui-ci est une description des événements nécessaires à l'accomplissement du comportement requis par le cas d'utilisation.
Ce flot décrit ce que le système doit faire (pas comment).
Il contient
une description du début du cas d'utilisation (l'événement qui déclenche le cas) ex : "le cas débute quand X se produit"
une description de la fin du cas d'utilisation ex : "le cas est terminé quand Y se produit"
les échanges d'informations entre le système et l'acteur en une formulation non informatique ex : "l'utilisateur se connecte au système et donne son nom et son mot de passe"
d'éventuelles répétitions de comportement au moyen de pseudo-code ex: "boucle fin de boucle"
des situations optionnelles
Chaque projet devrait utiliser un patron standard pour la création de documents relatifs à ses flots d'événements.
exemple1 de patron: (cf Terry Quatrani - Modélisation UML avec Rational Rose 2000- Edition Eyrolles- août 2000)
n flot du cas
n.1. préconditions
n.2 flot principal
n.3. sous-flots
n.4. flots secondaires
(avec n un nombre entre 1 le nombre de cas d'utilisation)
Exemple:
Le système en discussion est un système logiciel informatique présentant des utilisateurs "autorisés".
L'acteur primaire est un administrateur du système capable de donner des droits aux différents utilisateurs.
L'objectif est de gérer (créer, modifier, supprimer, viualiser) les utilisateurs
flot du cas "Gestion des utilisateurs "
Préconditions
Il faut que lutilisateur soit repris comme un des administrateurs du système.
Flot principal
Le cas dutilisation commence quand un des administrateurs du système saisit son mot de passe pour accéder au système de gestion des utilisateurs. Le système vérifie la validité du mot de passe (E-1). Les actions suivantes sont proposées à ladministrateur :
Si lactivité sélectionnée est Ajouter, le sous-flot S-1 : Ajouter un utilisateur est exécuté.
Si lactivité sélectionnée est Modifier, le sous-flot S-2 : Modifier un utilisateur est exécuté.
Si lactivité sélectionnée est Supprimer, le sous-flot S-3 : Supprimer un utilisateur est exécuté.
Si lactivité sélectionnée est Consulter, le sous-flot S-4 : Consulter utilisateur est exécuté.
Si lactivité sélectionnée est Quitter, le cas dutilisation se termine.
1.3 Sous-flots
S-1 : Ajouter un utilisateur
Le système incite ladministrateur à entrer toutes les caractéristiques du nouvel utilisateur, y compris sil est administrateur oui ou non. Ladministrateur complète les champs. Le système procède ensuite à linsertion de ce nouvel utilisateur (E-2). Le cas dutilisation recommence ensuite.
S-2 : Modifier un utilisateur
Ladministrateur sélectionne dans la liste des utilisateurs celui quil désire modifier. Le système affiche un écran avec lensemble des champs qui caractérise un utilisateur, y compris sil est administrateur oui ou non (E-6). Ladministrateur modifie le contenu des champs quil désire mettre à jour. Le système procède à la modification de lutilisateur (E-3). Le cas dutilisation recommence ensuite.
S-3 : Supprimer un utilisateur
Le système affiche un écran avec lensemble des champs qui caractérise un utilisateur, ceux-ci ne sont pas modifiables (en lecture seule) (E-7). Ladministrateur les consultes pour sassurer que cest bien lutilisateur à supprimer. Le système procède à la suppression de lutilisateur (E-4). Le cas dutilisation recommence ensuite.
S-4: Consulter un utilisateur
Le système affiche un écran avec lensemble des champs qui caractérise un utilisateur, y compris sil est administrateur oui ou non, ceux-ci ne sont pas modifiables (en lecture seule) (E-5). Le cas dutilisation recommence ensuite.
Flots secondaires
E-1 : Une paire de login et mot de passe entrée est invalide. Ladministrateur peut effectuer, pour un même login, trois tentatives infructueuses ou sortir du cas dutilisation.
E-2 : Le système ne permet pas linsertion de lutilisateur. Ladministrateur peut procéder à une nouvelle tentative dinsertion de ce même utilisateur en le modifiant préalablement ou sortir du cas dutilisation.
E-3 : Le système ne permet pas la mise à jour de lutilisateur. Ladministrateur peut procéder à une nouvelle tentative de modification de cet utilisateur en le modifiant préalablement ou sortir du cas dutilisation.
E-4 : Le système ne permet pas la suppression de lutilisateur. Le cas dutilisation recommence.
E-5 : Le système ne permet pas la consultation de lutilisateur. Le cas dutilisation recommence.
E-6 : Le système ne permet pas la modification de lutilisateur. Le cas dutilisation recommence. E-7 : Le système ne permet pas la suppression de lutilisateur. Le cas dutilisation recommence.
exemple2 de patron: (moins rigoureusement structuré)
flot principal
"extensions"
variations exemple : Le système en discussion est une compagnie d'assurance
L'acteur primaire est un assuré ayant eu un accident de voiture
L'objectif est d'être payé pour les dégâts subis.
Les préconditions sont d'être en ordre d'assurance et que les circonstances de l'accident soient couvertes par la police.
La sortie est le fait que la compagnie paie.
Le client soumet le cas et toute une série de données.
La compagnie vérifie que le client possède bien une police valide.
La compagnie demande à un de ses agents d'examiner le cas.
L'agent vérifie que toutes les circonstances sont couvertes.
La compagnie paie le plaignant.
Extensions:
1.a. Les données sont incomplètes.
1.a.1. La compagnie requiert l'information manquante.
1.a.2. Le client fournit cette information.
2.a. Le client ne possède pas de police valide.
2.a.1. La compagnie rejette la plainte, notifie le client et termine le cas.
3.a. Aucun agent n'est disponible.
3.a.1. Que faire dans ce cas?
4.a. Les circonstances de l'accident violent une clause de base de la police.
4.a.1. La compagnie rejette la plainte, notifie le client et termine.
4.b. Les circonstances de l'accident violent une clause mineure de la police.
4.b.1. La compagnie entame une négociation avec le client pour fixer le pourcentage de paiement.
Variations:
(pour indiquer des précisions supplémentaires donnant lieu à de légères variantes ne "méritant" pas un use case particulier afin d'éviter une explosion du nombre de uses cases.)
Le plaignant est a) un particulier b) une société c) une autre compagnie d'assurance d) le gouvernement
Le paiement se fera par a) chèque b) virement c) décompte de la prochaine échéance de la police d) création d'une nouvelle police
Remarque: Ces 2 exemples nous montent que tous les cas d'utilisation ne présentent pas le même niveau d'abstraction. Il est primordial de cerner la quantité de détails que l'on désire y voir apparaître.
3.3. Diagrammes de cas d'utilisation
Acteurs + Cas d'utilisation + Relations
3 sortes de relations (entre cas d'utilisation et acteur et entre cas d'utilisation)
la relation de communication: association entre un acteur et un cas d'utilisation. A priori, cette association est navigable dans les 2 sens puisque l'acteur peut donner ou recevoir des informations. Le sens de la flèche indiquera l'initiateur de l'interaction. stéréotype (ou )
la relation d'utilisation entre 2 cas d'utilisation: précise qu'une instance du cas d'utilisation source comprend également le comportement décrit par le cas d'utilisation destination. En d'autres termes cette relation sert à ce que le cas d'utilisation source puisse utiliser les fonctionnalités du cas d'utilisateur destinataire stéréotype ou (ou ) But: Factoriser une partie de la description d'un cas d'utilisation qui serait commune à d'autres cas. Attention: Ne pas se servir de la relation pour découper fonctionnellement un cas en plusieurs sous-cas qui s'enchaînent car un cas doit représenter une fonctionnalité complète du début à la fin. En réalité, la relation d'utilisation (=d'inclusion) est un artifice pour faire de la réutilisation d'une portion de texte. Souvent le cas d'utilisation inclus n'est pas un "vrai" cas d'utilisation car n'a pas d'acteur déclencheur ou receveur d'événements. exemple:
la relation d'extension entre 2 cas d'utilisation signifie que le cas d'utilisation source "étend" le comportement du cas d'utilisation destination. En d'autres termes, cela montre un comportement optionnel, qui ne se réalise que sous certaines conditions (par exemple en cas d'alarme) ou plusieurs flots différents qui peuvent s'exécuter, selon la sélection de l'acteur. stéréotype: (ou ) = La relation la plus utile: Elle a une sémantique qui a du sens au niveau métier et n'est pas seulement un artifice d'informaticiens. But: Montrer un comportement optionnel a) qui ne se réalise que sous certaines conditions Un cas d'utilisation X étend un cas d'utilisation Y lorsque le cas d'utilisation X peut être appelé optionnellement au cours de l'exécution de Y exemple: SHAPE \* MERGEFORMAT Lors de la prise de commande pour un client, lorsqu'on s'aperçoit qu'il est un nouveau client, on ne doit pas annuler le processus de prise de commande et exécuter "enregistrerClient" puis reprendre le processus de commansde depuis le début mais on peut appeler "enregistrerClient" au sein de l'exécution de "prendreCommande". b) plusieurs flots différents qui peuvent s'exécuter, optionnellement, selon la sélection de l'acteur exemple: Un virement par PCBanking est une extension du virement effectué en agence. Dans les 2 cas, le client doit être identifié.
la relation de généralisation / spécialisation : On considère un cas d'utilisation de "base" générique qui décrit des séquences d'événements et d'autres cas qui héritent de ce comportement de base et le spécialisent suivant différents critères. SHAPE \* MERGEFORMAT
3.4. La transition vers les objets
Les cas d'utilisation servent donc à capturer les besoins du système, servir de base au design du logiciel, le valider, le tester et sont utilisés comme point de départ pour rédiger des aides en ligne et des manuels utilisateurs.
En fait, on peut associer une collaboration à chaque cas d'utilisation. Une collaboration décrit les objets du domaine, les liens entre ces objets et les messages échangés par les objets.
Les scénarios, instances des cas d'utilisation (différents chemins possibles de leurs flots d'événements), sont effectivement là pour aider à identifier les objets, les classes et les interactions qui interviennent dans les fonctionnalités spécifiées par le cas d'utilisation.
Alors que le flot d'événements d'un cas d'utilisation est spécifié sous forme textuelle, les scénarios seront représentés par des diagrammes d'interactions (collaboration et séquence).
3.5. Quelques règles de bonne modélisation au niveau des cas d'utilisation
Bien identifier les acteurs: 2 acteurs différents doivent nécessairement interagir de façon différente avec le système. Inutile d'introduire des acteurs dont les rôles sont déjà assumés par des acteurs existants.
Règle générale : 1 acteur par cas d'utilisation.
Bien identifier les cas d'utilisation: Quelles sont les tâches de chaque acteur? Un acteur va t'il créer, stocker, modifier, supprimer ou lire des informations du système? Pour quels cas d'utilisation aura t'on besoin de créer, stocker, modifier, supprimer ou lire ces informations? Un acteur aura t'il besoin d'informer le système d'un changement externe inopiné? Un acteur aura t'il besoin d'être informé de certains événements survenus dans le système? Tous les cas d'utilisation couvrent-ils bien l'ensemble des besoins fonctionnels? Tout comportement du système sans intérêt pour les acteurs ne doit pas être repris dans les cas d'utilisation.
Bien fixer la taille et le niveau de détails adéquats des cas d'utilisation: Il n'y a pas de recette mais il est conseillé de respecter le principe exigeant qu'un cas d'utilisation représente un fragment majeur de fonctionnalité, complet du début à la fin. Ainsi 2 activités qui s'enchaînent nécessairement toujours font probablement partie du même cas d'utilisation.
Eviter l'explosion des cas d'utilisation: Quand un cas d'utilisation devient trop complexe (plus de 10 pages par exemple), il devient adéquat de le subdiviser en une hiérarchie de cas d'utilisation. Ainsi, les détails des cas d'utilisation de niveau inférieur seront décrits ailleurs, n'en retenant que le succès ou l'échec dans le cas d'utilisation de départ.
Bien cerner les conditions de démarrage et d'arrêt de chaque cas d'utilisation.
Peut-on réaliser une brève description qui donne une vraie image de chaque cas d'utilisation?
Un grand nombre de cas d'utilisation est le signe d'un manque d'abstraction. Normalement quelle que soit la taille du système, il existe relativement peu de cas d'utilisation mais par contre beaucoup de scénarios possibles. Typiquement un système moyen comporte 10 à 20 cas d'utilisation.
Le processus unifié (RUP)
Le processus unifié est une méthode proposée par G. Booch, J. Rumbaugh, I. Jacobson.
Le développement de lapplication sorganise en une série de mini projets courts, dune durée fixe (on conseille entre deux et six semaines).
Chaque mini projet représente une itération.
Chaque itération comprend une activité danalyse des besoins, une activité de conception, une activité dimplémentation et de tests.
Le résultat dune itération est un système testé, intégré aux autres itérations et exécutable.
Le projet grandit petit à petit à chaque itération puisque chacune delle ajoute des fonctionnalités (il y a incrémentation des fonctionnalités).
La méthode unifiée est donc itérative et incrémentale.
Remarque : pendant une itération donnée, on peut revenir en arrière sur une itération précédente afin de laméliorer ; rien nest jamais gelé.
Les retours en arrières (feed-back) sont plus fréquents lors des premières itérations.
Le système se stabilise beaucoup plus par la suite.
RUP : une méthode pour aider à modéliser.
Etape1 identification des besoins
Lobjectif est de définir les besoins de lapplication.
Pour représenter graphiquement les cas dutilisation, on peut utiliser un diagramme dactivité .
Pour représenter un scénario particulier, on peut utiliser un diagramme de séquence.
Démarche 05 (pour lidentification des besoins)
Facultative
On affine les diagrammes et les descriptions en organisant les cas dutilisation par des relations dinclusion, dextension, de généralisation (très controversé) et par regroupements en package.
RUP : une méthode pour aider à modéliser
Etape 2 identifier les classes et attribuer les responsabilités
Après avoir défini les besoins (via les use cases), il faut décider des objets nécessaires pour les réaliser et donc des classes nécessaires pour les fabriquer et les contrôler.
Cest pendant cette étape quon fait les choix daffectation des responsabilités.
Cette étape a pour but daboutir à un modèle de conception.
Létablissement dun modèle de conception nécessite 3 connaissances : La connaissance du domaine quon doit informatiser
La connaissance des règles daffectations des responsabilités
La connaissance de solutions reconnues par le monde informatique (patterns)
Démarche 6 ( identification des classes et des responsabilités)
Etablir un modèle du domaine. Un modèle du domaine est un diagramme de classes conceptuelles. Il sert uniquement à comprendre le domaine et à mettre en évidence le vocabulaire du domaine
Comment identifier les classes conceptuelles ?
Deux stratégies sont proposées dans la littérature :
1ère stratégie :
On débusque des classes potentielles en se basant sur une liste de catégories.
LISTE CLASSE CONCEPTUELLE
Objets physiques caisse, article
Spécification ou description dobjet descriptionProduit
Lieux magasin
Transaction vente, payement
Ligne dune transaction ligne article, acompte
Rôle des personnes caissier, acheteur
Conteneurs magasin, rayonnage, tiroir caisse
Contenu dun conteneur article, pièce de monnaie
Autre système externe informatique ou non système autorisation de crédit
Concepts faim
Organisation département vente
Evénement vente, paiement, réunion
Règle et politique politique de remboursement,de ristourne
Catalogue publicité, catalogue produits
Documents comptables reçu, livre de caisse
2ème stratégie : On analyse les textes des scénarios et on relève les groupes nominaux qui peuvent représenter des entités, des attributs ou ne pas intéresser.
Scénario nominal
Un client arrive à la caisse avec de la marchandise.
Le caissier démarre une nouvelle vente
Le caissier enregistre le numéro didentification de chaque article, ainsi que la quantité si elle est supérieure à un.
La caisse affiche le prix de chaque article et son libellé au caissier et au client ainsi que le total en cours déjà atteint
Le caissier répète les étapes 3 et 4 jusquà ce que tous les articles soient passés.
le caissier signale la fin de la vente
La caisse affiche le total à payer.
Le client paye
La caisse enregistre la vente et imprime un ticket.
Le caissier donne le ticket au client
Remarque : ce nest pas automatique : le paiement napparaît pas sous forme de groupe nominal mais sous forme de verbe : le client paie.
Quelques conseils.
Faut-il prendre en compte les objets de trace ? Un objet de trace est une facture, un reçu ; quelque chose qui représente la trace de quelque chose dautre. (le reçu est la trace des achats) Sil sagit dune simple trace (c'est-à-dire dune information quon peut retrouver à partir de éléments qui la compose), linclure dans le modèle injecte de la redondance. Sil sagit par contre dun élément qui représente plus que la trace il faut alors linclure. Exemple : Faut-il le faire figurer le reçu dans le modèle ? Réponse : Oui car il donne à son porteur un droit déchanger la marchandise. Ce reçu a donc un rôle supplémentaire et nest donc plus une simple trace. Remarque : Comme on ne gère dans cette itération que les ventes et pas les retours, on ne prend pas en compte le reçu
Classe ou attribut ? ou
Astuce : Si la « chose » est composée de chiffres et de lettres, cest probablement un attribut, sinon cest vraisemblablement une classe. Un magasin nest pas composé de chiffres et des lettres. Cest un lieu physique avec une adresse, une surface. Cest donc un concept (une classe). Dans le doute il est préférable den faire une classe quun attribut. Les attributs sont rares dans un modèle de domaine.
Ne pas oublier les classes qui spécifient ou décrivent dautres classes.
SHAPE \* MERGEFORMAT
Meilleure solution : utiliser une classe de description de la vidéo.
SHAPE \* MERGEFORMAT
Les objets de description interviennent fréquemment en modélisation objet.
Application de ces stratégies au cas caisse enregistreuse
Les associations.
On détermine les associations significatives en relation avec le scénario en cours de développement.
Exemple :
Les associations du modèle du domaine stipulent des relations significatives au niveau conceptuel. Certaines de ces associations disparaîtront dans le modèle de conception. Inversement, certaines associations apparaîtront dans le modèle de conception.
Comment trouver les associations ?
On peut sinspirer dune liste des associations courantes.
Il y a association entre A et B si
A est un élément physique de B Caisse et Tiroir
A est un élément logique de B Vente et LigneArticle
A est physiquement contenu dans B Caisse et Magasin
A est logiquement contenu dans B DescriptionArticle et Catalogue
A décrit B DescriptionArticle et Article
A fait lobjet dune transaction de B LigneArticle et Vente
A est consigné/enregistré dans B Vente et Caisse
A est membre de B Caissier et Magasin
A est une sous unité organisationnelle de B Rayon et Magasin
A utilise et gère B Caissier et Caisse
A communique avec B Client et Caissier
A est lié à une transaction B Client et Paiement
A est une transaction liée à une transaction B Vente et paiement
A est voisin de B Article a et Article b
A appartient à B Caisse et Magasin
A est un évènement lié à B Vente et client, Vente et Magasin
Parmi cette liste, les associations prioritaires sont : A est un élément physique ou logique de B A est physiquement ou logiquement contenu dans B A est enregistré dans B
Modèle du domaine avec associations :
Remarque :
Une caisse est mono utilisatrice. A tout moment la caisse ne gère quune seule vente à la fois. Ceci explique entre autre les multiplicités 1-1 entre vente et caisse.
Pour rappel : ce modèle du domaine est partiel : il na été inspiré que par lanalyse du morceau de scénario « traiter une vente » qui correspond à litération choisie.
Ce modèle du domaine nest pas figé et peut subir des corrections.
Sa raison dêtre est de mettre à disposition du vocabulaire décrivant lapplication.
Démarche 7 : (identification des classes et des responsabilités)
On écrit des contrats pour certaines opérations système en utilisant le vocabulaire du modèle du domaine (facultatif).
Soit les opérations systèmes suivantes :
Lexpression des contrats peut conduire à la modification du modèle de domaine.
Exemple : contrat de terminer vente
Opération : terminerVente()
Référence croisée : cas dutilisation : traiter une vente
Préconditions : il existe une vente en cours
Postconditions :
Lexpression de la postcondition nest pas possible avec le vocabulaire du modèle de domaine actuel. Il faut donc le modifier en ajoutant par exemple un boolean venteTerminée .
SHAPE \* MERGEFORMAT Postconditions : venteTerminee est vrai
Passage du modèle de domaine vers le modèle de conception.
Le modèle de conception est constitué
de diagrammes de classes logicielles (classes + attributs +opérations)
de diagrammes dinteractions nécessaire entre les objets des classes logicielles pour satisfaire les besoins identifiés par les uses case.
Démarche 8 :
(La plus importante concernant lidentification des classes et des responsabilités.)
Pour chaque opération système a) on définit les classes logicielles à implémenter. b) On affecte des responsabilités à ces classes
On saide de diagrammes dinteraction (diagramme de séquence ou diagramme de collaboration). On justifie nos choix daffectation par les patterns généraux daffections de responsabilité.(GRASP)
Quest ce quune responsabilité en UML ?
Une responsabilité est un contrat ou une obligation dun classificateur (classe, package).
Ces responsabilités sont de deux types : faire et savoir.
Exemple de responsabilité de faire : Créer un objet
Déclencher une action dun autre objet
Coordonner les activités dautres objets
Exemple de responsabilité de savoir : Connaître les données privées encapsulées.
Connaître les objets liés
Connaître les éléments quil peut calculer
Lorsque lon crée les diagrammes dinteractions on prend des décisions qui se reflètent dans les messages envoyés aux différentes classes.
Ces décisions se prennent selon une série de patterns . (Un ouvrage célèbre (« design patterns : catalogue de modèles de conception réutilisables) traite ce sujet. Il est écrit par Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides connus sous le nom de la bande des quatre.)
Quelques patterns :
Le pattern expert en information.
Problème : A qui affecter une responsabilité. Quel est le principe général à envisager en premier lieu. (le principe des principes)
Solution : on affecte la responsabilité à lexpert en information :
Lexpert en information est la classe qui possède les informations nécessaires pour assumer sa responsabilité. Ce pattern ne fait quexprimer une intuition : « qui sait fait ».
Exemple :.
Le système doit connaître le total à faire payer au client.
Qui doit avoir la responsabilité de connaître ce total (qui est capable de la calculer)?
Le pattern expert dit quil faut rechercher la classe qui possède les informations nécessaires pour déterminer ce total.
Observons la partie du modèle du domaine qui contient la réponse.
Le total à payer est la somme des totaux de chaque ligne darticle.
Vente connaît toutes les ligneArticle, il a donc selon lexpert en information la responsabilité de calculer le total à payer.
Exprimons cette décision dans le diagramme de collaboration :
Ce qui donne comme classe logicielle :
Le raisonnement doit bien entendu continuer. getTotal va sommer les sous-totaux de chaque ligne. Le sous total dune ligne est la quantité x le prix de larticle de la ligne. Lexpert en information nous dit que ligneArticle connaît la quantité et la description de larticle concerné, ce qui lui permet den connaître le prix. ligneArticle a donc la responsabilité de connaître son sous total
Exprimons cette décision dans le diagramme de collaboration :
Ceci donne les classes logicielles suivantes :
SHAPE \* MERGEFORMAT
En Uml lusage consiste à ne pas indiquer les accesseurs des champs (pour ne pas alourdir le schéma)..
Ceci explique quon nindique pas getPrix dans DescriptionArticle..
Le pattern créateur.
Problème. Qui doit avoir la responsabilité de créer une nouvelle instance lorsquon en a besoin.
Solution. La classe B est responsable de créer une instance de la classe A si une ou plusieurs des conditions suivantes existent :
B agrège des objets de A (agréger signifie mettre ensemble pour faire un tout)
B contient des objets de A
B enregistre des objets de A
B utilise étroitement des objets de A (subjectif)
B connaît les données dinitialisation des objets de A ( cf expert en information)
Exemple
Qui doit créer une instance de ligneArticle ?
Vente agrège (et contient) les ligneArticle, lexpert créateur justifie que Vente crée les instances de ligneArticle.
Ceci donne la classes logicielle VENTE suivante :
Le pattern contrôleur. La couche interface ne gère pas les évènements systèmes.
Problème : qui doit avoir la responsabilité de gérer un évènement du système entrant. (généré par un acteur externe).
Solution : le traitement dun évènement entrant est affecté à une classe dédiée à cet effet :
Soit
La classe représente lensemble du système. Il ny a alors quune seule classe destinée à la gestion de tous les évènements entrants. Cette classe peut être arbitrairement créée (hors du modèle du domaine) ou être une classe existante. On appelle cela une façade.
La classe représente un scénario de cas dutilisation. Il existe alors plusieurs classes qui soccupent de la gestion des évènements dentrées. Ces classes sappellent alors gestionnaires de
« nom du scénario » ou contrôleur de « nom du scénario ».
Le pattern contrôleur garantit que la couche interface ne gère pas les évènements système :
La logique de lapplication est donc isolée de linterface de lapplication, ce qui permet de changer facilement dinterface ou de modifier la couche application sans modification de linterface.
exemple de mauvaise solution :
On place la logique de lopération au niveau de linterface.
Pour rappel : Lopération système est saisirArticle. La logique de cette opération consiste entre autre à « créerLigneArticle ».
onClick
La couche interface soccupe de la gestion de lopération système saisirArticle.
Cette architecture est moins souple que celle faisant appel à un contrôleur.
Cette solution est considérée comme mauvaise car une modification dans la couche domaine peut entraîner une modification dans la couche interface.
Exemple de bonne solution
événement onClick
La couche interface (TButton) ne sert quà transformer les « évènements utilisateurs » (onClick) en opération système (saisirArticle). La logique de lopération saisirArticle est gérée par un objet de la couche domaine (ici cest caisse).
Affectation des responsabilités aux objets pour lexercice de la caisse enregistreuse :
Les patterns servent de guide pédagogique pour prendre les décisions.
Exemple : Opération système SaisirArticle
Lopération saisirArticle a lieu lorsque le caissier saisit le code de larticle et la quantité (facultatif).
Soit le contrat opération suivante :
Opération : saisirArticle(codeArticle :codeArticle,quantité :entier) ;
Référence croisée : cas dutilisation : traiter une vente
Préconditions : il existe une vente en cours
Postconditions : 1) une instance LA de ligneArticle a été crée (création dinstance) 2) LA est associée à la Vente en cours (formation dassociation) 3) LA.quantité est initialisé à quantité 4) LA a été associée à une descriptionProduit sur base du codeArticle(le paramètre) (formation dassociation)
On établit un diagramme de séquence ou de collaboration qui satisfait les post conditions de lopération.
Choix du contrôleur : Façade ( objet caisse
Réalisation des post-conditions
1) une instance LA de ligneArticle a été créée Il sagit ici de la création dune ligneArticle particulière et non plus de la collection vide des ligneArticle. La ligneArticle créée sera ensuite ajoutée dans la collection des ligneArticle.
Nous avons déjà désigné Vente comme créateur de la collection ligneArticle. On peut également considérer que Vente contient les ligneArticle et en est donc le créateur de chaque ligneArticle (raisonné selon le pattern créateur).
2) LA est associée à la Vente en cours ( lassociation consiste à stocker LA dans la collection des LA de Vente.
3) LA.quantité est initialisé à quantité ( comme cest Vente qui crée LA, Vente doit connaître quantité . Caisse doit passer quantité à Vente (comme paramètre dans son message).
EMBED Word.Picture.8 4) LA a été associée à une descriptionProduit sur base du codeArticle. ( Il faut donc extraire la descriptionProduit à laide du code.
Le modèle du domaine indique que la classe CatalogueProduit connaît toutes les DescriptionsArticle. Lexpert désigne CatalogueProduit comme responsable de fournir la description de produit.
SHAPE \* MERGEFORMAT
Caisse connaît les éléments (le code) pour obtenir la description darticle (pattern expert)
EMBED Word.Picture.8
Résumé de saisirArticle :
EMBED Word.Picture.8
Remarque : Considérons pour le moment que la collection des DescriptionArticle est entièrement contenue en mémoire. Ultérieurement, nous envisagerons quelle se trouve dans une base de données, ce qui nous obligera à introduire de nouvelles classes logicielles.
Démarche 9 : (identification des classes et des responsabilités)
Etablir le diagramme de classe de conception a) identifier les classes logicielles b) ajouter les attributs et les méthodes c) ajouter les associations et les navigabilités d) ajouter les relations de dépendance e) ajouter les visibilités f) on indique les attributs et méthodes de classe
Remarque :il est dusage
De ne pas indiquer les méthodes et constructeurs liés à la création et initialisation dobjets.
De ne pas indiquer les accesseurs et modificateurs dattributs (les méthodes daccès get et put). Exemple : on na pas indiqué getPrix dans DescriptionArticle.
Diagramme de conception (classes logicielles) :
4. Modèle dynamique
4.1. Introduction
Le modèle statique a permis détudier la structure des objets du système et les relations entre ceux-ci.
Les aspects du système tributaires du temps (modifications des objets) seront regroupés dans un modèle dynamique. Dans le chapitre Approche Objet, nous avons dailleurs déjà ébauché ce domaine au moyen des diagrammes dinteractions.
Le modèle dynamique est sans grand intérêt pour un système de données purement statiques, tel quune base de données. Par contre, il est très important pour les sytèmes interactifs.
Avec le temps, les objets se stimulent les uns les autres et il en résulte souvent une série de changements de leurs états.
Lorsque les interactions seront complexes, il sera souvent utile de détailler le comportement interne des objets.
4.2. Les automates
Le comportement des objets dune classe peut être décrit en termes détats(valeurs des objets) et dévénements (stimuli externes) au moyen dun automate relié à la classe considérée. Ces automates ou machines à états finis sont un concept standard de base de linformatique.
Un automate est une abstraction de tous les comportements possibles au sein dune classe. Chaque objet suit le comportement décrit dans lautomate et se trouve à un moment donné dans un état qui caractérise ses conditions dynamiques.
4.3. Etats
Chaque objet est à un moment donné dans un état particulier.
Notation UML : rectangle aux coins arrondis avec son nom (unique).
Un état est toujours limage des valeurs dattributs (une sorte de combinaison de certaines de ces valeurs, dautres naffectant pas la structure de contrôle) ET de la présence ou non de liens vers dautres objets.
exemple: Personnes travaillant pour une société : Diagramme de classes:
Les 3 états possibles (du point de vue professionnel) pour une personne à un moment donné sont:
Pour connaître la situation (létat) dune personne en particulier (un objet, instance de la classe Personne), il faut étudier la conjonction âge / présence dun lien vers la société sur le diagramme dobjets:
SHAPE \* MERGEFORMAT
On en déduit alors que André est dans létat chômeur, Antoine en activité et Albert retraité.
Un objet est toujours dans un état donné et cela pour un certain temps (idée de durée).
Ainsi, un état est souvent associé à une activité continue ou une activité qui prend un certain temps d'exécution.
UML propose une notation spéciale pour un état dit initial :
et pour un état final :
Les automates étant ici totalement déterministes, il faudra toujours décrire un état initial. Par contre, un automate peut ne pas posséder détat final (un système cyclique) ou en posséder plusieurs.
4.4. Evénements et diagrammes détats-transitions
= représentations graphiques des automates
Lorsque les conditions dynamiques évoluent, les objets changent détat en suivant les règles décrites dans lautomate associé à leur classe.
UML a intégré le formalisme proposé par David Harel avec ses statecharts pour représenter les diagrammes détats (représentations graphiques dautomates à états finis).
Les diagrammes détats-transitions seront des graphes dirigés dont les sommets seront les états et les arcs des connexions unidirectionnelles appelées transitions.
Le passage dun état à un autre (instantané) se produit lorsquune transition est déclenchée par un événement qui survient. Le nom de lévénement est alors placé sur la transition.
A linverse des états, les événements nont donc pas de durée (afin quun objet ne soit jamais dans un état inconnu ou non défini).
Un événement peut logiquement en précéder ou en suivre un autre mais 2 événements peuvent également être totalement indépendants, sans aucun lien de causalité. Ces derniers sont alors qualifiés de concurrents.
Un événement est une voie de transmission dinformation à sens unique dun objet vers un autre. La communication par événement est dailleurs de type asynchrone: Un objet peut envoyer un événement à un autre objet qui doit toujours être à même de linterpréter.
Un événement transporte de linformation vers un autre. Certains peuvent uniquement signaler que quelque chose survient, dautres transportent des données.
Les transitions indiquent les chemins dans le graphe des états, les événements déterminent quels chemins doivent être suivis.
exemple1: diagramme d'états-transitions de situations "professionnelles"
exemple 2 : diagramme d'états d'un jeu d'échecs
On peut également placer des gardes (notation : expression entre crochets), conditions booléennes qui valident ou non le déclenchement dune transition lors de loccurrence dun événement. Ainsi un même événement pourrait déclencher plusieurs transitions à partir dun même état tout en gardant laspect déterministe.
exemple:
4.5. Opérations, actions et activités
Le lien entre les opérations définies dans la spécification des classes et les événements qui apparaissent dans les diagrammes détats-transitions se fait via les actions et les activités.
Ainsi, chaque transition peut être décorée par le nom dune action à exécuter lorsquelle (la transition) est déclenchée par un certain événement.
Une action est nécessairement instantanée (du moins de durée négligeable par rapport à la dynamique du système) et atomique (non divisible en dautres actions).
Par exemple: déconnecter la ligne peut être une action en réponse à lévénement raccrocher.
Laction correspond alors à une des opérations déclarées dans la classe dont le temps dexécution est négligeable. Elle a accès aux paramètres de lévénement comme aux attributs de lobjet.
Remarque:
UML permet également de préciser dautres moments dexécution dactions. Ainsi un état peut contenir des actions en précisant quelles seront exécutées dès lentrée dans létat (notation: entry:
), à la sortie (notation: exit:
) ou lors de loccurrence dun événement interne (qui ne conduit pas à un autre état) pendant que lobjet se trouve dans létat (notation: OnUnEvénement:
).
Lorsquune opération prend un temps non négligeable et est exécutée pendant que lobjet est dans un état donné, on la qualifie dactivité.
(notation UML: do: ...).
Les activités peuvent être interrompues à tout moment lorsquune transition de sortie de létat est déclenchée.
Certaines activités dites cycliques ou continues ne sarrêtent dailleurs que comme cela (comme laffichage dune image sur un écran de télévision). Dautres séquentielles- (comme lexécution dun calcul) démarrent à lentrée dans létat après exécution des actions dentrée et prennent fin naturellement en arrivant à leur terme après un intervalle de temps, après quoi, létat peut être quitté si une des transitions est franchissable.
Ordre dexécution des opérations: op1, op2, op3, op4, op5, op6
4.6. Diagrammes détats-transitions imbriqués - Généralisations
Les diagrammes détats-transitions peuvent être structurés pour permettre des descriptions concises de systèmes complexes. En effet, lorsquil y a beaucoup de connexions entre états, on assiste à une explosion combinatoire qui rend les diagrammes totalement illisibles.
On structurera donc ces diagrammes de la même manière que les diagrammes de classes par lemploi de généralisations et dagrégations, ceci afin de faciliter la représentation et docculter des détails.
Les généralisations détats permettent à une activité (à un état) dêtre décrite à haut niveau puis dêtre étendue à un niveau inférieur en rajoutant des détails.
La généralisation exprime la relation - ou.
Un état est décomposé en sous-états disjoints héritants des caractéristiques de leur super-état (par exemple de leurs transitions ou de leurs actions). Un objet est alors précisément dans un seul de ces sous-états (ou dans un autre ou
).
Exemple:
Diagramme détats dune boîte de transmission automatique de voiture.
La transmission peut être dans les états MarcheArrière, PointMort, MarcheAvant. Les états Première, Deuxième, Troisième sont des sous-états de MarcheAvant.
Notation UML : Un super-état est représenté par une grande boîte arrondie enfermant tous ses sous-états. Harel les appelle contours.
Les transitions du super-état sont héritées par chacun des sous-états. Sélectionner PassePM depuis nimporte quel état de vitesse avant provoque une transition au point mort.
La transition de MarcheAvant vers PointMort implique donc trois transitions héritées.
MarcheAvant est donc un état abstrait; le contrôle doit être dans un état réel comme Deuxième.
La transition sur lévénement arrêt du super-état MarcheAvant à létat première représente une transition héritée par toutes les sous-états càd on modélise ici que dans chaque vitesse de marche avant, larrêt de la voiture provoque une transition vers Première.
Il est également possible de représenter des situations plus compliquées, comme une transition explicite dun sous-état vers un état en dehors du contour.
4.7. Concurrence et Agrégations détats Communication entre objets
Les agrégations détats réalisent une composition dun état à partir de plusieurs autres états indépendants.
Lagrégation exprime la relation - et.
En réalité, dans un système, la plupart des objets sont de façon inhérente concurrents càd quils peuvent changer détat indépendamment.
Aussi, létat dun système entier ne peut être représenté par un état unique dans un objet unique. Il est le produit de tous les états de tous les objets.
Un diagramme détats pour un assemblage est une série de diagrammes détats, un pour chaque composant. Létat de lagrégé est un état du premier diagramme et un état du second et
Bien sûr bien il arrive que les états composants interagissent. Les transitions gardées pour un objet peuvent dépendre dun autre objet dans un état donné. Cela permet une interaction entre les diagrammes détats tout en préservant leur modularité.
Exemple:
Voiture à boîte automatique
Diagramme de classes présentant des agrégations.
Diagramme d'états-transitions présentant des agrégations d'états
Létat dune voiture est donc une agrégation détats composants.
Chaque composant subit des transitions parallèles. Les diagrammes détats de composants sont presque, mais pas tout à fait, indépendants : la voiture ne démarrera pas tant que la transmission ne sera pas au point mort (cf expression gardée sur la transition de Arrêt à Démarrant.
Remarque:
Les agrégations détats permettent donc de simplifier fortement les diagrammes. En effet sans agrégations, lautomate dun composite possède un nombre détats maximal égal au produit du nombre détats de chaque automate composant. Ses états sont des tuples combinant les différents états des composants (etat1,etat2,etat3,
).
Pour lexemple précédent, le diagramme détat à plat de la voiture afficherait donc au maximum 3 * 5 * 2 *2 = 60 états au lieu de 3 + 5 + 2 +2 = 12 états.
3 automates dune centaine détats en donnerait donc un dun million détats!!!
Remarque:
La concurrence au sein dun objet unique survient quand lobjet peut être partitionné en sous-ensembles dattributs ou de liens, chacun deux ayant son propre sous-diagramme. Létat de lobjet englobe alors un état pour chaque sous-diagramme.
4.8. Diagrammes dinteractions versus Diagrammes détats
Dans les 2 sortes de diagrammes, il est question de dynamique du système.
Les objets communiquent en échangeant des messages.
Les diagrammes dinteractions (collaboration ou séquence) visualisent les échanges entre objets au travers de ces messages. Ils montrent des cas particuliers de comportement au sein dun cas dutilisation. Ils illustrent un scénario particulier càd une séquence dévénements se déroulant durant une exécution particulière dun système.
Bien sûr, le comportement décrit par un scénario est une conséquence particulière de létat de tous les objets qui collaborent au sein de ce scénario.
Les envois de messages entre 2 objets sont visualisés de manière abstraite dans le formalisme des diagrammes détats-transitions par lenvoi dun événement entre les automates détats-finis des classes dobjets concernés.
A priori, un diagramme détats décrit le comportement dune seule classe dobjets. Puisque tous les objets dune classe ont par définition le même comportement, ils partagent tous le même diagramme détats, comme ils partagent tous les mêmes caractéristiques de classe.
Bien sûr, chaque objet a son propre état, résultat de la séquence unique dévénements quil a reçue. Chaque objet est indépendant et fonctionne à son propre rythme.
Ces objets concurrents interagissent en échangeant des événements et en testant des conditions sur dautres objets.
Un diagramme détat, comme une classe dobjets, est un patron. Il décrit un éventail complet, éventuellement infini, de séquences détats possibles.
Le modèle dynamique est constitué dune collection de diagrammes détats (un pour chaque classe au comportement dynamique important) qui interagissent les uns avec les autres, par lintermédiaire dévénements partagés. Il est un patron qui spécifie les scénarios pouvant se produire.
Un scénario (et son diagramme dinteraction) est au modèle dynamique ce quun diagramme dobjets est au modèle statique.
Remarque: Durant la réalisation les automates illustrés par les diagrammes détats-transitions pourront sécrire facilement par exemple au moyen de tables contenant les états et les actions à exécuter lors des transitions.
Exemple :
Un scénario dutilisation dune ligne téléphonique à travers un diagramme de séquence est présenté au chapitre 2 page 18.
Le diagramme détats pour la ligne téléphonique. Il contient des séquences associées à des appels normaux autant que des séquences anormales, comme une coupure de téléphone au moment de la composition du numéro ou bien une ligne occupée.
On remarque que les états ne définissent pas toutes les valeurs dun objet. Par exemple, létat Composant inclut toutes les séquences de numéros de téléphone incomplets. Ce nest pas la peine de différencier les divers numéros en états séparés puisquils ont tous le même comportement.
Remarque:
Toutes les transitions de retour vers l'état En attente sont provoquées par l'événement raccroche qui peut intervenir n'importe quand.
On peut redessiner ce diagramme en utilisant un super état actif regroupant tous les états sauf l'état "En attente".
4.9. Quelques règles de bonne modélisation
Ne construisez de diagrammes détats-transitions que pour les classes dobjets ayant un comportement dynamique significatif. On identifiera ces classes en repérant les objets sur les diagrammes dinteractions qui sont à lorigine déchanges intenses de messages.
Utilisez donc des scénarios pour vous aider à démarrer le processus de construction des diagrammes détats.
Ne considérez que les attributs pertinents pour définir un état. Tous les attributs du modèle objet ne se retrouvent pas nécessairement dans les diagrammes détats.
Utilisez des états imbriqués quand la même transition sapplique à plusieurs états.
Essayez de faire des diagrammes détats de sous-classes indépendants des diagrammes détats de leur super-classe.
4.10. Diagrammes dactivités
= Variantes des diagrammes détats-transitions
principalement destinés à représenter le comportement interne séquentiel dune méthode ou dun cas dutilisation.
Un diagramme dactivités représente létat de lexécution dun mécanisme sous la forme dun déroulement détapes regroupées séquentiellement dans des branches parallèles de flot de contrôle.
En fait, il est fréquent que le seul but dun état soit dexécuter une activité séquentielle. Quand lactivité est achevée, une transition vers un autre état est déclenchée. Il sagit ici dune transition automatique (sans nom dévénement), lévénement implicite correspondant simplement à la fin de lactivité précédente.
Dans ce cas, on simplifie la représentation graphique des états réduits à leur activité.
Notation UML: Une activité sera un rectangle arrondi comme les états mais plus étiré horizontalement:
Le diagramme
prend donc la place de
Chaque activité représente une étape particulière dans lexécution de la méthode englobante.
Remarque: Les activités ne possèdent ni transitions internes, ni transitions déclenchées par des événements.
Les transitions entre activités peuvent être gardées par des conditions booléennes mutuellement exclusives.
Notation UML : losange doù sortent les transitions.
Un objet est parfois obligé dexécuter 2 ou plusieurs activités concurremment. Les étapes internes de ces activités ne sont pas synchronisées mais les deux activités doivent être achevées avant que lobjet puisse progresser ver létat suivant.
Notation UML : Les diagrammes dactivités représenteront les synchronisations entre flots de contrôle au moyen de barres de synchronisation.
Elles permettent douvrir et de fermer des branches parallèles au sein dun flot dexécution dune méthode ou dun cas dutilisation.
Pour refroidir, il faut donc en parallèle arrêter le chauffage et ouvrir les fenêtres.
On remesure la température une fois que le chauffage est arrêté et que la pièce est aérée.
Les diagrammes dactivités peuvent être découpés en couloirs dactivités qui montrent les différentes responsabilités au sein dun mécanisme ou dune organisation.
Chaque responsabilité est assurée par un ou plusieurs objets. Chaque activité se positionne dans un couloir bien particulier.
Remarque: les transitions peuvent librement traverser les couloirs.
exemple : Diagrammes dactivités correspondant au sous-flot Supprimer un utilisateur du cas dutilisation Gestion des utilisateurs (page 46).
Autres exemples de diagrammes d'activités
Analyse Orienté Objet - UML
Exercices sur le Modèle Dynamique
Le contrôle de la direction (avant, arrière) des premiers trains électriques jouets se faisait en interrompant l'alimentation du train. Préparez un diagramme d'états pour les feux avant et les roues du train, correspondant au scénario suivant: Le courant est coupé, le train ne bouge pas. Le courant est rétabli, le train se déplace vers l'avant et les feux avant sont allumés. Le courant est coupé, le train s'arrête et les feux s'éteignent. Le courant est rétabli, les feux avant sont allumés mais le train ne bouge pas. Le courant est coupé, les feux s'éteignent. Le courant est rétabli, le train se déplace vers l'arrière et les feux avant sont allumés. Le courant est coupé, le train s'arrête et les feux s'éteignent. Le courant est rétabli, les feux avant sont allumés mais le train ne bouge pas. Le courant est coupé, les feux s'éteignent. Le courant est rétabli, le train se déplace vers l'avant et les feux avant sont allumés.
Une montre digitale simple possède un cadran et 2 boutons, que l'on nommera A et B, pour la mettre à l'heure. La montre a 2 modes d'opération, affichage de l'heure et mise à l'heure. En mode affichage, les heures et les minutes sont affichées, séparées par un signe "2 points" intermittent. Le mode de mise à l'heure a 2 sous-modes, heures et minutes. Le bouton A s'utilise pour les modes. A chaque fois que l'on appuye dessus, le mode change suivant la séquence: affichage, configurer heures, configurer minutes, affichage, etc... Dans un sous-mode, le bouton B s'emploie pour avancer les heures ou les minutes à chaque fois que l'on appuye dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement. Préparez un diagramme d'états de la montre.
Révisez le modèle dynamique de l'exercice précédent pour offrir un moyen plus rapide de mise à l'heure en pressant et en maintenant le bouton B. Si celui-ci est poussé et maintenu pendant plus de 5 secondes dans le mode de mise à l'heure, les heures ou les minutes (selon le sous-mode) s'incrémentent toutes les demi-secondes.
On considère un système simplifié pour le contrôle d'un répondeur téléphonique. La réponse automatique aux appels se fait comme suit: un appel entrant est détecté sur la première sonnerie et la machine répond à l'appel avec un message enregistré. Lorsque le message est terminé, le message de l'appelant est enregistré. Lorsque l'appelant raccroche, la machine raccroche et s'arrête. Identifiez les différents états et placez les événements, actions ou activités suivants dans le diagramme: appel détecté, diffusion de l'annonce, enregistrement du message, raccrochage de l'appelant, fin de l'annonce.
Le répondeur téléphonique de l'exercice précédent est activé sur la 1ère sonnerie. Révisez ce diagramme pour que le déclenchement se fasse après la 5è sonnerie. Si l'on répond à l'appel avant la 5è sonnerie, la machine ne doit rien faire. Veillez à faire la distinction entre 5 appels pendant lesquels on répond au téléphone à la première sonnerie et un appel qui sonne 5 fois.
PAGE
PAGE 103
:Porte
:Cabine
:Lumière
:Bouton
ouvrir
aller au Rez
faire clignoter
Comportement visible
Un objet
état interne caché
accessible aux autres objets
UnEtudiant
Alain
Silovy
rue Bleue,22
UnEtudiant
Alain
Silovy
rue Verte,44
article
livraison
recommande
[pas de stock]
[de stock]
A
B
* [X] msg
B
A
while X
loop
end loop
return p:=valeur de retour
appel
arrivée
source
new
return
X
créé {nouveau}
source
:fenêtre
d'entrée de commande
:ligne de recommande
:article
:commande
:ligne de commande
:ligne
de
livraison
préparer()
* préparer()
vérifier()
[de stock]
retirer()
recommander()
[recommander==vrai]
new
[de stock]
new
La conversation
peut commencer
:maison
âge
prix
:cheval
âge
prix
Nom de classe
attributs
Opérations()
Rectangle
longueur
largeur
surface()
Opérations()
Rectangle
longueur
largeur
/surface
Opérations()
Téléviseur
allumer()
éteindre()
changerProgramme()
réglerVolume()
dépôt
montant
date
retrait
montant
date
Compte Epargne
solde
taux
déposer()
retirer()
Compte Courant
solde
déposer()
retirer()
effectué sur
effectué sur
nombre complexe
- module
- argument
+ Addition()
+ Soustraction()
+ Multiplication()
+ Division()
nombre complexe
- partie réelle
- partie imaginaire
+ Addition()
+ Soustraction()
+ Multiplication()
+ Division()
Une Classe
Vue A
Un utilisateur
Vue B
Un autre utilisateur
Compte en Banque
IClient
IBanquier
Compte en Banque
Math
Université
Etudiant
Etudiant
Salle
Prof
Cours
début
fin
Etudiant
Salle
Prof
Cours
début
fin
Personne
Société
travaille pour>
Personne
Société
employé
employeur
Personne
Moto
conduire
démarrer
laver
arrêter
Personne
Société
employé
employeur
1
0..*
Etudiant
TP
réalise >
cote
rien
A
B
C
attributs
opérations()
D
Equipe
Personne
joueur
capitaine
{sous-ensemble}
*
1
Equipe
Personne
joueur
trésorier
{ou-exclusif}
*
1
Personne
2 Parents
Enfants *
2..4
1
Moteur
Avion
:Client
:Délégué1
:Interface
:Délégué2
Question
propag.
Animal
Nourriture
Station
Carnivore
Quadrupède
Herbivore
Bipède
1
1
Répertoire
Nom_fichier
Fichier
0..250
1
Parking
Voiture
0..50
Parking
Voiture
Etage
1
*
User
Password
Employé
Badge
Association
Employé
Badge
dépendance
1
1
voiture
cylindre
carburateur
moteur
1
1
1
1
1
1
1
1
1
1
ensemble des besoins
userA
userD
placer une commande
virement par
PCbanking
Identification
virement en
agence
client distant
client local
40 ans
75 ans
30 ans
André
:Société
Antoine
Albert
Responsable clientèle
Prendre commande
Enregistrer client
Responsable clientèle
Souscrire contrat
Souscrire contrat X
Souscrire contrat Y
Démarche 01 (pour lidentification des besoins)
On identifie les acteurs et on établit un premier diagramme de haut niveau dabstraction, appelé diagramme de contexte.
Ce diagramme sert à délimiter précisément les frontières du système.
Démarche 02 (pour lidentification des besoins).
Lorsque le diagramme de contexte est établi on identifie les cas dutilisation du système
Démarche 03 (pour lidentification des besoins).
On donne une description textuelle des cas dutilisation afin de les décrire.
Démarche 04 facultative (pour lidentification des besoins).
On documente les cas dutilisation et les scénarios dune description graphique.
Ou
Vente
magasin
Vente
Magasin
Cette modélisation est déconseillé.
Si toutes les vidéos sont vendues, toutes les occurrences vidéo sont détruites et on perd le descriptif, le prix etc,
De plus il y a une duplication dinformations.
VIDEO
descriptif
prix
numéro de série
code article
VIDEO
numéro de série
DescriptionArticle
descriptif
prix
code article
1
n
décrit
n
1
CatalogueProduit
LigneArticle
quantite
Paiement
Client
Magasin
Adresse
nom
n
1
n
1
utilisé par
Gérant
Vente
1
1..n
1
1..n
contenue dans
1
1
1
1
Payée par
1
1
1
1
solicité par
0..n
1
0..n
1
journalise
caissier
caisse
1
n
1
n
est dans
1
1
1
1
contrôlée par
1
1
1
1
saisie
1
1
1
1
enregistre le vente sur
DescriptionArticle
descriptif
prix : monnaie
codeAticle : codearticle
1..n
1
1..n
1
contient
1
0..n
1
0..n
Décrit par
article
1..n
0..1
1..n
0..1
Enregistre le vente de
1
0..n
1
0..n
stocke
décrit
Pendant lanalyse, on peut affecter les opérations à une classe appelée système. Ceci noblige absolument pas de créer une classe logicielle système.
Vente
date
heure
venteTerminee
DescriptionArticle
descriptif
prix : monnaie
codeAticle : codearticle
La logique de lapplication est gérée par Tbutton qui fait partie de linterface
Couche domaine
Couche interface
La logique de lapplication est gérée par caisse qui joue le rôle de facade
Couche interface
Couche domaine
CatalogueProduit
DescriptionArticle
descriptif
prix : monnaie
codeAticle : codearticle
1..n
1
contient
DescriptionArticle
descriptif
prix : monnaie
codeAticle : codearticle
getPrix()
LigneArticle
quantite
getSousTotal()
1
0..n
1
0..n
décrit
Paiement
montant
caisse
créerNouvelleVente()
terminerVente()
saisiirArticle()
créerPaiement()
CatalogueProduit
getDescription()
chargementDescriptionProduit()
1..n
1
1..n
1
contient
1
1
1
1
consulte
Vente
date
heure
venteTerminee
getTotal()
creerLigneArticle(quantite)
Ternimer()
getPaiement()
1..n
1
1..n
1
contient
1
1
1
1
saisir
1
1
1
1
Payer par
Magasin
Adresse
nom
ajoutervente()
1
1
1
1
est dans
1
1
1
1
utilise
1
