UNIVERSITI TEKNOLOGI MARA

CSC565
SOFTWARE ENGINEERING LAB

UNIFIED MODELING
LANGUAGE (UML)

Version 2.0

Fakulti Teknologi Maklumat & Sains Kuantitatif

WHAT IS UML?
UML stands for Unified Modeling Language
A language (notation) for modeling object-oriented
systems.
A standard maintained by the Object Management
Group (OMG).
A modeling language which has 13(++) diagrams.
Means for visualizing, specifying, constructing and
documenting software systems.
http://www.uml.org

WHAT IS UML?
The UML combines the best of the best from
Data Modeling concepts (Entity Relationship Diagrams)
Business Modeling (work flow)
Object Modeling
Component Modeling

The UML is the standard language for visualizing,

specifying, constructing, and documenting the
artifacts of a software-intensive system
It can be used with all processes, throughout the
development life cycle, and across different
implementation technologies

HISTORY OF THE UML

Nov 97

UML approved by the OMG

UML THE LONG STORY

UML SUPPORTS APPLICATION

DEVELOPMENT
Objects

Relationships
Business Objects
large scale system

ORDBMS
Oracle
Classes

application partitioning

Components
Microsoft

Use Cases

Scenarios

ActiveX/COM
Microsoft

CORBA
OMG
Business Process

CSC565 - SOFTWARE ENGINEERING

UML CONCEPTS
The UML may be used to
Display the boundary of a system & its major
functions using use cases and actors
Illustrate use case realizations with interaction
diagrams
Represent a static structure of a system using class
diagrams
Model the behavior of objects with state transition
diagrams
Reveal the physical implementation architecture with
component & deployment diagrams
Extend functionality with stereotypes

UML DIAGRAMS PART I

UML DIAGRAMS PART II

Diagram
Activity Diagram
Class Diagram

Description
Depicts high-level business processes, including data flow, or to model the logic of complex logic within a
system.
Shows a collection of static model elements such as classes and types, their contents, and their relationships.

Communication
Diagram

Shows instances of classes, their interrelationships, and the message flow between them. Communication
diagrams typically focus on the structural organization of objects that send and receive messages. Formerly
called a Collaboration Diagram.

Component
Diagram

Depicts the components that compose an application, system, or enterprise. The components, their
interrelationships, interactions, and their public interfaces are depicted.

Composite Structure
Diagram
Deployment
Diagram
Interactive Overview
Diagram

Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction
points of the classifier to other parts of the system.
Shows the execution architecture of systems. This includes nodes, either hardware or software execution
environments, as well as the middleware connecting them.
A variant of an activity diagram which overviews the control flow within a system or business process. Each
node/activity within the diagram can represent another interaction diagram.

Object Diagram

Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a
communication diagram.
Shows how model elements are organized into packages as well as the dependencies between packages.

Package Diagram

Sequence Diagram Models the sequential logic, in effect the time ordering of messages between classifiers.

Learning
Priority
High
High
Low

Medium
Low
Medium
Low
Low
Low
High

State Machine
Diagram

Describes the states an object or interaction may be in, as well as the transitions between states. Formerly
referred to as a state diagram, state chart diagram, or a state-transition diagram.

Medium

Timing Diagram

Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the
change in state of an object over time in response to external events.

Low

Use Case Diagram

Shows use cases, actors, and their interrelationships.

refer to: http://www.agilemodeling.com/essays/umlDiagrams.htm

Medium

APPLYING UML

UMLS VIEW MODELS

A view model or viewpoints framework is a
framework which defines a coherent set of views
to be used in the construction of a system
architecture, software architecture or enterprise
architecture .
A view is a representation of a whole system
from the perspective of a related set of certain
concerns.
View model provides guidance and rules for
structuring, classifying, and organizing system
architectures.

NOMINAL VIEW MODELS

In Framework for Modeling Space Systems
Architectures, Peter Shames and Joseph
Skipper (2006) define nominal view as a list
of possible modeling viewpoints.
Enterprise Viewpoint
Information Viewpoint
Functional Viewpoint
Physical Viewpoint
Engineering Viewpoint
Technology Viewpoint

ENTERPRISE ARCHITECTURE VIEW

MODELS
Enterprise Architecture framework defines how to
organize the structure and views associated with an
enterprise architecture.
Since the enterprise architecture can be large and
complex, the models produced tend to be large and
complex.
To manage these scale and complexity, an Architecture
Framework provides tools, methods and guidelines.
Zachman Framework
RM-ODP Views
DoDAF Views
Federal Enterprise Architecture Views

GENERIC VIEW MODELS

Three Schema Approach an approach to build
information systems and systems information
management that promotes the conceptual model as
the key to achieve data integration.
External schema for user views
Internal schema that defines physical storage structures
Conceptual schema integrates internal and external
schemas

GENERIC VIEW MODELS

Three Views Model which
divides the diagrams accordingly
based on the type of the
diagrams i.e. functional, static
and dynamic.
An analysis level comprises
the functional view as well as a
subset of static and dynamic
views, excluding the component,
deployment and collaboration
diagrams.
A design view emphasis on
collaboration diagrams and the
design detail of class diagrams
and which includes component
diagrams and deployment
diagrams.

GENERIC VIEW MODELS

4+1 is a view model designed by Philippe Kruchten in 1995 for describing
the architecture of software-intensive systems, based on the use of
multiple, concurrent views
Logical view : is concerned with the functionality that the system provides to
end-users.
Development view : illustrates a system from a programmers perspective and
is concerned with software management
Process view : deals with the dynamic aspect of the system, explains the
system processes and how they communicate, and focuses on the runtime
behaviour of the system.
Physical view : depicts the system from a system engineer's point-of-view. It
is concerned with the topology of software components on the physical layer,
as well as communication between these components

In addition selected use cases or scenarios are utilized to illustrate the

architecture. Hence the model contains 4+1 views.

4+1 VIEWS MODEL

4+1 VIEWS MODEL

Use Case View
Use Case Analysis is a technique to capture business process from users
perspective
Encompasses the behavior as seen by users, analysts and testers.
Specifies forces that shape the architecture.
Static aspects in use case diagrams; Dynamic aspects in interaction (state
machine and activity) diagrams.

Design View
Encompasses classes, interfaces, and collaborations that define the vocabulary
of a system
Supports functional requirements of the system.
Static aspects in class and object diagrams; Dynamic aspects in interaction
diagrams

Process View
Encompasses the threads and processes defining concurrency and
synchronization that addresses performance, scalability, and throughput issues
Static and dynamic aspects captured as in design view; emphasis on active
classes

4+1 VIEWS MODEL

Implementation View
Encompasses components and files used to assemble and
release a physical system
Addresses configuration management.
Static aspects in component diagrams; Dynamic aspects in
interaction diagrams

Deployment View
Encompasses the nodes that form the system hardware
topology
Addresses distribution, delivery, and installation
Static aspects in deployment diagrams; Dynamic aspects in
interaction diagrams

RULES OF UML
Well formed models semantically self-consistent and
in harmony with all its related models
Semantic rules for
Names what you can call things
Scope context that gives meaning to a name
Visibility how names can be seen and used
Integrity how things properly and consistently relate to one
another
Execution what it means to run or simulate a dynamic
model

Avoid models that are

Elided certain elements are hidden for simplicity
Incomplete certain elements may be missing
Inconsistent no guarantee of integrity

PROCESS FOR USING UML

Use case driven use cases are primary
artifact for defining behavior of the system
Architecture-centric the systems
architecture is primary artifact for
conceptualizing, constructing, managing, and
evolving the system
Iterative and incremental managing
streams of executable releases with
increasing parts of the architecture included

APPLYING UML

A SIMPLIFIED VERSION

UNIVERSITI TEKNOLOGI MARA

Thank You