Académique Documents
Professionnel Documents
Culture Documents
Pour les grandes entreprises, le taux de succs est de 9% seulement, 37% des projets sont
arrts en cours de ralisation, 50% aboutissent hors dlai et hors budget.
Lexamen des causes de succs et dchec est instructif : la plupart des checs proviennent
non de linformatique, mais de la matrise douvrage (i.e. le client). Pour ces raisons, le
dveloppement de logiciels dans un contexte professionnel suit souvent des rgles strictes
encadrant la conception et permettant le travail en groupe et la maintenance du code. Ainsi,
une nouvelle discipline est ne : le gnie logiciel.
lanalyse du besoin,
llaboration des spcifications,
la conceptualisation,
le dveloppement,
la phase de test,
la maintenance.
Validit : aptitude dun produit logiciel remplir exactement ses fonctions, dfinies
par le cahier des charges et les spcifications.
Fiabilit ou robustesse : aptitude dun produit logiciel fonctionner dans des
conditions anormales.
Extensibilit (maintenance) : facilit avec laquelle un logiciel se prte sa
maintenance, cest--dire une modification ou une extension des fonctions qui lui
sont demandes.
Rutilisabilit : aptitude dun logiciel tre rutilis, en tout ou en partie, dans de
nouvelles applications.
Compatibilit : facilit avec laquelle un logiciel peut tre combin avec dautres
logiciels.
Efficacit : Utilisation optimales des ressources matrielles.
Portabilit : facilit avec laquelle un logiciel peut tre transfr sous diffrents
environnements matriels et logiciels.
Vrifiabilit : facilit de prparation des procdures de test.
Intgrit : aptitude dun logiciel protger son code et ses donnes contre des accs
non autoriss.
Facilit demploi : facilit dapprentissage, dutilisation, de prparation des donnes,
dinterprtation des erreurs et de rattrapage en cas derreur dutilisation.
Ces facteurs sont parfois contradictoires, le choix des compromis doit seffectuer en fonction
du contexte.
dtecter les erreurs au plus tt et ainsi de matriser la qualit du logiciel, les dlais de sa
ralisation et les cots associs.
Le cycle de vie du logiciel comprend gnralement au minimum les tapes suivantes :
Dfinition des objectifs Cet tape consiste dfinir la finalit du projet et son
inscription dans une stratgie globale.
Analyse des besoins et faisabilit cest--dire lexpression, le recueil et la
formalisation des besoins du demandeur (le client) et de lensemble des contraintes,
puis lestimation de la faisabilit de ces besoins.
Spcifications ou conception gnrale Il sagit de llaboration des spcifications
de larchitecture gnrale du logiciel.
Conception dtaille Cette tape consiste dfinir prcisment chaque sousensemble du logiciel.
Codage (Implmentation ou programmation) cest la traduction dans un langage
de programmation des fonctionnalits dfinies lors de phases de conception.
Tests unitaires Ils permettent de vrifier individuellement que chaque sousensemble du logiciel est implment conformment aux spcifications.
Intgration Lobjectif est de sassurer de linterfaage des diffrents lments
(modules) du logiciel. Elle fait lobjet de tests dintgration consigns dans un
document.
Qualification (ou recette) Cest--dire la vrification de la conformit du logiciel
aux spcifications initiales.
Documentation Elle vise produire les informations ncessaires pour lutilisation
du logiciel et pour des dveloppements ultrieurs.
Mise en production Cest le dploiement sur site du logiciel.
Maintenance Elle comprend toutes les actions correctives (maintenance corrective)
et volutives (maintenance volutive) sur le logiciel.
Notion de classe : une classe est un type dobjet caractris par des attributs et des mthodes.
Elle est utilise comme modle pour crer ou instancier des objets.
Encapsulation : Lencapsulation consiste masquer les dtails dun objet, en dfinissant une
interface. Linterface est la vue externe dun objet, elle dfinit les services
accessibles aux utilisateurs de lobjet.
Hritage : Lhritage permet la transmission des caractristiques dune classe vers une sousclasse.
Polymorphisme : reprsente la facult dune mthode pouvoir sappliquer des objets de
classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.
Agrgation : Il sagit dune relation entre deux classes, spcifiant que les objets dune classe
sont des composants de lautre classe. Une relation dagrgation permet donc de
dfinir des objets composs dautres objets. Lagrgation permet donc dassembler
des objets de base, afin de construire des objets plus complexes.
1.4 UML
UML nest pas une mthode : ses auteurs ont en effet estim quil ntait pas opportun de
dfinir une mthode en raison de la diversit des cas particuliers. Ils ont prfr se borner
dfinir un langage graphique qui permet de reprsenter et de communiquer les divers aspects
dun systme dinformation. Aux graphiques sont bien sr associs des textes qui expliquent
leur contenu.
UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes
pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en
deux grands groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure)
diagramme de classes (Class diagram)
diagramme dobjets (Object diagram)
diagramme de composants (Component diagram)
diagramme de dploiement (Deployment diagram)
diagramme de paquetages (Package diagram)
diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
diagramme de cas dutilisation (Use case diagram)
diagramme dactivits (Activity diagram)
diagramme dtats-transitions (State machine diagram)
Diagrammes dinteraction (Interaction diagram)
o diagramme de squence (Sequence diagram)
o diagramme de communication (Communication diagram)
o diagramme global dinteraction (Interaction overview diagram)
o diagramme de temps (Timing diagram)
Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits
loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les
diagrammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtatstransitions. Les diagrammes de composants, de dploiement et de communication sont surtout
utiles pour la matrise duvre qui ils permettent de formaliser les contraintes de la
ralisation et la solution technique.
Figure 2.2: Exemple de reprsentation dun acteur sous la forme dun classeur
une fin, pour lacteur qui linitie. Un cas dutilisation modlise donc un service rendu par le
systme, sans imposer le mode de ralisation de ce service.
Un cas dutilisation se reprsente par une ellipse (figure 2.3) contenant le nom du cas (un
verbe linfinitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.4.4).
Figure 2.4: Exemple de reprsentation dun cas dutilisation sous la forme dun classeur
Figure 2.5: Exemple simplifi de diagramme de cas dutilisation modlisant une borne
daccs une banque.
Comme le montre la figure 2.5, la frontire du systme est reprsente par un cadre. Le nom
du systme figure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas
dutilisation lintrieur.
les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss
sont linclusion et lextension),
et la gnralisation/spcialisation.
Une dpendance se reprsente par une flche avec un trait pointill (figure 2.7). Si le cas A
inclut ou tend le cas B, la flche est dirige de A vers B.
Le symbole utilis pour la gnralisation est une flche avec un trait plein dont la pointe est
un triangle ferm dsignant le cas le plus gnral (figure 2.7).
Relation dinclusion
Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas
B : le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie de
A. Cette dpendance est symbolise par le strotype << include >> (figure 2.7). Par
exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase
dauthentification avec un identifiant et un mot de passe (figure 2.7).
Les inclusions permettent essentiellement de factoriser une partie de la description dun cas
dutilisation qui serait commune dautres cas dutilisation (cf. le cas Sauthentifier de la
figure 2.7).
Le symbole utilis pour la gnralisation entre acteurs est une flche avec un trait plein dont
la pointe est un triangle ferm dsignant lacteur le plus gnral (comme nous lavons dj vu
pour la relation de gnralisation entre cas dutilisation).
Par exemple, la figure 2.9 montre que le directeur des ventes est un prpos aux commandes
avec un pouvoir supplmentaire : en plus de pouvoir passer et suivre une commande, il peut
grer le stock. Par contre, le prpos aux commandes ne peut pas grer le stock.
Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce qui
est lextrieur et qui interagit avec le systme est un acteur, tout ce qui est lintrieur est
une fonctionnalit raliser.
Vrifiez que les acteurs communiquent bien directement avec le systme par mission ou
rception de messages. Une erreur frquente consiste rpertorier en tant quacteur des
entits externes qui ninteragissent pas directement avec le systme, mais uniquement par le
biais dun des vritables acteurs. Par exemple, lhtesse de caisse dun magasin de grande
distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasin ne
correspondent pas un acteur car ils ninteragissent pas directement avec la caisse.
Des scnarii : Ces scnarii sont dcrits sous la forme dchanges dvnements entre
lacteur et le systme. On distingue le scnario nominal, qui se droule quand il ny a
pas derreur, des scnarii alternatifs qui sont les variantes du scnario nominal et enfin
les scnarii dexception qui dcrivent les cas derreurs.
Des postconditions : Elle dcrivent ltat du systme lissue des diffrents scnarii.
Une classe est la description formelle dun type dobjets ayant une smantique et des
caractristiques communes.
Un objet est une instance dune classe. Cest une entit discrte dote dune identit, dun tat
et dun comportement que lon peut invoquer. Les objets sont des lments individuels dun
systme en cours dexcution.
Ce sont les attributs et gnralement les terminaisons dassociations, tous deux runis
sous le terme de proprits structurelles, ou tout simplement proprits, qui dcrivent
ltat dun objet. Les attributs sont utiliss pour des valeurs de donnes pures,
dpourvues didentit, telles que les nombres et les chanes de caractres. Les
associations sont utilises pour connecter les classes du diagramme de classe ; dans ce
cas, la terminaison de lassociation (du ct de la classe cible) est gnralement une
proprit de la classe de base (cf. section 3.3.1 et 3.3.2).
Les proprits dcrites par les attributs prennent des valeurs lorsque la classe est
instancie. Linstance dune association est appele un lien.
Comportement dun objet :
Les oprations dcrivent les lments individuels dun comportement que lon peut
invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entre et modifier
les attributs ou produire des rsultats.
Une opration est la spcification (i.e. dclaration) dune mthode. Limplmentation
(i.e. dfinition) dune mthode est galement appele mthode. Il y a donc une
ambigut sur le terme mthode.
Les attributs, les terminaisons dassociation et les mthodes constituent donc les
caractristiques dune classe (et de ses instances).
modlisation, la date, etc. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef
abstract.
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ]
<Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]
Mta-langage des syntaxes
< >
:
les cotes sont utiles quand on veut utiliser un mta-caractre comme un caractre ; par
exemple, pour dsigner un crochet ([) il faut crire [ car [ est un mta-caractre
ayant une signification spciale ;
...
:
permet de dsigner une suite de squence de longueur non dfinie, le contexte
permettant de comprendre de quelle suite il sagit.
Le type de lattribut (<type>) peut tre un nom de classe, un nom dinterface ou un type de
donn prdfini. La multiplicit (<multiplicit>) dun attribut prcise le nombre de valeurs
que lattribut peut contenir. Lorsquune multiplicit suprieure 1 est prcise, il est possible
dajouter une contrainte ({<contrainte>}) pour prciser si les valeurs sont ordonnes
({ordered}) ou pas ({list}).
Attributs de classe
Par dfaut, chaque instance dune classe possde sa propre copie des attributs de la classe. Les
valeurs des attributs peuvent donc diffrer dun objet un autre. Cependant, il est parfois
ncessaire de dfinir un attribut de classe (static en Java ou en C++) qui garde une valeur
unique et partage par toutes les instances de la classe. Les instances ont accs cet attribut
mais nen possdent pas une copie. Un attribut de classe nest donc pas une proprit dune
instance mais une proprit de la classe et laccs cet attribut ne ncessite pas lexistence
dune instance.
Graphiquement, un attribut de classe est soulign.
Attributs drivs
Les attributs drivs peuvent tre calculs partir dautres attributs et de formules de calcul.
Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu ce que
vous puissiez dterminer les rgles lui appliquer.
Les attributs drivs sont symboliss par lajout dun / devant leur nom.
Comme pour les attributs de classe, il est possible de dclarer des mthodes de classe. Une
mthode de classe ne peut manipuler que des attributs de classe et ses propres paramtres.
Cette mthode na pas accs aux attributs de la classe (i.e. des instances de la classe). Laccs
une mthode de classe ne ncessite pas lexistence dune instance de cette classe.
Graphiquement, une mthode de classe est souligne.
Mthodes et classes abstraites
Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle peut
tre ralise (i.e. on connat sa dclaration mais pas sa dfinition).
Une classe est dite abstraite lorsquelle dfinit au moins une mthode abstraite ou lorsquune
classe parent (cf. section 3.3.9) contient une mthode abstraite non encore ralise.
On ne peut instancier une classe abstraite : elle est voue se spcialiser (cf. section 3.3.9).
Une classe abstraite peut trs bien contenir des mthodes concrtes.
Une classe abstraite pure ne comporte que des mthodes abstraites. En programmation
oriente objet, une telle classe est appele une interface.
Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef abstract derrire son nom.
Figure 3.4: Utilisation dun petit cercle plein pour prciser le propritaire dune terminaison
dassociation.
Par exemple, le diagramme de la figure 3.4 prcise que la terminaison dassociation sommet
(i.e. la proprit sommet) appartient la classe Polygone tandis que la terminaison
dassociation polygone (i.e. la proprit polygone) appartient lassociation Dfini par.
Une terminaison dassociation est une proprit
Une proprit est une caractristique structurelle. Dans le cas dune classe, les proprits sont
constitues par les attributs et les ventuelles terminaisons dassociation que possde la classe.
Dans le cas dune association, les proprits sont constitues par les terminaisons
dassociation que possde lassociation. Attention, une association ne possde pas forcment
toutes ses terminaisons dassociation !
Une proprit peut tre paramtre par les lments suivant (on sintresse ici essentiellement
aux terminaisons dassociations puisque les attributs ont t largement traits section 3.2) :
Nom : Comme un attribut, une terminaison dassociation peut tre nomme. Le nom
est situ proximit de la terminaison, mais contrairement un attribut, ce nom est
facultatif. Le nom dune terminaison dassociation est appele nom du rle. Une
association peut donc possder autant de noms de rle que de terminaisons (deux pour
une association binaire et n pour une association n-aire).
Visibilit : Comme un attribut, une terminaison dassociation possde une visibilit
(cf. section 3.2.4). La visibilit est mentionne proximit de la terminaison, et plus
prcisment, le cas chant, devant le nom de la terminaison.
Multiplicit : Comme un attribut, une terminaison dassociation peut possder une
multiplicit. Elle est mentionne proximit de la terminaison. Il nest pas impratif
de la prciser, mais, contrairement un attribut dont la multiplicit par dfaut est 1, la
multiplicit par dfaut dune terminaison dassociation est non spcifie.
Linterprtation de la multiplicit pour une terminaison dassociation est moins
vidente que pour un attribut (cf. section 3.3.4).
Navigabilit : Pour un attribut, la navigabilit est implicite, navigable, et toujours
depuis la classe vers lattribut. Pour une terminaison dassociation, la navigabilit peut
tre prcise (cf. section 3.3.5).
Quand les deux extrmits de lassociation pointent vers la mme classe, lassociation est dite
rflexive.
Association n-aire
exactement un : 1 ou 1..1
plusieurs : * ou 0..*
au moins un : 1..*
de un six : 1..6
Dans une association binaire (cf. figure 3.5), la multiplicit sur la terminaison cible contraint
le nombre dobjets de la classe cible pouvant tre associs un seul objet donn de la classe
source (la classe de lautre terminaison de lassociation).
Dans une association n-aire, la multiplicit apparaissant sur le lien de chaque classe
sapplique sur une instance de chacune des classes, lexclusion de la classe-association et de
la classe considre. Par exemple, si on prend une association ternaire entre les classes (A, B,
C), la multiplicit de la terminaison C indique le nombre dobjets C qui peuvent apparatre
dans lassociation (dfinie section 3.3.7) avec une paire particulire dobjets A et B.
Remarque 1 :
Pour une association n-aire, la multiplicit minimale doit en principe, mais pas
ncessairement, tre 0. En effet, une multiplicit minimale de 1 (ou plus) sur une extrmit
implique quil doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des
instances des classes situes aux autres extrmits de lassociation n-aire !
Remarque 2 :
Il faut noter que, pour les habitus du modle entit/relation, les multiplicits sont en UML
lenvers (par rfrence Merise) pour les associations binaires et lendroit pour les naires avec n>2.
3.3.5 Navigabilit
3.3.6 Qualification
Figure 3.10: En haut, un diagramme reprsentant lassociation entre une banque et ses clients
( gauche), et un diagramme reprsentant lassociation entre un chiquier et les cases qui le
composent ( droite). En bas, les diagrammes quivalents utilisant des associations qualifies
Gnralement, une classe peut tre dcompose en sous-classes ou possder plusieurs
proprits. Une telle classe rassemble un ensemble dlments (dobjets). Quand une classe
est lie une autre classe par une association, il est parfois prfrable de restreindre la porte
de lassociation quelques lments cibls (comme un ou plusieurs attributs) de la classe. Ces
lments cibls sont appels un qualificatif. Un qualificatif permet donc de slectionner un ou
des objets dans le jeu des objets dun objet (appel objet qualifi) reli par une association
un autre objet. Lobjet slectionn par la valeur du qualificatif est appel objet cible.
Lassociation est appele association qualifie. Un qualificatif agit toujours sur une
association dont la multiplicit est plusieurs (avant que lassociation ne soit qualifie) du ct
cible.
Un objet qualifi et une valeur de qualificatif gnrent un objet cible li unique. En
considrant un objet qualifi, chaque valeur de qualificatif dsigne un objet cible unique.
Par exemple, le diagramme de gauche de la figure 3.10 nous dit que :
Un compte dans une banque appartient au plus deux personnes. Autrement dit, une
instance du couple {Banque, compte} est en association avec zro deux instances de
la classe Personne.
Mais une personne peut possder plusieurs comptes dans plusieurs banques. Cest-dire quune instance de la classe Personne peut tre associe plusieurs (zro
compris) instances du couple {Banque, compte}.
Bien entendu, et dans tous les cas, un instance du couple {Personne, compte} est en
association avec une instance unique de la classe Banque.
Une instance du triplet {Echiquier, range, colonne} est en association avec une
instance unique de la classe Case.
Inversement, une instance de la classe Case est en association avec une instance
unique du triplet {Echiquier, range, colonne}.
3.3.7 Classe-association
Dfinition et reprsentation
associations doivent disposer des mmes caractristiques, elles doivent hriter dune mme
classe possdant ces caractristiques, ou lutiliser en tant quattribut.
De mme, il nest pas possible de rattacher une instance de la classe dune classe-association
plusieurs instances de lassociation de la classe-association. En effet, la reprsentation
graphique (association relie par une ligne pointill une classe dporte) est trompeuse : une
classe-associaiton est une entit smantique atomique et non composite qui sintancie donc en
bloc. Ce problme et nouveau abord et illustr section 3.5.2.
Auto-association sur classe-association
Il nest souvent pas simple trancher entre lutilisation dune classe-association, dune
association n-aire ou encore dune association qualifie. Lorsque lon utilise lun de ces trois
types dassociation, il peut tre utile ou instructif de se demander si lun des deux autres types
ne serait pas plus pertinent. Dans tous les cas, il faut garder lesprit quune classeassociation est dabord et avant tout une association et que, dans une classe-association, la
classe est indissociable de lassociation.
Figure 3.16: Pour couvrir le cas des comptes joints, il faut utiliser le modle de droite
Ainsi, le cas dun compte joint ne peut tre reprsent correctement par le diagramme de
gauche dans figure 3.16 : mieux vaut utiliser une association qualifie (diagramme de droite
dans la figure 3.16). Ce problme et nouveau abord et illustr section 3.5.2.
Figure 3.17: Si un cours doit pouvoir exister indpendamment dun lien entre un enseignant et
un groupe, il faut utiliser le modle de droite
Dans le diagramme de gauche de la figure 3.17, un cours ne peut exister que sil existe un lien
entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effac), le cours lest
galement. Si un cours doit pouvoir exister indpendamment de lexistence dun lien (on a pas
encore trouv denseignant pour ce cours, le cours nest pas enseign cette anne mais le sera
probablement lanne prochaine, ) il faut opter pour une association ternaire (modle de
droite dans figure 3.17).
La classe enfant possde toutes les caractristiques des ses classes parents, mais elle
ne peut accder aux caractristiques prives de cette dernire.
Une classe enfant peut redfinir (mme signature) une ou plusieurs mthodes de la
classe parent. Sauf indication contraire, un objet utilise les oprations les plus
spcialises dans la hirarchie des classes.
Toutes les associations de la classe parent sappliquent aux classes drives.
Une instance dune classe peut tre utilise partout o une instance de sa classe parent
est attendue. Par exemple, en se basant sur le diagramme de la figure 3.20, toute
opration acceptant un objet dune classe Animal doit accepter un objet de la classe
Chat.
Une classe peut avoir plusieurs parents, on parle alors dhritage multiple (cf. la classe
Ornithorynque de la figure 3.20). Le langage C++ est un des langages objet permettant
son implmentation effective, le langage Java ne le permet pas.
En UML, la relation dhritage nest pas propre aux classes. Elle sapplique dautre
lments du langage comme les paquetages, les acteurs (cf. section 2.3.3) ou les cas
dutilisation (cf. section 2.3.2).
3.3.10 Dpendance
3.4 Interfaces
Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits.
Par exemple, le diagramme de classes de la figure 3.23 montre quune entreprise emploie au
moins deux personnes et quune personne travaille dans au plus deux entreprises. Le
diagramme dobjets modlise lui une entreprise particulire (PERTNE) qui emploie trois
personnes.
Un diagramme dobjets ne montre pas lvolution du systme dans le temps. Pour reprsenter
une interaction, il faut utiliser un diagramme de communication (cf. section 7.2) ou de
squence (cf. section 7.3).
3.5.2 Reprsentation
Figure 3.24: Le diagramme dobjets de droite, illustrant le cas de figure dun compte joint,
nest pas une instance normale du diagramme de classe de gauche mais peut prciser une
situation exceptionnelle
La norme UML 2.1.1 prcise quune instance de classe-association ne peut tre associe qu
une instance de chacune des classes associes ce qui interdit dinstancier le diagramme de
classe gauche dans la figure 3.24 par le diagramme dobjet droite dans cette mme figure.
Cependant, un diagramme dobjet peut tre utilis pour exprimer une exception. Sur la figure
3.24, le diagramme dobjets droite peut tre lgitime sil vient prciser une situation
exceptionnelle non prise en compte par le diagramme de classe reprsent gauche.
Nanmoins, le cas des comptes joints ntant pas si exceptionnel, mieux vaut revoir la
modlisation comme prconise par la figure 3.16.
Parfois, la gnration automatique de code produit, pour chaque classe, un constructeur et une
mthode finalize comme ci-dessous. Rappelons que cette mthode est invoque par le
ramasse miettes lorsque celui-ci constate que lobjet nest plus rfrenc. Pour des raisons de
simplification, nous ne ferons plus figurer ces oprations dans les sections suivantes.
public class A {
public A() {
...
}
protected void finalize() throws Throwable {
super.finalize();
...
}
}
public class A {
public
String a1;
package
String a2;
protected String a3;
private
String a4;
public void op1() {
...
}
public void op2() {
...
}
}
Classe abstraite
...
}
Interface
public interface A {
...
}
Hritage simple
public class A {
...
}
public class B extends A {
...
}
public interface Ia {
...
}
public class A implements Ia {
...
}
public class A {
private B rb;
public void addB( B b ) {
if( b != null ){
if ( b.getA() != null ) {
// si b est dj connect un autre A
b.getA().setB(null);
// cet autre A doit se dconnecter
}
this.setB( b );
b.setA( this );
}
}
public B getB() { return( rb ); }
public void setB( B b ) { this.rb=b; }
}
public class B {
private A ra;
public void addA( A a ) {
if( a != null ) {
if (a.getB() != null) {
// si a est dj connect un autre B
a.getB().setA( null ); // cet autre B doit se dconnecter
}
this.setA( a );
a.setB( this );
}
}
public void setA(A a){ this.ra=a; }
public A getA(){ return(ra); }
}
public class A {
private B rb;
public void addB( B b ) {
if( b != null ) {
this.rb=b;
}
}
}
public class B {
... // La classe B ne connat pas l'existence de la classe A
}
public class A {
private ArrayList <B> rb;
public A() { rb = new ArrayList<B>(); }
public ArrayList <B> getArray() {return(rb);}
public void remove(B b){rb.remove(b);}
public void addB(B b){
if( !rb.contains(b) ){
if (b.getA()!=null) b.getA().remove(b);
b.setA(this);
rb.add(b);
}
}
}
public class B {
private A ra;
public B() {}
public A getA() { return (ra); }
public void setA(A a){ this.ra=a; }
public void addA(A a){
if( a != null ) {
if( !a.getArray().contains(this)) {
if (ra != null) ra.remove(this);
this.setA(a);
ra.getArray().add(this);
}
}
}
}
public class A {
Association 1 vers N
Dans ce cas, il faut utiliser un tableau plutt quun vecteur. La dimension du tableau tant
donnes par la cardinalit de la terminaison dassociation.
Agrgations
Dans la section 9.3.1, nous prsentons un type de diagramme de classes, appel modle du
domaine, tout fait adapt une implmentation sous forme de base de donnes.
Classe avec attributs
Chaque classe devient une relation. Les attributs de la classe deviennent des attributs de la
relation. Si la classe possde un identifiant, il devient la cl primaire de la relation, sinon, il
faut ajouter une cl primaire arbitraire.
Association 1 vers 1
Pour reprsenter une association 1 vers 1 entre deux relations, la cl primaire de lune des
relations doit figurer comme cl trangre dans lautre relation.
Hritage
Les relations correspondant aux sous-classes ont comme cl trangre et primaire la cl de la
relation correspondant la classe parente. Un attribut type est ajout dans la relation
correspondant la classe parente. Cet attribut permet de savoir si les informations dun tuple
de la relation correspondant la classe parente peuvent tre compltes par un tuple de lune
des relations correspondant une sous-classe, et, le cas chant, de quelle relation il sagit.
Ainsi, dans cette solution, un objet peut avoir ses attributs rpartis dans plusieurs relations. Il
faut donc oprer des jointures pour reconstituer un objet. Lattribut type de la relation
correspondant la classe parente doit indiquer quelles jointures faire.
Une alternative cette reprsentation est de ne crer quune seule table par arborescence
dhritage. Cette table doit contenir tous les attributs de toutes les classes de larborescence
plus lattribut type dont nous avons parl ci-dessus. Linconvnient de cette solution est
quelle implique que les tuples contiennent de nombreuses valeurs nulles.
create table relation_ABC (
id_C integer primary key,
attC1 text, attC2 integer,
attA1 text, attA2 integer,
attB1 text, attB2 integer,
type text);
Contraintes structurelles : les attributs dans les classes, les diffrents types de
relations entre classes (gnralisation, association, agrgation, composition,
dpendance), la cardinalit et la navigabilit des proprits structurelles, etc.
Contraintes de type : typage des proprits, etc.
Contraintes diverses : les contraintes de visibilit, les mthodes et classes abstraites
(contrainte abstract), etc.
Dans la pratique, toutes ces contraintes sont trs utiles mais se rvlent insuffisantes.
Toutefois, UML permet de spcifier explicitement des contraintes particulires sur des
lments de modle.
naturel ;
ddi, comme OCL ;
ou encore directement issu dun langage de programmation.
Si une contrainte possde un nom, on prsente celui-ci sous forme dune chane suivie dun
double point (:), le tout prcdant le texte de la contrainte.
Figure 4.1: UML permet dassocier une contrainte un lment de modle de plusieurs
faons. Sur les deux diagrammes du haut, la contrainte porte sur un attribut qui doit tre
positif. En bas gauche, la contrainte {frozen} prcise que le nombre de roues dun vhicule
ne peut pas varier. Au milieu, la contrainte {subset} prcise que le prsident est galement un
membre du comit. Enfin, en bas droite, la contrainte {xor} (ou exclusif) prcise que les
employs de lhtel nont pas le droit de prendre une chambre dans ce mme htel.
Figure 4.2: Ce diagramme exprime que : une personne est ne dans un pays, et que cette
association ne peut tre modifie ; une personne a visit un certain nombre de pays, dans un
ordre donn, et que le nombre de pays visits ne peut que crotre ; une personne aimerait
encore visiter tout une liste de pays, et que cette liste est ordonne (probablement par ordre de
prfrence).
UML permet dassocier une contrainte un, ou plusieurs, lment(s) de modle de diffrentes
faons (cf. figure 4.1) :
Nous venons de voir, au travers des exemples de la figure 4.1, quelques contraintes
prdfinies ({frozen}, {subset} et {xor}). Le diagramme de la figure 4.2 en introduit deux
nouvelles : {ordered} et {addOnly}. La liste est encore longue, mais le pouvoir expressif de
ces contraintes reste insuffisant comme nous le verrons dans la section 4.2.2. Le langage de
contraintes objet OCL apporte une solution lgante cette insuffisance.
Cest avec OCL (Object Constraint Language) quUML formalise lexpression des
contraintes . Il sagit donc dun langage formel dexpression de contraintes bien adapt aux
diagrammes dUML, et en particulier au diagramme de classes.
OCL existe depuis la version 1.1 dUML et est une contribution dIBM. OCL fait partie
intgrante de la norme UML depuis la version 1.3 dUML. Dans le cadre dUML 2.0, les
spcifications du langage OCL figurent dans un document indpendant de la norme dUML,
dcrivant en dtail la syntaxe formelle et la faon dutiliser ce langage.
OCL peut sappliquer sur la plupart des diagrammes dUML et permet de spcifier des
contraintes sur ltat dun objet ou dun ensemble dobjets comme :
Pourquoi OCL ?
Nous avons dit que les contraintes pouvaient tre crites en langage naturel, alors pourquoi
sembarrasser du langage OCL ? Lintrt du langage naturel est quil est simple mettre en
uvre et comprhensible par tous. Par contre (et comme toujours), il est ambigu et imprcis,
il rend difficile lexpression des contraintes complexes et ne facilite pas les rfrences
dautres lments (autres que celui sur lequel porte la contrainte) du modle.
OCL est un langage formel volontairement simple daccs. Il possde une grammaire
lmentaire (OCL peut tre interprt par des outils) que nous dcrirons dans les sections 4.3
4.6. OCL reprsente, en fait, un juste milieu entre le langage naturel et un langage trs
technique (langage mathmatique, informatique, ). Il permet ainsi de limiter les ambiguts,
tout en restant accessible.
Diagramme de classes
Figure 4.3: Diagramme de classes modlisant une banque, ses clients et leurs comptes
La figure 4.3 montre un diagramme de classes correspondant la problmatique que nous
venons de dcrire.
Figure 4.5: Diagramme dobjets cohrent avec le diagramme de classes de la figure 4.4
Figure 4.6: Diagramme dobjets cohrent avec le diagramme de classes de la figure 4.4, mais
reprsentant une situation inacceptable
Cependant, dautres problmes subsistent. La figure 4.5 montre un diagramme dobjets valide
vis--vis du diagramme de classes de la figure 4.4 et galement valide vis--vis de la
spcification du problme. Par contre, la figure 4.6 montre un diagramme dobjets valide vis-vis du diagramme de classes de la figure 4.4 mais ne respectant pas la spcification du
problme. En effet, ce diagramme dobjets montre une personne (P1) ayant un compte dans
une banque sans en tre client. Ce diagramme montre galement un client ( P2) dune banque
ny possdant pas de compte.
context Compte
inv : solde > 0
En crivant la contrainte entre accolades ({}) dans une note (comme nous lavons fait
sur la figure 4.4). Llment point par la note est alors le contexte de la contrainte.
En utilisant le mot-clef context dans un document accompagnant le diagramme
(comme nous lavons fait sur la figure 4.7).
Syntaxe
context <lment>
peut tre une classe, une opration, etc. Pour faire rfrence un lment op
(comme un opration) dun classeur C (comme une classe), ou dun paquetage, , il faut
utiliser les :: comme sparateur (comme C::op).
<lment>
Exemple
Le contexte est la classe Compte:
context Compte
Le contexte est lopration getSolde() de la classe Compte:
context Compte::getSolde()
Syntaxe
inv : <expression_logique>
<expression_logique>
Exemple
Le solde dun compte doit toujours tre positif.
context Compte
inv : solde > 0
Les femmes (au sens de lassociation) des personnes doivent tre des femmes (au sens du
genre).
context Personne
inv : femme->forAll(genre=Genre::femme)
self est dcrit section 4.5.1 et forAll() section 4.6.3.
Syntaxe
Prcondition :
pre : <expression_logique>
Postcondition :
post : <expression_logique>
<expression_logique>
Exemple
Concernant la mthode dbiter de la classe Compte, la somme dbiter doit tre positive pour
que lappel de lopration soit valide et, aprs lexcution de lopration, lattribut solde doit
avoir pour valeur la diffrence de sa valeur avant lappel et de la somme passe en paramtre.
Mme si cela peut sembler tre le cas dans ces exemples, nous navons pas dcrit comment
lopration est ralise, mais seulement les contraintes sur ltat avant et aprs son excution.
est une expression qui retourne un rsultat dont le type doit tre compatible avec
le type du rsultat de lopration dsigne par le contexte.
<requte>
Exemple
Voici une autre solution au deuxime exemple de la section 4.3.4 : le rsultat de lappel de
lopration getSolde doit tre gal lattribut solde.
context Compte::getSolde() : Real
body : solde
Un nouvel attribut dclar dans <dclaration> aura la valeur retourne par lexpression
<requte> dans toute lexpression <expression>.
context Personne
inv : let argent=compte.solde->sum() in age>=18 implies argent>0
context Personne
def : argent : int = compte.solde->sum()
context Personne
inv : age>=18 implies argent>0
Exemple
Quand on cre une personne, la valeur initiale de lattribut mari est faux et la personne ne
possde pas demployeur :
Type
Exemples de valeurs
Oprateurs
Boolean
true ; false
Integer 1 ; 5 ; 2 ; 34 ; 26524 ;
Real
1,5 ; 3,14 ;
* ; + ; ; / ; abs() ;
* ; + ; ; / ; abs() ; floor() ;
vrai
vrai
faux
vrai
vrai faux
faux
vrai
vrai
faux
faux vrai
faux
vrai
vrai
vrai
faux
faux
vrai
Tableau 4.3: Convention dinterprtation de la ngation.
Par exemple, la classe Personne possde un attribut genre de type Genre. On peut donc crire
la contrainte :
context Personne
inv : genre = Genre::femme
Dans ce cas, toutes les personnes doivent tre des femmes.
4.4.4 Collections
OCL dfinit galement la notion densemble sous le terme gnrique de collection (collection
en anglais). Il existe plusieurs sous-types du type abstrait Collection :
Ensemble (Set) :
collection non ordonne dlments uniques (i.e. pas dlment en double).
Ensemble ordonn (OrderedSet) :
collection ordonne dlments uniques.
Sac (Bag) :
collection non ordonne dlments identifiables (i.e. comme un ensemble, mais
pouvant comporter des doublons).
Squence (Sequence) :
collection ordonne dlments identifiables.
Jusqu UML 2.0 exclu, les collections taient toujours plates : une collection ne pouvait pas
possder des collections comme lments. Cette restriction nexiste plus partir dUML 2.0.
solde
self.solde
getSolde()
self.getSolde()
dbiter(1000)
self.dbiter(1000)
operation(paramtre).param_out
operation(paramtre).result
);
).
Emprunter une seule proprit structurelle peut produire un rsultat du type Set (ou
OrderedSet). Emprunter plusieurs proprits structurelles peut produire un rsultat du type
Bag (ou Sequence).
Par exemple, dans le contexte de la classe Socit (context Socit) :
Set(Personne)) ;
Figure 4.10: Diagramme illustrant une association qualifie entre une classe Banque et une
classe Personne.
Une association qualifie (cf. section3.3.6) utilise un ou plusieurs qualificatifs pour
slectionner des instances de la classe cible de lassociation. Pour emprunter une telle
association, il est possible de spcifier les valeurs, ou les instances, des qualificatifs en
utilisant des crochets ([]).
Plaons-nous dans le cadre du diagramme de la figure 4.10. Dans le contexte de banque
(context Banque), pour faire rfrence au nom des clients dont le compte porte le numro
19503800 il faut crire :
self.client[19503800].nom
Dans le cas o il y a plusieurs qualificatifs, il faut sparer chacune des valeurs par une virgule
en respectant lordre des qualificatifs du diagramme UML. Il nest pas possible de ne prciser
la valeur que de certains qualificatifs en en laissant dautres non dfinis. Par contre, il est
possible de ne prciser aucune valeur de qualificatif :
self.client.nom
Dans ce cas, le rsultat sera lensemble des noms de tous les clients de la banque.
Ainsi, si on ne prcise pas la valeur des qualificatifs en empruntant une association qualifie,
tout se passe comme si lassociation ntait pas qualifie. Dans ce cas, faites attention la
cardinalit de la cible qui change quand lassociation nest plus qualifie (cf. section3.3.6).
Cependant, dans le cas o lassociation est rflexive (cest le cas de la classe association
Mariage), il faut en plus prciser par quelle extrmit il faut emprunter lassociation. Pour
cela, on prcise le nom de rle de lune des extrmits de lassociation entre crochets ([])
derrire le nom de la classe association. Par exemple, dans le contexte de la classe Personne
(context Personne), pour accder la date de mariage de toutes les femmes, il faut crire :
self.mariage[femme].date
Opration oclIsTypeOf
oclIsTypeOf retourne vrai si le type de lobjet au titre duquel cette opration est invoqu est
exactement le mme que le type t pass en paramtre.
Par exemple, dans le contexte de Socit, lexpression directeur.oclIsTypeOf(Personne) est
vraie tandis que lexpression self.oclIsTypeOf(Personne) est fausse.
Opration oclIsKindOf
oclIsKindOf permet de dterminer si le type t pass en paramtre correspond exactement au
type ou un type parent du type de lobjet au titre duquel cette opration est invoqu.
Par exemple, supposons une classe B hritant dune classe A :
Opration oclIsNew
Lopration oclIsNew doit tre utilise dans une postcondition. Elle est vraie quand lobjet au
titre duquel elle est invoqu est cr pendant lopration (i.e. lobjet nexistait pas au moment
des prconditions).
Opration oclInState
Cette opration est utilise dans un diagramme dtats-transitions (cf. section 5). Elle est vraie
si lobjet dcrit par le diagramme dtats-transitions est dans ltat s pass en paramtre. Les
valeurs possibles du paramtre s sont les noms des tats du diagramme dtats-transitions. On
peut faire rfrence un tat imbriqu en utilisant des :: (par exemple, pour faire rfrence
un tat B imbriqu dans un tat A, on crit : A::B).
Dans tous les cas, lexpression <expression> est value pour chacun des lments de la
collection <collection>. Lexpression <expression> porte sur les caractristiques des
lments en les citant directement par leur nom. Le rsultat dpend de lopration
<opration>.
Parfois, dans lexpression <expression>, il est prfrable de faire rfrence aux
caractristiques de llment courant en utilisant la notation pointe :
<lment>.<proprit>. Pour cela, on doit utiliser la syntaxe suivante :
<collection> -> <opration>( <lment> | <expression> )
<lment> joue alors un rle ditrateur et sert de rfrence llment courant dans
lexpression <expression>.
Il est galement possible, afin dtre plus explicite, de prciser le type de cet lment :
<collection> -> <opration>( <lment> : <Type> | <expression> )
La syntaxe gnrale dune opration portant sur les lments dune collection est donc la
suivante :
<collection> -> <opration>( [ <lment> [ : <Type> ] | ] <expression> )
select
permet de gnrer une sous-collection de self ne contenant que des lments qui
satisfont lexpression logique <expression_logique>.
reject
permet de gnrer une sous-collection contenant tous les lments de self except ceux
qui satisfont lexpression logique <expression_logique>.
Par exemple, pour crire une contrainte imposant que toute socit doit possder, parmi ses
employs, au moins une personne de plus de 50 ans, on peut crire indiffremment :
1. context Socit
inv: self.employ->select(age > 50)->notEmpty()
2. context Socit
inv: self.employ->select(individu | individu.age > 50)->notEmpty()
3. context Socit
inv: self.employ->select(individu : Personne | individu.age > 50)->notEmpty()
Opration forAll et exists
Ces deux oprations permettent de reprsenter le quantificateur universel () et le
quantificateur existentiel (). Le rsultat de ces oprations est donc du type Boolean. Leur
syntaxe est la suivante :
forAll( [ <lment> [ : <Type> ] | ] <expression_logique> )
exists( [ <lment> [ : <Type> ] | ] <expression_logique> )
forAll
permet dcrire une expression logique vraie si lexpression <expression_logique> est
vraie pour tous les lments de self.
exists
permet dcrire une expression logique vraie si lexpression <expression_logique> est
vraie pour au moins un lment de self.
Par exemple, pour crire une contrainte imposant que toute socit doit possder, parmi ses
employs, au moins une personne de plus de 50 ans, on peut crire :
context Socit
inv: self.employ->exists(age > 50)
Lopration forAll possde une variante tendue possdant plus dun itrateur. Dans ce cas,
chacun des itrateurs parcourra lensemble de la collection. Concrtement, une opration
forAll comportant deux itrateurs est quivalente une opration forAll nen comportant
quun, mais ralise sur le produit cartsien de self par lui-mme.
Par exemple, imposer quil nexiste pas deux instances de la classe Personne pour lesquelles
lattribut nom a la mme valeur, cest dire pour imposer que deux personnes diffrentes ont
un nom diffrent, on peut crire indiffremment :
1. context Personne
inv: Personne.allInstances()->forAll(p1, p2 | p1 <> p2 implies p1.nom <> p2.nom)
2. context Personne
inv: (Personne.allInstances().product(Personne.allInstances()))
->forAll(tuple | tuple.first <> tuple.second implies tuple.first.nom <>
tuple.second.nom)
Opration collect
Cette opration permet de construire une nouvelle collection en utilisant la collection self. La
nouvelle collection construite possde le mme nombre dlments que la collection self, mais
le type de ces lments est gnralement diffrent. La syntaxe de loprateur collect est la
suivante :
collect( [ <lment> [ : <Type> ] | ] <expression> )
8. Une personne considre comme au chmage ne doit pas avoir des revenus suprieurs
100 .
9. context Personne
10. inv :
11.
let revenus : Real = self.poste.salaire->sum() in
12.
if chmeur then
13.
revenus < 100
14.
else
15.
revenus >= 100
16.
endif
20. Si une personne possde deux parents, lun est une femme et lautre un homme.
21. context Personne
22. inv :
23.
parent->size()=2 implies
24.
( parent->exists(genre=Genre::homme) and
25.
parent->exists(genre=Genre::femme) )
26. Tous les enfants dune personne ont bien cette personne comme parent et inversement.
27. context Personne
28. inv :
29.
enfant->notEmpty() implies
30.
enfant->forAll( p : Personne | p.parents->includes(self))
31.
32. context Personne
33. inv :
34.
parent->notEmpty() implies
35.
parent->forAll ( p : Personne | p.enfant->includes (self))
39. Pour tre mari, il faut avoir plus de 18 ans. Un homme est mari avec exactement une
femme et une femme avec exactement un homme.
40. context Personne
41. inv :
42.
self.mari implies
43.
self.genre=Genre::homme implies (
44.
self.femme->size()=1 and
45.
self.femme.genre=Genre::femme)
46.
and self.genre=Genre::femme implies (
47.
self.mari->size()=1 and
48.
self.mari.genre=Genre::homme)
49.
and self.age >=18
Comme nous venons de le dire, un automate tats finis est un automate dont le
comportement des sorties ne dpend pas seulement de ltat de ses entres, mais aussi dun
historique des sollicitations passes. Cet historique est caractris par un tat global.
Un tat global est un jeu de valeurs dobjet, pour une classe donne, produisant la mme
rponse face aux vnements. Toutes les instances dune mme classe ayant le mme tat
global ragissent de la mme manire un vnement. Il ne faut pas confondre les notions
dtat global et dtat. La section 5.2.1 donne plus dinformation sur ces deux acceptions du
terme tat.
Un automate tats finis est graphiquement reprsent par un graphe comportant des tats,
matrialiss par des rectangles aux coins arrondis, et des transitions, matrialises par des arcs
orients liant les tats entre eux.
5.2 tat
5.2.1 Les deux acceptions du terme tat
5.3 vnement
5.3.1 Notion dvnement
Un vnement est quelque chose qui se produit pendant lexcution dun systme et qui
mrite dtre modlis. Les diagrammes dtats-transitions permettent justement de spcifier
les ractions dune partie du systme des vnements discrets. Un vnement se produit un
instant prcis et est dpourvu de dure. Quand un vnement est reu, une transition peut tre
dclenche et faire basculer lobjet dans un nouvel tat. On peut diviser les vnements en
plusieurs types explicites et implicites : signal, appel, changement et temporel.
Les signaux supporte la relation de gnralisation (cf. figure 5.5). Les signaux hritent des
attributs de leurs parents (hritage) et ils dclenchent des transitions contenant le type du
signal parent (polymorphisme).
Notez la diffrence entre une condition de garde (cf. section 5.4.2) et un vnement de
changement. La premire est value une fois que lvnement dclencheur de la transition a
lieu et que le destinataire le traite. Si elle est fausse, la transition ne se dclenche pas et la
condition nest pas rvalue. Un vnement de changement est valu continuellement
jusqu ce quil devienne vrai, et cest ce moment-l que la transition se dclenche.
after ( <dure> )
5.4 Transition
5.4.1 Dfinition et syntaxe
Une transition dfinit la rponse dun objet loccurrence dun vnement. Elle lie,
gnralement, deux tats E1 et E2 et indique quun objet dans un tat E1 peut entrer dans
ltat E2 et excuter certaines activits, si un vnement dclencheur se produit et que la
condition de garde est vrifie.
La syntaxe dune transition est la suivante :
[ <vnement> ][ '[' <garde> ']' ] [ '/' <activit> ]
La faon de spcifier lactivit raliser est laisse libre (langage naturel ou pseudo-code).
Lorsque lexcution de leffet est termine, ltat cible de la transition devient actif.
Figure 5.6: Reprsentation graphique dune transition externe entre deux tats.
Une transition externe est une transition qui modifie ltat actif. Il sagit du type de transition
le plus rpandu. Elle est reprsente par une flche allant de ltat source vers ltat cible.
La figure 5.6 illustre la reprsentation graphique dune transition externe entre deux tats.
Figure 5.7: Reprsentation de la saisie dun mot de passe dans un tat unique en utilisant des
transitions internes.
Les rgles de dclenchement dune transition interne sont les mmes que pour une transition
externe except quune transition interne ne possde pas dtat cible et que ltat actif reste le
mme la suite de son dclenchement. La syntaxe dune transition interne reste la mme que
celle dune transition classique (cf. section 5.4.1). Par contre, les transitions internes ne sont
pas reprsentes par des arcs mais sont spcifies dans un compartiment de leur tat associ
(cf. figure 5.7).
Les transitions internes possdent des noms dvnement prdfinis correspondant des
dclencheurs particuliers : entry, exit, do et include. Ces mots clefs rservs viennent prendre
la place du nom de lvnement dans la syntaxe dune transition interne.
entry
entry permet de spcifier une activit qui saccomplit quand on entre dans ltat.
exit
exit permet de spcifier une activit qui saccomplit quand on sort de ltat.
do
Une activit do commence ds que lactivit entry est termine. Lorsque cette activit
est termine, une transition dachvement peut tre dclenche, aprs lexcution de
lactivit exit bien entendu. Si une transition se dclenche pendant que lactivit do est
en cours, cette dernire est interrompue et lactivit exit de ltat sexcute.
include
permet dinvoquer un sous-diagramme dtats-transitions.
Les activits entry servent souvent effectuer la configuration ncessaire dans un tat.
Comme il nest pas possible de lluder, toute action interne ltat peut supposer que la
configuration est effectue indpendamment de la manire dont on entre dans ltat. De
manire analogue, une activit exit est une occasion de procder un nettoyage. Cela peut
savrer particulirement utile lorsquil existe des transitions de haut niveau qui reprsentent
des conditions derreur qui abandonnent les tats imbriqus.
Le dclenchement dune transition interne ne modifie pas ltat actif et nentrane donc pas
lactivation des activits entry et exit.
Figure 5.8: En haut, un diagramme sans point de jonction. En bas, son quivalent utilisant un
point de jonction.
Figure 5.9: Exemple dutilisation de deux points de jonction pour reprsenter une alternative.
Les points de jonction sont un artefact graphique (un pseudo-tat en loccurrence) qui permet
de partager des segments de transition, lobjectif tant daboutir une notation plus compacte
ou plus lisible des chemins alternatifs.
Un point de jonction peut avoir plusieurs segments de transition entrante et plusieurs
segments de transition sortante. Par contre, il ne peut avoir dactivit interne ni des transitions
sortantes dotes de dclencheurs dvnements.
Il ne sagit pas dun tat qui peut tre actif au cours dun laps de temps fini. Lorsquun chemin
passant par un point de jonction est emprunt (donc lorsque la transition associe est
dclenche) toutes les gardes le long de ce chemin doivent svaluer vrai ds le
franchissement du premier segment.
La figure 5.8 illustre bien lutilit des points de jonction.
La figure 5.9 illustre lutilisation de points de jonction pour reprsenter le branchement dune
clause conditionnelle.
Figure 5.11: Exemple dtat composite modlisant lassociation dune commande un client.
Un tat simple ne possde pas de sous-structure mais uniquement, le cas chant, un jeu de
transitions internes. Un tat composite est un tat dcompos en rgions contenant chacune un
ou plusieurs sous-tats.
Quand un tat composite comporte plus dune rgion, il est qualifi dtat orthogonal.
Lorsquun tat orthogonal est actif, un sous-tat direct de chaque rgion est simultanment
actif, il y a donc concurrence (cf. section 5.6.5). Un tat composite ne comportant quune
rgion est qualifi dtat non orthogonal.
Implicitement, tout diagramme dtats-transitions est contenu dans un tat externe qui nest
usuellement pas reprsent. Cela apporte une plus grande homognit dans la description :
tout diagramme dtats-transitions est implicitement un tat composite.
5.6.2 Transition
Les transitions peuvent avoir pour cible la frontire dun tat composite et sont quivalentes
une transition ayant pour cible ltat initial de ltat composite.
Une transition ayant pour source la frontire dun tat composite est quivalente une
transition qui sapplique tout sous-tat de ltat composite source. Cette relation est
transitive : la transition est franchissable depuis tout tat imbriqu, quelle que soit sa
profondeur.
Par contre, si la transition ayant pour source la frontire dun tat composite ne porte pas de
dclencheur explicite (i.e. sil sagit dune transition dachvement), elle est franchissable
quand ltat final de ltat composite est atteint.
Les transitions peuvent galement toucher des tats de diffrents niveaux dimbrication en
traversant les frontires des tats composites.
Figure 5.13: Exemple de configuration complexe de transition. Depuis ltat tat 1, la rception
de lvnement event1 produit la squence dactivits QuitterE11, QuitterE1, action1, EntrerE2,
EntrerE21, initialiser(), EntrerE22, et place le systme dans ltat tat22.
La figure 5.13 illustre une configuration complexe de transition produisant une cascade
dactivits.
Une transition ayant pour cible ltat historique est quivalente une transition qui a pour
cible le dernier tat visit de ltat englobant. Un tat historique peut avoir une transition
sortante non tiquete indiquant ltat excuter si la rgion na pas encore t visite.
Il est galement possible de dfinir un tat historique profond reprsent graphiquement par
un cercle contenant un H*. Cet tat historique profond permet datteindre le dernier tat visit
dans la rgion, quel que soit sont niveau dimbrication, alors que le ltat historique plat limite
laccs aux tats de son niveau dimbrication.
La figure 5.14 montre un diagramme dtats-transitions modlisant le lavage automatique
dune voiture. Les tats de lavage, schage et lustrage sont des tats composites dfinis sur
trois autres diagrammes dtats-transitions non reprsents ici. En phase de lavage ou de
schage, le client peut appuyer sur le bouton darrt durgence. Sil appuie sur ce bouton, la
machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage,
exactement o le programme t interrompue, cest dire au niveau du dernier sous-tat
actif des tats de lavage ou de lustrage (tat historique profond). Si ltat avait t un tat
historique plat, cest toute la squence de lavage ou de lustrage qui aurait recommence. En
phase de lustrage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine
sarrtera dfinitivement.
Lorsque lon utilise le comportement par dfaut de ltat composite, cest--dire entrer par
ltat initial par dfaut et considrer les traitements finis quand ltat final est atteint, aucun
problme ne se pose car on utilise des transitions ayant pour cible, ou pour source, la frontire
de ltat composite. Dans ce cas, les points de connexion sont inutiles.
Le problme se pose lorsquil est possible dentrer ou de sortir dun tat composite de
plusieurs faons. Cest, par exemple, le cas lorsquil existe des transitions traversant la
frontire de ltat composite et visant directement, ou ayant pour source, un sous-tat de ltat
composite. Dans ce cas, la solution est dutiliser des points de connexion sur la frontire de
ltat composite.
Les points de connexion sont des points dentre et de sortie portant un nom, et situs sur la
frontire dun tat composite. Ils sont respectivement reprsents par un cercle vide et un
cercle barr dune croix (cf. figure 5.15). Il ne sagit que de rfrences un tat dfini dans
ltat composite . Une unique transition dachvement, dpourvue de garde, relie le pseudotat source (i.e. le point de connexion) ltat rfrenc. Cette transition dachvement nest
que le prolongement de la transition qui vise le point de connexion (il peut dailleurs y en
avoir plusieurs). Les points de connexions offrent ainsi une faon de reprsenter linterface
(au sens objet) dun tat composite en masquant limplmentation de son comportement.
On peut considrer que les pseudo-tats initiaux et finaux sont des points de connexion sans
nom.
5.6.5 Concurrence
Chaque rgion peut possder un tat initial et final. Une transition qui atteint la bordure dun
tat composite orthogonal est quivalente une transition qui atteint les tats initiaux de
toutes ses rgions concurrentes.
Toutes les rgions concurrentes dun tat composite orthogonal doivent atteindre leur tat
final pour que ltat composite soit considr comme termin.
La figure 5.16 illustre lutilisation dun tat composite orthogonal pour modliser le fait que la
prparation de la boisson dun distributeur de boisson se fait en parallle au rendu de la
monaie.
Les diagrammes dactivits sont relativement proches des diagrammes dtats-transitions dans
leur prsentation, mais leur interprtation est sensiblement diffrente. Les diagrammes dtatstransitions sont orients vers des systmes ractifs, mais ils ne donnent pas une vision
satisfaisante dun traitement faisant intervenir plusieurs classeurs et doivent tre complts,
par exemple, par des diagrammes de squence. Au contraire, les diagrammes dactivits ne
sont pas spcifiquement rattachs un classeur particulier. On peut attacher un diagramme
dactivits nimporte quel lment de modlisation afin de visualiser, spcifier, construire ou
documenter le comportement de cet lment.
La diffrence principale entre les diagrammes dinteraction et les diagrammes dactivits est
que les premiers mettent laccent sur le flot de contrle dun objet lautre, tandis que les
seconds insistent sur le flot de contrle dune activit lautre.
Nous dcrivons ci-dessous les types dactions les plus courants prdfinis dans la notation
UML.
Action appeler (call operation)
Laction call operation correspond linvocation dune opration sur un objet de
manire synchrone ou asynchrone. Lorsque laction est excute, les paramtres sont
transmis lobjet cible. Si lappel est asynchrone, laction est termine et les
ventuelles valeurs de retour seront ignores. Si lappel est synchrone, lappelant est
bloqu pendant lexcution de lopration et, le cas chant, les valeurs de retour
pourront tre rceptionnes.
Action comportement (call behavior)
Laction call behavior est une variante de laction call operation car elle invoque
directement une activit plutt quune opration.
Action envoyer (send)
Cette action cre un message et le transmet un objet cible, o elle peut dclencher un
comportement. Il sagit dun appel asynchrone (i.e. qui ne bloque pas lobjet appelant)
bien adapt lenvoi de signaux (send signal).
Action accepter vnement (accept event)
Lexcution de cette action bloque lexcution en cours jusqu la rception du type
dvnement spcifi, qui gnralement est un signal. Cette action est utilise pour la
rception de signaux asynchrones.
Action accepter appel (accept call)
Il sagit dune variante de laction accept event pour les appels synchrones.
Action rpondre (reply)
Cette action permet de transmettre un message en rponse la rception dune action
de type accept call.
Action crer (create)
Cette action permet dinstancier un objet.
Action dtruire (destroy)
Cette action permet de dtruire un objet.
Action lever exception (raise exception)
Cette action permet de lever explicitement une exception.
Graphiquement, les actions apparaissent dans des nuds daction, dcrits section 6.3.1.
Un groupe dactivits est une activit regroupant des nuds et des arcs. Les nuds et les arcs
peuvent appartenir plus dun groupe. Un diagramme dactivits est lui-mme un groupe
dactivits (cf. figure 6.2).
Figure 6.1: Reprsentation graphique des nuds dactivit. De la gauche vers la droite, on
trouve : le nud reprsentant une action, qui est une varit de nud excutable, un nud objet,
un nud de dcision ou de fusion, un nud de bifurcation ou dunion, un nud initial, un nud
final et un nud final de flot.
La figure 6.1 reprsente les diffrents types de nuds dactivit. La figure 6.2 montre
comment certains de ces nuds sont utiliss pour former un diagramme dactivits.
6.2.5 Transition
Un nud structur est dnot par le strotype structured et identifi par un nom unique
dcrivant le comportement modlis dans lactivit structure.
Graphiquement, le contour dun nud dactivit structure est en pointill. Une ligne
horizontale en trait continu spare le compartiment contenant le strotype structured et le
nom de lactivit structure du corps de lactivit structure.
condition de garde [else] est valide si et seulement si toutes les autres gardes des transitions
ayant la mme source sont fausses. Dans le cas o plusieurs arcs sont franchissables (i.e.
plusieurs conditions de garde sont vraies), seul lun dentre eux est retenu et ce choix est non
dterministe.
Graphiquement, on reprsente un nud de dcision par un losange (cf. figure 6.6).
Nud de fusion (merge node)
Un nud de fusion est un nud de contrle qui rassemble plusieurs flots alternatifs entrants
en un seul flot sortant. Il nest pas utilis pour synchroniser des flots concurrents (cest le rle
du nud dunion) mais pour accepter un flot parmi plusieurs.
Graphiquement, on reprsente un nud de fusion, comme un nud de dcision, par un
losange (cf. figure 6.6).
Remarque
Graphiquement, il est possible de fusionner un nud de fusion et un nud de dcision, et
donc davoir un losange possdant plusieurs arcs entrants et sortants. Il est galement possible
de fusionner un nud de dcision ou de fusion avec un autre nud, comme un nud de fin de
flot sur la figure 6.6, ou avec une activit. Cependant, pour mieux mettre en vidence un
branchement conditionnel, il est prfrable dutiliser un nud de dcision (losange).
Figure 6.7: Reprsentation des pins dentre et de sortie sur une activit.
Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on utilise
des nuds dobjets appels pins (pin en anglais) dentre ou de sortie. Lactivit ne peut
dbuter que si lon affecte une valeur chacun de ses pins dentre. Quand lactivit se
termine, une valeur doit tre affecte chacun de ses pins de sortie.
Les valeurs sont passes par copie : une modification des valeurs dentre au cours du
traitement de laction nest visible qu lintrieur de lactivit.
Graphiquement, un pin est reprsent par un petit carr attach la bordure dune activit (cf.
figure 6.7). Il est typ et ventuellement nomm. Il peut contenir des flches indiquant sa
direction (entre ou sortie) si lactivit ne permet pas de le dterminer de manire univoque.
Figure 6.9: Exemple dutilisation dun nud tampon central pour centraliser toutes les
commandes prises par diffrents procds, avant quelles soient traites.
Un nud tampon central est un nud dobjet qui accepte les entres de plusieurs nuds
dobjets ou produit des sorties vers plusieurs nuds dobjets. Les flots en provenance dun
nud tampon central ne sont donc pas directement connects des actions. Ce nud modlise
donc un tampon traditionnel qui peut contenir des valeurs en provenance de diverses sources
et livrer des valeurs vers diffrentes destinations.
Graphiquement, un nud tampon central est reprsent comme un nud dobjet dtach (en
bas de la figure 6.8) strotyp centralBuffer (cf. figure 6.9).
Figure 6.10: Dans cette modlisation, le personnel, aprs avoir t recrut par lactivit
Recruter personnel, est stock de manire persistante dans le nud de stockage Base de donne
du Personnel. Bien quils restent dans ce nud, chaque employ qui na pas encore reu
daffectation (tiquette strotype selection : personnel.affectation=null) est
disponible pour tre utilis par lactivit Affecter personnel.
Un nud de stockage des donnes est un nud tampon central particulier qui assure la
persistance des donnes. Lorsquune information est slectionne par un flux sortant,
linformation est duplique et ne disparat pas du nud de stockage des donnes comme ce
serait le cas dans un nud tampon central. Lorsquun flux entrant vhicule une donne dj
stocke par le nud de stockage des donnes, cette dernire est crase par la nouvelle.
Graphiquement, un nud tampon central est reprsent comme un nud dobjet dtach (en
bas de la figure 6.8) strotyp datastore (cf. figure 6.10).
6.6 Partitions
nuds dactivits appartiennent forcment une et une seule partition. Les transitions
peuvent, bien entendu, traverser les frontires des partitions.
Les partitions dactivits tant des catgories arbitraires, on peut les reprsenter par dautre
moyens quand une rpartition gomtrique savre difficile raliser. On peut ainsi utiliser
des couleurs ou tout simplement tiqueter les nuds dactivit par le nom de leur partition
dappartenance.
6.7 Exceptions
Figure 6.12: Notation graphique du fait quune activit peut soulever une exception.
Une exception est gnre quand une situation anormale entrave le droulement nominal
dune tche. Elle peut tre gnre automatiquement pour signaler une erreur dexcution
(dbordement dindice de tableau, division par zro, ), ou tre souleve explicitement par
une action (RaiseException) pour signaler une situation problmatique qui nest pas prise en
charge par la squence de traitement normale. Graphiquement, on peut reprsenter le fait
quune activit peut soulever une exception comme un pin de sortie orn dun petit triangle et
en prcisant le type de lexception proximit du pin de sortie (cf. figure 6.12).
Figure 6.13: Les deux notations graphiques de la connexion entre une activit protge et son
Figure 6.14: Exemple dutilisation dun gestionnaire dexception pour protger une activit de
lexception Division_par_zero dclenche en cas de division par zro.
Lorsquune exception survient, lexcution de lactivit en cours est abandonne sans gnrer
de valeur de sortie. Le mcanisme dexcution recherche alors un gestionnaire dexception
susceptible de traiter lexception leve ou une de ses classes parentes. Si lactivit qui a lev
lexception nest pas protge de cette exception, lexception est propage lactivit
englobante. Lexcution de cette dernire est abandonne, ses valeurs de sortie ne sont pas
gnres et un gestionnaire dexception est recherch son niveau. Ce mcanisme de
propagation se poursuit jusqu ce quun gestionnaire adapt soit trouv. Si lexception se
propage jusquau sommet dune activit (i.e. il ny a plus dactivit englobante), trois cas de
figure se prsentent. Si lactivit a t invoque de manire asynchrone, aucun effet ne se
produit et la gestion de lexception est termine. Si lactivit a t invoque de manire
synchrone, lexception est propage au mcanisme dexcution de lappelant. Si lexception
sest propage la racine du systme, le modle est considr comme incomplet ou mal
form. Dans la plupart des langages orients objet, une exception qui se propage jusqu la
racine du programme implique son arrt. Quand un gestionnaire dexception adapt a t
trouv et que son excution se termine, lexcution se poursuit comme si lactivit protge
stait termine normalement, les valeurs de sortie fournies par le gestionnaire remplaant
celle que lactivit protge aurait d produire.
7.1.1 Introduction
Un objet interagit pour implmenter un comportement. On peut dcrire cette interaction de
deux manires complmentaires : lune est centre sur des objets individuels (diagramme
dtats-transitions) et lautre sur une collection dobjets qui cooprent (diagrammes
dinteraction).
La spcification dun diagramme dtats-transitions est prcise et conduit immdiatement au
code. Elle ne permet pas pour autant dexpliquer le fonctionnement global dun systme, car
elle se concentre sur un seul objet la fois. Un diagramme dinteraction permet doffrir une
vue plus holistique1 du comportement dun jeu dobjets.
Le diagramme de communication (section 7.2) est un diagramme dinteraction mettant
laccent sur lorganisation structurelle des objets qui envoient et reoivent des messages. Le
diagramme de squence (section 7.3) est un diagramme dinteraction mettant laccent sur la
chronologie de lenvoi des messages. Les diagrammes dinteraction permettent dtablir un
lien entre les diagrammes de cas dutilisation et les diagrammes de classes : ils montrent
comment des objets (i.e. des instances de classes) communiquent pour raliser une certaine
fonctionnalit. Ils apportent ainsi un aspect dynamique la modlisation du systme.
Pour produire un diagramme dinteraction, il faut focaliser son attention sur un sous-ensemble
dlments du systme et tudier leur faon dinteragir pour dcrire un comportement
particulier. UML permet de dcrire un comportement limit un contexte prcis de deux
faons : dans le cadre dun classeur structur (cf. section 7.1.2) ou dans celui dune
collaboration (cf. section 7.1.3).
Figure 7.1: Exemple de classeur structur montrant quun classeur Moteur est en fait constitu
dun Allumage et de quatre Bougie.
Les classes dcouvertes au moment de lanalyse (celles qui figurent dans le diagramme de
classes) ne sont parfois pas assez dtailles pour pouvoir tre implmentes par des
dveloppeurs. UML propose de partir des classeurs dcouverts au moment de lanalyse (tels
que les classes, mais aussi les sous-systmes, les cas dutilisation, ) et de les dcomposer en
lments suffisamment fins pour permettre leur implmentation. Les classeurs ainsi
dcomposs sappellent des classeurs structurs.
Un classeur structur est donc la description de la structure dimplmentation interne dune
classe. Graphiquement, un classeur structur se reprsente par un rectangle en trait plein
comprenant deux compartiments. Le compartiment suprieur contient le nom du classeur et le
compartiment infrieur montre les parties internes relies par des connecteurs (cf. figure 7.1).
Un classeur structur possde des ports (cf. section 8.2.3), des parties et des connecteurs.
Lorsque lon cre linstance dun classeur structur, on cre galement une instance de ses
ports, de ses parties et de ses connecteurs.
7.1.3 Collaboration
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme
de communication et celui de squence. Une mme interaction peut tre prsente aussi bien
par lun que par lautre (cf. figure 7.4 et 7.5).
Remarque
A ces deux diagrammes, UML 2.0 en ajoute un troisime : le diagramme de timing. Son usage
est limit la modlisation des systmes qui sexcutent sous de fortes contraintes de temps,
comme les systmes temps rel.
Figure 7.6: Diagramme de communication illustrant la recherche puis lajout, dans son panier
virtuel, dun livre lors dune commande sur Internet.
Au moins un des deux noms doit tre spcifi dans ltiquette, les deux points (:) sont, quand
eux, obligatoire.
<sq>
est le numro de squence du message. On numrote les messages par envoi et sousenvoi dsigns par des chiffres spars par des points : ainsi lenvoi du message 1.4.4
est postrieur celui du message 1.4.3, tous deux tant des consquences (i.e. des
sous-envois) de la rception dun message 1.4. La simultanit dun envoi est dsigne
par une lettre : les messages 1.6a et 1.6b sont envoys en mme temps.
<iter>
<var>
spcifie (en langage naturel, entre crochets) lenvoi squentiel (ou en parallle, avec
||) de plusieurs message. On peut omettre cette spcification et ne garder que le
caractre * (ou *||) pour dsigner un message rcurrent envoy un certain nombre de
fois.
est la valeur de retour du message, qui sera par exemple transmise en paramtre un
autre message.
<msg>
<par>
Au moins un des deux noms doit tre spcifi dans ltiquette, les deux points (:) sont, quand
eux, obligatoire.
Messages asynchrones
cas chant quand il arrivera et sil serra trait par le destinataire. Un signal est, par dfinition,
un message asynchrone.
Graphiquement, un message asynchrone se reprsente par une flche en traits pleins et
lextrmit ouverte partant de la ligne de vie dun objet expditeur et allant vers celle de
lobjet cible (figure 7.7).
Messages synchrones
La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie de
lobjet (figure 7.9). La destruction dun objet nest pas ncessairement conscutive la
rception dun message.
vnements et messages
Figure 7.13: Reprsentation dun objet actif ( gauche) et dune excution sur un objet passif (
droite).
Un objet actif initie et contrle le flux dactivits. Graphiquement, la ligne pointille verticale
dun objet actif est remplace par un double trait vertical (cf. figures 7.13).
Un objet passif, au contraire, a besoin quon lui donne le flux dactivit pour pouvoir excuter
une mthode. La spcification de lexcution dune raction sur un objet passif se reprsente
par un rectangle blanc ou gris plac sur la ligne de vie en pointille (cf. figures 7.13). Le
rectangle peut ventuellement porter un label.
Nous naborderons que quelques-unes de ces interactions dans la suite de cette section.
Oprateur alt
Loprateur option, ou opt, comporte une oprande et une condition de garde associe. Le
sous-fragment sexcute si la condition de garde est vraie et ne sexcute pas dans le cas
contraire.
Oprateur loop
Un fragment combin de type loop possde un sous-fragment et spcifie un compte minimum
et maximum (boucle) ainsi quune condition de garde.
La syntaxe de la boucle est la suivante :
loop[ '('<minInt> [ ',' <maxInt> ] ')' ]
La condition de garde est place entre crochets sur la ligne de vie. La boucle est rpte au
moins minInt fois avant quune ventuelle condition de garde boolenne ne soit teste. Tant
que la condition est vraie, la boucle continue, au plus maxInt fois. Cette syntaxe peut tre
remplace par une indication intelligible comme sur la figure 7.15.
Oprateur par
Figure 7.16: Microwave est un exemple dobjet effectuant deux tches en parallle.
Un fragments combin de type parallel, ou par, possde au moins deux sous-fragments
excuts simultanment (cf. figure 7.16). La concurrence est logique et nest pas
ncessairement physique : les excutions concurrentes peuvent sentrelacer sur un mme
chemin dexcution dans la pratique.
Oprateur strict
&
Diagrammes de dploiement
(Deployment diagram)
8.1 Introduction
Les diagrammes de composants et les diagrammes de dploiement sont les deux derniers
types de vues statiques en UML. Les premiers dcrivent le systme modlis sous forme de
composants rutilisables et mettent en vidence leurs relations de dpendance. Les seconds se
rapprochent encore plus de la ralit physique, puisquils identifient les lments matriels
(PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la
disposition des excutables (reprsents par des composants) sur ces lments matriels.
Figure 8.1: Reprsentation dun composant et de ses interfaces requises ou offertes sous la
forme dun classeur structur strotyp component. Au lieu ou en plus du mot cl, on peut
faire figurer une icne de composant (petit rectangle quip de deux rectangles plus petits
dpassant sur son ct gauche) dans langle suprieur droit (comme sur la figure de droite).
Figure 8.3: Reprsentation classique dun composant et de ses interfaces requise (reprsent par
un demi-cercle) et offerte (reprsente par un cercle). Cette reprsentation est souvent utilise
dans les diagrammes de composants (cf. figure 8.5). Sur la figure du bas, le strotype
component est rendu inutile par la reprsentation mme du composant.
Figure 8.4: Reprsentation dun composant et de ses interfaces requise et offerte avec la
reprsentation explicite de leur port correspondant.
Figure 8.5: Reprsentation de limplmentation dun composant complexe contenant des souscomposants.
symbole du composant (cf. figure 8.5), ou ct en les reliant au composant par une relation
de dpendance.
Pour montrer les instances des composants, un diagramme de dploiement doit tre utilis (cf.
section 8.3).
Figure 8.7: Reprsentation dun nud ( gauche) et dune instance de nud ( droite).
Chaque ressource est matrialise par un nud reprsent par un cube comportant un nom (cf.
figure 8.7). Un nud est un classeur et peut possder des attributs (quantit de mmoire,
vitesse du processeur, ).
Figure 8.8: Deux possibilits pour reprsenter laffectation dun composant un nud.
Pour montrer quun composant est affect un nud, il faut soit placer le composant dans le
nud, soit les relier par une relation de dpendance strotype support oriente du
composant vers le nud (cf. figure 8.8).
Figure 8.10: Reprsentation du dploiement de deux artefacts dans un nud utilisant la relation
de dpendance strotype deploy.
Figure 9.1: Quelle mthode pour passer de lexpression des besoins au code de lapplication ?
La problmatique que pose la mise en uvre dUML est simple : comment passer de
lexpression des besoins au code de lapplication ? Cette problmatique est parfaitement
illustre par la figure 9.1.
Comme nous lavons dj dit, maintes reprises, UML nest quun langage de modlisation,
ce nest pas une mthode. En effet, UML ne propose pas une dmarche de modlisation
explicitant et encadrant toutes les tapes dun projet, de la comprhension des besoins la
production du code de lapplication. Une mthode se doit de dfinir une squence dtapes,
partiellement ordonnes, dont lobjectif est de produire un logiciel de qualit qui rpond aux
besoins des utilisateurs dans des temps et des cots prvisibles.
Bien quUML ne soit pas une mthode, ses auteurs prcisent nanmoins quune mthode
base sur lutilisation UML doit tre :
Pilote par les cas dutilisation :
La principale qualit dun logiciel tant son utilit, cest--dire son adquation avec les
besoins des utilisateurs, toutes les tapes, de la spcification des besoins la
maintenance, doivent tre guides par les cas dutilisation qui modlisent justement les
besoins des utilisateurs.
Centre sur larchitecture :
Larchitecture est conue pour satisfaire les besoins exprims dans les cas dutilisation,
mais aussi pour prendre en compte les volutions futures et les contraintes de
ralisation. La mise en place dune architecture adapte conditionne le succs dun
dveloppement. Il est important de la stabiliser le plus tt possible.
Itrative et incrmentale :
Lensemble du problme est dcompos en petites itrations, dfinies partir des cas
dutilisation et de ltude des risques. Les risques majeurs et les cas dutilisation les
plus importants sont traits en priorit. Le dveloppement procde par des itrations
qui conduisent des livraisons incrmentales du systme. Nous avons dj prsent le
modle de cycle de vie par incrment dans la section 1.2.3.
plusieurs annes dexprience sur de nombreux projets dans des domaines varis. Elle a donc
montr son efficacit dans la pratique et est :
conduite par les cas dutilisation, comme UP, mais bien plus simple ;
relativement lgre et restreinte, comme XP, mais sans ngliger les activits de
modlisation en analyse et conception ;
fonde sur lutilisation dun sous-ensemble ncessaire et suffisant du langage UML
(modliser 80% des problmes en utilisant 20% dUML).
Dans tous les cas, il faut garder lesprit quune mthode nest pas une formule magique. Le
fait de produire des diagrammes UML selon un ordre tabli nest en aucun cas une garantie de
russite. Une mthode ne sert qu canaliser et ordonner les tapes de la modlisation. La
valeur nest pas dans la mthode mais dans les personnes qui la mettent en uvre.
Figure 9.2: Les besoins sont modliss par un diagramme de cas dutilisation.
Les cas dutilisation sont utiliss tout au long du projet. Dans un premier temps, on les cre
pour identifier et modliser les besoins des utilisateurs (figure 9.2). Ces besoins sont
dtermins partir des informations recueillies lors des rencontres entre informaticiens et
utilisateurs. Il faut imprativement proscrire toute considration de ralisation lors de cette
tape.
Durant cette tape, vous devrez dterminer les limites du systme, identifier les acteurs et
recenser les cas dutilisation (cf. section 2.5). Si lapplication est complexe, vous pourrez
organiser les cas dutilisation en paquetages.
Dans le cadre dune approche itrative et incrmentale, il faut affecter un degr dimportance
et un coefficient de risque chacun des cas dutilisation pour dfinir lordre des incrments
raliser.
Les interactions entre les acteurs et le systme (au sein des cas dutilisation) seront explicites
sous forme textuelle et sous forme graphique au moyen de diagrammes de squence (cf.
section 9.2.2). Les utilisateurs ont souvent beaucoup de difficults exprimer clairement et
prcisment ce quils attendent du systme. Lobjectif de cette tape et des deux suivantes
(section 9.2.2 et 9.2.3) est justement de les aider formuler et formaliser ces besoins.
Figure 9.3: Les diagrammes de squence systme illustrent la description textuelle des cas
dutilisation.
Dans cette tape, on cherche dtailler la description des besoins par la description textuelle
des cas dutilisation (cf. section 2.5.3) et la production de diagrammes de squence systme
illustrant cette description textuelle (figure 9.3). Cette tape amne souvent mettre jour le
diagramme de cas dutilisation puisque nous somme toujours dans la spcification des
besoins.
Les scnarii de la description textuelle des cas dutilisation peuvent tre vus comme des
instances de cas dutilisation et sont illustrs par des diagrammes de squence systme. Il faut,
au minimum, reprsenter le scnario nominal de chacun des cas dutilisation par un
diagramme de squence qui rend compte de linteraction entre lacteur, ou les acteurs, et le
systme. Le systme est ici considr comme un tout et est reprsent par une ligne de vie.
Chaque acteur est galement associ une ligne de vie.
Lorsque les scnarii alternatifs dun cas dutilisation sont nombreux et importants, lutilisation
dun diagramme dtats-transitions ou dactivits peut savrer prfrable une multitude de
diagrammes de squence.
Figure 9.4: Une maquette dIHM facilite les discussions avec les futurs utilisateurs.
Une maquette dIHM (Interface Homme-Machine) est un produit jetable permettant aux
utilisateurs davoir une vue concrte mais non dfinitive de la future interface de lapplication
(figure 9.4). La maquette peut trs bien consister en un ensemble de dessins produits par un
logiciel de prsentation ou de dessin. Par la suite, la maquette pourra intgrer des
fonctionnalits de navigation permettant lutilisateur de tester lenchanement des crans ou
des menus, mme si les fonctionnalits restent fictives. La maquette doit tre dveloppe
rapidement afin de provoquer des retours de la part des utilisateurs.
dissocie de lanalyse des besoins (sections 9.2.1, 9.2.2 et 9.2.3). Elle peut tre mene avant,
en parallle ou aprs cette dernire.
La phase danalyse du domaine permet dlaborer la premire version du diagramme de
classes (figure 9.5) appele modle du domaine. Ce modle doit dfinir les classes qui
modlisent les entits ou concepts prsents dans le domaine (on utilise aussi le terme de
mtier) de lapplication. Il sagit donc de produire un modle des objets du monde rel dans
un domaine donn. Ces entits ou concepts peuvent tre identifis directement partir de la
connaissance du domaine ou par des entretiens avec des experts du domaine. Il faut
absolument utiliser le vocabulaire du mtier pour nommer les classes et leurs attributs. Les
classes du modle du domaine ne doivent pas contenir dopration, mais seulement des
attributs. Les tapes suivre pour tablir ce diagramme sont (cf. section 3.6.1) :
Lerreur la plus courante lors de la cration dun modle du domaine consiste modliser un
concept par un attribut alors que ce dernier devait tre modlis par une classe. Si la seule
chose que recouvre un concept est sa valeur, il sagit simplement dun attribut. Par contre, si
un concept recouvre un ensemble dinformations, alors il sagit plutt dune classe qui
possde elle-mme plusieurs attributs.
Figure 9.6: Le diagramme de classes participantes effectue la jonction entre les cas dutilisation,
le modle du domaine et les diagrammes de conception logicielle.
Le diagramme de classes participantes est particulirement important puisquil effectue la
jonction entre, dune part, les cas dutilisation (section 9.2.1), le modle du domaine (section
9.3.1) et la maquette (section 9.2.3), et dautre part, les diagrammes de conception logicielle
que sont les diagrammes dinteraction (section 9.4.1) et le diagramme de classes de
conception (section 9.4.2). Les diagrammes de conception logicielle napparaissent pas encore
sur la figure 9.6.
Il nest pas souhaitable que les utilisateurs interagissent directement avec les instances des
classes du domaine par le biais de linterface graphique. En effet, le modle du domaine doit
tre indpendant des utilisateurs et de linterface graphique. De mme, linterface graphique
du logiciel doit pouvoir voluer sans rpercussion sur le cur de lapplication. Cest le
principe fondamental du dcoupage en couches dune application. Ainsi, le diagramme de
classes participantes modlise trois types de classes danalyse, les dialogues, les contrles et
les entits ainsi que leurs relations.
Les classes de dialogues
Les classes qui permettent les interactions entre lIHM et les utilisateurs sont
qualifies de dialogues. Ces classes sont directement issues de lanalyse de la
maquette prsente section 9.2.3. Il y a au moins un dialogue pour chaque association
entre un acteur et un cas dutilisation du diagramme de cas dutilisation de la section
9.2.1. En gnral, les dialogues vivent seulement le temps du droulemet du cas
dutilisation concern.
Les classes de contrles
Les classes qui modlisent la cinmatique de lapplication sont appeles contrles.
Elles font la jonction entre les dialogues et les classes mtier en permettant au
diffrentes vues de lapplication de manipuler des informations dtenues par un ou
plusieurs objets mtier. Elles contiennent les rgles applicatives et les isolent la fois
des dialogues et des entits.
Les classes entits
Les classes mtier, qui proviennent directement du modle du domaine (cf. section
9.3.1), sont qualifies dentits. Ces classes sont gnralement persistantes, cest-dire quelles survivent lexcution dun cas dutilisation particulier et quelles
permettent des donnes et des relations dtre stockes dans des fichiers ou des bases
de donnes. Lors de limplmentation, ces classes peuvent ne pas se concrtiser par
des classes mais par des relations, au sens des bases de donnes relationnelles (cf.
section 3.6.3).
Lors de llaboration du diagramme de classes participantes, il faut veiller au respect des
rgles suivantes :
Les entits, qui sont issues du modle du domaine, ne comportent que des attributs (cf.
section 9.3.1).
Les entits ne peuvent tre en association quavec dautres entits ou avec des
contrles, mais, dans ce dernier cas, avec une contrainte de navigabilit interdisant de
traverser une association dune entit vers un contrle.
Les contrles ne comportent que des oprations. Ils implmentent la logique
applicative (i.e. les fonctionnalits de lapplication), et peuvent correspondre des
rgles transverses plusieurs entits. Chaque contrle est gnralement associ un
cas dutilisation, et vice versa. Mais rien nempche de dcomposer un cas
dutilisation complexe en plusieurs contrles.
Les contrles peuvent tre associs tous les types de classes, y compris dautres
contrles. Dans le cas dune association entre un dialogue et un contrle, une
contrainte de navigabilit doit interdire de traverser lassociation du contrle vers le
dialogue.
Les dialogues comportent des attributs et des oprations. Les attributs reprsentent des
informations ou des paramtres saisis par lutilisateur ou des rsultats dactions. Les
oprations ralisent (gnralement par dlgation aux contrles) les actions que
lutilisateur demande par le biais de lIHM.
Les dialogues peuvent tre en association avec des contrles ou dautres dialoques,
mais pas directement avec des entits.
Il est galement possible dajouter les acteurs sur le diagramme de classes
participantes en respectant la rgle suivante : un acteur ne peut tre li qu un
dialogue.
Certaines classes possdent un comportement dynamique complexe. Ces classes auront intrt
tre dtailles par des diagrammes dtats-transitions.
Lattribution des bonnes responsabilits, dgage dans la section 9.2.2, aux bonnes classes est
lun des problmes les plus dlicats de la conception oriente objet. Ce problme sera affront
en phase de conception lors de llaboration des diagrammes dinteraction (section 9.4.1) et
du diagramme de classes de conception (section 9.4.2).
Lors de la phase dlaboration du diagramme de classes participantes, le chef de projet a la
possibilit de dcouper le travail de son quipe danalystes par cas dutilisation. Lanalyse et
limplmentation des fonctionnalits dgages par les cas dutilisation dfinissent alors les
itrations raliser. Lordonnancement des itrations tant dfini par le degr dimportance et
le coefficient de risque affect chacun des cas dutilisation dans la section 9.2.1.
Figure 9.8: Les diagrammes dinteraction permettent dattribuer prcisment les responsabilits
de comportement aux classes danalyse.
Maintenant, il faut attribuer prcisment les responsabilits de comportement, dgage par le
diagrammes de squence systme dans la section 9.2.2, aux classes danalyse du diagramme
de classes participantes labor dans la section 9.3.2. Les rsultats de cette rflexion sont
prsents sous la forme de diagrammes dinteraction UML (figure 9.8). Inversement,
llaboration de ces diagrammes facilite grandement la rflexion.
Paralllement, une premire bauche de la vue statique de conception, cest--dire du
diagramme de classes de conception, est construite et complte. Durant cette phase,
lbauche du diagramme de classes de conception reste indpendante des choix
technologiques qui seront faits ultrieurement (dans la section 9.4.2).
Pour chaque service ou fonction, il faut dcider quelle est la classe qui va le contenir. Les
diagrammes dinteractions (i.e de squence ou de communication) sont particulirement utiles
au concepteur pour reprsenter graphiquement ces dcisions dallocations des responsabilits.
Chaque diagramme va reprsenter un ensemble dobjets de classes diffrentes collaborant
dans le cadre dun scnario dexcution du systme.
Dans les diagrammes dinteraction, les objets communiquent en senvoyant des messages qui
invoquent des oprations sur les objets rcepteurs. Il est ainsi possible de suivre visuellement
les interactions dynamiques entre objets, et les traitements raliss par chacun deux. Avec un
outil de modlisation UML (comme Rational Rose ou PowerAMC), la spcification de
lenvoi dun message entre deux objets cre effectivement une opration publique sur la
classe de lobjet cible. Ce type doutil permet rellement de mettre en uvre lallocation des
responsabilits partir des diagrammes dinteraction.
Figure 9.9: Le systme des diagrammes de squences systme, vu comme une bote noire, est
remplac par un ensemble dobjets en collaboration.
Par rapport aux diagrammes de squences systme de la section 9.2.2, nous remplaons ici le
systme, vu comme une bote noire, par un ensemble dobjets en collaboration (cf. figure 9.9).
Ces objets sont des instances des trois types de classes danalyse du diagramme de classes
participantes, savoir des dialogues, des contrles et des entits. Les diagrammes de
squences labors dans cette section doivent donc toujours respecter les rgles dictes dans
la section 9.3.2. Ces rgles doivent cependant tre transposes car, pour que deux objets puis
interagir directement, il faut que :
les classes dont ils sont issus soient en association dans le diagramme de classes
participantes1 ;
linteraction respecte la navigabilit de lassociation en question.
Si elles ne sont pas en association, il doit au moins exister une relation de dpendance
comme illustre par la figure 3.21 de la section 3.3.10.
Bibliographie
[1]
Wikipdia, encyclopdie librement distribuable. Internet. http://fr.wikipedia.org/ wiki/
Accueil.
[2]
Mamoun Alissali. Support de cours introduction au gnie logiciel. Internet, 1998.
http:// www-ic2.univ-lemans.fr/ ~alissali/ Enseignement/ Polys/ GL/ gl.html.
[3]
Franck Barbier. UML 2 et MDE. Dunod, 2005.
[4]
Donald Bell. Umls sequence diagram. Internet, 2004. http://www-128.ibm.com/
developerworks/ rational/ library/ 3101.html#notes.
[5]
Grady Booch, James Rumbaugh, and Ivar Jacobson. Le guide de lutilisateur UML.
Eyrolles, 2003.
[6]
Eric Cariou. Support de cours "le langage de contraintes ocl". Internet, novembre
2003. http:// www.univ-pau.fr/ ~ecariou/ cours/ mde/ cours-ocl.pdf.
[7]
Benot Charroux, Aomar Osmani, and Yann Thierry-Mieg. UML2. Pearson Education
France, 2005.
[8]
Laurent Debrauwer and Fien Van der Heyd. UML 2 Initiation, exemples et exercices
corrigs. eni, 2005.
[9]
Developpez.com. Club dentraide des dveloppeurs francophones. Internet.
http://www.developpez.com/.
[10]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns:
elements of reusable object-oriented sofware. Addison-Wesley, 1995.
[11]
Erik Gollot. Les cas dutilisation. Internet, 2004. http:// ego.developpez.com/ uml/
tutoriel/ casUtilisation/.
[12]
Pierre Grard. Uml. Internet, 2007. http:// www-lipn.univ-paris13.fr/ ~gerard/
fr_ens_uml.html.
[13]
Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Unified Process. Printice Hall, 1997.
[14]
Hugues Malgouyres, Jean-Pierre Seuma-Vidal, and Gilles Motet. Rgles de cohrence
uml 2.0 (version 1.1). Internet, 2005. http:// www.lesia.insa-toulouse.fr/ UML/
CoherenceUML_v1_1_100605.pdf.
[15]
Acteur, 2.2.1
o identification, 2.5.1
o principal, 2.3.1
o reprsentation graphique, 2.2.1,
2.2.1
o secondaire, 2.3.1
Action
o diagramme dactivits, 6.2.1
Activit
o diagramme dactivits, 6, 6.2.2,
6.7
o groupe, 6.2.3
o nud, 6.2.4
Historique
o modlisation objet, 1.4.2
o programmation par objets, 1.3.5
Implmentation
o en Java, 3.6.2, 3.6.2
agrgation, 3.6.2
association 1 vers N, 3.6.2
association bidirectionnelle 1 vers 1,
3.6.2
association bidirectionnelle 1 vers N,
Agrgation, 1.3.4
o composite , voir relation de
composition
o implmentation en Java, 3.6.2,
3.6.2
Approche
o fonctionnelle, 1.3.1
o fonctionnelle vs. objet, 1.3.3
o objet (concepts), 1.3.4
o oriente objet, 1.3.2
o structure, 1.3.1
Artefact (diagramme de dploiement),
8.3.3
Association
o 1 vers 1 (implmentation en
SQL), 3.6.3
o 1 vers N (implmentation en
Java), 3.6.2
o 1 vers N (implmentation en
SQL), 3.6.3
o bidirectionnelle 1 vers 1
(implm. en Java), 3.6.2
o bidirectionnelle 1 vers N
(implm. en Java), 3.6.2
o quivalences, 3.3.7
o instance, 3.5.2
o modles quivalents, 3.3.7
o N vers N (implmentation en
SQL), 3.6.3
o n-aire, 3.3.3, 3.3.7
o n-aire (modle quivalent),
3.3.7
o n-aire vs classe-association vs
qualifie, 3.3.7
o notion et discussion, 3.3.1
o qualifie, 3.3.6, 3.3.7
o qualifie vs n-aire vs classeassociation, 3.3.7
o unidirectionnelle 1 vers 1
(implm. en Java), 3.6.2
o unidirectionnelle 1 vers N
(implm. en Java), 3.6.2
Attribut, 3.2.6, 3.3.1
o drivs, 3.2.6
o de classe, 3.2.6
o de la classe, 3.2.6
o implmentation en Java, 3.6.2
o implmentation en SQL, 3.6.3
o syntaxe, 3.2.6
Auto-association sur classe-association,
3.3.7
Automate tats finis, 5.1.2
Caractristique
o dune classe, 3.2.2
o terminaison dassociation, 3.2.2
Cas dutilisation, 2.2.2
o description textuelle, 2.5.3
3.6.2
association unidirectionnelle 1 vers 1,
3.6.2
association unidirectionnelle 1 vers N,
3.6.2
attribut, 3.6.2
classe, 3.6.2
classe abstraite, 3.6.2
composition, 3.6.2
hritage simple, 3.6.2
interface, 3.6.2
opration, 3.6.2
ralisation dune interface, 3.6.2
en SQL, 3.6.3, 3.6.3
association 1 vers 1, 3.6.3
association 1 vers N, 3.6.3
association N vers N, 3.6.3
attribut, 3.6.3
classe, 3.6.3
classe-association N vers N, 3.6.3
gnralisation, 3.6.3
hritage, 3.6.3
opration, 3.6.3
relation dhritage, 3.6.3
relation de gnralisation, 3.6.3
Instance
o association, 3.5.2
o classe, 3.2.1, 3.5.2
o classe-association, 3.5.2
o notion, 3.2.1
o relation, 3.5.2
Interaction, 7.1.4
o diagramme dinteraction, 7, 7.3.4
Interface, 1.3.4, 3.2.4, 3.2.7, 3.4
o implmentation en Java, 3.6.2
o asynchrone, 7.3.2
o de cration, 7.3.2
o de destruction, 7.3.2
o diagramme de communication, 7.2.3
o diagramme de squence, 7.3.2, 7.3.2
o vnement, 7.3.2
o perdu, 7.3.2
o porte, 7.3.2
o synchrone, 7.3.2
o trouv, 7.3.2
Mise en uvre dUML, 9, 9.4.2
Modle, 1.2.1
o cycle de vie en cascade, 1.2.3
o cycle de vie en spirale, 1.2.3
o cycle de vie en V, 1.2.3
o cycles de vie, 1.2.3
o incrment, 1.2.3
o Pourquoi modliser ?, 1.2.1
o Qui doit modliser ?, 1.2.1
Multiplicit
o relation dassociation, 2.3.1
Nud
o daction, 6.3.1
o dactivit, 6.2.4
o dactivit structure, 6.3.2
o dobjet, 6.5
o dunion, 6.4.4
o de bifurcation, 6.4.4
o de contrle, 6.4
o de dbranchement, 6.4.4
o de dcision, 6.4.3
o de fin dactivit, 6.4.2
o de fin de flot, 6.4.2
o de fusion, 6.4.3
o de jointure, 6.4.4
o de stockage des donnes, 6.5.6
o diagramme de dploiement, 8.3.2
o excutable, 6.3
o final, 6.4.2
o initial, 6.4.1
o tampon central, 6.5.5
Navigabilit, 3.3.5
o reprsentation graphique, 3.3.5
Note, 2.4.5
o reprsentation graphique, 2.4.5
Dploiement
o diagramme de dploiement,
8.3, 8.3.4
Dpendance
o classe, 3.3.10
Diagramme
o dtats-transitions, 5, 5.6.5
o dactivits, 6, 6.7
o dinteraction, 7, 7.3.4
o dobjets, 3.5, 3.5.3
o de cas dutilisation, 2, 2.5.4
o de classes, 3, 3.4
o de communication, 7.2, 7.2.3
o de composants, 8.2, 8.2.4
o de dploiement, 8.3, 8.3.4
o de squence, 7.3, 7.3.4
Diagramme dtats-transitions, 5, 5.6.5
o concurrence, 5.6.5
o tat, 5.2
o tat composite, 5.6, 5.6.5
o tat final, 5.2.2
o tat historique, 5.6.3
o tat historique profond, 5.6.3
o tat initial, 5.2.2
o vnement, 5.3, 5.3.5
o vnement dappel, 5.3.3
o vnement de changement,
5.3.4
o vnement de type signal, 5.3.2
o vnement temporel, 5.3.5
o point de choix, 5.5, 5.5.2
o point de dcision, 5.5.2
o point de jonction, 5.5.1
o points de connexion, 5.6.4
o transition, 5.4, 5.4.6
o transition dachvement, 5.4.5
o transition externe, 5.4.4
o transition interne, 5.4.6
Diagramme dactivits, 6, 6.7
o action, 6.2.1
activit, 6.2.2
exceptions, 6.2.1, 6.7
flot dobjet, 6.5.4
groupe dactivits, 6.2.3
nud daction, 6.3.1
nud dactivit, 6.2.4
nud dactivit structure,
6.3.2
o nud dobjet, 6.5
o nud dunion, 6.4.4
o nud de bifurcation, 6.4.4
o nud de contrle, 6.4
o nud de dbranchement, 6.4.4
o nud de dcision, 6.4.3
o nud de fin dactivit, 6.4.2
o nud de fin de flot, 6.4.2
o nud de fusion, 6.4.3
o nud de jointure, 6.4.4
o nud de stockage des donnes,
6.5.6
o nud excutable, 6.3
o nud final, 6.4.2
o nud initial, 6.4.1
o nud tampon central, 6.5.5
o partitions, 6.6
o pin dentre, 6.5.2
o pin de sortie, 6.5.2
o pin de valeur, 6.5.3
o transition, 6.2.5
Diagramme dinteraction, 7, 7.3.4
o interaction, 7.1.4
o ligne de vie, 7.1.4
Diagramme dobjets, 3.5, 3.5.3
o relation de dpendance
dinstanciation, 3.5.3
o reprsentation graphique, 3.5.2
Diagramme de cas dutilisation, 2, 2.5.4
o acteur, 2.2.1
o acteur principal, 2.3.1
o acteur secondaire, 2.3.1
o cas dutilisation, 2.2.2
o cas dutilisation interne, 2.3.1
o identifier les acteurs, 2.5.1
o recenser les cas dutilisation,
2.5.2
o relation dassociation, 2.3.1
o relation dextension, 2.3.2
o relation dinclusion, 2.3.2
o relation de gnralisation,
2.3.2, 2.3.2, 2.3.3
o relation de spcialisation, 2.3.2,
2.3.2
o relations, 2.3, 2.3.3
o reprsentation graphique, 2.2.3
o Use case Realization, 2.5.4
Diagramme de classes, 3, 3.4
o auto-association sur classeo
o
o
o
o
o
o
Paquetage, 2.4.1
o reprsentation graphique, 2.4.1
Partitions (diagramme dactivits), 6.6
Pin
o dentre (diagramme dactivits), 6.5.2
o de sortie (diagramme dactivits), 6.5.2
o de valeur (diagramme dactivits), 6.5.3
Point de choix, 5.5, 5.5.2
o point de dcision, 5.5.2
o point de jonction, 5.5.1
Point de dcision, 5.5.2
Point de jonction, 5.5.1
Points de connexion, 5.6.4
Polymorphisme, 1.3.4
Port (diagramme de composants), 8.2.3
Porte, 7.3.2
associations, 3.3.7
classe, 3.2, 3.2.8
classe association, 3.3.7, 3.3.7
classe association (instance),
3.5.2
o classe association pour
plusieurs associations, 3.3.7
o classe-association vs
association n-aire vs
association qualifie, 3.3.7
o laboration, 3.6.1
o interface, 3.4
o notion dassociation, 3.3.1
o possession dune terminaison
dassociation, 3.3.2
o propritaire dune terminaison
dassociation, 3.3.2
o relation dagrgation, 3.3.8
o relation dassociation, 3.3.3,
3.3.7
o relation dassociation binaire,
3.3.3
o relation dassociation n-aire,
3.3.3
o relation dassociation qualifie,
3.3.6
o relation dhritage, 3.3.9
o relation de composition, 3.3.8
o relation de dpendance, 3.3.10
o relation de gnralisation, 3.3.9
o terminaison dassociation, 3.3.2
Diagramme de communication, 7.2,
7.2.3
o connecteur, 7.2.2
o ligne de vie, 7.2.1
o messages, 7.2.3
Diagramme de composants, 8.2, 8.2.4
o composant, 8.2.2
o port, 8.2.3
Diagramme de dploiement, 8.3, 8.3.4
o artefact, 8.3.3
o nud, 8.3.2
Diagramme de squence, 7.3, 7.3.4
o vnement, 7.3.2
o excution de mthode, 7.3.2
o excution simultane, 7.3.2
o fragment dinteraction
combin, 7.3.3, 7.3.3
o ligne de vie, 7.3.1
o message, 7.3.2
o message asynchrone, 7.3.2
o message de cration, 7.3.2
o message de destruction, 7.3.2
o message perdu, 7.3.2
o message synchrone, 7.3.2
o message trouv, 7.3.2
o objet actif, 7.3.2
o
o
o
Qualificatif, 3.3.6
o
o
o
o
o
o
o
o
Gnralisation, 1.3.4
o cas dutilisation, 2.3.2, 2.3.2
o classe, 3.3.9
o implmentation en SQL, 3.6.3
Gnie logiciel, 1.1, 1.1.3
Gnie logiciel (crise), 1.1.3
Groupe dactivits (diagramme
dactivits), 6.2.3
Hritage, 1.3.4
Squence
o diagramme de squence, 7.3, 7.3.4
Spcialisation, 1.3.4
o acteur, 2.3.3
o cas dutilisation, 2.3.2, 2.3.2
Strotype, 2.4.4
Standish Group (tude du), 1.1.2
Terminaison dassociation, 3.2.2, 3.3.1, 3.3.2
o possession, 3.3.2
o proprit, 3.3.2
o propritaire, 3.3.2
Transition, 5.4, 5.4.6
o condition de garde, 5.4.2
o dachvement, 5.4.5
o diagramme dactivits, 6.2.5
o effet, 5.4.3
o externe, 5.4.4
o interne, 5.4.6
Typologie des contraintes OCL, 4.3, 4.3.7
Utilisation dinteraction, 7.3.4
Visibilit, 3.2.4
o
o
classe, 3.3.9
implmentation en Java, 3.6.2