Unified Modeling Language(UML)

History

• 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.

Definition

• 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.

Software Development Process

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

Diagrams & Techniques

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

• Activity Diagram
• Class Diagram
• CRC Cards
• Deployment Diagram
• Design by Contract
• Interaction Diagram
• Package Diagram
• Patterns
• Refactoring
• State Diagram
• Use Case

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

Relationships

• include -- avoid repetition
• generalization -- describe normal behavior
• extend -- controlled form

Situation

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

Types

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

Practice

• Pen & Paper -- traditional
• Softwares -- modern

Example

• Images

Class Diagrams

A class diagram describes the static structure or relationship of :

• concepts -- conceptual domain
• types(specification)-- intrefaces 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-expressoin -- comma-separated list of return types(multiple return types allowed)
• property-string -- property value

Generalization

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

Constraint rules

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

Object Diagram

• 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

Interaction Diagrams

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

• sequence diagrams
• collaboration diagrams

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

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

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

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.

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

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.

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.

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

Patterns

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.