Notes from the book: UML Distilled by Martin Fowler

by Michael Thomas

Back to UML Products
 

(Book Review: UML Distilled (Applying the Standard Object Modeling Language) by Martin Fowler  UML v1.2 ISBN: 0-201-32563-2 (Addison-Wesley 1997 6/98)
Site for Book: http://www.awl.com/cseng/titles/0-201-32563-2.html

Example Diagrams - must view! (Wait for the loading of many images!)

Sub Notes
Definition UML - Unified Modeling Language. 
What is UML?
  • UML techniques helps display requirements and design.
  • UML records the resulting analysis and design decisions
  • UML helps you discuss your design with someone.
  • UML defines a graphical notation of a design.
  • UML is a modeling language, not a method.
  • UML is independent of process.
  • UML is the successor to OOAD.
Why do Analysis and Design w/UML?
  • When it comes down to it, the real point of software development is creating code. (p7)
  • UML helps you achieve good communication and understanding of the users world (domain experts).
  • UML can help show you the Big Picture.
  • UML helps the development team (usually 2-4 people made of developers and domain experts) to develop the domain model.
  • UML diagrams are useful for getting an overall understanding of a system.  Do not produce detailed diagrams of the whole system. (p34)
UML Terminology (see end of this table)
Purpose of UML
  • Availability of a standard modeling language will encourage more developers to model their software systems before building them. (Grady Booch)
  • Design is all about seeing the key issues in development.
Top Authors Grady Booch - leading the work on the user's guide to UML.  Unified Modeling Language User Guide - ISBN: 0-201-57168-4

Jim Rumbaugh - leading the work on the reference book to UML.  Unified Modeling Language Reference Manual - ISBN: 0-201-30998-X

Ivar Jacobson - leading the work to describe the process of using the UML.  The Objectory Software Development Process - ISBN:  0-201-57169-2

"Three amigos" - the name given to the above 3 authors who joined forces to form a single Unified Modeling Language.  Web site for the above books:  www.awl.com/cseng/titles/[I-S-B-N]  (replace [I-S-B-N] with the ISBN #'s including the dashes!)

Martin Fowler - see "Survey of Analysis and Design Methods" @ http://ourworld.compuserve.com/homepages/Martin_Fowler

Buschmann - interaction diagrams.
Robert Martin - packages.
Cook and Daniels - state charts.

Others:  Goldberg & Rubin, McConnell, and Graham

Techniques
(p8, Appendix A)
The most commonly used techniques are:  Use case, Class diagrams, and Activity diagrams.  Domain experts can understand these diagrams and provide valuable feedback.

Activity diagrams - focus on workflow processes.  Can show many objects over many use cases (implementation of methods).   Shows the steps people go through in doing their jobs.  Encourages finding parallel processes and eliminating unneccessary sequences in business processes. (p20)

Class Diagrams - diagrams the language of the business (language of your users).  It should be responsibility-oriented, not data-oriented.  You layout the concepts that the business experts use as they think about the business and layout the ways those experts link concepts together.

Shows static structure of:

  • Concepts - show how users think about the business. 
  • Types - show interfaces of software components. 
  • Classes - show implementation of software components.

CRC Diagrams (Class-Responsibility-Collaboration) - emphasis is on responsibilities of the class and its interaction with other classes (collaboration).  Helps to get the essence of the class's purpose.   Use if getting bogged down with the details or if learning OO approach to design.

Deployment Diagrams - Shows physical layout of components on hardware nodes.  Not used much.

Interaction diagrams - are models that describe how groups of objects collaborate in some behavior in a single use case.  Captures the behavior of a single use case.  Illustrates key behaviors in the system.  Two types of diagrams: Sequence & Collaboration. 

Iterative development - the process of developing and releasing software in pieces, not in one big bang.

Package diagrams - Shows groups of classes and dependencies among them.

Patterns - look at the results of the process.  Describe common ways of doing things.  Look for repeating themes in designs.

Refactoring - coding oriented.  Use when code is getting in the way of good design.  Helps in making changes to working programs to improve structure.

State Diagrams - shows how a single object behaves across many use cases.

Use Case - Use cases drive the whole development process.   Describes the typical interaction that a user has with the system in order to achieve some goal.  Each 'use case' should indicate a function that the user can understand and that has value for that user.  Proves the basis of communication between the sponsors and developers in planning the project.  Construction planning is built around delivering some use cases in each iteration.  Basis for system testing.

Process Steps
(CH 2)
Inception - Establish the business rationale for the project and decide on the scope of the project (p15).  Sponor agrees to no more than a serious look at the project.

Elaboration - collection of detailed requirements, high-level analysis and design to establish a baseline architecture, and create the plan for construction(p15).  Elaboration takes about 1/5 of the total length of the project.

  • Try to discover all the potential use cases. (p18)
  • Schedule interviews with users for the purpose of gathering use cases (p18)
  • Come up with the skeleton of a conceptual model of the domain. (p18)
  • Identify the risks in your project (requirements risks, technology risks, skills risks, political risks)
  • Build baseline architecture
  • Planning - Categorize use cases (high priority, architectural risk, schedule risk).  Perform iterations on the use cases.  Now you can estimate.   (p27) 
  • Finished when (1) developers can feel comfortable providing estimates, to the nearest person-week of effort it will take to build each use case, (2) significant risks have been identified, and the major ones are understood to the extent you know how to deal with them.

Construction - builds the system in a series of iterations (mini-projects).   Each mini project has analysis, design, coding, testing (unit-by developer & system-by testers), and integration.  You finish the iteration with a demo to the user, then do system tests.  The development team gets use to delivering finished code for each mini project.  Don't wait till the end.

Transition - beta testing, performance tuning, and user training.

 

Use Cases
(Ch 3)
  • Each use case indicates a function that the user can understand and that has value for that user.
  • A typical interaction between a user and a computer system.
  • Captures some user-visible function
  • Achieves a discrete goal for the user.
  • Capture use case by talking to your typical users and discussing the various things they might want to do with the system.
  • Take each use case, give it a name, and write up a short textual description (1 - 2 paragraphs)
  • Conceptual modeling with users helps uncover use cases. (p51)
  • Focus on user goals, then come up with 'use cases' to satisfy them.  Understand the use cases and the goals they satisfy. (p48)
  • In elaboration, use cases is the first thing you should do. (p51)
  • Use case is an essential tool in requirements capture and in planning and controlling an iterative project.
  • External events will help identify use cases.
  • In planning, use 'Use Cases' to devlope a commitment schedule.
  • Track the actors so you know who wants a use case. (p48)
  • Use cases are all about externally required functionality
  • Use cases provide the basis of communication between sponsors and developers in planning the project. (p18)
  • 2 Styles of use cases: user goals & system interaction.  User goals - requirements & design phase.  System interactions - used in the planning stage.
  • Use cases use the terms: "users" and "extends".  Each case has associated "actors".  Use the actors to find additional use cases.

Focus on the users goals first.  Later you can consider System interactions.

Links in the USE CASE

  • Identify actors - a role that a user plays.  An actor can be a person or an external system.
  • Uses - when you have a chunk of behavior that is similar across more than one use case.
  • Extends - one use case that is similar to another use case but does a bit more.

http://members.aol.com/acockburn - Cockburn's Web site (script is a use case)

Class Diagrams
(Ch 4 & 5)
  • Describes the types of objects in the system and the various kinds of static relationships that exist among them.
  • Show the attributes and operations of a class and the constraints that apply to the way objects are connected.
  • Show the process that a class should carry out. (public methods)
  • Identify interfaces and abstract classes (Java)
  • Shows the whole picture of the interconnected classes.

Types of static relationships

  • associations - the class "has a".  Relationships between the instance of classes.
  • subtypes - the class "is a".

Perspectives to a class diagram

  • Conceptual - represents the concepts of the domain.  Not language specific.
  • Specifications - this is the interfaces of the software, not the implementation.
  • Implementation - lay out the classes.
Interaction Diagrams
(Ch 6)
  • Models that describe how groups of objects collaborate in some behavior.
  • Captures the behavior of a single use case.
  • Shows messages being sent within a given use case (methods).
  • Good at describing the behavior of several objects in a single use case.
  • Two types of interaction diagrams: sequence & collaboration.  Sequence - shows messges being sent.  Collaboration - #'s those methods by order.
  • Interaction diagrams are at their best when the behavior is simple.  Simple ones provides best value.
Package Diagrams
(Ch 7)
  • A grouping of classes together into higher-level units.
  • Shows the packages of classes and the dependencies among them.
  • A key tool in maintaining control over a system's overall structure.
  • Break down large systems into smaller systems.  As systems get large, it becomes difficult to understand them and the changes we make to them.
  • Package diagram is just a form of a class diagram.  You see all public classes in the package and all their public methods.
State Diagrams
(Ch 8)
  • Describe all the possible states a particular object can get into and how the object's state changes as a result of events that reach the object.
  • Describe the behavior of a system as objects change states.
  • Drawn for a single class to show the lifetime behavior of a single object.
  • Good at describing the behavior of an object across several use cases.

Shows Actions and Activities of an object.

  • Actions - are associated with transitions and are considered to be processes that occur quickly and are not interruptible.
  • Activities - are associated with states and can take longer.  An activity may be interrupted by some event.
Activity Diagrams
(Ch 9)
  • Tell you what happens, but they do not tell you who does what.
  • Useful for describing complicated methods.
  • Represents the interaction of use cases.
  • In a conceptual diagram, an activity is some task that needs to be done.
  • In a specification or implementation diagram, an activity is a method on a class.
  • Useful in connection with workflow and in describing behavior that has a lot of parallel processing.
  • Ability to show behavior that spans multiple use cases.
  • Good at showing the general sequence of actions for several objects and use cases.
  • Shows parallel activities and sequential activities.  This is important in business modeling.  Shows Threads and synchronization.
  • Show interconnected behavior among classes.
  • A great strength is that they support and encourage parallel behavior.

Do use:

  • Analyzing a use case.
  • Understanding workflow across many use cases.
  • Use in situations that are dominated by workflow.
  • Dealing with multi-threaded applications.

Do not:

  • Do not make the links among actions and objects very clear.
Deployment Diagrams
(Ch 10)
  • Shows the physical relationships among software and hardware components in the delivered system.
  • Shows how components and objects are routed and move around a distributed system.
  • Shows were each package is running on the system.
  • Not being used much yet!
UML & Programming
(Ch 11)
Different UML diagrams are helpful in the different stages of coding.
  • The first step in the coding process is to come up with a conceptual model that describes the concepts of the domain (business).
  • Sketching out a design with a class diagram and an interaction diagram can help get your thoughts in order and make it easier to code. (p165)
  • Diagrams are like fast prototypes.
  • Once you've completed the coding, you can keep the diagrams for yourself and others or you may discard them.
Planning & Estimating The essence of a plan is to setup a series of iterations for construction and to assign use cases to iterations. (p26)

Developers do the estimating, not managers.

Categorize the use cases: (level of priority)

  • Absolutely need function
  • Can live without it for a short period.
  • Important function but can survive without it for awhile.

Determine Risk

  • Architectual Risk - risk if the use case is put aside until late in the project, the work that has gone before will be significately compromised, resulting in a lot of rework. (1-High risk, 2-Possible, but not likely, 3-Little chance)
  • Schedule Risk - how confident the developer feels about estimating the effort required for each use case.  (1-Can estimate to the person-week, 2-Can estimate to the person-month, 3-No idea)

List a set of iterations for construction and assign a use case to it.  Then estimate the effort needed.

  • Iteration length: Smalltalk - 2-3 weeks per case.  C++ - 6-8 weeks per case.
  • Effort for iteration:
    # of Developers * iteration length * .50 efficiency = effort per iteration.

Transition - tuning and packaging for delivery.  Allocate 10 - 35% of construction time.

Contingency Factor - add 10-20%.  Internal delivery date - does not include contingency.  External delivery date - does include contingency.

Develop a commitment schedule - this schedule is expected to change as the project proceeds.  Changes must be made jointly by developers and users.

UML Notation Associations
  • 1      = has only one
  • 1..*   = has one or more
  • 0..1  = has zero or one
  • *       = has zero, one, or more

Visibility

  • +    = public
  • -    = private
  • #    = protected

{mandatory} - abstract classes.

Models:
  • Domain models (use cases) - capture functional requirements (p19)
  • Analysis models - explore the implications of these requirements for a particular application. (p19)
  • Design Models - add the internal infrastructure to make the application work.  It realizes both the information in the domain objects and the behavior in the use cases. (p19)
Sayings
  • Object languages allow advantages but don't provide them. (Tom Hadfield)
  • One of the hardest things to understand in an object-oriented program is the overall flow of control.  A good design has lots of small methods in different classes, and at times it can be tricky to figure out the overall sequence of behavior. (p105)
Web Links http://www.awl.com/cseng/otseries - Source of UML books
Martin Fowler - www.awl.com/csent/titles/0-201-32563-2.html - thoughts on methods
CRC - http://c2.com/doc/oopsla89/paper.html
Terms actor - (p46)
aggregation - is a stronger form of an association -a relationship between a whole and its parts.
association
- is a bi-directional connection between clases.  Two objects are usually considered independently.
baseline architecture
- consists of the use cases, domain model, and technology platform.
case tool
- a modeling language that may generate code.
CRC cards - Class-Responsibility-Collaboration. You put a high-level description of the purpose of a class on a 4x6 card. (p64-66).  For each class, list its responsibilities and the name of the class it must work to fulfill it.
domain experts - a user that understands the business.
domain model - any model whose primary subject captures your understanding of the business the system is supporting.
iteration - to repeat steps in a development process.  Each iterations builds production-quality software, tested & integrated, that satisfies a subset of requirements of the project.  Each iteration contains all the usual lifecycle phases of analysis, design, implementation and testing.  Delivery can be external to users or purely internal.  In short, pick some functionality and build it, pick some other functionality, and so forth (p15).  The point of iterative development is to do the whole development process regualary so that the development team gets used to delivering the finished code (p40).
meta-model
- a diagram that shows the relationship among classes.  A diagram that defines the notation, like a class diagram.
methods
- use of a modeling language and a process.
Modeling Language - the graphical notation of a design.
node - some kind of computer unit - usually hardware.
notation - graphical picture; syntax of the model.
OOA&D - (Object Oriented Analysis & Design)
OMG - Object Management Groups - UML standards committee
process - advice on what steps to take in doing a design.
realization - (p50)
Rational Objectory Process - Rational Rose by the 3 amigos.  A unified process taht implements UML.
static vs dynamic - static does not change; dynamic can change states.
use case - a snapshot of one aspect of your system.  A way to communicate the big picture with a user.  A good vehicle for project planning and iterative development.  Tells you what the requirements are.