Institut Francophone International. Sujet : Études de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles

Transcription

1 Institut Francophone International MÉMOIRE DE FIN D ÉTUDES MASTER D INFORMATIQUE Option : Réseaux et Systèmes Communicants Année académique : Sujet : Études de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles Auteur : SIRISANG Jariya Étudiant de l Institut Francophone International (IFI) Encadrant : HO Tuong Vinh, Ph.D. L Institut Francophone International (IFI) 21 janvier 2015

2 REMERCIEMENTS Je voudrais tout d abord remercier Monsieur Victor Moraru qui m a conseillé ce stage pour la fin de mes études. Je tiens à remercier Monsieur HO Tuong Vinh qui m a proposé ce sujet intéressant et encadré pendant six mois de mon stage. Je le remercie de son contact chaleureux, ses conseils, ses soutiens et ses encouragements. Merci également toutes les réponses de mes amis qui m aident beaucoup de finir ce travail. Merci enfin à mes parents pour leur soutien et leur encouragement à tout l instant. i

3 RESUME Ce sujet du stage situe dans le domaine du génie logiciel. Il vise à étudier l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. Puisque la consommation des appareils mobiles augmente rapidement, les sociétés des applications mobiles ont envie de profiter cette situation. Mais il n est pas facile de développer une application qui peut fonctionner sur les plateformes différentes telque ios, Android, WindowsPhone, BlackBerry etc. Il est nécessaire de développer l application séparément pour chaque plateforme. En général, pour développer une application, on suit l étape d interroger des exigences, de faire l analyse, ensuite on conçoit la conception et commence à coder. Ce processus prend beaucoup de temps et de coûts. Et il aurait un grand problème lorsque le produit ne correspond pas aux exigences. Dans le cadre de ce stage, on propose une solution qui applique le principe de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. Celle-ci aiderait au développeur de réduire le temps et le coût de développement grâce aux avantages des modèles. L idée de l approche d ingénierie dirigée par les modèles est que le développement de l application est guidé par les modèles. Elle est très bien adaptée avec l approche Cross-platform afin de réaliser les applications mobiles pour des différences systèmes d exploitation. Cela réduit le temps et des ressources pour le développement. Le code est automatiquement généré à partir des modèles qui sont définis par le développeur. Mot-clé : Ingénierie dirigée par les modèles, Application mobile, Multi-plateforme, DSL, Modélisation. ii

4 ABSTRACT This subject of the internship is in the field of software engineering. It aims to study the mobile application development approach particularly in the engineering model driven approach. Since the consumption of mobile devices augumente quickly, the manufacturer of mobiles applications would like to take benefit of this situation. But it is not easy to develop an application that could execute on different platforms such as IOS, Android, WindowsPhone, Blackberry etc. It is necessary to develop separately for each platform. In general, to develop an application, we follow the step of getting the requirements, analyze the requirements and then designing and coding. This process takes many time and costs. And it would be a big problem when the product does not correspond to user requirements. We propose a solution that applies Model driven engineering approach for the development of mobiles applications, which will help to reduce the development s time and costs through the advantages of models. The idea for the approach of model driven engineering that is the application development is guided by the models. It is very well suited to the Cross-platform approach to realize the mobile application for the differences in operating systems. It reduces development s time and resources. The source code is automatically generated from the models that are defined by the developer. The generated application is truly native and causes less of the problems of non-response requiments. Keyword : Model Driven Engineering, Mobile Application, Cross- platform, DSL, Modelling. iii

5 Table des matières REMERCIEMENTS i RESUME ii ABSTRACT iii Contents List of Figures List of Tables iv v vi 1 Introduction Problématique Motivation et objectif Plan du document Recherche bibliographique Quelques Frameworks pour le développement des applications mobiles Adobe AIR jquery Mobile Framwork PhoneGap MD IDM :Ingénierie Dirigée par les Modèles pour le développement des logiciels La définition de l IDM L idée et l objectif de l IDM Les approches de l IDM Modèle-Integrated Computing (MIC) Les usines logicielles (Software Factories) L approche MDA : Model-Driven Architecture La transformation de modèle Les outils de l IDM Kermeta MetaEdit EMF (Eclipse-EMF-website) Intérêt de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles iv

6 Contents v 3 Solution proposée Méthodologie et technique de l approche MDA Méthodologie de l approche MDA Techniques disponibles de l approche MDA Solution proposée Méta-modélisation Conception de la méta-modélisation Générateur de code Conception pour le développement du générateur de code Plateforme cible (Android) Implémentation et Expérimentation Implémentation de la solution Implémentation de langage dédié : DSL Application Model View Control Implémentation de générateur de code Le module generatemanifest Le module generateview Le module generateresource Le module generateactivity Application de la méthode proposée Processus de développement Application 1 : Une application simple Description de l application Résultat Conclusion Application 2 : Une application de jeu Sudoku Description de l application Résultat Conclusion Evaluation Conclusion et perspective Conclusion Perspective A Modèle PIM de l application simple avec DSL 44 B Modèle PIM de l application de jeu Sudoku avec DSL 45 Bibliographie 47

7 Table des figures 2.1 L Adobe AIR Le jquery Mobile Framwork Le PhoneGap L architecture de MDA Le principe de processus de MDA L hiérarchie de modèles de MDA Le plan du flux de MDA La vue l ensemble de solution L étape de réalisation de PIM L étape de réalisation de générateur Les répertoires et fichiers nécessaires de l application Android Le concept de DSL L architecture de l Acceleo Le concept de la transformation pour la plateforme Android La configuration de l exécution d Acceleo La location du code généré vi

8 Liste des tableaux 4.1 La comparaison d interface de Main La comparaison d interface de Second La comparaison d interface de Main La comparaison d interface de Help La comparaison d interface de level La comparaison d interface de Game vii

9 Chapitre 1 Introduction Le premier chapitre concerne la présentation de la problématique du sujet Étude de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. On présente la motivation et l objectif du travail. 1.1 Problématique Actuellement, la tendance de l utilisation des appareils mobiles (par exemple. Smartphone, Tablet, Phablet etc.) augmente rapidement. Grâce à cela, le marché des applications mobiles est de plus en plus élargi. Chaque jour, les sociétés lancent des nouvelles applications pour répondre à l augmentation de consommation des appareils mobiles et aux besoins des utilisateurs. Cependant, des applications mobiles sont souvent fournis pour plusieurs systèmes d exploitation (Android, ios, WindowsPhone). Il est essentiel de développer séparément pour chaque plateforme en raison de détails différents dans la programmation des interfaces, des bibliothèques, et des langages de programmation. Dans l industrie de développement du logiciel, on trouve un grand besoin du développement. C est un effort de réaliser un logiciel complexe avec la courte durée et moins de budget. Cette situation existe aussi dans le développement des applications pour les appareils mobiles. Puisque l utilisation des appareils mobiles est de plus en plus populaire, la compétition entre des sociétés d application mobile est plus forte. Sûrement, la société qui peut recevoir le plus de bénéfits est celle qui peut produire plus rapidement et dépenser moins de ressource du développement des applications pour la sortie des nouveaux appareils mobiles et pour les différences plateformes. 1

10 Chapter 1. Introduction 2 Les applications sont séparément fournis pour les différents plateformes, néanmoins les fonctionnalités pour chaque plates-formes sont de mêmes. Donc il existe la répétition de code. Si l on peut éviter la répétition dans le développement, on peut aussi diminuer le temps et le budget. Les chercheurs tentaient d étudier des approches qui peuvent résoudre des problématiques sur : L évitement de répétition de code avec une structure généralisée pour la réduction du temps de développement. La probabilité de baisser d erreur ou faciliter de la correction. Le changement dans le code. Il est moins compliqué de modifier si des fonctionnalités sont changées. La capacité de rédiger des fonctionnalités pour les différents langages, en les appelants une fois et de réduire le temps de développement. Par exemple, la définition d une entité en Java, Objectif c,c# peut être faite par écrivant une seule fois dans la langue spécifique à un domaine et de générer les différentes versions. Généralement, la méthode de développement d un logiciel commence par l étape de réunir des requêtes et puis on analyse ces requêtes afin d avoir la conception du produit. En suite, la conception est prise à l implémentation du logiciel. Pareillement pour celle de l application mobile, à l étape d implémentation, les développeurs devraient réaliser l implémentation qui supporte les différences plates-formes pour la raison mentionné ci-dessus. En plus, cette méthode pourrait aussi agrandir l intervalle entre des requêtes et l implémentation si la conception n est pas bien conçue. Cela provoque un grand problème d économique. 1.2 Motivation et objectif L approche d ingénierie dirigée par les modèles est une nouvelle approche intéressante pour le développement des applications mobiles. Revoir sur la méthode de développement originale, on mettra à la place de la conception par les modèles de l application. Cela peut simplifier le développement et réduire l intervalle entre des requêtes et l implémentation. Le modèle représente clairement l idée de l application grâce à l aide des outils pour modéliser un modèle comme UML (Unified Modeling Language) et s il y a des erreurs, il est facile et rapide de corriger en revoyant et modifiant des modèles. L idée de l approche d ingénierie dirigée par les modèles est que le développement de l application est guidé par les modèles. Elle est très bien adaptée avec l approche

11 Chapter 1. Introduction 3 Cross-platform afin de réaliser l application mobile pour des différentes systèmes d exploitation, cela réduit le temps et des ressources de développement. Le code est automatiquement généré à partir des modèles qui sont définis par le développeur. Le code de l application générée est de même avec le code réalisé manuellement et amène moins de problème d insatisfaction des requêtes. Ce stage a l objectif d étudier l approche d ingénierie dirigée et découvrir ses avantages pour le développement des applications mobiles. Pour ce stage, je dois avoir la compréhension sur cet approche en étudiant des travaux qui ont été fait et faire la comparaison, donner des point fort et des points faibles de l approche. 1.3 Plan du document Ce rapport se compose 5 chapitres qui sont le produit de l étude de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. Dans le premier chapitre, on a présenté la problématique, la motivation et l objectif de ce sujet du stage. On va présenter dans le deuxième chapitre sur la recherche de bibliographies qui concernent notre travail, et les travaux qui ont déjà existants. D ailleurs on représente aussi les descriptions de l approche d ingénierie dirigée par les modèles. Dans le troisième chapitre, on propose une solution pour l implémentation de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. Le chapitre suivant est l implémentation de la solution proposé et l expérimentation. En fin, le cinquième chapitre, on donne l analyse sur le travail, la conclusion et les perspectives.

12 Chapitre 2 Recherche bibliographique Ce chapitre est une présentation de la recherche de bibliographie sur les travaux existants pour faciliter le développement des applications mobiles et sur l approche d ingénierie dirigée par les Modèles(IDM) pour le développement des logiciels. Commençant par la discussion sur les techniques qui nous permettent de développer plus rapide et facilement une application mobile. En suite, on va présenter l approche d ingénierie dirigée par les Modèles(IDM) qui est un autre choix pour le développement des logiciels et à la fin, on vous parle des outils de cette approche. 2.1 Quelques Frameworks pour le développement des applications mobiles Comme on a parlé dans le chapitre précédant de problématique dans le développement des applications mobiles, les chercheurs font des efforts afin de trouver la solution pour faciliter le développement des applications mobiles. Et l approche de multiple plateforme (Cross-platform) [21, 22] est considérée comme l approche qui est la plus populaire pour l instant. On présente des exemples de quelques travaux qui aident aux développeurs de développer des applications mobiles Adobe AIR À partir de 2011, il était clair qu Adobe AIR[11] a été choisi comme la plateforme au deuxième rang dans le développement des applications pour les appareils mobile d Android de Google et la première plateforme pour obtenir un soutien officiel afin de développer des applications pour le Blackberry Playbook. 4

13 Chapter 2. Recherche bibliographique 5 Au début Adobe AIR est inventé pour l objectif de faire Runtime sur l environnement de Microsoft Windows et d Apple OS X, car cela permet aux développeurs de créer des applications avec la technologie Adobe qui peut être mis au travail sur les systèmes d exploitation précités sans modifier l application. Le moment où Adobe AIR est populaire dans la section du développement de l application de web, les produits chez Apple comme iphone et ipad lance la nouvelle technologie du contrôle des appareils indépendant de la sourire et le clavier. C est la raison pour laquelle chez Adobe trouve la popularité de cette nouvelle technologie et améliore l Adobe AIR afin de soutenir la nouvelle technologie d écran tactile pour les appareils mobiles. Adobe AIR devient le premier choix qui est développé pour fonctionner sur cette nouvelle technologie et consiste à travailler en étroite collaboration des appareils mobiles et les tablettes de Google Android et RIM. Adobe AIR sur des appareils mobiles est adapté à consommer moins de ressources par rapport à celui sur un PC. Ceci permet aux développeurs d ignorer le problème du manque de ressource. Grâce au concept de ne pas dépendre trop de langage de programmation, Adobe AIR peut développer dans deux façons. C est la façon de l utilisation d Actionscript 3 et Adobe Flex framework, une autre façon est de l utilisation HTML, CSS et Javascript. Toutefois tous les façons sont implémentés par des outils d Adobe par exemple Adobe Flash Professionnel CS 5, Adobe Flash Builder 4.5 et Adobe Dreamweaver CS 5. Pour développeurs, il faut avoir connaissance sur le langage de programmation orienté objet (OOP). Cependant Adobe AIR est développé pour la technologie de web, il a besoin de l Internet afin d accéder à l application comme le site web général. Figure 2.1: L Adobe AIR

14 Chapter 2. Recherche bibliographique jquery Mobile Framwork jquery Mobile [15] nous permet de créer un site web mobile plus facilement. Avec laquelle nous ne devons pas perdre le temps à la conception de l interface de l utilisateur (UI). Cela nous permet aussi de construire une application mobile qui peut être adapté avec PhoneGap pour pouvoir soumis à l App Store d Apple ou Android ainsi. Les avantages de jquery Mobile : Une fois de la réalisation, il est possible de fonctionner sur tous les plateforme des appareils tels que ios, Android, BlackBerry, Windows Phone etc. La collaboration avec le Framework PhoneGap, nous permet de réaliser facilement une application. Il n a pas besoin d apprendre le langage du système tels que la plateforme ios d apprendre Objective-C langue et d apprendre Java pour la plateforme Android. Il peut être utilisé avec le langage de programmation PHP et la base de données MySQL, il n y a pas de différence de la programmation sur PHP et MySQL en général. Il y a beaucoup de beaux thèmes à choisir. Nous ne devons pas perdre de temps à écrire CSS ou Javascript pour les interfaces, il permet aux développeurs de travailler plus rapidement. Les points faibles de jquery Mobile : Le développement des sites web et des applications sur des appareils mobiles en utilisant jquery Mobile, il faut admettre que certaines capacités puisse commencer à utiliser un langage spécifique (langue maternelle) sont développés. Comme l interface matérielle de smartphones, mais certains App Mobile qui n a pas besoin de trucs, rien de plus. Il fonctionne comme un site Web et d afficher une excellente sur les smartphones, il est interdit d utiliser le jquery Mobile est un excellent choix pour l application des applications de développeur. Figure 2.2: Le jquery Mobile Framwork PhoneGap PhoneGap [10] est un Framework basé sur le principe de Cross-Platform. L idée de PhoneGap est d envelopper le code qui est créé par HTML, CSS, JavaScript dans une

15 Chapter 2. Recherche bibliographique 7 application par le Wrapper afin d obtenir des applications pour chaque plateforme. Cependant PhoneGap n est pas approprié avec l application de grandes fonctionnalités car il ne supporte pas certaines fonctions. L application générée par PhoneGap n est pas l application du langage original de plateforme cible. Figure 2.3: Le PhoneGap MD2 Le Framework MD2 [4] implémente l idée de la transformation automatique pour générer le code source à partir du développement des modèles. Ce fait permet aux plusieurs transformation de générer le code pour les différents cibles plateforme. L intérêt de cette approche n est que le Cross-Platform mais c est aussi le cycle du développement rapide grâce à la propriété de réutilisable et de traçabilité. Le développement des applications par MD2 est divisé en 3 phrases : Tout d abord, le développeur décrit l application par un modèle de textuelle. Deuxièmement, un générateur de code pour chacune des plateformes supportées transforme le modèle vers le code source de la plateforme respective avec des éléments structurels nécessaires tels que les fichiers de projet. Pour le moment, les générateurs de code pour Android et ios sont disponibles. A la troisième phase, le développeur doit compiler le code source généré. Le langage de MD2 est décrit sous le cadre de modèle Model-View-Controller (MVC)[16]. Le modèle d une application est séparé en partie de modèle, de vue, et de contrôleur. Dans les applications générées, le contrôleur est basé sur un système d événements, qui gère toutes les actions de l utilisateur ainsi que des événements internes ou périphériques. Les développeurs spécifient les actions dans le modèle, avant d être prises si un événement se produit. 2.2 IDM :Ingénierie Dirigée par les Modèles pour le développement des logiciels Dans le processus général pour développement de logiciel, il est difficile lorsqu on a besoin d ajouter des fonctions ou de corriger des erreurs. Cela peut aussi provoquer le

16 Chapter 2. Recherche bibliographique 8 problème de budget. Les chercheurs donc étudient des approches pour diminuer l écart entre les exigences et le produit final. Et l Ingénierie Dirigée par les Modèles est une approche qui peut résoudre ce problème. On va représenter les détails de cette approche à la suit La définition de l IDM L Ingénierie Dirigée par les Modèles(IDM) [1, 12] utilisée sous le terme anglais de MDE (Model Driven Engineering) est une discipline du génie logiciel par laquelle tout ou partie d une application informatique est engendrée à partit de modèles. Il est nécessaire de fournir des outils flexibles et fiables pour la gestion automatique des modèles ainsi que des langages dédiés pour leurs transformations, pour vocation l automatisation du développement de logiciel en fournissant des outils et des langages de la transformation L idée et l objectif de l IDM Un modèle est défini comme une abstraction d un système. Il est essentiel qu un modèle peut être utilisé pour répondre à des questions sur le système modélisé. On peut dire qu un modèle est une forme simple pour représenter l idée d un système. Il permet aux intervenants de comprendre facilement et correctement le concept de système. Cela aide aux développeurs de réaliser le système satisfait aux besoins exacts de l utilisateur. L ingénierie Dirigée par les Modèles (IDM) relève ces avantages de modèle pour le développement de logiciel. L IDM fournit des modèles afin d exprimer séparément des préoccupations des utilisateurs, des concepteurs, etc. L idée est d interpréter des exigences d utilisateur en forme des modèles, et puis considérer ces modèles comme la première source du processus de développement. En suite, les modèles seraient transformés par la machine, c est l idée de transformations de modèles. L objectif finale est de rendre opérationnels les modèles pour génération de code exécutable. Pour formaliser et transformer des modèles, l IDM fournit des outils et des langages pour réaliser la transformation et formaliser des modèles. On les appelle les langages de modélisation et les langages de transformation dont on parlera plus tard.

17 Chapter 2. Recherche bibliographique Les approches de l IDM Nous avons présenté dans la partie précédant le concept et l idée de l IDM. Pour mieux comprendre son principe, on représentera les principales approches de développement logiciel basées sur l IDM Modèle-Integrated Computing (MIC) Cette approche est proposée au milieu des années 90. Au début le MIC est conçu pour le développement des systèmes embarqués complexes. L idée de l approche MIC est comme le principe de l IDM, c est que considérer des modèles comme le centre de processus de développement d application. Le MIC fournit une technologie pour la spécification et l utilisation de DSMLs, des outils de méta-programmation, des techniques de vérification et de transformation de modèles. L architecture de MIC est conçue en 3 niveaux suivants : Le niveau Meta fournit des langages de méta-modélisation, des méta-modèles, des environnements de méta-modélisation et des méta-générateurs pour créer des outils spécifiques à un domaine, qui seront utilisés dans le niveau MIPS (Model-Integrated Program Synthesis). Le niveau (MIPS) est constitué de langages de modélisation spécifiques à un domaine, et de chaînes d outils pour la construction et l analyse de modèles, la synthèse d applications. Le niveau Application représente les applications logicielles adaptables. Dans ce niveau, les programmes exécutables sont spécifiés en termes de composition de plateformes (CORBA, etc.) Les usines logicielles (Software Factories) L idée des usines logicielles est d adapter ces caractéristiques au développement de logiciels. Les deux premiers points correspondent à la spécialisation des éditeurs de logiciels et des développeurs à l intérieur des équipes de développement. Le troisième point correspond à l utilisation d outils de génie logiciel spécifiques au domaine d application, c est-à-dire de langages, d assistants et de transformateurs spécifiques. Le dernier point correspond à la réutilisation de composants logiciels sur étagères. L environnement de développement Visual Studio.Net 2005 a été conçu autour de ces idées et propose un environnement générique extensible pouvant initialement être configuré pour un ensemble de domaines d applications prédéfinis.

18 Chapter 2. Recherche bibliographique L approche MDA : Model-Driven Architecture L approche MDA : Model-Driven Architecture est proposée par l OMG : Object Management Group en L idée de base du MDA est la séparation des spécifications fonctionnelles d un système des détails de son implémentation sur une plateforme donnée. Cela veut dire que des modèles sont spécifiés indépendant de plateforme, on appelle Platform Independent Model( PIM). Les modèles de PIM sont utilisés pour exprimer les fonctionnalités du système avant de définir la plateforme utilisée. Et un autre type de modèle est Platform Specific Model (PSM). Ce type de modèle est différent par rapport au PIM. Le PSM est les modèles spécifiés la plateforme utilisée. L approche MDA permet de déployer un même modèle de type PIM sur plusieurs plateformes grâce au principe de la transformation vers PSM. L architecture de MDA est standardisée en 4 niveaux : M0 Le monde réel ou CIM est un niveau des fonctionnalités du système ou des exigences des utilisateurs. M1 Le modèle est des exigences qui sont formalisés et modélisés, dans ce cas c est le modèle PIM et PSM qui représentent le système. M2 Le méta-modèle est un modèle de modèles. C est un langage utilisé pour décrire des modèles. Par exemple UML, XML. M3 Le méta-métamodèle permet de décrire un modèle de méta-modèles. Selon l OMG, le MOF est un exemple de description de méta-modèles. Figure 2.4: L architecture de MDA Ref.[1] Les transformations entre le CIM, le PIM et les PSM sont souvent automatisés à l aide d outils. Ces transformations sont réalisées avec des outils plus ou moins compatibles avec le standard de l OMG nommé QVT.

19 Chapter 2. Recherche bibliographique La transformation de modèle La communauté IDM (Bézivin, 2004)[3] consiste à dire qu une transformation de modèles est la génération d un ou de plusieurs modèles cibles à partir d un ou de plusieurs modèles sources. L un des objectifs d l IDM est que l IDM consiste à pouvoir rendre opérationnels les modèles à l aide de transformations. Donc la transformation est le cœur de l IDM. Cette notion est bien représentée dans l approche de MDA. L approche MDA demande de créer d abord un modèle indépendant de toute plateforme (PIM), en suite PIM est raffiné en un ou plusieurs modèles spécifique à une plateforme (PSM). La transformation joue le rôle de l intermédiaire, définit des règles de transformation entre PIM et PSM. Une transformation des entités du modèle source met en jeu deux étapes. La première étape permet d identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs méta-modèles, ce qui induit l existence d une fonction de transformation applicable à toutes les instances du méta-modèle source. La seconde étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d exécution Les outils de l IDM Dans cette partie est la présentation des outils qui permet de méta-modélisation dans lesquels la transformation de modèles revient à l exécution d un méta-programme. Il existe maintenant de nombreux des outils de méta-modélisation. Ces qui sont présentés suivants, sont quelques exemples souvent utilisés Kermeta Kermeta [3] est un atelier de méta-modélisation développé par l équipe Triskell de l IRISA. Kermeta est utilisable sous forme d un plugin Eclipse. Une description en KERMETA est assimilable à un programme issu de la fusion d un ensemble de métadonnées (EMOF) et du méta-modèle d action AS (Action Semantics) qui est maintenant intégré dans UML 2.0 Superstructure. Le langage KERMETA est donc une sorte de dénominateur commun des langages qui coexistent actuellement dans le paysage de l IDM. Kermeta peut être vu comme étant composé d un méta-méta-modèle (une extension d EMOF) auquel est associé un langage permettant de définir des actions sur les méta-modèles. Ces actions peuvent servir par exemple à vérifier la cohérence d un

20 Chapter 2. Recherche bibliographique 12 modèle (avec des validations de contraintes à l OCL) ou bien encore à réaliser des transformations de modèles. La définition d un méta-modèle en Kermeta peut se faire de 3 manières : Via un éditeur graphique de modèle à l UML Via un éditeur sous forme d arbre en associant des instances du méta-élément de Kermeta (représentation XMI) En écrivant un programme Kermeta correspondant à la définition du métamodèle MetaEdit+ MetaEdit+ [3, 6] permet de définir explicitement un métamodèle et au même niveau de programmer tous les outils nécessaires, allant des éditeurs graphiques aux générateurs de code, en passant par des transformations de modèles EMF (Eclipse-EMF-website) EMF (Eclipse Modeling Framework) a été développé pour simplifier le chargement, la manipulation et le stockage des modèles dans l environnement Eclipse. EMF repose dans la famille d Eclipse Modeling Framework. Elle est une plateforme de modélisation et de génération de code qui facilite la construction d outils et d autres applications basées sur des modèles structurés. EMF n est pas spécifique à un méta-modèle, donc il peut gérer tous les types de modèles. Il est basé sur une norme de description de métamodèle nommé Ecore. Cette norme est un sous-ensemble de la norme MOF (MOF Essentiel), qui à son tour est un sous-ensemble de MOF2.EMF est composé des plug-ins qui sont : Le méta-modèle Ecore qui est un canevas de classes pour décrire les modèles EMF et manipuler les référentiels de modèles. EMF.Edit qui est un canevas de classes pour le développement d éditeurs de modèles EMF. Le modèle de génération GenModel qui permet de personnaliser la génération Java. JavaEmitterTemplate qui est un moteur de template générique. JavaMerge qui est un outil de fusion de code Java.

21 Chapter 2. Recherche bibliographique Intérêt de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles Lorsque le marché des applications mobiles est de plus en plus élargi, les sociétés productrices des applications mobiles osent de trouver des façons d améliorer le processus de développement d applications mobiles. Ce travail a le but d obtenir une application mobile avec la bonne qualité dans le temps de développement plus court possible et pour faire face à l expansion du marché et l augmentation de la consommation des utilisateurs. L un des principaux problèmes qui entraîne des retards dans le développement d applications est des plateformes différentes des appareils mobiles. L application peut prendre en charge plusieurs plateformes auront une meilleure commercialisation. Cependant, en raison du développement d une application mobile pour les différentes plateformes doit avoir besoin de conception individuelle pour accueillir une bibliothèque différente de chaque plateforme. Pour cela, le développeur consacre beaucoup de temps à développer une application. Les chercheurs donc font la recherche pour améliorer le processus de développement des applications mobiles. On essaie de réaliser une application juste une fois de développement pourtant elle marche sur plusieurs plateforme. On appelle cette approche que Cross-platform. Pour l instance, plusieurs outils de ce type de développement sont inventés pour développer des applications mobiles marchées des grandes plateformes comme Apple ios, Google Android, Windows Phone et RIM BlackBerry. Néanmoins, les approches de cross-platform, elles sont toujours confrontées à des limites fondamentales de fonctionnement dans un environnement Web. Presque tous sont implémenté sur les langages de web application, pas exactement semblable à une application native et ces approches ont été trouvés à manquer de fonctionnalités et d avoir des problèmes de performance. Donc l idée d étudier l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles est un choix intéressant. Puisque le développement par les modèles favorite de la traçabilité et réutilisable de code source, dans le cas où le développement d une application qui a des mêmes fonctionnalités réalisé, il est facile de reprendre le modèle afin de générer le code. De plus, comme le problème principal de développement des applications mobiles est les différentes plateformes que l application doit capable de les supporter. L approche d ingénierie dirigée par les modèles permet de générer facilement le code pour chaque plateforme. Et dans le cas où il existe des erreurs

22 Chapter 2. Recherche bibliographique 14 dans l application, les développeurs peuvent aisément détecter et corriger en examinant des modèles. Une autre caractéristique du modèle est que la présentation des fonctions du système est claire et facile à comprendre. Il peut réduire l écart et la distorsion entre le produit final et les exigences du client. Les avantages mentionnés ci-dessus aideraient à résoudre le problème de temps utilisé et l économique dans le développement des applications mobiles aussi bien. Dans ce chapitre, on a introduit la vue d ensemble de l approche d ingénierie dirigée par les modèles et les travaux qui sont existants pour l amélioration du développement des applications mobiles. Le travail suivant est de trouver des idées, des outils appropriés pour planifier postérieurement la solution d implémenter l approche de d ingénierie dirigée par les modèles pour le développement des applications mobiles. Cela sera présenté dans le chapitre suivant.

23 Chapitre 3 Solution proposée Dans cette partie du rapport représente la solution proposée pour l implémentation de l approche d ingénierie dirigée par les modèles à partir de l étude théorique. On présente des techniques et des outils utilisés. 3.1 Méthodologie et technique de l approche MDA Parmi les approches de l ingénierie dirigée par les modèles, l approche MDA est la plus appropriée de appliquer le générateur pour l application mobile parce que l idée de base du MDA est la séparation des spécifications fonctionnelles d un système des détails de son implémentation sur une plateforme donnée. Comme on va adopter l approche MDA pour la solution, donc on va présenter en détail de cette approche Méthodologie de l approche MDA Le MDA a mis en évidence l intérêt de séparer les spécifications fonctionnelles d une application de son implémentation sur une plateforme donnée. Pour profiter les avantages commerciaux de cette approche et répondre aux problématiques du développement des applications mobiles, le PIM doit survivre le changement de plateforme et être réutilisable pour plusieurs plateformes. Les conséquences sont les suivantes : Les modèles deviennent des objets de première classe dans le processus de développement, plutôt que d être ignoré après : si vous modifiez le PIM, la fonctionnalité du système livré va changer. 15

24 Chapter 3. Solution proposée 16 La génération de code devient importante : la transformation de la PIM aux PSMs manuellement est coûteuse et risqué de source d erreurs, alors que le mappage automatique de la PSM peut réduire considérablement le coût de la transformation vers une nouvelle plateforme ou mis à niveau. L approche MDA demande de créer d abord un modèle indépendant de toute plateforme (PIM), en suite PIM est raffiné en un ou plusieurs modèles spécifique à une plateforme (PSM). La transformation joue le rôle de l intermédiaire, définit des règles de transformation entre PIM et PSM. La figure ci-dessous représente le processus de MDA : Figure 3.1: Le principe de processus de MDA Ref.[3] Premièrement, on considère le CIM (Computation Independent model) qui est des besoins de l utilisateur. On peut dire qu il est des modèles des exigences. En suite, c est le modèle d analyse et de conception. Le PIM (Platform Independent Model) a été spécifié par un langage de spécification. Ceci peut être un langage textuel ou graphique. Le modèle obtenu est indépendant des plateformes d exécution. Ce modèle sera transformé vers le PIM à la suite. Le modèle PSM (Platform specific model) est transformé à partir de modèle PIM. Un PIM peut être généré à plusieurs PSM pour plusieurs plateformes par l aide des mécanismes de transformation de modèle Techniques disponibles de l approche MDA Le MDA a un grand d ensemble des technologies disponible permettant de la réalisation des logiciels basant sur le cadre de MDA. La figure ci-dessous représente des technologies disponibles dans chaques niveaux de l approche selon la norme.

25 Chapter 3. Solution proposée 17 Figure 3.2: L hiérarchie de modèles de MDA Ref.[17] Voici en résumé une liste des normes importe quel expert de OMG devrait savoir : Méta-modélisation : UML Infrastructure : qui est à la base de la spécification MOF. Meta Object Facility (MOF) : qui est la langue à l aide de laquelle une méta-modèle est défini. Modélisation : UML Superstructure : Unified Modeling Language(UML) est un langage de modélisation à usage général, défini par l intermédiaire du MOF. System Modeling Language (SysML) Profile : un profil UML pour l ingénierie des systèmes. Modeling and Analysis of Real Time Embedded Systems (MARTE) Profil Transformations : Object Constraint Language (OCL) : permet de définir la formelle de contraintes sur des éléments d un modèle. Query View Transformation Language (QVT) : permet de définir un modèle à transformations. MOF Models to Text (MOFM2T) Transformation Langue : permet la définition de modèle au texte transformation. Dans la figure 3.3, c est la présentation d une carte de nombreux flux possibles de la modélisation et de la transformation que on peut suivre lors de la définition d un processus MDA. Tout d abord on doit choisir le langage de modélisation qu on souhaite d exploiter. Cela peut être UML, SysML, MARTE ou tout autre langage de modélisation défini par

26 Chapter 3. Solution proposée 18 Figure 3.3: Le plan du flux de MDA Ref.[17] le MOF ou la grammaire d une DSL peut correspondre à un méta-modèle équivalent, comme il arrive dans Xtext. D un modèle d entrée on peut appliquer le MOFM2T (MOF Models to Text Transformation Language) afin de générer la documentation, le code et les artefacts textuels précieux. Pour notre solution, on va prendre le DSL comme le langage de modélisation et appliquer le modèle au texte transformations (MOFM2T) afin de générer le code.

27 Chapter 3. Solution proposée Solution proposée Maintenant on va parler plus précisément sur la solution proposée. On peut expliquer l étape par étape comme la suite. Figure 3.4: La vue l ensemble de solution Au niveau de M3, le méta-métamodèle utilisé est suivi le standard MOF. On suppose que l application de langage naturel est le CIM dans la figure 3.1. On doit transformer le CIM vers le PIM par l aide d un langage DSL. On implémente la technologies du projet Eclipse, distribué dans Eclipse Modeling Framework : Xtext[8] pour définir le langage DSL. Ce Framework offre toutes les fonctionnalités pour créer son propre langage et la définition de règles de génération de transformer de grammaire dans leurs programmes à un langage d usage général comme Java, Objective C, C + +, etc. On implémente le Xtext pour définir le langage de meta-modèle (MobileApp- Model) et puis on utilise ce langage pour spécifier le modèle correspond au PIM. Ensuite, on développe le générateur de code pour les plateformes spécifiées en espérant d obtenir le code de l application mobile de la plateforme cible. Pour le fait, on applique la théorique de la transformation le modèle PIM vers les modèles PSM pour chaque plateforme mobile. Afin de définir la règle de la transformation, on utilise l Acceleo[18] qui est une implémentation de l Object Management Group (OMG) sur le norme de MOF,MOF Models to Text (MOFM2T)[19]. Les travaux de définir un DSL pour le PIM et de réaliser le générateur de code sont les travaux au niveau de méta-modèle (M2) dans le principe de l approche de d ingénierie dirigée par les modèles. Et les modèles obtenus (PIM, PSM) sont dans le niveau de modèle (M1) qui est transformé pour l objectif d obtenir le code exécutable.

28 Chapter 3. Solution proposée Méta-modélisation Un modèle est une représentation abstraite de la réalité. Il est utilisé pour représenter schématiquement une partie des concepts d un programme, afin de permettre une meilleure compréhension de la façon dont l architecture fonctionne. Pour comprendre ce qui est contenu dans un modèle ainsi que les informations qu il doit représenter, il faut d abord s entendre sur la définition de son contenu. C est le travail qui est visé lors de l utilisation du terme méta-modélisation. Normalement, il existe plusieurs techniques de méta-modélisation comme qu on a parlé dans la partie de techniques disponibles de l approche MDA dans le chapitre 2 et 3. Les méta-modèles dédiés peuvent donc être créés pour répondre aux besoins spécifiques. Ils sont appelés DSL (Domain Specific Language). Comme DSL sont plus largement utilisés, le développement de nouvelles méta-modèles devrait devenir mieux comprise et plus fréquente. Pour développer un méta-modèle, les étapes suivantes sont suivies : Définir les concepts qui devraient être modélisés et la meilleure façon de le faire. Représenter ces concepts sous forme de MOF ou EMF diagrammes. Notre objectif principal est de réaliser le générateur de code pour les applications mobiles en appliquant l approche d ingénierie dirigée par les modèles donc l application mobile sera le domaine considéré pour le DSL Conception de la méta-modélisation Une fois défini notre domaine de langage, on doit décider sur le choix d une syntaxe de notre langage qui doit représenter toutes les composantes de notre domaine. Ce type particulier de langage est appelé Domain Specific Language(DSL) : un langage spécifique à un domaine particulier. Enfin, on va créer une grammaire de transformation qui est capable de transformer un fichier écrit selon cette syntaxe textuelle et de construire une instance appropriée de notre modèle de domaine. La figure3.5 représente l idée du processus de la transformation le CIM vers le PIM. Figure 3.5: L étape de réalisation de PIM

29 Chapter 3. Solution proposée 21 Pour le développement du DSL, on utilise Eclipse Xtext. Le Xtext[8] fournit l outil pour créer et utiliser le DSL textuelles dans un environnement de Model Driven Developement (MDD). Le langage de domaine est décrit dans un méta-modèle. Et la syntaxe du langage textuelle est décrite dans un fichier de grammaire.xtext. Le Xtext peut également déduire de notre méta-modèle de langage, de la grammaire de langage Générateur de code Avant d obtenir le code complet, on a d abord le PSM. Pour générer le modèle PSM, on applique le principe de transformation de Object Management Group (OMG) qui s appelle Model to Text Transformation Language (M2T). M2T se concentre sur la génération le codage textuelle à partir de modèle. On a choisit l Acceleo comme l outil de développement Conception pour le développement du générateur de code Pour la conception de réalisation du générateur de code, on doit définir d abord la règle de la transformation pour le générateur de code. Afin de faire cela, on utilise Acceleo. Acceleo est nativement basée sur EMF, et est donc directement compatible avec les outils créés dans ce cadre comme Xtext. Les avantages de Acceleo sont une bonne intégration avec Eclipse et supporte les fonctionnalités du développement comme debug, tracking et tracing. Un autre avantage de Acceleo est qu il a la fonctionnalité qui permet de la manipulation confortable de code généré, la construction du générateur natif et il s applique au MOF, le standard de M2T (Model to Text transformation) spécifié par l OMG. Figure 3.6: L étape de réalisation de générateur

30 Chapter 3. Solution proposée 22 On définit la règle de la transformation pour le modèle PSM spécifié à la plateforme Android. Cela est le générateur de code. Ensuite le développeur fait passer le modèle PIM travers le générateur de code pour obtenir le code de plateforme cible. On choisit d implémenter le générateur de la plateforme Android. D abord il faut avoir la connaissance sur cette plateforme. Celle-ci sera représentée dans la partie suivante Plateforme cible (Android) La plateforme Android [20] est un logicielle libre de Google Inc., qui inclut un système d exploitation, middleware et aussi des applications pour une utilisation sur les appareils mobiles, y compris les Smartphones. Pour écrire le code pour les applications d Android, nous devons travailler avec des fichiers et de nombreux sous-répertoire dans le cadre du projet de répertoire principal. Chaque répertoire a été alloué à la fonction correspondante. Il est nécessaire de savoir que comment cela pourrait bien fonctionner. Figure 3.7: Les répertoires et fichiers nécessaires de l application Android La figure 3.7 représente les fichiers dans un projet de l application android. src : vient de mot Source Code en anglais. Le src est la partie de code source que nous avons créé, qui a été écrit dans le fichier.java, que nous allons voir le nom des attributs et méthodes de classe. gen : vient de mot Generated Java Files en anglais. C est une répartition qui a été faite automatiquement lors de la création du projet tel que R.java dans lequel se compose des textes et l élément de l interface en étant amené dans le projet par le plug-in d Android. Ce fichier est comme un pointeur vers les répertoires de drawable, layout, values. res : vient de mot Resource en anglais. Le res est pour stocker des fichiers qui sont utilisés en collaboration avec le projets, tels que des images etc. Il

31 Chapter 3. Solution proposée 23 se décompose en 5 répertoire : drawable - hdpi, drawable - ldpi, drawable - mdpi,layout et values. AndroidManifest.xml est structuré en fichier xml, qui stocke des propriétés et des paramètres de la configuration d application, telles que le nom des fonctions de l application, la version du code, le droits d autorisations pour accéder à l application, etc. La responsabilité de ce travail est de réaliser les générateurs de code à partir de l étude de l approche d ingénierie dirigée par les modèles. Ces générateurs doit capable de créer le code source pour l application mobile à partir de modèle PIM. Le code généré doit être compilable aux applications natives pour les plateformes de l appareil mobile. L objectif attendu est que le code généré peut être utilisé en moins de modification. Ce chapitre présente la solution du développement des applications mobiles. On espère que cette approche puisse résoudre la problématique du développement des applications mobiles. Et pour prouver l hypothèse, on implémentera cette solution proposée et on l expérimentera à la suite.

32 Chapitre 4 Implémentation et Expérimentation Ce chapitre est la présentation de notre travail. C est l implémentation de la solution proposée et l expérimentation pour examiner notre produit de projet. En fin on présente le résultat et l évaluation. 4.1 Implémentation de la solution Le travail sur la partie pratique du sujet Études de l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles se contient deux parties. La première, c est de modéliser le modèle indépendant des plateformes (PIM). Le modèle obtenu de cette partie joue le rôle comme la conception de l application qu on veut développer. Afin de réaliser ce modèle, on a besoin de définir un langage de modélisation, c est un langage dédié (Domain-specific language :DSL). La deuxième est la partie du développement de générateur de code. On a choisi de développer le générateur de code pour l application sur la plateforme Android. Afin de réaliser les générateurs de code, on suit le principe pour le modèle spécification des plateformes (PSM) Implémentation de langage dédié : DSL Notre DSL est développé sous la conception de regrouper des éléments en trois composants : Model, View et Control. Cela nous permet de réaliser la transformation de code pour les plateformes spécifies. Parce qu on a bien concevoir le 24

33 Chapter 4. Implémentation et Expérimentation 25 structure, on peut transformer le code facilement. Il soutient également la modification plus facile de modèle si l exigence a changée. La figure 4.1 est la structure de notre DSL. Figure 4.1: Le concept de DSL Application Application joue le rôle comme la racine de notre arbre qui contient les composants de View, Model et Control. L objet principal contient toutes les informations de base sur une application. Chaque projet doit contenir exactement un objet principal qui peut être dans un contrôleur arbitraire.

34 Chapter 4. Implémentation et Expérimentation Model Model est le premier élément dans l arbre est le Model. Dans la partie de model, le structure des attributs et des valeurs des paramètres sont décrits. Ces attributs seront définissent le type, le nom et la description d entité. Le type des attributs peut être String, Integer, Float, Boolen ou Array.

35 Chapter 4. Implémentation et Expérimentation View View est le deuxième élément. Les éléments de la partie de View sont la mise en page (Layouts) et des composants d interface (Widget). Pour les layout, on a maintenant définit juste 2 types, c est table layout et linear layout. Chaque type de layout doit être définit ses paramètre de caractères par exemple : la taille, la dimension, la marge, l orientation, la gravité, le colon etc. Pour les widget, on a définit le widget de base pour les applications mobiles comme TextView, Button, Label, ImageView, TextInput, RadioButton. TextView et Label servent à présenter des texts pour l utilisateur. Le TextView est définit par le mot-clé TextView suivi son nom et dans le parenthèse contient ses propriétés. C est la même pour le Label mais ceci indiqué par le mot-clé Label.

36 Chapter 4. Implémentation et Expérimentation 28 Botton permet à l utilisateur la possibilité d appeler des actions qui ont été liés à des événements de la touche. Pour la définition de bouton, il est indiqué par le mot-clé Botton suivi son nom et il existe la définition par défaut suivant. ImageView sert à afficher l image aux utilisateurs. Il est indiqué par le mot-clé ImageView suivi son nom et le chemin où se trouve l image. Et dans le parenthèse se compose ses description. TextInput est un champ pour mettre des entrées de l utilisateur, indiqué par le mot-clé TextInput suivi son nom et ses descriptions dans la parenthèse.

37 Chapter 4. Implémentation et Expérimentation 29 RadioButton sert à définir le choix, il peut y avoir plusieurs choix comme une liste des choix. La valeur est true et false Control Control est la dernière partie de notre DSL. Il sert à définir des actions de l application. Les éléments de View et les données de Model sont reliés avec les actions par la désignation dans le control. Une classe de control peut se contient plusieurs actions. Chaque action est décrite en forme de codefragment. Pour l instant, on peut définir les actions par les événements de base comme ontouch, onleftswipe, onrightswipe, etc. pour les éléments de la partie View et faire le mappage entre les éléments de View et de Model. Les images suivantes représentent quelques parties du code des descriptions de la partie de Control.

38 Chapter 4. Implémentation et Expérimentation 30 Pour les actions qui se présentent dans notre DSL, il y 9 actions. La forme pour décrire ces actions sont définies dans l ActionDef. InvokeActiviyAction : cette action sert à fait l appel d autre actions qui sont définies. La définition de InvokeActiviyAction commençant par le mot-clé invoke suivi par le nom d action dont on a envie d appeler. GoToURLAction : cette action est utilisé lorsque l application se compose de la fonction d accéder à l Internet. La définition de GoToURLAction commençant par le mot-clé goto suivi par l url du site-web destinataire. SetIntent : cette action permet de transformer des informations entre les classes dans une application. Par laquelle on définit des informations d envoyer sur la définition commençant par le mot-clé setintent. Dans le cas où l information envoyé est pris d un élément de l interface (par exemple : TextInput), on doit définir le nom du élément View suivi par le nom de classe destinataire. GetIntent : cette action permet de transformer des informations entre les classe dans une application aussi mais c est au niveau de récepteur. La définition de GetIntent commençant par le mot-clé getintent suivi par le Widget qui va représenter l information envoyé par exemple le TextView,l ImageViwer.

39 Chapter 4. Implémentation et Expérimentation 31 DrawLine : cette action permet de faire le graphique de désigner un line. Sa définition commençant par le mot-clé drawline et puis la coordonné à partir et d extrémité. DrawRactangle : cette action permet de faire le graphique de désigner un carré. Sa définition commençant par le mot-clé drawractangle et la coordonné du côté à gauche, à supérieur, à droit, à inférieur du rectangle à tirer. DrawTable : cette action permet de faire le graphique de désigner un tableur carré. Après le le mot-clé drawtable, on doit définir dans où le tableur affichera, ensuit c est la taille en unité carré, la couleur de la bordure et la taille de la bordure. MappingTask : Les éléments de View et les données de Model sont reliés par cette action. La définition de MappingTask commençant par le mot-clé map suivi par le nom de l élément View qui sera le présentateur. Ensuit c est l élément de l attribut définit dans le Model. ShowScreen : C est l action qui soutient la fonction de l affichage de l interface. Sa définition commence avec le mot-clé showscreen suivi par le nom de l interface. Après avoir réalisé le DSL pour notre domaine, on doit exporter notre langage en forme de plugin pour l utilisation de modéliser et de réaliser la transformation de modèle PSM. Une fois on a le plugin, on importe le plugin de MobileAppDSL dans notre Eclipse IDE Implémentation de générateur de code Pour le développement du générateur de code pour l application mobile par l aide de l approche d ingénierie dirigé par les modèles, il est très important de définir la règle de la transformation parce que la transformation est la clé de génération le code de la plateforme cible à partir de modèle PIM. Une fois que le développeur a modélisé le modèle PIM qui est compté comme l entrée de génération, le développeur doit faire passer ce modèle travers le générateur de code. Afin de développer le générateur de code, on peut exploiter l Acceleo qui est un outil visant à définir la transformation de modèle en texte, dans notre cas, un DSL à la transformation de l application Android. Après avoir installé l Acceleo sur l éditeur d Eclipse, on crée un projet d Acceleo, choisit le méta-modèle de notre DSL (on a nommé le DSL MDAmobileDsl ) qui devrait être dans la liste. Ensuite on crée le module, dans lequel on décrit la transformation. Voyant dans la figure4.2, le module se trouve au milieu de l architecture.

40 Chapter 4. Implémentation et Expérimentation 32 Figure 4.2: L architecture de l Acceleo Les modules seront la chaîne de génération pour l objectif de générer le code. Cette chaîne doit concevoir et être décrit sur le correspondant à la conception de plateforme cible. La figure 4.3 est le concept de la transformation pour la plateforme Android. Figure 4.3: Le concept de la transformation pour la plateforme Android Un module correspond à un fichier.mlt. Selon le concept de la plateforme

41 Chapter 4. Implémentation et Expérimentation 33 Android 3.7, le générateur doit être capable de générer le fichier nécessaire pour que l application puisse fonctionner. Au début de l exécution du modèle de générateur, le module Main qui est le module principal de modèle de générateur, faire l appel sur des autres modules. On va présenter maintenant chaque module du modèle de générateur de code pour l application d Android Le module generatemanifest Le module generatemanifest sert à générer le fichier AndroidManifest.xml par la définition dans le template generatemanifestfile qui va tirer des informations de l application qui est définit dans la partie de l application dans le modèle PIM Le module generateview Le module generateview sert à générer le répertoire layout et le fichiers dans ce répertoire. Le concept de génération est de générer le fichier.xml qui se compose les layouts et les widgets. Il va faire l appel sur le template generatelayoutprop (qui se trouve dans le fichier generatelayout.mtl) pour générer les propriété de layout qui est définit à partir de DSL, et fait l appel sur le template generatewidget (qui se trouve dans le fichier generatewidget.mtl) pour générer le xml de la propriété des widget. Un layout peut se compose plusieurs widgets dedans. On met l appel des templates for. Le boucle va s arrêter lorsqu il n y a plus des layouts et des widgets définies à partir de DSL Le module generateresource Le module generateresource sert à générer le répertoire values et les fichiers dans ce répertoire. Les valeurs de ressource qui sont définies dans la partie de Model de modèle PIM sera transformé en forme de fichier.xml tel que res/values/genstrings.xml, /res/values/gen-bools.xml etc. selon le type de l attribut Le module generateactivity Le module generateactivity sert à générer le répertoire src le et les fichiers.java. Une class dans le modèle PIM est généré à un fichier.java. Les actions seront générées sous le méthode de l événement définit. La template eventcode sera appelé lorsque la définition de EventDef de la partie Control dans le modèle se compose l événement

42 Chapter 4. Implémentation et Expérimentation 34 correspondance au paramètre dans le template. Et c est pareil pour le template de actioncode qui attente la définition dans le ActionDef de modèle PIM. Sous le projet de l Acceleo, on a créé le répertoire model pour mettre le modèle PIM qui est le modèle d entrée et le répertoire out pour mettre le code généré. 4.2 Application de la méthode proposée Dans notre étude, on réalise deux modèles PIM à partir de notre DSL pour l expérimentation. Un modèle PIM est le modèle d une simple application mobile et un autre PIM est le modèle d une application du jeu SUDOKU. Ces deux modèles jouent le rôle de modèle d entrée afin de générer le code de plateforme cible. Cette partie du rapport représente la méthodologie, les résultats et les analyses des travaux pratiques Processus de développement Pour tester notre DSL, on essaie de réaliser deux modèle PIM de l application mobile dans le projet Acceleo pour Android. Les étapes qu on va présenter suivants, sont le processus de développement une application mobile en utilisant notre générateur de code. Sur le projet Acceleo androidgen, faites un clique à droit sur le dossier de model. Choisissez Nouveau Fichier. Créez un fichier nommé nomdefichier.mda. Ecrire le code selon la syntaxe de notre DSL. Ensuite on passe le modèle PIM à travers le générateur comme les étapes suivants. Sur le projet Acceleo androidgen, faites un clique à droit sur le projet. Choisissez Run configuration. Complétez la configuration de l exécution comme la figure 4.4 Cliquez Run, vous obtenirez le résultat dans le répertoire out comme la figure Application 1 : Une application simple Pour le premier test de générateur, on crée une application très simple. Les fonctionnalités de cette application ne sont pas compliquées. Voici le concept de l application simple.

43 Chapter 4. Implémentation et Expérimentation 35 Figure 4.4: La configuration de l exécution d Acceleo Figure 4.5: La location du code généré Description de l application Cette application se compose deux pages. Ce sont le Main page et Secode page. La conception d interface est représenté dans le tableur 4.1 et 4.2. Les fonctionnalités de l application sont comme les suivants : La page Main Un label doit être capable d afficher le nom de l application. Un text input est prêt pour qu un utilisateur puisse entrer le nom. Le nom entré par l utilisateur dans le text input doit être transmettre à la page Second lorsque l utilisateur touche le bouton Show. Un bouton Next peut amener l utilisateur à la page Second. La page Second Un label doit être capable d afficher le nom de l application.

44 Chapter 4. Implémentation et Expérimentation 36 Un label affiche le nom d entré à partir du text input de la page Main. Un Image Viewer doit être capable de représenter un image. Un bouton Seach peut amener l utilisateur au site web http :// Une fois on a décrit l application, on transforme des exigences à un modèle PIM par le langage DSL. Le modèle PIM est présenté dans l annexe A Résultat Après avoir modélisé un modèle PIM correspondant à la conception, on fait passer le modèle à travers le générateur de code et obtient le résultat suivant : Mockup Genéré Table 4.1: La comparaison d interface de Main Pour le page Main au niveau de fonctionnalité, notre générateur est capable de généré le code qui peut faire l application fonctionnant comme tous les concepts cibles. Mockup Genéré Table 4.2: La comparaison d interface de Second

45 Chapter 4. Implémentation et Expérimentation 37 C est pareil pour le page Second. Si l on fait la comparaison des fonctions d application entre ces à partir de la conception et ces à partir de code généré, ils sont la même Conclusion Selon le concept de l application simple qu on a définit, notre générateur de code est capable de généré le code pour l application d Android. On peut faire la conclusion qu il peut générer les fonctions comme la suit : View : On a fait le test sur le layout Linear Layout, le Label, le Text Input, le Button et le Image Viewer. Le générateur de code a donné le code qui peut fait fonctionner bien pour tous les éléments testés. Le code en forme xml est bien structuré comme le code qui est réalisé manuellement. Control : Sur la partie de Control, on va parler de test sur les fichiers.java qui fait marcher des actions d application. Le code généré est capable de faire marcher l application Application 2 : Une application de jeu Sudoku Le deuxième test de générateur, on crée une application plus compliquée. C est une application du jeu Sudoku. On va présenter d abord le concept du jeu Description de l application Les fonctionnalités de l application sont décomposées en deux parties. Joueur : Jour au jeu Choisir le niveau du jeu. Voir le manuel. Quitter du jeu. Système : Désigner le tableur. Donner les chiffres pour l état initial. Vérifier les chiffres entrant par le joueur selon les règles du jeu. Une fois on a décrit l application, on transforme des exigences à un modèle PIM par le langage DSL. Le modèle PIM est présenté dans l annexe B.

46 Chapter 4. Implémentation et Expérimentation Résultat Une fois on a fait la conception de l application du jeu Sudoku, on modélise un modèle PIM selon la conception, ensuite on passe ce modèle au générateur code. Voici le résultat obtenu. Mockup Genéré Table 4.3: La comparaison d interface de Main La page Main est l interface principale de l application. Selon la conception cette page se compose les boutons qui relient à l interface du jeu Game, le manuel Help. Le code généré peut donner le résultat correspondant à la conception. Mockup Genéré Table 4.4: La comparaison d interface de Help La page Help est l interface principale de l application. Cette page sera affichée lorsqu un joueur clique sur le Help dans la page Main. Le textbox va présenter la description sur le jeu. Des informations du jeu est définit dans le fichier xml dans le répertoire value en type de string. Et le button Close va vous amener à la page Main.

47 Chapter 4. Implémentation et Expérimentation 39 Mockup Genéré Table 4.5: La comparaison d interface de level La page Level est l interface qui va afficher lorsqu un utilisateur clique sur le bouton Play. Il se compose les boutons qui vont envoyer les chiffre à la classe Game. On a 4 ensembles de chiffres qui distinguent des différences niveaux du jeu. Mockup Genéré Table 4.6: La comparaison d interface de Game La page Game est la plus importante parmi les interfaces de cette application. Il se compose plusieur l action à générés. La grille du jeu est le composant principal. On doit désigner la grille par la fonction drawractangle et la fonction drawline. On peut le faire à partir du générateur de code. Donner les chiffres pour l état initial. Ces chiffres sont donné à partir du choix de niveau dans la classe Level. Malheureusement le générateur n est pas capable de faire. Parce que le DSL n a pas de support de cette fonction. Vérifier les chiffres entrant par le joueur selon les règles du jeu. Le générateur de code n atteint pas à générer cette fonction car cette partie est le logique du jeu. On ne peut pas définir le modèle parce qu il est très compliqué de réaliser la fonction pour le soutenir dans le DSL. Il faut bien concevoir le structure de

48 Chapter 4. Implémentation et Expérimentation 40 DSL. Et afin de faire cela, il faut avoir la bonne connaissance de programmation sur le développement des applications mobiles Conclusion L application du jeu Sudoku est plus compliquée que le générateur puisse générer toutes les fonctionnalités. Il reste la partie de logique qui est en effet très important pour une application du jeu. Mais pour concevoir le DSL supporté et la transformation de modèle pour cette fonction, il faut avoir la bonne connaissance et plus haut niveau du développement des applications d Android. 4.3 Evaluation A la fin de notre l étude sur l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles, on peut appliquer cette approche pour le développement d application mobile de plateforme d Android. Dans cette partie, on souhaite de donner l analyse sur le résultat de notre travail comme la suit : L approche choisi : après avoir étudié, on trouve que parmi les plusieurs approches d ingénierie par les modèles, l approche MDA est le plus agréable pour le développement des applications mobiles. Le MDA est standardisé par l Objet Management Group (OMG) donc la méthodologie de cette approche est claire et pour implémenter on peut le faire de façon appropriée en basant sur le standard. Cependant il existe de nombreuses techniques dans le cadre de l approche MDA pour la modélisation et la transformation de modèles. Au niveau de méta-modèle, on a développé un langage dédié pour le modèle des applications mobile. On a conçu ce DSL afin de modéliser le modèle qui est segmenté en trois parties : la conception d interface, des ressources et des actions de l application. Cela permet d implémenter et de réviser facilement le modèle lorsque le développeur a besoin de modifier le modèle. Cependant, ce DSL n est pas très couvert son domaine à cause de la taille de domaine et de notre expérience sur le développement des applications mobiles. Autrement dire que le domaine des applications mobiles a plusieurs fonctionnalités mais notre DSL fournit juste quelques fonctions principales. Aussi pour l interface, il reste encore beaucoup de types layout et de widget Au niveau du développement de générateur de code, c est dommage qu on puisse développer seulement pour une plateforme Android. Mais la méthodologie

49 Chapter 4. Implémentation et Expérimentation 41 pour développer le générateur de code pour les autres plateformes (ios, Blackberry,WindowsPhone etc) est pareille. Ce qu il est essentiel est qu on doit avoir des connaissances de chaque plateforme sur le concept, la structure, les fonctionnalités fournis par la plat-forme etc. Néanmoins on peut générer le codage de l application Android à partir de modèle PIM sans modification pour une application simple et besoin de la modification pour le cas de l application l application de jeu SUDOKU. En raison que le développement d un jeu, il est plus compliqué que d autres applications, on a besoin de modifier et ajouter la partie de logique dans le code généré à partir de notre générateur.

50 Chapitre 5 Conclusion et perspective Dans ce chapitre, on présente la conclusion de ce qu on a fait pour étudier l approche d ingénierie dirigée par les modèles pour le développement des applications mobiles. En suite on donne l analyse sur le travail et en fin, c est le perspective. 5.1 Conclusion L objectif du stage est d étudier l approche d ingénierie dirigée par les modèles afin de trouver la solution qui aide les développeurs de développer plus rapidement des applications mobiles. On a étudié des avantages de l approche d ingénierie dirigée par les modèles et trouvé que l idée de l approche d architecture dirigée par les modèles (Model Driven Architecture :MDA) est plus approprié pour le développement des applications mobiles. C est la raison pour laquelle on a proposé la solution appliquant l approche MDA afin de développer des applications mobiles. Pour le fait, on commence à concevoir un langage dédié (Domain Specific language : DSL) qui joue le rôle de méta-modèle sur le domaine de l application mobile par le Framework Xtext qui permet de développer le langage de programmation et les langages dédiés (DSL). On définisse le concept de notre DSL en trois parties. La première partie est conçue pour définir l interface de l application. Elle se compose des dispositions pour la mise en page (Layouts) et des composants d interface (Widget). La deuxième partie a le concept de définir le contrôle de l application. Pour qu une application puisse fonctionner, il a besoin de définir des actions, ces actions sont définit grâce à cette partie. En fin la troisième partie est conçu pour fournir la définition des modèles des variables dans l application. Autrement dit que cette partie sert à définir des ressources qui seront utilisé dans l application. Le produit de cette étape est un langage dédié pour notre domaine de l application mobile en forme de plugin sur l éditeur Eclipse. Ce langage 42

51 Chapter 5. Conclusion et perspective 43 permet aux développeurs de construire un modèle indépendant de plateforme (PIM) sur le type de fichier.mda. Une fois qu on a le langage dédié, l étape suivant est de définir le modèle spécifique à la plateforme(psm). On doit définir la grammaire de la transformation pour des différentes plateformes. Malheureusement, à cause de le temps limité et la limite d expérience sur le développement mobile, on peut définir le PSM juste pour la plateforme Android. L Acceleo est choisi comme l outil de cette étape. On a décrit la grammaire en respectant la structure de la plateforme Android. Le résultat de cette étape est le générateur de code pour l application mobile de plateforme Android. Après que le développeur modélise le modèle PIM par notre DSL, il doit faire passer le modèle vers le notre générateur afin d obtenir le codage de l application mobile de chaque plateforme. 5.2 Perspective Même si l on a réussi de faire le générateur de code à partir de modèle comme le principe de l approche d ingénierie dirigée par les modèles, il reste encore le travail à améliorer et compléter. Puisque le domaine de l application mobile est large, notre DSL ne couvert pas tout domaine. Il nous faut fournir plus d éléments qui permettent de modéliser une application mobile plus compliquée par exemple : au niveau de l interface (View), il a besoin d autres layouts et widgets. Au niveau de l action aussi, il faut ajouter des éléments qui aident à définir des autres fonctions. Comme l application du jeu, il est nécessaire de définir la logique du jeu, malheureusement on n atteint pas à fournit le soutien de cette fonction. Ceci est important d améliorer dans l avenir. Pour le développement du générateur de code, on a pris le technique M2T, implémenté par l outil Acceleo. On a développé seulement le générateur de code pour la plateforme mobile. Il sera mieux de dévéloper aussi les générateurs des autres plateformes comme l ios, le Blackberry, le WindowsPhone.

52 Annexe A Modèle PIM de l application simple avec DSL 44

53 Annexe B Modèle PIM de l application de jeu Sudoku avec DSL 45

54 Appendix B. Modèle PIM de l application de jeu Sudoku avec DSL 46