Fusion de scénarios UML et Génération de code PDF

SETIT 2007 4th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 2007 – TUNISIA Fusion de scénarios...

SETIT 2007 4th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 25-29, 2007 – TUNISIA Fusion de scénarios UML et Génération de code Abdeslam JAKIMI, Mohammed EL KOUTBI, Ayoub SABRAOUI et Ali IDRI Université Mohammed V – Souissi, Ecole Nationale Supérieure d’Informatique et d’Analyse des Système. BP 713, Agdal, RABAT, MAROC. [email protected] Résumé: Cet article propose une nouvelle approche pour l’ingénierie des besoins basée sur la fusion et les transformations de modèles UML (Unified Modeling Language). Nous nous sommes intéressés, dans une première phase, à trois types de diagrammes d’UML : les diagrammes de classes (ClassD), les diagrammes de cas d’utilisation (UsecaseD) et les diagrammes séquence (SequenceD). Le processus qui supporte cette approche comporte globalement trois étapes : une première étape d’acquisition des besoins sous forme de diagrammes de classes, de cas d’utilisation et de séquences ; la deuxième étape propose un algorithme de fusion de plusieurs scénarios représentant un cas d’utilisation du système (service offert par le système) en un seul diagramme de séquence. La troisième étape de cette approche consiste à générer automatiquement du code pour les aspects dynamiques du système à partir du diagramme de séquence fusionné. Key words: Ingénierie des scénarios, Fusion de scénarios UML , Approches transformationnelles, Génération de code. diagrammes de cas d’utilisation et les diagrammes de séquence. INTRODUCTION Les approches transformationnelles sont de plus en Cet article est présenté selon quatre sections. Dans plus utilisées dans le génie logiciel. En effet, ces la section 1, le concept de scénario et de cas approches de développement exigent que les d’utilisation seront définis en utilisant le framework changements soient faits et documentés dans les notationnel UML. La section 2 décrit de façon spécifications des besoins à travers les modèles succinte l’approche que nous avons développée pour d’analyse et de conception et qu’ils soient propagés la fusion des scénarios et la génération de code. La par après vers l’environnement de déploiement (code section3 présente notre algorithme de fusion de source et exécutable). Ces nouvelles approches scénarios UML où nous avons distingué trois supposent un degré élevé de traçabilité qui ne peut être opérateurs de fusion : séquentiel, conditionnel et obtenu que par l’utilisation de techniques formelles concurrentiel. Dans la section 4, nous allons décrire (ou éventuellement semi-formelles) et d’algorithmes les aspects de génération de code à partir du scénario fiables de transformation de modèles. fusionné, représenté sous de diagramme de séquence. Nous terminerons cet article par une conclusion et les Différentes approches et différents outils, existant travaux futurs. actuellement sur le marché, permettent d’effectuer certaines transformations : de modèles à modèles ou de modèles vers du code. On peut les classifier selon 1. Scénarios et UML deux catégories : les approches boites noires et les Les scénarios connaissent un succès important approches boites blanches. Ces approches sont dans le génie logiciel, cela est dû à leur utilisation souvent complexes à utiliser et reposent sur dans toutes les phases du cycle de développement des l’utilisation d’un nouveau langage pour définir les systèmes informatiques depuis l’acquisition des transformations. besoins jusqu’aux activités de tests [Elk00]. Dans cet article, nous proposons une nouvelle Les scénarios trouvent leur place dans la plupart approche d’ingénierie des besoins basée sur la fusion des méthodes orientées objet (OMT, Fusion, OOSE, de scénarios et les transformations de modèles UML etc.) pour identifier les objets du système et (Unified Modeling Language). Nous nous sommes représenter les exigences fonctionnelles. Dans la particulièrement intéressés à trois types de méthode OOSE, les scénarios (cas d’utilisation) diagrammes d’UML : les diagrammes de classes, les dirigent toutes les étapes de la conception orientée -1- SETIT2007 objet. Ils sont utilisés comme point de départ pour la construction de tous les autres modèles de la méthode à savoir le modèle objet, le modèle d’analyse, le modèle de conception, le modèle d’implantation et le modèle de tests. La notation UML qui fait partie des standards de l’OMG (Object Managment Group), est le fruit des efforts d’unification de plusieurs méthodes orientées objet dans le but de bénéficier de tous les avantages de celles-ci. Dans sa première version, l’unification concernait uniquement les méthodes OMT et Booch. L’ajout de la méthode OOSE a permis à UML de Figure1 : Aspects des scénarios [Rol 98]. disposer d’une notation riche couvrant toutes les étapes de développement. 1.1.1. Forme des scénarios La forme des scénarios concerne essentiellement Les termes scénario et cas d’utilisation ont été les opérations d’acquisition, de spécification et de utilisés dans plusieurs travaux pour designer le même représentation. Les scénarios sont acquis en utilisant concept. Dans UML une distinction entre les deux différents médias, ils sont décrits et définis d’une termes est faite, et des définitions précises sont manière plus ou moins formelle, et ils sont reproduits données. Un cas d’utilisation (use case) est défini ou représentés selon diverses formes dans des buts de comme une suite d’interactions avec le système dans validation ou d’évaluation. le but de réaliser une transaction entière (tâche du système). Il est généralement décrit par plusieurs Lors de la description des scénarios, des langages scénarios. Ceci permet une acquisition structurée des de modélisation (semi-formels) ou des techniques de scénarios par cas d’utilisation. Un scénario est donc spécification formelles peuvent être utilisés. Ces une instance d’un cas d’utilisation, qui décrit une suite descriptions formelles ou semi-formelles sont très possible d’interactions dans la réalisation d’une tâche utiles pour la validation des besoins. Par exemple du système. dans [Jac92], les scénarios sont décrits en utilisant des diagrammes de séquence; dans UML les scenarios Les scénarios étant des descriptions partielles, peuvent être décrits par des diagrammes de l’obtention d’une description globale du collaboration ou de séquence; dans [Hsi94] les comportement du système nécessite une approche scénarios sont décrits par des grammaires régulières; permettant leur intégration ou fusion. Cette fusion dans [Kaw97, Lus97] les scénarios sont décrits par des peut être soit séquentielle soit concurrente automates; dans [Kos94, Gli95, Khr99] les scénarios dépendamment du contexte. sont formalisés à l’aide des Statecharts; dans [Dan97, La fusion séquentielle fournit un comportement Elk98, Lee98] les scénarios sont décrits en utilisant global où les scénarios peuvent être exécutés des formalismes dérivés des réseaux de Petri; etc. séquentiellement ou alternativement. Ce type de 1.1.2. Contenu des scénarios fusion a fait l’objet de plusieurs travaux de recherches Le contenu d’un scénario fait référence au type [Des 98, Hsi 94, Kos 94, Kaw 97, Som 97, Elk 00]. d’informations et de connaissances qui y sont La fusion concurrente fournit un comportement capturées. En effet, les scénarios peuvent adresser les global où le comportement de chacun des scénarios niveaux organisationnels ou stratégiques d’un système peut s’exécuter en concurrence ou en entrelacement (scenario in the wide) [Kyn95], comme ils peuvent avec les autres. Peu de travaux ont adressé ce type de concerner des descriptions détaillées de comportement composition [Dan 97, Gli 95, Elk 00]. (scenario in the narrow) [Jac96]. Selon Kuuti [Kuu95], le contenu d’un scénario peut décrire le 1.1. Aspect des scénarios : fonctionnement interne du système en main, les interactions entre le système et son environnement, et Les scénarios ont évolué dans le temps selon possiblement les aspects organisationnels du système. plusieurs aspects, et leur interprétation semble Selon la communauté du ‘requirements engineering’, dépendre du contexte d’utilisation et de la façon dont les scénarios peuvent décrire les aspects fonctionnels, ils étaient acquis ou générés. Dans un travail de non-fonctionnels et intentionnels d’un système récapitulation, Rolland [Rol 98] a proposé un cadre [Dar93]. L’aspect fonctionnel concerne la structure, le pour la classification des scénarios selon quatre comportement et les fonctions du système. L’aspect aspects : la forme, le contenu, le but et le cycle de non-fonctionnel correspond entre autres à des développement (Figure1). considérations organisationnelles ou de performance ou de gestion de risques. L’aspect intentionnel concerne les approches basées sur les buts (goal driven approach) et les responsabilités (responsability driven approach). Le contenu des scénarios dépend aussi de la manière dont les scénarios décrivent le système. On -2- SETIT2007 distingue entre les scénarios abstraits et les scénarios avec de nouvelles connaissances et fonctionnalités. concrets. Les scénarios abstraits font référence de L’opération de fusion tente de rassembler les vues manière abstraite à des objets du système (client, partielles décrites dans les scénarios pour obtenir une fournisseur, etc.), tandis que les scénarios concrets vue globale du système. Ceci peut être réalisé à l’aide utilisent des instances particulières d’objets d’algorithmes d’intégration [Hsi94, Kos94,Des98, (Université de Montréal, Prosys Inc., etc.). Som97, Elk98, Khr99] ou d’opérateurs de 1.1.3. But des scénarios composition [Gli95]. Les scénarios ont été utilisés entre autres pour la L'opération d’extension consiste à ajouter à un capture des besoins utilisateurs [Jac92, Pot94], pour la scénario existant de nouvelles connaissances pour description des interactions utilisateurs [Nar92, décrire des situations réelles ou souhaitées du système Car95], et pour l’investigation de nouvelles solutions [Kyn95]. dans les approches de réingénierie [Cam92]. Similairement aux approches de prototypage [Bis92], L’opération de suppression met fin à la vie d’un on peut donc dire que les scénarios sont utilisés pour scénario après son utilisation. des buts de description, d’explication ou d’exploration. Les scénarios de description sont 1.2. Les scénarios et la notation UML : surtout utilisés pour comprendre et décrire les aspects UML (Unified Modelling Language) est un comportementaux d’un système où les scénarios langage de modélisation objet. C’est le fruit des efforts représentent les points de vue des utilisateurs externes de l’unification de plusieurs méthodes orientés objet du système. Les scénarios d’exploration sont utilisés dans le but de simplifier et de bénéficier de tous les quand plusieurs solutions sont à explorer et à évaluer avantages de celles-ci [RJB 98]. Il a été conçu pour dans le but de sélectionner la meilleure. Ce type de servir de langage de modélisation, indépendamment scénario encourage la recherche de nouvelles du processus de développement adoptée [Pie 97]. alternatives et élargit le champ de solutions pour un UML définit neuf types de diagrammes, chacun d’eux problème donné. Les scénarios d’explication enfin représente une vision spécifique du système : servent à défendre une position, un choix ou un point de vue. Ils sont utilisés pour argumenter l’adéquation La vue fonctionnelle ou interactive, décrite à l’aide ou l’inadéquation d’une telle ou telle solution. Après des diagrammes de cas d’utilisation, des diagrammes utilisation des scénarios d’exploration, les scénarios des séquences et des diagrammes de collaborations. d’explication sont utilisés pour argumenter et détailler La vue structurelle ou statique, représentée à l’aide la solution retenue. des diagrammes de classe, des diagrammes d’objets, 1.1.4. Cycle de vie des scénarios des diagrammes de composants et des diagrammes de Si on considère les scénarios décrivant un système déploiement. comme étant des objets du système, on peut alors La vue dynamique, exprimée par les diagrammes parler de scénarios persistants par analogie aux objets d’états et les diagrammes d’activités. persistants. Les scénarios persistants accompagnent le projet depuis l’analyse des besoins jusqu’à la Dans ce qui suit, nous allons aborder les production de la documentation [Pot94, Jac92]. Par diagrammes de cas d’utilisation et les diagrammes de opposition, on définit les scénarios temporaires séquences qui ont un rapport à notre approche. comme ayant servi uniquement au niveau de certaines 1.2.1. Diagramme des cas d’utilisation étapes du cycle du développement. C’est le cas, par Le diagramme de cas d’utilisation est un apport exemple, où les scénarios ont été utilisés uniquement d’Ivar Jacobson à UML. Un cas d’utilisation décrit les pour l’acquisition des besoins, ou pour supporter la interactions entre les acteurs externes et le système production de diagrammes d’états des objets du (Fig.2). Il décrit une séquence d’actions réalisées par système [Rum91] ou bien pour la validation des le système dans le but d’offrir un service à besoins [Hsi94]. l’utilisateur. Qu’il s’agit de scénarios persistants ou temporaires, un scénario peut être l’objet des Authentifier opérations suivantes durant son cycle de vie : capture client (création), raffinement, fusion, extension et suppression. Déposer L’opération de capture concerne la création de Client nouveaux scénarios soit directement à travers les Retirer utilisateurs du système, soit à partir de scénarios existants (synthèse de scénarios). Fig.2 : Exemple d’un diagramme de cas L’opération de raffinement transforme un scénario d’utilisation. dans le but de le rendre plus lisible et plus réutilisable. On peut par exemple utiliser les relations uses et 1.2.2. Diagramme de séquences extends définies par Jacobson [Jac92, Rum99] pour Un scénario est une instance d’un cas d’utilisation, alléger le contenu d’un scénario ou pour l’étendre il décrit un ensemble d’interactions entre acteurs et -3- SETIT2007 objets du système. Acquisition Dans la spécification UML, les scénarios peuvent des besoins être représentés sous forme de diagrammes de collaboration et/ou de diagrammes de séquences. Ces CLASSD derniers, mettent en valeur l’ensemble des interactions USECASED de manière chronologique, l’évolution du temps se lisant de haut en bas. Chaque colonne correspond à un SEQUENCEDS objet ou éventuellement à un acteur, la ligne de vie de Fusion des l’objet représente la durée de son interaction avec les scénarios autres objets du diagramme (Fig.3). O O Ac m m Objet 1 Objet 2 SEQUENCED m Fusioné m m Acteur1 m1 Generation de m2 code m3 m4 UI ET JAVA m5 CODE Figure 5: Processus de fusion et génération de Fig.3 : Exemple d’un diagramme de séquences. code. Dans la première étape de ce processus, l’analyste 1.2.3. Diagramme de collaboration (développeur) procède à l’acquisition des besoins du Un diagramme de collaboration montre les système étudié sous forme de diagrammes UML à interactions entre les objets, en insistant plus savoir : le diagramme de classes, le diagramme des particulièrement sur la structure spatiale statique qui cas d’utilisation et les diagrammes de séquence pour permet la mise en collaboration d’un groupe d’objet, chaque cas d’utilisation. en plus, il fournit un second point de vue des aspects Dans la deuxième étape, un algorithme développé dynamiques. En effet un diagramme de collaboration en Java procède à la fusion (l’intégration) des correspond à une synthèse de l’ensemble des différents diagrammes de séquence correspondant à un diagrammes d’objets et des diagrammes de séquences. cas d’utilisation (service) du système afin de produire Il n’y a pas d’axe représentant le temps de façon un diagramme de séquence représentant le linéaire comme sur les diagrammes de séquence. Les comportement du cas d’utilisation. numéros sur les arcs permettent d’ordonner les Dans la troisième étape, un deuxième algorithme événements entre eux (Fig.4). Il est donc possible de génère du code (nous avons pris l’exemple de Java, suivre les échanges de messages entre les différents mais ça peut être n’importe quel autre langage) objets. représentant les aspects statiques et dynamiques du système. : Client : Système 1: Saisie 3. Fusion des scénarios UML 3: Accès autorisé Les scénarios étant des descriptions partielles, 4: Demande type l’obtention d’une description globale du opération comportement du système, suppose leur intégration ou 2: Vérification composition. La difficulté de la composition vient du : Guichet fait que les scénarios tout en étant décrits indépendamment les uns des autres, peuvent avoir des Fig.4 : Diagramme de collaboration. relations implicites. Ils peuvent par exemple se chevaucher : cas qui se produit surtout lorsqu’il s’agit de variantes du même scénario (scénarios nominal et 2. Processus de fusion et génération de d’exception par exemple) [Gli 95]. Ce problème de code recouvrement n’est pas traité dans notre approche. La figure 5 donne un aperçu du processus défini L’ordre d’exécution des scénarios peut être d’une qui supporte la fusion des scénarios UML ainsi que la des quatre manières (soient A et B deux scénarios) : B génération du code à partir du résultat de l’opération après A (séquentiel), A ou B (alternatif), A est suivi de de fusion. lui-même n fois (itératif), ou A et B en concurrence (simultanéité) [Gli95]. Ainsi, on peut définir quatre opérateurs pour la composition des scénarios : dans ce -4- SETIT2007 chapitre, nous allons décrire l’opérateur séquentiel qui définit une relation de précédence entre deux scénarios, puis l’opérateur conditionnel if_else qui représente deux comportements possibles, ensuite l’opérateur d’itération qui permet d’itérer des comportements et on terminera par l’opérateur de concurrence qui définit un comportement concurrent de deux scénarios. 3.1. L’opérateur séquentiel C’est un opérateur qui fait appel à la notion Fig.6 : (a) diagramme sd1, (b) diagramme sd2 d’ordre des interactions le long des lignes de vie (life et (c) diagramme fusionné sdie par if-else. line) d’un diagramme de séquence. Les interactions entre les objets (ou acteur et objets) des deux 3.3. L’opérateur de concurrence diagrammes de séquence sont ordonnées de telle Cet opérateur permet de définir un comportement manière que les interactions du premier SequenceD concurrent de deux scénarios, c’est une composition (sd1) arriveront avant celles du second SequenceD parallèle. Ce type de composition peut servir pour (sd2). Il s’agit de fusionner deux diagrammes de décrire des tâches indépendantes ou coopérantes et des séquences sd1 et sd2 dans le contexte à avoir au moins sous-systèmes séparés. un objet commun entre les deux diagrammes et à Deux cas se présentent : le premier, lorsqu’on a respecter l’ordre séquentiel d’envoi des messages. deux scénarios ayant des objets communs, le second Alors le principe de notre algorithme est décrit comme concerne deux scénarios ayant des objets différents. suit : Dans notre approche on s’intéressera au premier cas : 1. Parcourir la liste des messages du premier Principe : diagramme sd1. 2. Ajouter les messages de sd1 au diagramme Dans ce cas, on crée un diagramme de séquence fusionné sdf. comprenant les objets des deux premiers diagrammes 3. Compléter le diagramme de sdf par la liste des (à fusionner) sans redondance. Et le principe reste messages de sd2. analogue à celui de la composition séquentielle, bien sûr en marquant la concurrence sur les différents messages des deux diagrammes initiaux. La figure (Fig.8) est un exemple d’illustration de l’opérateur de concurrence : Fig.5 : (a) diagramme sd1, (b) diagramme sd2 et (c) diagramme fusionné sdf (sd1 ; sd2). 3.2. L’opérateur conditionnel if_else Fig.7 : (a) diagramme sd1, (b) diagramme sd2 et (c) Cet opérateur permet de définir un choix entre diagramme fusionné par concurrence. deux scénarios possibles à un instant donné. Dans ce cas, une condition notée [X] est attribuée au diagramme de séquence sd1 et une autre condition 3.4. Support outil notée [NonX] au diagramme sd2, l’opérateur agit en La première partie de ce travail consistait en regroupant les deux scénarios dans un diagramme l’étude de certains opérateurs pour la fusion des sdie, en gardant et mentionnant les mêmes messages scénarios UML. Pour implanter les algorithmes avec leurs conditions. La figure (Fig.6) montre la correspondants, nous avons recouru au standard XML, fusion de deux scénarios sd1 et sd2 : cela en manipulant des fichiers XML à l’aide de l’API JDOM. La figure 9 illustre le principe de l’application implémentée. -5- SETIT2007 un cas d’utilisation du système, nous commençons par identifier les opérateurs élémentaires d’interaction entre objets d’un diagramme de séquence. En effet, la syntaxe générale d’un message dans un diagramme de séquence est donnée sous la forme : *[CI] [CE] Name := Message (paramètres): Type retourné * : Représente l’itération ; [CI] : Condition d’itération; [CE] : Condition d’envoi de message ; Name : Nom de l’objet retourné. Une fois une interaction est identifiée, le code Java Fig.8 : Support outil pour la fusion de scénarios. correspondant sera généré selon le type de l’interaction. Nous avons opté pour Eclipse qui offre un environnement de développement intégré (Integrated 4.1. Cas d’une interaction séquentielle Development Environment). Eclipse est conçu pour être un outil modulaire. De nombreux modules (plug- L’exemple suivant illustre l’idée de l’algorithme de ins) sont fournis avec Eclipse mais il est aussi très génération de code pour le cas de messages facile d'en ajouter d'autres développés par la séquentiels entre objets du système. communauté ou des sociétés commerciales. Objet 1 Objet 2 Objet 3 Nous avons utilisé le plug-in ‘diagrammes UML’ qui permet de créer des diagrammes de classes, de m1 séquence, de collaboration, d'états, d'activités, de cas m2 d'utilisation, de déploiement et de composants. Nous avons testé notre algorithme sur le plug-in m3 ‘TogetherJ’. Cependant, notre algorithme de m4 composition peut être utilisé avec n’importe quel plug- m5 in de diagrammes UML. Le scénarios en entrée acquis via le plug-in de modélisation UML, sont transformés sous forme de Fig.9 : diagramme de séquence fusionné du fichiers XML puis ils seront fusionnés selon service1. l’opérateur indiqué par l’analyste afin de produire un Le code java généré relative au diagramme ci- fichier XML résultat de la fusion. Ce fichier pourra dessus est donné ci-après: éventuellement être visualisé sur le plug-in de modélisation et servira comme entrée à l’algorithme class mySystem { de génération de code. public void service1() { 4. Génération de code à partir d’un Objet2.m1(); diagramme de séquence UML Objet3.m2(); La génération de code à partir des modèles UML Objet2.m3(); se résume en la définition d’un ensemble de règles Objet1.m4(); pour réaliser un mapping entre les diagrammes UML Objet3.m5(); et les langages de programmation objet. Plusieurs } travaux ont surtout abordés la génération à partir des } modèles statiques (diagramme de classe par exemple). Certains travaux ont commencé à s’intéresser ces 4.2. Cas d’une interaction séquentielle dernières années au mapping UML vers le code en L’exemple ci-après illustre la génération de code à prenant en considération l’aspect dynamique des partie d’un diagramme de séquence fusionné systèmes. [Ali 00, Cho 00, Ifti 03, Ifti 05, Maj 99, Pin (service2) comportant une interaction de type if-else.. 03, Sam 00, Sam 02]. La plupart de ces travaux se concentrent sur la génération du code à partir du Objet 1 Objet 2 Objet 3 diagramme de Statechart correspondant à un objet du système. Notre approche complémente celles existantes par une génération de code non pas pour un [X] m1 seul objet mais pour un cas d’utilisation (service) [X] m2 faisant interagir plusieurs objets du système entre eux. [X].m3 Dans l’opération de génération de code à partir [nonX]m4 d’un diagramme de séquence fusionné et représentant [nonX] m5 -6- SETIT2007 Objet2.m3(); Fig.10 : diagramme de séquence fusionné du Objet1.m4(); service2. } Public void service3-B() Le code Java généré pour ce cas d’utilisation { (service2) est le suivant : Objet3.m2(); Objet3.m5(); } class mySystem { Public void service3 () public void service2() { { A.start(); if (X) { B.start(); Objet2.m1(); } Objet3.m2(); } Objet1.m3(); } else { 5. Conclusion Objet1.m4(); Dans ce travail, nous avons proposé une nouvelle Objet3.m5(); approche afin de réduire l'espace entre les modèles } d’analyse/conception et l’implémentation d’un système par la génération de code Java à partir de } modèles UML à la fois statiques et dynamiques. 4.3. Cas d’une interaction concurrentielle La première partie de ce travail (section 3) consistait en l’étude de certains opérateurs pour la L’exemple ci-après explique la génération de code fusion des scénarios UML. Selon la nature du à partie d’un diagramme de séquence fusionné système, cette fusion peut être soit séquentielle soit (service 3) comportant une interaction concurrentielle. concurrente. La deuxième partie (section 4) définit un ensemble de règles pour la génération de code à partir Objet 1 Objet 2 Objet 3 du digramme de séquence. Comme perspectives, nous allons étudier les possibilités de génération de code pour des A: 1.m1 plateformes utilisant les technologies suivantes : J2EE, B:1.m2 Web Services,.Net, etc. A: 2.m3 A:3.m4 6. References B:2.m5 [Ali 00] J. Ali, and J. Tanaka, “Converting Statecharts into Java Code”, in Proc. Fourth World Conf.on Integrated Design and Process Technology (IDPT’99), Fig.9 : diagramme de séquence fusionné du Dallas, Texas, USA, 2000. service3. [Boo 91] G. Booch. Object Oriented Design with class mySystem { Applications. Benjamin Cummings, 1991. Thread A = new Thread(); [Cho 00] K.O. Chow, W. Jia, V.C.P. Chan and J. Cao, Thread B = new Thread(); Modelbased generation of Java code, Proc. International Conf. on Parallel and Distributed public void run() Processing Techniques and Applications (PDPTA { 2000), Las Vegas, USA, 2000. If (this == A) service3-A(); [Elk 00] M. Elkoutbi, “User Interface Engineering If (this == B) service3-B(); based on Prototyping and Formal Methods” PhD } thesis, Université de Montréal”, Canada, March 2000. French title: Ingénierie des interfaces usagers à l'aide du prototypage et des méthodes formelles. public void service3-A() { [Gos 96] J. Gosling , H. McGilton. “The Java Objet2.m1(); language environment”: A white paper. Sun Microsystems,October 1996. -7- SETIT2007 [Ift 03] Iftikhar Azim Niaz , Jiro Tanaka; “Code Generation from UML StateCharts”, Mapping UML StateCharts, to Java code Institute of Information Sciences and Electronics, University of Tsukuba Tennoudai 1-1-1, Tsukuba, Ibaraki 305-8573 Japan [Ift 05] Iftikhar Azim Niaz, Automatic Code Generation From UML Class and Statechart Diagrams, dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Engineering Computer Science Doctoral Program in Engineering, University of Tsukuba, Japan. November 2005 [Jac 92] I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. Object-Oriented Softaware Engineering : A Use Case Driven Approach. Addison-Wesley, 1992. [Maj 99] MAJZIK, I. – JÁVORSZKY, J. – PATARICZA, A. – SELÉNYI, E., Concurrent Error Detection of Program Execution Based on Statechart Specification, Proc. 10th European Workshop on Dependable Computing, 1999. [OMG 03] Object Management OMG. Uinified modeling language specification version 2.0: Infrastructure. Technical Report ptc/03-09-15, OMG, 2003. [Pin 03] G.Pintèr. – Majzik, I.,” Automatic Code Generation based on Formally Analyzed UML Statechart Models”, In: Formal Methods for Railway Operation and Control Systems, Budapest, Hungary, May 15–16, 2003.and [Pin 03] G.Pintèr, “Code genration based on Statecharts”, Oct. 1, 2003, Budapest, Hungary, Vol. 47, No. 3–4, PP. 187–204 (2003) [Rol 98] C. Rolland, C. Ben Achour, C. Cauvet, J. Ralyté, A. Sutcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, K. Pohl, E. Dubois, P. Heymans "A Proposal for a Scenario Classification Framework" in Requirements Engineering Journal, Volume 3, Number 1, 1998. [Rum 91] J. Rumbaugh, M. Blaha, F. Eddy, P. W., and W. Lorensen. Object Oriented Modeling and Design. Prentice Hall Inc. Englewood Cliffs, New Jersy, USA, 1991. [Sun] Sun Microsystems Inc., Java Technology, http://java.sun.com [Sam 02] SAMEK, M., Practical Statecharts in C/C++, CMP Books, 2002. [Sam 00] SAMEK, M. – MONTGOMERY, P. Y., State Oriented Programming, Embedded Systems Programming, 2000. -8-