@Retention(value=RUNTIME) @Target(value=PACKAGE) @Documented public @interface Model
Apply on the top package of a JtxtUML model. Annotations on packages should
be defined in
value to define a unique name of the model.
If package A is marked as a model and B is a subpackage of A then B cannot be marked to be a model as it is already a part of one.
If a package is marked as a model then all
.java files in that
package and its subpackages are considered parts of the model and therefore
should be valid model elements.
A JtxtUML model is always a valid Java source but it must apply to other restrictions and requirements as well. All these special rules are detailed at the corresponding pages of this documentation.
A JtxtUML model consists of a package structure under one particular package
that has to be annotated with
Model. All parts of the model must be
implemented as contents of this package or its subpackages. As a general
rule, the model may not refer to or use any code in any
way that is from outside this package structure, with a few exceptions,
described below, in the 'Global Java restrictions' section.
APItypes which cannot be used.
A JtxtUML model may never run by itself. It has to be managed or at least started from the outside. As model executors use their own threads, there are two main cases of accessing the model from the outside:
In the first case, when the model is accessed from another thread, only a
small set of safe operations can be done which are listed in the
API class. This class cannot be used from the model but its static
methods are the only ones which can be called from any other thread.
This section is for some important definitions about JtxtUML which are referenced throughout this documentation.
Java code blocks that contain JtxtUML action code may contain any Java code that follows the rules set in the 'Global Java restrictions' section.
The most important features of the JtxtUML action language (the following list is not restrictive):
Actionclass and its static methods.
ModelClass.assocmethod, using the result through the returned collection type.
A condition evaluation in JtxtUML is a Java code block which aims to create a
boolean value that represents whether a certain condition about
the model (which condition the block represents) holds or not.
Condition evaluations in JtxtUML include
guards of transitions.
A condition evaluation is exported as a single model query, so it may include only the following actions:
GeneralCollectioninstances with the
Action.collectIn(java.lang.Class<C2>, E...)methods or methods of the collection types. (As all such instances are immutable, this does not affect the state of the model in any way.)
An execution step starts when an asynchronous event (like a signal event) is chosen by the executor to be processed and ends when that event and all the synchronous events caused by it (like a state machine changing state, entry and exit actions, transition effects, operation calls) have been processed.
|Modifier and Type||Optional Element and Description|
Sets the name of the model.