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.
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 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.
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.
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.
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
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.
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.
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.
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.
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}
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.