|
With the Petri net type definition for YAWL nets of
Assignment 5, it is still possible to create
nets that are not really YAWL nets. For example, it is possible to create
an arc from a place to a place or from a transition to a transition, and it is possible that
a net has no or more than one start and end place. In this assignment, you
will define additional constraints on the Petri net Type Definition for YAWL
in order to exclude this.
NB: Note that the above constraints are only two examples of what could
go wrong. For the project,
you need to add some more constraints (e.g. start places should have no incoming
arcs and end places should have no outgoing arcs); think carefully about which
additional constraints you would need for YAWL nets.
Moreover, you will get acquainted with ePNK applications by creating a very simple
simulator for YAWL nets.
In this tutorial, you will learn how to
- add an OCL constraint (see also lecture 7)
that makes sure that, in YAWL nets, an arc
connects a place with a transition or a transition with a place only,
- implement and add more complex constraints in Java, and
- learn the difference between batch and live constraints
(see also lecture 7).
- Moreover, you will get acquainted with the concepts and components of
ePNK applications.
Section 4.5.1.4 (pp. 102—106) and Section 4.5.3.3 (pp. 116— 119) of the
ePNK: Users' and Deveopler's Guide provide
detailed information and examples on how to add OCL and Java constraints to
PNTDs that are plugged in to the ePNK. Section 5.2.3 (pp. 163–166) and Section 5.3.5 (pp. 197–221)
of the
draft of a revised and extended ePNK Manual for version 1.1 provide
detailed information and an example on how to realize an ePNK application such as an simulator
for some Petri net type.
- First, you should add an OCL constraint stating that an arc can run from a
place to a transition or the other way round only — but not between
two transitions or two places. Moreover, arcs from a transition to a place
cannot be a reset arc; the easiest way to achieve this is saying that
for a YAWL arc from a transition to a place the type attribute should not
be set at all.
The constraint could look something like this (see lecture 7),
assuming that "type" is the name of the reference from the arc
to its type attribute:
( self.source.oclIsKindOf(pnmlcoremodel::PlaceNode) and
self.target.oclIsKindOf(pnmlcoremodel::TransitionNode) )
or
( self.source.oclIsKindOf(pnmlcoremodel::TransitionNode) and
self.target.oclIsKindOf(pnmlcoremodel::PlaceNode) and
self.type->size() = 0 )
In addition, the constraint needs to be configured: we need to "tell" the Eclipse
Validation Framework
on which objects the constraint should be applied. In our case, the constraint
should be applied to YAWL arcs. Moreover, we need to "tell" Eclipse whether
it is a live constraint or a batch constraint. Live constraints are automatically
checked whenever "something" changes, batch constraints are checked only
when a validation is explicitly invoked (typically, by the end-user pressing
the validate button). Live constraints can be used to prevent the user
from making any invalid change; any change will be rolled back if it results
in a state violating a live constraint. This is what we would like for the
constraints on the
arcs. But, some constraints (typically, the more "global" ones, which concern
many or even all elements) cannot be live
constraints, because it might require several editing steps to make a model
consistent again. One example is the requirement on start and end places (see 2.).
In EMF, all this configuration information is provided by plugging in
a constraint provider for some constraint category, which in the case of
the ePNK is org.pnml.tools.epnk.validation.
You will find a snippet, of such an extension in
plugin.xml,
which you need to slightly adjust (see comments
in the snippet) to your project settings; this adjusted snippet
needs to be added to the plugin.xml of the project with your YAWL
model from
Assignment 5. The concepts and different parts
of this snippet are explained in lecture 7.
NB: In principle, a constraint provider extension can be defined in any plugin
project. But, constraints are conceptually part of the model; therefore, constraint
provider extensions are typically defined in the same plugin project as
the underlying model itself.
Check whether your constraint works by starting the runtime workbench and
creating a YAWL net in the ePNK editor (try to create "illegal arcs" and
see whether their creation is prevented).
NB: As discussed in the lectures, the syntax of OCL is a bit tricky.
When creating your own OCL constraints,
I suggest that you use the "Interactive OCL" console in Eclipse to check
the correctness of the syntax of your constraints. To this end, you
need to install the "OCL Examples and Editors SDK" from the Eclipse Neon update site
(see Screencast 7c or slides 37ff of
lecture 7 on how to install
the "Interactive OCL" console and how to use it).
- Next, you should add a constraint that makes sure that a YAWL net has exactly
one start place and exactly one end place. Formulating this constraint in OCL is quite
tricky and it might be easier to program this constraint in Java, basically
iterating over all the objects contained in the net, counting all its start and
end places. This can be done by implementing a class extending
AbstractModelConstraint with a validate() method. Since
this constraint, conceptually, is a part of the model, this class should
be added to the project from Assignment 5
with your YAWL Net model.
Before you implement this class, add a dependency to the project
org.eclipse.emf.validation in your project from
Assignment 5 (double-click on plugin.xml
and use the tab "Dependencies" to add it to the "Required Plug-ins").
Then, you can use the template from
StartEndConditions.java in some
dedicated Java package in your YAWL plugin project, to actually implement counting start
and end places.
At last, you need to plug this Java class in as a constraint as
indicated in the snippet provided in
plugin.xml
(which needs to be slightly adjusted as indicated
by TODO comments). Note that this constraint is technically required for
the class representing the YAWL Net type, and it is configured as a batch
constraint, since it cannot be true all the time, but should be true in the
end.
- After you have created and plugged in both constraints, start the runtime
workbench (see Screencast 7a).
Create a PNML document with a YAWL net, and edit it. Test
which kind of arcs you are allowed to create; and test to change the
arc type attribute for incoming and out-going arcs of a transition. It should be impossible
to create arcs between two places or between two transitions; moreover,
it should be impossible to create and change the type attribute of
arcs starting at a transition.
For checking the constraint for start and end places, you would need to
explictly invoke the validation in the tree editor for Petri nets (right-click
-> Validate). The first time you validate, you will probably get lots of
errors reported since the Petri net objects are missing ids. You can fix that
by double-clicking on the top-level element Petri Net Doc
in the tree editor.
If you validate again, the validation should correctly report the status
of start and end places. Try to validate correct and incorrect YAWL nets
(with too many, too few start and end places, and try one with exactly
one start and end place).
- At last, try to get acquainted with the concept of ePNK applications. To this end,
have a look at the project
org.pnml.tools.epnk.tutorials.app.simulator,
which you had imported in Step 1 of Assignment 6, and
inspect the different classes.
Actually, you should try to convert this project into
a very simple simulator for YAWL nets (not yet taking OR and XOR joins and splits
and RESET arcs into account). For making this easier for you, you can
import a renamed and adjusted project
YAWL-sim-template.zip to your Eclipse (development) workspace.
Note that this project still has a dependency to and uses some parts of
org.pnml.tools.epnk.tutorials.app.simulator, which you should eventually get rid of.
You also need to add a dependency to
your project from Assignment 5 and adjust and add some imports
and add and fix some code (which is marked with TODO).
Before fixing the java classes, add the dependency to your YAWL project from
Assignment 5 to your project (in the plugin/MANIFEST
editor). Then, add the missing imports
for class Place and the other missing Petri net elements classes, so that you import the
respective
classes from your project in all Java classes (this is best done by hovering
the mouse over the classes that cannot be resolves). After that, fix the remaining
problems (the TODO comments indicate what you need to do in order to fix these
problems and adjust the code to your YAWL nets).
Try out the simulator one of your YAWL net examples by starting the runtime workbench of
Eclipse. Open the net in the graphical editor, and then start the YAWL simulator
application from ePNK application view.
NB: Note that this is a bit dirty hack, and just a quick (and dirty)
way to get something like a YAWL simulator running. Most importantly, you will
get some basic idea of how ePNK applications work. With this knowledge, you will start
over again in tutorial 8 (which will provide much more details on
ePNK Applications).
|
