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.

• 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

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
• association -- structural relationships among objects
• dependency -- relationships among classes

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
• Software -- modern

Example

• Images

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

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

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.

Terms

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)