Conception Des SI À Base D'objets

Bilal Hussein
husseinbilal@ul.edu.lb
2017-2018
SOMMAIRE
 Introduction à la conception
objet
 Conception à base de Patrons
 Patrons de création (Creational
design pattern)
 Patrons de structure
 Patrons de comportement
INTRODUCTION A LA
CONCEPTION OBJET
Méthodes de conception
à base:
- Fonctionnelles
- Objet
- Composant
CONCEPTION FONCTIONNELLE
 Décomposition en sous systèmes
 Hiérarchisation et partage de ressources
 Modularité
Structuration de l’application en
modules fonctionnels
 Anciennes méthodes fonctionnelles
(SADT, SASD)
Principe : Séparation des données et
des traitements
 Diagramme de Structure (SD, Yourdon)
Interaction entre les modules.

 Diagramme de flot de données DFD (SA,
Yourdon)
Exemple de diagramme de Structure
entre les modules A, B, C, D, E et F
Exemple d’un diagramme DFD
CONCEPTION OBJET
 Regroupement des données-traitements

 Diminution de l’écart entre monde réel
et représentation informatique
Abstraction
 Localisation des responsabilités
Encapsulation
 Identification des relations entre objets
Association, Généralisation, Composition,

Agrégation, etc.
CONCEPTION OBJET
Méthodes Objet
 OOA (Cood et Yourdon, 90)
 OOD (Booch, 91-93)
 OOM merise (Bouzeghoub, 93)
 OOSE (Jacobson, 94)
 OMT (Rumbaugt, 93)
 Unifié en 1995, UML V0.8

Unified Modeling Language
Première version standardisé par OMG
UML 1.0 en 97
De la version UML 1.2 (1998) à la version
UML 2.5(2013)
CONCEPTION A BASE DE
COMPOSANTS
 Identification des parties

autonomes du système
 Composants réutilisables
 Conception par assemblage
 Architecture 3-tiers
Structuration de l’application
en trois niveaux: Présentation,
Métier et Données
UNIFIED MODELING LANGUAGE
UML
Rappel
Grady Booch
James Rumbaugh
Ivar Jacobson
Le "Langage Unifié de Modélisation" constitue une synthèse des méthodes
Booch, OMT et OOSE.
1.3. DE OMT À UML
UML 1.3
UML 1.1
UML 1.0
UML 0.9
Unified Method 0.8
Other methodsBooch method OMT OOSE

2. MODÉLISATION UML
2.1 VUE D ’ENSEMBLE
State
Use Case State State
Use Case Diagrams
Diagramme State
Diagrammes de Diagrams
Diagrams Diagrams
Diagrammes
Diagrams de Classes Diagrams
cas d’utilisation d’objets
Use Case
Use Case
Diagrams
Diagrammes
Diagrams
de séquence
Scenario State
Scenario State
Diagrams
Diagrammes Modèle Diagrams
Diagramme
Diagrams Diagrams
de collaboration de composan
Scenario
Scenario Component
Diagrams
Diagrammes Diagrammes
Component
Diagrams
Diagrammes
Diagrams Diagrams
d’états-transitions d’activités de déploiement
2.2 LE R.U.P. (RATIONAL UNIFIED PROCESS)
Inception Elaboration Construction Transition
temps
 Inception Définir le cadre du projet
 Elaboration Analyser le domaine, établir une

architecture solide
 Construction Développer le système
 Transition Fournir le système aux utilisateurs
finaux
2.2 LE R.U.P. (RATIONAL UNIFIED PROCESS)
Inception Elaboration Construction Transition
Prelim ... Arch ... Dev Dev ... Trans ...

Iteration Iteration IterationIteration Iteration
Version Version Version Version Version Version Version Version
Une itération est une séquence d’activités planifiée

et validable aboutissant à une version exécutable.
2.2 LE R.U.P. : RELATION PROCESSUS - MODÈLE UML
Exigences Use Case Modèles
Analyse
Analyse
Conception Concept. Dépl.
Implémentation Impl.
Test Test
2.2 LE R.U.P. : RELATION MODÈLE - DIGRAMMES UML
Use Case
Use Case
Classes Objets
Analyse
Composants
ModèlesConcept. Déploiement Diagramme

Séquence
Dépl.
Collaboration
Impl.
Etats-
transitions
Test
Activités
Use Case
Use Case
Classes Objets
Analyse
Composants
Inclus . Sous-sytèmes
et paquetages
ModèlesConcept. Déploiement
Diagramme
Séquence
Dépl.
Collaboration
Impl.
Etats-
transitions
Test
Activités
Use Case
Use Case
Classes Objets
Analyse
Composants
ModèlesConcept. Déploiement
Diagramme
Séquence
Dépl.
Collaboration
Impl.
Etats-
transitions
Test
Activités
Use Case
Use Case
Classes Objets
Analyse
Composants
ModèlesConcept. Les tests font

Déploiement Diagramme
références à tous
les autres modèles Séquence
Dépl.
et les diagrammes
correspondants. Collaboration
Impl.
Etats-
transitions
Test
Activités
2.3 MODÉLISATION CONDUITE À PARTIR DES USE CASES
Exigences Analyse Conception Implémentation Tests
Client Analyste Architecte Programmeur Testeur
Les cas d ’utilisation
Les use cases permettent de communiquer entre différents groupes de personnes

suivant les étapes de la réalisation du projet. Ils sont consultés à tout moment.
2.4 MESSAGERIE
Réalisation d'une messagerie entre plusieurs postes PC Unix interconnectés sur un
réseau
ETHERNET.
Pour pouvoir utiliser la messagerie, il faudra être reconnu par l’application (notion
d’abonné). C'est l'administrateur qui décide de l'inscription d'un abonné.
Chaque abonné après connexion pourra ainsi saisir un message et l'envoyer à

plusieurs autres abonnés. Il pourra consulter les messages qui lui sont destinés. Les
messages lus seront conservés 1 mois maximum, les messages non lus, 1 semaine. Si
un abonné est connecté, il sera prévenu en temps réel de l'arrivée de nouveaux
messages.
L'ensemble des informations d'administration seront centralisées sur un serveur. Tout

abonné devra pouvoir se connecter depuis n'importe quel poste sur le réseau.
2.5 MESSAGERIE
 Représentation des éléments physiques
Envoi Envoi connexion

connexion message
Poste message
Poste
PC Unix Réseau Ethernet PC Unix
Réception Réception
message message
Utilisateur utilisateur
Inscription
abonné
Serveur
{ • Vérification abonné
• stockage messages
• routage messages
administrateur
2.4 MESSAGERIE
Objectifs
Formaliser la phase en amont de l'analyse et donner des

éléments qui
permettront de valider cette analyse.
Définir les acteurs externes et leur interaction avec le système.

Un cas d'utilisation décrit de façon générique et d'un point de vue organisationnel, une
transaction complète impliquant plusieurs objets. Les diagrammes de cas d'utilisation
associés à un haut niveau d'organisation permettent généralement de définir les
limites du système et d'identifier les intervenants extérieurs.
Définir les premiers éléments d’architecture système.

2.4 MESSAGERIE : LES CAS D’UTILISATION
connexion
création abonné
lecture message
suppression abonné
Utilisateur envoi message Administrateu

r
paramétrage
déconnexion
2.5. DIAGRAMME DE USE CASE
DÉFINITION
 Un diagramme de use case

 donne la définition des limites du système
 présente les relations entre des acteurs et des use case
(cas d ’utilisations)
 permet l ’identification des intervenants extérieurs
 est composé d ’un graphe d ’acteurs, d ’un ensemble de
use case, éventuellement d ’interfaces, et des relations
entre ces éléments
 Un use case
 est un ensemble cohérent de fonctionnalités offertes par
le système
 donne les fonctionnalités d ’un système telles que vues
par un intervenant extérieur au système
 Donne lieu à une description textuelle complète
 Un actor (acteur)
 est un ensemble cohérent de rôles que peut avoir un
intervenant extérieur interagissant avec le système
 a un rôle par use case.
REPRÉSENTATION
Use case
Acteur
Confirmer vol
Vérifier planning
Pilot Confirmer Emplo

e réservation yé
RELATION DES ACTEURS
 Relations standards des acteurs
 association : communication entre les instances d ’un
acteur et celles d ’un use case (seule relation entre use
case et acteur)
 généralisation : une généralisation entre un acteur A et
un acteur B indique qu ’une instance de A peut
communiquer avec les mêmes instances de use case que
celles d’une instance de B
1 * Bon de
commande
Vendeur
1 * Ligne de
crédit
Superviseur
RELATIONS DES USE CASE
 Relations standards des use case

 extension : une extension entre le use case A et le use
case B indique qu ’une instance de B peut être étendu
(i.e. sujet à des conditions particulières définies par
l ’extension) par le comportement de A; stéréotype
« extend »
 généralisation : une généralisation de A vers B
indique que A est une spécialisation de B
 inclusion : une inclusion de A vers B indique qu ’une
instance de A inclura aussi le comportement spécifié
par B; stéréotype « include »
RELATIONS DES USE CASE
Informations Produit Mode de

Client commandé Paiement
« include »
« include »
« include »
Prise de commande
1 * « extend »
Extension
commande supplémentaire: le Vendeur veut consulter
après création de commande le Catalogue
Vendeur Catalogue
produits
RELATIONS ENTRE LES CAS D ’UTILISATION
Virement par
minitel
<<extend>>
Le client utilise un Minitel
Virement Client
<<utilise>>
Identification
USE CASE ET SCÉNARII
 Un cas d'utilisation décrit le comportement d’un système,
d’un sous-système, voire d’une classe, du point de vue de
l’utilisateur (au sens large).
 Les diagrammes de cas d'utilisation permettent de définir
les limites du système et d'identifier les intervenants
extérieurs
 Un scénario est une instance de cas d'utilisation qui sert à
décrire les interactions non triviales entre objets. Il décrit
un ensemble d'interactions entre des objets impliqués dans
une réalisation particulière et inconditionnelle (UML
introduit la représentation de conditions) du système
 Un diagramme de séquences représente un scénario en
privilégiant l'aspect temporel des relations entre objets
 Un diagramme de collaboration représente un scénario en
privilégiant l'aspect topologique des relations entre objets.
LES DIAGRAMMES DYNAMIQUES
Rappel : un scénario décrit un ensemble d'interactions entre des objets impliqués
dans une réalisation particulière et inconditionnelle d ’un cas d ’utilisation.
Développer les scénarios (texte), diagramme de trace d'évènements, diagramme

d’interactions entre objets, langage formel (style SDL) :
• ils précisent les cas d'utilisation définis au départ en privilégiant l’aspect
temporel des relations entre objets.
• ils doivent préciser clairement les interactions entre les objets de l'application
et le monde extérieur
• ils doivent également préciser les modes de fonctionnement dégradé et les
conditions aux limites
•on ne considère ici que les événements externes aux objets
• en analyse les événements représentent des messages; leur structure ne sera
précisée qu'en conception
•définir la (les) source(s) et la (les) destinations de chaque événement
•la bonne définition de l’I.H.M peut aider à préciser les évènements
2.6. DIAGRAMMES DE SÉQUENCES
IDENTIFICATION DES OBJETS
 Étapes à réaliser
 Identifier les objets, en déduire les classes
 Décrire un dictionnaire de données contenant les
descriptions des classes, des attributs, des méthodes
évidentes et des associations
 Enrichir, par l'analyse, les associations entre classes
 Ajouter des attributs pour les objets et les liens
 Organiser et simplifier les classes en utilisant
l'héritage
 Tester le modèle en utilisant les scénarios d'analyse
 Répéter les étapes ci-dessus autant de fois que nécessaire

 Grouper les classes en modules réalisant une même
fonctionnalité
DICTIONNAIRE
 Liste des mots utilisés
réseau messagerie Message non lu Prévenir
Poste PC Unix Ethernet Message lu Durée de vie
Abonné Lire message administrateur inscription
connexion Saisir message serveur
…
message Envoyer message utilisateur
Le dictionnaire s’enrichira des éléments de modèles au fur et à mesure de leurs constructions

DICTIONNAIRE :VALIDATION DES CLASSES
 Il faut éliminer :
 les classes redondantes

 les sur-classifications d ’attributs (objets utilisés
uniquement comme valeur)
 les classes représentant une opération
 les classes représentant un rôle (sauf si elles ont des
différences comportementales ou structurelles par
rapport à la classe de départ)
 les classes trop spécifiques (appliquer une généricité
maximale pour permettre une évolution aisée du
système)
 les classes acteurs sauf si l ’état de celui-ci influe sur
le comportement du système
2.6. Diagrammes de séquences
Scénario de connexion de la messagerie
Système
affichage écran de connexion
Utilisateur
nom
mot de passe
affichage écran principal
Connexion réussie d'un utilisateur

lePosteClient
Utilisateur
nom leServeur
mot de passe
demande de connexion(nom,mot de passe)
connexion autorisée

lePosteClient
Utilisateur
nom leServeur
mot de passe l ’abonné

demande de connexion(nom,mot de passe)
Rechercher abonné(nom)
Vérifier mot de passe (mot de passe)

connexion autorisée

DIAGRAMME DE SÉQUENCES
 Aspect temporel des relations entre objets
 Enchaînement des tâches

 Un diagramme de séquences permet de représenter le
séquencement des interactions entre plusieurs objets
impliqués dans une transaction particulière du système
étudié.
 Un événement est une interaction, repérée dans le temps,
entre deux objets. Un événement est assimilé à l'envoi d'un
message par un objet source vers un objet destinataire.
 Le délai d’acheminement d’un message peut être pris en
compte et matérialisé dans la diagramme
NOTATION
 Représentation d ’un appel téléphonique
réussi
appelant:Personne :Central appelé:Personne
décrocher
tonalité
numéro (n)
écho sonnerie sonnerie

Temps
décrocher
arrêt tonalité arrêt sonnerie
Appel téléphonique : appelé non occupé

DÉLAI D'ACHEMINEMENT ET CONTRAINTES TEMPORELLES
 Le délai d'acheminement d'un message peut être

matérialisé en reliant la source et la destination par une
flèche oblique
a décrocher
{ b - a < 10 sec }
tonalité
b
< 10 sec
numéro (n)
Temps
c
routage { d - c < 5 sec }
echo sonnerie d sonnerie
décrocher
arrêt tonnalité arrêt sonnerie
Appel téléphonique appelé non occupé

MATÉRIALISATION DE L’IMPLICATION DES OBJETS
Une variante du diagramme de trace d'événements consiste à modifier alternativement la

représentation d’un objet en fonction de son implication dans une interaction. La période
durant laquelle un objet est impliqué dans une interaction est matérialisée par un double trait.
Un simple trait indique que l'objet n'est impliqué dans aucune interaction et en attente d'un
message
Région
de contrôle
décrocher
tonnalité
numéro (n)
Temps
echo sonnerie sonnerie
décrocher
arrêt tonnalité arrêt sonnerie
Appel téléphonique appelé non occupé

REPRÉSENTATION DES RÉPONSES AUX MESSAGES
L'acheminement d'un message détermine implicitement l'envoi d'une réponse par le

destinataire. Cette réponse n'est en général pas représentée. Elle peut l'être dans le cadre d'une
deuxième variante du diagramme de trace d'événements
leControlleur unSegment origine:Point fin:Point
afficher()
position()
p0
position()
p1
return
2.7. DIAGRAMMES DE COLLABORATION
DÉFINITION
 Aspect topologique des relations entre objets

 Architecture du système
 Coopération entre objets
 Un diagramme de collaboration fournit une représentation synthétique
des interactions entre objets pouvant être mises en œuvre dans le cadre
d'une transaction particulière du système étudié
 Fournit un instantané :
 de l'organisation des liens entre objets avant que la transaction
ne commence,
 des éléments (objets et liens) créés ou détruits au cours de la
transaction.
 Peut être défini sur deux niveaux :
 niveau instances : liens entre les objets
 niveau spécifications : rôles entre classes
 Représenté par une courte flèche :
NIVEAU INSTANCES
 Niveau instances :
Rafraîchir() fenêtre
:Contrôleur :Fenêtre
<<parameter>>fenêtre
1: AfficherCoordonnées(fenêtre) 1.1.3.1 : Ajouter(self)
wire Contenu {new}
<<local>>ligne *
unTrait:Trait new Ligne
1.1* [i=1..n] : AfficherSegment(i) : Ligne {new}
<<self>> 1.1.2 : Créer(r0,r1)
i-1 i 1.1.3 : Afficher(fenêtre)
1.1.1a: r0:=position() 1.1.1b: r1:=position()
Gauche:Point Droit:Point
NIVEAU INSTANCES
 Niveau instances :
serveurs
:Serveur
:Serveur
client
1: unServeur := find(specs)
<<local>>unServeur *
: Serveur
new Ligne
2 : process(request)
NIVEAU SPÉCIFICATIONS
 niveau spécifications
 donne les rôles des classes et des associations
Exemple : collaboration entre le corps enseignant et les étudiants d ’une faculté
Tuteur 1 Élève *
/ Enseignant : Personne / Étudiant : Personne
Membre de la Faculté * Conférencier 1 Participant *
Faculté Cours
Faculté 1 Cours * Cours *
NIVEAU INSTANCES
 niveau instances :
Exemple : collaboration entre le corps enseignant et les étudiants d ’une faculté
étudiantEnseignant()
Tuteur / Enseignant : Personne Conférencier / Enseignant : Personne
1: NomEnseignant()
1.i.1:nom()
1.1*[i:=1..n]:Conférencier()
/ Étudiant : Personne : Cours

2.8 DIAGRAMME DE CLASSES
CHOIX DES OBJETS
- Le choix des objets :

- Analyse syntaxique
Un objet pourra être un nom ou un groupe nominal.
Un verbe pourra être une opération.
- Etude de l'existant
- Analyse des cas d'utilisation
- Un objet = une entité palpable

- Identifier les objets pertinents
- En déduire les classes
CATÉGORIES D'OBJETS
La messagerie Objets du domaine

Abonné
Message
Boîte aux lettres
Serveur
Client
Objets de présentation
Texte
Son
Objets d'interface
IHM(s)
Objets de contrôle
Socket
DIAGRAMME DE CLASSES DE LA MESSAGERIE
Serveur
* quidam
Client Abonné
{quidam privilégié} nom
mot_de_passe
administrateur
Message
titre
texte Contient
Boîte_à_lettre
1..* s
NOTATION
Chaîne : CompteBancaire
{ auteur = « Jean Dupont », status =
analyse}
Nom : CompteBancaire
Mathématiques::Matrices::MatriceInvers
e
Label : CompteBancaire
compte
Mot clé : « MotClé »
Expression : CompteBancaire
CompteBancaire * (*) (Personne*, int)
NOTATION (SUITE-1)
Expression OCL : item . selector
item . selector [qualifier-value]
set -> select (boolean-expression)
vol.pilote.heures_vol > vol.avion.minimum_heures
compagnie.employés->select (titre=« Manager » and self.rapports-
>taille > 10
Note
:
NOTATION (SUITE-2)
Correspondance type/instance :
Classe : Objets (instances de classe) :
Point
x: Real p1:Point
y: real x = 3.14
rotation(angle: Real) y = 2.718
échelle (facteur: Real)
:Point
x=1
y = 1.414
NOTATION (SUITE-3)
Correspondance rôle/instance :
Rôle : Objets :
p1/tête:Point
tête : Point x = 3.14

y = 2.718
fin : Point
p2/fin:Point
x=1
y = 1.414
! Ne pas confondre rôle et sous classe

AXES DE REGROUPEMENT
 Regroupements par abstraction
<Package>
Sous-Système Package Modèle

PACKAGE
 Groupement d’éléments de modélisation

 identifié par son nom
 contexte de définition d’une classe
 regroupement logique de classes ou d’autres packages
(chaque classe ou sous-package appartient à un et un
seul package)
 arborescence gérée en graphe
 relations avec d’autres packages : ---> « access » ,
« import »
 propriétés rattachées : { … }
 visibilité des composants : + (public) - (private) #
(protected)
 espace de nommage : 2 classes peuvent avoir le même
nom dans 2 packages différents
PACKAGE : NOTATION
Exemple d’un package contenant 2 classes et 3
sous-packages
 Vue externe: NomPackage
 Vue interne : NomPackage
Class1
Class2 Pack1
Pack2
Pack3
PACKAGE : STÉRÉOTYPES PRÉDÉFINIS
 Stéréotypes de package
 « topLevel » : racine de l’arbre (le plus haut de la
hiérarchie)
 « facade » : représentation de processus, sous-systèmes
 « framework » : classes réutilisables
 « stub »
 « access » : référence un élément public d ’un autre
package
 « import » : intégration d ’éléments publics d ’un autre
package
Clients Banque
« access »
Banque::CompteBancaire
CompteBancaire
PACKAGE : EXEMPLE ÉDITEUR
Éditeur
« import » Contrôleur
« import » « access
Figure »
« access »
VueObjet « import »
Dessin Système de fenêtrage
« import »
Mode Motif Motif
« import »
Mode MS Windows MS Windows
PACKAGE : EXEMPLE ÉDITEUR
 Vue de l’arbre correspondant :
Éditeur
Contrôleur VueObjet Figure

PACKAGE : FACADE
 Représentation externe de dépendances entre packages
 référence sur des packages ou des classes existants
 abstraction de niveau supérieur (point de vue général)
 approche systémique d ’un système
 stéréotype : « façade »
Entreprise
« facade » « facade »
Comptabilité Commercial
« facade »
Livraison
SOUS SYSTÈME
 Environnement d’éléments de modélisation

 spécification du contexte : abstraction de package
 classification contextuelle des éléments de
modélisation
 spécification des éléments: use-case, état machine,
processus…
 Notation
 se représente comme un package avec une petite
fourchette dans le coin en haut à droite
 possède 3 sections : opérations, spécifications,
réalisation
 Stéréotypes
 « subsystem » : la notation sous forme de package
correspond à un sous-système
 « instanciable » : le sous-système est instanciable
SOUS SYSTÈME : NOTATION
Symbolisé par une fourchette en haut à droite
Opérations
Op1 :
Type1
Op2 :
Type2
Spécification
Réalisation
MODÈLE
 Point de vue
 visualisation sous un certain angle d’un système
 exemple : analyse, design, conception, architecture
 abstraction thématique (point de vue) du système
 enrichissement du modèle UML par apport de
nouveaux modèles
 plusieurs modèles pour un même sujet
 relations inter-modèles : matérialisation des
dépendances
 Regroupement de modèles
 stéréotype : « systemModel »
MODÈLE
Symbolisé par un triangle en haut à droite
« systemModel »
Analyse Design
Exemple : un projet peut être vu via son dossier d ’analyse, ou par son dossier d ’architecture.
Chaque dossier correspond à un modèle (une vue particulière) du projet
EXTENSIONS
 Contraintes et commentaires
 Propriétés
 Stéréotypes
CONTRAINTES ET COMMENTAIRES
 Contraintes
 relation sémantique entre les éléments du modèle
 conditions et propositions qui doivent être vérifiées
pour valider le système modélisé
 contraintes prédéfinies : xor
 définies par l ’utilisateur dans un langage adapté
 langage prédéfini : OCL
 Commentaires
 texte descriptif rattaché à un élément du modèle
Contrainte : { expression }
* Membre-de *
Personne { expression } Comité
1 Président *
L’expression définissant la contrainte est écrite en OCL ou en langage naturel
La définition d’une contrainte est juxtaposée à un élément simple. Elle

est matérialisée par une flèche en pointillé pour une relation entre deux
éléments
Contrainte dans une note :
La contrainte s’applique à tous les éléments concernés par
cette note, rattachés à celle-ci par des lignes en pointillé
Commentaire sur entreprise :

pas d ’accolades dans le texte
travailleur
employé employeur
*
Personne * 0..1 Entreprise
0..1
patron
{Personne.employeur =
Personne.patron.employeur }
PROPRIÉTÉ
 Valeur attachée à un élément de modèle
 attributs définis dans le métamodèle
 valeur étiquetée (couple mot-clé/valeur) prédéfinie ou
définie par l ’utilisateur; le tag (mot-clé) représente
la propriété
 liste de valeurs étiquetées
 valeur étiquetée booléenne : isEtiquette
Notation :
{ nom = valeur }
{ nom1 = valeur1, nom2 = « autre valeur », nom3 = blabla }
{isNom = true }
{ isNom }
STÉRÉOTYPES
 Modélisation d’utilisation
 applicable à une classe, une relation entre éléments,
...
 même forme (attributs et services) que la classe, mais
signification différente
 mode d’utilisation de la classe
 peut avoir des contraintes en plus de celles de la
classe
 peut nécessiter des tagged values
 extension native de UML
 « motClé » inscrit au-dessus du nom de l’élément
concerné
 peut être iconifié
 peut être décrit par un rectangle identifié par le mot
clé « stereotype »
STÉRÉOTYPES
Stéréotype de classe : classe de contrôle
« control » « control »
Crayon_Traceur Crayon_traceur Crayon_Traceur
location:Point location:Point location:Point Crayon_Traceur

enable(Mode) enable(Mode) enable(Mode)
Stéréotype de membre de classe : création d ’instance

Figure
NomFigure
« constructor »
Créer()
Nouvelle()
Stéréotype de relation entre classes : relation d ’invocation
« call »
JobManager Scheduler
STÉRÉOTYPES PRÉDÉFINIS
stéréotypes de classes :
« actor » : intervenant extérieur (agit sur le comportement)
« utility » : classe utilitaire (attributs et opérations globales)
« signal » : événement
stéréotypes de méthodes de classes :
« constructor » , « destructor » : services particuliers
stéréotype d ’objets :
« local » , « global » , « transiant »
stéréotypes de modèles :
« systemModel » , « subsystem » , « useCaseModel »
« extends » , « uses » : relations entre use case
stéréotypes de package :
« topLevel » , « façade » , « framework », « stub »
« import » , « access » : relations entre packages
STÉRÉOTYPES PRÉDÉFINIS
 Icônes normalisées pour certains

stéréotypes
acteur modèle
contrôle sous-système
 Structure statique du système

 point de vue logique
 ne contient pas d ’informations temporelles
 Classes
 Relations
 Contraintes (OCL)
STRUCTURE STATIQUE
Le diagramme de classes permet d’appréhender, d’un point de vue logique, la structure
statique du système, en indiquant :
• la structure des objets composant le système,
• les liens structurels entre ces objets.
Un diagramme de classes contient aussi bien des classes que des interfaces, des
packages, des relations et des instances (objets et liens). Il ne contient pas
d ’informations temporelles.
Moteur Voiture Personne

cylindrée couleur nom
.......... .......... ..........
.......... démarrer() identité()
.......... ..........
CLASSES
 classe (nom, attributs et méthodes)
 classe interface
 classe paramétrée (template)
 classe utilitaire
 métaclasse
 énumération
 objet
CLASSE : NOTATION
Une classe est représentée sous la forme d’un rectangle comportant 3 sections dédiées
respectivement :
• au nommage
• à la liste des attributs
• à la liste des opérations (méthodes).
nommage { ArticleDeLuxe
Référence : Entier
Désignation : Chaîne
attributs { PrixHT: Réel
Quantité : Entier
PrixTTC () : Réel
PrixTransport () : Réel
opérations { Retirer (q:Entier) : Entier
Ajouter (q:Entier) : Entier
CLASSE : NOTATION
Une classe peut être reconnue au travers de son package d’appartenance :
NomDePaquetage::NomDeClasse.
Selon le niveau d'abstraction requis, la représentation d'une classe pourra prendre une
des formes suivantes:
ArticleDeLuxe
Référence : Entier ArticleDeLuxe

Désignation : Chaîne
PrixHT : Réel
Quantité : Entier
PrixTTC () : Réel
PrixTransport () : Réel
Retirer (q:Entier) : Entier Articles ::
Ajouter (q:Entier) : Entier ArticleDeLuxe
CLASSE : NOTATION
Section de nommage :
• nom de la classe (obligatoire)
• stéréotype (ou icône) pour classifier la classe (métaclasse)
• propriétés (entre accolades)
<<Exception>>
ErreurSocket
{auteur = « Joe Smith » }

CLASSE : ATTRIBUT
Syntaxe:
visibilité nom [ multiplicité ] : type-expression = valeur-initiale {
propriété }
avec visibilité :
public : pubic ou +
protégé : protected ou #
privé : private ou -
Le soulignage de l ’attribut spécifie que celui-ci est un attribut de classe et non pas
uniquement un attribut d’une instance de cette classe (i.e. attribut global, commun
à toutes les instances de la classe)
CLASSE : MÉTHODE
Syntaxe:
visibilité nom ( paramètres ) : type-retour { propriétés }
avec pour visibilité les mêmes possibilités que pour les attributs
avec pour chaque paramètre :

direction nom : type-expression = valeur-par-défaut
avec direction prenant l ’une des valeurs : in, out, ou inout

avec pour propriété :
{ query } : ne modifie pas l ’état du système
{ abstract } : méthode non implémentée par cette classe
{ concurrency = nom } : indique la concurence
avec nom valant : sequential, guarded, ou concurrent
l ’ajout du stéréotype « signal » indique une méthode

événementielle
CLASSE : ATTRIBUTS ET MÉTHODES
Sections liste d ’attributs et liste de méthodes :
 chaque section peut être nommée
 la liste des éléments n ’est pas limitée
 les éléments peuvent être regroupés par un
stéréotype
« exception »
erreurSocket
Attributs
Errno: integer
Méthodes
throw ()
<<acces>> getID () : SocketID

setID(SocketID)
CLASSE : ATTRIBUTS ET MÉTHODES
Informations supplémentaires appliquées aux attributs et méthodes :
• soulignés : attribut et/ou méthode de classe (déclarées en « static » en C++)
• visibilité : + (public), # (protégé), - (privé)
• propriété en langage de programmation entre accolades
Fenêtre de
visualisation
{ auteur = J. DUPONT
}
# Visibilité : Booléen =
invisible
+ TailleDefaut : Entier
# TailleMax : Entier
+ Afficher () {abstract}
+ Cacher () {abstract}
+ Créer () {abstract}
Rafraîchir (mode : integer)
CLASSE : DOCUMENTATION
Une note de documentation peut être associée à chacun des éléments

graphiques.
Description de l ’élément graphique
Pour une classe :

Nom, Description, Documentation, Fichier source, Paramètres de généricité,
Superclasses, Stéréotype, Contraintes, Cardinalité, Type (Abstraite),
Persistance, Concurrence (Active, passive, ...), Catégorie (Domaine, Analyse,
Implémentation), ...
Pour un attribut :
Nom, Type, Valeur par défaut, contraintes, description, visibilité, Accès, …
Pour une opération :

Nom, Documentation, Paramètres, résultat, Type (Virtuelle, amie, …), pré-
conditions, actions, post-conditions, Exceptions, code de la méthode,
CLASSE INTERFACE
 Spécifiée par le stéréotype « interface »
 Classe particulière :
 ne donne que les opérations visibles hors de la classe
 donne une vue partielle du comportement de la classe qui
l ’inclue
 correspond à une classe abstraite (i.e. n’ayant pas d’attributs
et que des méthodes abstraites sans code d ’implémentation
spécifique)
 sert de routeur vers des services particuliers (point de vue
abstrait)
 symbolisée par :
 l ’accès à une méthode est symbolisé par une flèche en pointillé

pointant sur le cercle de la méthode de l ’interface :
(Côté interface) (Côté accès méthode)

CLASSE PARAMÉTRÉE
Une classe paramétrée (template) est représentée en surchargeant le compartiment supérieur

contenant le nom de la classe : la liste et le type des paramètres formels sont introduits sous la
forme :
[arg1:]type1, .., [argn:]typen
Une instance de classe template est représentée comme une classe ordinaire, mais en
introduisant le paramétrage dans le nom de la classe, sous la forme :
NomDeTemplate<valeur1,valeur2, .., valeurn>
T,n:Entier
Vecteur
Vecteur <Point,3> Vecteur

<Adresse,24>
CLASSE GLOBALE
 Spécifiée par le stéréotype : « utility »
 Les membres (attributs et méthodes) de l ’instance de classe sont
globaux
 Les membres de la classe sont globaux dans le domaine de la
classe
« utility »
FonctionsMathématique
s {auteur = J.
DUPONT}
Racine : Entier long = 0
PI : Entier long = 3.14159265358979
sinus (angle : Réel) : Réel

cosinus (angle : Réel) : Réel return sinus(angle + PI / 2)
NombreAléatoire () : Réel
OBJET
Un objet est une instance de classe; il est défini par :
• un nom souligné
NomObjet : NomDeClasse
: NomDeClasse (pour un objet anonyme)
NomObjet : NomDePackage :: NomDeClasse
NomObjet : NomDeClasse [ listeDeNomEtat ] (objet d ’une classe dans un état particulier)
• une liste de valeurs d ’attributs
NomAttribut : type = Valeur
NomAttribut = Valeur
kimono : Article
Kimono : Article
Référence = 30341
Désignation = “kimono”
PrixHT = 495.00 : Article
Quantité : Integer = 1000
RELATIONS
 Relations :
 par association (coopération)
 par agrégation (association de composition)
 par héritage (spécialisation/généralisation)
 par dépendances
 élément dérivé
ASSOCIATION
 Association
 Relation : décrit un ensemble de liens (instance d ’association)
entre des instances de classes
 Association entre une classe (ou ensemble de classes) associée
à une autre
 Représentation : une ligne droite, brisée ou courbe, reliant
deux classes
 Nom : le nom figure à proximité de la ligne représentant le

lien; le sens de lecture du nom peut être indiqué par un
triangle plein placé à côté du nom.
 Stéréotype : un stéréotype peut être ajouté au nom de
l ’association
 Propriété : une propriété peut être exprimée textuellement

 ex: pour l ’association Personnel entre un ensemble de personnes et
une entreprise, on peut ajouter la propriété Travaille pour, ou Poste
occupé
ASSOCIATION
 Exemple avec :
 nom (Fabrique)
 sens de lecture (de A
vers B)
 stéréotype
(Fabrication) « Fabrication »
Fabrique
Entreprise ArticleDeLuxe
 Exemple avec :
 nom (Personnel)
 sens de lecture Entreprise Personnel Personne
 propriété (Travaille
Travaille pour
Nom Nom
pour) Adresse No S.S.
Adresse
ASSOCIATION
 Informations sur les extrémités de l ’association
 Rôle : précision du rôle joué par une classe; peut être

ajouté à chacune des extrémités d’une association;
peut avoir une visibilité (public +, private -, protected
#)
 Cardinalité : nombres d ’instances concernées pour
chaque classes
 Navigation : orientation des relations dans la classe
destinataire de la flèche (flèche inscrite sur les
extrémités de la ligne représentant l ’association)
ASSOCIATION : RÔLE
 Exemple avec :
 rôles
 navigation
Fabrique
Entreprise fabricant produit fabriqué
ArticleDeLuxe
 Exemple avec :
 visibilité sur +Rôle_B
rôle
Classe_B
Classe_A
Classe_C
-Rôle_C
+Role_B : accès public à la classe Classe_B
-Role_C : accès privé à la classe Classe_C; c ’est une classe d ’implémentation;
elle n ’est accessible que quand on est dans la classe Classe_A
ASSOCIATION : CARDINALITÉ D ’ASSOCIATION
 La cardinalité donne le nombre d’instances de chacune des
classes mises en relation avec une instance de la classe
associée
 Elle est indiquée par une expression placée à chaque
extrémité du lien
classe Exactement 1 instance
* Plusieurs (0 ou plus)
classe
0..1 Optionnel (0 ou 1)
classe
1..* 1 ou plus
classe
1-3, 5 Cas particuliers

classe
* {ordered}
classe Avec ordonnancement
ASSOCIATION : CARDINALITÉ D ’ASSOCIATION
 Exemples de cardinalités :
Un seul fabriquant (qui est une entreprise) crée un ensemble produits de type articles de luxe
1 Fabrique *
Entrepris ArticleDeLuxe
e fabricant produit fabriqué
Nom : Chaîne Référence : Entier
AdresseSiège: Chaîne Désignation : Chaîne
AdresseUsine: Chaîne PrixHT : Réel
Quantité : Entier
Plusieurs revendeurs (boutiques de luxe) peuvent vendre des articles de luxe
* Vend *
Boutique de luxe ArticleDeLuxe
revendeur produit diffusé
{ordered}
ASSOCIATION : CONTRAINTES
Une classe peut être impliquée dans deux associations distinctes par l’intermédiaire de deux instances:
chacune des instances participe à une et une seule des deux associations. Cette situation est représentée en
appliquant une contrainte entre les deux liens:
Exemple : Le détenteur d ’un compte bancaire est soit un particulier, soit une entreprise (exclusion)
1..2
Particulier
Compte bancaire {ou-exclusif} détenteur
1
Entreprise
Remarque : la contrainte ou-exclusif mentionnée ici aurait pu être donnée en utilisant le mot clé xor
Exemple : un patron est aussi un collaborateur de son entreprise (inclusion)
Collaborateur 0..*
Personne 1..*
{subset} Entreprise
1 0..*
Patron
ASSOCIATION : QUALIFICATION
Une association peut être qualifiée par un (ou plusieurs) attribut. La valeur de cet attribut
permet de réduire l ’ensemble des instances répondant à l ’association. Ce qualificatif est
associé à la source de l ’association. La cardinalité précise :
0..1 : une seule valeur peut être sélectionnée, mais chaque valeur de l ’attribut n ’est pas
obligatoirement discriminante
1 : chaque attribut définit une instance unique
* : la valeur de l ’attribut est un index permettant de regrouper les instances en sous-ensembles
Échiquier
Banque
ligne:Ligne
compte # colonne:Colon
ne
* 1
0..1 1
Personne Carré
Association entre Banque et Personne pour Association entre Échiquier et Carré

déterminer le propriétaire d ’un compte en permettant de localiser une case de
banque spécifique l ’échiquier aux coordonnées fournies
ASSOCIATION : QUALIFICATION
Une association peut être qualifiée par une classe :
* Emploi *
Entrepri Personne
se employeur employé
Nom Nom
Adresse Numéro Sécurité Sociale
Emploi Adresse
Salaire
Fonction Patron
0..1
Collaborateur *
Dirige
Salaire et Fonction sont des attributs de la classe caractérisant l’association entre les Personnes et
l ’Entreprise. Ce ne sont ni des attributs de la classe Entreprise, ni des attributs de la classe Personne.
Cette classe (emploi) peut avoir une relation d ’association (dirige) entre ses représentants (poste de
patron, simple collaborateur)
ASSOCIATION : CAS PARTICULIERS
Association réflexive Association ternaire
Réservation
Person Place
Vol
Nom
ne patron vol place
Numéro Sécurité Sociale 0..1 Date passager Numéro
Adresse Situation
Dirige Individ
u
Nom
employé *
AGRÉGATION
 Agrégation :
 un ensemble d ’objets fait partie intégrante d ’un
autre objet
 Agrégation partagée
 symbolisée par :
 La destruction de la classe sur laquelle porte
l ’agrégation n ’implique pas la destruction des objets
qui la composent
 cfr. les objets pointés ou les références en C++
 Agrégation de composition
 symbolisée par :
 La destruction de la classe sur laquelle porte
l ’agrégation entraîne la destruction des objets qui la
composent
 cfr. les classes membre de classe en C++
AGRÉGATION
 Agrégation partagée
 peut être qualifiée : {ordered} .
Notation par inclusion Notation par diagramme
Dessin Dessin
Carré Triangle
Carré Triangle
Notation avec cardinalité et qualificatif
3..*
Polygon
{ordered} Point
e
AGRÉGATION
 Agrégation de composition :
Une moto est composée de:

2 roues, 1 siège, 1 châssis, 1 moteur
Moto
2 1 1 1
Roue Siège Châssis Moteu
r
AGRÉGATION
uneMoto:Moto
leSiège:Siège avant:Roue arrière:Roue
leChâssis:Châssis leMoteur:Moteur
Moto
Siège 1 2
Roue
Châssis 1 Moteur 1
AGRÉGATION Vue globale
Connecté à
* *
* 1
Feu tricolore Coordonné par Centre de contrôle
Connecté à Vue détaillée

Feu tricolore Centre de contrôle
* *
3 1 1 1
1 Ordinateur
Lampe * Coordonné par
Contrôleur
*
1
1 1
* *
Capteur 2 Capteur
1 *
magnétique Afficheur
* optique
HÉRITAGE
 Héritage : association particulière (héritage de données
et code)
 classe mère (classe de base, super-classe) : généralisation
 classe fille (classe dérivée, sous-classe) : spécialisation
 représentée par :
Super-classe
Sous-classe A Sous-classe B
HÉRITAGE
 Exemple : un article électroménager, un article de luxe, ou un vêtement ont en
commun les mêmes caractéristiques décrites dans la classe Article
Article
Référence
Désignation
PrixHT
Quantité
{ Classe de base
classe mère
super-classe
GENERALISATION
SPECIALISATION
PrixTTC ()
PrixTransport ()
Retirer ()
Ajouter ()
Électroménager ArticleDeLux Vêtemen

e t
DuréeGarantie
Poids
Coloris
Taille { Classes filles
classes dérivées
sous-classes
ValiderGarantie PrixTTC ()
()
HÉRITAGE
Expression des contraintes et des discriminants :
Véhicule
{non disjointes} ou {inclusif}
Motorisation Milieu
Véhicule à moteur Véhicule à Voile Véhicule terrestre Véhicule marin
Contraintes prédéfinies :
{disjoint} : une instance de sous-classe ne peut être instance d ’une autre sous-classe
{overlapping} : une instance peut appartenir à plusieurs sous-classes
{complete} : l ’arbre d ’héritage est exhaustif
{incomplete} : d ’autres sous-classes peuvent être ajoutées à l ’arbre des sous-classes
Discriminant :
Le discriminant sert à préciser le critère de classification utilisé
DÉPENDANCES
 Dépendance
 relation sémantique entre deux ou plusieurs éléments
 une modification de la cible implique une modification de la source
 Dépendances prédéfinies entre classes :

 derive - Derivation : relation entre 2 éléments; stéréotype
« derivation »
 trace - Trace : historique des relations: stéréotype « trace »
 refine - Refinement : affinage historique ou dérivée avec mapping
entre 2 éléments; une description peut être ajoutée dans une note;
stéréotype « refinement »
 use - Usage : dépendance d ’implémentation ou de fonctionnement;
stéréotype défini par l ’utilisateur ou stéréotype d ’usage « call » ,
« create » , « instantiate » ou « send »
 bind - Binding : agrégation d ’un template, génération d ’un
élément non-paramétré;
DÉPENDANCES
 Dépendances entre classes :
ClassA ClassB ClassD

« friend »
« fiend »
« instantiate » Opération()
ClassC
« call »
Exemple : instance de classe paramétrée
T,k:Integer
Tableau
k..k
T
« bind » (Adresse, 24)
ListeAdresses
DÉPENDANCES
 Dépendances prédéfinies entre packages
 access : permet à un package de référencer un élément
public d ’un autre package; stéréotype « access »
 import : permet à un package d ’utiliser le nom des
éléments publics d ’un autre package directement dans le
package courant en les y associant comme s ’ils étaient
définis localement; stéréotype « import »
Exemple : éditeur graphique

Controller
« access »
« access » « access »
Diagram Elements « access »
Domain Elements Graphics Core

ÉLÉMENTS DÉRIVÉS
 Un élément dérivé
 est généré à partir d ’un autre élément
 il n ’apporte pas de nouvelle sémantique
 il est utilisé pour plus de clarté et pour les besoins du
design
 indiqué par l ’ajout d ’un / (slash) devant le nom de
l ’élément dérivé
Personne
{âge = DateCourante - DateNaissance} /âge

DateNaissance
Entreprise Département
employeur
1 employeur 1 département
travaillePourDépartement
*
*
Personne
/travaillePourEntreprise
{ Personne.employeur = Personne.département.employeur }
OCL : OBJECT CONSTRAINT LANGUAGE
Le chemin d’accès à un attribut ou le parcours de relations d’association dans un diagramme

de classes peuvent être exprimés simplement sous la forme de pseudo-code. Le symbole « . »
indique une information ou un ensemble d’informations accessibles à travers la relation liant
deux classes : personne.employeur
La sélection d’un élément au sein d’un ensemble est exprimée entre crochets :
todaysFlight:= flights[flight.date=today].
Un attribut d’association peut également être indiqué entre crochets :
aFile:=directory.files[filename]
* Travaille pour 0..1

Personne Entreprise
employé employeur
Nom Nom
patron Numéro Sécurité Sociale Adresse
0..1 Adresse
{ personne.employeur =
Dirige personne.patron.employeur }
* employé
OCL : OBJECT CONSTRAINT LANGUAGE
Il est recommandé d’éviter d’introduire des informations redondantes dans un modèle d’objets
(quel qu’il soit). On peut cependant être amené à introduire une information redondante afin
d’indiquer les éléments dont elle dérive. Une entité dérivée est décrite en faisant précéder son
nom du symbole « / » et en lui associant une contrainte indiquant son domaine de définition.
/ emploie
* 1
Personne Entreprise
employé employeur
Nom Nom
patron Numéro Sécurité Sociale
Adresse
0..1 Adresse
Dirige 1
* *
employé
1
*
emploie
Service
{personne.employeur =personne.service.entreprise}
2. Modélisation UML
2.9 Retour à la messagerie : IHM
On passe maintenant à l'analyse des objets d'interface :
Nom :
Mot de passe :
OK ANNULER
menu connexion : IhmConnexionunClient
nom
activation
mot de passe
OK demande de connexion
connexion autorisée (type)

menu quidam : IhmMenu
activation
Connexion d'un utilisateur réussie

2.9 RETOUR À LA MESSAGERIE : IHM
:Client :Serveur
*
quidam
Fenêtr Abonné
e nom
{quidam privilégié}
mot_de_passe
administrateur
1 1
IhmMenu IhmConnexio Message
n titre
texte Contient
Boîte_à_lettre
1..* s
• Diagramme d ’état-transition de l'IhmConnexion
connexion non autorisée / Bip

Attente
OK[Nom et Prenom saisis]
Vérification
connexion autorisée[type = quidam] / ^activation:menu_quidam

2.10. DIAGRAMME ÉTATS-TRANSITIONS
DÉFINITION
 Un diagramme d ’états/transitions (automate) permet de

représenter les états successifs d'un d'objet en fonction des
sollicitations externes et/ou des interactions avec d'autres objets.
 Simulation de la dynamique de comportement du système
 Un diagramme états/transitions est un graphe orienté dont les

nœuds matérialisent des états reliés par des transitions.
 Il existe une forme particulière des diagrammes états/transitions

qui permet de représenter le déroulement des opérations à l'image
d'un organigramme, ces diagrammes sont appelés diagrammes
d'activité.
2. 10. DIAGRAMME ÉTATS-TRANSITIONS
DÉFINITIONS DES ÉLÉMENTS DE DIAGRAMME : ÉTAT
 État État :
 nœud du graphe valeur attributs
orienté à un instant T
 transitoire
 État initial
(création)
État initial
 État final
 peut avoir une
condition de
destruction État courant
Événement
(État final)
2.8 10. DIAGRAMME ÉTATS-TRANSITIONS
ÉTAT : NOTATIONS
 État :
 instant fini de la vie d’un objet pendant lequel il répond à des
conditions particulières, ou qu’il est en cours de réalisation
d’une action, ou qu’il attend l’arrivée d’un événement
 Défini par
 son nom (optionnel)
 des transitions internes (activités) de la forme : label_action /
expression_action (optionnelles)
 Notation :
État État
label / activité ou label / activité ou label / activité
ÉTAT : ACTIVITÉ
 Activité
 transition interne d ’un état, interruptible, et à durée limitée
 peut être continue ou finie (se termine toute seule)
 des transitions internes de la forme : label_action /
expression_action
 labels réservés :
 entry : action exécutée lors de l’entrée dans l ’état courant
 exit : action exécutée en sortie de l ’état courant
 do : action réalisée durant toute la durée de l ’état courant
 include : identification d ’une sous-machine utilisée pendant

cet état
 Exemple : Saisie mot de passe

entry / écho invisible
exit / écho visible
caractère / gérer caractère
help / afficher aide
DÉFINITIONS DES ÉLÉMENTS DE DIAGRAMME : TRANSITION
 Transition
 arc orienté du graphe
 relation entre 2 états
 un objet dans un premier état va exécuter des
actions et entrer dans un deuxième état
 exécution si les conditions sont remplies
 peut être mise en action sur réception
d ’évènement
Événement [ condition ]
Premier état Deuxième état
TRANSITION : EXEMPLE
 Exemple :
 La transition entre l ’état de célibataire et celui de
marié se fait par le biais du mariage (événement)
 une condition pour se marier est d’être majeur
Mariage [ Majorité atteinte]

Célibataire Marié
TRANSITION COMPLEXE
 Transition complexe
 peut avoir plusieurs sources et/ou
plusieurs destinations
 représentée par une barre de
synchronisation
Processus
Setup Cleanup
DÉFINITIONS DES ÉLÉMENTS DE DIAGRAMME : ÉVÉNEMENT
 Événement
 apparaît à un instant précis
 une durée de vie très courte
 c'est un message
 peut véhiculer de l ’information
 peut être paramétré
 Notation
Nom_Événement (paramètre_1:type_1, ..., paramètre_n:type_n)
 Exemple : appui du bouton d ’appel

d ’ascenseur
Appui Bouton Appel ( Etage )
DÉFINITIONS DES ÉLÉMENTS DE DIAGRAMME : CONDITION
 Condition
 expression booléenne
 peut porter sur les paramètres de l ’événement
déclencheur (si il existe)
 peut porter sur les variables d ’état
 peut porter sur les attributs (leurs valeurs sont
soumises à condition)
 Exemple : condition pour être majeur
[Age >= 18 ans]

Enfant Enfant
Mineur Majeur
DÉFINITIONS DES ÉLÉMENTS DE DIAGRAMME : ACTION
 Action
 opération atomique non interruptible
 déclenchée par une transition sur réception d ’un événement
 représentée par un / (slash)
 accès aux variables d ’état, aux paramètres de l ’événement,
aux attributs de l ’objet
Evenement ( Param ) [ Param != Valeur ]
État État
/ opération_atomique
Exemple : mise en route du moteur d ’un ascenseur
Appui Bouton Appel (Étage) [ Étage != Palier ]

Arrêt Marche
/ Démarrer moteur
ACTION À ÉMISSION ÉVÉNEMENT
 Une action peut générer un nouvel

événement
 un nouvel événement est envoyé vers un
destinataire
 Notation
Évènement(textuelle) : 1 , parametre2:type2 , ... ) [ expression booléenne ]
( parametre1:type
 /représenté par .un
^ catégorie d'objet ^ (chapeau)
Événement ( parametre1:type1 , … ) méthode
(arguments)
 Notation graphique
ACTION À ENVOI D ’ÉVÉNEMENT
 Notation graphique
Appui Bouton appel / Démarrer moteur

Arrêt Marche
Allumer(valeur)
BoutonEtage:PanneauAffichage
 Notation textuelle
Arrêt Marche
Appui Bouton Appel / Démarrer moteur
^BoutonEtage. Allumer(valeur)
EXEMPLE
Exemple
on [not PB and not AU] / ^ moteur.démarrer
off / arrêter Marche

Arrêt
do / surveiller
[PB or AU] / ^ moteur.arrêter alarmer

HIÉRARCHISATION DES ÉVÈNEMENTS
 Classification des événements déterminant le comportement du système

 diagramme de classes de stéréotype « signal » avec paramètre événement =
attribut classe
« signal »
Événement
heure
« signal »
Entrée utilisateur
périphérique
« signal » « signal »
Souris Clavier
position caractère
« signal » « signal » « signal » « signal »

Bouton pressé Bouton relâché Contrôle Graphique
ÉTAT COMPOSÉ
 État composé de sous-états
 sous-états concurrents (régions)
 sous-états disjoints
 icône associée :
Exemple : Composition numéro contient plusieurs sous-états
Numéro_Composé(num)
Téléphone Combiné décroché Composition Communication
inutilisé numéro établie
DÉCOMPOSITION D’ÉTATS
 Décomposition de l’état Composition du numéro

 on précise l ’état de départ
 l ’état intermédiaire Composition partielle est répété sur réception de
l ’événement chiffre
 en sortie (état final) on a un numéro totalement composé et validé
Composition du
numéro
numéro: chaîne = ““
Composition partielle
Composition du
numéro Chiffres(n) [numéro.Validé()]
entry / déclencher_ tonalité entry / numéro.concaténer(n)
exit / stop_tonalité / ^ Numéro_Composé(num)
Chiffres(n)
APPORT DE LA STRUCTURATION
S1
S
1
S2 S4 S2S4 S2 S5
S3 S5
S3S4 S3S5
SOUS-ÉTATS CONCURRENTS (RÉGIONS)
 Sous-états concurrents : représentés sous la forme de
plusieurs diagrammes états/transitions séparés par une
ligne hachée
 Exemple : validation d’une U.V.
Validation UV
Validation partielles
Expérience #1 réalisée Expérience #2réalisée

Laboratoire Laboratoire Validée
projet terminé
Projet
reçu
Examen
recalé Repasser
ÉTATS CONCURRENTS
États composites décrivant des sous-automates concurrents : l'évolution des états

concurrents est
représentée sous la forme de plusieurs diagrammes états/transitions parallèles regroupés
dans un état composite.
evt / bip AU
Process Arrêt
Attente
sp(activité1) do / activité1
[condition] / bip
Process
Attente
do / activité2
sp(activité2)
ÉTATS COMPOSÉS ET TRANSITIONS
 Transitions sur états composés
W
s
p s
A E C
u
F
B r
D
t
Simplification de la notation :
W s
p
A C
B r D
2. 10. Diagramme États-Transitions
exemple
Automate d'une Pile

dépiler() / erreur() empiler() / erreur()
Vide Pleine
empiler()/N=1 empiler() [N = Nmax-1]/N=Nmax
empiler()[N!=Nmax-1] / N = N+1
dépiler()[ N= 1]/N=0
dépiler() / N = Nmax-1
En Charge
dépiler()[N!=1] / N = N-1
HISTORIQUE D ’ÉTAT
 Un indicateur d'historique peut être associé à un état
composite A
 permet de marquer le dernier sous-état de A à
partir duquel une transition a été réalisée vers un
autre état H
 noté par la lettre H dans un cercle
Exemple :
A A1 B
H
A2
INDICATEUR D'HISTORIQUE
Un indicateur d'historique (lettre H dans un cercle) peut être associé à un état composite A
afin de marquer le dernier sous-état (Ax) à partir duquel une transition a été réalisée vers un
autre état composite (B). Une transition ultérieure vers l'indicateur d'historique indiquera une
restitution du sous-état marqué (Ax).
Chauffage Trop chaud Refroidissement

Temp OK
Repos
entry / ^démarrer : chaudière
exit /^ arrêter : chaudière Démarrage
Trop froid
[temps écoulé depuis dernier arrêt >= 5 mn]
Compresseur
panne actif
panne corrigée Temp OK
Prêt
Panne
H enregistrement panne
Ventilateur actif
Créé
Création Log Attente Enregistrement
Actif
panne enregistrée
ACTIONS INTERNES
 Traitement d’un événement dans un état : actions déclenchées
do / activité L ’événement event est interne à l’état;

entry / action 1 on ne sort pas de l’état pour le traiter
exit / action 2 entry et exit ne sont pas déclenchées.
event/ action 3
#
event / action 3
do / activité
L ’événement event est externe à l ’état (ayant pour
entry / action 1
effet de re-rentrer dans cet état);
exit / action 2
les actions relatives à exit puis entry sont déclenchées
quand l ’événement event apparaît.
ÉTAT DE SOUS-MACHINE
 Un état de sous-machine représente une invocation à un état
machine défini par ailleurs
 La sous-machine doit être dans le même contexte que l ’état
machine appelant
 Un état machine peut être accédé (ou quitté) à chacun de ses sous-
états
Exemple : Gestion des erreurs
• La transition due à l’événement include / ErreurSousMachine
Erreur1 se termine à l’état sub1 Erreur2 /
• La transition due à l’événement Erreur1 /
Erreur2 se termine au sous-état
sub12 de l ’état sub1 sub1 sub1::sub12
• La transition due à l’événement subEnd
Erreur3 utilise la transition par
défaut de la sous-machine Erreur3 /
• La transition Fixe1 est générée à
Fixe1 /
partir du sous-état subEnd
ÉTAT DE SYNCHRONISATION
 Un état de synchronisation permet de synchroniser des

régions concurrentes d ’un état-machine
 Le nombre de chargement des transitions de sorties peut être
limité par une valeur (* pour dire sans limite) dans un cercle
 Ce nombre correspond à la différence d ’occurrences entre les
transitions entrantes et sortantes
Construire Maison
Monter
Construire Poser le
les murs
charpente toit
Créer
fondation Inspection
* *
Electricité Electricité Electricité

fondations charpente extérieure
2.11. DIAGRAMME D’ACTIVITÉS
 Visualisation dynamique des activités du

système
 permet le contrôle de flux des données
 prises de décisions
 attribution de responsabilités
Remplir bon de commande

Aller au boulot
Activité simple, élément Activité composée de sous-activités, élément

de diagramme d ’activités de diagramme d ’activités
2. 11. DIAGRAMME D’ACTIVITÉS
PRINCIPE
Personne::Préparer_boisson [pas de café]
Trouver Boisson
[café trouvé]
Mettre le café dans Ajouter de l'eau Prendre un

le filtre dans le réservoir gobelet
Mettre le filtre dans

la machine
Allumer la
machine
Allumer la
on machine machine
/machine.on
Ecoulement
Ecoulement
lampe éteinte
lampe éteinte
Verser café Boire boisson
DÉCISIONS
 Prise de décision
 une action propose plusieurs transitions
 chaque transition est dotée d ’une condition
[coût < 500 F] Débiter

Calculer coût
[coût > 500 F]
Demander
autorisation
ATTRIBUTION DES RESPONSABILITÉS
Client Commercial Magasin
Commander
Payer Prendre commande
destocker produit
Delivrer
Receptionner
MODÉLISATION UML
2.12 RELATION ENTRE LES DIAGRAMMES
Connexion
Connecté à
Système
Client
Feu tricolore Centre de contrôle
nom * *
3 1
1 1 * Coordonné par 1
mot de passe Lampe Ordinateur
Contrôleur
*
1
1 1
* *
2 1 *
Capteur
Capteur
magnétiqu Afficheur
* optique
e
Premier état Événement [ condition ] Deuxième état

MODÉLISATION UML
2.13 VALIDATION DU MODÈLE OBJET
 Vérifier le modèle au niveau de

 la cohérence, la complétude, l’homogénéité
 Vérifier le respect
 des rôles, de la sémantique de composition et
agrégation
 Éliminer les sous-classes inutiles
 Exécuter les scénarios sur le modèle objet
 permet de voir si on a tous les attributs et méthodes
 Faire valider le modèle par toutes les personnes
concernées
 expert, client, gens de métier
 ceci peut amener à de grandes discussion (demande
de la diplomatie) et peut-être à revoir et rectifier le
modèle
 se baser sur la validation du dictionnaire pour étayer
ses arguments
MODÉLISATION UML
2.13 VALIDATION STATIQUE
La majorité des outils offrent cette possibilité.
Il s ’agit ici de vérifier la cohérence des données d ’un point de vue syntaxique
Ex : si dans un diagramme de collaboration un objet reçoit un message « démarrer »,

son interface doit comporter une méthode « démarrer ».
MODÉLISATION UML
2.13 VALIDATION DYNAMIQUE
Certain outils comme Object Geode de
CS Verilog,
proposent des modules de simulation

dynamique, à l ’aide d ’une description
précise (SDL),
le concepteur a la possibilité de
renseigner ses diagrammes et de les
faire exécuter sur une machine virtuelle,
voir directement sur le plate-forme cible
dans le cas d ’applications temps réel
embarquées.
MODÉLISATION UML
2.14 ÉLÉMENTS D’ARCHITECTURE
Objectifs :
Faire une description de l'architecture physique et

logique du système.
--> Description textuelle

--> Diagrammes de composants
--> Diagrammes de déploiement
MODÉLISATION UML
Décomposer en modules
(Vue non UML)
Service
CLIENT SERVEUR
(IHM)
COM
Interface C++
Implémentation
SOCKET
UNIX
HARD
MODÉLISATION UML
L’application messagerie est constituée de 2 entités distinctes qui fonctionnent en
parallèle et qui ont une implantation physique différente :
- Le Client et sa partie communication associée

- le Serveur et sa partie communication associée
Le sous système Client est implémenté sur 1 à n postes PC/UNIX.

Le sous système Serveur est implémenté sur 1 poste PC/UNIX.
Le sous-système Communication est présent dans les deux parties.
requêtes d'administration
requêtes utilisateur
CLIENT
SERVEUR
MODÉLISATION UML
Utilisation du système de fichiers Unix
SERVEUR
FICHIER DES
ABONNES
nom
mot de passe
BIN
ID process socket
client
ABONNE_1 ABONNE_n ADMIN

exécutables
messages de messages de messages de

ABONNE_1 ABONNE_n administrateur
MODÉLISATION UML
La Messagerie
Du côté serveur :
Multitâches Unix
Du côté Client :
Événementiel, lié à l'utilisation de X11

MODÉLISATION UML
• Mise en œuvre du système
Il faut prévoir une procédure d’installation au niveau du serveur :

· création de la structure arborescente définie précédemment
· saisie du nom et du mot de passe de l’administrateur et mémorisation dans le fichier spécial
qui contient la liste des abonnés
Au niveau Client, il faut initialiser le nom de la machine serveur dans une variable UNIX, pour pouvoir effectuer la
connexion
Serveur.
• Arrêt du système Serveur : 2 cas possibles

1. arrêt normal : 2. arrêt sur panne :
- l’indiquer de façon persistante (dans un fichier Log) - ne rien noter
En cas de redémarrage après un arrêt sur panne, il faut vérifier si les répertoires abonnés sont bien cohérents avec la liste
des abonnés. Si ce n’est pas le cas, il faut créer les répertoires manquant par rapport à la liste des abonnés.
• Espace disque
Au démarrage Serveur, il faut vérifier qu’il y est un espace disque suffisant pour créer l’arborescence et stocker des
messages (qcq Mega). En fonctionnement régulier, il faut contrôler en permanence l’espace disponible restant sur le
disque et avertir les clients qui veulent envoyer des messages, lorsque la place disque devient insuffisante.
On peut créer (au démarrage) un fichier tampon qui jouerait le rôle de réserve lorsque l’espace disque deviendrait limité.
MODÉLISATION UML
 Diagramme de composants
 Diagramme de déploiement
MODÉLISATION UML
2.14 ÉLÉMENTS D’ARCHITECTURE : DIAGRAMMES DE
COMPOSANTS
 Modèle physique
 Organisation des ressources : source, binaire,

librairie,…
Scheduler réservations
Projection mise à jour
GUI
MODÉLISATION UML
COMPOSANTS
 Composant avec interfaces
Orthographe
Dictionnaire
Synonymes
 Composant incluant des objets

dynamiques
maboîte : Mailer
Mailbox RoutingList
MODÉLISATION UML
COMPOSANTS
send
Socket
receive
Socket.h
Boite_a_lettre
Message Abonné
Boite_a_lettre.h
class Boite_a_lettre
class Message
class Abonné
MODÉLISATION UML
2.14 ÉLÉMENTS D’ARCHITECTURE : DIAGRAMMES DE DÉPLOIEMENT
 Modèle dynamique à l’exécution
 Exécutables utilisés par le système
 Montre la configuration des éléments d’exécution et des
composants logiciels
 architecture générale des éléments d ’exécution
 Permet de déterminer les ressources physiques
nécessaires au fonctionnement du système
 donne les associations de communication entre les
nœuds du graphe
 Un nœud du graphe peut contenir des composants

MODÉLISATION UML
2.14 ÉLÉMENTS D’ARCHITECTURE : DIAGRAMMES DE DÉPLOIEMENT
 Relations entre nœuds du graphe
AdminServer :
HostMachine « database »
RDV BD
: Planificateur
réservatio
n
Machine 1 : PC
:
Agenda
MODÉLISATION UML
2.14 ÉLÉMENTS D’ARCHITECTURE : DIAGRAMME DE DÉPLOIEMENT : LA
MESSAGERIE
Autre approche pour la messagerie avec une base de données gérant les abonnés
Serveur
« database »
Abonné
: Boite_a_lettre
send
: Socket
receive
Client
send
: IHM : Socket
receive
3. CONCEPTION
OBJECTIFS
 Approche en Y : Existant
{ • matériel
• logiciel
• compétence des équipes
Exigences prototypage
{
• langage
Analyse • distribution
• persistance des objets
• architecture logicielle
• normes de conception
• design patterns (modèles de conception)
• mécanismes réutilisables
Conception
Implémentation
Tests
3. CONCEPTION
EXEMPLES D ’ACTIVITÉS PROPRES À LA CONCEPTION
- Combiner les trois modèles pour obtenir les opérations sur les classes
- Concevoir les algorithmes qui implémentent les opérations
- Optimiser les chemins d'accès aux données (objets, attributs, associations dérivés)
- Implémenter les contrôles (automate, procédure, tâche)
- Ajuster les structures de classes pour augmenter l'héritage
- Préciser les associations
- Déterminer la représentation des objets
- Regrouper les classes et associations dans des modules
- Valider
3. CONCEPTION
LA MESSAGERIE
Conception des opérations
On s'aidera dans cette phase des diagrammes d’interactions entre objets
- Pour chaque opération, représenter les objets existants avant le déclenchement de la fonction,
superposer les objets créés à l'aide de pointillés, indiquer les flots de données.
→ 1 - activer(envoi)
→ 1.1 créer (Nom, Mot_de_passe)
:Client L
IHM-Connexion :Requète_connexion
L
→ 1.2 reponse = envoyer()
↓1.3 traiter()
↓1.2.1 trame_recept = envoyer(trame_em
L L
:Reponse_acquitement :Socket
3. CONCEPTION
LA MESSAGERIE
SOCKET
Serveur
destination
Service socket_administrateur
Identificateur
Socket (service)
Socket (machine,service)
Socket (numéro) 0 .. sockets_abonnés
activer_connexion () *
envoyer (buffer)
recevoir (buffer)
3. CONCEPTION
UTILISATION DES PATERNS
- Exemple d'un moniteur multitâches en environnement mono processu
1
Process Moniteur
Event
priorite 1..n
pos 0..1 1..1
reset() go()
set() main_loop quit()
isset()
3. CONCEPTION
PRÉCISION DES ASSOCIATIONS
Critères
- Un choix global ou spécifique à chaque association
- Utilisation faite des associations (sens)

3. CONCEPTION
Un losange placé à l’une des extrémités d’un lien d’agrégation (du côté du composant) permet
de définir le mode d’implémentation physique de l’agrégation:
- un losange vide indique une implémentation par référence (utilisation d’un pointeur ou
d’une table de hachage (Hash Coding) par exemple)
- un losange plein indique une implémentation par valeur (une classe est imbriquée dans une
autre).
1
3..*
Polygone Point
1 {ordered}
1
Bordure
Couleur
Texture
Densité
3. CONCEPTION
Préciser les associations
- Association mono directionnelle
Travaille pour
*
Personne Société
employeur
Personne
employeur Société
employeur est un pointeur sur un objet de type Société

3. CONCEPTION
- Association bidirectionnelle
1 - Traiter le retour par une méthode
2 - Implémenter un attribut dans chacune des classes
Travaille pour
* Société
Personne
employés employeur
Personne
employeur Société
employés
Ensemble
3. CONCEPTION
3 - Implémenter l'association comme un objet
Personne A
Société X
Personne B
Personne C
Société Y
Personne D
Surtout utilisé si l'association possède des attributs

3. CONCEPTION
REPRÉSENTATION DES OBJETS
Représentation des objets
Fichier Fichier
date_création : date_création
:
Entier Chaîne Fichier Date
date_création jour : Entier
mois : Entier
Ligne année : Entier
x1 : réel
y1 : réel p1
x2 : réel Ligne Point
y2 : réel x : réel
p2 y : réel
3. CONCEPTION
Quelques exemples
Fenêtre
Fenêtre Id : Entier
largeur largeur
hauteur hauteur
centre centre
* Ordered-collection
Equipe Joueur Equipe
{ordered} <joueur>
Ordered-collection<> *
joueur
Analyse Conception
3. CONCEPTION
Quelques exemples (suite)
process
Régulateur
régulateur
objet
Compte
compte
Analyse Conceptio
n
3. CONCEPTION
Quelques exemples (suite)
* Personne
Personne Société
Société ID Société
ID
Société
Personne
Société Key société nom * nom
{ société adresse * adresse
Analyse Conception
4. IMPLÉMENTATION
Validité
Robustesse
Objectifs à atteindre Réutilisation
Extensibilité
Compatibilité
Fiabilité
Lisibilité
4. IMPLÉMENTATION
- Avec un langage orienté objet (C++)
- Avec un langage non totalement objet (ADA)
- Avec un langage non orienté objet (C)
- Avec une base de données relationnelle

4. IMPLÉMENTATION
Avec un Langage Orienté Objet (C++)
La translation est directe :
Fenêtre class Fenetre

{
xmin :
Entier
xmax :
Entier
ymin :
Create (xo : Entier, yo : Entier, public :
$Entier
largeur Fenetre (int xo, int yo,
ymax : : Entier, longueur, Entier)
int largeur, int longueur)
Entier
deplacer void deplacer () ;
() private
int xmin, ymin, xmax, ymax
}
4. IMPLÉMENTATION
Avec un langage non totalement objet (Ada)
package class_Fenetre
type Fenetre is private
function create (xmin, ymin, largeur, longueur : Entier)
return Fenetre;
procedure deplacer (self : Fenêtre);
private :
type Fenetre is record
xmin : Entier;
ymin : Entier;
xmax : Entier;
ymax : Entier
end record;
end class_Fenetre
4. IMPLÉMENTATION
Avec un langage non objet (C)
Fichier fenetre.h
struct Fenêtre
{
int xmin;
int ymin;
int xmax;
int ymax;
};
Fenêtre create (int xo, int yo, int largeur, int longueur);
void deplacer ();
4. IMPLÉMENTATION
Avec une base de données relationnelle
Person
Object Person
ID
person name
Model address conception person name
address
Attribute name Nulls? Domain

Person table : person-ID N ID
person-name N name
address Y address
Table Candidate key: (person-ID)
Model Primary key: (person-ID)
Frequently accessed: (person-ID) (person_name)
CREATE TABLE Person

( person-ID ID not null ,
SQL person-name char (30) not null ,
Code adress char (30) ,
PRIMARY KEY (person-ID) ) ;
CREATE SECONDARY INDEX Person-index-name
ON Person (person-name) ;
5. Résumé d ’UML
Approche par les Use cases
Analyse
Cas d’utilisation
Diagrammes de classes
Diagramme de séquences
Diagrammes de Collaboration
Diagrammes d’activités
Diagrammes d’états-transitions
Diagrammes de composants
Diagrammes de déploiement
Implémentation
5. RÉSUMÉ D’UML
NOTATION
Classes
Relation
5. RÉSUMÉ D’UML
NOTATION
Use cases
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION
5. RÉSUMÉ D’UML
NOTATION

Conception Des SI À Base D'objets

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Des SI À Base D'objets

Transféré par

Droits d'auteur :

Formats disponibles

Bilal Hussein

Interaction entre les modules.

 Regroupement des données-traitements

Association, Généralisation, Composition,

 OOD (Booch, 91-93)

 OOM merise (Bouzeghoub, 93)

 OOSE (Jacobson, 94)

 OMT (Rumbaugt, 93)

 Unifié en 1995, UML V0.8

 Identification des parties

 Conception par assemblage

Unified Method 0.8

Other methodsBooch method OMT OOSE

 Inception Définir le cadre du projet

 Elaboration Analyser le domaine, établir une

Prelim ... Arch ... Dev Dev ... Trans ...

Version Version Version Version Version Version Version Version

Une itération est une séquence d’activités planifiée

Exigences Use Case Modèles

Conception Concept. Dépl.

ModèlesConcept. Déploiement Diagramme

ModèlesConcept. Les tests font

Client Analyste Architecte Programmeur Testeur

Les cas d ’utilisation

Les use cases permettent de communiquer entre différents groupes de personnes

Chaque abonné après connexion pourra ainsi saisir un message et l'envoyer à

L'ensemble des informations d'administration seront centralisées sur un serveur. Tout

Envoi Envoi connexion

Formaliser la phase en amont de l'analyse et donner des

Définir les acteurs externes et leur interaction avec le système.

Définir les premiers éléments d’architecture système.

Utilisateur envoi message Administrateu

 Un diagramme de use case

Pilot Confirmer Emplo

 Relations standards des use case

Informations Produit Mode de

Développer les scénarios (texte), diagramme de trace d'évènements, diagramme

 Répéter les étapes ci-dessus autant de fois que nécessaire

réseau messagerie Message non lu Prévenir

Poste PC Unix Ethernet Message lu Durée de vie

Abonné Lire message administrateur inscription

connexion Saisir message serveur

Le dictionnaire s’enrichira des éléments de modèles au fur et à mesure de leurs constructions

 les classes redondantes

affichage écran principal

Connexion réussie d'un utilisateur

Connexion réussie d'un utilisateur

mot de passe l ’abonné

Vérifier mot de passe (mot de passe)

Connexion réussie d'un utilisateur

 Aspect temporel des relations entre objets

 Enchaînement des tâches

écho sonnerie sonnerie

Appel téléphonique : appelé non occupé

 Le délai d'acheminement d'un message peut être

Appel téléphonique appelé non occupé

Une variante du diagramme de trace d'événements consiste à modifier alternativement la

echo sonnerie sonnerie

Appel téléphonique appelé non occupé

L'acheminement d'un message détermine implicitement l'envoi d'une réponse par le

leControlleur unSegment origine:Point fin:Point

 Aspect topologique des relations entre objets

wire Contenu {new}