By Martin Fowler and Kendall Scott. Notes from 2nd Ed on types of UML diagrams. Pictures are scanned from front/back flaps.

  • Use case

    Relationships for use cases:
    – generalize (also for actor)
    – include
    – extend: it’s more detailed than generalize (actually degeneralize) with defined extension points
    A passive actor is linked to a use case by a line without arrow.

  • Class

    • Three perspectives:
      – conceptual
      – specification (mostly interface)
      – implementation (actual classes implementing the stuff)

    • Navigability means responsibility in specification perspective: A->B means A is responsible of showing B. In implementation perspective it means A has a pointer/reference to B.
    • Class scope attribute/operation (static) is underlined.
    • Discriminator is used to label a generalization line to indicate the basis of subtyping (classfication/grouping of different subclasses). A subclass group that has a discriminator with a {complete} constraint means that one of the subclass in the group has to be chosen (e.g. male/female as person with sex discriminator). A discriminator with > stereotype means that an object may change its type among the group of subtypes.
    • Aggregation is looser than composition, such that when an instance is deleted, all its compositions are deleted, but not for aggregation, as if compoisition means owning an actual object, whereas aggregation only owns a pointer/reference.
    • Derived association and attribute are indicated by a slash: “/derived”.
    • Qualified association models associative arrays, maps, etc, where the qualifier is a unique key for the associated class.
    • Association class defines attributes for the association itself, which doesn’t belong in either ends of the association. Only one instance of association class can exist

    Bound element is a parameterized class with its parameter specified.

    Interface vs abstract class: remember java! The lollipop representation of interface is more compact.

  • Interaction: Sequence
    One interaction diagram usually captures one use case.

    • Message condition is indicated by “[condition]” above the message.
    • Use “*[basis for iteration (optional)] message” to indicate the message is sent many times to multiple receiver objects.
    • Return arrow is optional, not necessary if the lifeline is clear about when an object returns.
    • Use half arrow head for asynchronous message.
    • Add descriptive text on the left side for each processing block if necessary.
  • Interaction: Collaboration

    • Messages are numbered (sequential or hierarchical).
    • Draw a line back to the object for self-delegation.
    • May use Class-Responsibility-Collaboration card to represent interaction for exploring many alternatives.
  • Package

    • Use > for a commonly dependent package.
    • Use the same generalization arrow between packages.
    • Do unit testing on a per package basis: use test classes to test a package as a whole
  • State

    • To represent one object across many use cases.
    • Activity takes longer than action.
  • Activity

    • Good for analyzing a use case (allocate actions to objects later), understanding workflow, describing complicated sequential algorithm
    • Dynamic Concurrency means the activity is executed multiple times
    • Swimlanes: activity diagram arranged in vertical zones, each zone represents responsibilities of a particular entity.
  • Deployment

    • Each node is a physical entity
    • Dashed line means communication
    • Solid line means physical connection

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s