Wednesday, 29 October 2008

Loop Dependent Relationships

Relationship loops appear everywhere in information models. Most of these are loops of independent relationships. However, there are times when a loop-closing relationship is dependent on the relationship loop being closed.

OOA91 introduced the concept of a composed relationship (called an equal set constrained relationship in Executable UML) where the loop-closing relationship is equivalent to the composition of the relationships in the rest of the loop. In many cases, composed relationships are redundant and shouldn't be modelled by the analyst. Obviously, a composition containing a single relationship is always redundant and thus is not allowed. However, sometimes the nature of the composed relationship differs from the set of relationships which compose it even though the formalization is determined from those component relationships. The verb phrases used should highlight the differences. Composed relationships shouldn't be composed from other composed relationships. It would be possible to allow this as long as there was no circular compositions. However, such relationships can be difficult to understand and add little value. OOA Tool does not currently allow such relationships.

On a more pragmatic note, composed relationships allow heavily navigated complex relationship chains to be simplified. This technique should be used sparingly since it is a pollution of the information model. However, in some cases, it can significantly improve the readability and maintainability of Action Language code. Note that, composed relationships can be changed later without having to change any such code, e.g. the composition could be changed slightly or the composed relationship could be changed to become a mathematically dependent relationship.

The multiplicity and conditionality of composed relationships is initially determined directly from the component relationships. However, OOA Tool allows this to be changed reflecting the fact that the composed relationship should be modelling new information. The composed relationship can't increase multiplicity or add conditionality to component relationships. This will be flagged as an error in OOA Tool. However, many can be reduced to one and conditional can be changed to mandatory. This allows an additional constraint to be defined in the information model. Whether the final translated system checks this constraint is determined by the software architecture that you use. However, this constraint should be checked automatically by your simulator during testing.

OOA08 goes even further with composed relationships, it allows a participant mapping to be defined which can be used to constrain one or more referential attributes. This participant mapping is never used to navigate the composed relationship and a composed relationship is never created using an Action Language link statement. However, when other relationships are created which share referential attributes with a composed relationship's participant mapping then they can be checked against the composed relationship's navigation results. OOA Tool's tree browser shows referential attribute mappings for composed relationships in gray within referential suffixes.

This mechanism is sometimes useful since referential attributes aren't inherited in subtypes. An attribute may formalize a relationship in a supertype which is also used to formalise another relationship in a subtype. However, only referential attributes which are used as part of the supertype's identifier are 'inherited' in subtypes, i.e. they are used to formalise the subtype to supertype mapping. I have seen models where an analyst has added a common referential attribute to the supertype's identifier so that it can be used in the subtype. Identifier's should never be polluted in this way since the uniqueness constraint imposed by the identifier is always weakened (and sometimes completely broken) when redundant attributes are added.

Another type of loop dependent relationship is the subset constrained relationship. The concept of constrained relationships was introduced in OOA96. It annotates one or more of the referential attributes associated with the participant mapping which formalises the constrained relationship with a small 'c'. However, the concept was developed further in Executable UML [xtUML02] where the relationship label of a subset constrained association is annotated with a subset constraint indicating the relationship loop. OOA08 adopts a combination of the approaches. It annotates the relationship label of a constrained relationship (e.g. R2 ⊆ R3 + R1) and it annotates one or more referential attributes with a small 'c' in the appropriate part of the referential suffix. OOA08 allows simple relationships, associative relationships and mathematically dependent relationships to be constrained. Constrained relationships can constrain other constrained relationships since each constraint is checked independently using underlying relationship formalizations. The relationship loop being constrained may also contain only a single component relationship (unlike composed relationships which must be composed from two or more component relationships).

Below is an example of a constrained relationship in Shlaer-Mellor notation taken from [OOA96] (see page 14):

It uses the constrained relationship to impose the constraint that students can only be advised by a professor on the staff of the department in which the student majors in. This same example is shown below in Executable UML (xtUML) notation:

Note that, constrained referential attributes are not currently marked with a small 'c' in Executable UML class diagrams. However, OOA Tool does mark constrained referential attributes within its tree browser.

OOA Tool allows any referential attribute mappings to be marked as constrained. However, only referential attribute mappings associated with a constrained relationship should be marked as constrained since the flag currently has no meaning in other contexts. OOA Tool highlights informal constrained flags within its tree browser but it will still mark up the appropriate referential suffixes on Object Information Models. OOA Tool will only automatically mark one or more of the referential attributes of a constrained relationship if the analyst hasn't explicitly marked one of them already. This allows an analyst to more explicitly identify which attribute is being constrained. OOA96 only requires a single attribute to be marked. OOA Tool, by default, marks all referential attributes formalizing the constrained relationship except those which also formalise the first or last relationship from the associated relationship loop. However, in practice, this will normally be a single attribute.

The multiplicity and conditionality of a constrained relationship can initially be determined directly from it's dependent loop of component relationships. Obviously, OOA Tool allows this to be changed reflecting the fact that a constrained relationship should be a subset of it's dependent loop. However, a constrained relationship can't increase multiplicity or remove conditionality. This will be flagged as an error in OOA Tool. It can reduce many to one and mandatory to conditional. This differs from a composed relationship which acts like a superset constrained relationship since it allows conditional to be changed to mandatory but not vice versa.

Tuesday, 14 October 2008

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.

Tuesday, 30 September 2008

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.

Thursday, 25 September 2008

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.

Tuesday, 23 September 2008

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.

Wednesday, 27 August 2008

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:

WhereShlaer-MellorExecutable UML
Domain Chart domain namesTitle CaseTitle Case
Domain Chart subsystem namesUpper Sentence CaseN/A
Domain Chart prominent object namesLower Sentence CaseN/A
SRM/SCM/SAM1 subsystem namesTitle CaseTitle Case
SRM/SCM/SAM1 subsystem prefix lettersAll Caps Camel CaseAll Caps Camel Case
Upper Camel Case
SRM/SCM/SAM1 prominent object namesLower Sentence CaseN/A
OIM2 subsystem namesTitle CaseUpper Camel Case
OIM2 object namesAll Caps Title CaseUpper Camel Case
OIM2 object key lettersAll Caps Camel CaseAll Caps Camel Case
Upper Camel Case
OIM2 attribute namesUpper Sentence CaseLower Camel Case
OIM2 data type namesN/AUpper Camel Case3
OCM4 state model/terminator namesTitle CaseTitle Case
OCM4 event meaningsUpper Sentence CaseLower Camel Case
OAM5 state model/terminator namesTitle CaseTitle Case
OAM5 accessor meaningsUpper Sentence CaseLower Camel Case
STD6 state namesUpper Sentence CaseTitle Case
STD6 event meaningsUpper Sentence CaseLower Camel Case
STD6 supplemental data item namesLower Sentence CaseLower Camel Case
ADFD7 namesTBDN/A
Thread of Control Chart8 namesTBDTBD
Use Case Diagram namesN/ATBD
  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 DiagramUML1/Communication DiagramUML2 in Executable UML.
  5. Object Access Model.
  6. State Transition Diagram or Statechart DiagramUML1/State Machine DiagramUML2 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:

WhereShlaer-MellorExecutable UML
Object/Class namesTitle Underscore CaseUpper Camel Case
Attribute namesUpper Underscore CaseLower Camel Case
Supplemental data item/parameter/variable namesLower Underscore CaseLower Camel Case
Whichever name formats are used in your code, they should be used consistently.

Tuesday, 22 July 2008

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.

Monday, 14 July 2008

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.

Tuesday, 17 June 2008

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.

Friday, 13 June 2008

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:

Wednesday, 4 June 2008

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.

Saturday, 31 May 2008

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.

Thursday, 29 May 2008

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.

Monday, 26 May 2008

Polymorphic Attributes

Polymorphic attributes are new to OOA08 and have only really become useful since OOA96 introduced mathematically dependent (i.e. derived) attributes. Previously, if a common non-identifying attribute was defined in most (not necessarily all) subtypes of a subtype-supertype relationship, it would be abstracted into the supertype object. This would only cause a problem if the attribute was referential in any of the subtype objects. In which case, the analyst would have to leave the referential attributes where they were and decide whether having a copy of the attribute in the supertype object was still beneficial. OOA96 introduced the concept of a constrained referential attribute and this could be used to constrain any referential attributes left in subtypes after a common attribute is abstracted into a supertype object. This situation does not happen often in my experience. However, with the introduction of mathematically dependent attributes, abstracting common attributes of mixed type becomes much more difficult. How do you abstract a common attribute which is a simple attribute in one subtype and a mathematically dependent attribute in another subtype? The answer is a polymorphic attribute.

Polymorphic attributes are similar to polymorphic events (which were also introduced in OOA96) in that polymorphic attributes in a supertype object are mapped to true attributes in subtype objects. An analyst associates a subtype-supertype relationship with a polymorphic attribute and then selects a subtype attribute in each of the relationship's subtype objects. Subtype attributes may themselves be polymorphic attributes. When we refer to true attributes we mean non-polymorphic attributes with any intermediate polymorphic attributes flattened out. Obviously, the object containing the polymorphic attribute must be the relationship's supertype object. It is rare for there to be more than one choice of subtype-supertype relationship, i.e. multiple supertype objects are rare.

Polymorphic attributes and their corresponding true attributes do not have to have the same name but they must have the same data type. However, OOA Tool can pre-select subtype attributes that have the same name and data type. This makes the creation of a polymorphic attribute a 2 second job in most cases. The conditionality of a polymorphic attribute is the weakest conditionality of any of it's true attributes, i.e. the polymorphic attribute is conditional (1c) if any true attribute is conditional. Furthermore, an analyst can make a polymorphic attribute conditional even if none of it's true attributes are conditional. One could argue that the data type of a polymorphic attribute should be the weakest data type of any of it's true attributes. However, to keep things simple, the data types of all true attributes must match in OOA08.

The example above shows a typical polymorphic attribute with a true attribute defined in each of the subtype objects. The attribute suffix of a polymorphic attribute begins with 'P' and includes the associated subtype-supertype relationship ID, e.g. (P-R1). Using the relationship ID is important since the associated relationship may be defined in another subsystem and thus may not be shown on a particular diagram. The attribute suffix (P) is used if there is no associated relationship at present. In the example above the true attributes are simple, mathematically dependent and referential.

Polymorphic Attribute above could be replaced by Other Attribute if the associated calculation code performed a simple switch on the supertype's current subtype returning the appropriate true attribute value. This would be unthinkable in an object-oriented programming language. However, in Shlaer-Mellor OOA, a subtype-supertype relationship is complete in the sense that all subtypes are identified by the analyst in the information model. Therefore, the switch code for Other Attribute would also be complete. OOA Tool will inform an analyst if a subtype switch statement is no longer complete, e.g. when a new subtype object is added. The disadvantage of using this approach is that the polymorphic relationship is hidden in Other Attribute's calculation code.

The diagram above shows how polymorphic attributes can be used to create interface like objects without having to create additional redundant relationships or use arbitrary IDs. Main ID and Parent ID in Interface would normally have to be referential attributes but that would require some form of relationship to Parent to resolve the referential attributes (OOA08 requires all referential attributes to resolve to a single base attribute). Alternatively, an arbitrary ID could be added to Interface and then used in Child B and Child C. Making these attributes polymorphic means that they can resolve downwards in R3 while the matching attributes in Child B and Child C reference upwards to formalize R3. This works because the matching attributes in Child B and Child C have an alternative path to their base attributes in Parent and Main. How referential attributes are resolved to base attributes and why they should all resolve to a single base attribute will be discussed another day.

Friday, 23 May 2008

Flattening Subtype-Supertype Hierarchies

One of the first tasks when mapping (or translating) Shlaer-Mellor information models to XML documents or Java code is to flatten subtype-supertype hierarchies. Obviously, XML does not support any kind of generalization. While Java only allows single inheritence and this facility may be required to implement the objects within the Java software architecture.

The diagram above shows leaf objects with single and multiple supertypes. The definition of a leaf object is any object which doesn't participate in a subtype-supertype relationship as a supertype object. This example is easily flattened into:

  • Leaf A containing Leaf A and Supertype A
  • Leaf B containing Leaf B, Supertype A and Supertype B
  • Leaf C containing Leaf C and Supertype B

The diagram above shows an example of an improper subtype-supertype relationship. Leaf B is a subtype of Supertype B and Supertype C. However, the subtype-supertype relationship R1 specifies that all Supertype A objects are either Supertype B or Supertype C but not both. Executable UML (the UML version of Shlaer-Mellor) explicitly labels these relationships as disjoint to emphasis the point. C++ allows multiple inheritence with common base classes but Shlaer-Mellor OOA does not.

The other form of improper subtype-supertype relationship is where a subtype ends up being a supertype of itself via a circular chain of subtype-supertype navigations.

The diagram above shows an example of compound subtype-supertype relationships where Supertype is a Leaf A or Leaf B and a Leaf C or Leaf D. To flatten this example requires the introduction of new compound leaf objects:

  • Leaf A/C containing Leaf A, Supertype and Leaf C
  • Leaf A/D containing Leaf A, Supertype and Leaf D
  • Leaf B/C containing Leaf B, Supertype and Leaf C
  • Leaf B/D containing Leaf B, Supertype and Leaf D

Compound subtypes may participate in other subtype-supertype relationships either as supertypes or subtypes leading to complex hierarchies. However, as long as there are no improper subtype-supertype relationships then these hierarchies can always be flattened into leaf and compound leaf objects.

The algorithm for flattening subtype-supertype hierarchies gave me a few headaches before I settled on a two pass strategy:

  1. The first pass iterates over all leaf objects (non-supertype objects) creating flat elements each containing a set of component objects (as shown in the examples above). This pass uses limited recursion when navigating to supertypes and can easily check for improper subtype-supertype relationships by checking whether an object has already been added to a flat element's set of component objects prior to adding a new object.
  2. The second pass iterates over all multiple supertype objects (non-leaf objects which are supertypes in multiple subtype-supertype relationships). It then matches each subtype object to all flat elements whose set of component objects contain the subtype object. The set of flat elements for the subtype objects in each of the subtype-supertype relationships are then multiplied out by creating new flat elements containing the combined set of component objects (ignoring duplicates). The new flat elements replace the previous flat elements before the second pass iteration continues. This ensures multiple compound subtype-supertype relationships are correctly flattened without the need for recursion in this pass.

All flat elements contain at least one leaf object. A flat element containing multiple leaf objects represents a compound leaf object. A suitable name may need to be chosen for compound leaf objects since they aren't explicited defined in Shlaer-Mellor information models.

Flat elements can be easily mapped to XML elements as long as a suitable name for compound leaf objects can be determined. The XML attributes for the element are determined from the combined attributes of the flat element's set of component objects. All simple attributes except Arbitrary ID or Ordinal ID attributes are required. Mathematically dependent attributes may be useful but are not absolutely required. All referential attributes used solely to formalize subtype-supertype relationships can be ignored. Referential attributes used to formalize containment relationships can also be ignored. Only referential attributes used to formalize referential relationships need to be considered. All polymorphic attributes can be ignored since the true attributes must also be present. Attribute names may need to be qualified when they are mapped to XML attribute names. I will leave the discussion of containment and referential relationships within XML documents to another day.