Des différences de détails pour l'aspect statique
Ce chapitre est pour vous, cher lecteur, l'occasion de mettre en pratique une des conclusions de la précédente unité de cours : votre capacité à vous adapter à toute méthode de spécification formelle autre que NIAM.
Nous comparons rapidement les syntaxes des formalismes NIAM et UML[1] dans le tableau suivant. Pour information, la collection des symboles, et leur définition sémantique que nous examinons se nomment dans le jargon des modèles conceptuels « le méta-modèle[2] ».
Par ailleurs l'examen de la méthode UML[1] est un prétexte pour aborder de nouveaux concepts.
D'ou vient la méthode UML[1] (Unified Modeling Language) ?
S'appuyant sur les concepts objets, c'est une synthèse entre trois méthodes assez voisines très répandues : OMT[3] (Object Modeling Technique), Booch, et OOSE[4] (Object Oriented Software Engineering). Les trois auteurs de ces méthodes ont coopéré à cette synthèse UML : Rumbaugh James[5], Booch Grady[6], Jacobson Ivar[7].
Synthèse réussie, à constater la rapidité avec laquelle UML[1] se répand, et la liste des utilitaires logiciels qui intègrent ses diagrammes dans les ateliers de génie logiciel.
On constate que NIAM est à un niveau de granulométrie[8] plus fin, qui tient à un découpage binaire de l'aspect relationnel. Il oblige à une analyse des idées décomposées jusqu'à un niveau réellement élémentaire. Il permet une correspondance avec les propriétés de l'algèbre ensembliste. De ce point de vue, NIAM offre un avantage pédagogique certain.
En revanche, il est moins pratique dans l'élaboration opérationnelle des modèles. Il est moins concis qu'UML. NIAM a les défauts de ses qualités.
On a donc raison de préférer UML dans un contexte professionnel, qui permet beaucoup plus de libertés, par exemple dans l'expression des cardinalités, et qui de plus est plus complet, proposant également un modèle dynamique. Mais il est plus dangereux, car les incohérences sont plus difficilement décelables.
UML : Modèle statique | NIAM |
|---|---|
Acteur[9], use case[10], association
| concepts absents |
Classe[11], attribut[12], opération
L'identifiant est absent. Il est repéré par un attribut à qui on donne implicitement le statut de principal. A n'en pas douter, l'évolution d'UML comblera cette absence. | Concept[13] ou ensemble, identifiant
Concept opération absent |
Association (entre deux classes)
| Idée[15] (ou relation binaire) entre deux concepts[13] (ensembles)
|
Classe d'association
| Ce concept absent de NIAM est très pratique pour qualifier le nouvel ensemble constitué par les couples d'objets pris dans l'association A-B. |
Cardinalités : ensemble des entiers positifs
Exemples = 0..1 ; 1 ; 1..3 ; * * = plusieurs On peut de plus exprimer des contraintes de cardinalité sur chaque ensemble. (Voir plus loin)
| Cardinalités seulement binaires
Absence de symbole : pas de contrainte
|
Généralisation-spécialisation
| Relation d' [18] héritage [18]
|
Classe abstraite (sans instances) | Abstract super-type (sans occurrences) |
Association particulière d'agrégation (composé de, composant ou faisant partie de)
Le symbole flèche « losange » se place toujours du coté de l'agrégat, le contenant. Traduction en phrase élémentaires : Un objet de la classe A , par exemple un appartement, est composé de plusieurs pièces. Plusieurs pièces font partie d'un appartement. La sémantique de cette association implique deux propriétés :
Pour conserver explicitement la trace du contenu de chaque appartement, il faudrait créer une classe d'association. | NIAM ne distingue pas de noms particuliers pour une idée. Ce sont les rôles qui définissent la sémantique de la relation. Cette relation d'agrégation se traduit par le schéma :
|
Association unaire
| Idée[15] portant sur le même concept[13]
|
Contraintes[19] entre deux associations
Se note entre accolades.
Contrainte[19] portant sur les instances d'une classe :
Le principe de qualification libre d'une contrainte sur les occurrences d'un concept n'existe pas dans NIAM | Contraintes[19] entre deux idées[15] ou entre deux relations d'héritage[18]
Le symbole
Le symbole |
Les qualificateurs. Prenons un exemple
Traduction : dans un hôtel, il y a des chambres, qui portent entre-autre un numéro d'étage comme attribut. Le qualificateur permet de compter les chambres par étage : pour un numéro d'étage, il y a Y chambres. | Dans NIAM, il vaut mieux créer un concept à la place d'un attribut chaque fois que l'on doit utiliser un identifiant, comme ici le numéro. Le schéma NIAM correspondant à cet exemple comportera donc 3 concepts (hôtel, chambre et étage), et deux idées. Le schéma est moins concis, mais gagne en clarté. C'est d'ailleurs vrai aussi pour UML. |
