| TODO NGPM Metamodel: |
| -------------------- |
| |
| - Class extends EventProducer, EventProducer has :1-assoc to |
| TypeDefinition for notification type: this won't fly because a class |
| can emit / produce more than one event type. How should this be |
| described? |
| |
| - Model pre/post conditions and play with it as a S&AM |
| replacement. Thoughts: This has an impact on extensibility and |
| grouping of conditions. The S&AM approach has this notion of a schema |
| as a grouping entity, spanning multiple actions and multiple status |
| variables / values. A pre/post condition centers around the individual |
| action. This makes recognizing the grouping provided by a schema much |
| harder. Extensions have to happen within the expressions on the |
| action. The benefit of this, however, is full visibility of the sum of |
| all applicable conditions for the action which may be harder with a |
| set of overlapping schemas affecting a single action. A pre/post |
| condition that purely consists of a boolean expression over equality |
| checks of enumeration-typed features against values of these |
| enumerations can be depicted as a S&AM schema. |
| |
| The next fundamental question is whether postconditions should be |
| expressed primarily as separate (redundant) constraints or be derived |
| from the implementation of the action. The action's implementation may |
| effect the values of one or more attributes. For those where the |
| attribute has an enumeration type, the connection from the action to |
| the target value would be part of the "derived" S&AM diagram. At |
| least, there should be a relation between the existance of a S&AM |
| transition from an action to a value of an attribute and a statement |
| reachable from the action's code on a reachable execution path that |
| sets that attribute to the respective value. |
| |
| - Investigate enums / code lists more closely. How to do value help and |
| content assist for those? Is an enum / value set just another class |
| declaration where the "literals" are the names of the association ends |
| pointing to the class itself for the literals / code list items? |
| |
| - What about handling of VOID expressions such as calling a block |
| that does not define an output type? |
| |
| - Take care of nested TypeDefinitions, e.g., in order to allow for |
| types such as nested "collections" that correspond, e.g., with |
| Set<List<SalesOrder>>. This entails respective modifications to the |
| conformsTo definition on TypeDefinition. |
| |
| - Allow for Block instances as values whose type is defined by the |
| block's Signature. Thoughts: a Signature then acts similar to a |
| Class. It defines the type of a value. SignatureTypeDefinitions define |
| value types, i.e., its objects are immutable and always passed by |
| value. |
| |
| |
| Example: |
| |
| class A { |
| int->A m; |
| B[ordered, unique] theBs; |
| C[ordered, unique][unique] setOfOrderedSetOfCs; |
| } |
| |
| class B { |
| } |
| |
| class C { |
| } |
| |
| |
| |