The Party, Place, Thing class archetype is one of four class archetypes in Peter Coad's ' modeling in color' technique.
Parties, places, and things are the main role-players in which we are interested. These are the individual people, organizations of various kinds (companies, charities, government agencies, schools, churches, etc), buildings or locations, and other individually identifiable objects that participate in one or more ways in the Moment-Intervals captured in our software.
Figure 1: The Party, Palce, Thing Class Archetype
In business systems, the candidates for Party, Place, Thing classes are the actual people and organizations with whom we conduct business, the actual places we go to conduct business, and the individual things we give and receive in the course of that business. They are the people, organizations, places and things that participate in some way in our system and that we need to track. They are the role-players in our object model. In the classic board game, Cluedo (Clue in the USA), we have six characters with names like Colonel Mustard and Mrs. White that could have played the role of murderer, nine rooms that could be where the muder was committed and, therefore, the place plays the role of crime-scene, and six items that could be the murder weapon.
Finding Party, Place, Thing Classes
The party role-player classes for are typically Person and Organization. These are often, but not always, modelled as sub-classes of an abstract Party class (or implement a Java-style interface called Party). The super-class/interface is only of genuine value when there is significant genuinely common properties and behaviour that can be placed in the super-class/interface. Frequently, in business, individuals are treated very differently from organizations, and even properties like name and contact information differ considerably in the details. This makes the use of a Party superclass/interface less useful in practice than it might initially seem.
Typically a place is some identifiable location where Moment-Intervals that we are interested in happen. We look for where parties or things come to rest, containers of things, and departure points and destinations of journeys and movements.
A thing is a distinct entity participating in a Moment-Interval that is not a party and not the location where the Moment-interval is occurring. If parties answer the question of who is involved in a Moment-Interval and places answer the question of where a Moment-Interval occurs, then things are the answer to the question of what else is involved in a Moment-Interval.
Like all the class archetypes, the usefulness of the Party, Place Thing class archetype in reviewing and building object models is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
The Class Archetype Formerly Known As...
In 1997, Peter Coad, with David North and Mark Mayfield, published the second edition of their book, Object Models: Strategies, Patterns, & Applications. Page 435 describes a small object model pattern called 'Actor-Participant'. Today this is reflected in the Party, Place, Thing and Role class archetypes. In Streamlined Object Modeling: Patterns, Rules and Implementations, Jill Nicola, Mark Mayfield, and Mike Abney refer to the same collaboration as the 'Actor-Role' pattern.
It would seem intuitive to call the people and organizations that play roles in our software, actors [Coad 97]. Unfortunately, the term, actor, has been defined in UML to mean something that does not map to an individual person or organization as a role player. In UML an actor is far closer to what we usually call a role. So to avoid causing any more confusion than has already been caused by the abuse of the term in UML, we stick with the term role-player when modelling with class archetypes.
Another name sometimes suggested for this archetype is Entity but there are two arguments against using this term. Firstly it is already in use in the data-modelling world and although our parties, places and things naturally map to entities in data modellers' Entity-Relationship diagrams, the converse is not necessarily true. Secondly, the name Party, Place, Thing neatly reminds us that this archetype comes in three flavours, a fact that is of significance in the various analysis patterns involving class archetypes.
The Party, Place, Thing Class Archetype
The third of the four class archetypes defined by the modeling in color technique, is the Party, Place, Thing class archetype. These classes model someone or something who plays different roles. They are the role players. If Roles classes are the hats, then Party, Place, Thing classes are the hat wearers. If you can converse with it, pick it up, or stand in it, then it is likely to be an example of a party, place or thing.
Typical Responsibilities of Party, Place, Things
Like all the class archetypes in modeling in color, the true usefulness of the Party, Place, Thing class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
The Description Class Archetype
The fourth and last class archetype defined by the modeling in color technique, is the Description class archetype. This class archetype models a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description. It categorizes objects of other classes according to different values.
Reference Number Attributes in Class Archetypes
Each of the four class archetypes has a set of attributes that we might typically expect to find in classes belonging to that archetype. In each case, this set includes some sort of reference number attribute. While they all might seem very similar, and serve similar purposes, some subtle differences exist.
Accelerated Problem Domain Analysis
Peter Coad's 'Modeling in Color' technique uses the idea of class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with modeling in color. Domain experts and developers work together on a daily basis to build an overall, initial, 'just enough' domain model that is then used to build a much better initial product backlog or features list.
Model Archetypes and Domain Neutral Components
Linking together the typical associations between class archetypes presents us with a pattern of classes we call a model archetype or domain neutral component. We can display this with the Party, Place, Thing class archetype as a single class to give a basic model archetype. Alternatively we can explode the Party, Place, Thing class into its three flavors and produce a larger more comprehensive domain neutral component that is even more useful. Model archetypes can be used to rapidly build new problem domain models or review and revise existing problem domain models.
Class Archetypes, UML and Color
Class archetypes can be used without the color coding quite happily. Color can be used to highlight items in diagrams with great effect without the use of class archetypes. The combination of the two, however, provides a much deeper means of communication. The color-coding 'layers' into the diagram. It provides a means to quickly and effectively engage with a non-trivial diagram. You can 'step back' from the diagram and examine the patterns of linked colored classes, 'zooming in' on textual detail as needed. After modeling in color for a while, you wonder how you were ever satisfied with black and white diagrams.
From UML Association to the Domain Neutral Component
Karl Frank and I were in Denver, USA, giving a modeling in color workshop for a client. One evening Karl asked me what if any relationship I thought there was between roles in the Domain Neutral Component (DNC) and role labels on a UML association. The subsequent discussion sparked a train of thought that further convinced me of the simple, effectiveness of using the domain neutral component.