Vous êtes sur la page 1sur 46

Compléments d’analyse et

conception des systèmes


d’information (ACSI)

COURS, TD, Etude de cas

Public concerné : DUT Informatique 2ème année

Jacques LONCHAMP Date : 2012/2013

UNIVERSITE DE LORRAINE
IUT Nancy-Charlemagne
2ter boulevard Charlemagne
CS 5227
54052 NANCY Cedex
-------------------------------
Tél : 03.54.50.38.00
Fax : 03.54.50.38.01
http://iut-charlemagne.univ-nancy2.fr
2
Table des matières

PARTIE 1 : COURS
1. Présentation d’UML p. 5
2. Les cas d’utilisation p. 7
3. Les diagrammes de classes p. 11
4. Les diagrammes d’interactions p. 15
5. Les diagrammes d’états et d’activités p. 17
6. Traduction schéma de classes vers schéma relationnel p. 21
7. Le processus de développement objet p. 23

PARTIE 2 : TRAVAUX DIRIGES


1. TD cas d’utilisation p. 27
2. TD diagrammes de classes p. 31
3. TD diagrammes de séquences p. 35
4. TD diagrammes de modélisation de la dynamique p. 39
5. TD classes vers relationnel p. 41

PARTIE 3 : ETUDE DE CAS p. 43

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
TD Cas d’utilisation

1. Gestion de la formation
Une entreprise souhaite modéliser avec UML le processus de formation de ses employés afin
d’informatiser certaines tâches.
Le processus de formation est initialisé quand l’employé dépose une demande de formation. Cet
employé peut éventuellement consulter le catalogue des formations offertes par les organismes
sélectionnés par le responsable formation. Cette demande est examinée par le responsable. Pour
prendre sa décision (accord ou refus), le responsable examine le catalogue des formations
agréées qu’il tient à jour. Il informe l’employé du contenu de la formation choisie et lui soumet la
liste des prochaines sessions prévues. Lorsque l’employé à fait son choix il inscrit l’employé à la
session retenue auprès de l’organisme de formation concerné.
En cas d’empêchement 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 appréciation sur le stage suivi.
Le responsable formation valide la formation au vu de la facture envoyée par l’organisme de
formation.
Travail à faire
Identifier les acteurs et les cas. Dessiner le diagramme des cas d’utilisation en structurant
éventuellement les cas. Brièvement décrire chaque cas.

2. Cyber-Kebab
L'entreprise MegaKebab regroupe dans une même ville de nombreux restaurants appelés "Points
Kebab". Elle est spécialisée dans la livraison à domicile de Kebabs et autres spécialités.
Actuellement, les commandes se font par téléphone directement auprès de chaque restaurant. Un
nombre limité de commandes peut être traité et chaque client doit connaître 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.
Grâce à ce logiciel, MegaKebab souhaite gérer à distance et de manière centralisée toutes les
commandes, les Points Kebab et les employés appelés "Collaborateurs". Cette centralisation doit
permettre de rendre accessible sur Internet tous les plats disponibles. Chaque plat est décrit par
un nom, une photo et un prix (identique partout). Dans le cadre de la politique marketing, une
durée est également associée à chaque plat chaud : si le temps écoulé entre la fin de préparation
et la livraison est supérieur à cette durée, le client peut se faire rembourser sa commande.
Cependant, pour ne pas inciter les clients à utiliser cette possibilité, cette opération n'est pas
disponible sur Internet : le client doit remplir une demande écrite sur papier libre et l'envoyer au
gérant de MegaKebab. A tout moment il est possible de passer une commande par Internet. Le
client doit disposer d'une carte de crédit qui l'identifie de manière unique. Lors d'une première
commande il lui est également demandé de saisir son nom et de situer son lieu de résidence sur
une carte de la ville. Une même commande peut comporter plusieurs plats. Pour chaque plat
sélectionné le client doit indiquer la quantité désirée. Après 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 très flexibles. Lors de leur embauche, un téléphone portable leur est remis. Il suffit
d'appuyer sur un bouton pour faire part de leur disponibilité auprès de MegaKebab. Un autre
bouton permet d'indiquer qu'ils ne le sont plus. A tout moment le gérant peut consulter via Internet
l'état du système global. Il peut affecter un collaborateur soit à un Point Kebab soit à la livraison.
Un collaborateur peut ainsi changer de lieu de travail ou de rôle plusieurs fois dans une journée : le
rôle du gérant 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 gérant qui affecte la
commande à un PointKebab et à un livreur. Le gérant cherche en général à optimiser la distance
parcourue ainsi que les activités des PointKebabs et des collaborateurs.

27
Chaque livreur utilise son propre moyen de transport (bus, vélo, roller, voiture …). Par contre, un
appareil appelé "Pilote" lui est remis lors de son affectation à la livraison. Chaque pilote intègre un
GPS permettant de localiser le livreur de manière précise via une liaison satellite. Un écran permet
au livreur de consulter les commandes qui lui ont été affectées. Il 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 récupère une commande auprès du Point Kebab et quand il livre la
commande au client.
Dans chaque Point Kebab un collaborateur joue le rôle de "coordinateur". C'est le seul du
restaurant à agir directement avec CyberKebab : les autres collaborateurs préparent les plats. Le
coordinateur consulte les commandes à réaliser et indique pour chaque commande quand sa
préparation débute, quand elle se termine et quand elle est remise au livreur.
Travail à faire
Compléter le diagramme des cas d'utilisation du système CyberKebab donné ci-dessous. Seuls
les acteurs humains sont pris en compte (ni le Pilote, ni le téléphone ne sont représentés).

Passer une commande


Livrer une commande

unClient

CyberKebab

3. Gestion d’une bibliothèque


La bibliothèque prête des livres et magazines à des emprunteurs, qui sont enregistrés dans le
système de même que les livres et les magazines Les titres les plus demandés peuvent exister en
plusieurs exemplaires. Les vieux exemplaires sont retirés quand ils sont dépassés ou abîmés.

28
Le «bibliothécaire» est l’employé qui interagit avec les emprunteurs et dont le travail est assisté
par le système. Les documents ne sont pas en accès libre. Les clients peuvent consulter des listes
de titres et demandent les titres désirés.
Un emprunteur peut réserver un titre non disponible. Quand le livre ou magazine est retourné ou
acheté, la personne est avertie. La réservation est annulée quand l’emprunt est fait ou
explicitement par une opération d’annulation. Le système doit permettre facilement de créer,
mettre à jour, supprimer des titres, des emprunteurs, des emprunts, des réservations.
Travail à faire
Dessiner le diagramme des cas d'utilisation du système. Brièvement décrire chaque cas.

4. Ornithologie
Une association d’ornithologie (d’étude des oiseaux) souhaite réaliser une application de gestion
des observations faites par ses adhérents, appelée PIAFS. Son objectif principal est de stocker
toutes les observations et d’établir des cartes de présence des espèces d’oiseau sur le territoire
géré par l’association.
Pour chaque observation, l’adhérent qui l’a réalisée saisit : son nom, le nom de l’espèce observée
(nom courant ou nom scientifique), le nombre d’individus observés, le lieu de l’observation (nom ou
code postal de la commune et un descriptif précis du lieu), la date et heure de l’observation, les
conditions météo au moment de l’observation.
Les observations saisies par les adhérents sont dans un état ‘à valider’. Tant qu’elles ne sont pas
validées par un adhérent salarié de l’association elles restent modifiables.
Un adhérent salarié peut valider une observation. Lors de cette opération le logiciel contrôle
automatiquement que le nom d’espèce est connu (toutes les espèces connues sur ce territoire
sont répertoriées), que l’observateur est adhérent de l’association, que la commune existe sur le
territoire (toutes les communes du territoire sont répertoriées), que les dates et heures sont
correctement saisies et que tous les champs sont remplis. Au vu de ces contrôles et après lecture
de toutes les informations saisies, l’adhérent salarié fait passer l’observation dans l’état ‘validé’ ou
dans l’état ‘non validé’. Seules les observations validées sont conservées, les autres sont
automatiquement supprimées chaque semaine.
A partir des observations validées, PIAFS doit permettre d’afficher :
- des cartes de présence par espèce avec un cumul du nombre d’individus de l’espèce observés
(ce traitement peut être demandé par tout adhérent),
- des cartes des observations réalisées par chaque adhérent (ce traitement ne peut être demandé
que par les adhérents salariés de l’association).
Ces cartes sont construites grâce à la connaissance des coordonnées géographiques des communes.
Travail à faire
Dessiner le diagramme des cas d’utilisation du logiciel PIAFS. Brièvement décrire chaque cas.

5. Cyber-cartes
L’application web « cyber-cartes » doit permettre :
• à un internaute de s’inscrire pour créer un compte; il choisit alors un login et un mot de passe; il
devient, après validation du compte par l’administrateur, un client de « cyber-cartes »;
• à un administrateur de se connecter ; après quoi il peut valider un ou plusieurs comptes
correspondant chacun à une demande d’un internaute et se déconnecter ;
• à un client de se connecter à l’application ; après quoi il peut :
o créer 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 animées,
- ajouter une mélodie.
o expédier une ou plusieurs cartes par e-mail à un destinataire dont il fournit l’adresse e-
mail sous la forme d’une chaîne de caractères.
o se déconnecter.
Travail à faire
Dessinez le diagramme des cas d’utilisation de « cyber-cartes ». Brièvement décrire chaque cas.

29
30
TD Diagrammes de classes UML

1. Gestion cirque
Le propriétaire d’un cirque souhaite informatiser une partie de la gestion de ses spectacles.
Proposer un diagramme de classes UML qui réponde aux spécifications, fournies ci-dessous.
Les membres du personnel du cirque sont caractérisés par un numéro (en général leur numéro
INSEE), leur nom, leur prénom, leur date de naissance et leur salaire. On souhaite de surcroît
stocker les pseudonymes des artistes et le numéro du permis de conduire des chauffeurs de poids
lourds.
Les artistes sont susceptibles d’assurer plusieurs numéros, chaque numéro étant caractérisé par
un code, son nom, le nombre d’artistes présents sur scène et sa durée. De plus, on souhaite
savoir l’instrument utilisé pour les numéros musicaux, l’animal concerné par les numéros de
dressage et le type des acrobaties (contorsionnisme, équilibrisme, trapèze volant…).
Par ailleurs, chaque numéro peut nécessiter un certain nombre d’accessoires caractérisés par un
numéro de série, une désignation, une couleur et un volume.
On souhaite également savoir, individuellement, quels artistes utilisent quels accessoires.
Enfin, les accessoires sont rangés après chaque spectacle dans des camions caractérisés par leur
numéro d’immatriculation, leur marque, leur modèle 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).
Travail à faire
Dessiner le diagramme de classes.

2. Gestion de la formation
On reprend l’énoncé pour lequel on a déjà construit les cas d’utilisation.
Travail à faire
Dessiner le diagramme des classes du domaine avec les classes, les associations, les relations
d’héritage, les multiplicités (cardinalités). On ne demande pas les attributs.

3. Ornithologie
On reprend l’énoncé pour lequel on a déjà construit les cas d’utilisation.
Travail à faire
Dessiner le diagramme des classes du domaine avec les classes, les associations, les relations
d’héritage, les multiplicités (cardinalités), les attributs.

4. Cyber-kebab
On reprend l’énoncé du cyber-kebab pour lequel on a déjà construit les cas d’utilisation.
Travail à faire
Compléter le diagramme de classes en annexe sans ajouter ni classes, ni associations mais en
complétant les zones en pointillés. Les zones de petite taille correspondent à des cardinalités.

5. Carte géographique
Une carte géographique est caractérisée par une échelle, la longitude et la latitude de son coin
inférieur gauche, la hauteur et la largeur de la zone couverte par la carte. Une carte comporte un
ensemble de données géographiques de natures diverses. Les villes et les montagnes sont
repérées par un point unique. Chaque point a 2 coordonnées x et y calculées par rapport au coin
inférieur gauche de la carte. Un nom est associé à chaque donnée géographique repérée par un
point. Les routes et les rivières sont repérées par des lignes brisées, c’est à dire par un ensemble
de points correspondant aux extrémités de ses segments de droite. Les routes et les rivières ont
des noms et des épaisseurs de trait. Les lacs, mers et forêts sont représentées par des régions
caractérisées par un nom et une couleur de remplissage. Une région est une ligne brisée refermée
sur elle même.
Travail à faire
Donnez un schéma de classes UML permettant de représenter une carte en utilisant les relations
de spécialisation (héritage) et de décomposition (aggrégation).

31
6. Les démons
a. Pour chaque paragraphe numéroté, dessinez un diagramme UML permettant de représenter les
notions que ce paragraphe décrit.
(1) Les démons sont de deux sortes : les fermions et les bosons.
(2) Un être vivant possède une ou plusieurs loges dans lesquelles viennent se placer des démons.
Un démon est ubiquiste, cela signifie qu’il peut être présent 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 possèdent deux loges bosoniques (remplies de bosons). 5% sont
hors norme : ils possèdent une loge avec des bosons et une loge fermionique (avec un fermion).
0,000001% sont rarissimes : ils possèdent deux loges avec un fermion.
(5) Il existe plusieurs sortes de bosons : les hypnotiques, les processionnaires et les caracoles.
b. Synthétisez les diagrammes précédents en un seul.
c. Un démon possède une puissance, représentée par un nombre. Pour un boson, ce nombre est
entier, il s’appelle le charme. Pour un fermion, ce nombre est réel, il s’appelle la résistance. 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’, ‘résistance’.
Idem avec les méthodes ‘void occuperUneLoge(Loge)’, ‘void ecrireCharme(entier)’, ‘entier
lireCharme()’, réel lireResistance()’, ‘void afficherBosons()’, ‘void afficherFermion()’.

7. Les Vols
Une compagnie aérienne gère des vols, c'est-à-dire des parcours aériens entre une ville de départ
et une ville d’arrivée, avec un numéro de vol et une fréquence. Un vol peut se décomposer en un
ou plusieurs tronçons (s’il existe des escales dans des villes intermédiaires), caractérisés chacun
par une ville et une heure de départ, une ville et une heure d’arrivée, une distance. Certains vols
se partagent les mêmes tronçons mais pas nécessairement aux mêmes heures.
Lorsqu’un vol est programmé pour une date il constitue un départ, caractérisé par un numéro de
départ. Un vol n’est programmé qu’une seule fois dans une journée à l’heure de départ.
Des passagers sont enregistrés pour un départ, caractérisés par un nom, une adresse et un
numéro de téléphone.
Un avion est affecté à chaque départ, caractérisé par son immatriculation, son type et sa capacité.
Il utilise une certaine quantité de kérosène pour le trajet qui dépend des conditions climatiques et
donc de la date du départ.
Des personnels sont affectés à chaque départ. On distingue les non-navigants et les navigants. Ils
sont caractérisés par leur nom, adresse et numéro de téléphone. Pour les navigants on garde le
cumul des heures volées dans l’année.
Travail à Faire
Donnez un schéma de classes UML utilisant au maximum la relation de spécialisation/
généralisation entre classes (héritage).
Rappel : des attributs peuvent être attachés à une association grâce à une classe anonyme qui lui
est liée.

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

32
X

X X X X
X
X
X X
X
X
X

Travail à Faire
1) Donner le schéma de classes UML traduisant cette description du jeu (classes, associations,
relations d’héritage, multiplicités, attributs).
2) Quand et comment prendre en compte la contrainte ‘les bateaux doivent toujours être séparés
par au moins une case vide’ ?

9. Méta modèle UML


Donner le modèle 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
modèle est souvent appelé un ‘méta-modèle’ car c’est un modèle qui décrit tous les composants
d’un autre modèle.
On rappelle qu’un diagramme de cas d’utilisation contient 6 types de composants : acteur, cas,
interaction (entre un acteur et un cas), héritage (entre 2 acteurs ou entre 2 cas), relation
d’extension (entre 2 cas) et relation d’inclusion (entre 2 cas).

33
10. Annexe

Pilote Collaborateur

position : Lieu numCB : integer


position : Lieu
nom : string
1 *

nbCollaborateursMax : integer
nom : string
position : Lieu

quantité : integer

Plat Commande

état : EtatCommande
nom : string
no : integer
tarif : real
création : DateHeure
photo : Image
modification : DateHeure

Lieu est un type permettant de situer dans l’espace.


DateHeure est un type permettant de situer dans le temps.
EtatCommande est un type énuméré prenant les valeurs suivantes :

34
TD Diagrammes de séquences

1. Passage en caisse - diagramme de séquence au niveau de l’analyse des besoins


On considère le cas d’utilisation ‘Traiter le passage en caisse’ au sein de la gestion des caisses
enregistreuses d’un supermarché.

Initialiser la
caisse
Responsable magasin

Caissier
Traiter passage <<Etend>> Prendre en compte
en caisse coupons réduction

<<Inclut>>
Client
<<Acteur>>
Traiter paiement Gestion des
stocks

Paiement par Paiement par Paiement en


chèque carte espèces

<<Acteur>> <<Acteur>>
Centre Centre
autorisation autorisation
chèques cartes

Le scénario nominal d’un passage en caisse avec paiement en espèces est le suivant :
- un client arrive à la caisse avec des articles à payer,
- le caissier enregistre le numéro d’identification de chaque article et la quantité si elle excède un,
- la caisse affiche le libellé et le prix de chaque article,
- lorsque tous les achats sont enregistrés le caissier signale la fin de l’enregistrement,
- la caisse affiche le total des achats,
- le client choisit de payer en espèces et donne une somme et éventuellement des coupons de
réduction,
- la caissier enregistre la somme reçue et éventuellement les coupons de réduction,
- 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.
Travail à faire
Représenter ce scénario comme un diagramme de séquence entre caisse, caissier et client. On
pourra faire apparaître les messages et les flux matériels (en pointillés).

2. Ornithologie
On reprend l’énoncé pour lequel on a déjà construit les cas d’utilisation.
Travail à faire
Dessiner le diagramme de séquences correspondant à la saisie d’une observation.

35
3. Gestion d’une bibliothèque - diagramme de séquence entre classes d’une application au
niveau de l’analyse du système (‘classes métiers’)
Au cours de l’analyse de la gestion d’une bibliothèque on a retenu les classes métier suivantes.

Rappel : une association s’implante par un attribut contenant un objet (si cardinalité 1) ou par une
collection (table) d’objets (si cardinalité *). Donc l’implantation de Bibliothèque aura 3 attributs
collection (tables) pour les 3 associations et celle de Prêt aura 2 attributs pour les associations ‘de’
et ‘par’.
Travail à faire
Raffiner le diagramme de séquence suivant (associé au cas Emprunt des livres) en faisant
intervenir les classes concernées et les messages qu’elles s’échangent.

:Système
:Bibliothécaire

nom, prénom de l’emprunteur

ISBN du livre à emprunter

Les tables de la classe Bibliothèque (table de tous les objets livre, table de tous les objets
adhérents et table de tous les prêts pour une durée 15 jours) ont des méthodes :
- trouverLivre(ISBN), trouverAdhérent(nom, prénom) et trouverPrêt(n° prêt) qui retournent les
objets cherchés,
- ajouterLivre(objet livre), ajouterAdhérent(objet adhérent) et ajouterPrêt(objet prêt) qui ajoutent les
objets aux tables.

36
Rappel : pour créer un objet on appelle la méthode créer(valeurs initiales des attributs) qui
retourne cet objet; pour modifier un attribut d’un objet on appelle la méthode setAttribut(valeur);
pour lire la valeur d’un attribut d’un objet on appelle getAttribut() qui retourne la valeur.

4. Boutique en ligne

Soit le scénario suivant précisant les étapes du cas d’utilisation « création de client » d’une
boutique en ligne :
- L’internaute saisit son email et son mot de passe.
- Le système crée un client dans un état « non validé » ; puis il calcule et envoie par mail un
code d’activation à l’internaute qui doit le retourner afin de prouver la validité de l’adresse mail.
- Le système vérifie le code retourné et en cas d’égalité des codes fait passer le compte à l’état
« validé ».
Donner le diagramme de séquences qui décrit ce scénario.

5. Impressions
Le processus d’impression débute par la sélection d’un document auprès du Gestionnaire de
documents (cf. schéma de classes ci-après). Puis une demande d’impression du document
sélectionné est envoyée au Gestionnaire de documents. Suite à cette demande, le Gestionnaire
de documents demande au document sélectionné de s’imprimer lui-même. 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.

Travail à faire
Etablissez un diagramme de séquences représentant le processus d’impression d’un document à
l’aide des classes et méthodes de la figure qui suit.

37
38
TD Diagrammes de modélisation de la dynamique

1. Guichet automatique de banque - diagramme d’activités et d’états


Modéliser le retrait d’argent dans un guichet automatique de banque (GAB). La carte peut être
invalide (ex : date d’expiration dépassée) et elle est refusée. Si elle est valide, le client doit taper
son code. La carte est avalée après trois essais infructueux. Le système d’autorisation VISA
autorise un certain montant ou refuse tout retrait. Une carte non récupérée après quelques
secondes est avalée. Les billets non récupérés par le client sont repris. Un ticket est toujours
imprimé pendant que les billets sont proposés.
Travail à faire
a) Modéliser avec un diagramme d’activités la dynamique de ce système.
b) Modéliser avec un diagramme d’états l’évolution de la carte de crédit dans le GAB.
2. Gestion de la formation - diagramme d’activités et d’états
On reprend l’énoncé de la gestion de la formation pour lequel on a déjà construit les cas
d’utilisation.
Travail à faire
a) Modéliser avec un diagramme d’activités la dynamique de ce système.
b) Modéliser avec un diagramme d’états l’évolution d’une demande de formation.
3. Ornithologie
On reprend l’énoncé pour lequel on a déjà construit les cas d’utilisation.
Travail à 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 léger)
définie de la manière suivante. Le thread est :
- « non démarré » au début,
- « en cours » lorsqu’il possède toutes ses ressources applicatives plus le processeur,
- « en attente » lorsqu’il lui manque une ressource applicative,
- « prêt » lorsqu’il a toutes ses ressources applicatives et pas le processeur,
- « terminé » lorsqu’il a terminé son exécution.
On supposera qu’un thread n’envoie pas d’événement. Il ne fait que les recevoir. On supposera
que les événements reçus par le thread sont : « début », « ressource attendue », « ressource OK
», « processeur OK », « fin » :
- « début » correspond au démarrage du thread (start en java, execlv en Unix, …). Avant la
réception de « début », le thread est « non démarré ».
- « ressource attendue » correspond à l’indication qu’une ressource applicative attendue n’est
pas disponible.
- « ressource OK » correspond à la libération d’une ressource applicative par un autre thread et
donc à la réservation effective de la ressource par le thread qui l’attendait.
- « processeur OK » correspond à la libération du processeur par un autre thread et à l’utilisation
effective du processeur par le thread qui l’attendait.
- « fin » correspond soit à l’exécution de la dernière instruction du programme exécuté par le
thread soit à l’envoi d’un événement pour tuer définitivement le thread. Sur réception de « fin »,
le thread devient « terminé ».

5. Photocopieur
Un dispositif de contrôle d'accès par carte magnétique à un photocopieur est équipé d'un écran de
visualisation qui peut afficher les messages suivants :
– "INSEREZ VOTRE CARTE" lorsque le dispositif est inutilisé,
– "PATIENTER" pendant que le dispositif lit le code d'une carte introduite,

39
– "CARTE INVALIDE" lorsque le code n'est pas reconnu (illisible) ; la carte est alors
automatiquement éjectée,
– "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 éjectée,
– "UTILISATION EN COURS" lorsque le code composé est correct.
L'utilisateur peut à tout moment actionner un bouton qui provoque l'éjection de la carte. Après
toute éjection de carte, le dispositif affiche "INSERER CARTE".
Travail à faire
Proposez le diagramme d’états du lecteur de carte. Les états correspondent aux différents
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 déclenché la transition
(notation : action utilisateur/action dispositif une des deux actions pouvant être absente).

6. Windows
Pour éteindre un PC sous Windows, l’utilisateur clique sur le bouton « démarrer » puis sur le
bouton « arrêter l’ordinateur » du menu démarrer. Le système affiche une fenêtre de dialogue avec
trois options : « mettre en veille », « arrêter », « redémarrer » et un bouton « annuler ».
Si l’utilisateur choisit « mettre en veille », le système se met en pause et l’appui d’une touche le
réactive et le remet dans son état initial.
Si l’utilisateur choisit « arrêter », le système installe les éventuelles mises à jour système en
affichant une fenêtre montrant l’avancement des installations. A la fin de ces installations le PC
s’éteint.
Si l’utilisateur choisit « redémarrer », le système réalise la procédure d’arrêt presque jusqu’à la fin
(sans installer de mises à jour) et relance le bios et Windows pour revenir à l’état initial.
Donner le diagramme d’états qui décrit ce mode de fonctionnement.

40
TD Classes vers relationnel
Exercice 1
Traduire le diagramme de classes UML suivant en relationnel.

Exercice 2
Traduire le diagramme de classes UML suivant en modèle logique relationnel.

Transaction Client
NoTrans NoClient
0..* < émet 1
Libellé Nom
Montant Adresse

0..* 0..* 1..* 1


concerne > < estTitulaire
traite ^
possède v

1 1 Compte
1..* 0..1
NoCompte
Agence Solde 1 0..* CarteBleue
1 1..*
NoAgence
gère > NoCarte
Localisation
< moyen Paiement

CompteDépôt CompteEpargne

Autorisation Plafond

Exercice 3
Soit le schéma de classes ci-dessous.
a) D’après ce schéma, un lot peut-il contenir un lot ?
b) Traduisez ce schéma en relationnel avec la stratégie qui consiste à associer une table par
classe de l’arbre d’héritage,
c) Même question avec la stratégie qui consiste à associer une seule table à tout l’arbre d’héritage.

41
Exercice 4
Soit le schéma de classes ci-dessous.
a) Traduisez ce schéma en relationnel avec la stratégie qui consiste à associer une table par
classe de l’arbre d’héritage,
b) Même question, avec la stratégie qui consiste à associer une seule table à tout l’arbre
d’héritage.

Exercice 5
a) Modéliser le système de fichiers décrit ci-après à l'aide d'un diagramme de classes.
Le système 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 possède (‘owner’). Chaque utilisateur peut lire certains fichiers.
b) Traduire ce schéma de classes en relationnel.

42
Etude de cas UML
Un serveur de réunions virtuelles sur Internet

1. Présentation
Il s'agit d’adapter le concept de messagerie instantanée à un contexte de réunions de travail au
sein d'une entreprise ayant de multiples implantations géographiques.
Le but de l’étude est d’analyser la partie serveur d’une application client-serveur permettant de
faire des réunions de travail virtuelles sur Internet.

Serveur de
Client
l’application BD

Client

L'application cherche à imiter le déroulement des réunions de travail classiques. Les réunions sont
planifiées à l’avance. A la date fixée, les participants se connectent, entrent dans la réunion et
peuvent échanger des messages en mode texte. Le serveur doit permettre de planifier et de gérer
le déroulement de plusieurs réunions simultanées.

Une fois connecté (à l'aide d'un nom de login et d'un mot de passe spécifique à l’application et
mémorisé sur le serveur), un utilisateur a la possibilité de :
• planifier des réunions virtuelles (choix de son nom, description de son sujet, date de début,
durée prévue, description de son ordre du jour, type et éventuellement participants
autorisés) dont il devient l’organisateur,
• consulter les descriptions des réunions planifiées (tous les utilisateurs peuvent consulter
toutes les descriptions),
• modifier ces descriptions (seul l’organisateur peut modifier la description d’une réunion),
• ouvrir et clôturer une réunion (l'animateur de la réunion quand il existe ou à défaut son
organisateur – cf. ci-après les différents types de réunions),
• entrer virtuellement dans une réunion précédemment ouverte (tous les utilisateurs ou
seulement les participants autorisés si c’est une réunion privée),
• en sortir.

En cours de réunion, un participant doit demander à prendre la parole. Quand elle lui est accordée
(cf. ci-après les différents types de réunion), il peut entrer le texte d'un (ou plusieurs) message(s)
qui est (sont) transmis en « temps-réel » par le serveur à tous les participants de la réunion. Le
participant doit rendre la parole quand il a fini de s’exprimer. Il peut aussi annuler une demande de
prise de parole.

Les messages sont stockés avec un n° d’ordre attrib ué par le serveur, la date et heure de
réception et le nom de l’auteur du message. Cela permet aux retardataires de recevoir l’ensemble
des messages déjà échangés dans la réunion.

Plusieurs types de réunions peuvent être organisés :


• des réunions « standards », avec un organisateur qui se charge de la planification de la
réunion et désigne un animateur (éventuellement lui-même) chargé de choisir les

43
intervenants successifs parmi ceux qui ont demandé la parole ; tout utilisateur peut
participer (ce sont des réunions publiques) ;
• des réunions « privées », qui sont des réunions « standards » dont l'entrée est réservée à
un groupe de participants particulier autorisé par l'organisateur ;
• des réunions « démocratiques », qui sont planifiées comme des réunions 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 (FIFO). La réunion est ouverte et fermée par l’organisateur.

L’administrateur du système 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. Travail à faire
1) Cas d’utilisations
a) Etablir le diagramme des cas d’utilisation du système.
b) Associer une courte description textuelle à chaque cas d’utilisation (quoi ? qui ? quand ?).
c) Ecrire un scenario global d’utilisation du système : au minimum, création de quelques
utilisateurs et d’une réunion de chaque type avec quelques échanges de messages. Ce
scénario peut aider à comprendre le problème. Il pourra également être utilisé pour tester le
système quand il aura été développé.
Conseils
• L’héritage entre acteurs signifie que l’acteur qui hérite peut faire tout ce que l’acteur dont il
hérite peut faire. Cela simplifie le dessin du diagramme des cas mais n’a aucun impact sur
le programme qui sera réalisé.
• Les cas d’utilisation doivent correspondre à des fonctionnalités significatives du point de
vue des utilisateurs du système.
• Les relations « extends » et « include » entre cas ne doivent pas servir à décrire des
enchaînements d’actions élémentaires (ce sera le rôle des diagrammes d’activités).

2) Diagramme de classes initial


A partir de l’énoncé, proposer un diagramme de classes initial centré sur les utilisateurs et les
réunions, avec les principales associations et relations d’héritage entre ces concepts et les
attributs essentiels. Les méthodes seront ajoutées ultérieurement.
Conseils
• Dans la majorité des langages les objets possèdent un type et ne peuvent en changer
(typage statique). Quand un objet d’une classe dérivée est créé il prend ce type en héritant
de toutes les propriétés de la classe dont il dérive. Si on veut représenter quelque chose de
plus dynamique, qui évolue dans le temps, l’héritage ne convient pas.

3) Diagrammes de séquences
Expliciter les cas suivants par des diagrammes de séquences : se connecter au serveur, planifier
une réunion virtuelle, ouvrir une réunion virtuelle.
Ces diagrammes doivent montrer toutes les classes qui participent (c'est-à-dire qui hébergent des
traitements, qui sont créées, qui sont interrogées…) avec les messages qui circulent vers et
depuis ces classes. L’objectif est de trouver éventuellement de nouvelles classes et surtout les
méthodes utiles à la réalisation des cas.
Conseils

44
• A l’origine de chaque cas on a un acteur qui envoie un message contenant des chaînes de
caractères (la partie cliente de l’application n’est pas étudiée et pas représentée).
• Le message envoyé par l’acteur doit arriver à une classe bien définie qu’il faut introduire
dans le diagramme de séquences (quand on écrira l’application cliente il faudra appeler
cette classe particulière). Cette classe correspond à une « Façade » (cf. le patron de
conception « Façade » en annexe).

4) Diagrammes d’états
Donner les diagrammes d’états des classes utilisateur et réunion.
Conseils
• On cherche à représenter les états communs à tous les utilisateurs et tous les types de
réunions.
• On pourra utiliser des états imbriqués si nécessaire.
• L’objectif est de trouver de nouvelles propriétés (attributs et méthodes) utiles.

5) Diagramme de classes final


A partir des résultats précédents et de l’énoncé, enrichir le diagramme de classes avec les
classes, les associations, les attributs et méthodes jusqu’à ce qu’il apparaisse « raisonnablement
complet » pour cette phase initiale d’analyse.
Conseils
• Essayer d’utiliser toutes les possibilités de la notation objet UML (héritage, agrégation,
associations, multiplicités…).

Un dossier d’analyse doit être rendu qui réponde à ces questions. Les schémas seront réalisés à
l’aide de WinDesign. Les schémas devront être accompagnés d’explications à chaque fois que des
choix non évidents auront été effectués.

45
Annexe : les patrons de conception « façade » et « singleton »

Façade
Une classe « façade » constitue un point d’entrée unique pour accéder à un sous-système. La
façade est unidirectionnelle : de l'extérieur (les modules utilisant le sous système) vers l'intérieur.
Elle peut se charger de créer certains composants.

Singleton
Comme la classe Façade 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 méthode de classe
getInstance() qui crée l’instance si elle n’existe pas (via un constructeur privé) ou la retourne si elle
existe déjà.
Cela garantit l’unicité de l’instance.
De plus, Facade.getInstance() peut être appelé à tout endroit, sans avoir à passer l’objet façade en
paramètre des méthodes.

- : méthode ou attribut privé


soulignement : méthode ou attribut de classe

46