Modèles d’usage

Use cases
Le client présente son système d'un point de vue fonctionnel.

Les Use Cases vont permettrent de reformuler les besoins et constituent un moyen
de communication très efficace entre utilisateurs et équipes de développement.

Un Use Case décrit le système du point de vue de son utilisation, c'est-à-dire :

• Les interactions entre le système et les acteurs
• Les réactions du système aux événements externes
• Il permet de développer un système "orienté utilisateur".

Approche Approche
fonctionnelle objet

UC4
UC3

UC1 UC2

A partir du cahier des charges, la première étape de conceptualisation consiste à:

identifier les acteurs

identifier les événements

identifier les Use Cases.

http://www.ista.ma OBJET - Les méthodes Page : 27

 Acteurs
Un acteur est une entité externe agissant sur le système.
Il peut s’agir :

d’un utilisateur humain

d’une machine

d’un autre système ou sous-système

L'acteur peut consulter et/ou modifier l'état du système.

Le système répond à l'acteur en lui fournissant des informations, et le prévient

éventuellement des changements d'état.

L'acteur doit être défini à travers le rôle qu'il joue par rapport au système.

Différentes entités peuvent utiliser le système de la même façon (un rôle
unique).

Une même entité peut utiliser le système de diverses façons (plusieurs rôles).

Notation :

<< acteur >>

Client

Client

http://www.ista.ma OBJET - Les méthodes Page : 28

 Typologie des acteurs
Du point de vue du système, il existe deux types d’acteurs :

les acteurs primaires, qui utilisent le système

les acteurs secondaires, qui administrent le système.

Par exemple, pour une application bancaire, on peut imaginer les guichetiers qui
enregistrent les opérations courantes et le directeur de l’agence qui établit le bilan
de l’agence.
Pour effectuer un change de devise, il faut connaître le cours de la devise.
Il faut donc qu’un acteur secondaire soit capable de fournir ces informations.
Cet acteur peut être représenté par une personne chargée de la saisie des cours
journaliers ou par une application du système central qui fournit les informations
nécessaires.

Guichetier Application bancaire

Responsable
des devises
Directeur

Selon la taille de l’agence, un individu (salarié d’une banque) peut jouer plusieurs
rôles (guichetier, responsable de devises) et plusieurs individus peuvent jouer le
même rôle.

En conclusion, un acteur correspond à un rôle vis-à-vis du système.

http://www.ista.ma OBJET - Les méthodes Page : 29

Evénement – diagramme de contexte
Pour identifier précisément les événements, il faut en premier lieu déterminer la
frontière du système.

Le diagramme de contexte montre les échanges entre le système et les acteurs.

Acteur 1 Acteur 2

Système

Acteur 3

Les événements externes ( ) sont envoyés des acteurs vers le système.

Ils vont permettre d’identifier les use cases.

Le diagramme de contexte n'existe pas dans UML bien qu'il soit très utile.
Il emprunte le même formalisme qu'un diagramme de collaboration.

OBJET - Les méthodes Page : 30

Le diagramme de Use Cases
L'exécution du Use case est contrôlée par des événements externes envoyés au
système par les acteurs.

L'ensemble des Use Cases décrit les exigences fonctionnelles du système.

Application bancaire (système)

Saisie cours
Retrait euros devise

Responsable
Guichetier Retrait devises des devises

emprunt

bilan

Système
Directeur central

Cette représentation permet de voir de façon simple :

les différents acteurs

comment est délimité le système

les fonctionnalités demandées au système

les rôles des différents acteurs vis-à-vis du système.

OBJET - Les méthodes Page : 31

Organiser les uses cases au sein d’un système
La généralisation
Considérons les use cases « retrait francs » et retrait devises ».
Nous pouvons imaginer un use case « retrait » qui décrit les fonctions
communes dont héritent les use cases « retrait francs » et « retrait devises ».

Retrait
francs

retrait

Retrait
devises

Elle indique que le use case fils : « retrait devises » hérite de toutes les
caractéristiques du use case père : « retrait ».
Le use case « retrait devises » est une spécialisation du use case « retrait ».

La relation « include »
Elle indique que le use case qui est pointé par la flèche est une sous-partie
de l’autre.
Retrait
emprunt francs Retrait devises

« include » « include » « include »

Saisie N° compte

La relation « include » permet de :

factoriser des use cases correspondant à des fonctionnalités importantes
qui servent fréquemment

expliciter la constitution d’un use case complexe en le décomposant en
plusieurs use cases.

La relation « extends »
Permet de faire l’insertion optionnelle d’un comportement dans un use case
étranger. Est souvent utilisé pour décrire une alternative dans un scénario.

«extends »
Création commande Création client

OBJET - Les méthodes Page : 32

Description d’un Use Case
Un use case est une séquence d'actions réalisées par le système produisant un
résultat observable à un acteur particulier.
Sa description doit être synthétique et facilement compréhensible.

Un use case peut être décrit de différentes façons :

Une description textuelle

Use case « retrait »

Le guichetier saisit le numéro de compte du client

L’application valide le compte auprès du système central
L’application demande le type d’opération au guichetier
Le guichetier sélectionne un retrait d’espèces
Le système « guichet » interroge le système central pour s’assurer que le
compte est suffisamment approvisionné
Le système central effectue le débit du compte
Le système notifie au guichetier qu’il peut délivrer le montant demandé.

Un diagramme de séquence

Guichetier Système guichet Système central

Saisie compte
Validation compte
Demande type d’opération

Retrait d’espèces
Vérification provision
débit

Autorisation délivrance
temps

OBJET - Les méthodes Page : 33

Un diagramme de collaboration

6 Débit compte

Guichetier 4 Retrait d’espèces Système central

5 Vérification
3 Demande type provision
d’opération
7 Autorisation
délivrance
2 Validation compte

1 Saisie compte Système guichet

Là, les interactions sont représentées par des flèches, mais la chronologie par des
numéros. Cette notation devient vite difficile à lire pour les use cases qui
nécessitent beaucoup d’interactions. Par contre, elle met en évidence les acteurs
dont le rôle est important.

Les use cases entre la machine et les acteurs humains utilisent un interface
graphique. Ceux-ci peuvent être décrit assez finement par la succession d’écrans
annotés qui indiquent les options et les informations que doit renseigner
l’utilisateur pour un cas d’utilisation donné.

OBJET - Les méthodes Page : 34

Exercice

La médiathèque – use cases

Voir énoncé.

1. Déterminer les acteurs

2. Déterminer les use cases
3. Elaborer un diagramme de use cases en essayant de trouver un
exemple de relation « uses » et « extends ».

OBJET - Les méthodes Page : 35

 Modèles dynamiques

Permettent de comprendre et de décrire le comportement des objets et leurs

interactions.

Servent à définir ou à préciser les opérations.

Deux types de représentations :

dynamique entre objets avec les deux diagrammes d’interaction :
diagramme de séquence
diagramme de collaboration
dynamique interne à un objet avec le diagramme d’états-transitions.

Diagramme de séquence
Met en avant l’aspect temporel des interactions. Le temps s'incrémente du haut
vers le bas de la figure, mais les espaces ne sont pas significatifs; seules les
séquences d'événement sont représentées, non le temps qui les sépare.
Chaque objet concerné est représenté par une ligne verticale.

Appelant Ligne Appelé

décrocher
a
{b-a < 1 sec}
tonalité
b
{c-b < 10 sec}
Taper chiffre
c

d
routage
{d’-d < 5 sec}
d’

sonner sonner

décrocher

Arrêt sonnerie Arrêt sonnerie

OBJET - Les méthodes Page : 36

Diagramme de séquence – notations complémentaires:

Les stimulus inter-processus, ceux qui franchissent la frontière du système, sont

plutôt appelés des signaux.
Les autres stimulus intra-processus sont appelés les messages.

Interface Objet 1 : Objet 3 :

Frontière
Acteur Classe1 Classe3
du système
commenceSession
(nom, pass)
vérifieMotPasse
(pass)
Objet 2 :
^MotPasseOk Classe2

créé
ajouteSession

ouvreSession

Retour de
message

fermeSession

temps Message sur

l’objet lui-
même
Bloc Destruction
d’opération De l’objet

Les retours de messages ( ^ ) ne sont indiqués que s’ils augmentent la

compréhension du modèle.
Dans UML version 1 la tête de flèche est différente ( ).

Les rectangles sur les barres verticales sont des blocs d'opérations qui montrent
les périodes d’activité des objets.

OBJET - Les méthodes Page : 37

Utilisation des diagrammes de séquence - les scénarios - démarche
Dans UML, l’élaboration de la liste des scénarios est une activité importante de
l’analyse.

On peut proposer un début de démarche :

1. définir et décrire les cas d’utilisation : forme textuelle
2. pour chaque cas d’utilisation, choisir les scénarios
3. construire les diagrammes d’interaction pour chaque scénario.

Un scénario est une série d’événements ordonnés dans le temps, simulant une
exécution particulière du système.

Exemples de scénarios
Ce premier scénario décrit le recrutement d’un développeur C++ par la société
Objet SA qui s’adresse à l’ANPE.

Durant : Objet SA : ANPE

Personne Société

Demande développeur C++

Proposition

Demande d’entrevue

Convocation

Entrevue

Bilan
Attribution du poste

Notification d’embauche

Remarque : A priori on construit le scénario de base sans tenir compte des

exceptions (erreurs, absence de réponse quand le temps prévu est dépassé).

OBJET - Les méthodes Page : 38

Ce deuxième scénario décrit le recrutement d’un consultant objet par la société
OOsoft qui s’adresse au cabinet « Conseil Recrutement ».

Dupont : OOsoft : ConseilRecrut

Personne Société

Propose poste consultant objet

Proposition CV Dupont pour ce poste

Convocation

Entrevue

Bilan
Embauche

Notification d’embauche

Ce scénario peut aussi se représenter sous la forme d’un diagramme de

collaboration.

Dupont: Conseil recrutement:

Personne CabinetRecrutement

Convoquer ProposerPoste

4 3 1 2

PasserEntrevue ProposerCVCandidats

7 NotifierEmbauche
Embaucher 6
Oosoft:Sociéte
5 EffectuerBilan

Les messages qui se déroulent de façon séquentielle sont numérotés.

OBJET - Les méthodes Page : 39

Diagramme de collaboration
Il représente du point de vue statique et dynamique les objets impliqués dans la
mise en place d’une fonction applicative.

Sa granularité est plus ou moins fine, selon qu’il décrit un ensemble d’opérations
utilisées dans l’exécution d’une fonction ou une opération plus simple.

Deux notions fondamentales sont utilisées dans un diagramme de collaboration.

• Le contexte : c’est une vue statique partielle des objets qui collaborent pour
réaliser une fonction.. Il correspond donc à une partie du modèle objet.
• Les interactions : ce sont des séquences de messages échangés par les
objets dans le cadre de la réalisation d’une opération.

Dupont: estCandidat
Conseil Recrut:
Personne CabinetRecrutement

Convoquer(unPoste) ProposerPoste
(unPoste)

4 3 1 2

PasserEntrevue() ProposerCandidats
signer (desCandidats,unPoste)

signer estClient
New
Ct1:ContratTravail OOsoft:Sociéte
6 7

Embaucher(unPoste) EffectuerBilan() 5 NotifierEmbauche(unPoste)

Ce diagramme est souvent « chargé » en notations et parfois moins lisible que les
scénarios.
Pourtant, s’il n'est guère utile durant la phase d'analyse, il le devient
particulièrement lors de la phase de conception. car il permet de faire le lien entre
le modèle objet et le modèle dynamique.

OBJET - Les méthodes Page : 40

Exercice

Paiement au restaurant

Elaborer un diagramme de séquence décrivant le paiement d’un repas au

restaurant par carte de crédit.

Les objets considérés seront le client, le serveur et un terminal portable.

Moi :Client Firmin :Serveur :Terminal

Hep ! l’addition !

Voilà ! (montant)

Carte de crédit
Introduire carte
Vérifier
carte
Demander montant

Saisir montant

Demander code

Saisir code
Vérifier
code
Imprimer ticket

Retirer carte
Merci ! (carte, ticket)

Au revoir (pourboire)

OBJET - Les méthodes Page : 41

Diagramme d’Etat transition (ou STD: State Transition Diagram)
Source : les Statecharts de David HAREL.

Diagramme d'état:
un diagramme d’état décrit l’évolution au cours du temps d’un objet (instance
d’une classe) en réponse aux interactions avec d’autres objets ou acteurs.

Il décrit le cycle de vie des objets d'une seule classe .

On établit un diagramme d'état pour chaque classe qui a un comportement
dynamique significatif, ce qui signifie que toutes les classes n’en ont pas besoin.

Un diagramme d'état est un graphe dont les nœuds sont des états et les arcs
orientés des transitions portant des paramètres et des noms d'événements.

Notation de base :

Etat initial Etat final

Evénement condition

Naissance Décès

Anniversaire (âge) [âge=18]

Mineur Majeur

Etat transition

OBJET - Les méthodes Page : 42

Etat:
un état spécifie la réponse de l'objet aux événements d'entrée. Il est stable.
Il peut être caractérisé par un ensemble de valeurs d'attributs et de liens d'un objet.
Il correspond à l'intervalle de temps entre deux événements reçu par l'objet.

Transition :
Relation entre deux états indiquant qu’un objet dans le premier état va passer dans
le deuxième quand un événement particulier apparaîtra, et que certaines conditions
seront satisfaites.

Evénement:
un événement est un stimulus pouvant transporter des informations (sous forme de
paramètres). Il est considéré comme n'ayant pas de durée.
Un événement peut être émis par un objet du système ou par un objet externe au
système. Il peut également provenir de l’interface du système, par exemple un clic
de souris. Quelle que soit son origine, un événement peut être soit dirigé vers un
ou plusieurs objets, soit émis sans destination précise dans le système, certains
objets du système pouvant alors le capter.
La réponse d’un objet à un événement dépend de l'état dans lequel il se trouve
autant que de l'événement.
Remarque : la plupart des ouvrages et des outils de modélisation objet emploie les
termes événement et message indifféremment. En UML, un message est un
événement particulier, issu de l’interaction entre deux objets (un objet appelle une
méthode d’un autre objet). Tout événement n’est donc pas forcément un message.

Etats initial et final :

Chaque automate de classe doit préciser un état initial (état d’une instance juste
après sa création).
On peut également préciser les condition de destruction en ajoutant un état final.

(création)
(néant) Etat initial

Evénement y
Etat X (état final)

OBJET - Les méthodes Page : 43

Condition :
une condition est une expression booléenne, attachée à un événement, qui doit être
vraie pour le déclenchement de la transition.
Elle est indiquée entre crochets à la suite du nom de l'événement.

Refroidissement [temp < temp référence]

Chauffage Chauffage
à l'arrêt en marche
Réchauffement [temp > temp référence]

Action :
une action est une opération instantanée. Elle est associée à un événement.
Elle représente une opération dont la durée est insignifiante comparée à la
résolution (niveau de définition) du diagramme d'état.
La notation d'une action sur une transition est précédée d’une barre oblique ("/").

Bouton droit activé / afficher menu déroulant

En attente Menu
visible
Bouton droit non activé / effacer menu

Curseur bougé / item de menu en surbrillance

Activité :
une activité est une opération qui dure un certain temps.
Elle est associée à un état. Elle peut être continue ou finie (se termine d’elle
même).
Notation : "Do : activité".

Retrait [solde - retrait < 0]

Compte Compte débiteur
créditeur Do: CalculAgio
Dépôt [solde + dépôt > 0]

OBJET - Les méthodes Page : 44

Les diagrammes d'états peuvent s'exécuter en une seule fois ou en boucle
continue.

Les diagrammes "une seule fois" (one-shot diagrams) représentent les objets qui
ont une vie finie.

Un diagramme "une seule fois" possède un état initial et un état final..

L'état initial est entré à la création de l'objet; l'entrée dans l'état final (qui peut
éventuellement prendre plusieurs conditions) implique, elle, la destruction de
l'objet.

Echec et mat
Tour Noir gagne
Début
des blancs
pat
noir blanc
bouge bouge Partie nulle
pat
Tour
des noirs Echec et mat Blanc gagne

OBJET - Les méthodes Page : 45

Diagramme en boucle continue :
Ce diagramme qui décrit le comportement d'une ligne téléphonique, est une boucle
continue. On ne se soucie pas de savoir comment la boucle a démarré.

Combiné raccroché En attente Combiné raccroché

En tonalité Fin de délai En délai dépassé

faire: jouer tonalité faire: jouer bip fort

Fin de délai
Chiffre tapé
En numérotation Message enregistré
Faux numéro faire: jouer message

Bon numéro
Message fini
En connexion
faire: trouver connexion
Numéro occupé
Acheminé

Sonnant Tonalité: "occupé"

faire: sonner faire: tonalité occupé

Appelé répond / connecter ligne

Connecté

Appelé raccroche / déconnecter ligne

Deconnecté Fin de délai

L'événement "Combiné raccroché" provoque une transition de n'importe quel état

vers l'état "En attente".
Noter que les états ne définissent pas toutes les valeurs d'un objet; par exemple,
l'état "En numérotation" inclut toutes les séquences de numéros incomplets.
Ce n'est pas la peine de les différencier puisqu'ils ont tous le même comportement.

OBJET - Les méthodes Page : 46

Exercice

La montre
Bouton mode

22 :15 :35
Bouton avance

En fonctionnement normal, la montre affiche les heures, les minutes et les

secondes qui défilent.
Une pression sur le bouton mode sélectionne le chiffre des heures qui se met
à clignoter. A ce moment une pression sur le bouton avance incrémente le
compteur d’une heure.
Une nouvelle pression sur le bouton mode sélectionne le chiffre des minutes
qui se met à clignoter. A ce moment une pression sur le bouton avance
incrémente le compteur d’une minute.
Une nouvelle pression sur le bouton mode revient à l’affichage normal.

1) Dessiner le diagramme état-transition de cette montre.

2) On veut modifier le comportement de la montre pour que si on maintient

la pression sur le bouton avance au moins deux secondes, l’avancement des
heures ou des minutes se fasse en continu.

OBJET - Les méthodes Page : 47

Complément sur les actions

En entrée :
L’action est exécutée chaque fois que l’on entre dans l’état.
Notation : entry / action

En sortie :
L’action est exécutée chaque fois que l’on quitte l’état.
Notation : exit / action

Action interne :
L’action est exécutée suite à un événement sans qu’il y ait de changement d’état.
Notation : événement / action

Notation complète et ordonnancement :

Etat x
Evt 1 [cond 1] / action 1 Entry / action 2 Evt 6 [cond 6] / action 6
Do : activité 3

Evénement / action 4
…
Exit / action5

Ordre temporel d’exécution :

En entrée :
• Action sur la transition d’entrée (action 1)
• Action d’entrée (action 2)
• Activité (activité 3)

Dans l’état :
• Interruption de l’activité (activité 3)
• Exécution de l’action interne (action 4)
• Reprise de l’activité (activité 3)

En sortie :
• Arrêt de l’activité (activité 3)
• Action de sortie (action 5)
• Action sur la transition de sortie (action 6).

OBJET - Les méthodes Page : 48

Diagrammes d'états hiérarchiques ou imbriqués
Dans le cas d’un comportement dynamique complexe, les diagrammes d’états sur
un niveau deviennent rapidement illisibles.
Pour éviter ce problème, il est nécessaire de structurer les diagrammes d'états.
Cela permet à une activité liée à un état, d'être décomposée hiérarchiquement en
sous-activités.

Pièces insérées
En attente Encaissement
Annuler / rendre la monnaie d'argent

Choisir
article [Article vide] [MT insuffisant]

Do: tester article et calculer la monnaie

[MT OK] [monnaie>0]

Do : distribuer article Do : rendre monnaie

L'activité "distribuer article" est décrite dans ce sous-diagramme :

Do: placer Bras prêt Do : placer Bras prêt Do : faire poussé

le bras à la le bras à la tomber l'article
bonne rangée bonne colonne de l'étagère

Les événements peuvent aussi être étendus dans des diagrammes d'états
subordonnés. L'événement "choisir article" implique en fait plusieurs événements
de plus bas niveau :

Do : Taper un chiffre Do: validation

réinitialiser ajouter
l'article chiffre
annuler

Taper un chiffre

OBJET - Les méthodes Page : 49

Généralisation d'états

On l’utilise généralement pour réduire la complexité de la représentation :

Passer M.Arrière Marche

Point mort arrière
Passer P.M.

Passer M.Avant
Passer P.M. Passer P.M. Passer P.M.

Rapport sup. Rapport sup.

Première Deuxième Troisième
Rapport inf. Rapport inf.

… en construisant un diagramme d'états imbriqué :

Passer M.Arrière
Marche
Point mort arrière
Passer P.M.

Passer P.M. Passer M.Avant

Marche avant
Rapport sup. Rapport sup.
Première Deuxième Troisième

Rapport inf. Rapport inf.

La généralisation exprime la "relation-ou". Ici, dans l’état MarcheAvant, la

transmission se trouve dans le sous-état Première ou Deuxième ou Troisième.

Remarque : on peut repasser au point mort depuis n’importe quel sous-état, mais
on entre toujours dans l’état MarcheAvant en première.

OBJET - Les méthodes Page : 50

Exemple de la ligne téléphonique

La généralisation permet de représenter plus simplement les différents états de

l’objet étudié, sans surcharger le diagramme avec tous les retours vers un état final
depuis n’importe quel état de l’objet.
Cette situation est très fréquente.

En attente

Décrochage Combiné raccroché

En tonalité Fin de délai En délai dépassé

Do : jouer tonalité Do : jouer bip fort

Fin de délai
Chiffre tapé
En numérotation Message enregistré
Faux numéro Do : jouer message

Bon numéro
Message fini
En connexion
Do: trouver connexion
Numéro occupé
Acheminé

Sonnant Tonalité: "occupé"

Do: sonner Do: tonalité occupé

Appelé répond / connecter ligne

Connecté

Appelé raccroche / déconnecter ligne

Deconnecté Fin de délai

OBJET - Les méthodes Page : 51

Sous-états parallèles

Plusieurs sous-diagrammes d’états peuvent intervenir en parallèle dans un même

état. Ils sont alors :

Soit en concurrence : le premier sous-diagramme permettant de faire la transition

de l’état englobant vers un autre état, interrompt les autres sous-diagrammes et fait
quitter l’état englobant.

Etat 1 (englobant)

Do : A1 Do : A2

ou Etat 2

Do : A3 Do : A4

Soit en synchronisation : la transition de l’état englobant vers un autre état n’est

effectuée que lorsque tous les sous-diagrammes le permettent, aucun sous-
diagramme ne pouvant être interrompu.

Etat 1 (englobant)

Do : A1 Do : A2

et Etat 2

Do : A3 Do : A4

OBJET - Les méthodes Page : 52

Diagrammes d'activité
Ce sont des cas particuliers de diagramme d’état dans lesquels les états
représentent des activités, et les transitions des transitions automatiques.

Il sont plutôt rattachés à une opération ou un Use Cases qu’à une classe.
Utilisés pour décrire l’algorithmique d’une opération : séquences d’étapes, avec
représentation de décisions et de la synchronisation des flots de contrôles.
Focalisés sur les traitements internes et non pas sur la réception d’événements
externes.

Chercher un café [plus de

jus d’orange]
[il reste du
jus d’orange]

Mettre un filtre Remplir Prendre une tasse

Le réservoir
D’eau
Prendre
Mettre du café un jus d’orange

Allumer la cafetière

Le café passe

Servir

Synchronisation Déguster

OBJET - Les méthodes Page : 53

Responsabilités
Un diagramme d’activité peut être divisé en couloirs verticaux (« swinlanes »)
assignant la responsabilité de certaines activités à des objets particuliers.

Enseignant Etudiant Jury

Enseigner

Apprendre

Contrôler
Les connaissances Composer

Evaluer

OBJET - Les méthodes Page : 54

 Diagramme de composants

Un diagramme de composants décrit des modules et leurs relations dans

l’environnement de réalisation.
Les modules peuvent être de simples fichiers, des paquetages du langage Ada, ou
encore des bibliothèques chargées dynamiquement.
La notation utilise 3 icônes pour désigner respectivement :
• Le programme principal qui correspond à la fonction main du C++
• La spécification qui contient les déclarations ; fichier .h du C++
• Le corps (body) qui correspond au fichier .cpp du C++.

Main spécification body

Les relations, représentée par une flèche pointillée qui pointe de l’utilisateur vers
le fournisseur, montrent les dépendances de compilation ou les dépendances
d’exécution entre les différents modules.

Exemple tiré du livre de Grady Booch

plans

heater climate

cropdefs

cooler
climatedefs

Deux modules, climatedefs et cropdefs ne sont que des spécifications et exportent des
types et des constantes. Les quatre autres sont représentés avec leurs spécifications et leurs corps
groupés car ils sont très liés.
Les dépendances suggèrent un ordre partiel de compilation. Le corps de climate dépend de la
spécification de heater, laquelle dépend de celle de climatedefs.

OBJET - Les méthodes Page : 55

 Diagramme de déploiement (1)

Un diagramme de déploiement montre la disposition physique des différents

matériels (les nœuds) qui entre dans la composition d’un système et la répartition
des programmes exécutables sur ces matériels.

Uranus Routeur IP
Serveur BDD
ORACLE V7
Venus
Serveur exchange << RNIS Internet >>
passerelle internet

Saturne
Stockage
de fichiers << ligne spécialisée 64 Kbps >> IBM
<< ethernet 100Mb >> grand système
MVS

Station Mercure
d’administration Passerelle
SNA

<< Token Ring >> IBM

AS/400

Jupiter
Serveur
logiciels
<< Réseau téléphonique commuté >>

Pluton
Serveur impression
et communication
Elara
Imprimante

Neptune
Serveur BDD
SQL Server

OBJET - Les méthodes Page : 56

 Diagramme de déploiement (2)

Un diagramme de déploiement peut spécifier la répartition des traitements dans

une architecture client-serveur.

Poste Client Serveur de BDD

BDD
Procédures
Pages stockées
WEB d’insertion

Serveur de
Serveur WEB traitement

ODBC
HTML

Objet
métier
ActiveX

OBJET - Les méthodes Page : 57

Synthèse : les 9 diagrammes UML

OBJET - Les méthodes Page : 58

 La démarche UML

UML propose un standard de notation (autour des 9 diagrammes) pour représenter

l’analyse et la conception orientée objet. Ce n’est pas une notation fermée : elle est
générique, extensible et configurable par l’utilisateur. Une grande liberté est
donnée aux outils pour le filtrage et la visualisation d’information.

Il n’y a pas de démarche standard dans UML. On peut cependant en proposer une :

définir et décrire les cas d’utilisations

pour chaque cas d’utilisation, choisir les scénarios

construire les diagrammes d’interaction pour chaque scénarios

élaborer en parallèle le diagrammes de classes.

Cas
d’utilisation

Scénarios

Diagramme Diagrammes
de classes d’interaction

Diagrammes
d’états-transition

OBJET - Les méthodes Page : 59

 Exercice

Téléphone public

Imaginer un téléphone public très simple, à pièces.

Le prix d’une communication est de 2 francs.
Après l’introduction de la monnaie, l’utilisateur a 1 minute pour numéroter.

La ligne peut être libre ou occupée. L’appelé peut raccrocher le premier.

Le téléphone consomme de l’argent dès que l’appelé décroche et à chaque

unité de temps. On peut rajouter des pièces n’importe quand.

Décroché

Pièces / augmenter crédit

décrochage

Raccroché Erreur Numéro invalide

Do :réciter message

Racrochage /
Rendre monnaie
Paiement Numérotation
Do :attendre 2F Do :numéroter
> 1 minute > 1 minute
Numéro
valide

Do :tonalité Numéro occupé

Attente
occupée
ligne

[crédit=0] [crédit>0] Numéro

/ encaisser libre

Conversation Sonnerie
Racrochage Décrochage Do :sonner
de l’appelé de l’appelé
/ encaisser

http://www.ista.ma OBJET - Les méthodes Page : 60