diff --git a/rapport/rapport.pdf b/rapport/rapport.pdf index d08252d..0015058 100644 Binary files a/rapport/rapport.pdf and b/rapport/rapport.pdf differ diff --git a/rapport/rapport.tex b/rapport/rapport.tex index 5518cd0..aa18443 100644 --- a/rapport/rapport.tex +++ b/rapport/rapport.tex @@ -139,13 +139,15 @@ Pour les modèles SimplePDL, nous contraignons les noms des Process au format ca context Process inv validName('Invalid name: ' + self.name): self.name.matches('[A-Za-z_][A-Za-z0-9_]*') + context WorkDefinition, Resource inv nameMin2Char: self.name.matches('..+') inv weirdName: not self.name.matches('([0-9]*|_*)') \end{textcode} -Pour ne pas avoir d'ambiguité dans le modèle, les noms des WorkDefinitions et des Ressources doivent être uniques: +Pour ne pas avoir d'ambiguité dans le modèle, les noms des WorkDefinitions et des Ressources doivent être uniques. \begin{textcode} +context Process inv uniqNamesWD: self.processElements ->select(pe | pe.oclIsKindOf(WorkDefinition)) ->collect(pe | pe.oclAsType(WorkDefinition)) @@ -167,26 +169,46 @@ inv successorAndPredecessorInSameProcess('Activities not in the same process : ' inv notReflexive: self.predecessor <> self.successor \end{textcode} - 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.) \begin{textcode} context Resource, Request inv negativeQuantity: self.quantity > 0 + context Request inv greedy: self.quantity <= self.target.quantity \subsection{petriNet.ocl} \end{textcode} -Les modèles PetriNet étant relativement similaireq aux modèles SimplePDL, nous avons établi des contraintes OCL similaires. +\subsection{petriNet.ocl} + +Les modèles PetriNet étant relativement similaires aux modèles SimplePDL, nous avons établi des contraintes OCL similaires. Nous obligeons le Network et les Node à avoir des noms uniques mais également sensés. +\begin{textcode} +context Network +inv validName('Invalid name: ' + self.name): + self.name.matches('[A-Za-z_][A-Za-z0-9_]*') +inv uniqNamesNode: self.nodes + ->forAll(n1, n2 | n1 = n2 or n1.name <> n2.name) + +context Node +inv nameMin2Char: self.name.matches('..+') +inv weirdName: not self.name.matches('([0-9]*|_*)') +\end{textcode} + Le nombre de jetons des Place et le poids des Arc doivent évidemment être positifs. +\begin{textcode} +context Place +inv negativeQuantity: self.tokens >= 0 +context Arc +inv negativeQuantity: self.weight >= 0 +\end{textcode} \section{Eclipse Modeling Framework (EMF)} -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 celui-ci convienne parfaitement à nos critères. -Ces plugins seront déployés dans une Eclipse Application séparée de notre Application principale pour ne pas mélanger métamodèles et modèles. +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. \subsection{plugin simplePDL}