Title: UML Distilled: Applying the Standard Object Modeling Language
Authors: Martin Fowler with Kendall Scott
Publisher: Addison-Wesley
Reviewer: Allen Harper
Chapter 1: Introduction
The Unified Modeling language is the “winner” of the methods war. After years
of fighting among the competing methods camps, the UML was selected by the OMG to
be presented to the ISO for approval as the international standard for object-oriented
modeling.
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.
2
Chapter 2 : An Outline Development Process
The UML is not a method. A method has both a modeling language and a
process. The UML is a modeling language. So what process should a developer use?
Fowler answers by stating that the UML can be used with any process that the developer
is comfortable using. Of course Booch, Rumbaugh, and Iverson are writing their own
process called the Rational Unified Process (RUP) and Fowler uses an outline of this
method that parallels RUP throughout the book.
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
3
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.
Technological Risks
The main issues in this category that need to be addressed by a developer are
knowing that the technology you are using can do the job, knowing how to use the
technologies individually and how to integrate them, and planning for a failure of one of
the pieces you are using.
Skills Risks
Make sure that all the critical staff are well trained and experience using the
technologies that you propose to use. One way or another this money will be spent so
spend it up front.
4
Political Risks
Fowler has nothing to say on this point but strongly recommends that all projects have a
member with experience with corporate politics.
Baseline Architecture
One of the milestones of the elaboration phase is establishing the baseline
architecture of the system. This consists of the list of use cases, which indicate the
system requirements, the domain model, which captures a view of the business and
indicates the key classes in the system, and finally the technology platform, which
indicates the key pieces of technology that will be used and how it will be integrated.
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.
Planning
This is a pre-construction phase where all the use cases are enumerated, and categorized
for a number of features. First, the use cases are categorized according to how important
it is to the users. This categorization determines the importance of each use case to the
project. Next, the developers assess the architectural risk of each use case. That is how
difficult is this use case to implement and how well will it integrate into the system later
on if its construction is delayed. In addition, the developers should assess the schedule
risk of each use case. This is a measure of how confident the developers are about their
time estimates. Take note that Fowler says the developers should do the time estimates
on the use cases and not the managers.
5
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.
Construction
This is the phase where the system is built in a series of iterations. Each iteration
is a small project as the use case is further analyzed, designed, coded, tested, and
integrated. Each iteration is finished with a demo of the system and all system tests are
performed. Remember, warns Fowler, integration and system testing are large jobs and
should never be left to the end of a project. System testing should be done by a separate
group outside of the development team.
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.
6
Chapter 3: Use Cases
Use cases are not a new tool in software development. Developers have always
used informal scenarios to specify how to handle different them to outline different
pathways through the software. It was not until Ivar Jacobson created his Objectory
method that use cases became a formalized and documented part of the software
development process. In the UML use cases are integral to the software development
process.
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.
Use Case Diagrams
In addition to his work on use cases, Jacobson also developed the use case
diagram, which is now a part of the UML.
Actors
7
Summary of the actors:
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.
Extends Relationship
In a use case diagram arrows can be marked with <<extends>> which means that
the origin of the arrow does everything that the destination can do and then something
more. In other words, the origin does a variation on the standard theme.
Uses Relationship
In a use case diagram, arrows can also be marked with <<uses>> which means
that the origin of the arrow does the same thing as all the other origins pointing to the
same destination and nothing more. In other words, they all share a use case.
8
Scenario
This is one of those vague terms that is used extensively, has many meanings and
predates the UML. In relation to the UML a “scenario refers to a single path through a
use case…” For example, a use case for ordering a product on-line has more than one
path. The item might be out of stock, the credit card rejected, etc. Each of these paths
through the order process use case is a scenario.
Realizations
Different models of the system functionality will exist depending on how you
plan to delineate you use cases. In the UML, these are called realizations.
When to Use Use Cases
Fowler is quite clear on this point: always. In fact isolating use cases is one of the
primary tasks of the design phase of any software project, but the developer must be
aware of the possibility that use cases can appear at any time during the project. In fact,
use cases are so important that some developers try to list all the use cases before they do
any modeling.
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.
9
Putting It All Together in a Use Case Diagram
Turning to Figure 3-1, we see how some of the use cases of a financial trading
system are captured in a use case diagram. The trader actor uses the use cases “Analyze
Risk,” “Price Deal,” and “Capture Deal.” Of course, a trading system probably has more
than one trader just as it probably has more than one salesperson. Additionally, notice
how both the Analyze Risk and the Price Deal use cases use the Valuation use case. For
this reason the arrow is labeled <<uses>>. In a similar fashion the Limits Exceeded use
case is labeled <<extends>> because this use case does everything that the Capture Deal
use case does but it also can handle the exceptional situation.
10
Chapter 4: Class Diagrams: The Essentials
Class diagrams are central to OO-methods and are a part of every OOA&D
system. A class diagram does two things. It describes the types of objects that are in the
system and it delineates the static relationships that exist between the objects. In general,
there are two kinds of static relationships: associations and subtypes. In addition, these
diagrams can show the methods and attributes of a given class as well as the constraints
that exist on the relationships between objects.
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.
11
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 is
visibility name (parameter list): return type expression{property string}
12
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
13
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.
14
Conclusion
The UML combined with an effective process solves many of the problems that
have plagued the field of software development since the introduction of object oriented
technology 20 years ago.
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.
15