01 - Introduction To UML

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 52

An Introduction to the Unified Modeling Language

Prepared by Ryan Rodriguez


For Action FE Batch 25
June 2, 2015

UML 2.0
Discussion Objective

 Define UML
 Explain the importance modeling
 Explain the importance of system design
 Explain the importance of UML in modeling and
system design
 Identify the 13 diagrams of UML 2
 Categorize the 13 diagrams according to their
function
 Identify which diagrams are applicable to which
modeling requirements
Discussion Outline

 UML in a nutshell
i. Why do we need to design a system?
ii. Why do we need to model a system?
iii. Why use UML in design and modeling?

 UML in specifics
i. 13 diagrams of UML 2.0
ii. The diagrams categorized by function
iii. When to use which diagram
UML in a Nutshell

 Stands for Unified Modeling Language


 Developed by Grady Booch, Ivar Jacobson,
James Rumbaugh at Rational Software
 A general purpose modeling language
for software engineering
 Currently being managed and maintained by the
Object Management Group
 Current version is UML 2.4.1
 For the purposes of this course, we will use UML
2.0 as baseline
What is Software Engineering?

 A systematic approach to developing a


software
 Usually comprised of the following steps:
1. Design
2. Development
3. Maintenance
The Importance of Design and
Modeling in Software Engineering
 Without a process, imagine this scenario

Hi Derpina. I want
Consider it done.
make a system
Call me, maybe,
for the Action
in 2 months.
Training
WWDD: What Would Derpina Do?
 Ask for specifics and requirements
 Make sure she understands what Derp really wants
 When requirements and functionality are clear between
both parties, Derpina will now know the volume of work
 From the volume, schedule and cost can be determined
 If Derp agrees to the price, Derpina can now roll her sleeves
and start the work
 Design
 Code
 Test
 Deliver
WWDD continued

 Requirements Gathering
 Requirements Understanding

MODELING
 Transposing the requirements to functionality
 Structuring the system to be able to deliver
the functionality, scope and volume
DESIGNING
What Modeling Achieves
 Abstraction of the real system to manage
complexity
 Aids in designing software before coding
 Assures that the target business functionalities
are complete and correct
 Assures that end-user needs are met
 Assures that development is maximized with
proper program scalability, extendibility, design,
structure etc
 Assures that software development can be
manageable and result in a successful output
Why Do We Use UML in
Modeling and Design?
 Concise, simple and straightforward
notations
 Comprehensive
- Describe different parts of the system
through different diagrams
 Scalable
 Built on a rich history of lessons learned
(almost 17 years)
 Standardized modeling language
What you can do with UML 2.0

UML 2.0 IN DETAIL


Model and Diagrams

 Model
A representation of the elements in your
system
A representation of how these elements
interact
 Diagram
A tool to represent information about your
model
UML 2.0 Diagrams Categorization

 Structure Diagrams
static application structure
 Behavior Diagrams
represent general types of behavior within an
application
 Interaction
represent aspects of interaction between
parts of a system
13 Diagrams by UML Classification
UML 2.0
Diagrams

Structure Behavior

Composite
Class Use Case Interaction
Structures

Object Deployment Activity Sequence

State Timing
Component Package
Machine
Communi-
cation
Interaction
Overview
Structure: (1) Class Diagram

1. Class Diagram
 Shows the system’s classes, their attributes,
operations (or methods), and the relationships
among the classes.
Structure: (1) Class Diagram
Structure Diagram:
(2) Object Diagram
2. Object Diagram
 Derived from class diagrams
 Represent an instance of a class diagram.
 Represent a static snapshot view of a system at
a particular moment.
Structure Diagram:
(2)Object Diagram
Structure Diagram:
(2) Object Diagram
Structure:
(3) Component Diagram
3. Component Diagram
 Used to model the physical aspect of a
system
 Items such as executables, libraries, files,
documents
Structure:
(3) Component Diagram
Structure:
(4) Composite Structure
4. Composite Structure Diagram
 Show the internal interactions between
classes
 Show interaction of a class to other parts of
the system
Structure:
(4) Composite Structure
Structure:
(5) Package Diagram
5. Package Diagram
 Used to organize model elements into
groups, making your UML diagrams simpler
and easier to understand. Packages are
depicted as file folders
Structure:
(5) Package Diagram
Structure:
(6) Deployment Diagram
6. Deployment Diagram
 Deployment diagrams are used for describing
the hardware components where software
components are deployed. Component
diagrams and deployment diagrams are
closely related.
 Component diagrams are used to describe
the components and deployment diagrams
shows how they are deployed in hardware.
Structure:
(6) Deployment Diagram
Behavior:
(1) Use Case Diagram
1. Use Case Diagram
 Describes the proposed functionality of a
new system. A Use Case represents a
discrete unit of interaction between a user
(human or machine) and the system.
 This interaction is a single unit of
meaningful work, such as Create Account
or View Account Details.
Behavior:
(1) Use Case Diagram
Behavior:
(2) Activity Diagram
2. Activity Diagram
 Show system workflow, how they start and
the possibly many decision paths that can
be taken from start to finish.
 Illustrate the where parallel processing
may occur in the execution of some
activities.
Behavior:
(2) Activity Diagram
Behavior:
(3) State Machine Diagram
3. State Machine Diagram
 Show transitions or changes of an object’s
state
 Show how an object moves from one state to
another and the rules that govern that change.
Behavior:
(3) State Machine Diagram
Interaction:
(1) Sequence Diagram

1. Sequence Diagram
 Sequence diagrams are used to display
the interaction between users, screens,
objects and entities within the system.
 It provides a sequential map of message
passing between objects over time.
Interaction:
(1) Sequence Diagram
Interaction:
(2) Communication Diagram
2. Communication Diagram
 Models the interactions between objects or
parts in terms of sequenced messages.
 Similar to sequence diagrams.
 Show which elements each one interacts with
better, but sequence diagrams show the
order in which the interactions take place
more clearly.
Interaction:
(2) Communication Diagram
Interaction:
(3) Timing Diagram
3. Timing Diagram
 Show the behavior of objects throughout a
given period of time.
 A special form of sequence diagram.
 The differences between timing diagram and
sequence diagram are the axes are reversed
so that the time is increased from left to right
and the lifelines are shown in separate
compartments arranged vertically.
Interaction:
(3) Timing Diagram
Interaction:
(4) Interaction Overview
3. Interaction Overview Diagram
 Like the Activity Diagram this visualizes a sequence
of activities
 The difference is that the individual activity in the
interaction overview diagram is pictured as a frame,
which can contain interaction - or sequence
diagrams
 All the same controls from activity diagrams (fork,
join, merge, etc.) can be used on interaction
overview diagrams to put the control logic around
the lower level diagrams
Example we have a sequence diagram for
Check Trainer Availability
We can reference that diagram
in an interaction diagram
Another example
KNOWING WHEN TO USE WHICH
DIAGRAM
Another way to group diagrams

Logical View Process View

Use Case
View
Development
Physical View
View

THE 4+1 View


Logical View
 Abstract descriptions of a system’s parts and
how these parts interact with each other

1. Class Diagram
2. Object Diagram
3. Composite Structure Diagram
4. Sequence Diagram
5. Communication Diagram
6. Interaction Overview Diagram
7. Timing Diagram
8. State Machine Diagram
Process View
 Describes must what happen within the
system

1. Activity Diagram
Development View
 describes how your system’s parts are
organized into modules and components

1. Component Diagram
2. Package Diagram
Physical View
 Describes mapping between the abstract
entities and how it is deployed in the real-
world

1. Component Diagram
2. Deployment Diagram
Use Case View
 View from a perspective outside the system

1. Use Case Diagram


Course Objective Checklist
 Define UML
 Explain the importance modeling
 Explain the importance of system design
 Explain the importance of UML in modeling
and system design
 Identify the 13 diagrams of UML 2
 Categorize the 13 diagrams according to their
function
 Identify which diagrams are applicable to
which modeling requirements
以上です ^_^
お疲れ様皆!

You might also like