Examen

Vous trouverez ici l'examen 2008 avec sa correction et son barème

Soumission

Vous trouverez ici la façon dont il vous faut soumettre votre sujet

Sujets CAR

Génération de tests à partir de machine à états UML2

Un test permet de révéler des fautes dans une application. Réaliser un test sur une application consiste à exécuter des cas de tests (suite d’envois de messages) et de vérifier pour chaque cas de test que le comportement obtenu de l’application correspond bien au résultat attendu. Si tel n’est pas le cas, cela veut dire que l’application contient des défaillances (erreurs dans le code). L’écriture des cas de tests est la tache la plus compliqué à faire lors de la mise en place d’un test. Une façon de faire est de générer automatiquement les cas de tests à partir de la spécification de l’application sous forme de machine à états. Le but de ce sujet est de mettre en place une génération de cas de tests (diagramme de séquence ou code JUnit) à partir d’une spécification d’une application faire grâce à une machine à états UML2. Contact: Xavier Blanc

Refactoring de modèles UML2

Les opérations de refactoring consistent à modifier la structure d’une application afin d’en améliorer sa réutilisation. Les modifications réalisées ne doivent pas altérer le comportement de l’application. Plusieurs opération de refactoring de code sont connues et supportées par les environnements de développement tels que Eclipse. Le but de ce sujet est de mettre en place un ensemble d’opération de refatoring sur les modèles UML2 (partie diagramme de classe) en assurant que le comportement du modèle UML n’est pas altéré. Contact: Xavier Blanc

Contraintes méthodologiques

Dans un processus de construction de modèles, les contraintes dites méthodologiques permettent de préciser quelles sont les suites de constructions qui sont autorisés aux développeurs et celles qui ne le sont pas. Grâce à ces contraintes, il est possible par exemple de contraindre un développeur à réaliser l’intégralité de son diagramme de classe avant de commencer l’élaboration de ses diagrammes de séquences. Le but de ce sujet est de mettre en place l’ensemble des contraintes méthodologique permettant la réalisation de modèle UML (partie diagramme de classes) suivant l’architecture MVC. Contact: Xavier Blanc

Langage d’actions pour UML2

Pour assurer une productivité maximale en termes de génération de code, un langage de modélisation comme UML2 devra supporter la modélisation des concepts liés aux actions des opérations de classes. L’objectif de ce projet est de fournir un tel langage d’actions. Ce langage devra permettre la modélisation des actions associées aux opérations dans les diagrammes de classes d’UML2. Il doit supporter les actions élémentaires (comme l’affectation) mais aussi les actions propres aux langages orientés-objet comme l’invocation de méthodes. De plus, le langage d’actions proposé devra offrir les mécanismes permettant de spécifier les structures de contrôle (comme le branchement conditionnel, les boucles,.etc). Il est demander par la suite de mettre en ouvre au moins deux opérations de génération de code vers deux langages OO cibles. Contact: Tewfik Ziadi

Génération de code Java à partir de machines à états UML2

Les machines à états d’UML sont principalement utilisées pour modéliser le comportement complet d’une classe UML. Plusieurs techniques ont été identifiées pour implémenter la génération de code à partir de machines à états (ex. utilisation des design pattern..etc). L’objectif de ce sujet est de revisiter ce problème en proposant aux moins deux techniques et en considérant le langage Java comme langage cible. Contact: Tewfik Ziadi

Construction automatique de modèles UML2 de lignes de produits

Un modèle UML d’une Ligne de Produits logiciels (LdP) est définit comme un modèle UML commun à un ensemble de systèmes (produits) appartenant à un domaine particulier. La notion de variabilité est utilisée pour désigner les parties du modèle qui diffèrent d’un produit à un autre. Plusieurs travaux ont été proposés pour la manipulation des LdPs en utilisant des langages de modélisation UML. L’idée de base de ces travaux consiste à : 1) proposer des mécanismes pour la spécification de la variabilité dans les modèles UML, 2) automatiser la dérivation de produits en utilisant les transformations de modèles. L’approche de manipulation de LdP dans ces travaux devient donc descendante : la ligne de produits est modélisée en premier lieu et par la suite les modèles de produits sont dérivés. Cependant, il existe des cas où un grand nombre de produits similaires et dans le même domaine sont modélisés séparément, c’est-à-dire sans prise en compte de la notion de LdP et de la variabilité dès le départ. L’objectif de ce sujet est d’entreprendre une approche ascendante pour la construction de la LdP à partir d’un ensemble de produits similaires. En d’autres termes, retrouver le modèle UML de la LdP à partir de modèles de produits. Ceci devra conduire à proposer des algorithmes permettant l'automatisation de la recherche des éléments communs et variables dans les modèles UML. Il est demandé de ne considérer qu’un seul type de modèle UML2 (les diagrammes de classes OU les diagrammes de séquence). Contact: Tewfik Ziadi

Evolution des modèles de procédés logiciels

Les modèles de procédés de développement logiciels ont souvent été considérés comme étant des modèles contemplatifs, servant uniquement à documenter les différentes étapes de construction d’un produit logiciel. Avec l’avènement de l’Ingénierie Dirigée par les Modèles (IDM), ces derniers tendent à devenir exécutables et servent de moyen pour guider les développeurs dans leurs démarches de développement. Un exemple de leur utilisation est de s’en servir afin d’automatiser certaines routines dans le procédé de développement telles que l’affectation des responsabilités sur les agents, le routage automatique des artéfacts, le contrôle du flux de travail et le respect des deadlines ainsi que la bonne tenue des contraintes méthodologiques. Cependant, les procédés de développement étant de par leur nature complexes et imprévisibles, il est rarement envisageable de ne pas dévier du modèle initial. Les approches courantes imposent soit d’arrêter complètement l’exécution et de reprendre dès le début en prenant en compte le nouveau modèle, soit si le procédé était bien avancé, d’abandonner le suivi automatique et de continuer le procédé sans aucun suivi. L’objectif de ce sujet et d’explorer le moyen d’apporter de la réflexion au langages servant à définir ces modèles de procédés de sorte à pouvoir les modifier en cours d’exécution. Cela passe par une identification des conditions sous lesquelles on pourrait stopper le procédé, le modifier et le relancer à chaud. Des expérimentations ou un prototype pourront se faire dans le cadre d’UML4SPM, un langage de modélisation de procédés logiciel exécutable définit au sein de l’équipe. Contact: Reda Bendraou

Génération automatique d’un éditeur graphique pour UML4SPM

Le but de se sujet est de fournir le moyen de générer automatiquement l’éditeur graphique d’UML4SPM, un langage de modélisation de procédé logiciel exécutable définit au sein de l’équipe Move au LIP6. UML4SPM vient sous la forme d’un meta-modèle MOF qui réutilise quelques concepts du meta-modèle UML. Pour cela vous devrez utiliser le framework GMF de la plateforme Eclipse. L’objectif final est de pouvoir simuler et exécuter les modèles de procédés logiciel instances d’UML4SPM. Contact: Reda Bendraou