Domain Chart Notation

This is the first of a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers Domain Charts which are used to show the domains and bridges used to model a project and realize a system.

OOA Tool (Build 012 onwards) supports switchable notation on projects and individual diagrams. Users can switch between:

• Shlaer-Mellor (OOA08 notation),
• Executable UML (xtUML notation [xtUML02] which is UML1 based),
• and Executable UML2 (a UML2 [UMLManual05] based variant of xtUML notation).

OOA Tool does not support the xUML notation [xUML04] from Kennedy Carter.

Below is an example Domain Chart in Shlaer-Mellor notation taken from [OOA91] (see page 2 and 134):

Domains are represented using ellipse shapes containing the domain name along with subsystem names (prefixed by round bullets) and prominent object names (prefixed by square bullets). The inclusion of subsystem names is new to OOA08 while the inclusion of prominent object names was optional in OOA91. By default, both are shown in OOA Tool. However, if a domain shape's Preferred Size Usage attribute is set to None or Use As Maximum Size then the content shown in the domain shape can be reduced by manually resizing the shape. Prominent object names disappear first, followed by subsystem names later.

Bridges are represented using double curved links containing 1 or 2 way points. If you want to reshape a curved link then all you need to do is move the associated way points. However, the locations of these way points are not always obvious since curved links have no kinks! The best way to determine where they are is to select the area containing the link or use CTRL-A to select all shapes and way points and then reselect the specific way point you want to move.

Below is an example Domain Chart in Executable UML notation taken from [xtUML02] (see page 15):

Domains are represented using folder shapes containing the domain name. Subsystems and prominent objects are not currently shown. Implementation domains are highlighted using the stereotype «realized». Domain shapes can be resized to include other domains for presentation purposes, e.g. the Model Compiler domain in the example above includes several implementation domains. However, all domains exist at the same level. The Oracle, J2EE and Java domains in the example above can be moved elsewhere in the Domain Chart and you would then see that each has an ordinary bridge from the Model Compiler domain. However, if application or service domains are shown to include a service domain (rather than an implementation domain) then there may be confusion as to whether the included domain is actually a subsystem.

Bridges are represented using diagonal links containing 1 or 2 way points. Executable UML uses long (rather than short) dashed links to distinguish Domain Charts from Subsystem Diagrams.

Finally, the Executable UML example above is shown below in Executable UML2 notation:

Domains are still represented using folder shapes containing the domain name. However, the domain name is now shown in bold and is vertically centred. Furthermore, domains which include other domains now show their domain name in the folder tab if there is enough room.

Bridges are still represented using diagonal links containing 1 or 2 way points. However, the links look slightly different. See page 43 of [UMLManual05] for an example UML2 package diagram.

Naming

Names within OOA08's OOA of OOA are represented using a single attribute with a data type of Name. However, names are more complicated than they first appear. Names need to be formatted into numerous formats across various diagrams and generated work products. Letter case will often change during this formatting, as will the separator text before, between and after the words which compose each name. However, even though a name may have many formatted representations, there needs to be an underlying name for determining uniqueness within the context of what is being named. This underlying name needs to be case-insensitive and independent of particular separator text so that uniqueness is maintained in the many formatted representations of each name. A Naming service domain has been created to formalize names and name formats.

The object information model for Naming is given below:

The equivalent class diagram for Naming can also be shown since OOA Tool now supports Executable UML notation:

In the above model, names retain their original Unicode text representation. This representation is converted into a case-insensitive identifier by stripping out all non alpha-numeric characters, including characters such as underscore which are normally allowed within identifiers, and converting the remaining characters into lower case. Since we don't want empty identifiers, all names must include at least one letter. We also don't want any identifiers starting with a digit, so any leading digits are ignored when determining this identifier. The case-insensitive identifier is only unique within certain contexts which is why it is not an identifying attribute in the model above.

Each name is decomposed into one or more alpha-numeric words to simplify formatting. Each word is either all letters or all digits. In the model above, alpha-numeric words contain start and end indexes for the word's text within the original text representation. This also allows us to determine any separating text that precedes the word. This appears to break the normal Shlaer-Mellor rule that attribute values are atomic. However, data values in OOA08 are write atomic but not necessarily read atomic.

Name formats allow letter case to be specified for first letter and secondary letters of first word and secondary words (other replaces secondary in the model above). Name formats also allow acronyms to be preserved even when embedded within CamelCase names.

Name formats are represented using a pattern, the syntax of which is given below:

pattern :=
    textChoices         // Leading text choices
    ( 'A' | 'a' | '?' ) // First word first letter case
    ( 'A' | 'a' | '?' ) // First word other letter case
    textChoices         // Separating text choices
    ( 'A' | 'a' | '?' ) // Other word first letter case
    ( 'A' | 'a' | '?' ) // Other word other letter case
    textChoices         // Trailing text choices
    [ 't' | 'f' ]       // Preserve first acronym case
    [ 't' | 'f' ]       // Preserve other acronym case

textChoices := { '(' { ! ')' $anyCharacter }* ')'
               | '[' { ! ']' $anyCharacter }* ']' }*

Letter case is determined by using 'A' for upper case, 'a' for lower case and '?' for any case. Whether acronym case is preserved acronyms are preserved is determined by 't' for true and 'f' for false (false is the default value). Text choices are delimited by parenthesis or brackets. If any of the given text choices match the actual leading, separating or trailing text then that text choice is used. Otherwise, the first text choice is used. If no text choices are given then the actual leading, separating or trailing text is always used.

OOA Tool's Archetype Language will allow the pattern syntax defined above to be used directly within substitution expressions to control the formatting of text.

Acronyms may span multiple alpha-numeric words since technical acronyms often include digits (e.g. J2SE). However, we need to watch out for 'A' and 'I' which are valid words in their own right. A syntax which summarises the rules for matching acronyms is given below:

    acronym := acronymStart { acronymPart }*

    acronymStart := $upperCaseLetter { $upperCaseLetter }+
                    | ! 'A' ! 'I' $upperCaseLetter
                    | 'A' !! $digit | 'I' !! $digit

    acronymPart := { $upperCaseLetter }+ | { $digit }+

The main name formats used in OOA Tool are listed below:

Name Format	Pattern
All Caps Title Case	()AA( )(-)(/)AA()
Title Case	()Aa( )(-)(/)Aa()tt
Upper Sentence Case	()Aa( )(-)(/)aa()tt
Lower Sentence Case	()aa( )(-)(/)aa()tt
All Caps Underscore Case	()AA(_)AA()
Title Underscore Case	()Aa(_)Aa()tt
Upper Underscore Case	()Aa(_)aa()tt
Lower Underscore Case	()aa(_)aa()tt
All Caps Camel Case1	()AA()(_)AA()
Upper Camel Case2	()Aa()(_)Aa()tt
Lower Camel Case2	()aa()(_)Aa()ft

1. Not parsable unless underscore separators used.
2. Parsable as long as two acronyms don't appear next to each other.

The table below identifies where the above name formats are used within OOA Tool's Shlaer-Mellor and Executable UML diagrams:

Where	Shlaer-Mellor	Executable UML
Domain Chart domain names	Title Case	Title Case
Domain Chart subsystem names	Upper Sentence Case	N/A
Domain Chart prominent object names	Lower Sentence Case	N/A
SRM/SCM/SAM1 subsystem names	Title Case	Title Case
SRM/SCM/SAM1 subsystem prefix letters	All Caps Camel Case	All Caps Camel Case Upper Camel Case
SRM/SCM/SAM1 prominent object names	Lower Sentence Case	N/A
OIM2 subsystem names	Title Case	Upper Camel Case
OIM2 object names	All Caps Title Case	Upper Camel Case
OIM2 object key letters	All Caps Camel Case	All Caps Camel Case Upper Camel Case
OIM2 attribute names	Upper Sentence Case	Lower Camel Case
OIM2 data type names	N/A	Upper Camel Case3
OCM4 state model/terminator names	Title Case	Title Case
OCM4 event meanings	Upper Sentence Case	Lower Camel Case
OAM5 state model/terminator names	Title Case	Title Case
OAM5 accessor meanings	Upper Sentence Case	Lower Camel Case
STD6 state names	Upper Sentence Case	Title Case
STD6 event meanings	Upper Sentence Case	Lower Camel Case
STD6 supplemental data item names	Lower Sentence Case	Lower Camel Case
ADFD7 names	TBD	N/A
Thread of Control Chart8 names	TBD	TBD
Use Case Diagram names	N/A	TBD

1. Subsystem Relationship Model/Subsystem Communication Model/Subsystem Access Model.
2. Object Information Model or Class Diagram in Executable UML.
3. User data type names are formatted in Upper Camel Case while core data type names are formatted in lower case.
4. Object Communication Model or Collaboration Diagram^UML1/Communication Diagram^UML2 in Executable UML.
5. Object Access Model.
6. State Transition Diagram or Statechart Diagram^UML1/State Machine Diagram^UML2 in Executable UML.
7. Action Data Flow Diagram.
8. Thread of Control Chart or Sequence Diagram in Executable UML.

Name formats within Action Language and Archetype Language code are determined by whoever writes the code. Since uniqueness of names is determined by the case-insensitive alpha-numeric identifier associated with each name, name formats can be mixed within code. However, the following name formats are recommended:

Where	Shlaer-Mellor	Executable UML
Object/Class names	Title Underscore Case	Upper Camel Case
Attribute names	Upper Underscore Case	Lower Camel Case
Supplemental data item/parameter/variable names	Lower Underscore Case	Lower Camel Case

Whichever name formats are used in your code, they should be used consistently.

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.