Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (8)
Voici quelques exemples de règles à vérifier.
Chaque élément de modélisation a un nom unique dans son espace de nommage. Une propriété d'instance ne peut de ce fait avoir le même nom qu'une propriété de classe. Deux opérations se distinguent par leur nom. La surcharge avec un profil différent est donc interdite, ce qui n'est pas un usage courant en objet.
Les propriétés sont définies dans les classificateurs. Dans le diagramme de classes, on doit restreindre ces classificateurs aux classes, aux associations ou aux qualificatifs d'association. Une interface ne contient que des opérations.
Les opérations sont définies da,ns les classes ou classes-association (spécialisation "multiple" de ciasse et association) mais pas dans les noeuds ou les cas d'utilisation.
Le type des paramètres d'une opération est inclus dans I'espace de travail du classificateur associé.
Si une classe est concrète (non abstraite) toutes ses opérations doivent avoir une implantation en terme de mêthode.
Les relations entre classes peuvent être de type généralisation, association ou dépendance. Les relations de spécialisation, d'agrégation ou de composition sont antiréflexives et antisymétriques. Les graphes de ces relations sont orientés et sans circuit.
Une association est une relation composée de deux terminaisons vers des classificateurs. Par héritage, une classe peut donc être associée à un composant. Il faut définir des contraintes dans les sous-classes pour qu'une classe soit associée uniquement à des classes dans le modèle des classes.
Selon le métamodèle, toute association a un nom (unique comme nous I'avons vu). En pratique, ies noms d'associations ou de rôles sont facultatifs. Si deux associations (sémantiquement) différentes existent entre deux classes alors d'une part elles ont obligatoirement un nom d'association ou de rôle et d'autre part tous ces noms doivent être différents.
Une association est navigable dans au moins un sens.
Deux attributs de qualification d'une association doivent avoir des noms différents. Il n'y a pas d'interférence avec les propriétés des classificateurs.
Toute propriété (resp. association) dérivée doit être accompagnée d'une expression OCL valide indiquant le mode de calcul de la dérivation. Une association dérivée doit être compatible, d'un point de vue cardinalités et contraintes) avec les associations dont elle dépend.
La composition est exclusive. Dans la relation de composition, un objet est composant d'au plus un composé (cardinalité maximale de 1) et cet objet ne peut être lié directement pax une autre relation de composition sauf en présence de cardinalités minimales de 0 à chaque fois et d'une contrainte d'exclusion (xor ou nand) entre les deux associations de compositions. La composition indirecte est implicite par transitivité de la relation de composition.
Si deux sous-classes sont exclusives (discriminant ou coatrainte disjoint) alors un héritage multiple de ces classes est interdit.
Certaines vérifications portent sur la cohérence entre contraintes posées sur les associations (cardinalités, notations de contraintes, expressions OCL) :
- les cardinalités des associations doivent être cohérentes ;
- une association avec une cardinalité (unique) 0 sur une extrémité n'a pas de sens ;
- une association binaire avec la cardinalité 1 sur chaque extrémité signifie que les deux objets sont intimement liés. On doit vérifier qu'il s'agit bien de deux objets différents. Sauf cas particulier, une telle association doit être une composition.
Les contraintes entre associations doivent être compatibles avec les cardinalités des associations :
- la contrainte standard d'exclusion xor n'est pas compatible avec la cardinalité minimale de 1. La règle est identique pour la contrainte de totalité disjonctive or et Ia contrainte d'unicité (présence dans une seule association) ;
- la contrainte de totatité and est redondante avec la cardinalité minimale de 1 sur chaque extrémité d'association concernée ; la contrainte d'égalité = implique des cardinalités identiques sur chaque extrémité d'association concernée.
Les contraintes entre associations doivent être cohérentes entre elles :
- les contraintes sur associations ne sont acceptables que pour des ensembles comparables. Par exemple, I'inclusion (subset) d'association n'est possible que si les extrémités sont égales ;
- les contraintes portant sur une association doivent être cohérentes. Par exemple, I'inclusion (subset) d'association est incompatible avec les contraintes xor et nand et partiellement redondante avec les contraintes or et and ;
- la vérification entre associations deux-à-deux n'est pas suffisante. Il faut vérifier les contraintes globalement.
- La vérification des expressions OCL doit prendre en compte les règles de visibilité des éléments.
- Quel est le sens de lecture d'une association n-aire (n>2) ?
"Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés."
Confucius
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
A découvrir aussi
- Unified Process Analyse et Conception : voici ce que doit faire la MOE
- Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (4)
- Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (6)
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 769 autres membres