Validation des Besoins dans les Modèles UML2.0

Validation des Besoins dans les Modèles UML2.0 Mouez ALI, Hanene BEN-ABDALLAH, Faïez GARGOURI Laboratoire MIRACL, FSEG - ISIM, Université de Sfax, BP 1030-3018, Sfax. TUNISIE. mouez.ali@fmsf.rnu.tn, {hanene.benabdallah, faiez.gargouri}@fsegs.rnu.tn RÉSUMÉ. Les systèmes d information deviennent de plus en plus complexes et présentent davantage des exigences de fonctions, temps de réponse, fiabilité, sécurité de communication, etc. Pour appréhender cette complexité, UML propose plusieurs diagrammes permettant de structurer, documenter et analyser les différents aspects de ces systèmes. Cependant, la diversité des diagrammes UML peut facilement mener un développeur à définir des diagrammes incohérents au sein du même modèle. Dans ce papier, nous présentons une approche de vérification et de validation formelles des modèles UML. L approche proposée repose sur les dépendances explicites et implicites entre les diagrammes d un modèle dérivé selon UP et respectant la syntaxe d UML comme définie dans le méta-modèle. ABSTRACT. Information systems are becoming further complex and require increasing constraints in their functionalities, response time, reliability, security, etc. To overcome this difficulty, UML proposes several diagrams to structure, document and analyse such systems. However, the diversity of the UML diagrams can easily induce a developer to specify incoherent diagrams within the same system model. In this paper, we present an approach for the formal verification and validation of UML models. The proposed approach relies on the explicit and implicit dependencies among the diagrams of a model derived according to UP and respecting the UML syntax as defined in its meta-model. MOTS-CLÉS : UML, UP, Vérification, Validation Formelle, relations inter-diagrammes. KEYWORDS: UML, UP, Formal Verification, Validation, inter-diagrams relationships

1. Introduction De nos jours, les systèmes d information deviennent de plus en plus complexes et présentent davantage des exigences de fonctionnement, fiabilité, sécurité, etc. Afin d appréhender cette complexité des systèmes, la majorité des méthodes et langages de conception propose de structurer, documenter et analyser séparément les différents aspects d un système en termes de vues (Perin, 2000). Ces dernières permettent de décrire, séparément et à différents niveaux d abstraction, les aspects statique, dynamique et fonctionnel d un système. Parmi les langages de conception jouissant d une grande popularité, UML (OMG, 2003 ; Raumbaugh et al., 2004) est devenu le standard de fait pour la modélisation des systèmes d information, tant dans la communauté industrielle qu académique. La version UML 2.0 permet de structurer les aspects d un système 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). En plus, 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 Processus Unifié (Jacobson et al., 1997). 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 permette 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 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é. D autre part, dans la littérature, deux techniques de vérification et de validation (V&V) de modèles sont utilisées (Katoen, 2002). La première technique, peer review, consiste à effectuer des révisions et des examens manuels des modèles représentant un système. La deuxième technique, software testing, consiste à générer une suite de tests utilisés pour dégager les erreurs dans l implémentation. La première technique de V&V est très subjective. Elle dépend de la compréhension et de l interprétation des diagrammes UML. De plus, étant manuelle, elle ne peut donc pas offrir un grand degré de fiabilité. La deuxième technique de V&V nécessite la génération du code de l application afin de faire des cas de tests (test unitaire, test d intégration, etc.). Cependant, le coût de la réparation des défauts durant la phase

de maintenance est 500 fois plus important que durant la phase de conception (Katoen, 2003). Ainsi, l intégration de techniques formelles au cours de la V&V des modèles UML durant la phase de conception (préliminaire et détaillée) permet de réduire le coût de détection et de réparation des erreurs de conception avant de passer à l implémentation. Nous distinguons deux approches appliquant des techniques formelles de V&V des modèles UML, à savoir, l approche de formalisation du méta- modèle UML (Kim et al., 1999 ; Evans et al., 1999) permettant de vérifier des propriétés syntaxiques des diagrammes et l approche de traduction des diagrammes UML vers un langage formel, dite encore couplage entre UML un langage formel. Dans (Ledang, 2002), l auteur accomplit le travail commencé par Mayer (Mayer, 2001), qui consiste à traduire les concepts du diagramme de classes vers des machines B (Abrial, 1996), par la traduction des concepts du diagramme de collaboration, étendus par des contraintes d OCL, en des machines B. La deuxième approche, focalise seulement sur un sous ensemble des diagrammes d UML, par exemple ceux exprimant l aspect dynamique comme le diagramme d états (Latella et al., 1999, Gihwan et al., 2000). Notre approche, proposée pour la V&V de modèles UML, vise à combiner les deux approches précédentes afin de bénéficier de leurs avantages. Plus précisément, nous nous fixons deux objectifs : i) permettre la V&V de tous les diagrammes d un modèle UML ; et ii) réduire la V&V d un modèle en une vérification élémentaire de certains diagrammes du modèle. Ce dernier objectif permet, d une part, de réduire la complexité de la V&V et, d autre part, bénéficier des avantages des différentes techniques d analyse, comme la technique de model-checking, pour les diagrammes d états (Gihwan et al., 2000), et la celle de theorem proving pour les diagrammes de classes traduits en Z (Jonathan, 1996). L objectif de ce papier est de proposer une démarche de validation des besoins dans les modèles UML. Dans la section 2, nous présentons une version simplifiée d une librairie en ligne (Roques, 2003) que nous utiliserons pour illustrer nos propositions. Dans la section 3, nous présentons notre approche de vérification et de validation globale des modèles UML. Dans la section 4, nous détaillons la validation des besoins des utilisateurs. La section 5 résume le travail présenté et souligne ses perspectives. 2. Exemple : librairie en ligne Nous utiliserons dans les sections suivantes l exemple d une librairie en ligne inspiré de (Roques, 2003). La modélisation de cet exemple est spécifiée avec un diagramme de classes (partiellement illustré dans la Figure 1), un diagramme de séquences «alimenter panier» (Figure 2), des diagrammes d états pour les objets «livre», «panier» et «commande» (Figure 3).

/ total Panier recalculer() ajouterligne() supprimerligne() viderpanier() 1..n LignePanier quantite prixunitaire recalculer() 0..n concerne donne_lieu 1 0..1 commande date modfierreglement delailivraison fraisdeport / montant 0..n est passée_par 1 client nom prenom motdepasse email 1 adresse_facturation 1 1 adresse_livraison Adresse numerorue complements codepostal ville pays telephone societe opname() 0..1 1 Livre titre soustitre ISBN nbpages langue dateparution prix disponiblite GetDetails() 0..1 cartebancaire type numero datevalidite Figure 1 : Diagramme de classes de «la gestion des commandes» : internaute : resultatrecherche fichedétaillee : Catalogue l : Livre : panier afficherdetaillivre afficher(id) details :=getdetails create(details) mettredanspanier ajouter_ligne(qte) recalculer Figure 2 : Diagramme de séquences de «Alimenter panier» S q1

Comme indiqué dans le diagramme de séquence (figure 2), une des fonctionnalités principales du système est de permettre à un internaute de rechercher un livre et d avoir plus de détails sur cet livre. maj-infos nouveaulivre supprimer [ qte=null ] / changer_etat livre_dispo nible MAJ( stock ) livre_non_dis ponible ajouter_nouveau_ouvrage selectionner_ouvrage panier vide supprimer( panier p ) supprimer E t1 : diagramme d état transition de l objet «livre» panier alimenté dernier_ligne panier validé E t3 : diagramme d état transition de l objet «commande» commande créée supprimer ajouter_contenu_panier archiver commande calculée livrer_commande commande livrée E t2 : diagramme d état transition de l objet «panier» Figure 3: Les diagrammes d états transitions des objets «livre», «panier» et «commande». Ainsi, lorsque l internaute est intéressé par un livre, il peut l enregistrer dans un panier virtuel. Il a, à tout moment, la possibilité d ajouter d autres livres, d en supprimer ou encore de modifier les quantités avant de valider la commande. Comme illustré par la figure 3, les machines d états des objets «livre», «panier» et «commande» illustrent le cycle de vie de chaque objet en indiquant ses états possibles et les transitions nécessaires. 3. Approche globale de V&V Notre approche de V&V se base sur l identification et la formalisation des relations inter-diagrammes d un modèle (Ali et al., 2004). Sans ces relations, les diagrammes UML forment une simple juxtaposition de spécifications partielles qui peuvent exprimer séparément des exigences contradictoires. Ces relations expriment les dépendances syntaxiques et sémantiques entre les diagrammes d un modèle UML. Elles permettent d entreprendre la vérification (Ali et al., 2004, Ali et al.,

2005a, Ali et al., 2005b) et la validation (comme nous illustrerons dans ce papier) d une manière modulaire (i.e., élémentaire). Dans le reste de l article, on se base sur les définitions suivantes (Legunnec, 2001) : La vérification est l ensemble des pratiques permettant d assurer que le logiciel, à la fin de chaque phase du cycle de développement, remplit les conditions requises pour passer à l étape suivante. Elle répond à la question : «Construisonsnous correctement le produit?». La validation regroupe des techniques permettant d évaluer le système développé vis-à-vis des besoins des utilisateurs. Elle répond à la question : «Construisons-nous le bon produit?». La figure 4 illustre notre approche globale de V&V formelles des modèles UML, composée de quatre principaux processus. Dans les sections suivantes, nous présentons le graphe de dépendances, la matrice de correspondance et le cadre formel adopté pour les diagrammes UML. Dans la section 4, nous détaillons le processus de validation des besoins des utilisateurs. Graphe de dépendances Modèles UML 2.0 Matrice de correspondances Formalisation Spécification des besoins utilisateurs Modèle formel Propriétés du système Vérification Validation Diagrammes vérifiés Diagrammes validés Figure 4. Vue schématique de notre approche de V&V formelles des modèles UML

3.1 Graphe de dépendances En tant que standard de l OMG, UML 2.0 comporte treize diagrammes qui spécifient et documentent graphiquement les trois aspects d un système, à savoir : les aspects statique, dynamique et fonctionnel. D autre part, le processus unifié UP, standardisé aussi par l OMG, complète UML avec une démarche permettant de gérer les activités de développement afin de transformer les besoins des utilisateurs en un système logiciel. Selon UP, un modèle UML est un ensemble de diagrammes représentant le système à un certain niveau d abstraction. Naturellement, plusieurs dépendances explicites et implicites existent entre les diagrammes d un modèle. <<Spec>> U c <<Spec>> S q <<Spec>> <<Real>> <<Real>> A c C l <<Equi >> <<Real>> <<Inst>> O b C o V e S m <<Spec>> <<Decomp>> <<Impl>> <<Dist>> D p T i P c C m S c Relations implicites Spécification Réalisation Equivalence Instance Distribution Implémentation Spec Real Equi Inst Dist Impl Décomposition Decomp Relations implicites possibles, dont le type est indéfinis. Diagrammes Cas d utilisation Communication Séquence Classes Activités Machines d états Objets Composants Déploiement Timing Structure Composite Vue d ensemble d Interaction Package U c C o S q C l A c E t O b C m D p T i S c V e P c Figure 5. Graphe de dépendances entre les diagrammmes UML 2.0

Les dépendances explicites sont définies par la syntaxe des diagrammes UML à travers le méta-modèle d UML. Les dépendances implicites représentent, d une part, la sémantique des digrammes et, d autre part, la démarche de dérivation du modèle. Le graphe dépendances définit donc les relations implicites liant deux diagrammes ; par exemple, le diagramme d activité est en relation avec le diagramme de classes à travers la relation de réalisation (Real). Cependant, des relations indirectes peuvent être dérivées par transitivité ; par exemple, comme le diagramme d activité est réalisé par le diagramme de classes et que ce dernier est spécifié par un diagramme d états, alors le diagramme d activité est indirectement lié au diagramme d états. La Figure 5 étend ce graphe pour tenir compte des nouveaux diagrammes de UML 2.0. 3.2 Matrice de correspondances La matrice de correspondances (MC) consiste à préparer, un tableau, pour chaque diagramme D, illustrant, en lignes, les éléments du diagramme D et en colonnes, les autres diagrammes d un modèle M. Les éléments (les concepts du diagramme D) sont ceux du méta-modèle d UML (OMG, 2005). Par exemple, les concepts du diagramme d activités sont partiellement illustrés par la figure 6. Figure 6. Une portion de méta-modèle UML2.0 décrivant le concept d activité. Chaque cellule de la matrice peut contenir une règle de correspondance. Cette règle assure la vérification d un élément du diagramme d activités par rapport aux autres éléments des diagrammes d un modèle UML. A titre indicatif, nous présentons informellement quelques règles de dépendances entre les éléments du diagramme d activité A c avec les éléments des autres diagrammes :

R1. Toute activité (activity) de A c correspond à une méthode dans le diagramme de classes. R2. Toute activité de A c correspond à un message dans un diagramme de séquence et/ou communication. R3. Toute activité de A c correspond à un cas d utilisation dans un diagramme de cas d utilisation. R4. Tout état (state) d un ObjectNode est un état d objet dans un diagramme de machines d états. R5. Tout objectnode correspond à un objet appartenant à un digramme de séquences et/ou de communication. R6. Tout élément (Traget) correspond à un objet dans un diagramme de séquences. R7. Tout élément (Source) correspond à un acteur dans un diagramme de séquences. Le tableau 1 illustre ces dépendances pour le cas du diagramme d activité en projetant ces éléments sur l ensemble des diagrammes UML. Ainsi, les cellules qui contiennent (R i ou ) désignent l obligation d exécuter une opération de vérification. Cette matrice sera la base du processus de validation ( section 4). Tableau 1 : Matrice de correspondances pour le diagramme d activités. 3.3 Cadre formel La formalisation des diagrammes d un modèle UML consiste à donner un cadre formel d appliquer des techniques de V&V formelles. Dans cet égard, nous avons formalisé tous les diagrammes UML 1.X en utilisons la théorie des ensembles et la logique du premier ordre. En particulier, dans (Ali et al., 2005a, Ali et al., 2005b) nous avons présenté la formalisation des diagrammes de cas d utilisation, de

séquence et de classes. Par exemple, le diagramme d acticités est défini comme suit : A c = <ActivityN, ActivityE, ObjectNode, ControlNode> où - ActN = {actn 1,,actN n} est un ensemble d activités (chaque activité est désignée par un nom). - ActE = {ActE 1,,ActE m} est un ensemble de transitions ou - Chaque ActE i à la structure suivante: acte =< exp, [guard], Source, target> où - Exp : l expression de transition, - Guard : la condition de garde, - Source et Target décrivent l objet émetteur et l objet récepteur. - ObjectN : est l ensemble d états possibles d un objet - ControlN : un ensemble de n uds de control où =<IN, FN, JN, FRN> où - IN : n ud initial, - FN : n ud Final, - JN : n ud de jonction, - FRN : n ud de disjonction. Cette formalisation a été étendue pour prendre en compte les diagrammes de UML 2.0. L utilisation de la logique de premier ordre ainsi que la théorie des ensembles facilite la tâche de traduction vers des langages orientés modèles comme object-z (Graeme, 2000). 4. Validation des besoins des utilisateurs Le processus de la validation des besoins utilisateurs (figure 7) consiste à valider les diagrammes exprimant ces besoins. Pour UML, les besoins des utilisateurs sont illustrés informellement avec les diagrammes de cas d utilisation. Nous présentons par la suite les étapes du processus de validation des besoins des utilisateurs par rapport à l ensemble de diagrammes d un modèle UML. Etape 1 : identification des propriétés Le point d entrée de la validation est l identification des propriétés liées aux besoins des utilisateurs. Nous nous basons sur la constatation suivante : l utilisateur exprime ses besoins avec les diagrammes de cas d utilisation. C est l expert informaticien qui «prend en charge» ces besoins afin de leur générer les diagrammes nécessaires. En fait, l intervention de l expert définit les propriétés que le système (autrement ses modèles) doit satisfaire. Nous admettons que ces propriétés sont représentées avec un diagramme d activité.

s'authent ifier [ OK ] client authent ifié [ code erroné ] panier non vide passer _com mande ou vrage disponible archiver( ) Diagrammes vérifiés Règles de correspondance Diagramme d activités Validation Instanciation de Matrice de Correspondances e1 e2 ej en Vérification élémentaire Matrices de Correspondances Non Diagrammes valides Figure 7. Vue schématique du processus de la validation formelle. Pour illustrer cette étape, considérons la propriété P pour notre exemple de la librairie en ligne et exprimée à l aide d un diagramme d activité A c1 de la figure 8. Informellement, P indique que «tout client authentifié, peut effectuer une commande comportant au moins un livre existant dans le catalogue et disponible dans le stock». Etape 2 : Instanciation de MC Cette étape consiste à projeter les instances des éléments du diagramme d activité représentant la propriété P. Le résultat de cette opération est d avoir une la matrice représentant les instances du diagramme d activité et leurs correspondances avec les éléments des autres diagrammes.

s'authentifier [ code erroné ] [ OK ] client authentifié panier non vide ouvrage disponible passer_commande archiver( ) Figure 8. Diagramme d activité A c1 Diagramme d activités A c1 Autres diagrammes Classe Instance Relation E U t c1 S q1 C l E t1 E t2 E t3 ActN1 S authentifier R3 R2 R1 ActN2 effectuer_commande R3 R2 R1 initialnode Final Node decisionnode Si(code correct) Alors Ok state= Client_non_authentifié Sinon[Code erroné] state= Client_authentifié ForkNode joinnode State 1 Client_non_authentifié R5 R5 R4 R4 R4 State 2 Client_authentifié R5 R5 R4 R4 R4 State 3 Panier_non_vide R5 R5 R4 R4 R4 State 4 Commande_effectuée R5 R5 R4 R4 R4 Expression F :ouvrir( ) 1 Guard-condition Source Client R6 Target client R7 Expression Archiver() 2 Guard-condition Commande validée Source Administrateur R6 Target commande R7 Tableau 2. Les éléments du diagramme d activités sont projetés sur la liste des diagrammes. Pour notre exemple, selon le graphe de dépendance, les diagrammes en relation avec le diagramme A c1 sont: le diagramme de classes «gestion de commande» (figure 1); le diagramme de séquence «alimenter panier» (figure 2) et le les diagrammes de machine d état d une «commande», d un «panier» et d un «livre»

(figure 3). Tout diagramme de cette liste doit satisfaire la propriété P. Une première matrice de correspondances pour P, illustré par le tableau 2, présente l instanciation des éléments de A c1. Le tableau 2 est le résultat d une opération de projection des instances de A c1 et d insertion des règles de correspondance ( 3.2) à appliquer. Etape 3 : Vérification élémentaire La vérification élémentaire se base sur le graphe de dépendances et la matrice de correspondances. En fait, elle consiste à vérifier une règle. Par exemple, l activité «s authentifier» nécessite un message m appartenant à l ensemble des messages M du diagramme de séquences. En appliquant la règle 2, nous remarquons qu il n y a pas un de message qui explicite cette activité. De même, l état «client_authentifié» doit avoir un objet o appartenant à l ensemble des objets du diagramme de séquences. En appliquant la règle 5, on vérifie l existence de l objet «client». Le tableau 3 illustre ces deux exemples de vérification élémentaire. Diagramme d activités A c1 Diagramme de séquences S a classe Elément instance Objet Message ExecutableNode Activity S authentifier R2 : (s authentifier) ControlNode initialnode Final Node decisionnode ForkNode joinnode ObjectNode state Client_authentifié R5 : (client) Tableau 1. Exemples de vérification élémentaire La validation formelle d un modèle UML revient à exécuter l ensemble de opérations de vérification élémentaire. Pour chaque cellule de MC, la validité de la règle doit être vérifiée en appliquant une ou plusieurs opérations de vérification élémentaire. 4.1 Vers une optimisation de la validation Il est clair que la projection des propriétés sur les diagrammes réduit la complexité de la vérification élémentaire. Cependant, cette projection peut causer un grand nombre d opérations de vérification dont certaines peuvent être déduites à travers les relations de dépendance inter-diagrammes. Une procédure d optimisation est appliquée sur la matrice du tableau 2 en exploitant les relations implicites interdiagrammes. En fait, si nous assurons la cohérence de la relation implicite «Spec» entre le diagramme S q1 et U c1, alors nous pouvons en déduire les opérations de vérification des éléments du diagramme d activités avec le diagramme de cas d utilisation.

Diagramme d activités A c1 Autres diagrammes Classe Instance Relation E U t c1 S q1 C l E t1 E t2 E t3 ActN 1 S authentifier R3 R2 R1 ActN 2 effectuer_commande R3 R2 R1 initialnode Final Node decisionnode Si(code correct) Alors Ok state= Client_non_authentifié Sinon[Code erroné] state= Client_authentifié ForkNode joinnode State1 Client_non_authentifié R5 R5 R4 R4 R4 State2 Client_authentifié R5 R5 R4 R4 R4 State3 Panier_non_vide R5 R5 R4 R4 R4 State4 Commande_effectuée R5 R5 R4 R4 R4 Expression ouvrir( ) 1 Guard-condition Source Client R6 Target client R7 Expression Archiver() 2 Guard-condition Commande validée Source Administrateur R6 Target commande R7 Tableau 3. Réduction des opérations de vérification élémentaire. Comme illustré par le tableau 3, cette procédure nous a permis de réduire le nombre des opérations de vérification élémentaire, pour passer de 53 à 33 opérations (soit 62% de vérification en moins). Actuellement, nous sommes en cours d énumérer les optimisations possibles par les relations de dépendance dans le cas de propriétés exprimées dans la logique du premier ordre. 5. Conclusion et perspectives La vérification et la validation des modèles UML sont des activités primordiales. En fait, elles permettent de passer la phase d implémentation en tenant compte des spécificités des besoins exprimés par les futurs utilisateurs et une réduction maximale des erreurs. En particulier, la validation permet de s assurer que les diagrammes générés, et par suite l implémentation correspondante, cadre bien les besoins de l utilisateur. Dans ce papier, nous avons présenté notre approche de vérification et de validation formelles des modèles UML. Les processus de cette approche sont illustrés dans une vue schématique fournissant une vue globale de ce travail de recherche. Nous avons détaillé le processus de validation des diagrammes UML en

illustrant la démarche avec le cas d une librairie en ligne. Actuellement, nous sommes entrain de traduire notre formalisation des diagrammes en object-z en vue de bénéficier du démonstrateur de théorèmes Z-eves (Saaltink, 1992). 6. Bibliographie Abrial J.R. The B-Book, Assigning Programs to Meanings. Cambridge University Press, 1996. Ali M. Vérification formelle des modèles UML. Mémoire de Mastère Informatique. Juillet- 2004, Faculté de Sciences Economiques et de Gestion de Sfax, Tunisie. Ali M., Ben-Abdallah H., Gargouri F., Verification of UML models through inter-diagram dependencies, in: Proceeding of Eighth Maghrebian Conference on Software Engineering and Artificial Intelligence, pages 349-360, 9-12 May 2004 Sousse, Tunisie. Ali M., Ben-Abdallah H., Gargouri F. Towards a Validation Approach of UP Conceptual Models", in: Proceeding of Consistency in Model Driven Engineering in European Conference on Model Driven Architecture - Foundations and Applications, pages 143-154, November, 7-10, 2005, Nuremberg, Germany. Ali M., Ben-Abdallah H., Gargouri F. Towards coherence verification of functional requirement descriptions, in: Proceeding of the international workshop Use case for Modelling Driven Architecture at ACM-IEEE UML/Models 2005, October 2-7, 2005, Jamaica. Evans A. and Kent S., Core Meta-Modeling Semantics of UML: The puml Approach, in: Proceeding of the second IEEE conference on UML: UML 99, LNCS, No 1723, pp. 140-155, 1999. Gihwan K. Rewrite rules and operational Semantics for model checking UML state charts, In Andy Evans, Struart Kent, and Branselic, editors, UML 2000- the Unified Modeling Language, Advancing the Standard. Third International Conference, York, UK, October 2000, Proceedings, Volume 1939 of LNCS, page 528-540. Springer, 2000. Graeme S. The Object-Z Specification Language. Advances in Formal Methods. Kluwer Academic Publishers, 2000. ISBN 0-7923-8684-1. 160 pages. Ivar J., Grady B., and Rumbaugh J., The Unified Software Development Process. Addison Wesley/ACM Pres, 1997. ISBN: 0201571692, 463 pages. Katoen J. P., "System validation", University of Twente, [on line] [juin 2003] URL: http://fmt.cs.utwente.nl/courses/systemvalidation/ Kim S-K., Carrington D., Formalizing the UML class diagram using Object-Z, in the Proceeding of the second IEEE conference on UML: UML'99, LNCS, No 1723, pp. 83-98, 1999. 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. Kruchten P., The rational Unified Process, an introduction. Addison-Wesley Object Technology Series. Addison Wesley, 2nd printing edition, 2000.

Latella D., Majzik I., and Massink M. Towards a Formal Operational Semantics of UML Statechart Diagrams, in: Proceeding pf third International Conference on Formal Methods for Open Object-Oriented Distributed Systems, P. Ciancarini and R. Gorrieri, editors, IFIP TC6/WG6.1, Kluwer Academic Publishers (1999). Ledand H., Traduction Systématique de Spécification UML en B. Thèse de doctorat, Université Nancy 2, novembre 2002. Leguennec A., Génie logiciel et méthodes formelles avec UML Spécification, Validation et Génération de Test. Thèse de Doctorat, Université Rennes, 1. 29 juin 2001. Mayer. E., Développements formels par Objets : utilisation conjointe de B et d UML. Thèse de doctorat, LORIA Université de Nancy 2, Nancy (F), mars 2001. Object Management Group, Model Driven Architecture official web-site. URL: http://www.omg.org/uml, 2005. Périn M. Spécifications graphiques multi-vues : Formalisation et Vérification de cohérence. Thèse de doctorat, Université de Rennes 1, 6 octobre 2000. Printz J., Génie Logiciel, Technique de l ingénieur, traité informatique, H3 208-32 p, 1997. Roques P., UML, modéliser un site E-Commerce, Edition Eyrolles, 2003 France. ISBN : 2-212-11070-7, 152 pages. Rambaugh J, Ivar J, Grady B., UML 2.0, Guide de référence. Campus Press. Févier 2004. France. ISBN : 2-7440-1820-1, 774 pages. S. Tyszberoicz B Litvak and A. Yehudai. Behavioral consistency validation of UML diagrams, in: Proceeding of the 1st IEEE International conference on Software Engineering and Formal methods (SEFM), pages 118-125. IEEE Computer Society Press, 2003. Saaltink M., Z and Eves Z User Workshop, Workshops in Computing, pages 223-242, Springer-Verlag, 1992, York, UK. Spivey. J. M. The Z Notation: A Reference Manual, Prentice Hall, 2nd edition, 1992.