Systems Analysis & Design
Chapter 4 : Dr. Yahya Esmail Al-Ashmori
Unified Modeling Language (UML) Ph.D. in Information Technology
Email: Gdyahya@gmail.com
Learning Objectives
❑What is UML?
❑UML Diagram Classification
❑Explain use cases and use case diagrams and how they can be used to model system
functionality.
❑Present the basic aspects of how to create written use cases.
❑Discuss process modeling with use cases for electronic commerce application.
2
The Value of the UML
➢Is an open standard
➢Supports the entire software development lifecycle
➢Supports diverse applications areas
➢Is based on experience and needs of the user community
➢Supported by many tools
3
What is UML?
The Unified Modeling Language (UML) is a standard language for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well
as for business modeling and other non-software systems.
The UML is a very important part of developing object oriented software and the
software development process. The UML uses graphical notations to express the
design of software projects. Using the UML helps project teams communicate,
explore potential designs, and validate the architectural design of the software.
4
Overview of the UML
The UML is a language for
◦ visualizing
◦ specifying
◦ constructing
◦ documenting
the artifacts of a software-intensive system
5
Overview of the UML
➢Modeling elements
➢Relationships
➢Extensibility Mechanisms
➢Diagrams
6
The Objectives of UML
▪Ready-to-Use, Expressive Visual Modeling Language that Promotes Development/Exchange
▪Extensibility/Specialization of Core Concepts
▪Independent of Programming Languages and Development Processes
▪Formal Basis for Understanding Language
▪Encourage Growth of OO Tools Market
▪Support Higher Level Design Concepts
▪ Collaborations, Frameworks, Patterns, etc.
▪Integrate the Best Practices of All OOD
7
Why use UML
The industry looks for techniques to automate the production of software and
to improve quality and reduce cost and time-to-market. These techniques
include component technology, visual programming, and frameworks.
Businesses also seek techniques to manage the complexity of systems as they
increase in scope and scale.
8
Why use UML
Use graphical notation to communicate more clearly than natural language
(imprecise) and code(too detailed).
Help acquire an overall view of a system.
UML is not dependent on any one language or technology.
UML moves us from fragmentation to standardization.
9
UML Diagram Classification
A software system can be said to have three distinct characteristics: static,
dynamic, and implementation.
Static: the structural aspect of the system, define what parts the system is
made up of.
Dynamic: The behavioral features of a system; for example, the ways a system
behaves in response to certain events or actions are the dynamic
characteristics of a system.
Implementation: The implementation characteristic of a system is an entirely
new feature that describes the different elements required for deploying a
system.
10
Modeling Elements
Structural elements
◦ class, interface, collaboration, use case,
active class, component, node
Behavioral elements
◦ interaction, state machine
Grouping elements
◦ package, subsystem
Other elements
◦ note
11
Relationships
➢Dependency
➢Association
➢Generalization
➢Realization
12
Extensibility Mechanisms
➢Stereotype
➢Tagged value
➢Constraint
13
Models, Views, and Diagrams
State
State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams
Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams
A model is a complete Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
description of a system Statechart
Diagrams Diagrams
Diagrams Diagrams
from a particular Activity
perspective Diagrams
14
UML Diagram Classification
The UML diagrams that fall under each of these categories are:
◦ Static
◦ Use case diagram
◦ Class diagram
◦ Dynamic
◦ Object diagram
◦ State diagram
◦ Activity diagram
◦ Sequence diagram
◦ Collaboration diagram
15
UML Diagram Classification
◦Implementation
◦ Component diagram
◦ Deployment diagram
16
Use Cases
The Use case diagram is used to identify the primary elements and processes that
form the system. The primary elements are termed as "actors" and the processes
are called "use cases." The Use case diagram shows which actors interact with each
use case.
◦ UML Use Case Diagrams (UCDs) can be used to describe the functionality of a
system, they capture the functional aspects and business process in the system.
17
Use Cases
▪UCDs have only 4 major elements: The actors that the system you are describing
interacts with, the system itself, the use cases, or services, that the system knows
how to perform, and the lines that represent relationships between these elements.
▪A use case is a depiction of a system’s behavior or functionality under various
conditions as the system responds to requests from users.
▪An actor is an external entity that interacts with the system.
18
Use Cases (Cont.)
Most actors represent user roles, but actors can also be external
systems.
An actor is a role, not a specific user; one user may play many
roles, and an actor may represent many users.
A use case model consists of actors and use cases.
19
Use Cases diagrams
Use case diagram: a picture showing system behavior along with
the key actors that interact with the system
Abstract use case is when a use case is initiated by another use
case.
A use case represents complete functionality.
20
Definitions and Symbols
Use Case
Actor
Boundary
Connection
<<include>> Include relationship
Extend relationship <<extend>>
21
Definitions and Symbols (Cont.)
Actor is a role, not an individual.
◦ Involved with the functioning of the system at some basic level
◦ Represented by stick figures
Use case represents a single system function.
◦ Represented as an eclipse
22
Definitions and Symbols (Cont.)
System boundary includes all the relevant use cases.
◦ A boundary is the dividing line between the system and its environment.
◦ Use cases are within the boundary.
◦ Actors are outside of the boundary.
◦ Represented as a box
23
Definitions and Symbols (Cont.)
Connection is an association between an actor and a use case.
◦ Depicts a usage relationship
◦ Connection does not indicate data flow
◦ Actors are connected to use cases with lines.
◦ Use cases are connected to each other with arrows.
24
Use Cases (Cont.)
FIGURE 5-1 :A use case diagram for a university registration system
25
Use-Case Diagrams
Boundary Use Case
Actor
Library System
Borrow
Employee
Client
Order Title
Fine Remittance
Supervisor
26
Definitions and Symbols (Cont.)
Extend relationship is an association between two use cases where one
adds new behaviors or actions to the other.
◦ Extends a use case by adding new behavior or actions
◦ Specialized use case extends the general use case.
27
Definitions and Symbols (Cont.)
Include relationship is an association between two use cases where one
use case uses the functionality contained in the other.
◦ Indicates a use case that is used (invoked) by another use case
◦ Links to general purpose functions, used by many other use cases
28
Definitions and Symbols (Cont.)
FIGURE 5-2 :A use case diagram featuring an include relationship
29
FIGURE 5-3 :A use case example of student enrollment.
30
Written Use Cases
Document containing detailed specifications for a use case
Contents can be written as simple text or in a specified format
Step-by-step description of what must occur in a successful use case
31
Figure 5-5
A template for writing use cases
(Source: Cockburn, Alistair, Writing
Effective Use Cases, 1st ed., ©
2001. Reprinted and Electronically
reproduced by permission of
Pearson Education, Inc. Upper
Saddle River, New Jersey.)
32
Level of Use Case
Refers to degree of detail in the use case description
summary
Five suggested levels (Cockburn)
1. White – as seen from clouds
2. Kite – “birds-eye view”
3. Blue – sea-level view
4. Fish – below sea-level
5. Black – bottom of the sea detail
33
Sample Format for Written Use Case
Title – descriptive name, matches name in use case diagram
Primary actor – usually a user role
Stakeholders – any group or individual with an interest in the function of the
use case
Precondition – conditions that must be satisfied in order to execute the use case
Minimal guarantee – outputs that can be expected if the service attempt failed
Success guarantee – outputs that can be expected if the service succeeds
34
Sample Format for Written Use Case (Continued)
Trigger – an event or action that initiates the use case
Main success scenario – description of sequence of interactions between actor
and use case during the use case execution
Extensions – detailed description of how errors are handled
35
Figure 5-6: Jim Woo’s kite level written use case for buying a product at PVF’
36
Classes
❑Defines the set of shared attributes and behaviors found in each
object in the class
❑Should have a name that differentiates it from all other classes
❑Instantiate is when an object is created from a class.
❑An attribute describes some property that is possessed by all
objects of the class.
❑A method is an action that can be requested from any object of the
class.
37
Objects
▪Persons, places, or things that are relevant to the system being
analyzed
▪May be customers, items, orders, and so on
▪May be GUI displays or text areas on a display
38
Class Diagrams
▪Show the static features of the system and do not represent any
particular processing
▪Show the nature of the relationships between classes
▪Show data storage requirements as well as processing requirements
39
An Example of a UML Class: A Class Is Depicted as a Rectangle Consisting
of the Class Name, Attributes, and Methods (Figure 5.1)
40
Class Diagrams
The class diagram is the main building block of object oriented
modeling UML
Show the static features of the system and do not represent any
particular processing.
Show the nature of the relationships between classes.
41
Class Diagrams (Continued)
Class Name
Attributes
◦Private -
◦Public +
◦Protected #
Methods
42
Inheritance
➢When a derived class inherits all the attributes and behaviors of
the base class
➢Reduces programming labor by using common objects easily
➢A feature only found in object-oriented systems
43
Car and truck are
specific examples of
vehicles and inherit the
characteristics of the
more general class
vehicle.
A Class Diagram Showing Inheritance (Figure 5.2)
44
Inheritance
•Inheritance refers to the ability of one class (child class) to inherit the identical
functionality of another class (super class), and then add new functionality of its
own
•Inheritance is indicated by a solid line with a closed, unfilled arrowhead
pointing at the super class
45
The Unified Modeling Language (UML) Concepts and Diagrams
▪Things
▪Relationships
▪Diagrams
10-46
Things
▪Structural things are
▪Describe relationship between things
▪Classes, interfaces, use cases, and other elements that provide a way to create models
▪Behavioral things
▪Describe how things work
▪Interactions and state machines
▪Group things
▪Used to define boundaries
▪Annotational things
▪Can add notes to the diagrams
47
Relationships
▪Structural relationships
▪Tie things together in structural diagrams
▪Behavioral relationships
▪Used in behavioral diagrams
10-48
Structural Relationships
▪Dependencies
▪Aggregations
▪Associations
▪Generalizations
49
Behavioral Relationships
▪Communicates
▪Includes
▪Extends
▪Generalizes
10-50
Association
❑ An association is a linkage between two classes
❑ 0..1 Zero or one
❑1 One only
❑ 0..* Zero or more
❑ 1..* One or more
51
Types of associations that may occur in class diagrams.
52
Types of associations that may occur in class diagrams.
53
Aggregation
Aggregation is a special type of association used to model a "whole
to its parts" relationship. (has a)
In basic aggregation relationships, the lifecycle of a part class is
independent from the whole class's lifecycle.
10-54
Aggregation
To represent an aggregation relationship, draw a solid line from the
parent class to the part class, and draw an unfilled diamond shape on
the parent class's association end
55
Composition
• The composition relationship is another form of the aggregation relationship,
but the child class's instance lifecycle is dependent on the parent class's
instance lifecycle.
• The department cannot exist before a company exists. Here the Department
class's instance is dependent upon the existence of the Company class's
instance.
• The composition relationship is drawn like the aggregation relationship, but
this time the diamond shape is filled.
56
A Class Diagram for Course Offerings: The Filled-In Diamonds Show Aggregation
and the Empty Diamond Shows a Whole-Part Relationship (Figure 5.13)
57
Abstract Classes
▪Abstract classes are general classes
▪No direct objects or class instances, and is only used in conjunction
with specialized classes
▪Usually have attributes and may have a few methods
10-58 10-58
A Generalization/Specification Diagram Is a Refined Form of a Class
Diagram (Figure 5.5)
10-59 59
Dynamic Modeling: Sequence Diagrams
▪Sequence diagram: depicts the interactions among objects during
a certain period of time
▪ May be presented either in a generic form or in an instance form:
▪ Generic form shows all possible sequences of interactions – sequences
corresponding to all the scenarios of a use case.
▪ Instance form shows the sequence for only one scenario.
60
Dynamic Modeling: Sequence Diagrams (Cont.)
▪Elements of a sequence diagram
▪ Objects: represented by boxes at top of diagram
▪ Lifeline: the time during which an object exists
▪ Messages: means by which objects communicate with each other
61
Dynamic Modeling: Sequence Diagrams (Cont.)
Activation: the time period during which an object performs an
operation
Synchronous message: a type of message in which the caller has
to wait for the receiving object to finish executing the called
operation before it can resume execution itself
62
Dynamic Modeling: Sequence Diagrams (Cont.)
Simple message: a message that transfers control from the sender to the
recipient without describing the details of the communication
Asynchronous message: a message in which the sender does not have to
wait for the recipient to handle the message
63
Types of Messages
➢Synchronous (flow interrupt until the message has completed.
➢Asynchronous (don’t wait for response)
➢Flat – no distinction between sysn/async
➢Return – control flow has returned to the caller.
64
Sequence Diagrams
Illustrate a sequence of interactions between classes or object
instances over time
Often used to show the processing described in use case scenarios
Used to show the overall pattern of the activities or interactions in a
use case
65
Sequence Diagram - Objects
▪A life line illustrates what is happening to an object in a chronological fashion.
:Name Object
Life line
Activation
66
Specialized Symbols Used to Draw a Sequence Diagram (Figure 5.8)
67
A Sequence Diagram for Student Admission: Sequence Diagrams Emphasize the Time
Ordering of Messages (Figure 5.9)
68
FIGURE 5-10 :Sequence diagram for a class registration scenario with prerequisites
69
A Class Example for the Web
Classes may be represented using special symbols for entity,
boundary (or interface), and control classes. These are called
stereotypes, an extension to UML, which are special symbols that
may be used during analysis but are often used when performing
object-oriented design. They give an analyst freedom to play with the
design to optimize reusability
70
A Sequence Diagram for Using Two Web Pages: One for Student Information, One for Course
Information (Figure 5.13 )
71
Activity Diagrams
Show the sequence of activities in a process, including sequential and parallel
activities, and decisions that are made
Symbols
◦ Rectangle with rounded ends
◦ Arrow
◦ Diamond
◦ Long, flat rectangle
◦ Filled-in circle
◦ Black circle surrounded by a white circle
◦ Swimlanes
72
Specialized Symbols Are Used to Draw an Activity Diagram (Figure 5.13)
73
Creating Activity Diagrams
▪Created by asking what happens first, what happens second, and so on
▪Must determine what activities are done in sequence or in parallel
▪The sequence of activities can be determined from physical data flow
diagrams.
▪Can be created by examining all the scenarios for a use case
74
Swimlanes
▪A swim lane (or swimlane diagram) is a visual element used in
process flow diagrams, or flowcharts, that visually distinguishes job
sharing and responsibilities for sub-processes of a business process.
Swim lanes may be arranged either horizontally or vertically.
75
Swimlanes
▪Useful to show how the data must be transmitted or converted
▪Help to divide up the tasks in a team
▪Makes the activity diagram one that people want to use to
communicate with others
76
This Activity Diagram Shows Three Swimlanes: Client Web Page, Web Server, and
Mainframe (Figure 5.14)
77
Activity Diagrams and Test Plans
▪Activity diagrams may be used to construct test plans.
▪Each event must be tested to see if the system goes to the next state.
▪Each decision must be tested.
78
Activity Diagrams Not Created for All Use Cases
▪Use an activity diagram when:
▪It helps to understand the activities of a use case
▪The flow of control is complex
▪There is a need to model workflow
▪When all scenarios for a use case need to be shown
79
Summary
you learned how to:
✓Explain use cases and use case diagrams and how they can be used to model system
functionality.
✓Present the basic aspects of how to create written use cases.
✓Discuss process modeling with use cases for electronic commerce application.
✓How to represent system logic with sequence diagrams.
UML diagrams
◦ Use case diagrams
◦ Activity diagrams
◦ Sequence diagrams
◦ Class diagrams
80
