Unified Modeling Language(UML)

basics & concepts

Development Process
Diagrams & Techniques


  • Appeared in the late '80s and early '90s.
  • Based on
    • Jim Rumbaugh's research work in GE(General Electric). A book titled "Object Modeling Technique"(OMT).
    • Grady Booch's research work in Rational Software in developing Ada systems. Several books published.
    • Ivar Jacobson's experience with Ericsson. Several book published.
  • OMG(Object Management Group) standardized since 1997. Version 1.3 made public in early 1999.
  • Widely used with Smalltalk, C++ and Java
  • Graphical notations based on OOA&D(Object-Oriented Analysis and Design).

Note: You must learn OO concept first before you study UML.

Return to top


  • The Unified Modeling Language (UML) is a modeling language, not a method.
  • The syntax is a series of graphical notations which are used to express OO designs.
  • An effective external view of design and development.

Return to top

Software Development Process

  • Inception -- establish business rationale
  • Elaboration -- baseline architecture
  • Construction -- Iterations of
    • analysis
    • design
    • implementation
    • testing
  • Transition -- beta testing, tuning, user training

Return to top

Diagrams & Techniques

The following techniques are used to express OO designs, but not limited.

  • Structural Diagrams
    • Class diagram
    • Object diagram
    • Component diagram
    • Deployment diagram
  • Behavioral Diagrams
    • Use case diagram
    • Sequence diagram
    • Collaboration diagram
    • Statechart diagram
    • Activity diagram
  • CRC Cards
  • Design by Contract
  • Interaction Diagram
  • Package Diagram
  • Patterns
  • Refactoring

Return to top

Use Case

Use diagrams to describe a sequence of steps between a user and a system. A user may be a human being, an action, or other system. Use cases can be applied in different processes of a software development.

Elements involved in Use Case

  • Actor - stick figures in a system.
  • Links - dotted, solid, arrowed lines and text
  • Diagrams - linked with lines, text and actors


  • include -- avoid repetition
  • generalization -- describe normal behavior
  • extend -- controlled form
  • association -- structural relationships among objects
  • dependency -- relationships among classes


  • business -- response to customer
  • system -- interaction with software


  • one base use case.
  • many variant use cases based on scenarios.


  • Pen & Paper -- traditional
  • Software -- modern


  • Images

Return to top

Class Diagrams

A class diagram describes the static structure or relationship of :

  • concepts -- conceptual domain
  • types(specification)-- interfaces of components
  • classes -- implementations of components

Static relationship

  • association -- between instances of classes.
    • two association ends --lower and upper bounds
      • "*" -- 0..infinity
      • "1" -- 1..1
    • role name
  • subtypes

Attribute syntax:

visibility name: type = defaultValue 
  • similar to associations
  • field -- called in implementation level
  • data member -- another name
  • instance variable -- another name
  • includes name(string), type and default value
  • multiplicity can be used to indicate many values
  • visibility:
    • " + " -- public
    • " # " -- protected
    • " - " -- private

Operation syntax:

visibility name(parameter-list): return-type-expression{property-string}
  • visibility:
    • " + " -- public
    • " # " -- protected
    • " - " -- private
  • name -- a string
  • parameter-list -- comma-separated parameters
        direction name: type = default value
    • " in " -- for input (default)
    • " out " -- for output
    • " inout " -- for both input and output
  • return-type-expression -- comma-separated list of return types(multiple return types allowed)
  • property-string -- property value


  • super type interface
  • sub type interfaces confirm to super interface
  • inheritance
  • substitutability
  • less constraint

Constraint rules

  • Object Constraint Language
  • rules in side braces " {} "
  • assertions

Return to top

Object Diagrams

Shows a set of objects and their relationships.

  • instance diagram -- another name
  • a snapshot of the objects
  • syntax:
    instance name:class name
  • underlined
  • optional for all the parts

Advanced concepts

  • multiple and dynamic classification-- relationship btw an object and its type
  • class scope operations and attributes
  • aggregation -- close to association
  • composition
  • derived associations and attributes
  • interfaces and abstract classes
  • reference objects and value objects
  • collections for multivalued association ends
  • frozen
  • classification and generalization
  • qualified associations
  • associated class
  • parameterized class(not for Java)
  • visibility

Return to top

Interaction Diagrams

Interaction diagrams describe how several objects collaborate in single use case.

  • sequence diagrams
  • collaboration diagrams

Return to top

Package Diagrams

Package diagrams describe groups of classes and dependencies among them.

  • a kind of class diagram that just shows packages and dependencies.
  • a dependency may exist between two classes or two packages.
  • dependencies may not be transitive.
  • collaborations
  • for large projects

Return to top

State Diagrams

State diagrams describe how single object behaves across many use cases.

  • description of a system behavior
  • all possible states and changes
  • lifetime behavior from entry to exit
  • concurrent state

Return to top

Activity Diagrams

Activity diagrams describe behaviors with control structure in many objects over many uses or in single use case.

  • a state of doing something
  • sequencing of activities
  • parallel behavior
  • a branch, a single incoming transition and several guarded outgoing transition
  • a merge, multiple input transitions and a single output
  • a fork, one incoming transition and several outgoing transitions
  • a join, outgoing transition is taken only when all the states on the incoming transitions have completed their activities
  • sync state, synchronizing in places where the forks and joins rule matches
  • decomposing an activity, broke down into subactivities
  • dynamic concurrency
  • swimlanes, show what happens. Devide an activity diagrams based on responsibility with vertical zones
  • Usage:
    • analyzing a use case
    • understanding work flow
    • describing a complicated sequential algorithm
    • dealing with multithreaded applications

Return to top

Deployment Diagrams

Deployment diagrams describe the physical relationships among software and hardware components in the delivered system.

  • how the components and objects are routed and move around.
  • node represents computational unit.
  • connections among nodes show the communication paths over which the system will interact.

Return to top

Component Diagrams

Component diagrams describe the various components in a system and their dependencies.

  • a component, a physical module of code
  • a single class may be present in multiple components.
  • dependencies show how changes to one component may cause other components to change
  • part of deployment diagrams

Return to top

CRC Cards

CRC cards stands for Class-Responsibility-Collaboration cards

  • a 4 x 6 index cards
  • developed by Cunningham and Beck at Tektronix lab, Portland, Oregon in the late 1980s.
  • write responsibilities on the cards instead of attributes and methods.
  • a high-level description of the purpose of the class.
  • collaboration means other classes that this class needs to work with.
  • encourage animated discussion among the developers.
  • help explore an interaction between classes.

Return to top

Design by Contract

Design by contract is a design technique. The central part is assertion. An assertion is a boolean statement that should never be false.

  • developed by Bertrand Meyer in the Eiffel language
  • checked only during debug
  • three kinds of assertions
    • pre-condition -- expected condition before execution
    • post-condition -- what should be after execution
    • invariants -- about a class
  • caller is responsible for checking if pre-condition is set.
  • invariants are equivalent to constraint rules on class diagrams.

Return to top

Code Refactoring

Code refactoring describes techniques that reduce the short-term pain of redesigning.

  • change internal structure not functionality
  • renaming method
  • moving fields
  • consolidating two similar methods into a super class
  • taking short, deliberate or tiny steps
  • test after each alteration

Return to top


Patterns describe common ways of doing things.

  • collection of repeating themes in designs
  • the most famous design pattern(23) book developed by four guys (Gang of Four).
  • Java design patterns by Cooper with Java code examples.
  • more than 150 OO design patterns.
  • whenever you develop something, search applicable design patterns.

Return to top


Mostly useful terms

  • A class is a description of a set of objects that share the same attributes.
  • An attribute is a named property of a class that describes a range of values that instances of the property may hold
  • An operation is the implementation of a service that can be requested from any object of the class to affect behavior.
  • A responsibility is a contract or an obligation of a class.
  • A relationship is a connection among things.
  • A dependency is a change affecting another thing (dashed directed line with arrowhead).
  • A generalization is "a kind of" general thing (solid directed line with a large open arrowhead pointing to parent)
  • An association is a structural connection among objects (bidrectional and solid line connecting to the same or different classes)
  • An aggregation is the type of one-to-many relationship where one object contains a collection of other objects (has-a relationship). (open diamond <>).
  • A composite aggregation is a variation of simple aggregation, or a special kind of association, with strong ownership and lifetime cycle.
  • A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of element (Rectangle with a dog-eared corner, together with a textual comment)
  • A stereotype is a building block specific to the problem with name or icon.
  • A tagged value is a string enclosed by brackets, placed below the element.
  • A constraint is used to add new rules to existing one, a string enclosed by brackets, placed near the associated element.
  • A classifier is a mechanism that describes structural and behavioral features. It includes classes, interfaces, data types, signals, components, nodes, use cases, and subsystems.
  • An interface is a collection of operations that are used to specify a service of a class or a component.
  • A type is a stereotype of a class used to specify a domain of objects, together with the operations applicable to the object.
  • A role is the behavior of an entity participating in a particular context.
  • A package is a general-purpose mechanism for organizing elements into groups.(a tabbed folder)
  • An instance is a concrete manifestation of an abstraction to which a set of operations can be applied and which has a state that stores the effects of the operations.
  • An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose.
  • A message is a specification of a communication between objects that conveys information with the expectation that activity will ensure.
  • A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events.
  • A process is a heavyweight flow that can execute concurrently with other process.
  • A thread is a lightweight flow that can execute concurrently with other threads within the same process.
  • A node is a physical element that exists at runtime and represents a computational resource, generally having at least some memory and often processing capability (rendered as a cube)
  • A collaboration is a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that is bigger than the sum of all its parts.(ellipse with dashed lines)

Return to top