We believe that Applying UML and Patterns succeeds as the candidate for this 'single, best book' because it provides:

• A good, solid introduction to the full UML notation.
• An excellent explanation of the object-oriented development process.
• An introduction to object-oriented software patterns.
• A single, coherent example application, methodically developed to show the application of the UML notation, object-oriented development process, and software patterns.

In addition, the book is concisely written. This stands in contrast to many books on the subject which can lose their readers quickly, either because they are long-winded or wander from the point.

Teaching

Larman's book is also ideally suited as the basis for teaching a course on UML and object-oriented analysis and design. Objects by Design has a very successful college course built largely around this text. In fact, we have proposed to the author that he promote his methodology in a number of different ways, with a view toward ultimately establishing a curriculum for certification. After all, there are certifications for competency in many computer disciplines; why shouldn't object technologists be subjected to the same standards? For more on UML certification, see our article UML Certification?

Process?

The major, understated achievement of Larman's book is its successful exposition of an object-oriented development process. This achievement is understated probably because the process doesn't even have a name to call it by. Maybe the author didn't want to take credit for practices which have been informally established in the industry for a while. In the author's own words, "This book presents a sample development process which describes a possible order of activities and a development life-cycle. It does not, however, prescribe a definitive process or method; it provides a sample of common steps."

We beg to differ. We believe that object technology as it stands today has under emphasized the key role played by process in the development life-cycle. The UML notation, without a process, is just too confusing for most developers. If there is a candidate to fill this role, by all means let's recognize it. To this end, we took a crack at a summary of Larman's process.

The Dice Game

The best way to jump start a description of a complex process is to provide a capsulized example at the outset. Larman's dice game example is cute because, while it is a pretty miniature application, it successfully shows the basic process: use case, conceptual model, collaboration diagram, and class diagram. Students, being a generally impatient and skeptical breed, need to be convinced that object-oriented analysis and design is worth the effort. After all, it is much easier to 'hack' together a piece of software (especially a game!) than it is to design the whole thing out before writing a stitch of code.

For the Objects by Design course, we found that spending the time right away to challenge students' assumptions about how to develop software can quickly provide a buy-in attitude. The dice game is ideal in this respect.

Use Cases

The analysis process commences with the use case. Two features in particular distinguish the author's presentation of use cases: his distinction between high-level and expanded use cases and his use of textual templates for describing use cases.

The UML includes a basic use case notation for depicting actors interacting with the system. However, the notation does not specify the format in which the narration of the use case should be captured, nor how it should be used. This is where the author steps in.

High-level use cases include the use case name, list of actors, and a basic summary of the actors' interaction with the system being modeled. The purpose of the high-level use case is to rapidly scope out the system, without getting bogged down in detail. This can be a highly effective tool for project planning: in the early stages of a project the entire scope may be known. Using projections based on previous projects, a skilled manager may be able to produce reasonable time estimates for a new project. Also, the order in which the system is designed may be understood by mapping the dependencies between the full set of use cases.

Larman's expanded use-case template, which describes the Actor-System interaction in greater detail, is a subtle but powerful tool. For one, the template makes a clear distinction between the Actor Action and System Response by separating them into two columns. Secondly, by using sequence numbers to order the events initiated by the actor and the system responses, the template provides a clear framework which feeds into subsequent stages in the process: system sequence diagrams and contracts. This forms the foundation for the Larman process; subsequent stages always have well defined precedents from which they are derived.

What immediately brings the use-case templates to life is their application to the example system which dominates the book - the point-of-sale terminal, or POST.

Conceptual Model

The conceptual model captures real-world concepts (objects), their attributes, and the associations between these concepts. The author provides guidance for identifying each of these components by means of very useful 'category checklists' and introduces the UML class diagram notation for capturing the conceptual model. The emphasis throughout is that this is an analysis-level activity - a model of real-world objects - and not an attempt to design the actual software. The example application, the POST, is used to create a full-fledged model and the reader gets a true sense of accomplishment by the end when all the pieces come together in an intelligible diagram.

From the process perspective, the author also describes the technique of identifying nouns in the use cases as a strategy for finding concepts and their attributes. We particularly like this approach because it emphasizes the continuity of the process by deriving the outcome of each stage from previous stages. It also provides students with their first tangible proof of the value of doing good use cases.

Fundamentals

As an interlude to our discussion of Larman's process at this point, we need to take note of a fundamental difference between the approaches of two pioneers of object technology: Ivar Jacobson and Bertrand Meyer.

Jacobson has long championed the 'use-case driven' approach to object-oriented development and has built a comprehensive process around this approach called Objectory, or more recently, the Unified Software Development Process.

Meyer, in his highly regarded book Object-Oriented Software Construction, has roundly rejected a central role for use cases in object-oriented development. An online excerpt from the book clarifies this rejection. Essentially, he believes that an early emphasis on the sequencing of interactions between actors and the system being modeled shifts the focus away from creating well-abstracted, independent objects. The pitfall of focusing on the sequencing of interactions is inevitably to lock into the design artificial sequencing dependancies between objects which are hard to break later on.

Instead, Meyer promotes the Design by Contract approach whereby a contract is formed for each object, precisely specifying the tasks it is obligated to perform on behalf of clients. This focus on abstraction allows interactions between objects to remain fluid; as long as the contracts are honored, the sequence of interactions may be easily modified as need arises.

Whatever Craig Larman's motivation (theoretical, practical), it appears that he has consciously tried to reconcile these two fundamentally different approaches, as we will now see at this point in our discussion of his process.

System Sequence Diagrams

In order to clearly model the events which will be handled by a system, the system sequence diagram is used. In the Larman process, these are directly derived from the expanded use cases by identifying each of the events generated by the user to the system. Here the benefit of separating the actor actions from the system responses in the use case template (using two columns) becomes evident - it is much simpler to identify the actor initiated events with this visual partitioning. As we will soon see, identifying these system interactions forms a precise framework for subsequent stages of the process.

At this point it would appear that Larman's process is governed by Jacobson's use-case driven approach.

System Contracts

Contracts? Larman has switched over to the Bertrand Meyer approach! Very clever indeed.

The emphasis that the author places is on one particular feature of contracts, the post-conditions (contracts also include pre-conditions and class invariants). While the author doesn't utilize a formal language to describe the post-conditions, they are clearly derived from the conceptual model and expressed as:

1. Object creation and deletion.
2. Attribute modification.
3. Associations formed and broken.

Is this UML? Actually, the UML 1.1 standard has a very well-crafted, formal language for describing contracts: the Object Constraint Language or OCL. Larman does not utilize OCL and this could very well be for two reasons. One, OCL was a late addition to the UML and it may not have been available when Larman wrote his book. Two, the context for post-conditions expressed by OCL is always a method on a class; at this stage of the process it would be premature to use OCL because methods have not yet been identified. We are still at the system as black-box stage. As Larman states, "A system operation contract describes changes in the state of the overall system when a system operation is invoked."

It remains to be seen how Larman's concept of system contracts can be fully adapted to the UML/OCL approach. However, what is of great value in the system contracts at this point in the process is their emphasis on object abstraction - the determination of how elements of the conceptual model take form. But note that it is the system sequence diagrams which provide the context for forming the system contracts because it is they that identify operations at the system level.

Collaborations with Patterns

To use Larman's own metaphor, the stage has been set. The curtain is raised and we view the scenery for the next act. The system contracts have defined the demarcation between the analysis and design phases. Post-conditions describe all the assertions about the conceptual model which must prevail to satisfy the contracts for each system operation. We know the what, now we need to know the how. How are the post-conditions fulfilled?

The answer unfolds with the design of interaction diagrams. The author identifies interaction diagrams as "one of the most important artifacts created in object-oriented analysis and design". The attention devoted to this stage of the process is proof of this conviction. These several chapters are pivotal in terms of defining a process for the UML.

First the UML notation for interaction diagrams is introduced. While the treatment is thorough, Larman shows a distinct preference for collaboration diagrams over sequence diagrams. The reader shouldn't allow this bias to color his perception too much. For the author, collaboration diagrams work well to convey the dynamic flow of messages to his reader. Our experience has often shown that, for complex software with many objects and messages, collaboration diagrams can quickly become more unwieldy and less clear than sequence diagrams, which follow a straight-forward top-down, left-right flow.

As we have seen already, notation without a process doesn't promote good design. The magic twist that Larman adds is the application of software patterns to the development of the collaboration diagrams. His GRASP patterns are essentially the key guidelines for assigning responsibilities to classes for fulfilling the system contracts. The patterns show the motivation for determining which objects should create other objects, build associations and modify attributes - the assertions contained in the contracts - by sending messages to the other objects. Expert, Creator, High Cohesion, Low Coupling and Controller. Each is explained in detail with application to the POST example. The details are beyond the scope of this review. Suffice it to say - the process makes a lot of sense and it really works. The proof is in the resulting design of the POST example.

Classes to Code

While the production of the collaboration diagrams demands creativity, one gets the impression that the remaining stages of the process are almost mechanical. You know you have succeeded on an object-oriented project when this is in fact true.

Class diagrams are easy to derive from the conceptual model and are completed by adding the newly discovered methods from the collaboration diagrams. In actuality these updates can be made concurrently with the discovery of the messages in the collaboration diagram. This is true because most decent UML tools will allow methods to be created on an object's underlying class when a new message is needed. In fact, it may even be preferrable to create the correct method signature on the class diagram first and then create the message on the collaboration diagram by just picking the name from a pick list.

The generation of the code may actually be mechanical if the UML tool provides forward engineering. This feature works for the creation of classes, attributes and method signatures. However, the really fun part is the concluding step of the process. In Larman's own words:

"A collaboration diagram shows the messages that are sent in response to a method invocation. The sequence of these messages translates to a series of statements in the method definition."

Anyone who has had the satisfaction of coding from a well-designed set of collaboration diagrams knows how rewarding this last step can be.

End of Iteration

The book continues with a second iteration which introduces some advanced concepts including inheritance, package diagrams, state diagrams, additional software patterns and persistence frameworks. These advanced concepts are all creatively applied to the POST example application. However, it is the first iteration that really stands out for its coherent presentation of the core aspects of analysis and design.

In summary, we highly recommend this book because the author has achieved what few others have achieved before or after him. He has successfully demystified the object-oriented analysis and design process.

Links:

• Summary of Larman's UML Process
• Choosing a UML Modeling Tool
• Buy this book at amazon.com
• Learn OCL - The Object Constraint Language
• Larman's 2nd Edition: Unified Process
• Larman's 3rd Edition: Agile Modeling
• Craig Larman on Agile Modeling
• Agile and Iterative Development: A Manager's Guide

• Ezequiel Cuellar's Notes on Applying UML and Patterns
• Section 1 - Development Process
• Section 2 - Requirements Modeling
• Section 3 - Architecture
• Section 4 - Static Modeling
• Section 5 - Dynamic Modeling
• Section 6 - Design and Implementation Techniques
• All the notes in Word format - ZIP file