3.1.2.2. La vue dynamique
La vue dynamique est orientée algorithme et
traitement, elle vise à décrire l'évolution (la dynamique)
des objets complexes du programme tout au long de leur cycle de vie. De leur
naissance à leur mort, les objets voient leurs états
changés et ce à cause de leur interaction avec d'autres objets du
programme. La vue dynamique est constituée des diagrammes
d'états, des diagrammes d'activité,
des diagrammes de séquence et des diagrammes de
communication.
Diagramme de séquence :
Un diagramme de séquence sert à la description
d'un scénario possible dans la description d'un cas d'utilisation d'une
fonction. Les diagrammes de séquences mettent en valeur les
échanges de messages (déclenchant des événements)
entre acteurs et objets (ou entre objets et objets) de manière
chronologique (l'évolution du temps se lisant de haut en bas). Chaque
colonne correspond à un objet (décrit dans le diagramme des
classes), ou à un acteur (introduit dans le diagramme des cas). La ligne
de vie de l'objet représente la durée de son interaction avec les
autres objets du diagramme. Notons que le même besoin dans un logiciel
peut être réalisé à travers plusieurs
scénarios, dans ce cas on aura donc plusieurs diagramme de
séquence pour ce même besoin.
41
Diagramme de séquence associé à
chaque cas d'utilisation :
Gérer une collection : une collection
est gérée par un utilisateur, le logiciel lui-même et le
système d'exploitation dans le quel tourne l'application.
Figure 3.7 : Diagramme de séquence de la
gestion d'une collection.
42
Gérer un groupe : un groupe est
contenu dans une collection. Pour cela on suppose qu'une collection a
été démarrée. Le diagramme de séquence
ci-dessous est celui d'un groupe qui sera créé et contenu dans
une collection.
Figure 3.8 : Diagramme de séquence de la
gestion d'un groupe.
Gérer une copie : une copie est
contenue dans un et un seul groupe. Pour cela on suppose que le comportement de
la copie dont le diagramme de séquence est donné ci-dessous est
dans un groupe qui lui-même est dans une collection ; bien
évidemment le groupe et la collection étant ouverts.
43
Figure 3.9 : Diagramme de séquence de la gestion
d'une copie.
Ces diagrammes de séquences nous ont permis d'avoir un
comportement détaillé de chaque objet de notre application et de
ressortir les différentes méthodes associées à
chacun d'eux. Tout ceci étant fait on peut donc présenter la vue
statique de notre application.
3.1.2.3. La vue structurelle ou statique
La vue structurelle présente la structuration des
données et identifie les objets/composants constituant le programme,
leurs attributs, opérations et méthodes, ainsi que les liens ou
associations qui les unissent. Elle regroupe également les classes
fortement liées entre elles en des composants les plus autonomes
possibles. Cette vue a pour objectif principal de modéliser la structure
des différentes classes d'une application orientée objet ainsi
que leurs relations [18]. La vue statique est
constituée des diagrammes de classes, des
diagrammes de
44
packages, des diagrammes
d'objets, des diagrammes de structure composite, des
diagrammes de déploiement.
· Le diagramme de classe :
Le diagramme de classe est le diagramme le plus
important dans la modélisation UML (il est le diagramme
prioritaire pour les outils de génération automatique de code).
Ces diagrammes sont représentés avec plus ou moins
d'exhaustivité selon que l'on est en phase d'analyse, de conception ou
d'implémentation. Avant de dessiner un diagramme de classe il est donc
important de tenir compte de la phase dans laquelle on se trouve ; ainsi donc
:
En phase d'implémentation on cherche à
décrire chaque classe, ses attributs et ses méthodes en pensant
déjà au code qui les implémentera tout en prenant en
compte les contraintes matérielles de temps d'exécution,
d'architecture, etc.
Présentation des concepts utilisés dans le
diagramme de classe
Les concepts élémentaires que nous
présentons dans cette section sont les plus employés pour la
réalisation de la vue structurelle d'un modèle UML et ceux que
nous avons utilisé pour la réalisation de notre diagramme de
classe.
Une classe :
De façon sémantique : En UML,
une classe définit la structure commune d'un ensemble d'objets et permet
la Construction d'objets instances de cette classe. Une classe est
identifiée par son nom. [18]
De façon graphique : Une classe se
représente à l'aide d'un rectangle sous forme de tableau à
une colonne et trois lignes ; qui contient le nom de la classe (première
ligne et éventuellement le nom du package auquel elle appartient)
viennent ensuite les propriétés (deuxième ligne) de la
classe puis ses opérations (troisième ligne). La Figure
3.11 illustre la classe nommée User.
Les propriétés ou attributs
Pour une classe, une propriété peut être
vue comme une forme simple d'association entre les objets (instances) de la
classe et un objet de classe standard. Il s'agit d'une variable qui est en
général propre à l'objet ou qui est peut être commun
à tous les objets de la classe (on parle alors de
propriété de classe). Dans un diagramme de classe les
propriétés de la classe sont notées de la façon
suivante :
<NomAttribut> : <Type> = [<valeur par
défaut>]. (Voir deuxième ligne Figure
3.11)
Les opérations
Une opération peut être vue comme une
tâche que doit effectuer l'objet lorsqu'on lui fait appel. En
programmation elle représente une méthode de la classe. Dans un
diagramme de classe la notation des opérations se fait de la
façon suivante :
<NomOpération> (ListeParamètres) :
<TypeRetour>(Voir troisème ligne Figure
3.11) On distingue deux catégories d'opérations :
· celles qui modifient l'état de l'objet (ses
attributs) : ces opérations sont appelées modifiants ou
mutateurs.
· A l'opposé des opérations d'accès ou
accesseurs qui ne se contentent que de retourner la valeur d'une
propriété.
De ce qui précède on a donc la Figure 3.11
suivante :
User
IdUser : integer Nom : string
Creer( ) Demarrer( ) Changer ( )
|
|
Figure 3.11 : Représentation graphique d'une
classe
Les associations
Les associations représentent des relations entre
objets, c'est-à-dire entre des instances de classes. Aux
extrémités d'une association figure la multiplicité
(cardinalité) qui est une énumération sous forme
d'intervalle d'entiers positifs ou nuls indiquant le nombre d'objets qui
peuvent participer à une relation avec l'objet de l'autre classe dans le
cadre d'une association. Les multiplicités sont notées de la
manière suivante
1 : Obligatoire (un et un seul)
0..1 : Optionnel (0 ou 1)
0..* ou * : Quelconque
n..* : Au moins n
n..m : Entre n et m (n et m en entier)
I,n,m : I, n, ou m
45
Les multiplicités les plus utilisées sont : 1,*,
1..* et 0..1.
46
Ayant présenté de façon très
brève les concepts du diagramme de classe, et les informations acquises
lors de la réalisation des diagrammes de cas d'utilisation et de
séquence ; ces informations nous ont permis d'avoir le diagramme de
classe suivant :
Figure 3.12 : Diagramme de classe de l'application
PressePapier1.0
· Le diagramme de package
Un package est un regroupement de classes présentant
des liens sémantiques entre elles. Le regroupement de classes en package
est une activité délicate mais d'une importance capitale dans les
logiciels de grande taille. Le regroupement de classes en packages les plus
indépendants possibles améliore la modularité du logiciel
et son développement par des équipes séparées (en
évitant les interactions) ou encore en utilisant les classes statiques
déjà développées et pouvant se mettre en relation
avec les classes de l'application qu'on veut
47
implémenter. La structuration d'un modèle en
package doit respecter deux principes fondamentaux à savoir : la
cohérence et l'indépendance.
La cohérence consiste à regrouper
les classes qui sont proches d'un point de vue sémantique.
Le principe de l'indépendance vise
à concentrer les efforts pour minimiser les relations entre les packages
(autrement dit les relations entre classes de packages différents).
Les classes de la Figure 3.12 étant en
relation avec les classes statiques du système d'exploitation dont un
héritage n'est possible il est vient donc qu'il soit possible de les
mettre en relation grâce aux packages. D'où les packages suivant
:
Figure 3.13 : Package de l'application
PressePapier1.0
Figure 3.14 : Package des classes du système
d'exploitation
48
Des Figure 3.13 et Figure 3.14
on obtient le diagramme de package suivant :
49
Figure 3.14 : Diagramme de package du
PressePapier1.0.
| 
