-
Notifications
You must be signed in to change notification settings - Fork 9
Restrictions_Limitations
Since Ciera was first developed pragmatically as a personal side project, its design and implementation was not driven by the same requirements as a "production" model compiler — pieces were implemented little by litte as needed by the few applications it was used to translate. This chapter describes the main restrictions and limiations of Ciera. Other restrictions are peppered throughout the user guide where it was natrual to discuss them.
Ciera makes no attempt to correct or flag model element names which may cause compilation errors. Users should avoid choosing model element names which may conflict with Java reserved words, built in classes, or other model elements.
Specific cases to avoid:
-
Names that would conflict with Java reserved words such as "enum", "public", "while", etc.
-
Names that would conflict with built in Java language classes such as "String", "Exception", etc.
-
Naming different types of model elements with the same name (e.g. a port named the same as a class or an EE named the same as a datatype).
A more formal analysis of meta-model coverage has been performed and can be accessed online Engineering Documentation: 11844_Coverage.
Ciera only supports asynchronous interface singals. Interface operations are not supported. Modelers must design their applications to be asynchronous and operate without relying on synchronous operations across component boundaries.
State machines are the area of greatest weakness for Ciera. While technically any desired behavior can be achieved with the current support, many model constructs are missing.
Ciera does not support class-based state machines. To achieve the same result, a modeler must create a new singleton class to act as assigner. Corollary to this, signal events are not supported. OAL actions must be written to "forward" events to the appropriate instance state machine to emulate this pattern
Ciera does not support creation events. Instances must always be created synchronously. It is trivial to achieve the same effect by creating an instance with a create statement and then subsequently generating an event to the new instance. Sometimes it is necessary to create a dummy start state to represent the non-existent state.
Ciera does not support polymorphic events. Modelers must manually "pass down" events by having a switch like statement in the super type state machine to generate an event to the correct subtype.
-
Ciera does not support structured data types
-
Ciera does not support declaring ranges on user defined types
Deployments are an alternative style system modeling scheme introduced to meet the needs of the MASL community. Ciera supports the component system modeling paradigm and does not provide any support for deployments.
-
Ciera does not support derived associations
-
Ciera does not support delegations
-
Ciera does not support exceptions
-
Ciera does not honor default values on attributes (attributes are always initialized with the type default value)
-
Ciera does not support baseless referential attributes
-
Ciera does not support passing parameters by reference
If you are running into a problem, be sure to check the issue tracker for known bugs.
< next: Features | next: Marking >