UML Chapitre 1

UMl (Unified Modeling language)

INTRODUCfION

Il LA MODELISATION des USE CASES

III LA MODELISATION des ClASSES

IV LA MODELISATION des INTERACfIONS

V LA MODELISATION des ACTIVITES

VI LA MODELISATION des Machines dEtat

VII La MODELISATION STATIQUE

(Compleacutement Package Objet Composant Deacuteploiement Structures Composites)

Bibliographie

Grady Booch James Rumbaugh et Ivar Jacobson

1) UML 20 le Guide de lUtilisateur

2 UML 20 le Manuel de Reacutefeacuterence

3) UML le Processus Unifieacute

MLAI UML La notation unifieacutee de modeacutelisation objet MASSON

P A MULLER Modeacutelisation Objet avec UML

EYROLLES

Urlographie wwwdeveloppezcom

Introduction

UML est un langage qui sappuie sur la technologie orienteacutee objet et sesconcepts

Meacutethodologie Meacutethode et Formalisme

bull Le terme laquo meacutethodologie raquodans son sens premier deacutesigne leacutetude

des meacutethodes scientifiques et techniques Il est employeacute pour deacutesigner lutilisation dune deacutemarche

rationnelle et structureacutee lors de leacutelaboration dun logiciel

bull Un formalisme est un ensemble de notations et de regravegles deacutecrivant des concepts permettant de

speacutecifier construire visualiser et documenter un systegraveme informatique

bull Une meacutethode informatique est une deacutemarche conceptuelle et

organisationnelle baseacutee sur un formalisme speacutecifique et permettant la mise en oeuvre dune solution

informatique

UML nest pas une meacutethode

UML est un langage objet graphique autrement dit un formalisme orienteacute objet ce nest pas une

meacutethode mais une synthegravese de tous les concepts et formalismes meacutethodologiques les plus utiliseacutes

dans la Technologie Objet

o UML est issu de la fusion du formalisme de trois meacutethodes orienteacutees objet qui eacutetaient les

plus utiliseacutees aux USA

o OMT (Object Modeling Technique)de James Rumbaugh

o BOOCH de Grady Booch

1

o OOSE (Object Oriented Sofware Engineering) de Ivar Jacobson qui fut inteacutegreacutee agrave UMl en

1997

o UMl sinspire eacutegalement de toutes les autres meacutethodes leaders du marcheacute

[J le formalisme UMl peut donc ecirctre utiliseacute dans diffeacuterents processus de deacuteveloppement et en

particulier dans celui proposeacute par les concepteurs du langage (RUP Rational Unified Process

ou le Processus Unifieacute) (UP l Unified Process) ( 2TUP Two Track Unified Process ) (XP

Extreme Programming )0

o la migration de MERISE 00 agrave UMl peut se faire assez aiseacutement

[J UML et la standardisation

o Initialement UMl a eacuteteacute soumise en janvier 1997 agrave lOMG (Object Management Group) dans

le cadre de la standardisation des meacutethodes danalyse et de conception orienteacutees objet la

version 10 dUML a tregraves vite obtenu le ralliement de nombreux acteurs du marcheacute

(Microsoft Oracle Hewlett-Packard )et de nombreux eacutediteurs dAGL (ateliers de geacutenie

logiciel) UML 20 est la derniegravere version voteacutee en 2003

o la technologie orienteacutee objet et le formalisme UMl en particulier veacutehiculent des concepts

tregraves geacuteneacuteraux dont lapplication nest pas limiteacutee au domaine informatique

UML et La Modeacutelisation

bull Un Systegraveme est un ensemble deacuteleacutements organiseacutes et de relations entre ces

eacuteleacutements en vue datteindre un objectif Il est deacutecrit par un ensemble de Modegraveles en

geacuteneacuteral sous diffeacuterents points de vues ou angles

bull Un Modegravele cest une abstraction dun Systegraveme complegravete et fermeacutee du point de

vue seacutemantique c ad repreacutesentant une simplification coheacuterente de la reacutealiteacute et

creacuteeacutee dans le but de faciliter la compreacutehension du systegraveme (UMl20 propose 13 en

tout)

bull Un Diagramme est une repreacutesentation graphique dun ensemble deacuteleacutements sous

forme dun graphe connecteacute de sommets (eacuteleacutements structurels) et darcs (relations)

bull Un diagramme nest pas un modegravele ce nest quune repreacutesentation de quelques

eacuteleacutements du modegravele

o Plusieurs diagrammes savegraverent souvent neacutecessaires pour illustrer un modegravele complet

o Pour la modeacutelisation UML distingue 2 cateacutegories de diagrammes

Les Diagrammes Structurels permettent de visualiser construire et documenter les aspects

statiques dun systegraveme

Dans cette cateacutegorie on trouve 6 diagrammes

- de Classes

- dObjets

- de Composants

- de Deacuteploiement

2

- de Structure Composite

- de Package

Les Diagrammes Comportementaux

permettent de visualiser construire et documenter

les aspects dynamiques dun systegraveme Dans cette

cateacutegorie on trouve 7 diagrammes

bull des USE CASES

bull des Interactions

C Seacutequence

C de Communication (av collaboration)

C vue densemble des Interactions

C deTiming

bull dlActiviteacutes

bull de Machine dEtats (av Etats-Transitions)

o En principe ni UML ni le Processus Unifieacute (la Meacutethode) nobligent agrave repreacutesenter les 13

diagrammes

Ils laissent agrave lanalyste et au concepteur la latitude deacutecisionnelle en fonction de leurs besoins

Cependant les 2 diagrammes qui savegraverent toujours neacutecessaires sont surtout

bull le diagramme des USE CASES et

bull le diagramme de Classes

Il) La Modeacutelisation des USE CASES

(CAS DUTILISATION ou CAS DUSAGE)

111) Que sont les USE CASES

Les USE CASES constituent le concept principal de la meacutethode OOSE dIvar Jacobson

Le concept des USE CASE a eacuteteacute repris dans le but deffectuer une bonne deacutelimitation du systegraveme mais

eacutegalement pour ameacuteliorer la compreacutehension de son fonctionnement et reacutealiser sa speacutecification

Les USE CASES repreacutesentent un meacutecanisme qui permet de deacutetecter didentifier de comprendre et

de consigner les besoins

Ils permettent dorienter tout le processus de deacuteveloppement car les activiteacutes dAnalyse de

Conception et de Test sont effectueacutees agrave partir des USE CASES

Les USE CASES repreacutesentent le premier modegravele du systegraveme agrave concevoir

Les USE CASES sont une repreacutesentation orienteacutee laquo fonctionnaliteacuteraquo du systegraveme qui permettent de

modeacuteliser les attentes des utilisateurs

3

Une bonne compreacutehension du systegraveme est primordiale avant dentreprendre lanalyse et la

conception

USE

CONCEPTION

Il2 Les concepts

Deux concepts fondamentaux pour repreacutesenter les USE CASES

- les acteurs qui utilisent le systegraveme

- les USE CASES qui repreacutesentent lutilisation

du systegraveme par les acteurs

A) Les acteurs (utilisateurs du systegraveme)

Pour permettre une bonne deacutelimitation du systegraveme il est bon de bien seacuteparer les eacuteleacutements

constitutifs du systegraveme logiciel des eacuteleacutements exteacuterieurs les acteurs repreacutesentent cette frontiegravere

Ce sont des eacuteleacutements exteacuterieur au systegraveme et qui interagissent avec lui

Il faut dabord Identifier les acteurs qui peuvent ecirctre des

Humains ce sont des utilisateurs du logiciel agrave

travers son interface graphique par exemple

Logiciels ce sont des logiciels deacutejagrave disponibles qui

communiquent avec le systegraveme gracircce agrave une

interface logicielle (une API par exemple)

Mateacuteriels robots et automates qui exploitent les

donneacutees du systegraveme ou qui sont piloteacutes par le

systegraveme (GAB)

Systegravemes exteacuterieurs (le Systegraveme de la banque de la

socieacuteteacute)

Al) Typologie des acteurs

Il existe trois types dacteurs

Les acteurs principaux ou primaires Ceux qui utilisent le systegraveme pour atteindre leurs buts (ils sont

la raison de lexistence du systegraveme)

Les acteurs secondaires Ceux qui administrent le systegraveme et assurent sa maintenance Ce sont eux

qui paramegravetrent le systegraveme et qui lui fournissent toutes les informations ou services neacutecessaires agrave son bon fonctionnement pour les acteurs principaux

Exla personne chargeacutee de la MAJ des cours des devises

Les acteurs externes Ceux qui ont un inteacuterecirct dans le comportement du cas dutilisation

Ex les services des impocircts du commerce

4

Remarquef

bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond

souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus

jouent souvent le mecircme rocircle (guichetier)

bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs

Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)

A2) Pourquoi des acteurs

Identifier les acteurs dun systegraveme permet de

deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier

- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception

interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes

attendues par les diffeacuterents acteurs

Remarque

UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec

utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel

Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie

Ex

Un eacutetudiant Une eacutetudiante

A3) Les relations entre ACTEURS

Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation

B) Les USE CASES Eleacutements de linterface dutilisation

Bl) Deacutefinitions

Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un

des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou

reacutepondre au(x) besoin(s) dun acteur

les USE CASES permettent de bien comprendre le systegraveme

Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme

logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une

classe ou une interface) mais ne preacutecisent pas comment il le fait

5

Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute

performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement


Bi) Deacutefinitions

o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee

par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour

produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur

o Les USE CASES permettent de bien comprendre le systegraveme

Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du

systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un

sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait

o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute

performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement

o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs

Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou

utilisateurs)

Le symbole graphique dun Use Case se fait par

~om du Use Case

B 2) Description dun USE CASE

o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et

doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation

o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons

bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications

bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun

pseudo-code

bull Il est recommandeacute deffectuer au moins deux descriptions

bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur

uniquement

bull

bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du

systegraveme (classes eacutecrans controcircles base de donneacutees )

bull Pour cette description interne on peut utiliser une maquette (une succession

deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour

un Use Case donneacute

bull Ex Retrait dArgent dans une agence bancaire

6

Responsable argent

Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un

client sur un compte preacutecis

Une description teKtuelle peut ecirctre

+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des

besoins

+ Le guichetier saisit le numeacutero de compte du client

+ Lapplication valide le compte aupregraves du systegraveme central

+ Lapplication demande le type dopeacuteration au guichetier

+ Le guichetier choisit un retrait despegraveces du montant en Dirhams

+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est

suffisamment approvisionneacute

+ Le systegraveme central effectue le deacutebit du compte

+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute

UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu

correspond au format ci dessus

o Acteur Principal celui qui fait appel au systegraveme

o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait

o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario

o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario

o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees

o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception

o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES

o Liste de variantes et de donneacutees technologiques

ex lecteur de cartes pour diffeacuterents codes agrave barres

o Freacutequence doccurrences

o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes

Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions

(voir exemple 1 ci dessous)

7

Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme

Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme

(voir exemple 1 ci-dessous)

83) les relations entre USE CASES au sein dun systegraveme

On distingue trois types de relations entre USE CASES

a) la relation de Geacuteneacuteralisation 1Speacutecialisation

Cest le principe dheacuteritage ex

b) la relation laquo Include raquo

o Permet la factorisation dun ensemble de tacircches

o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur

Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On

peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute

sera utiliseacutee dans diffeacuterents USE CASES

Cette relation permet donc de

+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE

CASES

+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES

relieacutes

Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit

+ le guichetier saisit le code de la banque du compte

+ il saisit te numeacutero du compte

+ il saisit la cleacute de compte

+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne

+ le systegraveme interroge le compte sur le systegraveme central

+ le systegraveme affiche le compte ainsi que son deacutetenteur

c) la relation laquo extend raquo

Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche

est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul

8

La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du

USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les

acteurs et les autres USE CASES

Ce type dheacuteritage a aussi une valeur seacutemantique

Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere

Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est

un cas particulier du premier

Remarque Il faut distinguer entre une relation laquo extend raquo

et une relation de Geacuteneacuteralisation ISpeacutecialisation

Il3) le Diagramme des USE CASES

Cette repreacutesentation graphique permet de voir de faccedilon simple

+ les diffeacuterents acteurs

+ comment est deacutelimiteacute le systegraveme

+ les fonctionnaliteacutes demandeacutees au systegraveme

+ les rocircles des diffeacuterents acteurs vis-agrave-vis du

systegraveme

Il faut donner un nom au diagramme

9

1

CAISSIER

Applkation BaliCaire

Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ

Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique

Sommaire didentification (obligatoire)

Titre retrait dargent avec un chegraveque ou un chegraveque guichet

Reacutesumeacute ce cas permet agrave un client de la banque de retirer de

largent de son compte avec un chegraveque une carte ou un

chegraveque guichet si son solde ou son deacutecouvert le lui permet

Acteurs guichetier de la banque le systegraveme central

Date de creacuteation 110904 Date de MAJ 190904

Version 23

Responsable Kaddour ben Jilali

Description des enchaIcircnements (obligatoire)

o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est


o Sceacutenario Principal

1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams

2) Le guichetier demande identification du client

10

3 Le systegraveme valide lidentification et affiche la signature

4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque

5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client

6) Le systegraveme donne son accord

7 Le guichetier deacutelivre le montant demandeacute

Le systegraveme met agrave jour le compte client et le solde caisse

bull Sceacutenarios alternatifs

SAl Le client na pas de chegraveque

Cet enchaicircnement deacutemarre au point 1)

la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute

1) Le client signe le chegraveque

2) le guichetier le reprend

Ce sceacutenario continue au point 2 du sceacutenario principal

SA2 Le solde et le deacutecouvert ne permettent pas le retrait

Cet enchaicircnement deacutemarre en 6)

6a) le systegraveme ne donne pas laccord pour le retrait

1) le chegraveque est remis au client

2) lopeacuteration est termineacutee

bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en

cas de succegraves du retrait autrement ils doivent rester inchangeacutes

bull Besoins dIHM lfocultatiO

+ un lecteur de chegraveques

+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de

la signature du client

+ Un compteur de billets

o Contraintes non fonctionnels lfocultatiO

+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes

+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne

aupregraves dun autre guichetier dans la mecircme agence

11

1 slj~ IbL~~ )~ l~ 3((1

+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la

demande du directeur de lagence

+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client

quelque soit sa position

Description du cas dutilisation laquo Retraits Dirhamsraquo

Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)

Description des enchaIcircnements obligatoire

D Sceacutenario Principal

Le guichetier 1Le systegraveme

1) prend le chegraveque client

et demande identification

2) lit le chegraveque et

veacuterifie identification et

affiche la signature

3) veacuterifie la signature

~~----------~---------------~ tXfflLe

~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt

et ~ J~ kA slj~iJV ~l S(~

Le S crf)- _ JeA b 1~~ ))J

Loc s~eacuteJi

D cc(9v-~~~eacute Jt iJr-6

12

o OOSE (Object Oriented Sofware Engineering) de Ivar Jacobson qui fut inteacutegreacutee agrave UMl en

1997

o UMl sinspire eacutegalement de toutes les autres meacutethodes leaders du marcheacute

[J le formalisme UMl peut donc ecirctre utiliseacute dans diffeacuterents processus de deacuteveloppement et en

particulier dans celui proposeacute par les concepteurs du langage (RUP Rational Unified Process

ou le Processus Unifieacute) (UP l Unified Process) ( 2TUP Two Track Unified Process ) (XP

Extreme Programming )0

o la migration de MERISE 00 agrave UMl peut se faire assez aiseacutement

[J UML et la standardisation

o Initialement UMl a eacuteteacute soumise en janvier 1997 agrave lOMG (Object Management Group) dans

le cadre de la standardisation des meacutethodes danalyse et de conception orienteacutees objet la

version 10 dUML a tregraves vite obtenu le ralliement de nombreux acteurs du marcheacute

(Microsoft Oracle Hewlett-Packard )et de nombreux eacutediteurs dAGL (ateliers de geacutenie

logiciel) UML 20 est la derniegravere version voteacutee en 2003

o la technologie orienteacutee objet et le formalisme UMl en particulier veacutehiculent des concepts

tregraves geacuteneacuteraux dont lapplication nest pas limiteacutee au domaine informatique

UML et La Modeacutelisation

bull Un Systegraveme est un ensemble deacuteleacutements organiseacutes et de relations entre ces

eacuteleacutements en vue datteindre un objectif Il est deacutecrit par un ensemble de Modegraveles en

geacuteneacuteral sous diffeacuterents points de vues ou angles

bull Un Modegravele cest une abstraction dun Systegraveme complegravete et fermeacutee du point de

vue seacutemantique c ad repreacutesentant une simplification coheacuterente de la reacutealiteacute et

creacuteeacutee dans le but de faciliter la compreacutehension du systegraveme (UMl20 propose 13 en

tout)

bull Un Diagramme est une repreacutesentation graphique dun ensemble deacuteleacutements sous

forme dun graphe connecteacute de sommets (eacuteleacutements structurels) et darcs (relations)

bull Un diagramme nest pas un modegravele ce nest quune repreacutesentation de quelques

eacuteleacutements du modegravele

o Plusieurs diagrammes savegraverent souvent neacutecessaires pour illustrer un modegravele complet

o Pour la modeacutelisation UML distingue 2 cateacutegories de diagrammes

Les Diagrammes Structurels permettent de visualiser construire et documenter les aspects

statiques dun systegraveme

Dans cette cateacutegorie on trouve 6 diagrammes

- de Classes

- dObjets

- de Composants

- de Deacuteploiement

2


- de Package





bull des USE CASES


C Seacutequence



C deTiming




diagrammes


















3


conception

USE

CONCEPTION

Il2 Les concepts

















systegraveme (GAB)


socieacuteteacute)










4

Remarquef












Remarque




Ex













5
















utilisateurs)


~om du Use Case







pseudo-code



uniquement

bull







6

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12


- de Package





bull des USE CASES


C Seacutequence



C deTiming




diagrammes


















3


conception

USE

CONCEPTION

Il2 Les concepts

















systegraveme (GAB)


socieacuteteacute)










4

Remarquef












Remarque




Ex













5
















utilisateurs)


~om du Use Case







pseudo-code



uniquement

bull







6

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12


conception

USE

CONCEPTION

Il2 Les concepts

















systegraveme (GAB)


socieacuteteacute)










4

Remarquef












Remarque




Ex













5
















utilisateurs)


~om du Use Case







pseudo-code



uniquement

bull







6

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12

Remarquef












Remarque




Ex













5
















utilisateurs)


~om du Use Case







pseudo-code



uniquement

bull







6

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12
















utilisateurs)


~om du Use Case







pseudo-code



uniquement

bull







6

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12

Responsable argent





besoins
























7
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12
















CASES


relieacutes











8
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12
















systegraveme


9

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12

1

CAISSIER


Responsable Devise

DIRECTEUR Acte-ur

Syst Ce-nb-aJ









Version 23








10






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12






























11

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12

1 slj~ IbL~~ )~ l~ 3((1
















~~----------~---------------~ tXfflLe




Loc s~eacuteJi


12

UML Chapitre 1

Documents

Transcript of UML Chapitre 1