urbanisation-si.com

20/08/2015

0 J'aime 2 Poster un commentaire

Modélisation de système : rien n'est parfait du premier coup alors mettez en place une gestion de version

Réfléchissez à comment vous allez gérer vos differentes versions de modèles dans l'AGL que vous avez choisi pour vos projet.

Ne faites pas comme dans ce projet ou MEGA était utilisé sans gestion de version.

Au fil des itérations et des évolutions, il fallut bien faire quelque chose.

Alors l'administrateur eût la brillante idée de concevoir un méta modèle en créant une entité changement et une série de scripts pour qu'à chaque fois que l'utilisateur apporte une modification, il aille lui même dans un nouvel onglet créer un changement en indiquant son type et ce sur quoi il porte.

Cela permet de connaître les évolutions d'une iteration et de générer juste le différentiel dans le Modèle Physique de Données.

Par contre, rien n'est automatique, il faut que l'utilisateur pense lorsqu'il fait une modification à créer un changement, indiquer le type, ... Si finalement il décide d'annuler son changement, il faut aussi qu'il supprime le changement. Et s'il oublie de le faire ?

La seule et unique bonne solution consiste à installer au départ une Gestion de Configuration Logicielle comme Microsoft Visual Source Safe ou pour les opensource Subversion ou GIT.

Ceci n'est pas un luxe mais une nécessité.

L'urbaniste ou l'architecte doit convaincre les sponsors que le surcoût sera largement rentabilisé à très court terme.

"Nous portons en nous des merveilles que nous cherchons en dehors de nous."

Thomas Browne

Voir aussi :

06/06/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (12)

Automatisation de la vérification des modèles UML.

En s'inspirant des techniques de compilation, la vérification dans le langage UML est découpée en deux parties : syntaxe et sémantique.

La syntaxe abstraite (les structures réelles du langage, indépendamment du sucre syntaxique) est celle définie par le métamodèle.

En compilation, toujours, les vérifications lexicales, syntaxiques et certaines vérifications sémantiques sont dirigées par la syntaxe.

Dans UML, comme nous I'avons vu, bon nombre de règles lexicales, syntaxiques et de sémantique statique peuvent être formulées à partir du métamodèle.

La structuration des règles est induite par Ia syntaxe : elles sont rangées par élément de rnodélisation. Ces règles, pour peu quelles soient formalisées, sont décrites sous forme d'assertions OCL. Pour vérifier les règles, il faut disposer d'outils d'évaluation et de preuve pour OCL.

Pour automatiser la vérification des règles, il faut les formuler dans le langage OCL et disposer d'outils pour Ie contrôle, la preuve et l'évaluation avec OCL.

En résumé, il faut qu'OCL soit un langage formel à part, entière et outillié.

Un premier travail consiste, à partir de la description du langage OCL, à développer un environnement de développement autour d'OCL (edition, compilateur, évaluateur, débogueur, etc.) et une interface avec le métamodèle.

Ce travail permettra alors d'étudier en profondeur le langage et de lui donner une sémantique formelle, condition indispensable pour vérifier la pertinence, la cohérence ou mieux la complétude des règles.

Pour que la vérification puisse s'intégrer avec le processus de développement, il faut pouvoir associer des degrés de vérification au niveau d'itération atteint. On accordera plus d'importance à certaines propriétés du système et des modèles dans les premières itérations et plus d'importance à d'autres dans les dernières itérations. La vérification va de pair avec le niveau de détail exigé.

"Il ne faut pas pleurer pour ce qui n'est plus mais être heureux pour ce qui a été."

Marguerite Yourcenar

Voir aussi :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (11)

Quels besoins en pratique ?

La vérification repose sur des descriptions complètes des modèles, une liste exhaustive et cohérente de règles de vérification, un ordre d'application de ces règles. En pratique, elle repose aussi sur une automatisation du processus, dans I'AGL qui permet de saisir les modèles puis de les exploiter.

Une vérification de cohérence n'est pas possible si les diagrammes sont volontairement incomplets c'est-à-dire si tout ce qui est noté dans un diagramme n'a pas besoin d'être noté dans I'autre, l'union des deux donnant le modèle global.

Par exemple, si dans un diagramme états-transitions les opérations et les événements émis ne sont pas modélisés, il est difficile de vérifer la cohérence avec le diagramme de classes, les diagrammes d'objets et les autres diagrammes états-transitions.

En résumé, des vérifications sont possibles si les diagrammes ont un niveau de détail suffisant.

Dans un processus itératif et incrémental, les seuls modèles complets sont ceux qu'on obtient à la fin du processus.

La seule sémantique formelle est celle du langage de programmation cible. A chaque itération du processus unifié, les différents modèles du systèmes sont enrichis, sachant que les modèles d'analyse des besoins, d'analyse et de conception sont plus complets dans les premières phases (préparation, élaboration) tandis que les modèies de déploiement, d'implantation et de test sont plus riches dans les dernières phases (construction, transition).

La vérification doit s'adapter à cette réalité : on travaille rarement avec des modèles complets.

Il est en effet souhaitable dans un modèle d'analyse de donner I'allure générale sans trop de détails. Ainsi, pour conserver un certain niveau d'abstraction, on peut omettre le profil des opérations, la description interne des opérations, ne définir que des interfaces pour certains paquetages ou certaines classes, etc.

L'usage de la vérification doit prendre en compte ces contraintes pratiques. On peut imaginer plusieurs niveaux de vérification, un filtrage de certaines règies, des priorités dans les erreurs relevées, des degrés de vérification) une qualité de la vérification, etc.

"Nous sous-estimons souvent le pouvoir d'un contact, d'un sourire, d'un mot gentil, d'une oreille attentive, d'un compliment sincère, ou d'une moindre attention ; ils ont tous le pouvoir de changer une vie."

Leo Buscaglia

Voir aussi :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (10)

Vérification croisée des diagrammes de types et d'instances.

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 :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (9)

Vérification croisée des actions et des classes

Dans un envoi de message, Ie receveur du message est la cible de I'action (msg.receiver = msg . action . target). Si le type de la cible est calculabie statiquement, alors ce type est une classe déclarée.

Si la classe a des paramètres, ceux de la classe de la cible doivent être compatibles.

Si l'action modifie des attributs alors ceux-ci doivent être définis dans la classe de la cible. Pour cela, il faut que le script soit une expression analysable, une expression OCL par exemple.

Si une action est asynchrone, alors la classe de I'objet à I'origine de I'action doit être active.

Si l'action invoque une opération alors la classe de la cible doit déclarer ou hériter cette opération. Les paramètres des actions doivent être compatibles (au sens du typage) avec la signature (le profil) des opérations de Ia classe.

Si I'action crée une instance, alors la classe associée doit exister et les paramètres de I'instanciation doivent être compatibles avec la méthode d'instanciation de cette classe. La cible n'a pas de sens. Si le langage autorise les métaclasses, la création d'instance est un appel d'opération ordinaire.

Si l'action rend un résultat, alors elle doit être corrélée à un appel d'opération et être conforme au profil de cette opération.

Si I'action envoie un signal, ce dernier devra être capté par la cible. Il est défini par une classe ; les pararnètres de l'envoi sont compatibles avec la spécification du signal.

Si I'action supprime une instance, définie dans la cible, alors cette dernière devait exister !

Une action de terminaison n'a ni argument ni paramètre.

Un stimulus (ce qui est envoyé à une instance) est associé aux actions de création, d'appel d'opération, d'envoi de signal ou de destruction d'opération.

Si une action modifie un attribut, alors elle respecte I'invariant de la classe.

"Nous vivons avec nos défauts comme avec les odeurs que nous portons : nous ne les sentons plus ; elles n'incommodent que les autres."

Marquise de Lambert

Voir aussi :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (8)

Vérification du diagramme de classes.

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 :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (7)

La vérification du modèle logique est statique c'est-à-dire avant I'implantation du système.

La vérification statique prend en compte les combinaisons licites d'éléments de modélisation et des propriétés de la spécification (cohérence, complétude).

Elle est basée sur la syntaxe, le typage des éléments, ou la cohérence des contraintes (cardinalités, notations de contraintes, expressions OCL). D'un point de vue langage et compilation, il s'agit de la syntaxe et de la sémantique statique. La syntaxe est la disposition correcte des éléments de modélisation, la sémantique statique est une restriction des combinaisons possibles, selon certaines propriétês des spécifications (cohérence, complétude, etc.).

On ne tient pas compte d'un "contenu" réel ou d'une exécution (sémantique dynamique).

En UML, la description du langage s'appuie sur le métamodèle. On peut dire que la structure du métamodèle définit Ia syntaxe. Par exemple, un "classificateur" ou classifier (classe, UC, noeud) a des propriétés (opérations ou attributs) et peut faire I'objet de connexions avec des associations. Une opération ne peut être en relation directe avec une association.

La vérification syntaxique ne tient pas compte a priori des commentaires, mais dans le cas des contraintes exprimées avec OCL, on peut vouloir inclure la vérification (syntaxique) des expressions OCL.

Des contraintes OCL ont donc été ajoutées dans le métamodèle, qui réduisent le nombre de combinaison licites. On peut qualifier ces contraintes de sémantique statique :

Règles d'agencement ; par exemple, une interface ne contient pas d'autres propriétés que des opérations, la relation d'héritage est anti réflexive.
Contraintes : typage, cardinaiités, contraintes entre associations, contraintes OCL.
Cas particuliers liés à une connaissânce plus profonde de la sémantique des concepts : par exemple, il n'y a pas d'héritage multiple pour des sous-classes d'un discriminant, un objet passif ne peut envoyer deux messages simultanément. Dans cette catégorie rentrent aussi les règles associées aux stéréotypes.

Le modèle logique est constitué d'un ensemble de diagrammes représentant des aspects complémentaires et non disjoints du système à modéliser.Deux niveaux de vérification : le niveau diagramme et le niveau modèle.

On peut dire que I'effort de vérification des diagrammes est plus proche de Ia syntaxe tandis que celui de la vérification des modèles est orientée vers la sémantique.

"La vie me semble trop courte pour la passer à entretenir des ressentiments ou ressasser des griefs."

Charlotte Brontë

Voir aussi :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (6)

Le niveau physique est basé sur les diagrammes de composants et de déploiement.

La cohérence entre ces deux vues du niveau externe est basée simplement sur une association entre éléments et noeuds : un élément est rattaché à des noeuds.

Comme pour Ie niveau externe, on peut distinguer la syntaxe de la sémantique.

Certains contrôles syntaxiques sont implantables dans I'outil de modélisation :

Unicité des noms dans le système et les sous-systèmes.
L'unique relation entre éléments est la dépendance. La relation enire næuds est I'association.
Les éléments reliés à un nceud sont définis. Inversement, tout élément doit être lié directement ou indirectement à un noeud.
Les interfaces peuvert être associées aux composants et servir de point d'encrage âux dépendances entre composants.

La notation des diagrammes de composants et de déploiement est relativement pauvre. Il s'agit avant tout d'une définition structurelle du système logiciel (composants) et matériel (déploiement).

La sémantique associée est tout aussi pauvre, ce qui est en complète contradiction avec Ia réalité puisque le logiciel et le matériel constituent des domaines extrêment complexes et variés.

L'ajout de stéréotypes permet d'enrichir la notation. Par exemple, on distingue différentes sortes de composants (programmes, sous programmes) tâches, composants génériques, processus, etc.). Les stéréotypes permettent aussi de rêférencer I'environnement système sous-jacent ; composants (classe java, paquetage java, fichier source, exécutable, processus, interfaces, bibliothèque, répertoires, sous-systèmes, système existants...), dépendances (compilation, liaison dynamique...), liaisons (internet, middleware...), noeuds (PC, mainframe, dispositifs périphériques...). Mais, il n'y a là rien de rigoureux qui nous permette d'établir les bases d'une vérification. En fait, la sémantique réelle est repoussée à l'implantation réelle du système, et à ce niveau là, il existe des descriptions formelles, des règles à respecter et des outils de manipulation des spécifications (des programmes).

Les modèles du niveau physique sont une représentation simplifiée de l'implantation système qui met en évidence son architecture, sans se soucier des détails. La vérification est celle du système implanté.

"Le bonheur, c'est de continuer à désirer ce que l'on possède."

Saint-Augustin

Voir aussi :

31/05/2015

0 J'aime 0 Poster un commentaire

Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (5)

Le niveau externe inclut les diagrammes de cas d'utilisation et les scénarios rattachés à ces diagrammes.

La cohérence entre ces deux vues du niveau externe est basée simplement sur une association entre cas d'utilisation (UC) et scénarios : un scénario est rattaché à un seul cas d'utilisation. La syntaxe et le nombre de concepts sont réduits.

Certains contrôles syntaxiques sont implantables dans l'outil de modélisation :

Unicité des noms, y compris dans les catégories (paquetages structurant les cas d'utilisation)
La relation entre UC et acteur est une association
Les cas d'utilisation reliés à un acteur sont définis. La relation entre UC est une association, une dépendance ou une spécialisation.
Les acteurs et les UC reliés à un cas d'utilisation sont définis.
Les acteurs apparaissant dans un scénario d'un UC et sont reliés à cet UC.

La représentation étant essentiellement textuelle, la vérification sémantique (cohérence, complétude) doit faire I'objet de revues et d'inspection.

La spécialisation de cas d'utilisation doit absolument être évitée.

Dans tous ces cas, la vérification est manuelle et doit s'appuyer sur une définition précise et claire, à défaut d'être formelle, des règles de modélisation et d'interprétation des concepts.

Une méthode d'identification des Use Case doit être fomalisée pour permettre leur vérification et leur traçabilité.

( Voir l'article que j'ai consacré à la méthodologie de l'expression des besoins : https://www.urbanisation-si.com/urbanisation-si-la-methode-ultime-pour-modeliser-les-besoins-d-un-projet-14eme-partie-cas-dutilisation-uml-diag-use-case )

"On n'est heureux que dans la proportion de ce qu'on donne."

Louis Bromfield

Voir aussi :