UML Distilled: Applying the Standard Object Modeling Language
by Martin Fowler with Kendall Scott
Chapter 1: Introduction
Chapter 2 : An Outline Development Process
Chapter 3: Use Cases
Chapter 4: Class Diagrams: The Essentials
Presented by Allen Harper
In this introduction Fowler lays out the sequence of events that led to the consolidation of the three OO methods of Grady Booch, Jim Rumbaugh and Ivar Jacobson thus creating the UML. Included in this paper is an article from the ACM Communications that details this history.
The real question that is raised here is why do analysis and design
in the first place. After all the result of software development
is the production of code—the rest is just pretty pictures. Fowler
points out that there is no empirical evidence to prove that UML is a good
or a bad technique.
This lightweight process consists of four stages named inception, elaboration, construction and transition. Inception is the time to sit down with the person who is initiating the project. This might be a high ceremony meeting in front of the board of directors or a low ceremony meeting in an informal setting. This is where a developer gets the overall idea of what the project is about, its size, scope and maybe a feeling for the political climate that the project will be conducted.
Elaboration is the stage in the project when the requirements must be specified in detail. At this stage, the developer has been given only vague instructions. The pertinent questions to be answered are 1) What is going to be built; 2) How is it going to be built; 3) What technologies are going to be used to build the system.
Fowler argues that the elaboration phase of a project is driven by the need to determine the risks of the project. He breaks the risks down into four categories 1) Requirements risks; 2) Technological risks; 3) Skills risks; and 4) Political risks. Requirements Risks
UML techniques have a major part to play during the specification of the project requirements. Use cases drive this phase of a project. They are the method of communication between users and developers. During the elaboration phase of a project, one of the most important tasks is the identification of all the use cases. Use cases are gathered by meeting with users and finding out how they view the system. It is the actions of the user in the context of the system that makes up a use case. During this phase, a developer starts the process of modeling the system from a conceptual level. During their interviews, users may used words such as “customer,” “service,” etc. Combining these concepts with the use cases that are coming up in the interviews a picture of the system begins to emerge. Fowler uses the term domain model to describe this model that is dealing with the parts of the system at a high level.
At this point in the design there are two models: the use case model
and the domain model. The next model to be developed is the design
model, which starts to include classes and the behavior that resides in
the use cases. Fowler recommends that class diagrams and activity
diagrams be used to build the domain model.
The whole process of elaboration is nearing completion when several
conditions occur. The first is when the developers start to feel
comfortable with their time estimates for each use case and the second
is when the developers think they have identified all the major risks and
have a plan to deal with them.
Now that the use cases have been categorized, it is time to calculate the length of the standard iteration of the construction cycle. Fowler suggests that the length of iteration be long enough to complete a handful of use cases. Next comes the calculation of the amount of effort needed for each iteration. Fowler assumes that developers are only coding 50% of the time, so if the length of iteration is 3-weeks and the team has 8 developers then the effort per iteration is: 3 x1/2 x 8=12. Dividing the total of time estimates for all the use cases by the effort per iteration yields the first estimate of the number of iterations that the project will need.
The next step in planning is to assign use cases to iterations. If a use case has a high user assigned priority, architectural, and/or schedule risk it should be dealt with early on.
Refactoring is a technique to repair the code base after you have
added on new functionality during iteration.
One of the major reasons for doing iterative development is that
it gets the team used to hitting the completion dates and avoiding the
demoralizing effects of schedule slippage.
Only use iterative development on projects that you want to succeed.
In their essential form, a use case represents a single action that a user can take. A typical use case in a RDBMS would be “update the record” and in a word processor it would be “change the font size to 12 point.” A use case then can be seen to illuminate a function, to be simple or complex, or to highlight a single goal of the user.
Fowler further divides use cases by focusing on whether they are predominantly system interactions or user goals. For example, “update the record” is not a user goal, but instead the user telling the system to copy data from one location to another. The user goal would be something more like “keep my client data up to date.”
The importance of this distinction is that it can be used in the design
process. User goals are important for considering various ways to
satisfy the user. System interactions are better for planning.
1. An actor is a role played by a user in the software system.
2. Actors carry out use cases.
3. One actor may execute many use cases.
4. One use case may be performed by many actors.
5. Actors do not need to be human—they might be external systems.
The fifth item on the list causes a great deal of confusion
among developers. Different philosophies exist as to how to model
external systems in use case diagrams. One way to handle external
systems is to include all interactions. Another way is to only include
interactions initiated by the external system. A third possibility
is to call external systems actors if they need to use an internal resource.
Finally, some developers feel that viewing systems as actors is the incorrect
focus altogether.
Another issue related to use cases is their granularity.
Ivar Jacobson gives a figure of 20 use cases in a 10-person-year project
while Fowler states that one a similar size project he had more than 100.
The reason for the difference is that Fowler is using much finer grained
use cases—each one is handling a smaller amount of work than Jacobson’s.
Fowler uses Table 4-1 and Figure 4-2 to illustrate the proliferation of terminology and notations that existed in OO methods prior to the UML. The simplification of this situation is the driving force behind the UML.
Before getting involved in actual diagramming Fowler makes a distinction in the way that class diagrams can be used. While his distinctions are not part of the UML, he maintains that they are very valuable.
Fowler identifies three perspectives--conceptual, specification, and implementation--for looking at a diagram, with each one being appropriate to a particular design stage.
The conceptual perspective, as its name implies, is when the diagram just deals with the concepts that exist in the system. This perspective is at such a high level that it can be viewed as language-independent. While the concepts are modeling the eventual classes at this perspective, there is not a one-to-one correspondence between them.
The specification perspective is involved with the
interface level of the software but not with the implementation.
The focus at this level is the type and not the class.
The implementation perspective deals with the actual code
that comprises the class. Fowler states that this is the most frequently
used perspective when developers are drawing class diagrams.
Which perspective is being used is crucial for interpreting a class diagram correctly. The problem is that developers blur the lines and combine perspectives. Class diagrams should be drawn from a clear perspective and a designer should be aware of which perspective the diagram is drawn from when making interpretations.
The following is a description of the terminology associated with class diagrams. The relationships between instances of classes are indicated by associations. For example, a Customer has an Order. Each association has two roles with each role being a direction on the association. In this case, one role is between the Customer and the Order and the other is between the Order and the Customer. In reading class diagrams, the source is the class where the role starts from and the target is the class where the role ends. Roles also have multiplicity. This indicates how many objects there are in a relationship. Common multiplicities are 1, * and 0..1 where 1 indicates only 1 object, * indicates many objects, and 0..1 indicates only 0 or 1 object may participate in the relationship. If association lines have arrows then we are implying that navigability which can be uni-directional or bi-directional. Attributes can be viewed as small classes, like strings, dates, etc. Attributes that cannot be changed are labeled immutable. Operations are the actions that classes know how to carry out. In the UML the syntax of an operation isvisibility name (parameter list): return type expression{property string} where visibility are indicated as + for public, # for protected and – for private. Name is a string, parameter list is optional and contains arguments, return type is an optional language-dependent specification and property string indicates property values that apply to the given operation.
Generalizations occur in design when classes have many similarities but can still be seen as distinct. The mechanism of the generalization allows the designer to separate the classes at one level, but treat them the same at another level of the design. This relation is called subtype to supertype. Another way of viewing this relationship is that everything we can say about the supertype is also true of the subtype. In other words, we can substitute any subtype object for the supertype without any breaking the model. Constraints also play a large part in the drawing of class diagrams, but they are not part of the UML. They may be indicated informally or might be present in the form of an invariant or even source code.
Now that we have outlined Fowler’s ideas of perspective and the
terminology for class diagrams we can analyze Figures 4-1 and 4-3.
Starting with the class for Customer, we can see that it has an association
with class Order. This association is 1 to * meaning that a Customer
may have more than one Order in the role Customer to Order. In the
role Order to Customer it means that an Order may only have 1 customer.
In the Customer class we see that a Customer has two attributes, name and
address, and one operation creditRating() which returns a string.
In the role Order to Order Line we can see that the role is named line
items, the multiplicity is 1 to * and a constraint exists on thee customer’s
credit rating. Finally, looking at the association between Corporate
and Personal Customers and Customer we see that a generalization exists
between them. What this means is that Customer is the supertype and
Corporate Customer and Personal Customer are the subtypes. Each of
the subtypes may be substituted into the model wherever there is a request
for an object of Customer type.
The important question that we have been addressing in this class is whether the UML is such a significant improvement on the previous technologies to bring about more than a fractional improvement in the process of software development.
After analyzing the method outlined in this paper, which bears striking similarities to the one proposed by Brooks 25 years ago, I think that you would agree that the method is not a “silver bullet.”
Since we still have 7 more chapters of this book to cover, I think
that we will have to hold off judgment as to whether the UML by itself
will be capable of solving the software crisis.