Object Information Model Notation

This is the fourth in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers partial and complete Object Information Models (OIM) which are used to show the objects, attributes and relationships within a domain or subsystem. If a domain is partitioned into subsystems then each subsystem has a partial OIM showing assigned or imported objects along with assigned relationships. This is instead of showing a complete OIM for the entire domain. OIMs also show preferred identifiers, mathematically dependent statuses and referential attribute mappings.

Object Information Models in Shlaer-Mellor notation used to be called Information Structure Diagrams [OOA91]. However, the name Object Information Model was adopted later since OIMs are complemented by Object Communication Models and Object Access Models. This is the only name used in OOA08 and in OOA Tool (when using Shlaer-Mellor notation). Object Information Models are called Class Diagrams in all Executable UML variants, including [xtUML02] and Executable UML2. However, the Executable UML variant [xUML04] makes various minor changes to the Class Diagram notation described here which OOA Tool does not support.

There are a number of other name changes which are relevant here when switching between Shlaer-Mellor and Executable UML notation:

• Information Models are known as Platform-Independent Models (PIM),
• Objects are known as Classes,
• Binary Relationships are known as Binary Associations,
• Composed Relationships are known as Equal Set Constrained Associations,
• Subtype-Supertype Relationships are known as Generalizations,
• Participants are known as Relationship Ends,
• Supertypes and Subtypes are known as Superclasses and Subclasses,
• and the term mathematically dependent is replaced by derived, i.e. Mathematically Dependent Attribute becomes Derived Attribute and Mathematically Dependent Relationship becomes Derived Association.

Below is an example Object Information Model in Shlaer-Mellor notation taken from [OOA91] (see page 4):

Another example Object Information Model showing instances of all notationally different forms of object, attribute and relationship is shown below:

Objects are represented using rectangle shapes containing the object name, key letters and number along with attribute names (prefixed by star or round bullets). The attributes which compose the object's preferred identifier are prefixed by a star bullet. Imported objects are represented using dashed (and half transparent) rectangle shapes containing the same information as normal object shapes. A from annotation is always shown below imported objects, indicating which subsystem the object is imported from. On partial OIMs, key letters always include any prefix letters associated with the subsystem.

Attributes can be hidden by manually reducing the size of an object or imported object shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). An OIM which shows no attributes on any of the included objects is called an Overview Object Information Model (it used to be called an Overview Information Structure Diagram in [OOA88]).

Within object shapes, mathematically dependent attributes (introduced in [OOA96]) have an (M) suffix. Referential attributes have an (R) or (Rn, Rn...) suffix where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. The relationship IDs in a referential suffix may end with c indicating that the reference is constrained. Constrained referential attributes are supported in OOA Tool. However, better support for defining loop constraints will be added in the future. Polymorphic attributes (introduced in OOA08) have a (P) or (P-Rn) suffix where the relationship ID identifies the subtype-supertype relationship determining the polymorphic attribute's scope. Within OOA Tool's browser, naming attributes have an (N) suffix but this suffix is not used in OIMs.

Relationships are represented using rectilinear links labelled with relationship IDs. Relationships are either binary relationships or subtype-supertype relationships. Binary relationships are either simple relationships, associative relationships, composed relationships or mathematically dependent relationships. A binary relationship between an object and itself is called a reflexive relationship. Reflexive relationships are symmetric if both ends of the relationship have the same multiplicity, conditionality and verb phrase. Otherwise, they are called Asymmetric reflexive relationships.

Binary relationships connect a first and second object shape. Simple relationships are centrally labelled with the relationship ID. Associative relationships connect an associative object shape with a binary relationship. The point where the associative object shape connects to the binary relationship is labelled with the relationship ID. Composed relationships are centrally labelled with a summary of the composition, e.g. R10 = R2 + R3 + R4. Mathematically dependent relationships (introduced in OOA08) are centrally labelled with the relationship ID and an (M) suffix. Subtype-supertype relationships connect a supertype and two or more subtype object shapes. The link segment connected to the supertype object shape has a split bar labelled with the relationship ID on the left and the fixed partial verb phrase is a on the right.

A first or second object shape connector is either a single arrow or double arrow (if multiplicity is many) with an optional C annotation (if conditional). The connector is also annotated with the verb phrase (in italics) from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LEFT SUBTYPE participant but shown on the RIGHT SUBTYPE connector. If there is no verb phrase and the participant's role (introduced in OOA08) has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. An associative object shape connector is a plain line. A binary relationship connector from an associative link is either a single arrow or a double arrow (if multiplicity is many) with an optional C annotation (if conditional). Conditional in this sense means that the associative object can exist independently of the associative relationship. Associative relationship conditionality was introduced in OOA08. OOA96 introduced a special notation for symmetric reflexive relationships. No arrows or annotations are shown on one end of the relationship, i.e. the second object shape connector is a plain line. Such relationships are normally formalized using an associative object, e.g. R12 in the diagram above. Supertype and subtype object shape connectors are plain lines.

An example Class Diagram taken from [xtUML02] (see page 315) is shown below:

The second Shlaer-Mellor example above is also shown below in Executable UML notation:

Classes are represented using rectangle shapes split into three compartments. The first compartment contains the class name centred in bold along with the key letters and number as a right aligned UML property string. Attribute names along with associated data type names and any initial values are shown in the second compartment. Preferred identifiers are not shown on class shapes. However, identifier IDs for preferred and secondary identifiers are included in the UML property strings associated with identifying attributes in the second compartment. Event names are optionally shown in the third compartment. The class shape must be manually increased in size to show events (after setting Preferred Size Usage attribute to None or Use As Minimum Size). The second and third compartment can be hidden by manually reducing the size of a class shape (after changing the shape's Preferred Size Usage attribute to None or Use As Maximum Size). Imported classes are represented using half transparent rectangle shapes containing the same information as normal class shapes. An imported from annotation is always shown right aligned (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.

Within the second compartment of class shapes, derived attributes have a slash '/' prefix. Conditional attributes are not currently distinguished in Executable UML class diagrams. However, a [0..1] multiplicity expression is normally shown immediately after the attribute name. The name of an attribute's data type (if defined) is shown after the attribute name prefixed by a colon ':' separator. This is followed by the attribute's initial value (if one is defined) prefixed by an equals '=' separator. Identifying attributes have an {In, In...} property set where the identifier IDs identify which identifiers the attribute is part of. Note that, I1 is always abbreviated to I. Referential attributes have an {Rn, Rn...} property set where the relationship IDs identify referential attribute mappings, i.e. the relationships that the attribute formalizes. Referential attributes without referential attribute mappings and constrained referential attributes are not distinguished on class diagrams. Polymorphic attributes (introduced in OOA08) are shown in italics and have a {P-Rn} property where the relationship ID identifies the generalization determining the polymorphic attribute's scope. Literal value attributes have a {frozen} property indicating that they can't be changed. All properties associated with an attribute are included in a single right aligned UML property string.

Relationships are represented using rectilinear links labelled with relationship IDs in italics. These are solid links except for links between association classes and binary associations which are short dashed links. Relationships are either binary associations or generalizations. Binary associations are either simple associations, association class associations, equal set constrained associations, subset constrained associations or derived associations. However, OOA Tool does not currently support subset constrained associations. It will when better support for loop constraints are added. A binary association between a class and itself is called a reflexive association. Executable UML does not support aggregations, compositions or n-ary associations. Furthermore, only disjoint complete generalizations are supported.

Binary associations connect a first and second class shape. Simple associations are centrally labelled with the relationship ID. Association class associations connect an association class shape with a binary association. The point where the association class shape connects to the binary association is labelled with the relationship ID. Equal set constrained associations are centrally labelled with the relationship ID and equal set constraint, e.g. R10 {equal, R2, R3, R4}. Derived associations are centrally labelled with the relationship ID prefixed with a slash '/'. Generalizations connect a superclass and two or more subclass shapes. The link segment connected to the superclass shape is centrally labelled with the relationship ID (in italics) on the left and the fixed constraint {disjoint, complete} on the right.

All class shape connectors except for superclass shape connectors are plain lines. A superclass shape connector is a large hollow arrow. Multiplicity and conditionality on first or second shape connectors are indicated using one of the following annotations: 0..1 for zero or one, 1 for exactly one, 0..* for zero or more, or 1..* for one or more. These connectors are also annotated with the verb phrase from the opposite participant, e.g. the verb phrase contains (from R2 in the diagram above) is associated with the LeftSubtype participant but shown on the RightSubtype connector. If there is no verb phrase and the participant's role has been changed from the default (i.e. first or second) then the connector is annotated with the role instead. A binary association connector from an association class is also annotated with one of the above multiplicity and conditionality annotations if multiplicity is many or conditionality is true. An explicit 1 annotation is never used here. A multiplicity of many indicates that there may be many association class associations between any given first and second class. A conditionality of true indicates that the association class can exist independently of the association class association. This level of formality (which is not defined in standard UML) is required to validate navigation across arbitrary relationships in Executable UML.

Finally, the second Shlaer-Mellor example above is also shown below in Executable UML2 notation:

Rather than repeat what was previously discussed, only the differences between Executable UML and Executable UML2 notation are listed below:

• Imported classes are represented using half transparent rectangle shapes (with half transparent borders) containing the same information as normal class shapes. A from annotation is always shown centred (just below the class name) in the first compartment of imported classes, indicating which subsystem the class is imported from.
• The colon ':' separator used between attribute and type names now appears without a proceeding space.
• Conditional attributes are indicated by including a [0..1] multiplicity expression immediately after any type name.
• Literal value attributes have a {readOnly} property indicating that they can't be changed.
• Relationships are represented using rectilinear links labelled with relationship IDs in bold.
• The links between association classes and binary associations are still short dashed links but dash lengths are slightly longer in Executable UML2.

Subsystem Communication Model Notation

This is the third in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers Subsystem Communication Models (SCM) which are used to show the subsystems within a domain and identify any asynchronous communications between those subsystems. The model itself is automatically derived. However, OOA Tool currently requires someone to layout the model since automatic layout of diagrams where all nodes are connected in many ways is incredibly difficult to perform.

Executable UML [xtUML02] does not name SCMs explicitly. However, diagrams in UML are generally called diagrams, not models. Furthermore, Object Communication Models are called Collaboration Diagrams in Executable UML while Collaboration Diagrams are now called Communication Diagrams in UML2. Thus, the name Subsystem Collaboration Diagram is used here when referring to an SCM in Executable UML notation while the name Subsystem Communication Diagram is used instead in Executable UML2 notation. The other Executable UML variant [xUML04] doesn't seem to use SCMs at all.

Below is an example Subsystem Communication Model in Shlaer-Mellor notation taken from [OOA91] (see page 153):

Subsystem Communication Models are very similar to Subsystem Relationship Models and Subsystem Access Models. They all represent subsystems using rectangle shapes containing the subsystem name, optional prefix letters and an optional number range along with prominent object names (prefixed by square bullets). The relative position of the prefix letters and number range was reversed in OOA08 compared to OOA91. OOA08 adopts a format consistent with that used for Objects within Object Information Models. Showing prominent object names in subsystem shapes is also a new feature of OOA08.

All internal asynchronous communications (i.e. internal events generated within state actions) from state models in a source subsystem to state models in a target subsystem are listed on a single rectilinear link with an arrow pointing to the target subsystem. Only the meaning of internal events is shown, i.e. supplemental data items are not shown on SCMs. Any asynchronous communications going in the opposite direction are listed on another rectilinear link with an arrow pointing in the opposite direction. These links only exist if one or more asynchronous communications exist. However, since subsystems within a domain are peer-to-peer, there may be many such links in a typical domain.

Asynchronous communications between subsystems and terminators (which are subsystem independent) are not shown on SCMs in OOA91. They are currently not shown on SCMs in OOA08 either. However, this may change in the future. There is a need to capture the external interface to a domain. This could partially be accomplished by showing external events (those generated outside the domain or within synchronous service actions) from terminators to subsystems and domain-crossing events from subsystems to terminators on SCMs.

The Shlaer-Mellor example above is shown below in Executable UML notation:

Another example Subsystem Collaboration Diagram taken from [xtUML02] (see page 273) is shown below:

Subsystem Collaboration Diagrams are very similar to Subsystem Relationship Diagrams and Subsystem Access Diagrams. They all represent subsystems using folder shapes containing the subsystem name. Prominent objects are not currently shown.

Subsystem dependencies listing asynchronous communications are represented using short dashed rectilinear links. The internal events are shown on a floating arrow pointing at the target subsystem. Unlike Shlaer-Mellor SCMs, there is never more than one link between any two subsystems, i.e. two links between a particular pair of subsystems in Shlaer-Mellor are replaced with two floating arrows on a single link in Executable UML.

Finally, the Shlaer-Mellor example above is also shown below in Executable UML2 notation:

Subsystems are still represented using folder shapes containing the subsystem name. However, the subsystem name is now shown in bold. Furthermore, the subsystem's optional prefix letters and number range is now shown as a right aligned UML property string below the subsystem name. This is consistent with how key letters and numbers are shown on class shapes within Class Diagrams.

Subsystem dependencies are still represented using short dashed rectilinear links. However, a consistent dash length is used across all package diagrams in Executable UML2. See page 43 of [UMLManual05] for an example UML2 package diagram. More significantly, the single floating arrows at each end of these links are replaced with multiple leading or trailing arrows (one per event). In UML2, events going in both directions can be listed together in sequence number order since each event is prefixed or suffixed with an arrow indicating the event's direction. However, sequence numbers are not used in Executable UML. Thus, OOA Tool keeps events which are going in the same direction together and separated from events going in the opposite direction.

Subsystem Relationship Model Notation

This is the second in a series of technical notes outlining the Shlaer-Mellor and Executable UML notation supported by OOA Tool. This technical note covers Subsystem Relationship Models (SRM) which are used to show the subsystems within a domain and identify any spanning relationships between those subsystems. The model itself is automatically derived. However, OOA Tool currently requires someone to layout the model since automatic layout of diagrams where all nodes are connected in many ways is incredibly difficult to perform.

Executable UML [xtUML02] does not name SRMs explicitly. However, diagrams in UML are generally called diagrams, not models. Thus, the name Subsystem Relationship Diagram is used here when referring to an SRM in Executable UML notation. The other Executable UML variant [xUML04] doesn't seem to use SRMs at all.

Below is an example Subsystem Relationship Model in Shlaer-Mellor notation taken from [OOA91] (see page 153):

Subsystems are represented using rectangle shapes containing the subsystem name, optional prefix letters and an optional number range along with prominent object names (prefixed by square bullets). The relative position of the prefix letters and number range was reversed in OOA08 compared to OOA91. OOA08 adopts a format consistent with that used for Objects within Object Information Models. Showing prominent object names in subsystem shapes is also a new feature of OOA08.

All key letters for objects assigned to a subsystem begin with the subsystem's specified prefix letters. Prefix letters are automatically added to key letters in OOA Tool. All objects and relationships assigned to a subsystem should have numbers within the subsystem's specified number range. However, automatic numbering of objects and/or relationships can be disabled in OOA Tool which may lead to objects and relationships having numbers outside the specified number range (see Manual and Automatic Numbering).

All spanning relationships between a particular pair of subsystems are listed on a single rectilinear link. These links only exist if one or more spanning relationships exist. However, since subsystems within a domain are peer-to-peer, there may be many such links in a typical domain.

Below is an example Subsystem Relationship Diagram in Executable UML notation taken from [xtUML02] (see page 271):

Subsystems are represented using folder shapes containing the subsystem name. Prominent objects are not currently shown. Domains and subsystems use the same folder shapes since both are a type of UML package. However, Executable UML (xtUML) uses a smaller width folder for domains compared to subsystems and subsystem shapes show the subsystem name vertically centred (as packages should in UML).

Subsystem dependencies listing spanning relationships are represented using short dashed rectilinear links. They don't have an arrow since they are bidirectional dependencies. The spanning relationships are shown as a UML property string on the link. All UML property strings within OOA Tool use brace spacing in a consistent way, i.e. no space after '{' or before '}'.

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

Subsystems are still represented using folder shapes containing the subsystem name. However, the subsystem name is now shown in bold. Furthermore, the subsystem's optional prefix letters and number range is now shown as a right aligned UML property string below the subsystem name. This is consistent with how key letters and numbers are shown on class shapes within Class Diagrams.

Subsystem dependencies are still represented using short dashed rectilinear links. However, a consistent dash length is used across all package diagrams in Executable UML2. See page 43 of [UMLManual05] for an example UML2 package diagram.

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.