Manual and Automatic Numbering

Shlaer-Mellor OOA uses numbers to help analysts identify various model elements. Some model elements use numbers as primary identifiers, e.g. relationships. While other model elements use numbers as secondary identifiers, e.g. objects, states, events, processes and synchronous services. Note that, OOA08 defines operations as a process and synchronous service supertype, generalizing process and synchronous service numbers as operation numbers.

If an object or relationship has been assigned to a subsystem then its number is restricted to the number range associated with that subsystem. These number ranges are typically assigned at intervals of 100, e.g. 1-99, 101-199, 201-299 etc. This helps analysts identify which subsystem an object or relationship is assigned to simply from looking at its number.

These numbering conventions were introduced in OOA91 at a time when there was minimal CASE tool support. They were designed to help analysts handle a mostly paper driven modelling process. OOA08 assumes a CASE tool is being used to capture and maintain models since OOA Tool has been implemented hand-in-hand with OOA08 as a cross platform reference implementation. The standard edition of this CASE tool is distributed freely to help promote the use of Shlaer-Mellor OOA/RD in a UML dominated industry.

OOA08 supports all of the numbering conventions used in OOA91. However, all of these numbers should by default be automatically allocated by your CASE tool. The CASE tool should also allow an analyst to override the automatic numbering so that previously defined models can still be captured and maintained. The CASE tool should also support and enforce subsystem number ranges.

OOA08 supports manual and automatic numbering by defining a naming attribute called Order of type Ordinal ID, a naming attribute called Manual Number and a mathematically dependent attribute called Number for each of the numbered model elements. The order attribute is automatically updated as a model element is reordered within the context of its parent model element. Ordinal ID attributes will be discussed along with Arbitrary ID attributes in a future post. The manual number attribute is maintained by the analyst (after manual numbering is enabled). The number attribute is derived from either the order attribute or the manual number attribute dependent on whether manual numbering is enabled. Deriving object and relationship numbers is more complicated since objects and relationships may be assigned to a subsystem. If that is the case then automatic numbers are derived from the subsystems lowest number offset by the assigned object or relationship order attribute which is distinct from the object or relationship order attribute. OOA Tool does not allow an analyst to define non-unique manual numbers.

The attributes in OOA08 which control each model element number are given below:

• object numbers are controlled by the Manual Object Numbering attribute defined on an object's parent information model,
• relationship numbers are controlled by the Manual Relationship Numbering attribute defined on a relationship's parent information model,
• state numbers are controlled by the Manual State Numbering attribute defined on a state's parent state model,
• event numbers are controlled by the Manual Event Numbering attribute defined on an event's parent event destination,
• and operation numbers are controlled by the Manual Operation Numbering attribute defined on an operation's parent event destination.

The fact that all operations have a parent event destination will be discussed in a future post.

OOA08 supports manual and automatic subsystem number ranges by defining the optional descriptive attributes Manual Lowest Number and Manual Highest Number along with the mathematically dependent attributes Lowest Number and Highest Number. The manual lowest and highest number attributes are maintained by the analyst. The lowest and highest number attributes are derived from the manual numbers dependent on whether the manual number range allows all objects and relationships to be allocated unique numbers within the specified number range. OOA Tool will automatically override the manual number range with a valid range if necessary to ensure all object and relationship numbers are unique.

Code Generation 2008 Conference

I attended the Code Generation 2008 conference this year to see what the state of the art was and to find out the status of Executable UML within the code generation community.

However, the focus of the conference was very much on Domain-Specific Languages (DSL). Before going to the conference I wouldn't have guessed that there would be so much interest in non-tool vendors creating their own programming languages to define their domain-specific configuration data. Various tool vendors demonstrated and talked about their DSL creation tools. Steven Kelly from MetaCase demonstrated their MetaEdit+® product. Steve Cook from Microsoft gave the keynote presentation on the final day. Their product is Microsoft DSL Tools for Microsoft Visual Studio 2005. Although it doesn't seem to be a mainstream product on their website, just some free components for an old version of their development tool. There were numerous talks on DSL plugins for the open source Eclipse tool including Eclipse Modelling Framework (EMF) and openArchitectureWare's Xtext. I was impressed with Xtext and its ability to define grammars and static semantics, allowing automatic code completion and constraint checking in a generic editor. I will have to evaluate whether any of its features should be incorporated into the Pattern Language used in OOA08.

Code generation from analysis models was really only discussed in Kennedy Carter's presentations and in several of the panel discussions. Chris Raistrick gave a tutorial on Executable UML. However, his talk was almost identical to the Shlaer-Mellor talks he gave more than 10 years ago at the Shlaer-Mellor User Group conferences that Kennedy Carter used to organise. I still enjoyed his talk since he's a great presenter. In fact, it was Chris who taught me Shlaer-Mellor OOA/RD in three 1 week courses over 15 years ago. The potential of the method has stayed with me since then. The only technology that I have come across with the same potential since then has been Java which I have also fully embraced. Allan Kennedy also gave a talk which was billed as an experience report but was actually an attempt to convince people of the merits of translation rather than elaboration. Unfortunately, an experience report would have more useful for the audience present.

What was sad after listening to Kennedy Carter's talks and speaking to them personally was the lack of vision they now have. They have embraced UML by promoting their version of Shlaer-Mellor OOA/RD as an Executable UML profile [xUML04]. This has allowed their company to do well in a UML dominated industry. Their technology works and I'm sure their customers are happy with the delivered systems. However, they have abandoned the vision they themselves promoted of an open marketplace for reusable service domains and software architectures. Reuse is what makes code generation from analysis models practical and affordable. Not reuse of assets within your own organisation. That benefit may come later. It is the immediate reuse of off-the-self assets that can make this approach viable for most companies. XMI does not allow Executable UML models to be interchanged between tools. I asked Chris whether Kennedy Carter would be prepared to make their tool interchange format publicly available and his answer was a definite no. They have made their action language [ASL03] openly available but this is not enough.

The most interesting panel discussion involving Executable UML was Goldfish Bowl: Modelling Standards: what exists, what's missing and what failed? This session was recorded and will hopefully be available on the code generation website in the future. Most of the discussion involved OMG standards, e.g. UML and XMI. Bran Selic who chaired the team responsible for the UML 2.0 standard, made it very clear that MDA is not a standard even through many people think it is. There was a consensus within the goldfish bowl that UML 2.0 is inconsistent and incomplete. Bran reinforced this conclusion by mentioned that an unnamed company recently spent 1 million dollars trying to build a compliance suite for UML. The effort was apparently a complete failure due to problems with the standard. The point was also made that these issues probably couldn't be fixed because there are too many vested interests and too much user momentum behind the current standard. The failure of XMI as a UML interchange format was also discussed. Bran suggested that customers haven't made this a priority with tool vendors and until they did interoperability probably wouldn't improve. Bran also indicated that UML should evolve into an executable UML. However, he seemed to disown the current Executable UML offerings from Kennedy Carter and Mentor Graphics. He even suggested that Executable UML was a failure during questions in the final keynote presentation by Steve Cook.

This year's conference was interesting and well worth attending. My thanks to Mark Dalgarno and his team for organising it. I would also like to thank all the speakers for their contributions. Barring any scheduling conflicts I will try to attend next year.

Participant Roles

Binary relationships and subtype-supertype relationships are defined between participant objects in information models. Binary relationships have two main participants and one optional associative participant. The associative participant object can't be either of the main participant objects in a binary relationship. However, the main participant objects may be the same object, i.e. when the binary relationship is a reflexive relationship (discussed in OOA96). Subtype-supertype relationships have one supertype participant and two or more subtype participants. A specific object can't participate more than once in a subtype-supertype relationship.

To identify a particular participant you need the relationship and object involved. However, you also need additional information to distinguish between the main participant objects in a reflexive relationship. The verb phrases associated with the main participants can be used to distinguish between them in a asymmetric reflexive relationship. However, verb phrases can't be used to distinguish between main participants in a symmetric reflexive relationship (introduced in OOA96). Several existing action languages use verb phrases to help identify participants in relationship navigation expressions. Obviously, this is not sufficient for symmetric reflexive relationships.

OOA08 formalizes the concept of participant role so that verb phrases don't need to be used to help identify participants. Participant roles include first, second, associative, supertype, and subtype. The first and second roles arbitrarily denote the main participants in a binary relationship. The associative role denotes an associative participant. The supertype and subtype roles denote a supertype and subtype participant respectively.

OOA08 initially defined all of these roles as literal values. However, the first and second roles can now be changed allowing short role names to be associated with the main participants of a binary relationship. In practice, participant roles are only used with reflexive relationships. In asymmetric reflexive relationships, the roles should be self evident, e.g. the roles client and server are used in the reflexive relationship between Domain objects formalized by the associative Bridge object (from OOA of OOA). In symmetric reflexive relationships, the default first and second roles should be used.

Polymorphic Events

OOA96 introduced the concept of polymorphic events into Shlaer-Mellor OOA. It allows a supertype object to define a polymorphic event which is mapped to events associated with subtype object lifecycle models. A polymorphic event is generated without the need to know which subtype object is associated with the polymorphic event's supertype object. A mapped event is either a lifecycle model transition event (known as a true event) or another polymorphic event where the subtype object is itself a supertype object in another subtype-supertype relationship. Obviously, mapped events can't be assigner model events or creation events since a supertype and subtype object instance must exist for a polymorphic event to be routed. Polymorphic events and their corresponding true events may or may not have the same meaning.

OOA08 defines a new type of event destination called a polymorphic destination for encapsulating a set of polymorphic events associated with a specific subtype-supertype relationship. It defines the label prefix for a polymorphic destination as the subtype-supertype relationship ID followed by a -P suffix, e.g. R2-P. This eliminates the need in OOA96 to use a * suffix when referencing polymorphic events since the -P suffix performs the same function. Polymorphic destinations are the only event destinations that do not appear on communication models. However, true events do appear on communication models with a prefix indicating the polymorphic event which is routed to the true event, e.g. R2-P1 → CA2: Perform task. OOA08 uses a right arrow rather than the equals specified in OOA96 since an equals suggests a bidirectional relationship which doesn't exist.

Since polymorphic events are associated with a subtype-supertype relationship rather than a supertype object in OOA08, a polymorphic event always results in one and only one true event being generated. A polymorphic event in OOA96 (and Executable UML [xtUML02]) results in one and only one true event being generated per subtype-supertype relationship that the polymorphic event's supertype object participates in. However, Kennedy Carter (for Executable UML [xUML04] and Shlaer-Mellor before this) defines significantly different semantics for polymorphic events. They allow a polymorphic event to be received by all state models in the subtype-supertype hierarchy including the initial supertype object. Furthermore, they require that any actions that are performed in a supertype object complete before the polymorphic event propagates down into subtype objects. This definition of polymorphic events is not supported in OOA96, OOA08 or OOA Tool.

A simple example model showing polymorphic events in action is given below, starting with the Object Information Model:

the State Transition Diagram for Main next:

followed by the State Transition Diagram for Child A:

and Child B:

and finally, the Object Communication Model showing communications between Main, Child A and Child B:

Attribute Conditionality

OOA91 requires all attributes associated with an object instance to have one and only one value (see first rule of attribution on page 19). However, OOA91 allows these values to be accumulated over time in a lifecycle model (see page 61). Thus, some attributes may not have a value at certain points in time. OOA08 formalizes this property of attributes as conditionality. An attribute must always have a value if it is not conditional, whereas, an attribute may or may not have a value if it is conditional. A (1c) suffix may be used to label attributes which are conditional.

A simple attribute is conditional only if the attribute is explicitly made conditional by the analyst, i.e. by setting Manual Conditional status. Obviously, a simple attribute with an initial value that is final is never conditional. A mathematically dependent attribute is conditional if its value calculation code is not guaranteed to calculate a value or if the attribute is explicitly made conditional by the analyst. A referential attribute is conditional if its associated base attribute is conditional, or if all navigation paths from the referential attribute to the base attribute are conditional or if the attribute is explicitly made conditional by the analyst. Obviously, a referential attribute with a literal value is never conditional. A polymorphic attribute is conditional if any of its true attributes are conditional or if the attribute is explicitly made conditional by the analyst.

Associating an initial value with a conditional attribute still makes sense since OOA08 allows a conditional attribute to be cleared. An attribute with no current value contains a special UNDEFINED (but typed) value. A non-conditional attribute with no associated initial value will be initialized with the default value (if there is one) of the attribute's associated data type when an object instance is created. A conditional attribute with no associated initial value will not be initialized even if there is a default value.

OOA08 (and OOA Tool) requires all Action Language code to strictly obey conditionality constraints. When an object instance is created, all non-conditional attributes must be assigned a value within the enclosing action (if they don't have an initial or default value). If the enclosing action is modelled using a process model then all non-conditional attributes must be assigned a value within the enclosing accessor process (an accessor can access multiple objects in OOA08). This is a much stricter requirement than OOA91 which allows conditionality constraints to be satisfied within actions triggered by events sent from the original enclosing action. The problem with OOA91 is that there is no easy way to determine when conditionality constraints are broken. OOA08 takes the view that conditionality constraints are only useful if they are enforceable.

Mathematical Dependence

OOA96 added the concept of mathematical dependence and mathematically dependent attributes to information modelling. Such attributes are annotated with an (M) suffix and are known as derived attributes in most other object-oriented methods (including Executable UML). Although the term mathematically dependent is a mouthful and the alternative term derived is much easier to use, it does allow us to distinguish between the analysis and design/implementation concept of derived.

When mathematically dependent attributes are calculated depends on the software architecture. They may be calculated on demand, i.e. whenever their value is accessed. Alternatively, they may be calculated whenever their dependent attributes change and then cached for instant access when needed. However, Recursive Design in OOA08 allows attribute updated mappings to be created in bridges that execute action language code whenever an attribute changes. If such a mapping is made from a particular mathematically dependent attribute then the second approach must be implemented for that attribute.

OOA08 also allows mathematically dependent relationships which are a new type of binary relationship formalized using action language code. Code needs to be provided for navigation in both directions. This code is given an instance of the source participant and returns a set of corresponding instances of the target participant. Using mathematically dependent relationships, analysts can now define composed relationships of the form R1 = R2 - R3 etc.

Referential Attributes

Referential attributes are used to formalize binary and associative relationships. All objects should have one or more identifiers each of which is composed of one or more identifying attributes. Any attribute on an object can be identifying. It is common for identifiers to be composed of more than one identifying attribute. Some analysts get lazy and create arbitrary ID identifiers everywhere but I try to avoid them whenever possible. To formalize a one-to-one or one-to-many binary relationship between two objects (or participants), a target identifier is chosen on one object and a set of referential attributes are chosen (or added) to the other object where each referential attribute is mapped to an identifying attribute of the target identifier. These referential attributes can't be set directly by the analyst, they exist only as a by product of a relationship instance existing. A referential attribute may be used in many participant mappings each of which is annotated in the referential suffix.

OOA08 (and OOA Tool) fully supports the use of referential attributes to formalize binary and associative relationships. However, OOA08 requires all referential attributes be resolvable to a single base attribute (non-referential and non-polymorphic). This wasn't an explicit requirement in OOA91 or OOA96. An analyst could keep a model consistent by using the same data type (or attribute domain) for overlapping referential attributes. However, in my experience it is always possible to resolve overlapping referential attributes to a single base attribute and the resulting model is always more complete.

As a result of this requirement, all referential attributes have a base attribute status of either:

• Unresolved indicating that there is no path from the referential attribute to any base attribute,
• Partially Resolved indicating that there is a path from the referential attribute to a base attribute but that there are also other non-circular paths which don't lead to a base attribute yet,
• Fully Resolved indicating that all paths from the referential attribute lead to a single base attribute (ignoring circular references),
• Incompatible indicating that one or more paths from the referential attribute lead to a base attribute with a data type that doesn't match the manual data type associated with this attribute (which can't happen if a manual data type is not specified),
• Multiple Base Attributes indicating that one or more paths from the referential attribute lead to multiple base attributes (whether they have the same data type is not relevant in OOA08),
• and Only Circular References indicating that all paths from the referential attribute are circular in nature.

The example above should help illustrate the different base attribute statuses. Attribute A1 is Unresolved since it is declared as referential but doesn't appear in any participant mappings. Attribute A2 is Unresolved since although it references Attribute B1, that attribute is Unresolved. Attribute A3 is Partially Resolved since although it references Attribute B2 which is a base attribute, it also references Attribute C1 which is Unresolved. Attribute A4 is Fully Resolved since it only references Attribute D1 which is a base attribute. If Attribute A4 had a manual data type of Integer and Attribute D1 had a manual data type of String then Attribute A4 would have an Incompatible status instead. If Attribute C1 was a base attribute rather than a referential attribute then Attribute A3 would have a Multiple Base Attributes status instead. If Attribute B1 formalized relationship R4 then both Attribute A2 and Attribute B1 would have a Only Circular References status.

Circular references are common when composed identifiers are used, i.e. the identifiers for a set of related objects may all have a common identifying attribute. Having circular references is not a problem unless there are only circular references. However, once a referential attribute with this problem has been identified, it can normally be easily fixed, i.e. a set of related objects with a common identifying attribute implies a relationship should exist to an object defining the common attribute as a base attribute. There are situations that appear to be correct but which still have referential attributes with only circular references, i.e. when an identifying attribute which should have been a base attribute has become a referential attribute. However, an analyst should always be able to determine the home object of a referential attribute and if that attribute is not a base attribute, the analyst should make it a base attribute by separating the referential duties off into another attribute and noting the constraint.

The algorithm for resolving base attributes is highly iterative because referential attribute mappings form arbitrary graphs which may be cyclic, i.e. they may include circular paths. The algorithm is briefly outlined below:

1. Add all referential attributes to a set of unresolved referential attributes
2. Loop thru the set of unresolved referential attributes until a complete iteration occurs without resolving a single referential attribute
   • Attempt to resolve the base attribute and base attribute status of each referential attribute using previously resolved referential attributes (or previously determined true attributes for polymorphic attributes) while checking for error conditions at the same time
   • If any unresolved referential attributes are referenced by this attribute then skip the resolution of this attribute for now
   • A base attribute status can be resolved if all references from this attribute are non-referential attributes, previously resolved referential attributes or if an error condition can be detected without the need to completely resolve all references from this attribute, e.g. for Incompatible or Multiple Base Attributes error conditions
   • If a base attribute status can be resolved then remove this attribute from the set and perform another complete iteration of the unresolved referential attributes after this iteration completes
3. If the set still contains unresolved referential attributes then a final iteration thru the set is made re-enter the above loop, except that references to unresolved referential attributes are treated as circular references and ignored
4. Any unresolved referential attributes after this final iteration are all given the base attribute status of Only Circular References

The data type of a referential attribute is determined from the resolved base attribute. However, a manual data type can be specified for a referential attribute for consistency checking purposes. An error condition will be flagged if the resolved base attribute's data type doesn't match the manual data type.

The conditionality of the referential attribute is determined from the resolved base attribute's conditionality along with the navigation conditionality across all the paths to the resolved base attribute. This can also be weakened by specifying a manual conditionality for the referential attribute. Further discussion of attribute conditionality will be left for another day.