Unified Modeling Language (UML)

Modeling
 Modeling is a way of thinking about the problems using models
organized around the real world ideas.
 A modeling method comprises a language and also a procedure for using
the language to construct models.
 Modeling is the only way to visualize your design and check it against
requirements before your crew starts to code. 

Unified Modeling Language (UML) is a standardized general- purpose modeling

language in the field of software engineering.

 It is used to specify, visualize, modify, construct and document the

artifacts of an object-oriented software intensive system under
development .
 It is not simply a notation for drawing diagrams, but a complete language
for capturing knowledge(semantics) about a subject and expressing
knowledge(syntax) regarding the subject for the purpose of
communication.

UML Building Blocks

Three basic building blocks:
 Elements: main “citizens” of the model.
 Relationships: relationships that tie elements together.
 Diagrams: mechanisms to group interesting collections of elements and
relationships.

Elements
Four basic types of elements:
 Structural
 Behavioral
 Grouping
  Annotation

Structural Behavioural Grouping Annotation

class interaction Package Note
interface state machine
collaboration
use case
active class
component
node

Relationships
Four basic types of relationships:
 Dependency, a semantic relationship between two elements in which a
change to one element (independent element) may affect the meaning of
another (dependent element). Given as a directed dashed line
 Associations, a structural relationship describing a set of links, links are
connections between objects, aggregation is a special type of association
depicting the whole-part relationship, association is presented as a solid
line, possibly directed, labeled and with adornments (multiplicity and role
names)
 Generalization, a relationship in which objects of a specialized element
(child) are substitutable for objects of a generalized element (parent),
rendered graphically as a solid line with hollow arrowhead pointing to the
parent.
 Realization, a semantic relationship between elements, wherein one
element specifies a contract and another guarantees to carry out this
contract, graphically depicted as a dashed arrow with hollow head, a cross
between dependency and generalization.

Diagrams
A diagram is a graph presentation of a set of elements and relationships where
 nodes are elements
 edges are relationships
UML is characterized by nine major diagrams:
 class
 object
 use case
  sequence
 collaboration
 state chart
 activity
 component
 deployment

Class Diagrams
Class Diagrams describe the static structure of a system, or how it is structured
rather than how it behaves. These diagrams contain the following elements.
• Classes, which represent entities with common characteristics or features.
These features include attributes, operations and associations
• Associations, which represent relationships that relate two or more other
classes where the relationships have common characteristics or features.
These attributes and operations.

Class Notation
Basic notation: a solid-outline rectangle with three compartments separated by
horizontal lines.
Three compartments:
 top compartment holds the class name and other general properties of the class
 middle compartment holds a list of attributes
 bottom compartment holds a list of operations

Class Relationships
Four relationships between classes:
 association
 aggregation
 generalization
 dependency

Multiplicities for Classes

Shows how many objects of one class can be associated with one object of another
class

Multiplicities Syntax

Value Description
0..0 zero
0..1 Zero or one
0..* Zero or more
1..1 one
1..* One or more
* Unlimited number
<literal> Exact number (eg. 4)
<literal>_* Exact number or more (eg: 4..*
indicates 4 or more
<literal>_<literal> specified range (eg: 4..13)
<literal>_<literal>,<literal> Specified range or exact number
(4..13,31 indicating 4 through 13 and
31
<literal>_<literal>,<literal>_<literal> Multiple specified ranges
(eg:4..13,31..41)

Class Diagram Example

Use Case Diagrams

Use Case Diagrams describe the functionality of a system and users of the system.
These diagrams contain the following elements
 • Actors, which represent users of a system, including human users and other
systems
• Use Cases, which represent functionality or services provided by a system
to users

Use Case Relationships

Three kinds:
 Generalization, a more specialized use case is related to a more general use
case.
 Include, the base use case explicitly incorporates the behavior of another
use case at a location specified in the base
 Extend, the base use case implicitly incorporates the behavior of another use
case at a location specified by the extending use case (extension point)

Use Case Diagram Parts

A use case diagram commonly contains:
 use cases
 actors
 relationships:
Dependency - between use cases
Generalization - between use cases or actors
Association - between use cases and actors

Use Case Diagram Example

Object Diagrams
Object Diagrams describe the static structure of a system at a particular time.
Whereas a class model describes all possible situations, an object model describes
a particular situation. Object diagrams contain the following elements:
• Objects, which represent particular entities. These are instances of classes.
• Links, which represent particular relationships between objects. These are
instances of associations.

Creating an Object Diagram

 identify the function/behaviour of interest that results from interaction of
classes, interfaces and other artifacts
 for each function/behaviour, identify the artifacts that participate in the
collaboration as well as their relationships
 consider one scenario that invokes the function/behaviour, freeze the
scenario and render each participating object
 expose the state and attribute values of each object, as necessary to
understand the scenario
 expose the links among these objects

Object Diagram Example

Sequence Diagram
Sequence Diagrams describe interactions among classes. These interactions are
modeled as exchange of messages. These diagrams focus on classes and the
messages they exchange to accomplish some desired behavior. Sequence diagrams
are a type of interaction diagrams. Sequence diagrams contain the following
elements:
• Class roles, which represent roles that objects may play within the
interaction.
• Lifelines, which represent the existence of an object over a period of time.
• Activations, which represent the time during which an object is performing
an operation.
• Messages, which represent communication between objects.

Sequence Diagram Example

State Chart Diagrams

State chart (or state) diagrams describe the states and responses of a class. State
chart diagrams describe the behavior of a class in response to external stimuli.
These diagrams contain the following elements:
• States, which represent the situations during the life of an object in which it
satisfies some condition, performs some activity, or waits for some
occurrence.
• Transitions, which represent relationships between the different states of an
object.

State Chart Diagram Example

Collaboration Diagrams
Collaboration Diagrams describe interactions among classes and associations.
These interactions are modeled as exchanges of messages between classes through
their associations. Collaboration diagrams are a type of interaction diagram.
Collaboration diagrams contain the following elements.
• Class roles, which represent roles that objects may play within the
interaction.
• Association roles, which represent roles that links may play within the
interaction.
• Message flows, which represent messages sent between objects via links.
Links transport or implement the delivery of the message.
Collaboration Diagram Example

Activity Diagrams
Activity diagrams describe the activities of a class. These diagrams are similar to
state chart diagrams and use similar conventions, but activity diagrams describe the
behavior of a class in response to internal processing rather than external events as
in state chart diagram.
• Swim lanes, which represent responsibilities of one or more objects for
actions within an overall activity; that is, they divide the activity states into
groups and assign these groups to objects that must perform the activities.
• Action States, which represent atomic, or noninterruptible, actions of
entities or steps in the execution of an algorithm.
• Action flows, which represent relationships between the different action
states of an entity.
• Object flows, which represent the utilization of objects by action states and
the influence of action states on objects.
Activity Diagram Example

Component diagrams
Component diagrams describe the organization of and dependencies among
software implementation components. These diagrams contain components, which
represent distributable physical units, including source code, object code, and
executable code.

Component diagram Example

Deployment Diagrams
Deployment diagrams describe the configuration of processing resource elements
and the mapping of software implementation components onto them. These
diagrams contain components and nodes, which represent processing or
computational resources, including computers, printers, etc.

Nodes and Components

Components participate in the execution of a system, represent the physical
packaging of otherwise logical elements
Nodes execute components, represent the physical deployment of components
The relationship deploys between a node and a component.

Deployment Diagram Example

Advantages of UML
 You can model just about any type of application, running on any type
and combination of hardware, operating system, programming language,
and network, in UML.
 Used for modeling middleware
 UML Profiles (that is, subsets of UML tailored for specific purposes)
help you model Transactional, Real-time, and Fault-Tolerant systems in
a natural way. 
 UML is effective for modeling large, complex software systems
 It is simple to learn for most developers, but provides advanced features
for expert analysts, designers and architects
 It can specify systems in an implementation-independent manner
 10-20% of the constructs are used 80-90% of the time
 Structural modeling specifies a skeleton that can be refined and extended
with additional structure and behavior
 Use case modeling specifies the functional requirements of system in an
object-oriented manner