Vérification formelle de la cohérence d un modèle UML à base de relations de dépendance interdiagrammes

Vérification formelle de la cohérence d un modèle UML à base de relations de dépendance interdiagrammes Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI Laboratoire MIRACL, Université de Sfax, BP 1030, 3080, Sfax, Tunisie Mouez.ali@fmsf.rnu.tn, fahmi_bargui@yahoo.fr, {hanene.benabdallah, faiez.gargouri}@fsegs.rnu.tn Résumé. La multitude des diagrammes UML, bien qu elle permet la représentation des différentes vues du système, accentue la difficulté du processus de vérification et de validation. Les différents diagrammes dans un modèle UML se complètent et présentent plusieurs chevauchements sémantiques et syntaxiques entre eux. Dans ce papier, nous proposons une nouvelle approche de vérification formelle de modèles UML à base de relations de dépendance inter-diagrammes. Cette approche consiste à i) assurer la cohérence intra diagramme par la formalisation des diagrammes UML et ii) assurer la cohérence inter-diagrammes par la formalisation des relations implicites inspirées du processus unifié de modélisation et celles indiquées dans le méta-modèle d UML. Le langage formel utilisé est le langage Z. 1. Introduction La version UML 2.0 [18], permet de structurer les aspects d un SI avec treize diagrammes appartenant à différents niveaux d abstraction. Par exemple, l aspect statique d un système peut être décrit par un diagramme de classes, l aspect dynamique avec un diagramme de machines d états et les fonctionnalités générales peuvent être décrites sous forme de diagrammes de cas d utilisation (à un niveau assez abstrait). D autre part, la structuration des aspects d un système avec des diagrammes UML peut être guidée par la démarche de développement appelée Unified Process UP [11]. Cette démarche organise le travail de développement du système en termes de temps et d espace et se fait à travers des raffinements itératifs et incrémentaux des différents diagrammes. La multitude des diagrammes UML, bien qu elle permet la représentation des différentes vues du système, accentue la difficulté du processus de vérification et de validation. Les différents diagrammes dans un modèle UML se complètent et présentent plusieurs chevauchements sémantiques et syntaxiques entre eux. Ces chevauchements ne sont que partiellement pris en compte par les outils d aide à la conception, proposés pour UML. En effet, ces outils n offrent que des facilités d édition et les vérifications qui y sont intégrées se chargent essentiellement de

2 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI détecter les conflits simples comme ceux des noms (de classes par exemple). De plus, actuellement aucun AGL ne permet de réaliser une vérification de la cohérence de l ensemble des diagrammes spécifiant un système donné. Dans la littérature, plusieurs approches intègrent les techniques formelles dans le processus de développement (la phase de conception en particulier). Leur objectif est de réduire le coût d une erreur éventuelle en la détectant dès la première phase de développement des logiciels (avant de passer à la phase d implémentation). Plusieurs travaux appliquent des techniques formelles de V&V pour UML. Ces techniques adoptent soit l approche de formalisation du méta modèle UML comme [12], soit l approche de traduction des diagrammes UML vers un langage formel comme les travaux de [14] qui traduisent les concepts d un diagramme de classes en des machines B [1]. La première approche permet de vérifier essentiellement des propriétés syntaxiques des diagrammes. La deuxième approche focalise généralement sur un seul diagramme, généralement celui exprimant l aspect dynamique comme le diagramme d états [9, 13]. Nous proposons une nouvelle approche de vérification de modèles UML qui vise à intégrer les deux approches afin de bénéficier de leurs avantages. Plus précisément, notre approche de V&V de modèles UML a deux objectifs : 1) permettre la vérification de la cohérence d un modèle UML (ensemble de diagrammes), et 2) Réduire la difficulté de la vérification d une propriété complexe en la limitant à un sous-ensemble de propriétés plus simples et en la vérifiant et en la validant sur seulement quelques diagrammes d un modèle UML. Ce dernier objectif permet, d une part, de réduire la complexité de la vérification et, d autre part, de bénéficier des avantages des différentes techniques d analyse, comme la technique de modelchecking pour les diagrammes d états [9], et celle de theorem proving pour les diagrammes de classes traduits en Z [17]. La vérification formelle des modèles UML consiste à 1) assurer la cohérence intra-diagramme par la formalisation des diagrammes UML et 2) assurer la cohérence inter-diagrammes par la formalisation des relations implicites. Cette vérification assure la cohérence de l ensemble des modèles d une application. Ce papier est organisé comme suit ; dans la deuxième section, nous présentons notre approche de vérification formelle d un modèle UML. Dans la section 3, nous testons notre approche avec une étude de cas. Finalement, nous donnons les perspectives de ce travail. 2. Approche de vérification formelle d un modèle UML L originalité de notre approche est le fait d exploiter les relations explicites et implicites présentes entre les diagrammes d un modèle UML (Ali et al., 2004a). Les relations explicites sont dégagées à partir de la syntaxe d UML, comme définie dans son méta-modèle [18]. Les relations implicites représentent les chevauchements sémantiques présents entre les diagrammes d un modèle. Par exemple, il existe une relation implicite entre le diagramme de séquences et le diagramme de classes. En effet, nous devons vérifier que tout objet d un diagramme de séquences est aussi une

3 instance d une classe appartenant au diagramme de classes de la même application. Il est à noter que, pour notre démarche, nous avons identifié ces relations implicites à partir du processus de développement UP [18]. 2.1. Le processus de V&V d un modèle UML La figure 1 présente le processus de vérification formelle. En effet, dans une première étape, nous avons traduit formellement les concepts de base d UML. Meta modèle UML/ MOF Formalisation Editeur UML Transformation Méta-modèle formel + Base de règles de cohérence Spécification Z Analyse formelle de la spécification Z Résultat Fig. 1. Une vue simplifiée du processus de vérification formelle des modèles UML Dans une seconde étape ( ), nous traduisons chaque spécification du concepteur en une spécification formelle Z. Finalement, chaque spécification résultat est analysée et animée à l aide d un prouver Z/eves [19] ( ). Dans la section suivante, nous présentons les sources de règles de cohérence. 2.2. Source des règles de cohérence Afin d identifier les règles de cohérence inter diagrammes, nous nous sommes basé sur le processus unifié de développement afin d identifier les relations inter

4 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI diagrammes. De plus, le méta-modèle présente les dépendances inter concepts d UML 2.2.1 Processus unifié Le processus unifié UP est une démarche de développement des logiciels, produisant des modèles basés sur la notation UML. Ce processus permet une structuration en modèles comme le modèle d analyse, le modèle de conception, etc. Cette structuration peut mener à des représentations syntaxiquement et sémantiquement incohérentes. Pour cela, ce processus définit des relations implicites entre les modèles développés. En se basant sur UP, dans [2,4], nous avons dégagé les relations inter-diagrammes. La figure 3 illustre les différentes relations. U c <<Spec>> A c <<Spec>> <<Real>> S q <<Real>> C l <<Spec>> <<Equi >> <<Real>> <<Inst>> C o O b V e S m <<Spec>> <<Decomp>> <<Impl>> <<Dist>> D p T i P c C m S c Diagrammes de Relations implicites Cas d utilisation Communication Spécification Spec Séquence Réalisation Real Classes Equivalence Equi Activités Instance Inst Machines d états Distribution Dist Objets Implémentation Impl Composants Décomposition Déploiement Decomp Timing Structure Composite Vue d ensemble d Interaction Package Fig. 2. Relations de dépendance inter-diagrammes Uc C o S q C l A c E t O b C m D p T i S c V e P c 2.2.2. Méta modèle UML Le méta-modèle UML [15, 18] décrit la sémantique statique (partielle) du langage UML. La cohérence syntaxique est assurée par ce méta-modèle, dite encore la syntaxe

5 abstraite de UML. Ce méta-modèle donne une structure arborescente en utilisant les concepts de : - classes, pour définir la structure des nœuds, - attributs, pour définir les propriétés attachées à chaque nœud et, - associations, pour représenter les connexions entre ces nœuds. Fig. 3. Extrait du méta-modèle UML [15] Le méta-modèle présente des relations de dépendances explicites entre les éléments structurels par exemple «chaque message d une collaboration doit avoir une opération». 2.3. Règles de cohérence D une façon générale, un modèle conceptuel est cohérent si et seulement s il a satisfait des restrictions ou des règles de bonne formation. La restriction reflète la relation statique ou dynamique (syntaxique ou sémantique) entre les éléments structurels qu ils le composent [8]. Dans cet article, nous illustrons les règles assurant la cohérence d un modèle UML composé de trois diagrammes de séquences (Sq), de collaboration et de classes. Le tableau suivant illustre l ensemble des règles identifiées. Dans [5], un ensemble de règles est illustré pour assurer la cohérence syntaxique inter diagrammes de collaboration (Co) et diagramme de classes (Cl). Dans [3], nous donnons les règles de cohérences inter diagrammes de séquence et de classes. Le tableau suivant (figure 4) illustre l ensemble de règles ainsi que les trois diagrammes concernés.

6 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI N Diagrammes Description source 1 Sq, Co, Cl Une classe abstraite ne doit pas avoir des instances, elle ne peut ni envoyer ni recevoir des messages et des stimulus. Métamodèle 2 Sq, Co, Cl Tout classifieur (classe, acteur), émetteur (sender) et/ou receveur (receiver) d un message, ne doit pas être abstrait. 3 Sq, Co, Cl Un rôle d association est cohérent avec une association s il vérifie des contraintes (de correspondance, de multiplicité, de navigabilité et de visibilité) suivantes : [1] - La multiplicité maximale de chaque extrémité de rôle d association doit être inférieure ou égale à la multiplicité maximale de l extrémité d association de base et la multiplicité minimale de chaque extrémité de rôle d association doit être supérieure ou égale à la multiplicité minimale de l extrémité d association de base. [2] - Si une extrémité d un rôle d association est navigable alors l extrémité d association de base doit être aussi navigable. Autrement, si une «AssociationEndRole» est navigable alors «AssociationEnd» de base doit être aussi navigable. [3] - La visibilité de chaque extrémité de rôle d association doit être inférieure ou égale à la visibilité de l extrémité d association de base. 4 Co, Cl Un objet actif d un diagramme de collaboration est une instance d une classe active. 5 Co, Cl Tout objet du diagramme de collaboration doit être une instance d une UP classe déjà définie. 6 Co, Cl Pour tout message m échangé entre deux objets d un diagramme de UP collaboration, il existe une association entre deux classes. 7 Sq, Co, Cl Pour tout message m, il existe une méthode appartenant à une classe. UP 8 Sq, Co, Cl Pour toute condition de garde d un message m, il existe une précondition, UP qui la correspond, appartenant à la structure de l opération correspondante au message m. 9 Sq, Co, Cl Pour tout paramètre d un message m, il existe un et un seul paramètre de la méthode correspondante. Métamodèle 10 Sq, Co, Cl Tout attribut dérivé d une classe C nécessite une méthode op1. Cette méthode correspond à un message m de type callprocedure. 11 Sq, Co Un rôle d association doit être le même pour tout message Sq.M et son correspond dans Co.M. 12 Sq, Co Le sender et le receiver d un message doivent être les mêmes pour un message du diagramme de séquence et son correspond dans le diagramme de collaboration. 13 Sq, Co La durée d activation d un objet o émetteur (sender) d un message nécessite une instance du classifieur tel que instance_of(classifieur) = o. 14 Sq, Co Un rôle d association doit être le même pour tout message Sq.M et son correspond dans Co.M. 15 Sq, Co Le sender et le receiver d un message doivent être les mêmes pour un message de diagramme de séquence et son correspond dans le diagramme de collaboration. 16 Sq, Co, Cl La durée d activation d un objet o émetteur (sender) d un message nécessite une instance du classifieur tel que instanceofclass = o. 17 Sq, Co, Cl Pour tout objet appartenant au diagramme de séquence. Il existe un objet appartenant au diagramme de collaboration. Tab 1. Tableau des règles de cohérence identifiées UP

7 3. Formalisation des règles de cohérence d un modèle UML Afin d assurer la cohérence d un modèle de conception (ensemble de diagrammes de collaboration, séquence, de classes, etc), dans cette section, nous présentons les règles assurant la cohérence et leur formalisation à l aide du langage formel Z. cette formalisation est dérivée des travaux de [10]. Nous présentons un extrait de la spécification formelle avec le langage Z. La figure 5 présente un extrait de notre formalisation des trois diagrammes. (a). Diagramme de classes (b) Diagramme de séquences (c) Diagramme de collaboration Fig. 4. Spécification formelle des diagrammes de classes, séquences et collaboration. 3.1. Cohérence entre le diagramme de classes et le diagramme de collaboration Le théorème de la figure 5 permet de vérifier si la contrainte de navigabilité est respectée au niveau de diagramme de collaboration (c est la règle 3 [2] du tableau 1).

8 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI theorem navigibilitycheck ACo ECl Aar: associationroles Eas: associations as = ar. base ar. e 1. availablenavig = True fi as. e 1. isnavigable = True ar. e 2. availablenavig = True fi as. e 2. isnavigable = True proof of navigibilitycheck prove by reduce Fig. 5. Extrait de la traduction de la règle [2] Le schéma Z (Fig 6) présente l ensemble des prédicats nécessaires traduisant les règles du tableau 1. Fig. 6. Schéma de la relation «réalisation» traduisant les règles du tableau 3.2 Cohérence entre le diagramme de séquences et le diagramme de collaboration Selon le méta-modèle [15], Communication Diagrams correspond to simple Sequence Diagrams that use none of the structuring mechanisms such as InteractionUses and CombinedFragments.

9 La spécification Z (figure 9) illustre la relation d équivalence «equiv», illustrée par le graphe de dépendance (section 2.1.1) entre les deux diagrammes de collaboration et de séquences.»_ Equivalence Æ CollDiag : UMLCollaborationDiagram ÆSeqDiag: UMLSequenceDiagram Æ A Co: CollDiag E 1 sq: SeqDiag Æ A m : Co.UMLMessage E 1 m1: Sq.UMLMessage m.name =m1.name Æ A i: 1..# : Co.m.UMLparametres Ej e N Sq.m1.UMLparametres. Æ Co.m.UMLparametres(i).name=Sq.UML.name =Sq.m1.UMLparametres(j).name ÆCo.m.UMLparametres(i).type= Sq.UMLparametres(j).type Fig. 7. Spécification de la relation d équivalence «Equivalence» Ce schéma vérifier que deux instances de deux diagrammes CollDiag et SeqDiag sont équivalentes. 3.3. Fonctions de transformation des concepts UML Afin d automatiser la traduction d une spécification UML vers une spécification formelle Z, nous nous sommes inspirés des travaux de kim et al [12]. Ces derniers proposent de définir des fonctions de mapping des concepts des différents diagrammes vers des schémas Object-Z. A titre d exemple, nous avons défini le schéma Z suivant pour la fonction mapumlclass. ÆmapUMLClass: UMLClass fzsch ÆA uc:umlclass mapumlclass(uc)={zs:zsch uc.name=zs.name ÆE ua:attributes E za: zs.attributes Æza.name=ua.name za.type= convtype(ua.type) Æza.visibility=ua.visibility ÆA uo:uc.operations ÆE zo: zs.operations Æzo.name=uo.name zo.visibility=uo.visibility ÆA up: ran uo.parameters ÆE zp: ran zo.parameters Æzp.name=up.name zp.type =convtype(up.type)} Cette fonction qui retourne un schéma Z avec le même nom de la classe à transformer. Tous les attributs d une classe sont des types du schéma Z. 4. Expérimentation : Etude de cas Dans cette section, nous illustrons notre approche de vérification de la cohérence avec une version simplifiée du problème de jeux de deux dés. Ce problème est tiré de l ouvrage Applying UML and Patterns de Craig Larman [6]. Le joueur lance 10 fois

10 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI 2 dés. Si le total des 2 dés fait 7, il marque 10 points à son score. En fin de partie, son score est inscrit dans le tableau des high scores. Fig. 8. Diagramme de classes jeu_deux_dés Dans ce papier, nous intéressons aux trois diagrammes donnés par les figures 8, 9 et 10. Afin d assurer la cohérence du modèle, nous appliquons l ensemble de règles transformation. L ensemble de diagrammes de l application est traduit en une spécification formelle Z. Fig. 9. Un diagramme de collaboration jouer_deux_dés Fig. 10. Diagramme de séquences jouer_deux_dés En appliquant les fonctions de mapping comme mapumlclass, mapumlobject, mapumlmessage, mapumllink, nous obtenons les schémas Z nécessaires. Nous présentons un extrait de la spécification formelle du modèle nommé jeux_deux_des :

»_ name Ætype: string Ævisibility : visibilitykind Æmultiplivcity: N Æ multiplivcity =1 Æ visibility =private»_score Ætype:int Ævisibility : visibilitykind ÆinitiedValue: N ÆinitialValue=0 Æ visibility =private»_ play Ævisibility: visibilkitykind ÆreturnType: type Æparameters: seq UMLparametre Ævisbility =private ÆreturnType=void Æparametres = Ò»_player Æname Æscore... La spécification suivante présente les schémas Z qui décrivent séparément les trois diagrammes de l application :»_ jeux_deux_des Æ player: PPlayer Ædie:PDie ÆdieGame:PDieGame ÆhighScore:PHighScore Æentry:PEntry ÆRolls:PlayerjDie ÆPlays:Player DieGame ÆIncludes:DieGamejDie ÆScoring:DieGame HighScore 11

12 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI Æ dom Rolls=player Æran Rollsz die Ædom Plays = player Æran Plays = diegame Ædom Include = diegame Æran Include z die Ædom Scoring = diegame Æran Scoring = highscore ÆA r:rolls #Rolls {r} = 2 ÆA i:includes #Includes {i} =2»_ Dc_Jeux_deux_Des Æ game: DiceGame Ætoto: Player Æd1,d2: Die Æinterractions: seq UMLMessages Æ interractions= play, r1=roll, r2=rollò»_ Sq_Jeux_deux_des ÆRealPalyer: RealPlayer ÆDiceGame: DiceGame Æd1, d2: Die ÆHighScore: HighScore Æinterractions: seq UMLMessages Æinterractions= DieGame, Die, Die, HignscoreÒ Pour assurer la vérification de la propriété d équivalence entre les deux diagrammes de séquence et de collaboration, nous appliquons un ensemble des théorèmes. Par exemple, l exercice du théorème t1 qui vérifie que tous objets est une instance d une classe donnée. La figure 7 présente la relation InstanceOfClass. La démonstration du théorème est donnée par la figure 8. Fig. 6. Spécification Z de la relation de réalisation inspirée du UP

13 Fig. 7. Animation théorème d instance t1 4. Conclusion et perspectives Le présent travail présente une approche formelle pour vérifier la cohérence d un modèle UML (de conception) à base des relations de dépendances issues du processus UP et celles inspirées de la syntaxe abstraite du méta-modèle UML. Dans cet article, nous avons illustré notre approche à travers trois diagrammes du modèle de conception UML. Une étude de cas simplifiée est présentée afin de vérifier la cohérence du modèle entier. Les règles identifiées assurent un passage au modèle d implémentation (diagrammes de composant et de déploiement) en réduisant le risque d avoir des erreurs de conception. Comme perspectives de ce travail, noue envisageons d assurer la cohérence intermodèles UP et d automatiser les opérations de traductions des spécifications de concepteur vers Z en profitant des facilités la technologie XML/XMI puisque la majorité des AGL génère une documentation en format XMI pour un projet UML. Bibliographie 1. Abrial J.R., The B-Book, Cambridge University Press, 1996. ASIN : 0521496195, 813 pages. 2. Ali M., Ben-Abdallah H., Gargouri F. "Validation des Besoins dans les Modèles UML2.0". Proceeding of INFORSID 2006: 959-974. 3. Ali M., Ben-Abdallah H., Gargouri F. Towards a Validation Approach of UP Conceptual Models, in: Proceeding of Consistency in Model Driven Engineering workshop in European Conference on Model Driven Architecture - Foundations and Applications, pages 143-154, 7-10 Novembre 2005, Nuremberg, Germany. 4. Ali M., Ben-Abdallah H., Gargouri F. Towards coherence verification of functional requirement descriptions, in: Proceeding of the international workshop of Use case for

14 Mouez ALI, Fahmi BARGUI, Hanêne BEN ABDALLAH, Faïez GARGOURI Modelling Driven Architecture at ACM-IEEE UML/Models 05, October 2-7, 2005, Jamaica. 5. Bargui F, Vérification de la cohérence d un modèle UML. Mémoire de mastère en informatique. Université de Sfax, FSEGS nouvembre 2006. 6. Craig Larman, Applying UML and Patterns, Prentice Hall PTR, 2000, ISBN-13: 978-0137488803, 507 pages. 7. Dupuy S., Ledru Y., Chabre-Peccoud M., An overview of RoZ - a tool for integrating UML and Z specifications, in: Proceeding of the 12th Conference on Advanced information Systems Engineering (CAiSE'2000), 2000. 8. Engles G., Kuster J.M., Groenewegen L., and Heckel R. A methodology for Specifying and Analyzing Consistency of Object-Oriented Behavioral Models, in: Proceeding of the 8th European Software Engineering Conference (ESEC) and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9), ACM Press, 2001 editor: V. Gruhn. 9. Gihwan K. Rewrite rules and operational Semantics for model checking UML state charts, In: Proceeding of the third International Conference UML 2000, pages 528-540, Volume 1939 of LNCS, Springer, October 2000, York, UK. Editors: Andy Evans, Struart Kent, and Branselic, the Unified Modeling Language, Advancing the Standard. 10. Haddar N. "intégration des représentations conceptuelles ". Thèse de doctorat, Université Tunis, 2005. 11. Ivar J, Grady B., and Rumbaugh J., The Unified Software Development Process. Addison Wesley/ACM Press, 1997. ISBN: 0201571692, 463 pages. 12. Kim, S.-K., Carrington D., A Formal Mapping between UML Models and Object-Z specifications. Technical Report, 00-03, Software Verification Research Center University of Queensland, 2000. 13. Latella D., Majzik I., and Massink M. Towards a Formal Operational Semantics of UML Statechart Diagrams, in: Proceeding of the third International Conference on Formal Methods for Open Object-Oriented Distributed Systems, Kluwer Academic Publishers (1999). Editors In P. Ciancarini and R. Gorrieri, IFIP TC6/WG6.1 14. Ledang H., "Traduction Systématique de Spécification UML en B". Thèse de doctorat, Université Nancy 2, novembre 2002. 15. Meta Object Facility (MOF), OMG. version 2.0. Technical report, Object Management Group, 2003. 16. Smith G. "The Object-Z Specification Language. Advances in Formal Methods, Kluwer Academic Publishers, 2000. ISBN 0-7923-8684-1. 160 pages. 17. Spivey. J. M., The Z Notation: A Reference Manual, Prentice Hall, 2nd edition, 1992. 18. UML 2.0 Superstructure Specification, OMG Document, ptc/03-08-02http://www.omg.org/ docs/ptc/03-08-02.pdf, 2003. 19. Irwin Meisels and Mark Saaltink. The Z/EVES 2.0 Reference Manual. Technical Report TR-99-5493-03e, ORA Canada, October 1999.