Week 3 of 2009

First week is now over and I'm not sure where it all went! I've been answering lots of email, tweaking stuff on my website, getting a tooth filled, adding an RSS feed to the Portal website so that users can be informed whenever new releases are made.

I also read Leon Starr's recent article Time and Synchronization in Executable UML. It discusses the fact that time is relative to each state machine, actions aren't interruptible, events aren't lost while actions are being processed, events are processed one at a time and that events aren't generally ordered. The two exceptions being that events sent from a specific state machine to itself are always processed before other events and that events sent between two specific state machines are always ordered. What the article doesn't discuss is synchronization of access to attribute values or relationship instances. Since any state machine can access any attribute values and navigate any relationships, this is a significant synchronization issue which is left to the software architecture to sort out.

OOA09 will have to address this issue to ensure domains are reusable across different software architectures. This will be done by introducing units of locking and a locking strategy. Units of locking will be either accessor processes or complete actions if there is no process model (accessor actions or complete procedures in Executable UML). Basic locking strategy will be either none, pessimistic or optimistic. Pessimistic will lock any object instances or relationship instance sets before allowing a process or action to be started. Optimistic will lock object instances and relationship instance sets just before they are accessed. Pessimistic locking reduces deadlock possibilities but keeps more stuff locked for longer. The amount of locking required in a system depends on the number of threads being used. If there is only one thread, no locking is required at all. If each state machine has its own thread then every unit of locking needs to perform locking. Obviously, a domain needs to define potential threads so that synchronization can be tested. Anyone who reuses that domain can decide to use a subset of those threads and still be confident in the original testing but if they introduce additional threading then additional testing of the domain will be required. The whole concept of locks and threads (not just the design and implementation of locks and threads) is left to individual software architectures prior to OOA09. However, this leads to significantly reduced reusability across different software architectures. More on this stuff in the future. OOA09 will tackle these issues in its Simulation subsystem.

What's up for this week? I need to finish off Build 013 and get it released. The tasks that are outstanding are:

• completion of arbitrary ID calculation logic along with an associated technical note,
• completion of object instance table editor and other population editing forms,
• completion of metamodel relationship population (metamodel object instance population is now finished),
• and the normal updating of web pages and release files.

The complicated task is finishing the arbitrary ID stuff while the big task is finishing the table editors and forms associated with population editing. Metamodel relationship population coding is just tedious and energy sapping, i.e. each relationship in the metamodel requires a chunk of Java code to populate. If I'm lucky, the next build will get released at the end of this week, if I find problems or issues or I run out of time then it may not get released until next week or even the week after. The firm deadline for this build is the end of January.

Week 2 of 2009

Happy new year everyone.

This is the first of many weekly reports which aim to keep everyone up-to-date with what is happening to OOA Tool, OOA09 and the portal website. First, OOA08 will become OOA09 for obvious reasons! The portal website is being renamed from Shlaer-Mellor OOA/RD Portal to Shlaer-Mellor and Executable UML Portal since OOA Tool now supports Executable UML notation. I'm keeping the name OOA Tool for sentimental reasons even thought the CASE tool will be an analysis, design, implementation and testing tool. These weekly reports will not be duplicated on the portal website unlike most of the other blog entries which are actually important technical notes.

The main achievements for 2008 were:

• major improvements to OOA Tool (now over 100KLOC of Java) including Executable UML support,
• portal website created,
• this blog created (which includes 16 technical notes),
• OOA Interchange Format released and version controlled,
• OOA of OOA released and version controlled,
• and fUML captured as an Executable UML model.

The main objectives for 2009 are:

1. release Standard edition of OOA Tool 1.0,
2. ensure portal website provides the products, services and resources necessary for users to actually use Shlaer-Mellor or Executable UML on real projects.

These objectives include:

• add simulator to OOA Tool,
• finish translator in OOA Tool,
• release and version control Action Language,
• release and version control Archetype Language,
• release and version control Pattern Language while allowing users to plug their own alternative into OOA Tool,
• and release initial Java Software Architecture for translating a project into a standalone Java application.

And finally, I would love to hear from anyone interested in Shlaer-Mellor or Executable UML. Especially anyone thinking about using either on a real project.

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.

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.