M.E.D.A.L.

M.E.D.A.L.M.E.D.A.L.

Module d’Enseignement à Distance pour Module d’Enseignement à Distance pour l’Architecture Logiciellel’Architecture Logicielle

Alain VAILLYDiapositive n° 1 IUP MIAGE - Université de NANTES

IUP-MIAGE 3ème année

UML, esperanto ou babel ?

Alain VAILLYDiapositive n° 2

1) Introduction

IUP MIAGE - Université de NANTES


Avec un langage complexe, à géométrie variable (sémantique) et des éléments combinables à souhait,

peut-on écrire des spécifications de qualité (c’est à dire cohérentes, complètes, lisibles, exploitables, etc) ?



- L’interprétation varie avec le contexte : exemple des diagrammes d’activités,- Le contenu varie avec le niveau d’abstraction : exemple des classes en analyse et en implantation,- Dans un modèle, on trouve des préoccupations différentes : utilisation, classes, objets, composants- L’usage varie avec la méthode de développement : méthode itérative degré de précision

1) Introduction



Chacun a sa sémantique d’UML en fonction de sonexpérience, des langages et environnements de

développement utilisés, des applications développées, desbesoins requis.

ProblèmeProblème : de nombreuses modélisations erronées, incohérentes,incomplètes...

SolutionsSolutions : Gérer la complexitéProposer un compilateur (ou un interpréteur)

Proposer un correcteurAutres solutions...

1) Introduction



1. GrouperGrouper les diagrammes par activité :approche (UC, scénarios, activités)logique (classes, DET, activités, séquences, collaborations)implantation (composants, déploiement, classes)

2. LimiterLimiter l’usage des diagrammes par activité.3. GrouperGrouper les diagrammes par type InstanciationInstanciation :

scénario UC, séquence, collaboration classe, DET, activités

4. AssocierAssocier les diagrammes complémentaires :DET activités, DET classe, opération activité,

composant déploiement

1) Introduction



Aspects syntaxiquesAspects syntaxiques : le méta-modèleproblème de classification des conceptspas de grammaire complèteun jeu de règle de vérifications (complet ? cohérent ?)

Aspects sémantiquesAspects sémantiques : langage naturelpas satisfaisantdes travaux en coursmulti-formalisme

Executable UMLExecutable UML :traduction complète (sémantique opérationnelle)génération de code par le compilateurextraction pour les spécifications formelles

1) Introduction



Objectifs limitésObjectifs limités : vérifier des propriétésde systèmes : redondances, non-blocage...de modèles : cohérence, complétude...de processus : équivalences, traçabilité...

EvolutifEvolutif :le correcteur s’adapte au compilateurle correcteur s’intègre dans différents outilsla base de règles est incrémentale, paramétrable

RigoureuxRigoureux :formaliser les règles (OCL, spec. formelles)vérifier la base de règles (cohérence...)

Automatisable, génération de test

1) Introduction


2) Vérification



La vérification consiste à s’assurer que les modèles successifs satisfont la spécification globale, que le

développement est correct par rapport à la spécification de départ.

Il y a trois catégories de propriétés sur lesquelles peut porter la vérification : les propriétés du système, les

propriétés des modèles et les propriétés du processus.


2) Vérification



Les propriétés du systèmepropriétés du système sont relatives aux trois aspects d’un système :

structurelstructurel : pas de redondances d’informations, volumes finis, modularité, cohérence…

fonctionnelfonctionnel : terminaison des calculs, temps fini, cohérence, complétude…

dynamiquedynamique : pas de blocage, pas de famine, équité, sureté…


2) Vérification



Dans UML / UP, il s’agit de vérifier la cohérence et la complétude des descriptions à travers les différents

diagrammes.

Nous pouvons ranger dans la catégorie propriétés des propriétés des modèlesmodèles celles relatives à la qualité des

spécifications : cohérence, complétude, non redondance…

Cela correspond à la vérification croisée données / traitements dans Merise.


2) Vérification



- un échange dans un diagramme de collaboration,

Par exemple, un envoi de message dans un diagramme de séquence peut / doit correspondre à :

- une opération dans un diagramme de classe,

- une transition dans un diagramme états-transition,

- un sous-diagramme d’activité…


2) Vérification



Il s’agit, en gros, de vérifier qu’à travers les niveaux d’abstraction, les spécifications sont toujours les

mêmes.

Nous pouvons ranger dans la catégorie propriétés du propriétés du processusprocessus celles relatives à la qualité du processus :

sûreté, terminaison, traçabilité…

Dans UML / UP, la propriété essentielle est la traçabilité des éléments dans le cycle de

développement.


2) Vérification



Nous dégageons trois étapes :

- établissement des propriétés attendues pour chaque modèle ou groupe de modèles,

- définition pour chaque propriété de règles ou de contraintes de vérification,

- vérification par elle-même.

(ce que l’on veut étudier) (ce que l’on veut étudier)

(ce que l’on(ce que l’onveut obtenir)veut obtenir)


2) Vérification



Il y a des pistes, dans les ouvrages, dans les manuels de documentation, dans les outils…

Actuellement, il n’existe pas de document de référence établissant les bases d’une mise en œuvre de

la vérification dans UML et UP.

Il y a encore un travail énorme à faire ici.


2) Vérification



Vérifier quelques centaines de règles prend du temps. Pour que la vérification soit opérationnelle, il faut l’outiller : outils de saisie et d’édition de modèles,

outils de vérification, outils de simulation…

La construction de ces outils repose sur une formulation claire et précise des concepts, des

modèles et des règles de cohérence.


2) Vérification



Pour automatiser la vérification des règles, il faut les formuler dans le langage OCL et disposer d’outils

pour le contrôle, la preuve et l’évaluation avec OCL.

Il faut qu’OCL soit un langage formel à part entière et outillé.

Il faut donc qu’il ait lui même une sémantique formelle (non ambigüe).

Il faut donc que la notation UML, elle-même, ait une sémantique formelle, modulaire et incrémentale.


2) Vérification



Plusieurs axes de travail et de recherche peuvent être mis en évidence, autour :

- du langage OCL,

- de la notation UML,

- du processus de vérification…

… voire du métamodèle lui-même.

Precise UMLPrecise UML

www.cs.york.ac.uk/puml/www.cs.york.ac.uk/puml/


3) Conclusion



On attend…On attend…

Pour se prévaloir du titre de norme, UML se doit d’être un langage rigoureux et bien fondé. De nombreux travaux ont été lancés dans ce sens.

Tant qu’une sémantique formelle d’UML et d’OCL ne sera pas disponible, la vérification de modèles ne sera pas possible (ou très aléatoire) et on sera plus près de

Babel que de l’espéranto.

M.E.D.A.L.

Documents

Transcript of M.E.D.A.L.