Uml

Mthodes d'analyse et de conception orientes objet UML (Unified Modeling Language)
Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)
Pourquoi modliser ? (1)

Importance de la modlisation La niche, la maison familiale et l'immeuble pour construire une niche :
quelques planches, des clous, un marteau et quelques outils.
pour construire une maison familiale :

+ plans gnraux, plans d'excution dtaills (pices, lectricit, plomberie, chauffage) ;
pour construire un immeuble :

+ Planification dtaille, nombreux plans et tudes

Do lintrt dune modlisation pour Mieux comprendre le systme Objectifs :
nous aider le visualiser tel qu'il est ou tel qu'il devrait tre spcifier la structure et le comportement d'un systme avoir un "patron" pour guider la construction du systme documenter les dcisions qui ont t prises
Nous construisons des modles de systmes complexes parce que nous sommes incapables d'apprhender ces systmes dans leur entiret. Un modle est une simplification de la ralit
Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML) 3

Lapproche par modlisation facilite: La communication (et sa prcision)
avec donneur dordre entre diffrentes phases de dveloppement et de maintenance
La capacit de vrification
Cohrence Compltude
La continuit entre les diffrentes phases du cycle de vie

Quest ce quun modle ?
Un modle est une abstraction de la ralit
Un modle est une vue subjective mais pertinente de la ralit
Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur.
Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente.
5
Caractristiques fondamentales dun modle
Le caractre abstrait d'un modle doit notamment permettre : de faciliter la comprhension du systme tudi Un modle rduit la complexit du systme tudi. de simuler le systme tudi Un modle reprsente le systme tudi et reproduit ses comportements. Un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques. Un modle est une simplification de la ralit. Il permet de mieux comprendre le systme qu'on doit dvelopper. Les meilleurs modles sont proches de la ralit.
Buts dUML
Modlisation du systme complet (pas seulement le logiciel) Relier les objets conceptuels au systme "excutable" Contrler la complexit (chelle) Lisible par des humains et des machines Langage ouvert (mcanisme d'extensibilit) Langage de spcification : signification claire et non ambigu
Gnalogie de UML
La problmatique du dveloppement dun logiciel

La construction dun logiciel est complexe quand elle met en uvre de nombreuses ressources :
humaines ; matrielles ; technologiques.
Do la ncessit de suivre : un processus bien dfini => le cycle de vie dun logiciel : prvoir et planifier les travaux ; coordonner les activits de conception, de fabrication, de validation, ragir lvolution des objectifs. une mthode rigoureuse base sur des Modles: reprsentations smantiques simplifies mais justes dun systme visant lanalyser et le comprendre pour mieux le concevoir.
Les tapes du cycle de vie

client / fournisseur
Lexpression des besoins : laboration par le client et le fournisseur dun cahier des charges dcrivant : les fonctionnalits du systme tudi ; comment utiliser ce systme ; les spcifications du systme : lever les ambiguts, liminer les redondances du cahier des charges ; lanalyse : phase indpendante du toute considration technique et informatique visant dfinir le systme (saccorder sur le quoi ) ;
utilisateurs, experts / fournisseur
la conception : prise en compte de lenvironnement technique pour dterminer la manire de rsoudre le problme pos (saccorder sur le Experts comment ) ; informatiques limplmentation : traduction de la conception dans un langage de programmation, en une base de donnes, ...
Experts les tests : vrification que limplmentation est correcte ; informatiques utilisateurs, experts / fournisseur
la validation : vrification que le systme correspond aux besoins ;

la maintenance et lvolution pendant la phase dexploitation.
10
Le cycle de vie objet

Un cycle de vie suivant un modle objet se caractrise par : une bonne traabilit : les mme concepts servent, depuis lanalyse jusqu limplmentation (par exemple les classes implmentes sont dcouvertes pendant la phase danalyse) ; un caractre itratif :
un caractre incrmental : une srie de prototypes (sous-ensemble logiciel intgrable, rutilisable et volutif) voluent jusqu la version finale.
La place dUML dans le cycle de vie
12
Comment modliser avec UML ?
UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus d'laboration des modles ! Cependant, dans le cadre de la modlisation d'une application informatique, les auteurs d'UML prconisent d'utiliser une dmarche : itrative et incrmentale, guide par les besoins des utilisateurs du systme, centre sur l'architecture logicielle. D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits devrait favoriser la russite d'un projet.
Comment choisir une dmarche ?
Une dmarche itrative et incrmentale ? Une dmarche pilote par les besoins des utilisateurs ? Une dmarche centre sur l'architecture ?
14
Une dmarche itrative et incrmentale ?
L'ide est simple : pour modliser (comprendre et reprsenter) un systme complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par tapes. Cette dmarche devrait aussi s'appliquer au cycle de dveloppement dans son ensemble, en favorisant le prototypage. Le but est de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes.
Une dmarche pilote par les besoins des utilisateurs ?

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles : Le primtre du systme modliser est dfini par les besoins des utilisateurs (les utilisateurs dfinissent ce que doit tre le systme). Le but du systme modliser est de rpondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du systme).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de dveloppement (itratif et incrmental) : A chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. A chaque itration de la phase de conception et de ralisation, on veille la prise en compte des besoins des utilisateurs. A chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits.
Une dmarche pilote par les besoins des utilisateurs ?

L'expression des besoins est un travail difficile, peut-tre le plus difficile en pratique. C'est la qualit de ce travail qui dtermine quel sera au bout du compte le cot du systme dvelopp. Il faut tout d'abord se comprendre, c'est--dire tre certain que les utilisateurs et les informaticiens ont la mme vision des concepts du domaine informatiser (qu'est-ce qu'une image de tlvision numrique ? qu'estce qu'une facture ? qu'est-ce qu'un missile, qu'est-ce qu'un client? ...) et de la manire dont ils sont lis les uns aux autres. Ensuite, il faut s'accorder sur l'organisation gnrale du systme : quelles en sont les grandes parties, quels en sont les utilisateurs, quels rles jouent-ils exactement, quels sont les grand flots d'informations entre utilisateurs et parties du systme ? Il faut enfin spcifier les diffrentes manires d'utiliser le systme, du point de vue de l'utilisateur, et la manire dont le systme est peru par son environnement (interfaces).
Une dmarche centre sur l'architecture ?
Une architecture adapte est la cl du succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...).
18
vue ("4+1")
Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspir UML :
19
La vue logique
Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modlise les lments et mcanismes principaux du systme. Elle identifie les lments du domaine, ainsi que les relations et interactions entre ces lments : les lments du domaine sont lis au(x) mtier(s) de l'entreprise, ils sont indispensables la mission du systme, ils gagnent tre rutiliss (ils reprsentent un savoirfaire). Cette vue organise aussi (selon des critres purement logiques), les lments du domaine en "catgories" : pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique, isoler ce qui est propre une version donne, etc..
20
La vue des composants

Cette vue de bas niveau (aussi appele "vue de ralisation"), montre : L'allocation des lments de modlisation dans des modules (fichiers sources, bibliothques dynamiques, bases de donnes, excutables, etc...). En d'autres termes, cette vue identifie les modules qui ralisent (physiquement) les classes de la vue logique. L'organisation des composants, c'est--dire la distribution du code en gestion de configuration, les dpendances entre les composants... Les contraintes de dveloppement (bibliothques externes...). La vue des composants montre aussi l'organisation des modules en "sous-systmes", les interfaces des soussystmes et leurs dpendances (avec d'autres soussystmes ou modules).
21
La vue des processus
Cette vue est trs importante dans les environnements multitches ; elle montre : La dcomposition du systme en terme de processus (tches). Les interactions entre les processus (leur communication). La synchronisation et la communication des activits parallles (threads).
22
La vue de dploiement
Cette vue trs importante dans les environnements distribus, dcrit les ressources matrielles et la rpartition du logiciel dans ces ressources : La disposition et nature physique des matriels, ainsi que leurs performances. L'implantation des modules principaux sur les noeuds du rseau. Les exigences en terme de performances (temps de rponse, tolrance aux fautes et pannes...).
23
La vue des besoins des utilisateurs

Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres.
Dessiner le plan (l'architecture) d'un systme informatique n'est pas suffisant, il faut le justifier ! Cette vue dfinit les besoins des clients du systme et centre la dfinition de l'architecture du systme sur la satisfaction (la ralisation) de ces besoins. A l'aide de scnarios et de cas d'utilisation, cette vue conduit la dfinition d'un modle d'architecture pertinent et cohrent. Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force se concentrer sur les problmes importants.
24
Les diagrammes UML
25
Comment "rdiger" un modle avec UML ?

UML permet de dfinir et de visualiser un modle, l'aide de diagrammes. Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est une perspective du modle, pas "le modle". Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis). Un type de diagramme UML vhicule une smantique prcise (un type de diagramme offre toujours la mme vue d'un systme). Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un systme. Par extension et abus de langage, un diagramme UML est aussi un modle (un diagramme modlise un aspect du modle global).
26
Quelques caractristiques des diagrammes UML

Les diagrammes UML supportent l'abstraction. Leur niveau de dtail caractrise le niveau d'abstraction du modle. La structure des diagrammes UML et la notation graphique des lments de modlisation est normalise (document "UML notation guide"). Rappel : la smantique des lments de modlisation et de leur utilisation est dfinie par le mtamodle UML (document "UML semantics"). Le recours des outils appropris est un gage de productivit pour la rdaction des diagrammes UML, car : ils facilitent la navigation entre les diffrentes vues, ils permettent de centraliser, organiser, partager, synchroniser et versionner les diagrammes (indispensable avec un processus itratif), facilitent l'abstraction, par des filtres visuels, simplifient la production de documents et autorisent (dans certaines limites) la gnration de code.
Les diffrents types de diagrammes UML
Vues statiques du systme :

diagrammes diagrammes diagrammes diagrammes diagrammes diagrammes diagrammes diagrammes diagrammes de cas d'utilisation d'objets de classes de composants de dploiement de collaboration de squence d'tats-transitions d'activits
28
Vues dynamiques du systme :
Lenchanement des modles
29
Vues et diagramme UML

VUE Diagramme Cas d'utilisation Objets Collaboration Squence Des cas dutilisation Acteurs Cas d'utilisation Acteurs, Objets Liens Acteurs, Objets Liens, Message Acteurs, Objets Message Acteurs, Classes Objets, Liens Acteurs, Classes Objets, Liens Acteurs, Objets Messages Acteurs, Classes Paquetages Relations Etats Transitions Activits Transitions tats Transitions Activits Transitions composants tats Transitions Activits Transitions composants composants Noeuds, Liens Classes, Objets Liens Objets Messages logique Des composants Des processus De dploiement
Classes
tats-transition Activits Composants dploiement
30
LES CAS D'UTILISATION
31
32
La conceptualisation :
Le but de la conceptualisation est de comprendre et structurer les besoins du client. Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Une fois identifis et structurs, ces besoins :
Le modle conceptuel doit permettre une meilleure comprhension du systme. Le modle conceptuel doit servir d'interface entre tous les acteurs du projet. Les besoins des clients sont des lments de traabilit dans un processus intgrant UML.
dfinissent le contour du systme modliser (ils prcisent le but atteindre), permettent d'identifier les fonctionnalits principales (critiques) du systme.
33
Cas d'utilisation (use cases)
Il s'agit de la solution UML pour reprsenter le modle conceptuel. Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un systme. Ils centrent l'expression des exigences du systme sur ses utilisateurs : ils partent du principe que les objectifs du systme sont tous motivs.
34
Cas d'utilisation (use cases)
Ils se limitent aux proccupations "relles" des utilisateurs ; ils ne prsentent pas de solutions d'implmentation et ne forment pas un inventaire fonctionnel du systme. Ils identifient les utilisateurs du systme (acteurs) et leur interaction avec le systme. Ils permettent de classer les acteurs et structurer les objectifs du systme. Ils servent de base la traabilit des exigences d'un systme dans un processus de dveloppement intgrant UML.
Dictionnaire du domaine
Cest un outil de dialogue Informel, volutif et simple raliser, il permet dtablir et de figer la terminologie du domaine dapplication. Il Constitue le point d'entre et le rfrentiel initial de l'application ou du systme Le dictionnaire est un outil mthodologique important. Il permet de runir utilisateurs et informaticiens autour d'un objectif commun. La communication et donc la qualit de l'expression des besoins s'en trouvent amliores.
36
Dictionnaire du domaine
La terminologie issue du cahier des charges doit tre reprise et prcise, afin d'en extraire le dictionnaire. Les concepts de ce dictionnaire (noms communs) sont candidats tre des classes, relations ou attributs, alors que les actions (verbes) sont candidats tre des oprations. Le cahier des charges peut comporter des manques et des incohrences. Un premier objectif du dictionnaire est de clarifier ces aspects. Le dictionnaire est un document de rfrence, qui fait foi au cours du projet. Les dfinitions prcises des termes du dictionnaire doivent permettre de rgler les cas des synonymes (plusieurs termes ont la mme dfinition) et des polysmies (un mme terme plusieurs smantiques).
37
Exemple de dictionnaire dun simulateur de vol

Notion Pilotage Dfinition Action de piloter un avion en enchanant des manoeuvres lmentaires
Organe d'interaction entre le pilote et l'avion ou entre l'avion et le pilote Instrument qui permet d'agir sur la quantit de carburant injecte dans le moteur
Traduit en ... Package
Nom informatique Pilotage
Instrument
Classe abstraite Classe
Instrument
Manette des gaz
Manette_gaz
Action
Dfinition Action qui permet dinjecter le maximum de carburant pour atteindre la vitesse maximale
Traduit en ...
Nom informatique
Mettre les gaz fond
Opration
Mettre_a_fond
38
lments de base des cas d'utilisation
Acteur : entit externe qui agit sur le systme (oprateur, autre systme...).
L'acteur peut consulter ou modifier l'tat du systme. En rponse l'action d'un acteur, le systme fournit un service qui correspond son besoin. Les acteurs peuvent tre classs (hirarchiss).
Use case : ensemble d'actions ralises par le systme, en rponse une action d'un acteur.
Les use cases peuvent tre structurs. Les use cases peuvent tre organiss en paquetages (packages). L'ensemble des use cases dcrit les objectifs (le but) du systme.
Intrt des cas d'utilisation
Un cas d'utilisation "use-case" est une manire particulire d'utiliser le systme. Les cas d'utilisation permettent d'exprimer rapidement et simplement les besoins fondamentaux d'un point de vue compltement externe au systme. On dfinit une relation entre lacteur et chacun de ses use-cases. Lacteur communique avec le use-case, il participe au cas dutilisation. Un use-case peut tre reli plusieurs acteurs.
Notation des cas d'utilisation
41
Exemple : Cas d'utilisation standard
42
Exemple : Relation d'utilisation
43
Relations sur les use-cases
Relation dassociation
Un lien entre le use case et lacteur , cest une relation de communication
Utilisation dautres use-cases pour en prciser la dfinition Relation dextension

Extention : extends : utilisation optionnelle (Attention au sens de la flche)
Relation dutilisation
Inclusion ( includes ) : utilisation systmatique
Relation de gnralisation
Hritage Generalization
Exemple : Vente par correspondance
45
Relation dutilisation : Distributeur de billets
46
Relation dextension: Distributeur de billets
47
Le recensement des acteurs

Comment ? Par un dialogue avec le client et les utilisateurs ; en reprant les frontires du systme. Qui sont-ils ? Des utilisateurs humains ; des priphriques manipuls par le systme (imprimantes, robots, ) ; des logiciels dj disponibles intgrer dans le projet ; attention ne pas oublier les acteurs qui administrent le systme ; un mme utilisateur peut avoir plusieurs rles et tre plusieurs acteurs :
48
Recensement des cas dutilisation par les vnements

Pour reprer les cas dutilisation, on peut lister les vnements du systme ; un vnement est un stimulus envoy un systme, il survient un moment et un endroit prcis, il peut tre dcrit et mmoris par le systme ; il y a 3 types dvnements : les vnements externes au systme qui sont souvent initis par un acteur ; les vnements temporels qui rsultent de latteinte dun moment dans le temps ; les vnements dtat qui se produisent quand quelque chose dans le systme ncessite un besoin de traitement. Lors des spcifications et de lanalyse on fait le postulat de la technologie parfaite et on ignore les vnements qui visent vrifier lintgrit du systme.
La documentation des vnements
En gnral, chaque vnement se dveloppe en un cas dutilisation, mais un vnement peut engendrer plusieurs cas dutilisation.
50
Caractristiques de la modlisation par use cases
La modlisation par use cases est une technique imprcise, assez difficile mettre en oeuvre. Nanmoins, elle permet de vrifier la conformit du produit avec les spcifications. La modlisation par use cases adopte un formalisme vraiment simpliste, ce qui facilite la comprhension par tout le monde, surtout aux non initis aux pratiques objet. La modlisation par use cases n'est pas une technique OBJET en soi
51
Caractristiques de la modlisation par use cases
L'excutant profite du flou artistique sur la modlisation par use cases pour laisser le champ libre sa conception future du produit L'excutant a besoin des use cases pour faire l'valuation de l'ampleur du projet et tablir le cot et les autres paramtres d'affaires. Une bonne modlisation par use cases doit rpondre la question: que fait le systme un haut niveau et jamais comment (WHAT TO DO et NOT HOW TO DO) ?
Recettes pour tablir les cas dutilisation
tape 1: Identifier les "rles" du systme: Ce sont les acteurs avec le strotype "acteur". Lorsquun systme est subdivis en sous-systmes plus lmentaires, un soussystme peut devenir un acteur pour un autre sous systme. Si l'acteur n'est pas humain, utiliser une forme rectangulaire. tape 2: Diffrencier les acteurs si possible si la nature du problme lexige. Chercher les proprits communes de ces acteurs. Factorisez ventuellement un rle commun et driver (si possible) les autres acteurs partir de cet acteur commun (usage de l'hritage)
tape 3: Pour chaque acteur, chercher ce que cet acteur peut faire avec le systme et identifier les use cases de base. tapes 4: tudier chaque use case de base. S'il a l'air complexe et ne permet pas d'estimer l'ampleur du projet, dcomposer le et identifier les use cases sous-jacents. tape 5: Dcrire en dtail chaque use case, aussi bien des use case de base que les use cases sous-jacents. C'est une tape importante car elle permet de clarifier ce qu'on veut confier comme tches un systme.
tape 6 : Supprimer les uses cases qui n'ont pas leur raison d'tre. Gnralement, un use case est "ralis" possiblement avec un mini diagramme de squence ou de collaboration, aussi petit soit-il, si l'on poursuivait l'tude. Si ce n'est pas le cas, peut tre le use case n'a pas sa raison d'tre. tape 7: Trouver les traitements communs dans les descriptions et cherchez les possibilits de factorisation. Dgagez si possible les use cases factoriss tape 8: tablir les liens strotyps pour prciser la smantique du systme. Ce sera la partie la plus technique de la spcification.
tape 9: Recommencer les tapes 4 8 pour tous les use cases de base. tape 10: Identifier les acteurs secondaires (par exemple, les acteurs de maintenance et recommencez les tapes de 2 9 pour les acteurs secondaires)
56
Exercice : Le GAB - cas dutilisation
Modlisation dun GAB (Guichet Automatique de Banque). Les principales fonctions sont les suivantes :
Identifier les acteurs et les cas. Structurer les cas.

distribution dargent tout porteur dune carte de la banque (autorisation dun certain montant par le Systme dInformation de la banque) ou dune carte VISA (autorisation distance par le Systme dAutorisation VISA), consultation du solde, dpt en numraire et de chques pour les possesseurs dune carte de la banque. Toutes les transactions sont scurises (code personnel vrifi avec le code enregistr sur la puce de la carte ; la carte est avale aprs trois checs).Il faut parfois recharger le GAB et retirer des choses ...
Exercice : Le GAB - cas dutilisation
58
Bibliothque
Un grant de bibliothque dsire automatiser la gestion des prts. Il commande un logiciel permettant aux utilisateurs de connatre les livres prsents, d'en rserver jusqu' deux. L'adhrent peut connatre la liste des livres qu'il a emprunts ou rservs. L'adhrent possde un mot de passe qui lui est donn son inscription. L'emprunt est toujours ralis par les employs qui travaillent la bibliothque. Aprs avoir identifi l'emprunteur, ils savent si le prt est possible (nombre max de prts = 5), et s'il a la priorit (il est celui qui a rserv le livre). Ce sont les employs qui mettent en bibliothque les livres rendus et les nouveaux livres. Il leur est possible de connatre l'ensemble des prts raliss dans la bibliothque.
Les diagrammes de squences
60
Les diagrammes de squence

Les diagrammes de squence permettent de reprsenter des interactions entre objets ; Les objets communiquent entre-eux par envoi de messages (appel de mthodes); Un objet peut recevoir un vnement.
61
Intrt et limites des diagrammes de squence

Les diagrammes de squence sont utiliss : pour illustrer les use cases ; dans le modle dynamique.
Les limites des diagramme de squence : comment faire apparatre des oprations non squentielles? Si la somme nest pas suffisante?
62
La syntaxe des messages
La syntaxe pour un message est la suivante :

[ condition vraie ou faux ] valeur retourne := nom du message( liste des paramtres)
63
Les types de messages
synchrone : lmetteur reste bloqu le temps que le rcepteur traite le message envoy ; asynchrone : lmetteur nest pas bloqu lorsque le rcepteur traite le message envoy.
64
Les boucles et les conditions
65
Les diagrammes dactivits
66
Intrt des diagrammes dactivits
Les diagrammes dactivits reprsentent ltat de lexcution dun mcanisme, sous la forme dun droulement dtapes regroupes squentiellement dans des branches parallles de flot de contrle ; Les diagrammes dactivit peuvent tre utiliss comme alternatives aux diagrammes de squences pour dcrire un cas dutilisation (quand les utilisateurs dun systme ont du mal manipuler des diagrammes de squences).
67
Exemple dun diagramme dactivits
68
69
70
tude de cas : Cahier des charges

Pour faciliter sa gestion, un entrept de stockage envisage de sinformatiser. Le logiciel produire doit allouer automatique un emplacement pour le chargement des camions qui convoient le stock entreposer. Le fonctionnent du systme informatique doit tre le suivant: dchargement dun camion : lors de larrive dun camion, un employ doit saisir dans le systme les caractristiques de chaque article ; le systme produit alors une liste o figure un emplacement pour chaque article ; chargement dun camion : les caractristiques des articles charger dans un camion sont saisies par un employ afin dindiquer au systme de librer des emplacements. Le chargement et le dchargement sont raliss manuellement. Les employs de lentrept sont sous la responsabilit dun chef dont le rle est de superviser la bonne application des consignes.
Use cases : Recensement des acteurs
Ltude du cahier des charges ainsi quun dialogue avec les employs et leur chef a abouti retenir 3 acteurs : Un employ dont le rle est de saisir les caractristiques des articles lors dun chargement / dchargement. Un superviseur dont le rle est de pouvoir contrler ltat du stock. Un administrateur du systme dont le rle est de grer des comptes utilisateurs pour les employs et le superviseur.
Diagramme des cas dutilisation
73
Cas dutilisation : dchargement dun camion
Lors de larrive dun camion : lemploy saisie les caractristiques des articles du chargement :
les articles sont caractriss par :
une rfrence unique pour chaque type darticle ; le nombre darticles dun type donn ;
Le systme imprime une liste dallocation des articles dans lentrept.
Remarque : ce cas dutilisation ninclue pas ltape de vrification du chargement qui est faite manuellement.
Cas dutilisation : chargement dun camion
Lors du chargement dun camion : lemploy saisie les caractristiques des articles charger :
les articles sont caractriss par :
une rfrence unique pour tout le stock.
Le systme imprime une description du chargement contenant :

une rfrence unique pour chaque type darticle ; le nombre darticles dun type donn.
75
Cas dutilisation : ajout dun employ
Lors de lajout dun nouvel employ utilisant le systme informatique : ladministrateur saisie des informations sur lemploy (son immatriculation) ; Ladministrateur ajoute cette personne aux groupes des employs.
76
Diagrammes de squence pour le dchargement dun camion
Plusieurs scnario doivent tre envisags lors du dchargement :

dchargement sans problme ; dchargement avec manque de place ; Ces scnarios peuvent tre dcrits par des diagrammes de squence :
77
Diagrammes de squence pour le dchargement dun camion
78
GAB: diagramme dactivits diagramme de squence
A)Modliser le retrait dargent avec une carte VISA avec un diagramme dactivits. La carte peut tre invalide. Si elle est valide, le client doit taper son code. La carte est avale aprs trois essais infructueux. Le SA VISA autorise un certain montant ou refuse tout retrait. Une carte non rcupre est avale. Les billets non rcuprs par le client sont repris. Un ticket est toujours imprim pendant que les billets sont proposs. B)Modliser le scnario nominal (succs) avec un diagramme de squence.
80
81

Uml

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml

Uploaded by

Copyright:

Available Formats

Mthodes d'analyse et de conception orientes objet UML (Unified Modeling Language)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Pourquoi modliser ? (1)

pour construire une maison familiale :

pour construire un immeuble :

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Pourquoi modliser ? (2)

Pourquoi modliser ? (3)

La continuit entre les diffrentes phases du cycle de vie

Quest ce quun modle ?

Un modle est une abstraction de la ralit

Un modle est une vue subjective mais pertinente de la ralit

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Caractristiques fondamentales dun modle

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

La problmatique du dveloppement dun logiciel

Les tapes du cycle de vie

utilisateurs, experts / fournisseur

la validation : vrification que le systme correspond aux besoins ;

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Le cycle de vie objet

La place dUML dans le cycle de vie

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Comment modliser avec UML ?

Comment choisir une dmarche ?

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Une dmarche itrative et incrmentale ?

Une dmarche pilote par les besoins des utilisateurs ?

Une dmarche pilote par les besoins des utilisateurs ?

Une dmarche centre sur l'architecture ?

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

La vue des composants

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

La vue des processus

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

La vue des besoins des utilisateurs

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Les diagrammes UML

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Comment "rdiger" un modle avec UML ?

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Quelques caractristiques des diagrammes UML

Les diffrents types de diagrammes UML

Vues statiques du systme :

Vues dynamiques du systme :

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Lenchanement des modles

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Vues et diagramme UML

tats-transition Activits Composants dploiement

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

LES CAS D'UTILISATION

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Cas d'utilisation (use cases)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Cas d'utilisation (use cases)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Y. BERAICH - Mthodes d'analyse et de conception orientes objet (UML)

Exemple de dictionnaire dun simulateur de vol

Traduit en ... Package