rapport: fin des ocl

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}