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.