@Retention(value=RUNTIME)
@Target(value=PACKAGE)
@Documented
public @interface Model
Represents: model
Usage:
Apply on the top package of a JtxtUML model. Annotations on packages should
be defined in package-info.java
file.
Set 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.
String
s.ExternalClass
. See the documentation of
ExternalClass
for details.java.lang.Object
).
abstract class
es.synchronized
, native
or
abstract
methods, using synchronized
blocks.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:
ExternalClass
), and then the model is
accessed from that method (on the executor's thread).
For details about the second case, see the documentation of
ExternalClass
. 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):
Action
class and its static methods.ModelClass.assoc
method, using the result through the Collection
interface.ExternalClass
to bring external features into
the model or to communicate with components of the program that are not part
of the model.
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 and conditions
of certain Collection
methods ( Collection.selectAll(java.util.function.Predicate<T>)
).
A condition evaluation is exported as a single model query, so it may include only the following actions:
ModelClass.assoc
method.Sting
).Collection
instances with methods of that type or its
subtypes. (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.
ModelClass
,
Association
,
Signal
Modifier and Type | Optional Element and Description |
---|---|
java.lang.String |
value
Sets the name of the model.
|