urbanisation-si.com

Il faut bien noter que les diagrammes séquence sont des exemples d'interactions qui doivent respecter les spécifications des diagrammes de types. Tous les diagrammes d'interaction doivent être conformes aux diagrammes de types. L'inverse n'est pas vrai, certaines propriétés des diagrammes de types ne sont pas dêmontrables car les interactions ne définissent pas TOUTES les instanciations possibles.

Exemples de règles dificiles à démontrer :

• Toute classe a des instances dans au moins une interaction
• Tous les événements ou actions de type envoi de message ou de signal d'une machine figurent dans au moins une interaction (actions reçues/émises).
• Toutes les opérations d'une classe sont utilisées dans au moins un diagramme d'objet ou un diagramme états-transitions ou la description d'une autre opêration.
• Tous les attributs sont accédés par au moins une opération (pré- post-conditions OCL).
• Tout événement d'un diagramme états-transitions apparaît dans un diagramme d'objets.
• Une classe abstraite n'a pas dtinstances.

Ci dessous une liste non exhaustive de règles de vérification entre interactions et diagrammes de types :

• Tout objet est défini par au moins une ciasse. Nous conseillons de ne pas avoir d'objets ou
• de classificateurs type sa,ns nom de classe. Son utilisation est conforme à la spéciûcation
• de la classe : son état (ses valeurs) est conforme à la définition de ses attributs ; ses liens sont conformes à ses associations (classes, cardinalités, contraintes, propriétés) ; un objet composant ne peut communiquer qu'avec son composé ou avec d'autres composants (encapsulation forte) ;  une classe abstraite n'a pas d'instances ; l'invariant de la classe est respecté ; si I'objet est actif, sa classe doit l'être ; si t'objet est multiple, sa classe doit être une sous-classe de la classe Collection ; si des règles associées au stéréotype de la classe sont formalisées en OCL, on peut envisager de les vérifier.
• Si deux objets communiquent, alors il existe une navigation possible entre les classes de ces objets

Pour chaque envoi de messâge, on vérifie les points suivants :

• Les messages reçus par un objet sont déflnis par des événements dans le diagramme états-transitions de sa classe ou par des opérations de la classe s'il n'y a pas d'automate ;
• Les actions des envois de messages ou de signaux sont conformes à celles des opérations utilisées (profil, synchronisme) ; les actions des envois de messages ou de signaux sont conformes à celles des transitions (appel d'opération, signal, création, destruction), lorsqu'une machine existe chez Ie receveur (profil, synchronisme) ;
• Si un message est envoyé par un objet, on doit trouver une action correspondant à cet envoi chez I'appelant, soit dans la description d'une opération ou dans son graphe d'activité, soit dans la machine associée à la classe de l'objet ou de I'une de ses super-classes ;
• Si un résultat est envoyé par un objet, on doit trouver une action correspondant à I'invocation d'une opération. Le résultat est conforme au profil de I'opération et à sa post-condition ;
• Si un envoi de message est gardé dans la collaboration, il en est de même dans la machine ;
• Si un envoi de message est itératif dans la collaboration, il en est de même dans la machine, I'opération ou le graphe d'activité ;
• Si un envoi de message est récursif dans l'interaction, il en est de même dans la machine, I'opération ou le graphe d,activité.

Dans un diagramme de collaboration, on vérifie la conformité de la structure avec le diagramme de classe :

• Les objets ou classifi.cateurs type correspondent à des classificateurs. S'iIs ont des descriptions spécifiques, elles doivent être conformes à celles des classes (valeurs, invariants, stéréotypes, etc.).
• Les liens ou associations type correspondent à des associations. Les caractéristiques des associations sont respectées par leurs occurrences (noms de rôles, cardinalités, contraintes, agrégation, composition, etc.).
• Les relations autres que I'association type entre deux classificateurs type sont une copie identique de la même relation entre classe.
• Les stéréotypes et contraintes sont cohérents. Difficile à vériter.

L'ordre des envois de message ou de signaux est conforme à I'ordonnancement imposé par les machines des objets concernés. Les liens de précédence entre messages d'une collaboration sont conformes à I'ordonnancement imposé par les machines des objets concernés.

L'ordre des envois de message ou de signaux induits par un- appel d'opération est conforme à I'ordonnancement imposé par le graphe d'activité de I'opération, ou à défaut de la liste des actions de l'opération.

Si un objet a plusieurs flots de contrôle concurrents dans un diagramme de séquence alors sa classe est active et ses flots apparaissent dans la machine.

Les points suivants sont plus difficiles à vérifier :

• Cohérence des expressions OCL. Par exemple, vérifier que les cond.itions des gardes ne sont pas toujours fausses.
• Vérification de type, tena"nt compte du polymorphisme.
• Simulation des diagrammes de séquence à I'exécution.
• Vérification des règles de visibilité des attributs et des opérations.

"La bonne humeur a quelque chose de généreux: elle donne plutôt qu'elle ne reçoit."

Alain

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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/