CompIments d'anaIyse et

conception des systmes

d'information (ACSI)

COURS, TD, Etude de cas


PubIic concern : DUT Informatique 2
me
anne




Jacques LONCHAMP Date : 2011/2012




UNIVERSITE NANCY 2
INSTITUT UNIVERSITAIRE DE TECHNOLOGIE
2ter bouIevard CharIemagne
CS 5227
54052 NANCY Cedex
-------------------------------
TI : 03.54.50.38.00
Fax : 03.54.50.38.01
http://iut-charIemagne.univ-nancy2.fr
2

3


TabIe des matires

PARTIE 1 : COURS

1. Prsentation d'UML p. 5
2. Les cas d'utiIisation p. 7
3. Les diagrammes de cIasses p. 11
4. Les diagrammes d'interactions p. 15
5. Les diagrammes d'tats et d'activits p. 17
6. Traduction schma de cIasses vers schma reIationneI p. 21
7. Le processus de dveIoppement objet p. 23


PARTIE 2 : TRAVAUX DIRIGES

1. TD cas d'utiIisation p. 27
2. TD diagrammes de cIasses p. 31
3. TD diagrammes de squences p. 35
4. TD diagrammes de modIisation de Ia dynamique p. 39
5. TD cIasses vers reIationneI p. 41

PARTIE 3 : ETUDE DE CAS p. 43

6

7

8














9



























10

11














12














13














14







































15














16














17














18














19










20

21














22













23














24














25














26
































27

TD Cas d'utiIisation

1. Gestion de Ia formation
Une entreprise souhaite modliser avec UML le processus de formation de ses employs afin
d'informatiser certaines tches.
Le processus de formation est initialis quand l'employ dpose une demande de formation. Cet
employ peut ventuellement consulter le catalogue des formations offertes par les organismes
slectionns par le responsable formation. Cette demande est examine par le responsable. Pour
prendre sa dcision (accord ou refus), le responsable examine le catalogue des formations
agres qu'il tient jour. l informe l'employ du contenu de la formation choisie et lui soumet la
liste des prochaines sessions prvues. Lorsque l'employ fait son choix il inscrit l'employ la
session retenue auprs de l'organisme de formation concern.
En cas d'empchement l'employ doit le signaler au plus vite au responsable formation, pour que
celui-ci demande l'annulation de l'inscription l'organisme concern.
A la fin de la formation l'employ transmet une apprciation sur le stage suivi.
Le responsable formation valide la formation au vu de la facture envoye par l'organisme de
formation.
TravaiI faire
dentifier les acteurs et les cas. Dessiner le diagramme des cas d'utilisation en structurant
ventuellement les cas. Brivement dcrire chaque cas.

2. Cyber-Kebab
L'entreprise MegaKebab regroupe dans une mme ville de nombreux restaurants appels "Points
Kebab". Elle est spcialise dans la livraison domicile de Kebabs et autres spcialits.
Actuellement, les commandes se font par tlphone directement auprs de chaque restaurant. Un
nombre limit de commandes peut tre trait et chaque client doit connatre la carte des plats
offerts par le Point Kebab contact (ils varient d'un restaurant l'autre). La direction de
MegaKebab souhaite informatiser le processus de commande/fabrication/livraison via un logiciel
baptis CyberKebab.
Grce ce logiciel, MegaKebab souhaite grer distance et de manire centralise toutes les
commandes, les Points Kebab et les employs appels "Collaborateurs". Cette centralisation doit
permettre de rendre accessible sur nternet tous les plats disponibles. Chaque plat est dcrit par
un nom, une photo et un prix (identique partout). Dans le cadre de la politique marketing, une
dure est galement associe chaque plat chaud : si le temps coul entre la fin de prparation
et la livraison est suprieur cette dure, le client peut se faire rembourser sa commande.
Cependant, pour ne pas inciter les clients utiliser cette possibilit, cette opration n'est pas
disponible sur nternet : le client doit remplir une demande crite sur papier libre et l'envoyer au
grant de MegaKebab. A tout moment il est possible de passer une commande par nternet. Le
client doit disposer d'une carte de crdit qui l'identifie de manire unique. Lors d'une premire
commande il lui est galement demand de saisir son nom et de situer son lieu de rsidence sur
une carte de la ville. Une mme commande peut comporter plusieurs plats. Pour chaque plat
slectionn le client doit indiquer la quantit dsire. Aprs avoir pass sa commande, le client
peut tout moment consulter l'tat de sa commande. Tant que la commande n'est pas partie du
PointKebab, il peut l'annuler.
Les Points Kebab sont ouverts 24h/24. Pour assurer un service 24h/24 dans toute la ville,
MegaKebab fait appel un grand nombre de collaborateurs, souvent tudiants, qui ont des
horaires trs flexibles. Lors de leur embauche, un tlphone portable leur est remis. l suffit
d'appuyer sur un bouton pour faire part de leur disponibilit auprs de MegaKebab. Un autre
bouton permet d'indiquer qu'ils ne le sont plus. A tout moment le grant peut consulter via nternet
l'tat du systme global. l peut affecter un collaborateur soit un Point Kebab soit la livraison.
Un collaborateur peut ainsi changer de lieu de travail ou de rle plusieurs fois dans une journe : le
rle du grant est d'optimiser l'attribution de chacun en fonction des commandes. Lorsqu'un client
passe une commande, il n'indique pas de PointKebab particulier; c'est le grant qui affecte la
commande un PointKebab et un livreur. Le grant cherche en gnral optimiser la distance
parcourue ainsi que les activits des PointKebabs et des collaborateurs.
28

Chaque livreur utilise son propre moyen de transport (bus, vlo, roller, voiture .). Par contre, un
appareil appel "Pilote" lui est remis lors de son affectation la livraison. Chaque pilote intgre un
GPS permettant de localiser le livreur de manire prcise via une liaison satellite. Un cran permet
au livreur de consulter les commandes qui lui ont t affectes. l peut tout moment consulter la
carte et se situer par rapport aux points Kebab et aux clients livrer. Le livreur utilise galement le
pilote pour indiquer quand il rcupre une commande auprs du Point Kebab et quand il livre la
commande au client.
Dans chaque Point Kebab un collaborateur joue le rle de "coordinateur". C'est le seul du
restaurant agir directement avec CyberKebab : les autres collaborateurs prparent les plats. Le
coordinateur consulte les commandes raliser et indique pour chaque commande quand sa
prparation dbute, quand elle se termine et quand elle est remise au livreur.
TravaiI faire
Complter le diagramme des cas d'utilisation du systme CyberKebab donn ci-dessous. Seuls
les acteurs humains sont pris en compte (ni le Pilote, ni le tlphone ne sont reprsents).

3. Gestion d'une bibIiothque
La bibliothque prte des livres et magazines des emprunteurs, qui sont enregistrs dans le
systme de mme que les livres et les magazines Les titres les plus demands peuvent exister en
plusieurs exemplaires. Les vieux exemplaires sont retirs quand ils sont dpasss ou abms.
unClient
CyberKebab
Passer une commande
Livrer une commande
29

Le bibliothcaire est l'employ qui interagit avec les emprunteurs et dont le travail est assist
par le systme. Les documents ne sont pas en accs libre. Les clients peuvent consulter des listes
de titres et demandent les titres dsirs.
Un emprunteur peut rserver un titre non disponible. Quand le livre ou magazine est retourn ou
achet, la personne est avertie. La rservation est annule quand l'emprunt est fait ou
explicitement par une opration d'annulation. Le systme doit permettre facilement de crer,
mettre jour, supprimer des titres, des emprunteurs, des emprunts, des rservations.
TravaiI faire
Dessiner le diagramme des cas d'utilisation du systme. Brivement dcrire chaque cas.

4. OrnithoIogie
Une association d'ornithologie (d'tude des oiseaux) souhaite raliser une application de gestion
des observations faites par ses adhrents, appele PAFS. Son objectif principal est de stocker
toutes les observations et d'tablir des cartes de prsence des espces d'oiseau sur le territoire
gr par l'association.
Pour chaque observation, l'adhrent qui l'a ralise saisit : son nom, le nom de l'espce observe
(nom courant ou nom scientifique), le nombre d'individus observs, le lieu de l'observation (nom ou
code postal de la commune et un descriptif prcis du lieu), la date et heure de l'observation, les
conditions mto au moment de l'observation.
Les observations saisies par les adhrents sont dans un tat ' valider'. Tant qu'elles ne sont pas
valides par un adhrent salari de l'association elles restent modifiables.
Un adhrent salari peut valider une observation. Lors de cette opration le logiciel contrle
automatiquement que le nom d'espce est connu (toutes les espces connues sur ce territoire
sont rpertories), que l'observateur est adhrent de l'association, que la commune existe sur le
territoire (toutes les communes du territoire sont rpertories), que les dates et heures sont
correctement saisies et que tous les champs sont remplis. Au vu de ces contrles et aprs lecture
de toutes les informations saisies, l'adhrent salari fait passer l'observation dans l'tat 'valid' ou
dans l'tat 'non valid'. Seules les observations valides sont conserves, les autres sont
automatiquement supprimes chaque semaine.
A partir des observations valides, PAFS doit permettre d'afficher :
- des cartes de prsence par espce avec un cumul du nombre d'individus de l'espce observs
(ce traitement peut tre demand par tout adhrent),
- des cartes des observations ralises par chaque adhrent (ce traitement ne peut tre demand
que par les adhrents salaris de l'association).
Ces cartes sont construites grce a la connaissance des coordonnees geographiques des communes.
TravaiI faire
Dessiner le diagramme des cas d'utilisation du logiciel PAFS. Brivement dcrire chaque cas.

5. Cyber-cartes
L'application web cyber-cartes doit permettre :
un internaute de s'inscrire pour crer un compte; il choisit alors un login et un mot de passe; il
devient, aprs validation du compte par l'administrateur, un client de cyber-cartes ;
un administrateur de se connecter ; aprs quoi il peut valider un ou plusieurs comptes
correspondant chacun une demande d'un internaute et se dconnecter ;
un client de se connecter l'application ; aprs quoi il peut :
crer une (ou plusieurs) carte(s) lectronique(s) avec obligatoirement un texte
personnalis et dans la(les)quelle(s) il peut en plus :
- ajouter une ou plusieurs images animes,
- ajouter une mlodie.
expdier une ou plusieurs cartes par e-mail un destinataire dont il fournit l'adresse e-
mail sous la forme d'une chane de caractres.
se dconnecter.
TravaiI faire
Dessinez le diagramme des cas d'utilisation de cyber-cartes . Brivement dcrire chaque cas.
30


31

TD Diagrammes de cIasses UML


1. Gestion cirque
Le propritaire d'un cirque souhaite informatiser une partie de la gestion de ses spectacles.
Proposer un diagramme de classes UML qui rponde aux spcifications, fournies ci-dessous.
Les membres du personnel du cirque sont caractriss par un numro (en gnral leur numro
NSEE), leur nom, leur prnom, leur date de naissance et leur salaire. On souhaite de surcrot
stocker les pseudonymes des artistes et le numro du permis de conduire des chauffeurs de poids
lourds.
Les artistes sont susceptibles d'assurer plusieurs numros, chaque numro tant caractris par
un code, son nom, le nombre d'artistes prsents sur scne et sa dure. De plus, on souhaite
savoir l'instrument utilis pour les numros musicaux, l'animal concern par les numros de
dressage et le type des acrobaties (contorsionnisme, quilibrisme, trapze volant.).
Par ailleurs, chaque numro peut ncessiter un certain nombre d'accessoires caractriss par un
numro de srie, une dsignation, une couleur et un volume.
On souhaite galement savoir, individuellement, quels artistes utilisent quels accessoires.
Enfin, les accessoires sont rangs aprs chaque spectacle dans des camions caractriss par leur
numro d'immatriculation, leur marque, leur modle et leur capacit (en volume). Selon la taille du
camion, une quipe plus ou moins nombreuses de chauffeurs lui est assign (de un trois
chauffeurs).
TravaiI faire
Dessiner le diagramme de classes.

2. Gestion de Ia formation
On reprend l'nonc pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
Dessiner le diagramme des classes du domaine avec les classes, les associations, les relations
d'hritage, les multiplicits (cardinalits), les attributs.

3. OrnithoIogie
On reprend l'nonc pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
Dessiner le diagramme des classes du domaine avec les classes, les associations, les relations
d'hritage, les multiplicits (cardinalits), les attributs.

4. Cyber-kebab
On reprend l'nonc du cyber-kebab pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
Complter le diagramme de classes en annexe sans ajouter ni classes, ni associations mais en
compltant les zones en pointills. Les zones de petite taille correspondent des cardinalits.

5. Carte gographique
Une carte gographique est caractrise par une chelle, la longitude et la latitude de son coin
infrieur gauche, la hauteur et la largeur de la zone couverte par la carte. Une carte comporte un
ensemble de donnes gographiques de natures diverses. Les villes et les montagnes sont
repres par un point unique. Chaque point a 2 coordonnes x et y calcules par rapport au coin
infrieur gauche de la carte. Un nom est associ chaque donne gographique repre par un
point. Les routes et les rivires sont repres par des lignes brises, c'est dire par un ensemble
de points correspondant aux extrmits de ses segments de droite. Les routes et les rivires ont
des noms et des paisseurs de trait. Les lacs, mers et forts sont reprsentes par des rgions
caractrises par un nom et une couleur de remplissage. Une rgion est une ligne brise referme
sur elle mme.
TravaiI faire
Donnez un schma de classes UML permettant de reprsenter une carte en utilisant les relations
de spcialisation (hritage) et de dcomposition (aggrgation).
32


6. Les dmons
a. Pour chaque paragraphe numrot, dessinez un diagramme UML permettant de reprsenter les
notions que ce paragraphe dcrit.
(1) Les dmons sont de deux sortes : les fermions et les bosons.
(2) Un tre vivant possde une ou plusieurs loges dans lesquelles viennent se placer des dmons.
Un dmon est ubiquiste, cela signifie qu'il peut tre prsent dans plusieurs loges.
(3) Les bosons sont toujours plusieurs dans une loge. Dans ce cas la loge est dite bosonique. Un
fermion, par contre, est toujours seul dans une loge. Dans ce cas la loge est dite fermionique.
(4) Les tres humains normaux possdent deux loges bosoniques (remplies de bosons). 5% sont
hors norme : ils possdent une loge avec des bosons et une loge fermionique (avec un fermion).
0,000001% sont rarissimes : ils possdent deux loges avec un fermion.
(5) l existe plusieurs sortes de bosons : les hypnotiques, les processionnaires et les caracoles.
b. Synthtisez les diagrammes prcdents en un seul.
c. Un dmon possde une puissance, reprsente par un nombre. Pour un boson, ce nombre est
entier, il s'appelle le charme. Pour un fermion, ce nombre est rel, il s'appelle la rsistance. Les
hypnotiques ont un charme variable, les caracoles ont un charme constant de 1, les
processionnaires ont un charme constant de 2.
Placez dans les classes les attributs 'puissance', 'charme', 'rsistance'.
dem avec les mthodes 'void occuperUneLoge(Loge)', 'void ecrireCharme(entier)', 'entier
lireCharme()', rel lireResistance()', 'void afficherBosons()', 'void afficherFermion()'.

7. Les VoIs
Une compagnie arienne gre des vols, c'est--dire des parcours ariens entre une ville de dpart
et une ville d'arrive, avec un numro de vol et une frquence. Un vol peut se dcomposer en un
ou plusieurs tronons (s'il existe des escales dans des villes intermdiaires), caractriss chacun
par une ville et une heure de dpart, une ville et une heure d'arrive, une distance. Certains vols
se partagent les mmes tronons mais pas ncessairement aux mmes heures.
Lorsqu'un vol est programm pour une date il constitue un dpart, caractris par un numro de
dpart. Un vol n'est programm qu'une seule fois dans une journe l'heure de dpart.
Des passagers sont enregistrs pour un dpart, caractriss par un nom, une adresse et un
numro de tlphone.
Un avion est affect chaque dpart, caractris par son immatriculation, son type et sa capacit.
l utilise une certaine quantit de krosne pour le trajet qui dpend des conditions climatiques et
donc de la date du dpart.
Des personnels sont affects chaque dpart. On distingue les non-navigants et les navigants. ls
sont caractriss par leur nom, adresse et numro de tlphone. Pour les navigants on garde le
cumul des heures voles dans l'anne.
TravaiI Faire
Donnez un schma de classes UML utilisant au maximum la relation de spcialisation/
gnralisation entre classes (hritage).
Rappel : des attributs peuvent tre attachs une association grce une classe anonyme qui lui
est lie.

8. BataiIIe navaIe
Le jeu de la bataille navale se compose d'un tableau de n lignes et m colonnes et d'un ensemble
de bateaux positionns sur ce tableau.
Chaque bateau comporte un ensemble de taille fixe de cases. l y a les croiseurs qui comportent 3
cases, les escorteurs avec 2 cases et les sous-marins avec une seule case.
Chaque case est caractrise par sa position dans le tableau (n de la ligne et n de la colonne) et
par son tat : intacte ou touche.
Les bateaux doivent toujours tre spars par au moins une case vide.
Les sous-marins ont la possibilit de plonger. Lorsqu'ils plongent ils ne peuvent pas tre touchs.
Exemple : tableau 10 sur 10 avec 2 bateaux de chaque type

33













TravaiI Faire
1) Donner le schma de classes UML traduisant cette description du jeu (classes, associations,
relations d'hritage, multiplicits, attributs).
2) Quand et comment prendre en compte la contrainte 'les bateaux doivent toujours tre spars
par au moins une case vide' ?

9. Mta modIe UML
Donner le modle de classes UML qui permet d'instancier n'importe quel diagramme de cas UML
avec des instances d'acteurs, des instances de cas, des instances d'interactions, etc. Un tel
modle est souvent appel un 'mta-modle' car c'est un modle qui dcrit tous les composants
d'un autre modle.
On rappelle qu'un diagramme de cas d'utilisation contient 6 types de composants : acteur, cas,
interaction (entre un acteur et un cas), hritage (entre 2 acteurs ou entre 2 cas), relation
d'extension (entre 2 cas) et relation d'inclusion (entre 2 cas).

34

10. Annexe

Lieu est un type permettant de situer dans l'espace.
DateHeure est un type permettant de situer dans le temps.
EtatCommande est un type numr prenant les valeurs suivantes :







Pilote
position : Lieu
Collaborateur
numCB : integer
position : Lieu
nom : string
nbCollaborateursMax : integer
nom : string
position : Lieu
Plat
nom : string
tariI : real
photo : Image
quantite : integer
Commande
etat : EtatCommande
no : integer
creation : DateHeure
modiIication : DateHeure

*
1
35

TD Diagrammes de squences


1. Passage en caisse - diagramme de squence au niveau de I'anaIyse des besoins
On considre le cas d'utilisation 'Traiter le passage en caisse' au sein de la gestion des caisses
enregistreuses d'un supermarch.





























Le scnario nominal d'un passage en caisse avec paiement en espces est le suivant :
- un client arrive la caisse avec des articles payer,
- le caissier enregistre le numro d'identification de chaque article et la quantit si elle excde un,
- la caisse affiche le libell et le prix de chaque article,
- lorsque tous les achats sont enregistrs le caissier signale la fin de l'enregistrement,
- la caisse affiche le total des achats,
- le client choisit de payer en espces et donne une somme et ventuellement des coupons de
rduction,
- la caissier enregistre la somme reue et ventuellement les coupons de rduction,
- la caisse affiche la somme rendre,
- le caissier encaisse la somme et sort la monnaie rendre,
- le caissier rend la monnaie,
- la caisse enregistre la vente et imprime le ticket,
- le caissier donne le ticket de caisse au client.
TravaiI faire
Reprsenter ce scnario comme un diagramme de squence entre caisse, caissier et client. On
pourra faire apparatre les messages et les flux matriels (en pointills).

2. OrnithoIogie
On reprend l'nonc pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
Dessiner le diagramme de squences correspondant la saisie d'une observation.
Initialiser la
caisse
Responsable magasin
Caissier
Client
Traiter passage
en caisse
Prendre en compte
coupons reduction
Etend~~
Traiter paiement
Inclut~~
Acteur~~
Gestion des
stocks
Paiement par
cheque
Paiement par
carte
Paiement en
especes
Acteur~~
Centre
autorisation
cheques
Acteur~~
Centre
autorisation
cartes
36

3. Gestion d'une bibIiothque - diagramme de squence entre cIasses d'une appIication au

niveau de I'anaIyse du systme ('cIasses mtiers')
Au cours de l'analyse de la gestion d'une bibliothque on a retenu les classes mtier suivantes.


Rappel : une association s`implante par un attribut contenant un objet (si cardinalite 1) ou par une
collection (table) d`objets (si cardinalite *). Donc l`implantation de Bibliotheque aura 3 attributs
collection (tables) pour les 3 associations et celle de Prt aura 2 attributs pour les associations de`
et par`.
TravaiI faire
Raffiner le diagramme de squence suivant (associ au cas Emprunt des livres) en faisant
intervenir les classes concernes et les messages qu'elles s'changent.















Les tables de la classe Bibliothque (table de tous les objets livre, table de tous les objets
adhrents et table de tous les prts pour une dure 15 jours) ont des mthodes :
- trouverLivre(SBN), trouverAdhrent(nom, prnom) et trouverPrt(n prt) qui retournent les
objets cherchs,
- ajouterLivre(objet livre), ajouterAdhrent(objet adhrent) et ajouterPrt(objet prt) qui ajoutent les
objets aux tables.

:Systeme
:Bibliothecaire
nom, prenom de l`emprunteur
ISBN du livre a emprunter
37

Rappel : pour crer un objet on appelle la mthode crer(valeurs initiales des attributs) qui
retourne cet objet; pour modifier un attribut d'un objet on appelle la mthode setAttribut(valeur);
pour lire la valeur d'un attribut d'un objet on appelle getAttribut() qui retourne la valeur.

4. Cyber-cartes
On reprend l'nonc pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
En vous basant sur le diagramme de classes qui suit, dessiner un diagramme de squences
dcrivant un client qui se connecte, cre une carte lectronique, ajoute un texte et une image
anime, l'envoie une adresse e-mail et se dconnecte.





































5. Impressions
Le processus d'impression dbute par la slection d'un document auprs du Gestionnaire de
documents (cf. schma de classes ci-aprs). Puis une demande d'impression du document
slectionn est envoye au Gestionnaire de documents. Suite cette demande, le Gestionnaire
de documents demande au document slectionn de s'imprimer lui-mme. Le document va alors
demander au Gestionnaire de lui retourner l'imprimante utiliser. Puis il communique avec cette
imprimante pour lui demander de l'imprimer. Celle-ci va lui demander successivement le titre, le
corps du texte et le pied de page.
*
38


TravaiI faire
Etablissez un diagramme de squences reprsentant le processus d'impression d'un document
l'aide des classes et mthodes de la figure qui suit.

39

TD Diagrammes de modIisation de Ia dynamique


1. Guichet automatique de banque - diagramme d'activits et d'tats
Modliser le retrait d'argent dans un guichet automatique de banque (GAB). La carte peut tre
invalide (ex : date d'expiration dpasse) et elle est refuse. Si elle est valide, le client doit taper
son code. La carte est avale aprs trois essais infructueux. Le systme d'autorisation VSA
autorise un certain montant ou refuse tout retrait. Une carte non rcupre aprs quelques
secondes est avale. Les billets non rcuprs par le client sont repris. Un ticket est toujours
imprim pendant que les billets sont proposs.
TravaiI faire
a) Modliser avec un diagramme d'activits la dynamique de ce systme.
b) Modliser avec un diagramme d'tats l'volution de la carte de crdit dans le GAB.
2. Gestion de Ia formation - diagramme d'activits et d'tats
On reprend l'nonc de la gestion de la formation pour lequel on a dj construit les cas
d'utilisation.
TravaiI faire
a) Modliser avec un diagramme d'activits la dynamique de ce systme.
b) Modliser avec un diagramme d'tats l'volution d'une demande de formation.
3. OrnithoIogie
On reprend l'nonc pour lequel on a dj construit les cas d'utilisation.
TravaiI faire
Dessiner le diagramme d'tats d'une observation.

4. La vie d'un thread. Diagramme d'tats
Dessinez un diagramme d'tats correspondant la dynamique d'un thread (processus lger)
dfinie de la manire suivante. Le thread est :
- non dmarr au dbut,
- en cours lorsqu'il possde toutes ses ressources applicatives plus le processeur,
- en attente lorsqu'il lui manque une ressource applicative,
- prt lorsqu'il a toutes ses ressources applicatives et pas le processeur,
- termin lorsqu'il a termin son excution.
On supposera qu'un thread n'envoie pas d'vnement. l ne fait que les recevoir. On supposera
que les vnements reus par le thread sont : dbut , ressource attendue , ressource OK
, processeur OK , fin :
- dbut correspond au dmarrage du thread (start en java, execlv en Unix, .). Avant la
rception de dbut , le thread est non dmarr .
- ressource attendue correspond l'indication qu'une ressource applicative attendue n'est
pas disponible.
- ressource OK correspond la libration d'une ressource applicative par un autre thread et
donc la rservation effective de la ressource par le thread qui l'attendait.
- processeur OK correspond la libration du processeur par un autre thread et l'utilisation
effective du processeur par le thread qui l'attendait.
- fin correspond soit l'excution de la dernire instruction du programme excut par le
thread soit l'envoi d'un vnement pour tuer dfinitivement le thread. Sur rception de fin ,
le thread devient termin .

5. Photocopieur
Un dispositif de contrle d'accs par carte magntique un photocopieur est quip d'un cran de
visualisation qui peut afficher les messages suivants :
"NSEREZ VOTRE CARTE" lorsque le dispositif est inutilis,
"PATENTER" pendant que le dispositif lit le code d'une carte introduite,
40

"CARTE NVALDE" lorsque le code n'est pas reconnu (illisible) ; la carte est alors
automatiquement jecte,
"COMPOSEZ VOTRE CODE" lorsque celui-ci a pu tre lu,
"CODE REFUSE" si le code compos n'est pas identique au code lu ; la carte est alors
automatiquement jecte,
"UTLSATON EN COURS" lorsque le code compos est correct.
L'utilisateur peut tout moment actionner un bouton qui provoque l'jection de la carte. Aprs
toute jection de carte, le dispositif affiche "NSERER CARTE".
TravaiI faire
Proposez le diagramme d'tats du lecteur de carte. Les tats correspondent aux diffrents
affichages. Sur chaque transition entre tats indiquer la condition de transition (notation : si
condition) ou l'action de l'utilisateur et/ou l'action du dispositif qui a dclench la transition
(notation : action utiIisateur/action dispositif une des deux actions pouvant tre absente).

41

TD CIasses vers reIationneI

Exercice 1

Traduire le diagramme de classes UML suivant en relationnel.

Exercice 2

Traduire le diagramme de classes UML suivant en modle logique relationnel.



























Exercice 3
Soit le schma de classes ci-dessous.
a) D'aprs ce schma, un lot peut-il contenir un lot ?
b) Traduisez ce schma en relationnel avec la stratgie qui consiste associer une table par
classe de l'arbre d'hritage,
c) Mme question avec la stratgie qui consiste associer une seule table tout l'arbre d'hritage.
Transaction

NoTrans
Libelle
Montant
Client

NoClient
Nom
Adresse
emet
0..* 1
Compte

NoCompte
Solde
concerne ~
1
0..*
estTitulaire
1..*
1..*
Agence

NoAgence
Localisation
gere ~
1..* 1
1
0..*
traite `
CarteBleue

NoCarte
possede v
0..1
1
moyen Paiement
0..* 1
CompteDept

Autorisation
CompteEpargne

PlaIond
42



Exercice 4
Soit le schma de classes ci-dessous.
a) Traduisez ce schma en relationnel avec la stratgie qui consiste associer une table par
classe de l'arbre d'hritage,
b) Mme question, avec la stratgie qui consiste associer une seule table tout l'arbre
d'hritage.

Exercice 5
a) Modliser le systme de fichiers dcrit ci-aprs l'aide d'un diagramme de classes.
Le systme de fichiers est une arborescence de dossiers et de fichiers contenue dans un dossier
racine (le 'root directory'). Les dossiers contiennent des (sous-)dossiers et/ou des fichiers. Chaque
utilisateur a un dossier son nom (son 'home directory'). Chaque fichier/dossier a un utilisateur qui
le possde ('owner'). Chaque utilisateur peut lire certains fichiers.
b) Traduire ce schma de classes en relationnel.
43


Etude de cas UML

Un serveur de runions virtueIIes sur Internet

1. Prsentation
l s'agit d'adapter le concept de messagerie instantane un contexte de runions de travail au
sein d'une entreprise ayant de multiples implantations gographiques.
Le but de l'tude est d'analyser la partie serveur d'une application client-serveur permettant de
faire des runions de travail virtuelles sur nternet.










L'application cherche imiter le droulement des runions de travail classiques. Les runions sont
planifies l'avance. A la date fixe, les participants se connectent, entrent dans la runion et
peuvent changer des messages en mode texte. Le serveur doit permettre de planifier et de grer
le droulement de plusieurs runions simultanes.

Une fois connect ( l'aide d'un nom de login et d'un mot de passe spcifique l'application et
mmoris sur le serveur), un utilisateur a la possibilit de :
planifier des runions virtuelles (choix de son nom, description de son sujet, date de dbut,
dure prvue, description de son ordre du jour, type et ventuellement participants
autoriss) dont il devient l'organisateur,
consulter les descriptions des runions planifies (tous les utilisateurs peuvent consulter
toutes les descriptions),
modifier ces descriptions (seul l'organisateur peut modifier la description d'une runion),
ouvrir et clturer une runion (l'animateur de la runion quand il existe ou dfaut son
organisateur cf. ci-aprs les diffrents types de runions),
entrer virtuellement dans une runion prcdemment ouverte (tous les utilisateurs ou
seulement les participants autoriss si c'est une runion prive),
en sortir.

En cours de runion, un participant doit demander prendre la parole. Quand elle lui est accorde
(cf. ci-aprs les diffrents types de runion), il peut entrer le texte d'un (ou plusieurs) message(s)
qui est (sont) transmis en temps-rel par le serveur tous les participants de la runion. Le
participant doit rendre la parole quand il a fini de s'exprimer. l peut aussi annuler une demande de
prise de parole.

Les messages sont stocks avec un n d'ordre attribu par le serveur, la date et heure de
rception et le nom de l'auteur du message. Cela permet aux retardataires de recevoir l'ensemble
des messages dj changs dans la runion.

Plusieurs types de runions peuvent tre organiss :
des runions standards , avec un organisateur qui se charge de la planification de la
runion et dsigne un animateur (ventuellement lui-mme) charg de choisir les
Serveur de
l'application BD
Client
Client
44

intervenants successifs parmi ceux qui ont demand la parole ; tout utilisateur peut
participer (ce sont des runions publiques) ;
des runions prives , qui sont des runions standards dont l'entre est rserve
un groupe de participants particulier autoris par l'organisateur ;
des runions dmocratiques , qui sont planifies comme des runions standards et,
comme elles, sont publiques. Elles n'ont pas d'animateur : les intervenants successifs sont
choisis automatiquement par le programme sur la base d'une politique premier demandeur-
premier servi (FFO). La runion est ouverte et ferme par l'organisateur.

L'administrateur du systme peut ajouter/supprimer des utilisateurs et des administrateurs avec
leur nom, login, et mot de passe initial. Les utilisateurs peuvent modifier leur mot de passe.


2. TravaiI faire
1) Cas d'utiIisations
a) Etablir le diagramme des cas d'utilisation du systme.
b) Associer une courte description textuelle chaque cas d'utilisation (quoi ? qui ? quand ?).
c) Ecrire un scenario global d'utilisation du systme : au minimum, cration de quelques
utilisateurs et d'une runion de chaque type avec quelques changes de messages. Ce
scnario peut aider comprendre le problme. l pourra galement tre utilis pour tester le
systme quand il aura t dvelopp.
ConseiIs
L'hritage entre acteurs signifie que l'acteur qui hrite peut faire tout ce que l'acteur dont il
hrite peut faire. Cela simplifie le dessin du diagramme des cas mais n'a aucun impact sur
le programme qui sera ralis.
Les cas d'utilisation doivent correspondre des fonctionnalits significatives du point de
vue des utilisateurs du systme.
Les relations extends et include entre cas ne doivent pas servir dcrire des
enchanements d'actions lmentaires (ce sera le rle des diagrammes d'activits).


2) Diagramme de cIasses initiaI
A partir de l'nonc, proposer un diagramme de classes initial centr sur les utilisateurs et les
runions, avec les principales associations et relations d'hritage entre ces concepts et les
attributs essentiels. Les mthodes seront ajoutes ultrieurement.
ConseiIs
Dans la majorit des langages les objets possdent un type et ne peuvent en changer
(typage statique). Quand un objet d'une classe drive est cr il prend ce type en hritant
de toutes les proprits de la classe dont il drive. Si on veut reprsenter quelque chose de
plus dynamique, qui volue dans le temps, l'hritage ne convient pas.


3) Diagrammes de squences
Expliciter les cas suivants par des diagrammes de squences : se connecter au serveur, planifier
une runion virtuelle, ouvrir une runion virtuelle.
Ces diagrammes doivent montrer toutes les classes qui participent (c'est--dire qui hbergent des
traitements, qui sont cres, qui sont interroges.) avec les messages qui circulent vers et
depuis ces classes. L'objectif est de trouver ventuellement de nouvelles classes et surtout les
mthodes utiles la ralisation des cas.
ConseiIs
45

A l'origine de chaque cas on a un acteur qui envoie un message contenant des chanes de
caractres (la partie cliente de l'application n'est pas tudie et pas reprsente).
Le message envoy par l'acteur doit arriver une classe bien dfinie qu'il faut introduire
dans le diagramme de squences (quand on crira l'application cliente il faudra appeler
cette classe particulire). Cette classe correspond une Faade (cf. le patron de
conception Faade en annexe).


4) Diagrammes d'tats
Donner les diagrammes d'tats des classes utilisateur et runion.
ConseiIs
On cherche reprsenter les tats communs tous les utilisateurs et tous les types de
runions.
On pourra utiliser des tats imbriqus si ncessaire.
L'objectif est de trouver de nouvelles proprits (attributs et mthodes) utiles.


5) Diagramme de cIasses finaI
A partir des rsultats prcdents et de l'nonc, enrichir le diagramme de classes avec les
classes, les associations, les attributs et mthodes jusqu' ce qu'il apparaisse raisonnablement
complet pour cette phase initiale d'analyse.
ConseiIs
Essayer d'utiliser toutes les possibilits de la notation objet UML (hritage, agrgation,
associations, multiplicits.).

Un dossier d'analyse doit tre rendu qui rponde ces questions. Les schmas seront raliss
l'aide de WinDesign. Les schmas devront tre accompagns d'explications chaque fois que des
choix non vidents auront t effectus.
46


Annexe : Ies patrons de conception faade et singIeton

Faade
Une classe faade constitue un point d'entre unique pour accder un sous-systme. La
faade est unidirectionnelle : de l'extrieur (les modules utilisant le sous systme) vers l'intrieur.
Elle peut se charger de crer certains composants.


SingIeton
Comme la classe Faade a une seule instance on peut en faire un singleton . C'est une classe
qui contient un attribut de classe priv contenant l'instance unique et une mthode de classe
getnstance() qui cre l'instance si elle n'existe pas (via un constructeur priv) ou la retourne si elle
existe dj.
Cela garantit l'unicit de l'instance.
De plus, Facade.getnstance() peut tre appel tout endroit, sans avoir passer l'objet faade en
paramtre des mthodes.


- : mthode ou attribut priv
soulignement : mthode ou attribut de classe