Nous avons ensuite dû choisir une manière de modéliser les ressources nécessaires au processus de développement.
Notre choix de modélisation s’est porté sur : une Ressource (qui implémente ProcessElement) est demandée par le biai d’une Request elle-même générée par une WorkDefinition.
On se retrouve donc avec un nouveau modèle Ecore de la forme :
Les relations Ressource-Request et Request-WorkDefinition sont déclarées en EOpposite pour pouvoir facilement passer d’un fils à un parent et vice versa.
Le modèle SimplePDL est maintenant complet pour représenter des processus de développement.
Un exemple complet d’utilisation de ce modèle serait :
En se basant sur ce que l’on a vu pour le modèle SimplePDL, nous avons créé un modèle Ecore permettant de modéliser les réseaux de pétri.
Nous avons modélisé un réseau comme étant composé de nœuds.
Ces nœuds peuvent être les places ou des transitions.
Ils sont donc nommés et reliés entre eux par des arcs.
Ses arcs ont un attribut entier nommé weight pour indiquer le poids de l’arc ainsi qu’un boolean outgoing pour indiquer si ce dernier est dirigé d’une Place vers une Transition ou d’une Transition vers une Place.
(Si outgoing est vrai, alors l’arc va de la transition vers la place.)
Pour les modèles SimplePDL, nous contraignons les noms des Process au format camelCase. De même les noms des WorkDefinitions et des Resources doivent posséder au minimum 2 caractères et ne pas être exclusivement constitués de chiffres ou d'underscores.
Nous avons aussi contraint l’utilisateur à utiliser les WorkSequence sur des WorkDefinition appartenant au même Process. Pour éviter des non-sens, les WorkSequence ne peuvent pas non plus avoir le même successeur et prédécesseur.
\begin{textcode}
context WorkSequence
inv successorAndPredecessorInSameProcess('Activities not in the same process : '
+ self.predecessor.name + ' in ' + self.predecessor.process().name+ ' and '
+ self.successor.name + ' in ' + self.successor.process().name):
Nous avons aussi ajouté des contraintes sur les quantités des Resource et Request.
En effet, cela n’a pas de sens d’savoir des Resource ou des Request avec des quantités négatives. De plus, une Request ne peut pas être plus grande que le nombre initial de ressources. (Le nombre initial de ressources est le maximum puisqu’il n’y a pas de création.)
Pour permettre une meilleur intégration de nos métamodèles dans notre environnement de developpement (sous Eclipse), nous pouvons créer des greffons nous permetttant de les intégrer dans d'autres projets, ainsi que des éditeurs arborescents nous permettant de mieux visualiser/éditer des modèles conformes à nos métamodèles Ecore.
Le code java de ces éditeurs arborescent est engendré par nos métamodèles Ecore, mais nous pouvons le modifier manuellement pour que ceux-ci conviennent parfaitement à nos critères.
Ces plugins seront déployés dans une Eclipse Application séparée de notre environnement de developpement principale pour ne pas mélanger métamodèles et modèles.
Il nous est possible de transcrire nos modèles vers d'autres formats de fichiers pour nous permettre de les utiliser dans logiciels tierces, et ainsi de les modifier/visualiser plus aisaiment.
Tout comme lors de la création d'éditeurs arborescent spécifiques à nos métamodèles (cf EMF), il nous est possible de créer des éditeurs graphiques spécifiques à nos métamodèles.
Dans la continuité de la création d'outils pour manipuler et visualiser nos modèles, il nous est possible de définir une styntaxe textuelle associée à nos métamodèles.
Ainsi, pour simplePDL, la syntaxe textuelle suivante permet de manipuler nos modèles, sans passer par des outils complexes générés automatiquement par Eclipse.
Finalement il nous est possible, tout comme lors de la transformation modèle à modèle via l'écriture d'un programme, de transformer un modèle selon un autre métamodèles via l'outil ATL.
