Advanced Domain Modeling  Architecting for Agility with Color Models

By David J. Anderson, June 2004

Introduction

In 1999, Peter Coad introduced the concept of using colors to signify archetypal behavior for UML classes in a domain (or business) model [Coad 1999]. He went further and suggested that the colored archetypal classes typically formed a pattern which he dubbed the Domain Neutral Component (DNC). Color modeling was the culmination of over a decade of work in object-oriented theory for Peter Coad. Throughout those years, he had been seeking methods to enable the building of frequent, tangible, working results. Modeling and its derivative  code re-use  were at the heart of his attempt to create a truly agile method for software engineering This paper will present some of the history of domain modeling in color and the DNC with a brief explanation of its origins and effectiveness. A five year update on the technique will follow. It will show that the DNC provides a strong and robust architecture which withstands change with minimal refactoring and minimal regression effect across the rest of the model. This is the essence of enabling agility with object-oriented functional architecture  a fast, reliable, elegant modeling technique which maps directly to implementable code whilst gracefully accepting change even late in the development cycle.

History of Modeling in Color

1992 Object-oriented Patterns

In 1992 Peter Coad published his first work on recurring patterns in object-oriented analysis [Coad 1992] in the Transactions of the ACM and later in the same year at OOPSLA. This was the beginning of the patterns movement in object-oriented technology which was to gain greater prominence in the mid-1990s. This first paper contained the object inheritance pattern Item  ItemDescription as shown in Figure 1.

Figure 1. Object Inheritance Pattern Item  ItemDescription

In this pattern, the Item inherits its catalog description, price and any logic or rules which calculate the price from its ItemDescription class. This pattern provides a more flexible and loosely coupled form of reuse for the business rules which calculate price. The ItemDescription class could also be thought of as a table-driven class where an editable table holds the data for description and price.

1995  Patterns combining Patterns

By 1995 Coad and his collaborators [Coad 1995] had discovered that some of their earlier simple two class patterns often appeared together in larger patterns. Figure 2 shows the combination of the Role  Transaction pattern with the Item  Item Description pattern. With the introduction of this larger pattern, the industry begins to move towards a meta-model for describing business domains.

Figure 2. Role  Transaction  Thing  Description Pattern from 1995

Spring 1997  Moments or Intervals of Time

In Spring of 1997, the 2^nd edition of Object Models: Strategies, Patterns and Applications [Coad 1997] was published and the pattern from 1995 had been modified with the concept of a transaction being widened to include any moment in time or period of time such as a warranty period, a period of employment, a loan approval request or a disbursement of funds. The concept of a Thing was also broadened to include a Party (Person or Organization) and a Place. Peter was also now using UML notation and the meta-types of Role, Moment-Interval, Party|Place|Thing and Catalog Description were now being signified with UML <<stereotype>> tags as shown in Figure 3.

Figure 3. Role  Moment-Interval  PPT  Catalog Description Pattern from 1997

September 1997  Color is Introduced

The world was to change in September 1997 and significant progress would become possible after the introduction of color to signify the meta-types or "stereotypes" as Coad and his collaborators were then calling them as shown in Figure 4. The sequence of four meta-types was now being referred to as the "mega-pattern" for want of a better name.

Figure 4. The Mega-Pattern showing 4 <<stereotype>>s in color

January 1999  Final Revision of Java Modeling [Coad 1999]

Modeling in color was one of two highly significant developments which came out of Peter Coads work in Singapore - the other being the agile method Feature Driven Development (FDD). In late, 1998 the team in Singapore were helping Peter to complete his new book and document the color modeling technique. With some heavy influence from the work of David Hay [Hay 1996] and strong encouragement from one member of the team  Philip Bradley  the term stereotype was dropped in favor of the more accurate archetype  though stereotype tags in UML were still used to signify the archetype. Archetype is taken literally from the die or mold from which others are cast. In common usage it means something from which all others more or less follow. The recurring pattern of colors was defined into a general purpose shape dubbed the Domain Neutral Component (DNC) as shown in Figure 5.

Figure 5. The Domain Neutral Component 1999

The DNC epitomized the goals for an agile domain modeling framework. It was elegant. It communicated clearly with its different colors for different purposes and its three legs for connections to Parties, Places and Things. It offered a framework which allowed for easy repeatable modeling with a minimal number of classes  enough to get the job done and no more whilst at the same time it was built on years of foundation work which insured it was loosely coupled, easily extensible, maximized re-use through object inheritance and robust to change.

Much of benefit from the DNC is not immediately obvious as it required an understanding of much of the foundation work which enabled it. Over the last 5 years, Stephen Palmer and I have sought to illuminate the power of the DNC through a series of newsletters published at The Coad Letter, now part of the Borland Developer Network. The remainder of this paper summarizes much of that work and seeks to explain why the DNC is so powerful and why the color modeling technique is so agile and productive.

Why Archetypes Make Sense

Archetypes would be of little value, if there were not a recurring pattern across classes of the same archetype  an archetypal inheritance (or, meta-model inheritance). Classes of the same archetype share similar looking (or sounding) methods and similar attributes as shown in Figure 6.

Figure 6. Archetypal Behavior

This understanding of archetypal behavior helps us to understand what is possible with our model and system and to easily offer many features to the customer without additional modeling work, refactoring or addition of extra classes. It is possible with a color model to quickly map terms in a domain to the elements on the DNC. It is then possible to map the archetypal method names and attributes to those classes. This allows a modeler to quickly enumerate the features possible with a set of domain classes. Using a tool such as Together Control Center these can be quickly turned into working Java code stubs. The customer can then assess which features are required for a system release and these can be coded. Other features can be ignored. However, if these are needed later, they can be added without the need for refactoring or regression testing. Archetypal behavior is the first agility enabler in color modeling.

Where Do Roles Come From?

Another often asked question in color modeling is, "where do roles come from?" and "why do I need them?" With a start from a blank page and add classes approach to modeling, there is a tendency to omit roles (or fail to see them or their usefulness). The color modeling approach asks us to design by take-away. Start by mapping all the domain terms into a DNC model then where you have an archetype but no domain term challenge it and see if you can take it away  remove it from the model. Perhaps you will discover that keeping it provides opportunities for re-use.

Roles Provide Object Inheritance across Transactions

Roles provide another layer of object inheritance. Where a green Party, Place of Thing class can inherit attributes and behavior from its associated blue Description class, so too can a yellow Role class inherit attributes and behavior from a green Party, Place or Thing class. Roles act as proxies for green classes in specific transactions and are generally named for the transaction, moment in time or period of time with which they ineract. Figure 7 shows a typical class inheritance hierarchy which shows behavior that is specific to two different transactions being separated into sub-classes of the super-class Person. This encapsulates the Person related behavior for each transaction into the sub-class  a desirable effect in object-oriented design. However, it fails to provide the opportunity for re-use. Figure 8 shows an alternative model where class inheritance is replaced with object inheritance. This allows the transaction specific behavior to be re-used by another green class  in this case, an Organization or corporate entity.

Figure 7. Banking Behavior through Class Inheritance

Figure 8. Banking Behavior re-use through Object Inheritance

Roles enable re-use and future flexibility. The cost and risk of including a role class is very low but the longer term benefits can be high. Figure 9 shows how it is possible to create many Roles for Parties, Places or Things. There should be a specific Role class for each pink transaction or Moment or Interval of Time with which the green class interacts. The Role class becomes re-usable by any other green class of the same sub-type (i.e. Party, Place or Thing) which wishes to interact with the pink class.

Figure 10. Roles create re-use through Object Inheritance

Figure 10 shows how it is possible to break out behavior for participation in many transactions or other moments or intervals of time into role classes  one role for each pink class in which the green class wants to participate. This pattern first appeared in [Coad 95] as Actor-Participant. Todays nomenclature is cleaner and less overloaded against Use Case language. A Person (or other green class) plays a role in a transaction or other moment or interval of time (pink). Roles use object inheritance to acquire the properties and behavior of their associated green class, in this case Person.

Pluggable Components

Roles also offer us the possibility of creating pluggable components for a truly decoupled enterprise component system. In order for re-usable components to be truly re-usable they must be decoupled from (have no or little knowledge of) the systems in which they participate. In order to create re-usable Parties, Places or Things, we need to provide the green classes with some core infrastructure. They need to be able to hold a collection of abstract Roles (whether by superclass or interface) as shown in Figure 11. Whether a particular green can (or is allowed to) play a role is determined by the rules in its Description blue class. Further the description can be made flexible and runtime reconfigurable by the addition of a plug-in interface which allows particular policies to be hot loaded. In Figure 11, the Person class code is completely independent and has no knowledge of the pink classes with which it may in future interact. Breaking out yellow role classes enables enterprise level reuse. Roles and their associated Moment-Intervals are reusable across core green and blue components, whilst core green and blue classes are reusable across applications within the enterprise.

Figure 11 Runtime Defined Roles and Role Playing Policies

Figure 12 shows the sequence diagram for adding a yellow Role class to a very generic and loosely coupled green class. Some generic code in the green class will delegate to its description for a decision on whether or not the particular role can be added.

Figure 12 addRole() method Sequence Diagram

Subsequent Roles

Sometimes it is possible to hard code some role playing relationships because it is only possible to play a role if the role player (the green class) can already play a particular role. These roles are known as subsequent roles. In Figure 13, a Person must be playing an employee role before they can become a SystemUser and they must in turn be a SystemUser before they can become any of Cashier, Admin, Manager or InventoryClerk. The advantage of this pattern is that it is easy to code and requires no policies or rule description classes. However, the disadvantage of is the rules are hard coded and less easily changed. Hence, it is important to understand a domain fully before committing to the subsequent role concept.

Figure 13. Subsequent Roles

Getting the Blues

In the original DNC (Figure 5) only green Party, Place or Thing classes had blue catalog-like Description classes. Description classes provide what Martin Fowler [Fowler 1997] described as the "knowledge layer". They provide meta-data which describe the classes to which they attach. At the time, "the coloring book" [Coad 1999] went to press, Coad and his collaborators had a strong suspicion that other classes in the DNC could have Descriptions but it was too late to change the book prior to publication. Stephen Palmer corrected this with a Coad Letter [Palmer 2001b] over 2 years later. Both pink Moment-Interval classes and yellow Role classes can technically have Descriptions because meta-data about them may prove to be useful. The use of blue Descriptions is an alternative to class inheritance. It is loosely coupled and can potentially be changed at runtime. Hence, the blue association is very powerful when you need a flexible system. One area Ive found it to be useful is telecom grade applications where rules may change but deploying code in a telecom network is expensive and difficult. Hence, it makes sense to deploy the code once and allow the meta-data, rules and policies to be altered at runtime without any code changes or need to regression test the system. Figure 14 shows a wireless telecom example where the pink class models the period for a service agreement between the wireless carrier and the subscriber. The blue ServicePlan class describes the terms and conditions for the period of the ServiceAgreement.

Figure 14 A pink Moment-Interval with a blue Description

Technically yellow Role classes can have descriptions too. However, this is seldom used. One application for it would be to soft-code the policies for playing subsequent roles. This would avoid the disadvantage of the code in Figure 13 where the subsequent roles are hard-coded.

Whole-Part Relationships

In the original DNC, there was little said about whole-part or aggregate relationships with the exception of the Moment-Interval collecting MI-Details. What immediately strikes us about the model in Figure 15 is the whole-part relationships. A Hotel can have one or more rooms. If it didnt have any rooms at all, by definition, it wouldnt be a hotel. A Conference can have many Sessions and again by definition, if there werent any sessions it wouldnt be a conference. A Hotel can also have a description, for example, Sheraton, or Hilton. The description includes a list of the hotel facilities and their quality. The HotelDescription can in turn have RoomDescriptions which describe the facilities for types of rooms available at that type of hotel.

What should also strike you about this model is that color is inherited from the containing class. A green contains greens! A blue contains blues! And, pink contains pinks!

Figure 15. Whole Part-Relationships in a DNC Model

Object Inheritance across Whole-Part Relationships

There are two types of object inheritance at work in this model. The first type works across the model from left to right. A Hotel inherits behavior and default attributes from its HotelDescription, for example, the brand and the class of the hotel and perhaps its rack rate pricing. A ConferenceVenue inherits behavior and default attributes from its Hotel, for example, the address and name of the venue. Similarly, the same left to right object inheritance is at work on the lower row of the model. A Room inherits some behavior and default attributes from its RoomDescription. A SessionVenue inherits some behavior and its default attributes from its Room, for example, occupancy limit which is may turn be inherited from the RoomDescription.

The second type of object inheritance on this diagram is bottom to top. A RoomDescription may inherit attributes from its containing parent, HotelDescription, for example, the class of the room or level of dicor may be inferred from the parent. A Room may inherit default behavior or attributes from its containing parent, Hotel, for example, address, or telephone number (without extension). A Session may inherit behavior or default attributes from its containing parent, Conference, for example, the name of the sponsor.

Role Composition

There is no composition or aggregation relationship shown for the yellow role classes in Figure 15. It is certainly possible to model roles as containing other roles. It seems to fit with the notion of subsequent roles and object inheritance. However, I have never found yellow composition useful. The role of Roles is to connect greens to pinks in a loosely coupled fashion. Features associated with this relationship typically need to message from pink to green or green to pink through a role. If they need to go up a level of containment then this is best done through their containing pink or green parent.

Color Difference across Whole-Part Relationships

Some color differences across a whole-part relationship can be OK because they actually reflect an optimized DNC model. Consider the model in Figure 16 showing a Sale from a typical retail environment and the Items in the sale and their catalog entries, ItemDescription. Note that this is an aggregation relationship rather than a composition relationship. In fact, there is strong argument that a simple association would be the correct relationship. Items can exist outside of a Sale. Hence, composition is definitely inappropriate. Note also that the parent role cardinality is shown as 0..* because an Item may be sold more than once. In a domain such as vehicle retailing, the same vehicle may be sold several times over its lifetime. For example, luxury brand retailers such as Mercedes or BMW will often retail the same vehicle 3 or 4 times over a 10 year period. The serial number did not change. It is still the same vehicle. Hence, the model shown requires a zero to many relationship to the Sale object.

Figure 16. Retail Model for Sale or Items

Modeling in color could be described as the art of take-away rather than the typical object modeling approach of add classes until complete. If we started with the DNC and attempted to model a retail sale, then the model in Figure 17 would be much closer to our result.

There are several things to note in this example. Firstly, the aggregation under Sale has changed to a composition relationship. A SaleItem <<MI-Detail>> would not exist without its containing Sale <<Moment-Interval>> object and hence we have a pure containment relationship which can be signified with the solid diamond in the object model. We have also introduced the somewhat awkwardly named ItemInSale <<Role>> class. What is this doing?

As stated earlier, roles separate out behavior for specific transaction interaction from the original Person, Place or Thing class. This provides for cleaner, simpler classes. It provides a more loosely coupled model and facilitates re-use. For example, if we wanted to re-use the Item class in a system for distribution or delivery then we do not have to carry the baggage of the retail transaction code with us. That code has been delegated out into the ItemInSale <<Role>> class.

Figure 17. DNC compatible Retail Model

It is a key lesson that the Domain Neutral Component is a very loosely coupled architecture which facilitates distributed component architecture. By using the modeling by take-away approach, you maximize the chance of re-use and minimize the coupling of the model. Every time you take away a colored class on the model, you are making a choice to limit flexibility and increase coupling in the system's functional architecture. In exchange you have less classes on your model. The Model in Figure 16 is not wrong but it is more tightly coupled and this may create problems later which would require refactoring of code.

The use of color gives us a strong visual clue. The model in Figure 16 looks different. It doesnt look like a DNC model because the colors are in the wrong sequence. This is telling us that we have sacrificed some flexibility and added some coupling to the architecture. It is then up to our judgment to decide whether or not we should add back the other classes which are missing to complete a DNC facsimile. Advocates of extreme programmings approach of doing the simplest thing which will work for the current story may prefer the model in Figure 16. The model in Figure 17 is more forward looking but adds little risk or complexity.

Some combinations remain just plain wrong as shown in Figure 18 and should set off the alarm bell for the modeling team. As a general rule question all aggregation or composition relationships which change color across the collection.

Figure 18. Some unnatural color combinations

Subsequent Blues

In [Nicola 2001] Jill Nicola et al, introduce an idea similar to and derived out of the work of Peter Coad which they call collaboration patterns. Collaboration patterns happen between pairs of classes which inherit some meta type, for example, Item - Specific Item, Place  Outer Place, and so forth. Often classes in models play roles in several collaboration patterns, i.e. they collaborate with more than one other class. This leads to the notion of multiple meta-type inheritance e.g. a class can be both a Place and an Outer Place at the same time. In Figure 13 for example, Employee would be both a Role and an Actor at the same time. This has caused confusion for color modelers because it implies that a class ought to have more than one color.

As shown in Figure 13, color modeling adopts the notion that all Roles are Roles first and foremost and adopt the yellow color. If they have Subsequent Roles they are still Roles.

A similar problem occurs with blue Description classes where there can be multiple layers. The example in Figure 19 shows that a model of Mobile Phone can in turn have a description for its Manufacturer. It may also have other descriptions for its radio compatibility e.g. CDMA or GSM. Several layers of knowledge are possible depending on the domain. As a general rule, Descriptions are always Descriptions even if they have Subsequent Descriptions and hence take the blue color as shown in Figure 19. This leaves us with a single layer of green sandwiched between potentially multiple layers of blue and yellow. What this is telling you, is that the green classes represent the fundamental physical objects in a domain and have the highest desirability for re-use across applications within that domain. More recently, Martin Fowler has coined the term assets for these fundamental elements in a domain. This term seems both particularly succinct and appropriate. Hence, only assets would be green and we might prefer to use the stereotype tag <<asset>> to signify a green class.

Figure 19. Subsequent Blues in a Wireless Telephony Application

Class or Object Inheritance?

When talking about Descriptions, we often find ourselves using the word 'type'. A BMW 528i is a type of car; the actual BMW 528i sat on the driveway of my friendly lawyer neighbor is an object, an example, a specimen or instance of that type. Deciding when it is appropriate to use object inheritance from green to blue or when it would be more appropriate to use class to provide reuse within a type hierarchy is a tricky business which involves tradeoffs.

Figure 20. Object and Class Inheritance in Combination

Using a blue Description class to represent different types we can very easily create a new type in a running system by creating a new instance of our Description class and configuring its attributes accordingly. Using subclassing we need to code a new class and deploy it before we could create objects of the new type. Using blue classes allows us to postpone decisions until runtime rather than compile time.

However, blue Descriptions have their limitations; if different types actually have different attributes instead of just different values of the same attributes it quickly becomes messy or over complicated to use a Description class and subclassing is usually the better option. The same is true when different types need different operations; if only the algorithm of one or two operations differ then use a plug-in strategy as seen in Figure 11 and 21.

Figure 20 demonstrates that object versus class inheritance is not a mutually exclusive choice. There are domains where a combination provides the best solution.

Color and Class Inheritance

Note in every example of class inheritance, Figures 7, 10, 11, 13, and 20 that the color of the super-class is always inherited by the sub-class. By definition a sub-class has an is a relationship with its super-class. Hence, if the super-class is a green, then the sub-class must also be a green.

Types of Blues

I've found over the years that many developers struggle to understand what a blue Description class is. With some it's easy, you say "table-driven" and they get it. With others they look blankly back and struggle with the concept. I've found that blue classes come in three basic types and that a single blue class could exhibit behavior from one, two or all three of those types  enumeration, meta-data, collection of business rules or policies. In addition, blue classes can be used to achieve the Strategy Pattern [Gamma 1995] through the use of a plug-in algorithm. Figure 21 shows blue Description classes being used in non-traditional roles as rules collection, strategy implementer and an enumeration.

Figure 21. Blues playing Rules Collection, Strategy Implementer and Enumeration

Law of Demeter in the DNC

The Domain Neutral Component is usually drawn with static associations. Consider the version of the DNC in Figure 22 which shows the dynamic dependencies in the form of <<use>> relationships between the classes in the DNC. Note how each class only holds dependencies to its immediate neighbors. This is at the heart of the agile nature of color modeling and the flexibility of the Domain Neutral Component. Building a loosely coupled functional architecture in this fashion minimizes the future impact of change and minimizes the regression effect when code needs to be refactored. It also facilitates lean software development by allowing decisions on coarse-grained componentization and the interfaces of coarse-grained components to be postponed until the last responsible moment. The result is a significant reduction in refactoring effort.

Law of Demeter

The Law of Demeter was first proposed by Ian Holland of Northeastern University, Boston, MA, in 1987. It was named after the project on which the style guide was first adopted. The law states,

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

Or: Each unit should only talk to its friends; Don't talk to strangers.

Figure 22. DNC showing <<use>> dependencies

Figures 23 and 24 show the sequence diagram for the Feature, list the availability of hotel conference venues for a given hotel chain and set of dates. The first diagram is Law of Demeter complaint and does not add any additional dependencies across the DNC compliant model. The second is not!

Figure 23. LoD Compliant list availability of hotel conference venues

Figure 24. Tightly coupled alternative list availability of hotel conference venues

The first diagram has a side-effect that intermediate classes grow large method signatures as they delegate responsibilities. Many developers intuitively prefer the second sequence. However the first sequence offers us a small price to pay for flexibility. It costs almost nothing at runtime and has little effect during development time as unit testing simple messaging methods has little overhead or opportunity for defects. The benefit from LoD compliance comes later when we need to package classes or define coarse-grained distributed components.

Coarse-Grained Component Definition from the DNC

The DNC truly shows its agility and compatibility with Lean Thinking [Womack 1996] when you consider its ability to postpone the definition of packages or component boundaries. By maintaining a strict adherence to the Law of Demeter whilst designing and implementing Features across a color model, it is possible to leave decisions on larger components to the last responsible moment. This is a bottom-up approach to component definition rather than the traditional top-down approach.

Component Definition Ambiguity

What tends to happen at the beginning of the architecture work on a distributed system is the team makes a high level attempt to define a set of components from a sketchy understanding of the domain. Then in a traditional modeling approach, they will try to define the interface or set of services provided by each component  again this is being done with a sketchy understanding of the domain. Typically, this component definition is done before domain modeling and may in larger companies be done by a different team. Its a top-down approach. The components definitions may later be distributed to geographically dispersed teams who are asked to develop the interior of the component. This technique of defining interfaces is considered a best practice because it mitigates risk and encapsulates the implementation of individual components. It allows for parallel development with low risk. It is based on the underlying assumption that the interfaces do not need to change and that the component boundaries are correctly drawn in the first instance.

What gets many distributed computing projects into trouble is that these component boundaries are often ill-conceived and either they become a burden - a drag on development and an impediment to reuse - or they require refactoring later. Why is this so?

As each team begins to analyze the requirements for their piece of the system in depth, they struggle with understanding precisely what fits within their scope resulting in debate about the responsibilities of their component. Often as they gain a deeper and better understanding, they decide it is better to delegate some responsibilities to other components. This results in communication across teams and more than likely a refactoring of the agreed interface. This causes confusion, delay and may impact quality, which in turn causes further delay.

Postponement and Lean Software Development

In manufacturing industry, the concept of postponement is well understood. Postponement means leaving a decision as late as possible. This has been shown in lean manufacturing to minimize inventory levels, and reduce lead times, whilst improving customer satisfaction. Postponement means designing a product such that fickle end user choices, such as color, or shape, or fabric, or pattern, or user interface such as language settings, can be committed as late as possible. No manufacturer wants to be left with a large inventory of purple widgets because they were caught by a consumer sentiment change and purple is suddenly last years color.

The DNC facilitates postponement of component boundaries

One fear held by developers, is that, if they do not do a high level, top down, component definition but simply jump in to a requirements wide domain model, then they will simply be left with one big monolithic system which cannot be sub-divided readily without massive refactoring  and there will never be time for that.

However, the Domain Neutral Component and the color modeling technique are designed for optimal loosely coupled systems which can easily be componentized. With the DNC, every class is treated as a component and every method on every class is a service that class is providing. Through application of the Law of Demeter [Anderson 2004], each class holds dependencies only to its immediate neighbors. In a typical DNC model, that means that most classes hold relationships only to 2 or 3 others. This means that it is easy to define coarse-grained component boundaries later. All that is required is minor impact refactoring to resolve any two-way dependencies. The interface of the coarse-grained component will inherit the methods from the classes on its boundary which are available to classes which now reside in a different coarse-grained component. Figure 25 shows the guidelines for packaging or componentizing a DNC model.

Figure 25. Guidelines for Packaging classes in a DNC Model

We could draw the DNC as a coarse-grained component model like the one in Figure 26.

Figure 26 DNC drawn in Component Packages

The example in Figure 26 shows explicitly the desired one way dependency direction where a Moment-Interval component is dependent upon a set of Party, Place or Thing components. In turn a series of subsequent Moment-Intervals is always dependent on its predecessor. This allows for new business processes  series of pink Moment-Intervals  to be added to an enterprise computing framework without the need to rework existing components in the framework. Figure 26 also includes the use of a Factory which can make the next Moment-Interval component for a current one, removing the potential two-way dependency between a Moment-Interval and its subsequent Moment-Interval.

Resolving Two-way Dependencies

Figure 27 shows a typical Java solution to resolving two-way dependencies. In this case, it is desired to break the relationship between a yellow Role ConferenceVenue with its green Hotel. We want the transactional behavior in ConferenceVenue to be dependent on the Hotel class because we do not want our re-usable green Hotel class to need to know much about holding conferences  that behavior is in the ConferenceVenue class. We could have a Hotel booking system which does not handle conferences and conference functionality is to be added in a later release. Figure 28 shows the package level diagram for the same model fragment.

Figure 27 Resolving Two-way dependency between Role and Place Archetypes

Figure 28. Package Diagram of Figure 27

Summary

Domain modeling in color is a technique which was developed over a decade collecting best of breed techniques in object modeling and object-oriented design. It is a craft which is best learned by doing and it takes time to become fully competent at it. However, the power of the four color archetypes makes it a technique which is easily taught and easily learned to a basic level of competence. The DNC eliminates the class discovery problems of older approaches  no need to list verbs and nouns and then debate which nouns are candidates for classes. Its model by take-away approach leads to far better quality results from novice modelers than the older add classes until done approach. DNC models can be easily formulated from reading a requirements document and mapping the terms in the document to the four class archetypes. As such, the DNC provides a reliable, repeatable and transferable technique for building highly robust, reusable models which are resilient to change and embrace the principles of agile and lean software development.

In my experience, color modeling can produce fast high quality results which provide an order or magnitude performance improvement over techniques advised in the mid-1990s. Domain modeling in color is agile modeling.

About the author

David J. Anderson is the author of the recent book, "Agile Management for Software Engineering  Applying the Theory of Constraints for Business Results" published in Peter Coad's series by Prentice Hall PTR in September 2003. He is Principal Consultant with VA Systems Professional Services. David was one of the team which created the popular agile development method, Feature Driven Development. He has introduced FDD at two Fortune 100 companies Sprint (a telecommunications operator in the United States) and Motorola. He writes the regular Agile Management column at the Borland Developer Network website and publishes his weblog at http://www.agilemanagement.net/.

He holds a degree in Computer Science and Electronics from the University of Strathclyde.

Email: fddmanager@yahoo.com

References

[Anderson 2003] Anderson, David J., Agile Management for Software Engineering  Applying the Theory of Constraints for Business Results, Prentice Hall, Upper Saddle River, NJ, 2003

[Anderson 2004] Anderson, David J., The Coad Letter: Color Modeling and the Law of Demeter, Borland Developer Network, 2004

[Coad 1992] Coad, Peter, Object-oriented Patterns, Communications of the ACM, Volume 35 page 152, September 1992

[Coad 1995] Coad, Peter, Mark Mayfield and David North, Object Models: Strategies, Patterns and Applications, 1^st Edition, Yourdon Press, Prentice Hall PTR, 1995

[Coad 1997] Coad, Peter, Mark Mayfield and David North, Object Models: Strategies, Patterns and Applications, 2^nd Edition, Yourdon Press, Prentice Hall PTR, 1997

[Coad 1999] Coad, Peter, Eric Lefebvre and Jeff De Luca, Java Modeling in Color with UML: Enterprise Patterns and Process, Yourdon Press, Prentice Hall PTR, 1999

[Fowler 1997] Fowler, Martin, Analysis Patterns, Addison Wesley 1997

[Gamma 1995] Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns  Elements of Re-usable Object-oriented Software, Addison Wesley 1995

[Hay 1996] Hay, David C., Data Model Patterns  Conventions of Thought, Dorset House 1996

[Nicola 2001] Nicola, Jill, Mark Mayfield and Mike Abney, Streamlined Object Modeling  Patterns, Rules and Implementation, Prentice Hall PTR, 2001

[Palmer 2001a] Palmer, Stephen R., The Coad Letter #76: Modeling User Roles, Borland Developer Network, http://www.thecoadletter.com/ 2001

[Palmer 2001b] Palmer Stephen R. , The Coad Letter #82: Description Class Archetype, Borland Developer Network, http://www.thecoadletter.com/ 2001

[Palmer 2001c] Palmer Stephen R., The Coad Letter: Reference Number Attributes, Step-10 Limited, http://www.step-10.com/

[Womack 1996] Womack, James and Daniel Jones, Lean Thinking  Banish Waste and Create Wealth in Your Corporation, 2^nd Edition, Free Press 2003