Soutenance mémoire
Faiblesses du langage UML
UML est un langage de modélisation graphique, avec lequel, on peut modéliser la structure statique et la structure dynamique du système, mais UML n’aide pas les concepteurs des systèmes pour les raisons suivantes [1] :
– L’absence d’une précision sémantique formelle, parce qu’UML est un langage semi-formel;
– La complexité d’un modèle en termes de nombre des diagrammes et de symboles, surtout si le système en conception est grand;
– Le non existence de relation ou de dépendance définie entre les digrammes d’un modèle;
– Le manque d’une hiérarchie lors de la décomposition d’un modèle ;
– L’absence de présentation des contraintes et propriétés temps réel dans un modèle ;
– Le manque d’annotations.
– La non existence d’une méthode de transformation à partir du modèle vers l’implantation sans faire assister l’ingénieur.
Les principes de l’IDM
Suite à l’approche objet des années 80 et de son principe du « tout est objet », l’ingénierie du logiciel s’oriente aujourd’hui vers l’ingénierie dirigée par les modèles (IDM) dont le principe est « tout est modèle ». Cette nouvelle approche peut être considérée au même temps comme une continuité et une rupture des travaux précédents en continuité et en rupture avec l’approche objet [5]. Elle est en continuité grâce à la technologie objet qui a mené à l’évolution vers les modèles. En effet, lors de la conception des systèmes sous forme d’objets qui communiquent entre eux, on trouve le problème de classification des objets selon leur origine (objets métiers, techniques,..). L’IDM vise donc, de manière plus radicale à fournir un grand nombre de modèles pour exprimer séparément chacune des préoccupations des utilisateurs, des concepteurs, des architectes, etc. C’est par ce principe de base différent que l’IDM peut être considérée en rupture par rapport aux travaux de l’approche objet. Le concept fondamental de l’IDM est la notion de modèle pour laquelle il n’existe pas à ce jour de définition universelle. Selon les travaux de l’OMG 1, de Bézivin [6] et al et de Seidewitz [7], la définition suivante d’un modèle est considérée [8]. Définition (Modèle) : Un modèle est une abstraction d’un système, modélisé sous la forme d’un ensemble de faits construits dans une intention particulière. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système modélisé. On déduit de cette définition la première relation capitale de l’IDM, entre le modèle et le système qu’il représente, appelée « représentation de ». Pour qu’un modèle donne une représentation efficace d’un système qu’il modélise, il doit respecter quelques caractéristiques du modèle parmi lesquels [8]:
– Abstraction : un modèle doit donner une abstraction correcte du système ; c.-à-d. il doit assurer les besoins souhaités de la même façon que le système les assure.
– La compréhensibilité: le modèle ne doit pas être ambigu, facile a comprendre par les utilisateurs. Pour cela il doit être formalisé dans un langage compréhensif.
– La substituabilité: le modèle doit être précis et suffisant c’est-à-dire en substitution avec le système qu’il modélise, le modèle doit contenir les propriétés à étudier par le système.
– L’économie: le modèle doit être peu coûteux par rapport aux coûts du développement du système réel.
Définition Un méta-modèle est un modèle d’un langage de modélisation. Il définit les concepts ainsi que les relations entre ces concepts nécessaires à la description des modèles. La définition de méta-modèle mène à l’identification d’une autre relation entre le modèle et le méta-modèle, appelée « conforme à ». On dit qu’un modèle est conforme à un méta-modèle si tous les éléments du modèle sont instance du méta-modèle ; et les contraintes exprimées sur le méta-modèle sont respectées [9]. Dans l’IDM il existe deux relations de base :
– La première relation lie le modèle et le système modélisé, elle s’appelle « Représentation de ».
– La seconde relation lie le modèle et le méta-modèle du langage de modélisation, c’est la relation « Conforme à ».
Un autre concept important dans l’IDM est la transformation de modèles. Elle permet le raffinement des modèles, c’est-à-dire le passage d’un modèle abstrait à un modèle plus détaillé en allant jusqu’à la production des artefacts exécutables [10]. Définition 3 Une transformation de modèle est une technique qui génère un ou plusieurs modèles cibles à partir d’un ou plusieurs modèles sources conformément à un ensemble de règles de transformations. Ces règles décrivent essentiellement comment un modèle décrit dans un langage source peut être transformé en un modèle décrit dans un langage cible. La transformation endogène versus transformation exogène : une transformation endogène est une transformation dont les modèles source et cible ont le même méta-modèle tandis qu’ils sont différents pour une transformation exogène [11]. Les transformations de modèle à modèle: selon Tom MENS, ce type de transformation est un raffinement et amélioration de la qualité du modèle. C’est un passage d’un modèle à un autre modèle du même système dont le méta-modèle peut être différent ou le même. Pour cela, ces transformations de modèles nécessitent l’utilisation d’un langage de transformations, Selon Jean BÉZIVIN [12] ces derniers sont classés en ordre chronologique en trois générations : La première génération concerne les langages de transformation destructures séquentielles d’enregistrement. Dans cette catégorie, un script montre comment le modèle source est transformé en un modèle cible comme les langages de scripts UNIX, AWK ou Perl. La deuxième génération est les langages de transformation d’arbres. Les modèles sont représentés sous forme d’arbre. La transformation est réalisée par le parcours d’un arbre d’entrée (le modèle source) et la génération d’un arbre de sortie (le modèle cible). Elle se base souvent sur des documents au format XML et l’utilisation de XSLT ou XQuery [13]. La troisième génération forme les langages de transformation de graphes, dans ce cas le modèle à transformer est représenté par un graphe orienté étiqueté. La transformation est donnée cette fois sous forme d’un modèle conforme à un méta-modèle. ATL est un exemple représentatif de langage de transformation de graphes. Les transformations de modèle à code source: ou génération de code, il s’agit d’un cas particulier de transformation de modèle à modèle où la grammaire du langage de programmation est le méta-modèle du modèle cible. C’est une représentation textuelle des informations du modèle dans un langage de programmation cible [13]. Il existe plusieurs langages de génération de code, par exemple XPand, Acceleo [14].
Historique d’UML
Depuis 1974 jusqu’à 1990, de nombreuses approches objets ont apparues, ensuite en 1994, une cinquantaine de méthodes de conception objets ont existé, parmi elles, trois méthodes sont véritablement émergées:
1) La méthode OMT de James Rumbaugh représente graphiquement les aspects statique, dynamique et fonctionnel du système.
2) La méthode BOOCH’93 de Grady Booch introduit le concept paquetage (package).
3) La méthode OOSE de Ivar Jacobson (Object Oriented Software Engineering) donne une analyse sur la description des besoins des utilisateurs (cas d’utilisation).
Ces trois analystes ont décidé d’unir leur efforts en constituant un langage commun, le fruit de ce travail est proposé en 1996 suite à une requête RFP (Request For Proposal), où la version 0.9 d’Unifed Medeling Language (UML) a été présentée. Le terme unifed signifie que les analystes ont établi un couplage des concepts objets. Le terme langage signifie qu’il s’agit de créer un langage de modélisation, et pas une méthode. En janvier 1997, la version 1.0 d’UML est proposée initialement à l’OMG. Ce dernier ne l’a accepté qu’en Novembre 1997 dans sa version 1.1 où UML a été normalisé par l’OMG comme un standard international. UML a évalué rapidement. En 1998, UML 1.2 a vu le jour avec des changements cosmétiques. En Mars 2000, la version 1.3 d’UML a apparue avec des modifications dans le cas d’utilisation et les diagrammes d’activité. En Septembre 2001, avec l’ajout des nouveaux composants, et profils, la version UML 1.4 est née. En Avril 2004, une autre version d’UML est créée, c’est la version 1.5. Ainsi, en Juillet 2005, la version 2.0 est proposée, avec de nouveaux diagrammes et une bonne prise en compte de l’aspect dynamique. En Avril 2006, la version 2.1est créée. En Février 2009, UML c’est stabilisé à la version 2.2 [20].
Ingénierie dirigée par les modèles pour les systèmes temps réel embarqués
Dans le but est de concevoir des applications temps réel embarqués sûres, fiables et efficaces, des spécifications précises, complètes et non ambiguës sont nécessaires pendant le processus de développement. L’ingénierie dirigée par les modèles apporte de bonnes pratiques pour le développement de logiciels. Ces pratiques sont ajoutées lors du développement des applications temps réel embarquées pour de nombreuses raisons [30]:
La spécification des applications temps réel embarquées peut avoir des points de vue différents (ex. fonctionnel, temps-réel, tolérance aux fautes, etc.) D’où la nécessité d’ajouter qui des techniques d’abstraction lors du développement.
Les options d’implémentation peuvent changer considérablement ; où pour un même modèle, nous pouvons voir plusieurs différents modèles d’exécution selon les contraintes de réalisation particulières (modèle multitâches, communication synchrone, programmation en boucle, etc).
La contrainte de performance des applications temps réel embarquées diminue lors de l’utilisation des techniques standards pendant le développement du logiciel. Les optimisations réalisées engendrent un code fonctionnel qui provoque la non fidélité du système final.
Le test et la validation des applications temps réel embarquées sont des contraintes cruciales, en effet la définition de modèles et d’outils d’analyse précis et spécifiques est nécessaire.
En effet, lors de l’utilisation de l’IDM lors du développement des applications temps réel embarquées, elle mène à la définir un ensemble d’artéfacts (règles méthodologiques, transformations de modèles, génération automatique de code), qui doit être homogène, intact et auparavant testés, assurés et évalués. En outre l’ingénierie dirigée par les modèles introduit un inconvénient dont le code généré est moins performant qu’un code optimisé directement pour une plateforme cible.
Les réseaux de Pétri
Les réseaux de Pétri [32] sont utilisés afin de modéliser le comportement dynamique de systèmes discrets. Ils sont composes de deux types d’objets : les places et les transitions. L’ensemble des places permet de représenter l’état du système ; l’ensemble des transitions représente alors l’ensemble des événements dont l’occurrence provoque la modification de l’état du système. A l’occurrence d’un événement correspond le franchissement d’une transition dépendant de la satisfaction de préconditions. Les réseaux de pétri offrent une représentation graphique simple des systèmes modélisés. Une place est représentée par un cercle, une transition par un rectangle, et les relations de causalité au sein du système sont représentées par la présence – ou l’absence – d’arcs valus reliantles places aux transitions. Un des atouts, et non le moindre, de ce formalisme est d’offrir de nombreux outils d’analyse structurelle, tels que la théorie des réductions ou le calcul d’invariants. Un certain nombre d’outils utilisent cette théorie comme base, on peut citer : DESIGN-CPN [33], PAPE-TRI [34] et PEP [35].
|
Table des matières
Introduction
Chapitre 1 Positionnement
1. Contexte du projet
1.1. Faiblesses du langage UML
1.2. La complexité grandissante des systèmes embarqués
2. Ingénierie Dirigée par les Modèles
2.1. Les principes de l’IDM
2.2. L’approche MDA
2.3 La Sémantique des langages de modélisation
2.4. Langage de modélisation UML
3. Les systèmes embarqués
3.1. Définition
3.2. Architecture d’un système embarqué
3.3 La structure de base d’un système embarqué
3.4 Contraintes d’un système embarqué
3.5 Le codesign
3.6 Ingénierie dirigée par les modèles pour les systèmes temps réel embarqués
Chapitre 2 Etat de l’art
1. Les techniques de vérifications
1.1. L’analyse statique
1.2. Vérification formelle
1.3. Simulation
2. fUML
2.1. Définition
2.2. La syntaxe abstraite de fUML
2.3. La sémantique : Le modèle d’exécution de fUML
2.4. Le moteur d’exécution et son environnement
2.5. L’exécution des activités
Chapitre 3 Contribution
1. Présentation du système
1.1. Diagrammes de cas d’utilisation
2. La préparation de l’environnement de travail
3. La réalisation du système
4. Vue générale sur l’outil proposé
4.1. L’entité Interface
4.1.1. Le modèle UML
4.1.2. Les informations supplémentaires ajoutées par le concepteur
5. Implémentation
5.1. Générateur de code
5.2. Simulation
6. Conclusion
Conclusion
Bibliographie
Télécharger le rapport complet
