"When doing analysis you are trying to understand the problem. To my mind this is not just listing requirements in use cases. ... Analysis also involves looking behind the surface requirements to come up with a mental model of what is going on in the problem. ... Some kind of conceptual model is a necessary part of software development, and even the most uncontrolled hacker does it."
Martin Fowler, Analysis Patterns: Reusable Object Models, 1996

"Inheritance was all the rage in the early days of object-oriented development. But over time, designers have discovered that inheritance is effective only within certain contexts. Composition, in tandem with interfaces … is far more common, far more generally useful, and much closer to the heart of good object-oriented design."
Peter Coad, Mark Mayfield, Jonathan Kern, Java Design: Building Better Apps and Applets, 1996

"Just as the transition from black-and-white photography to color is so profound, the transition from black-and-white modeling to color is an awesome one."
Coad, Lefebvre, De Luca, Java Modeling In Color With UML, 1999

"Object modeling addresses the 'what' of the business; its concern is only with what is to be built, never why or how. Prior to the object modeling session, a good object architect inquires about the 'why' questions, and raises a red flag if no one at the client site knows the answers. Clients not clear on their strategy are not ready to discuss what they want to build."
Jill Nicola, Mark Mayfield, Mike Abney, Streamlined Object Modeling: Patterns, Rules, and Implementation, 2001

"In reality, in even the simplest project, developers do some amount of modeling, albeit very informally. ... Even in the realm of disposable software … modeling can help the development team better visualize the plan of their system ..."
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, 2005

"Use case modeling, when used in isolation and performed incorrectly, may lead to certain types of problems.... the possibility of ending up with a functional model instead of an object model. … Use cases authored by different developers may describe the same thing differently. … When domain analysis is performed in conjunction with use case modeling, it reduces the risk of a functional design. … Domain analysis pinpoints the language to be used to create textual descriptions in the use cases."
Frank Armour, Granville Miller, Advanced Use Case Modeling: Software Systems, 2001

"The fundamental reason to use UML involves communication. ... Natural language is too imprecise and gets tangled when it comes to complex concepts. Code is precise but too detailed. So I use UML when I want a certain amount of precision but I don't want to get lost in the details."
Martin Fowler, Kendall Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2000

"What we don't like is needless complexity."
Richardson, Ruby, RESTful Web Services, 2000

Basic shapes and symbols of UML 2.x sequence diagrams

Basic notational constructs in UML seqeunce diagrams

Figure 1: Basic shapes and symbols of UML sequence diagrams

  1. Example objects of classes are drawn as rectangles arranged across the top of the diagram

  2. The name for the object is displayed inside each object rectangle using the format object-name:class-name. Either the object-name or the class-name section may be omitted but not both. Omitting the object name is common. The object-name is only necessary when two different objects of the the same class participate in the sequence in different ways. Omitting the class section is not particularly useful in practice. Strictly speaking, the separating colon character is required unless the the class name is omitted, but in practice, when sketching sequence diagrams, it is often also left out when the object name is  omitted.

  3. Lifelines are drawn as dashed lines vertically down the page beneath each object.

  4. Messages representing the calling of operations are drawn as solid lines with a solid arrowhead from the calling object to the called object (the object whose type defines the operation being invoked). The name of the operation is written above the line and may be followed by a list of parameters for that call.

  5. The sequence of operation calls progresses from the top of the page downwards. The messages are also numbered in sequence using a decimal numbering scheme.

  6. A thin rectangle drawn on the lifeline indicates the execution scope of the called operation. All operation calls possible as part of the execution of an operation are drawn in order from this rectangle. Officially these rectangles are called execution specifications. When sketching sequences it is common to leave out the execution specification rectangles.

  7. Calls back to an object or calls to other operations defined for the object (self-calls or calls to 'this') are drawn as indented execution specification rectangles.

  8. Calls that create an instance of an object are drawn as dashed lines with a stick arrowhead. The object's rectangle is also dropped down from the top of the diagram to the point where he call is made so that the dashed line connects to the rectangle instead of its dashed lifeline.

  9. Destroying an object is shown by a message line drawn to the object being destroyed and an X symbol being added to the object's lifeline immediately afterwards. Take care when using this notation to ensure that it is clear whether the object is being erased from persistent storage (database or file system) or simply removed from memory.

  10. Arbitrary notes are displayed as text within a rectangle with a fold in the top right-hand corner. Notes are linked to their subjects by optional dashed lines without any arrowheads.

Follow me on Twitter...