Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Description structurale du système

L’état des lieux

Les descriptions dynamique et fonctionnelle ont révélé comment le système doit fonctionner pour que les acteurs du métier puissent remplir leur mission, et à quoi il sert (quels services sont rendus aux acteurs).

De ces deux descriptions doit surgir une conception de premier niveau : de quels composants le système doit-il être doté pour qu’il soit capable de remplir son office ? La préoccupation change : on se place désormais à l’intérieur du système et on décrit sa structure interne.

Il s’agit donc d’établir sa description structurale : les composants vont être décrits, et on va s’interroger sur la manière dont ils vont collaborer. Ces deux préoccupations sont peu dissociables, elles coexistent même si les obligations rédactionnelles imposent d’en faire des sujets séparés.

La description structurale (ou statique) fait appel aux notions de classes et de composants, qui seront représentés dans les diagrammes correspondants. Bien que classes et composants d’un système puissent être identifiés et construits en cohérence avec les spécifications fonctionnelles, l’analyste du métier se servira essentiellement de la notion de classe ; la notion de composant intervient...

Les notions de classe et de composant

Classes et composants vont servir à structurer le système, puis amorceront la génération du code, ainsi que celle de la base de données.

1. Définitions

Classe

À l’origine, la classe est un apport informatique.

La notion de classe est issue des langages orientés objet (C++, Java, Smalltalk, Delphi...). Elle peut être vue comme le prolongement de la structure du langage C. Une structure en C décrit une entité sous forme de plusieurs propriétés. Par exemple, un point est décrit en donnant son abscisse, son ordonnée, sa cote (ses trois dimensions) ; un segment est décrit en réunissant deux points dans la même structure.

En plus des propriétés, la classe possède des traitements. Ces traitements agissent sur les propriétés de la classe en modifiant leur valeur : ils pilotent le devenir de la classe.

Ces traitements sont implémentés par du code informatique ; ils sont appelés en UML opérations. Les propriétés sont dénommées attributs en UML.

Opérations et attributs sont membres de la classe.

Une classe est un patron : c’est à partir de la classe Point que l’ensemble des points sont construits. De même, tous les véhicules de LOCA’ROYANS sont issus de la classe Véhicule.

Spécifier une classe UML, c’est fournir la liste de ses attributs et de ses opérations.

La classe doit être désormais vue sous l’angle fonctionnel.

images/Chap5Fig1.png

Figure 1 : Exemple de classe (notation UML) : les trois compartiments : nom, attributs, opérations

Chaque point issu de la classe Point est une instance de Point ; chaque véhicule de LOCA’ROYANS issu de la classe Véhicule est une instance de Véhicule. Cela signifie que la classe est une entité abstraite (elle n’a pas d’existence physique), alors que l’instance est une entité concrète, elle a une existence physique (elle naît, elle vit, elle meurt).

Par conséquent, nous avons deux descriptions possibles d’une classe :

  • Une classe est vue comme un patron des instances manipulées par le système ; pour la décrire, il faut fournir l’ensemble...

Les concepts UML en jeu

Cette section reprend les éléments de la description statique vus précédemment et énonce leur description selon UML. Elle veut bâtir une vision cohérente de tous les éléments vus jusque-là.

1. La classe

La classe en UML est destinée à classer des instances (c’est-à-dire à les réunir dans des ensembles cohérents), à préciser leur structure et leur comportement.

La classe UML est dotée :

  • d’attributs membres ;

  • d’opérations membres ;

  • éventuellement de réceptions, de ports et de connecteurs.

La réception d’une classe spécifie quels signaux cette classe est capable de traiter. Cette question sera examinée au chapitre Description collaborative du système. Cette possibilité offerte par UML n’est pas souvent utilisée.

Instancier une classe, c’est créer une instance en considérant cette classe comme un patron. De plus, les attributs des objets doivent (tous) être valorisés, en cohérence avec leur type et leur multiplicité.

Les opérations membres d’une classe peuvent modifier les valeurs des attributs membres.

Enfin, deux remarques pour ceux que le modèle d’UML (son métamodèle) ne rebute pas :

Ce qui différencie une classe des autres classifiers, c’est que Classe hérite à la fois de Behaviored Classifier et de Encapsulated Classifier. L’arbre d’héritage vu à la figure 15 est en fait un peu plus riche :

images/Chap5Fig23.png

Figure 23 : La classe et d’autres classifiers UML (représentation simplifiée)

C’est Encapsulated Classifier qui permet d’affecter un port à une classe ; Behaviored Classifier apporte la capacité à une classe d’être la réalisation d’une interface (interface realization).

2. Le port et l’interface

Port est une classe dérivant de Property ; Interface, dérive de classifier. La représentation des classifiers UML s’en trouve enrichie.

images/Chap5Fig24.png

Figure 24 : La classe et autres classifiers UML (représentation simplifiée)

3. L’association

Une association binaire...

Pour aller plus loin

La description structurale propose d’autres éléments descriptifs ; en particulier, il est possible d’enrichir la syntaxe UML et donc de l’adapter à un contexte particulier. 

1. La classe paramétrée

Cette notion est particulièrement fructueuse lorsqu’il s’agit de décrire des ensembles. Une classe ensemble permet de créer des classes Collections, Catalogues, Portefeuilles... On remarque que, quel que soit le contenu d’un ensemble, certaines des propriétés et opérations membres de cet ensemble sont identiques.

Par exemple, la gestion d’un catalogue de véhicules disponibles et celle d’un portefeuille de clients présentent plusieurs points communs : il faut pouvoir ajouter, consulter, connaître le nombre d’éléments contenus, etc.

images/Chap5Fig35.png

Figure 35 : Classes paramétrées UML

On définit une classe générique Collection, capable de stocker plusieurs instances d’Eléments. Un élément n’est pas défini à ce niveau : on sait que c’est une classe d’objets concrets, objets qu’on peut ajouter, chercher et enlever, compter.

Cette classe générique donne naissance à deux classes réelles : CatalogueVéhicule est une collection capable de recevoir des véhicules ; Liste-Clients est une collection capable de recevoir des clients. Ainsi, le paramètre Eléments a reçu pour valeur respectivement la classe Véhicule et la classe Client lors de la création des deux classes générées CatalogueVéhicule et ListeClients à partir de la classe générique Collection.

UML prévoit que l’association entre les classes Collection et CatalogueVéhicule soit stéréotypée «access» ; c’est un lien d’importation entre ces classes. Cette précision peut être oubliée.

En revanche, il faut bien noter que la classe Eléments a été remplacée par deux classes réelles : Véhicule et Client.

2. L’association ternaire

L’association ternaire est un concept extrêmement puissant, d’une grande richesse expressive. Son maniement...

Conclusion

1. Les solutions spécifiques : l’analyse préfigure la conception

UML est particulièrement bien équipé pour la description statique d’un système. Cette description préfigure la future solution puisque les classes et composants membres de cette description statique vont donner naissance aux composants (modules informatiques) du système solution.

Cette première description statique est issue de la spécification métier : la description dynamique et la description fonctionnelle ont justifié la présence de ces classes et composants, qui sont déduits des objets manipulés par les gens du métier. On est en phase d’analyse : on les appelle classes et composants d’analyse.

Les classes d’analyse vont générer la base de données et le code du programme, mais pas directement. Ces classes d’analyse seront auparavant, en fonction du style architectural choisi, transformées en classes de conception. Ce sont ces classes de conception qui vont piloter la construction du code et de la base de données. Il ne faut surtout pas passer directement de l’analyse à la production du code et de la base de données de la solution.

Les ouvrages consacrés à l’architecture logicielle et des systèmes répondent à cet impératif : les classes...