CarbonX : un outil de modélisation naturel et interactif

Transcription

1 CarbonX : un outil de modélisation naturel et interactif Scénario 2 : Modifications des attributs de concepts dans le calepin Résumé : Après quelques temps, Marc pense à de nouvelles fonctionnalités pour son application. Il rouvre le projet, et modifie des attributs de concepts dans le calepin.; ceci provoque alors la mise à jour automatique de tous les diagrammes dépendants (écrans, classes UML, etc.). Auteurs (ordre alphabétique) Nom Prénom Dumoulin Cédric cedric.dumoulin@univ lille1.fr Le Pallec Xavier xavier.le pallec@univ lille1.fr Renaux Emmanuel emmanuel.renaux@telecom lille.fr Tarby Jean Claude jean claude.tarby@univ lille1.fr Date : 06 juin 2016 Version : CarbonX_2.0 Document protégé sur MaPreuve.com ( le 15 novembre 2016 sous la

2 Sommaire I. Contexte général de CarbonX... 3 II. Contexte du scénario... 4 Page 2 sur 8

3 I. Contexte général de CarbonX L équipe Carbon du Laboratoire CRIStal ( lille.fr) propose de nouveaux outils pour la modélisation logicielle. Dans ce cadre, l équipe Carbon a imaginé des nouvelles façons de produire des modèles de façon plus naturelle et interactive. Ce document présente le second scénario associé à cet outil. Page 3 sur 8

4 II. Contexte du scénario Ce scénario fait suite au scénario 1 (CarbonX_1.0). Après quelques temps, Marc pense à de nouvelles fonctionnalités pour son application. Il rouvre le projet, c'est à dire le calepin ainsi que les diagrammes qui en dépendent (UML, écrans, etc.). Marc constate que le concept Ami pourrait se voir ajouter l attribut «surnom». Il modifie ce concept dans le calepin (Figure 1) ; ceci provoque alors la mise à jour automatique de tous les diagrammes dépendants (écrans, classes UML, etc.), cf. Figure 2 et Figure 3. Note Cette mise à jour peut : être entièrement automatique, sans aucune animation graphique être visualisée étape par étape pour validation par l utilisateur. Ceci permet par exemple de donner son accord pour UML et de refuser pour certains écrans. Ceci peut être complété par des animations graphiques pour renforcer l idée de la modification, par exemple en montrant l insertion d un champ texte dans un écran. Par ailleurs, ce type de modification peut être initialisé depuis le calepin, un diagramme de classe, un écran, etc. Dans tous les cas, CarbonX garde un lien de dépendance entre tous les concepts, qu ils aient été modifiés ou non. Figure 1 : Modification du concept Ami (ajout d un surnom) Page 4 sur 8

5 Figure 2 : Mise à jour automatique de la classe Ami Figure 3 : Mise à jour automatique de l écran Ami Peu après, Marc se dit que l attribut «lieu» de Salle n est pas assez précis, il préfère le remplacer par «étage», et s apprête à le faire dans le calepin. Or, l attribut «lieu» apparait aussi dans Place libre. Si Marc fait la modification dans le calepin, CarbonX proposera alors à Marc de faire la même modification dans les deux concepts (Salle et Place libre), ainsi que toutes les dépendances (UML, écrans ). Dans ce cas : Page 5 sur 8

6 soit Marc accepte, et CarbonX fait la modification d attribut pour les deux classes et leurs dépendances soit Marc refuse, et CarbonX ne fait la modification que pour Salle et laisse «lieu» pour Place libre. De fait, CarbonX «casse» le lien entre Salle et Place libre puisque, pour lui, les attributs «lieu» des deux classes n étaient pas identiques. Note CarbonX garde la trace de toutes les modifications faites sur les concepts, diagrammes et écrans, et peut donc à tout moment montrer le lien entre le concept originel et sa version actuelle dans le reste du projet (voire même montrer les évolutions du concept). Note CarbonX intègre la notion de priorisation dans les concepts et leurs dépendances. Voici, classé par ordre décroissant, la hiérarchie des importances des localisations des concepts : calepin. Etant donné que le calepin est considéré comme une vue «de création/réflexion», il doit rester a priori dans son état originel. Il influence a priori directement les autres vues. vue «développeur logiciel» (diagramme de classe, diagramme de séquence ) : n influence a priori que la vue «designer» vue «designer «(écrans, enchainement d écrans, ). Ainsi, si le chef de projet (ou un développeur par exemple) modifie un concept dans une vue UML, alors cette modification ne sera pas répercutée dans le calepin (sauf demande explicite de l utilisateur). Pour les éventuelles répercussions sur les écrans de l application, CarbonX peut demander confirmation à l utilisateur. A l inverse, si la modification est faite sur un écran, par défaut ni le calepin ni le diagramme UML ne seront modifiés (sauf demande explicite de l utilisateur), mais CarbonX garde tout de même la trace de cette modification comme indiqué précédemment. Marc ne fait la modification que pour Salle (Figure 4), mais quelques temps après il se dit qu il a fait une erreur. Il ouvre le calepin, entoure le mot «étage» de Salle et trace un trait jusqu à l attribut «lieu» de Place libre (Figure 5). CarbonX comprend qu il veut lier les deux attributs et lui propose alors de remplacer «lieu» par «étage» comme indiqué précédemment avec les mêmes conséquences. Page 6 sur 8

7 Figure 4 : Modification du concept Salle Figure 5 : Modification du concept Place libre Note Ce principe peut s appliquer de la même façon pour créer des dépendances entre des classes, entre des concepts, entre des attributs, ou toute combinaison de tout ceci. Par exemple, «tirer Page 7 sur 8

8 un lien» entre deux classes peut proposer de créer un héritage, une association, etc. Un lien entre un attribut et une classe peut créer une association, etc. Page 8 sur 8