Object Modeling Using Archetypes and Color in UML - PracticesThis article provides an overview of the practical application of object-oriented analysis and design (OOAD) design concepts and the Unified Modeling Language (UML). It is taken from chapter two of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259)
print this article SEARCH DEV SHED |
An insightful and useful technique that hasn’t received the level of recognition it deserves is the use of color, as proposed by Peter Coad in his book Java Modeling in Color with UML: Enterprise Components and Process (Prentice Hall PTR). The color in UML technique hinges on the notion of an archetype, which is a concept similar to the concept of a stereotype in UML with the difference being in the rigidity of the definition and its effect on the target class. An archetype is a way to tag a class as something that more or less adheres to a certain set of characteristics. (This is a looser definition than inheritance for example.) Coad started using 3M Post-it Notes, which come in four colors, pink, yellow, blue, and green, to label model elements. Coad assigns a color to each one of the archetypes or class categories. The addition of color gives you a sense of spatial layering that enables designers to quickly capture both structure and behavior and helps you to see dynamism in an otherwise static class diagram. Coad defined the following four main archetypes and associated them with four colors:
The four basic archetypes are interconnected in a way that repeats over and over in models. This pattern in its simplest form entails a PPT playing a role in a moment-interval, which might affect other PPTs. PPT also might have descriptions associated with them. In this pattern physical entities such as PPT never interact directly but instead are participants (as role players) in an activity. For example, in the conference attendee example a person (party) is an attendee (role) in the context of a conference (moment-interval). The temporal relationship between the conference and the person is fulfilled by the attended role. This basic pattern is depicted in Figure 2-7.
Figure 2-7. Basic relationships between the Coad archetypes As you’ll see later in more detail the main formula is to find an activity (moment-interval), find the participants in that activity (roles), and find who or what is playing that role (party, place, or things). You begin by making a list of possible m-i classes that are central to the system in question. Eventually you’ll arrive at a model for which all classes belong to one of the four archetypes. Table 2-4 shows your initial list of m-i candidates. As you can see you started at the highest level and moved toward moments-intervals of finer and finer detail. For example, at the highest level you have the conference as the top m-i class. Conference is an m-i class because it’s something that happens over a period of time and can be tracked for legal and business reasons. You can also see that your four main stakeholders are roles played by either a person or an organization of some kind.
A more encompassing set of interconnections between the four basic archetypes is the domain-neutral component (DNC), which is a template built upon the four archetypes based on roles being played by the three different entitylike elements (PPTs): party, place, and thing. This results in a template model with three legs or branches: the party branch, the place branch, and the thing branch. The DNC, as originally introduced by Coad, is shown in Figure 2-8.
The result is a flexible, semantic-based class diagram template that you can use to build any kind of model. The best part is that it’s remarkably simple to use. You don’t have to fit your model into the DNC, rather, the DNC will guide you to make your model more complete. The trick about using the DNC is an understanding that archetypes are very flexible definitions, and that elements of the DNC template can be dropped out to simplify the model. Basically you start with a very complete model and progressively collapse or drop archetypes as you go along. This takes a bit of effort in the beginning because programmers tend to model interactions or temporal relationships between elements as a method in one of the participating elements. The DNC and the four archetypes hinge on the notion of representing these relationships as elements themselves. You might be asking yourself where we’re going with all this color stuff. The truth is that it takes a bit of time and a couple of models to begin to grasp the power of the technique. But once it sinks in it will help you produce better, more accurate, and complete models. To an extent it’s a completeness theorem of sorts, especially when it comes to modeling. That’s the main goal of the technique—to make you a better modeler.
blog comments powered by Disqus |
Oracle Releases Communications Data Model 11.2.5
