| Role | Moment, Interval |
| Description | Party, place, thing |
UML color standards are a set of four colors associated with Unified Modeling Language (UML) diagrams. The coloring system indicates which of several archetypes apply to the UML object. UML typically identifies a stereotype with a bracketed comment for each object identifying whether it is a class, interface, etc.
The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.
A stereotype is one of three types of extensibility mechanisms in the Unified Modeling Language (UML), the other two being tags and constraints. They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular domain or otherwise specialized usage. The nomenclature is derived from the original meaning of stereotype, used in printing. For example, when modeling a network you might need to have symbols for representing routers and hubs. By using stereotyped nodes you can make these things appear as primitive building blocks.
Contents
These colors were first suggested by Peter Coad, Eric Lefebvre, and Jeff De Luca in a series of articles in The Coad Letter, and later published in their book Java Modeling In Color With UML.
Peter Coad is a software entrepreneur and author of books on programming. He is notable for his role in defining what have come to be known as the UML colors, a color-coded notation chiefly useful for simplifying one's understanding of a design or model.
Jeff De Luca is a global information technology strategist and an author in the field of software development methodology. He is considered the primary architect of Feature Driven Development (FDD) circa 1999 [^JDLBIO], a lightweight methodology for developing computer software with reduced management overhead, time and money.
Over hundreds of domain models, it became clear that four major "types" of classes appeared again and again, though they had different names in different domains. After much discussion, these were termed archetypes, which is meant to convey that the classes of a given archetype follow more or less the same form. That is, attributes, methods, associations, and interfaces are fairly similar among classes of a given archetype.
In computing, an attribute is a specification that defines a property of an object, element, or file. It may also refer to or set the specific value for a given instance of such. For clarity, attributes should more correctly be considered metadata. An attribute is frequently and generally a property of a property. However, in actual usage, the term attribute can and is often treated as equivalent to a property depending on the technology being discussed. An attribute of an object usually consists of a name and a value; of an element, a type or class name; of a file, a name and extension.
In object-oriented programming, association defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf. This relationship is structural, because it specifies that objects of one kind are connected to objects of another and does not represent behaviour.
Protocol is a term used by particular object-oriented programming languages with a variety of specific meanings, which other languages may term interface or trait.
When attempting to classify a given domain class, one typically asks about the color standards in this order:
- pink
- moment-interval — Does it represent a moment or interval of time that we need to remember and work with for legal or business reasons? Examples in business systems generally model activities involving people, places and things such as a sale, an order, a rental, an employment, making a journey, etc.
- yellow
- roles — Is it a way of participating in an activity (by either a person, place, or thing)? A person playing the role of an employee in an employment, a thing playing the role of a product in a sale, a location playing the role of a classroom for a training course, are examples of roles.
- blue
- description — Is it simply a catalog-entry-like description which classifies or 'labels' an object? For example, the make and model of a car categorises or describes a number of physical vehicles. The relationship between the blue description and green party, place or thing is a type-instance relationship based on differences in the values of data items held in the 'type' object.
- green
- party, place, or thing — Something tangible, uniquely identifiable. Typically the role-players in a system. People are green. Organizations are green. The physical objects involved in a rental such as the physical DVDs are green things. Normally, if you get through the above three questions and end up here, your class is a "green."
Although the actual colors vary, most systems tend to use lighter color palettes so that black text can also be easily read on a colored background. Coad, et al., used the 4-color pastel Post-it notes, and later had UML modeling tools support the color scheme by associating a color to one or more class stereotypes.
Many people feel colored objects appeal to the pattern recognition section of the brain. Others advocate that you can begin a modeling process with a stack of four-color note cards or colored sticky notes.
The value of color modeling was especially obvious when standing back from a model drawn or projected on a wall. That extra dimension allowed modelers to see important aspects of the models (the pink classes, for instance), and to spot areas that may need reviewing (unusual combinations of color classes linked together).
The technique also made it easy to help determine aspects of the domain model – especially for newcomers to modeling. For example, by simply looking first for "pinks" in the domain, it was easy to begin to get some important classes identified for a given domain. It was also easy to review the standard types of attributes, methods, and so on, for applicability to the current domain effort.
