It's been a busy month traveling to three cities in three weeks to give workshops. On the last of these I was accompanied by Karl Frank (kfrank@togethersoft.com), another of the Coad Certified Mentors at Togethersoft. During a rather indifferent, evening meal at a 1950's style diner (Yes - it really did look like something out of the old Happy Days television series), we discussed the correlation between the role labels that may be specified on the end of associations in UML and the yellow Role classes found in Pete's Domain Neutral Component. The following short set of notes is the result. I hope you enjoy them.

Have fun

Steve

ps. see Coad Letter #68 for an introduction to the Domain Neutral Component and class archetypes.

From Associations To Domain Neutral Component

Labeling UML Associations Imagine two parties (persons or organizations) are related to each other. We can represent this in an UML class diagram by connecting both ends of an association to a Party class. We may label the association with the name of the relationship. In addition, we may also label each end of the association with the role played by the party in the relationship.

A corresponding object diagram looks as follows - two objects of the Party class with a link drawn between them.
Examples: 1. A person and organization related by an employment relationship with the organization playing the employer role and the person playing the employee role.
2. Two parties related by a sale with one party playing the buyer role and the other playing the seller role. In this case the relationship is no more than a business transaction involving the two parties. (We could view a ongoing business relationship as a set of interactions and/or transactions between two parties.)

Using a Class to Represent a Relationship Where there is more to a relationship than a simple name -- when there are attributes and operations that are specific to that relationship -- we can add a class with those attributes and operations in between the two parties.  For a business relationship it is highly likely that we will need to track the start and possibly the duration of the relationship so the new class belongs to the Moment-Interval (pink) class archetype.

Examples: 1. Attributes specific to an employment relationship include such things as start date, salary and amount of paid leave. Operations might include calculating the length of employment or calculating the amount of leave left, for example.  2. The attributes you find in a Sale class include the cost, receipt or invoice number and possibly the status of the sale. Operations may include calculating discounts, tax, etc.

Using Classes for Roles

We can also apply the same reasoning to the role labels on the association. Where there are attributes and operations that are applicable to the role being played instead of the party or relationship then we can add a classes to represent the party roles. Now we have a generic class model shape that looks as follows - Party connected to PartyRole connected to Moment-Interval.  Personal note: An object modeler named Marc Sewell first introduced me to this object model shape. He called it the triad pattern; it was my first encounter with a domain neutral pattern of any sort.

Examples:

1. For employment we add an Employee role class and an Employer role class to capture information specific to the role and provide operations that can iterate over all the associated Employment objects. The Employer class may include an employer's tax code attribute and an operation to pay employees. The Employee role class could have an operation to total income across multiple jobs and/or over a period of time like the tax year.

2. We can do the same for the sale model. If we also add classes for the things being sold and the place where the transaction is happening, we have Party connected to PartyRole connected to Moment-Interval connected to both Place and Thing

Place and Thing Roles

Using similar reasoning, let's add PlaceRole and ThingRole classes to our model. Place roles allow a property to play the role of a store and/or a warehouse and/or a residence for example. Thing roles allow an aircraft to play a military role and/or a civilian role for example.

Until now we have been considering situations where we need to track both parties in a relationship or Moment-Interval. Now let's generalize to allow for situations where the second party is not tracked (e.g. a typical customer in grocery store). Now we have a Moment-Interval connected to PartyRole, PlaceRole and ThingRole classes that are connected to Party, Place and Thing respectively. The model is starting to take on a familiar shape.

The Domain Neutral Component

If we compare the shape of the object model above with the Domain Neutral Component there are only a few items missing. Add the blue description classes for the Party, Place and Thing classes, a MomentIntervalDetail to represent parts of a sale and we have all the classes in the Domain Neutral Component.

Conclusion

We have seen that the core of the Domain Neutral Component can be derived from a general association by replacing its label and roles with classes. Knowing this it should be less of a surprise when we see the Domain Neutral Component's pattern occurring again and again in our domain models. Of course, the Domain Neutral Component and archetypes also provides us with typical attributes, operations, interactions and interface plug-in points.

References

Coad, De Luca, Lefebrve, Java Modeling in Color with UML, Prentice Hall 1999 (www.togethersoft.com/jmcu)