-
Notifications
You must be signed in to change notification settings - Fork 9
Marking
The following describes the available marks and how to use them.
Marks are defined using comma separated values in the application.mark file.
Available features are defined using comma separated values in the
features.mark file. This file must be present and populated for marks to be
loaded properly. The master version of this file can be found at
features.mark.
Marks in application.mark are in the format:
<path>,<mark_name>,<markable_type>,<value>
where <path> is a unique identifier for the element you desire to mark,
<mark_name> is the name of the feature, <markable_type> is the xtUML element
type marked, and <value> is the value passed in to the feature.
A * for the path denotes all elements of that type. A * for the path
and for the markable type denotes a system-wide mark.
|
Note
|
BridgePoint includes a marking editor for editing application.mark
files. Unfortunately, BridgePoint does not include the wildcard (*) which
the Ciera marking mechanism uses. Perhaps BridgePoint can be extended in the
future to support Ciera style marks.
|
By default the application Java class (entry point for the application) is
named <project_name>Application where <project_name> is the name of the
xtUML project with spaces removed and each word capitalized. For example the
application name for a project called "my project" would be
"MyProjectApplication". If you would like to change this default behavior, add
the following to your application.mark file.
*,ApplicationName,*,<app_name>
ex: *,ApplicationName,*,CoreTool
where <app_name> is your custom name.
By default the application Java class is generated into a top level package
called <project_name> where <project_name> is the name of the xtUML project
with spaces removed and all lower case. For example the package name for a
project called "my project" would be "myproject". If you would like to change
this default behavior, add the following to your application.mark file.
*,ApplicationPackage,*,<package_name>
ex: *,ApplicationPackage,*,io.ciera.tool
where <package_name> is your custom package location.
The root package is the package that is the translation unit for the compiler.
This mark is required. If it is missing, no code will be generated. Add the
following to your application.mark file.
*,RootPackage,*,<package_name>
ex: *,RootPackage,*,MicrowaveOven::components
where <package_name> is the double colon delimited path to the xtUML package
you want to translate (including the project name as the first path segment).
Ciera does not guarantee order of selected instance sets, however an attribute
can be configured as the global sort comparator. For any selection, if the class
has an attribute by that name, it will be used to sort the result set in
ascending order. This is mostly useful for model compilers when you want
elements to have a consistent order on each code generation. Ciera itself uses
this feature to support all named elements by the attribute "name". Add the
following to your application.mark file:
*,SortComparator,*,<attribute_getter>
ex: *,SortComparator,*,getName
where <attribute_getter> is the name of the generated getter method for the
attribute. Note that this mark can be configured to be any method on the
generated classes — it could be configured to sort based on the return value
of an instance operation.
Ciera supports simulated time. For more detail about how simulated time affects
application behavior, see Features: Simulated
time. To enable simulated time for a component, add the following to your
application.mark file:
<component_name>,EnableSimulatedTime,Component,true
ex: components::MicrowaveOven,EnableSimulatedTime,Component,true
where <component_name> is the double colon delimited path to the xtUML
component (not including the project name).
|
Warning
|
although this is a per component feature, Ciera does not yet support separate tasks for individual components. Therefore, if any component in a system is marked with simulated time, they will all operate in simulated time. |
Components can be marked with exactly one initialization function that will
execute after the system is set up, but before any events, messages, or timers
are handled. This is typically used to "kickstart" an application, however
components do not necessarily need one if they are designed without any instance
population setup needed or are configured at the time of the first external
stimulus. To mark an initialization function, add the following to your
application.mark file:
<component_name>,InitFunction,Component,<function_name>
ex: components::MicrowaveOven,InitFunction,Component,init
where <component_name> is the double colon delimited path to the xtUML
component (not including the project name), and <function_name> is the name of
the xtUML domain function. The function name must be unique within the component — Ciera does not support domain functions with identical names even in
different packages.
Ciera provides a default scheme for versioning generated components when using
the Maven build plugin, however the version identifier can be overridden. To
configure a custom version identifier, add the following to your
application.mark file:
<component_name>,Version,Component,<version>
ex: components::MicrowaveOven,InitFunction,Component,v1.0-pre-release
where <component_name> is the double colon delimited path to the xtUML
component (not including the project name), and <version> is the custom
version identifier.
|
Note
|
Ciera will still include a generated timestamp with the version, even if the main version identifier is overridden |
Ciera allows unused model elements (classes and associations) to be marked for
exclusion. This can be useful if you are including a subsystem from another
project as a package reference and are not using part of the model. See
Features: Exclusions to read about the behavior and
limitations of this feature. To configure exclusions, add the following to your
application.mark file:
<path>,Exclude,Model Class,true <path>,Exclude,Association,true
ex: ooaofooa::Domain::Enumerator,Exclude,Model Class,true ooaofooa::Domain::R20,Exclude,Association,true
where <path> is the double colon delimited path to the xtUML class or
association (not including the project name).
Ciera uses the modeled class name to generate the Java class name for each
generated class. Spaces are removed and the first letter of each word is
capitalized. If a class name is not suitable (e.g. it would clash with a Java
reserved name), the key letters can be used as the generated class name. To
confiugre a class to use the key letters as the name, add the following to your
application.mark file:
<path>,UseKeyLettersForName,Model Class,true
ex: architecture::statement::Break,UseKeyLettersForName,Model Class,true
where <path> is the double colon delimited path to the xtUML class (not
including the project name).
Ciera allows users to provide their own implementations for ports. See
Features: Custom IPort
implementation to read about the behavior and limitations of this feature. To
configure exclusions, add the following to your application.mark file:
<path>,BaseClass,Port,<class_name>
ex: Tracking::Tracking::UI,BaseClass,Port,HttpPort
where <path> is the double colon delimited path to the xtUML port (not
including the project name), and <class_name> is the name of the base class
for generated ports.
|
Warning
|
The marked base class must either be a fully qualified class name or it must be defined in the same package into which the port will be generated. |
Marks specifically related to instance loading, templating, and experimental features will be covered in Persistence, Templating, and Experimental Features respectively.