A problem domain (pd) class represents a 'real world' concept such as sales, invoices, people, places and things, rather than technology concepts such as user interface windows, pages, panels and controls, database rows, tables, connections and transactions, and network services and messages. Often referred to as defining the business objects or business logic of the software, problem domain classes model the concepts, ideas and rules within our software that are left after stripping away the stuff specific to the technologies we are using. They form the heart of a piece of software.
Modeling in color is an object modeling technique. It helps identify and define appropriate, problem domain classes for a software component, application, or system.
Problem domain classes form the most important logical layer of the software in a conventional object-oriented software application, or system. In more component-based or service-oriented software, problem domain classes help drive the definition and organization of business services and components. They also help drive the design of the problem domain classes used in the internal implementation of a component or service.
Regardless of whether the software is conventional, component-based,
or service-oriented, nearly all modern software architectures require a
significant number of technology classes to support each problem domain
class. As shown in
figure 1:
- User interface classes, typically organized as some variant
of the venerable Model-View-Controller
and Command
patterns, cater for the display and manipulation of pd objects by human
users of the software.
- Persistence classes, or configuration files for a persistence
mechanism such as Hibernate, ADO.Net Entity
Framework, and Core
Data, handle the mapping, storing and retrieving of pd objects from
files on disk or relational database.
- Classes for services (web, API, etc) and their parameters provide
the means for other components, or external systems to integrate and
interact with pd objects across a network.
Figure
1: A PD class can require a significant number of supporting technology
classes
While not every pd class requires so many supporting technology
classes, significant pd classes may require more because they appear in
multiple views,
participate in multiple services, and be persisted in different
ways at different times. The whole thing is further complicated by
the relationships and dependencies between pd classes, such as the
products within a sale for a customer, or the items in a delivery made
by a supplier. The average
number of supporting classes for a pd class
can easily reach a dozen or more. This is without considering any
related unit, integration and system test classes and scripts.
Despite best-practice encapsulation, changes to a pd class
frequently ripple
through the supporting classes.
Small refactorings (renaming an operation for example) are automated
within modern integrated development environments (IDE) such as Eclipse, NetBeans, Visual Studio
and XCode.
More significant changes (removing an attribute, changing a
relationship from one-to-one to one-to-many, making a relationship
bi-directional, for example) still typically require manual updates and
retesting of a number of classes, configuration files and required
supporting artifacts.
Some amount of change is inevitable, but any patterns or strategies that enable earlier identification of more robust problem domain classes are obviously worthwhile learning. This is precisely what the 'modeling in color' technique provides, especially for business and industrial I.T. components and systems.
First used on a major Java software development project in Singapore
in 1997 and building on his previous work on object-oriented analysis
and design patterns and strategies, Peter Coad, researched and refined
the technique over the
next couple of years. In 1999, Peter Coad, and
co-authors, Eric Lefebvre, and Jeff
De Luca, published an introduction to technique in their book,
Java Modeling in Color with UML.
Other acknowledged contributors to the technique and related FDD
process include Phil Bradley,
Jon Kern, Mark
Mayfield, David North, and myself.
Class Archetypes
The modeling in color patterns and strategies are built around the
idea of class archetypes.
In business systems, the same general kinds of significant problem
domain class keep appearing, no matter what the domain. For example, we
nearly always find classes that represent business
transactions or interactions of different types such as sales,
orders, rentals, bookings, scheduled events, deliveries, submissions,
approvals, inquiries, etc. Then we generally find classes that
model the parties, places, and things that participate in those
business transactions or interactions, the
people or organizations doing the buying, selling, ordering,
submitting, approving, etc. In addition, the products and services
being bought, sold, approved, etc., need to be represented, as do the
places like
shops, bank branches, websites, etc., where all this happens. These
general kinds of classes are not specific to a domain. It does not
matter whether the problem domain is banking, insurance, retail,
manufacturing, human resources, travel, transportation, or something
else, the same general kinds of classes keep on appearing. The
different kinds of class are independent of the domain. They are domain
neutral.
It is not just business systems where these kinds of class appear. In industrial systems we have classes modeling specific types of event and intervals of time such as changes in state of a sensor or switch, a period of time over which a measurement is taken, the length of time a piece of equipment is ramping up to a certain level of performance, and so on. Again, there are also typically, party, place, and thing classes representing the sensors and devices themselves, human operators supervising the equipment or process in question, and the locations of the various pieces of equipment, etc.
The similarities between all the classes of one of these
rough
categories are not close enough to be generalized into a useful
superclass or Java/C#-style interface. However, the similarities are
close
enough for them to help guide the choice and definition of problem
domain classes in
our designs. Modeling in color calls these rough categories, class
archetypes, the term archetype
supposedly representing a less rigid pattern and, therefore, being a
more appropriate term than stereotype.
Modeling in color recognizes four class archetypes and assigns each a
color.
Figure 2: Modeling in color defines
four class archetypes for problem domain classes
The four class archetypes as shown in figure 2 are:
- The Moment-Interval
class archetype that models something
that one needs to
work with
and track for business and legal reasons, something that occurs at a
moment in time or over an interval of time. [Coad99]
Examples of Moment-Interval classes include Sale, Rental, Order, Journey, Flight, Meeting, Booking, Murder, Sensor Reading, Alarm Activation, etc.
Moment-Interval classes are pink (pastel red). They represent happenings that take place that our software is interested in, interactions and business transactions between people, places and things.
In other words, if it happens, it is pink! Pink happens!
- The
Role
class archetype that
models a way of
participation by a party (person or organization), place or, thing.
[Coad99]
Examples of role classes include Applicant, Account Holder, Approver, Pilot, Cashier, Customer, Supplier, Operator, etc.
Role classes are pastel yellow in color. They represent recognizable ways that people, places, and things participate in moment-intervals (happenings) in our software. Roles are sets of responsibilities and duties that we are able and authorized to perform. We often talk about ourselves as wearing multiple or different hats when we are expected to perform multiple or different roles. Role classes model those hats, and those hats are always yellow.
We wear yellow hats!
- The Party,
Place, Thing
class archetype that
models someone
or something who plays different roles.[Coad99]
Examples of Party classes are Person and Organization. Examples of Place classes include Office, Store, Warehouse, Airport, Bank Branch, etc. Thing classes are those that identify individual items such as individual cars, airplanes, DVD's, books, pieces of equipment, etc.
Party, Place, Thing classes are pastel green in color. If Role classes are the different (yellow) hats that can be worn, then Party, Place, Thing classes are the wearers of those hats. Obviously, people play roles but places can too. A building might have a role as a restaurant another as a crime scene. Things can also play roles, a role in a manufacturing process, and a role in a sales process, for example. If it you can converse with it, be taken to court by it, move it, kick it, sit on it, or stand in it, then it is likely to be a green Party, Place, Thing.
Hats are yellow but those that wear them are green!
- The Description
class
archetype that 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. [Coad99].
Examples include classes representing product descriptions of all kinds. The difference between a blue and green is the difference between a film and the DVD's on which the film is recorded.
Description classes are pastel blue in color. Description classes categorize or label other stuff depending on different values, typically objects of Party, Place, Thing classes but occasionally Moment-Intervals too. The industries that companies work within are objects of a Description class. The models of a car in a show room are objects of a Description class. The titles of books sold by Amazon.com are objects of a Description class.
The labels you use to catalog stuff like this, are always blue!
Typical Responsibilities
Because classes of the same class
archetype model roughly the same
sort of thing, their objects generally need to remember similar sorts
of bits of information and perform similar sorts of tasks.
For example, objects of a Moment-Interval class generally remember the
date and time
they occurred and can tell you if they completed successfully or not.
Objects of a Role class typically need to remember some sort of
identifier they have been given that authorizes them to perform that
role, a pilot's license number, for example, and so on.
By examining numerous examples of each class archetype and generalizing slightly we can create a rough list of typical operations and attributes for each class archetype. Each attribute or operation in the list represents a typical kind of operation or attribute that we might expect to define for classes of that archetype (see Figure 3).
Figure 3: The four class archetypes each have typical attributes and operations
Few if any of the classes in a particular model will have examples of all the typical attributes and operations of their class archetypes. If a particular typical attribute or operation is not relevant for a specific class we simply do not define an equivalent attribute or operation for that class. For example, some Moment-Interval classes need the concept of relative priorities and will have the equivalent of a priority attribute. Other Moment-Interval classes do not.
Each typical attribute or operation of a class archetype may match multiple attributes or operations on a specific class. For example a Moment-Interval may need both a major and minor status attribute if it has a complex lifecycle.
The lists of typical attributes and operations are not exhaustive either. Our classes will attributes and operations that are not in the relevant archetypes list. For example a Party class modeling an individual person may contain a retention date indicating when data must be erased to comply with some legal requirement. No equivalent for this attribute exists in the Party, Place, Thing class archetype.
The typical attributes and operations of a class archetype are simply a list of suggestions for specific attributes and operations that we might need in our actual class definitions. They act as prompts and hints of things we should consider when creating or reviewing a class belonging to a particular class archetype.
Another way to think of this is that each operation or attribute of a class archetype acts as a reminder of a typical responsibility for classes of a particular class archetype. If we can identify the class archetypes of the classes in our problem domain, the lists of typical operations and attributes give us a check-list that can help us review or place responsibilities appropriately in our own models. For example, the first attribute in each of the class archetypes is some sort of identification or reference number. This reminds us that objects of classes belonging to any of the class archetypes have a responsibility to enable themselves to be matched to the real-world object that they represent. For example, a cash sale object will typically remember a receipt number as its reference number so that it can be matched to the particular transaction it models. Objects representing cashiers may be required to remember a user name to match them to their human counterparts when they login, and so on.
The fact that class archetypes have a name, a list of typical attributes, and a list of typical operations means we can represent class archetypes graphically in the Unified Modeling Language (UML). We simply reuse the same notation as we do for the specific classes that belong to the class archetypes, as shown in Figure 3.
Model Archetypes
To fulfill their responsibilities
objects frequently need to
collaborate with objects of the same or other classes. Therefore, many
of the typical responsibilities in class archetypes imply typical
associations with other classes and typical ways of interacting with
objects of other classes. These typical associations and typical
interactions of their objects enable us to combine class archetypes
into archetypal, problem-domain object models. These model archetypes
or domain neutral components act as general repeating patterns for our
analysis and design models.
Figure 4:
The four class archetypes link together into the basic model archetype
Figure 5:
The basic model archetype expands for
each flavor of Party, Place and Thing into a larger Domain Neutral
Component
Using the Domain Neutral Component (DNC) can really help speed up the building of our problem domain object models. Start by identifying one or more Moment-Interval classes in the particular problem domain of interest. Then for each of these in turn, overlay the DNC. Step through each item in the DNC turn replacing it with items specific to this particular problem domain or dropping it if there is no equivalent in this problem domain or it is simply not needed in model.
The DNC can also be very useful in
reviewing existing models. First, color in the model by assigning
archetypes to each
class. Then challenge and justify deviations and omissions from the
DNC. However, remember that the DNC is a pattern not a meta-model. A
meta-model defines a rigid set of rules for creating compliant models.
The DNC does not do this. It is much looser, a set of suggestions and
hints. Justifiable deviations from the pattern are allowed, expected,
and essential in many cases.
When they first encounter it, many
people, are a little skeptical
about how applicable the DNC is in practice. I certainly was.
There are two reasons I think that the DNC is much more applicable than
maybe first expected. Firstly, most business systems are centered on a
particular business event or activity or a flow of events and
activities in the form of a business process. The Moment-Intervals
model these business events and activities. For each business event and
activity there are typically different people or organizations involved
in different ways. The events and activities usually take place at some
location even if, these days, that location is somewhere in cyberspace.
Frequently business events and activities are about buying, selling,
assigning, and moving things. The Roles and Party, Place, Things
model the who, where and with what of the
business events and activities. The Descriptions model different sets
or categories of the Party, Place, Things involved in the events and
activities. In addition, the emphasis on the Moment-Intervals first,
followed by Roles, role players , and Descriptions helps counter a
tendency to center things around and concentrate too much on role
players as one might in more traditional Entity-Relationship
Diagramming
(ERD).
The second reason why I think that the DNC is much more applicable than maybe first expected is a line of thinking triggered by a discussion with an old colleague of mine from TogetherSoft and Borland, Karl Frank. When you step back and think about it for a while, you realize that the DNC is in essence a natural expansion of a UML association between Party, Place and Thing classes. The Moment-Intervals are similar in many ways to the idea of an association class and the Roles are a similar idea applied to the role names found on the ends of the association.
Over the years, I have incorporated a number of minor changes to the DNC in comparison to that presented in the Java Modeling in Color with UML book. Read more about these changes...
Color Coding Class Archetypes
Although class and model archetypes can obviously be effective without color, it is the color coding that gives the technique its name. The color coding has proved so beneficial in practice that it is well worth the little extra effort required to use it.
The color makes it easier to learn and remember the class archetypes. It also makes the class archetypes easier to identify in a non-trivial UML class or sequence diagram. When you are new to object modeling or not frequently involved in object modeling, it can be very off putting when first presented with a complex diagram. The color makes it easier to engage with the diagram. This helps people such as a project's customers and end users contribute better in the modeling process. For example, they can easily identify and initially focus on pink Moment-Interval classes representing the business interactions they are interested in and work outwards from there.
Much of the benefit derived from using object-modeling techniques is in the ability to communicate complex analysis and design more easily (something that seemed frequently forgotten and lost in the long, detailed object modeling phases of the late 1990's and the subsequent design of the UML 2.x specification). The careful use of color dramatically increases that ability for UML class and sequence diagrams to communicate.
For those interested in why the use of color works so well, Color Coding Class Archetypes has a further discussion on the use of color, including what colors to use for each class archetype.
For most, it is enough to learn and remember that the four class archetypes are usually assigned the following colours:
- Moment-Interval classes are a
pastel shade of pink.
Pink happens!
- Role classes are a pastel shade of
yellow.
We always wear yellow hats!
- Party, Place, Thing classes
are a
pastel shade of green.
The wearers of the yellow hats are green!
- Description classes are a pastel
shade of blue.
You give stuff blue labels!
Next Steps
Armed with the general appreciation of the technique and ideas behind it, it is time to delve a little deeper and uncover more about each of the four class archetypes:- Read
more about the Moment-Interval class archetype
- Read
more about the Role class archetype
- Read
more about the Party,
Place, Thing class archetype
- Read more about the Description class archetype
Free 'Modeling in Color' Resources
'Modeling in Color' support for a number of popular UML modeling tools
Read more about this...
Four Logical Layers
One of the most common initial strategies for selecting the types of object needed in a software system, service or component is to define a set of logical layers into which we can place candidate classes. There are various layering schemes but they are generally variations of a similar theme. The problem domain or business layer is the most important.
Read more about this...
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.
Read more about this...
The Moment-Interval Class Archetype
Modeling in color defines four archetypes. The first of these, the Moment-Interval class archetype, models something that one needs to work with and track for business and legal reasons, something that occurs at a moment in time or over an interval of time. It represents significant interactions between people, places an things. If something happens and we are interested in it, it is usually an object of a Moment-Interval class.
Read more about this...
The Role Class Archetype
The Role class archetype is the second of the four class archetypes defined by the modeling in color technique. Role classes model a way of participation by a party (person or organization), place or, thing. We sometimes talk of people wearing more than one hat when they have multiple responsibilities. Roles model those hats.
Read more about this...
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.
Read more about this...
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.
Read more about this...
Typical Responsibilities of Moment-Intervals
Like all the class archetypes in modeling in color, the true usefulness of the Moment-Interval 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.
Read more about this...
Typical Responsibilities of Roles
Like all the class archetypes in modeling in color, the true usefulness of the Role 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.
Read more about this...
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.
Read more about this...
Typical Responsibilities of Descriptions
Like all the class archetypes in modeling in color, the true usefulness of the Description 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.
Read more about this...
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.
Read more about this...
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.
Read more about this...
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.
Read more about this...
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.
Read more about this...
Historic Values
In business software it is often necessary to remember the values of objects at the time a business transaction took place. For example, the price of a product may change over time and it may be necessary to remember the price used in a sale of the product. There are two fundamentally different ways of satisfying this requirement and a good number of variations between the two extremes
Read more about this...
Moment-Intervals and GoF State Pattern
The Moment-Interval class archetype lists a status attribute as a typical attribute for this kind of class. The Gang of Four State pattern provides an alternative to a simple attribute for implementing state-driven behavior. In fact, there are a number of interesting comparisons and differences between the GoF State pattern and Moment-Interval classes that can be made.
Read more about this...
Modeling People, Organizations and their Names and Ids
People! They make things so complicated! Some days it seems like the only thing more frustrating than people, are the organizations that they have created or for which they work. Producing software that models people and organizations flexibly and efficiently is a real challenge even when using modeling in color.
Read more about this...
FDD and 'modeling in color' Workshops
Help give your next software development project a better start, or correct the course of a wayward project. Now available in the USA, UK, and continental Europe.
Read more about this...