Object-Oriented Software

Engineering

Chapter II- Modeling using UML

Understanding modeling tools in
system/software development

1
 Chapter II- Topics
Overview- The UML
Functional Model
Use Case Diagram (essential and system)
Structural Model
Class/object, Component and Deployment Diagram
Behavioral Models
Activity, State chart, sequence /collaboration

2
 Chapter 5 System Modeling

Overview- The UML

3
 OO METHODOLOGIES
 During the early 90s, there were around 50 O-O
methodologies among them:
 Rumbaugh’s Object Modeling Technique (OMT): Class and
Associations – OOA and OOD
 Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),
 Booch Method : Categories and Subsystems - Diagrams
 Wirfs-Brock (Responsibility-Driven Design /Class
/Responsibility /Collaboration) RDD/CRC,
 Coad/Yourdon Methodology : Class, Object, Class-&-Object
 Jacobson Object-Oriented Software Engineering (OOSE) Use
case driven

4
 PROBLEMS
The existence of different OO methodologies resulted in
the following problems:
Resulted in multitude interpretation of same
concepts
Encouraged confusion
Limited the progress of methods
Methods influenced one another

5
 THE NEED FOR
STANDARDIZATION
 There are many methods and notations competing with
each other that users are distracted by the decisions they
need to make.
 Existing methods are already converging since these
methods pick up ideas from other sources.
 A single, common language is desirable because it can be
used for all development methods, used throughout the
project lifecycle, and used for different application
technologies.

6
 THE UNIFICATION
Based on the fact that differences between the
various methods were becoming smaller.
The method wars did not move OOT any longer.
Jim Rumbaugh and Grady Booch decided at the end
of 1994 to unify their work within a single method:
the Unified Method.
Definition of a universal language for O-O modeling
Unified Method 0.8 Oct. 1995

7
 THE UNIFICATION…
 A year later they were joined by Ivar Jacobson
 Objective: Standardization of the o-o development
process
 The Unified Method was transformed into UML- the
Unified Modeling Language
 6/96 UML 0.9
 9/96 UML 0.91
 A consortium of partners created

8
9
 THE UNIFIED MODELLING LANGUAGE (UML)
 A language whose vocabulary and rules focus on
the conceptual and physical representation of a
system.
 UML defines structural and behavioral things and
diagrams.
 UML is the language of blueprints for software.

10
 UML…
It is a graphical language for
Visualizing
Specifying – building models that are precise,
unambiguous, and complete
Constructing – possible to map from a model in the
UML to a programming language
Documenting
Intended for software-intensive systems

11
 WHAT UML IS NOT
UML is not a method or methodology (Method
= Notation (e.g.,UML) + Process)
UML does not dictate a particular process
UML can be used to record the resulting
domain and design models, independent of the
process
Choose an appropriate process for a particular
project, independent of the modeling language

12
 WHY USE UML
Standardized notation without sacrificing
specialized model data
Common language that can be used from product
conception to delivery, from system to detailed
design levels
Reduced learning curve across projects
Increased domain and design model reuse
Increased customer involvement /understanding of
problem translation to product solution

13
 UML STRUCTURE
UML

Building Common Architecture

mechanisms
blocks
 Building blocks  Architecture
 things
 use-case view
 relationships  logical view
 Diagrams  process view
 Common mechanisms  implementation view
 specifications
 deployment view
 Adornments (decoration)
 common divisions
 extensibility mechanisms
14
 The Unified Modeling Language (UML)
UML has three building blocks:
Things, the objects.
Relationships, the glue that holds things together.
Diagrams, categorized as either structure or behavioral.

15
 UNDERSTANDING UML
 BUILDING BLOCKS OF UML
1. Things – the abstractions
1. Structural things – nouns, static, represent
conceptual or physical elements: Class, interface,
collaboration, use case, active class, component, and a node
2. Behavioural things – verbs, dynamic, represent
behaviour over time and space: Interaction and state
machine
3. Grouping things – organizational parts of UML:
Packages
4. Annotational things – explanatory parts of UML:
Note
16
 BUILDING BLOCKS OF UML…
2. Relationships – tie things together
A. Dependency (uses) – a semantic relationship
between two things in which a change to one thing
(the independent thing) may affect the semantics of
the other thing (the dependent thing)
A car uses a fuel

B. Association – a structural relationship that describes

a set of links, a link being a connection among
objects. association
0..1 *
employer employee
role name
17
 BUILDING BLOCKS OF UML…
C. Generalization (is-a) –
a specialization/generalization relationship in which objects of the
specialized element (the child) are substitutable for objects of the
generalized element (the parent)

18
 BUILDING BLOCKS OF UML…
3. Diagram
The graphical representation of a set of elements
Help to visualize a system from different perspectives
May contain any combination of things and
relationships.

19
 UML DIAGRAMS
Diagrams used to describe structure
 Class diagram
 Object diagram
 Component diagram
 Deployment diagram
Diagrams used to describe behavior and Function
 Use Case diagram (functional)
 Sequence diagram
 Activity diagram
 Collaboration diagrams
 Statechart diagram

20
 Commonly Used UML Diagrams
The most commonly used UML diagrams are:
Use case diagram, describing how the system is used.
 The starting point for UML modeling.
 Capture the high level of a system from the user point of view
Activity diagram.
 Each use case may create one activity diagram.
 Represent the workflow of the system usecase

21
 Commonly Used UML Diagrams
Sequence Diagram:
Showing the sequence of activities and class
relationships.
Represent the communication among objects
that identified
Each use case may create one or more sequence
diagrams.
A collaboration diagram is an alternative to a
sequence diagram.

22
 Commonly Used UML Diagrams
Class diagram:
Shows the structure of a system in terms of
classes and relationships.
Sequence diagrams and CRC cards are used to
determine classes.
Statechart diagram:
Each class may create a Statechart diagram,
useful for determining class methods.
Used to determine the behavior of a class

23
 Overview of UML Diagrams

24
 RULES OF UML
 UML’s building blocks should be put together to develop a
well-formed model.
 well-formed model is a model that is semantically self-
consistent and in harmony with all its related models.
The UML has semantic rules for
 Names: What you can call things, relationships, and diagrams
 Scope: The context that gives specific meaning to a name.
 Visibility: How those names can be seen and used by others
 Integrity: How things properly and consistently relate to one another.
 Execution: What it means to run or simulate a dynamic model.

25
 COMMON MECHANISMS IN
UML
Systems development using UML can be made simpler by the
presence of common mechanisms:
1. Specifications – Behind every part of UML’s graphical notation
there is a specification that provides a textual statement of the
syntax and semantics of that building block.
• Specification are used to state the system’s details.
• Provides a semantic backplane that contain all the parts of
all the models of the system.
• Example – a class diagram
2. Adornments – Most elements in the UML have a unique and
direct graphical notation that provides a visual representation of
the most important aspects of the element.
• Every element in the UML’s notation starts with a basic
Transaction symbol, to which can be added a variety of adornments to
that symbol.
+execute()
+rollback()
#priority()
26 -timestamp()
 COMMON MECHANISMS IN UML…
3. Common divisions
Class and Object
Costomer : Costomer
-name name Alemayehu : Costomer
-address
-phone
address name
phone address
phone
4. Extensibility mechanisms
UML can be extended using the following mechanisms
• Stereotypes: Extends the vocabulary of UML, allowing you to create new
kinds of building blocks that are derived from existing ones but that are
specific to your problem.
• Constraints: Extends the semantics of a UML building block, allowing you
to add new rules or modify existing ones.

27
 ARCHITECTURE
Architecture is the set of significant decisions about
The organization of a software system
The selection of the structural elements and their interfaces
by which the system is composed
Their behavior, as specified in the collaborations among
those elements
The composition of these structural and behavioral
elements into progressively larger subsystems
The architectural style that guide this organization: the
static and dynamic elements and their interfaces, their
collaborations, and their composition.

28
 ARCHITECTURE
Software architecture is not only concerned with
architecture and behavior, but also with usage,
functionality, performance, resilience, reuse,
comprehensibility, economic and technology
constraints and trade-offs, and aesthetic/visual
concerns.
Architecture of a system can be described by a view.
A view is simply a subset of UML modeling
constructs that represent one aspect of the system
Each of the views involve structural and behavioural
models
29
 Views of a system
Systems can be viewed from a number of perspectives
different stakeholders: system owners, end users, analyst,
developers, project managers etc
Each looks at the system in different angle at different times
over the project’s life span
System architecture can be used to manage these different
viewpoints, therefore controlling the development of a
system throughout its life cycle

30
 UML captures these different angles/viewpoints as a set of five
interlocking views: -
vocabulary system assembly
functionality configuration mangmt

Design view Implementation view

behavior Use case view

Process view Deployment view

performance system topology

scalability throughput distribution delivery
installation
• Each view focused on a particular aspect of the
system, are stand alone and interact with each other
31
 Use case view
Focuses on scenarios executed by
human users and external systems
Expresses what the new system will
do without specifying how it will do it
End-product: use case diagrams

32
 Design views
Supports the functional requirements of the system
Focuses on the things (classes, interfaces and
collaborations) that form the vocabulary of the problem
that the system is trying to solve and the elements of the
solution to that problem.
The view encompasses the static and dynamic aspects of
the system
End-product: class and object diagram (static),
sequence/collaboration, activity and statechart diagram
(dynamic)

33
 Process view
Focuses on the aspects of the system that
involves timing and the flow of control.
Addresses the performance, scalability and
throughput of the system
End product: activity diagrams

34
 Implementation view
Encompasses the components and files that are used to
assemble and release the physical system
End-product: component diagrams

Deployment view
Focuses on the geographic distribution of the various
software elements on hardware and other physical elements
that constitute a system
Encompasses the nodes that form the system’s hardware
topology on which the system executes
End-product: deployment diagram

35
 Functional Model

Use Case Diagram

1) Essential
2) System

36
 USE CASE MODEL
Use Case analysis is one of the first and primary
means of gathering requirements in the behavioral
methodology.
Used to capture the intended behaviour of the
system under development (requirements of a
system)
The Use case diagram is used to identify the
primary elements and processes that form the
system.

37
 Cont…
Represents the functional requirements of a system
under development
Captures the business processes carried out in the
system
A use case model may consists of
Single use case diagram
Further (nested) packages of use case diagrams
The supreme package of the nested packages is the use
case model

38
 Cont..
Use case Modeling could be
Essential
 Used at requirement elicitation stage
 Technology free
 Just to understand what users need to see on the system from
functions point of view
System
 Is a continuation of essential use case
 Adding implementation related details

39
 System Use case Modeling
The system use case talks more about more or less
same concept like the essential use case with some
details of the implementation.
The modeling will be influenced by the technology
to be used for the systems development.
System use case model is composed of the system
use case diagram and its corresponding
documentation.
The use case diagram and the documentation will
have same components as the essential use case
model with little technology influence.
40
 Components
Shows the relationship between actors and use
cases in a system
Diagram with the following components
Actors
Use cases
Boundary
Relationship (Associations, include or use, Extend)
Documentation
For each use case using the standard template

41
 On-line Bookstore System

Register

Customer Order books

Sell used
books

Use Case Functional Review books

Requirements
42 Diagram
 What is the difference with the previous use case?
Sell Item <<
Inc
lud
es
>>

Reorder
<<Includes>>
Sales Clerk

Login

Add to Stock
<<Includes>>

<<Includes>>

Generate
Report

Manager

43
 Cont…
The Use Case documentation needs information like:
List of Actors
List of Business Rules (BR)
List of User Interfaces (UI)
 The template will be the same as the essential use
case documentation except that the “Include” and
“Extend” part will be exercised (included) at this
level.
The following example describes one of the use cases
from the previous use case diagram.

44
 Use case documentation
Name Sell Item
Identifier UC-008
Description Sell available items in a store to a customer
Actor Sales Clerk
Pre Condition none
Post Condition The sales clerk will sell the item if available in store

Extends none
Includes UC-001
Basic Course of Action
1.The Sales Clerk want to sell an item
2.The Sales Clerk logs into the system using “UC-001: Login”
3.The system displays the main Window “UI-002: Main Menu”
4.The Sales Clerk selects “Sell” from the Main Menu
5.The system displays the Sell interface “UI-006: Sell Item”
6.The Sales Clerk selects the items and quantity he want to sell
7.The system check the availability of the items according to the business rule “BR-012: check availability of item”
8.The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
9.The Sales Clerk indicates he want to print the payment voucher.
10.The system prints the payment voucher
11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer.
Alternative Course of Action A: The item is not available in store
8.The system determines that the item is not available.
9.The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not Available”
10.The use cases resumes at step 6 of the basic course of action

45
 Cont…
Note
Association between Actors and Use cases dictate the
need for Interfaces (screen or Report)
Use case description does not include unexpected
interruption of the action either by the actor or by system
failure
The flow of events should be in
action-response style.

46
 General steps in Use case Modeling
Identify actors from the SRS or problem definition
Identify use cases
Identify relationships
Use symbols for representing use cases and actors with
in a boundary
Define use case description

47
 Actor
An actor define roles that users can play.
Actors model anything that needs to exchange
information with the system
The different roles the actor represents are the actual
business roles of users in a given system.
An actor in a use case diagram interacts with a use case.

48
 Actor …
Actor classes have actors instances or objects that
represent specific actors.
An actor is shown as a stick figure in a use case
diagram depicted "outside" the system boundary.
To identify an actor, search in the problem
statement for business terms that describe roles in
the system.

Doctor Patient Student

49
 USE CASES
A use case is a specific way of using the system by
performing some part of the functionality.
A visual representation of a distinct business
functionality in a system.
The business process is discrete in nature.
A use case describes what a system does; not how.
List the discrete business functions in your
problem statement - potential use case.
Remember that identifying use cases is a
discovery rather than a creation.

50
 USE CASES …
 A use case is shown as an ellipse in a use case diagram
Perform Medical
Make Appointment
Tests

 Use cases have the following characteristics:

 Use case are interactions or dialogs between a system and actors,
including the messages exchanged and the actions performed by the
system. Use cases may include variants of these sequences, including
alternative and exception sequences.
 Use cases may be initiated by actors and may involve the participation
of numerous other actors.
 Use cases may have extension points that define specific points within
an interaction at which other use cases may be inserted
 Use cases classes have use case instances or objects called scenarios
that represent specific interactions.
51
 Use-Cases: describing how the user will
use the system
 A use case is a typical sequence of actions that a user
performs in order to complete a given task
 The objective of use case analysis is to model the system
from the point of view of
… how users interact with this system
… when trying to achieve their objectives.
It is one of the key activities in requirements elicitation and analysis

52
 Use cases
A use case should
Cover the full sequence of steps from the beginning of a
task until the end.
Describe the user’s interaction with the system
 Not the computations the system performs.
Be written so as to be as independent as possible from
any particular user interface design.
Only include actions in which the actor interacts with the
computer.

53
 Scenarios
A scenario is an instance of a use case
A specific occurrence of the use case
 a specific actor ...
 at a specific time ...
 with specific data.

54
 RELATIONSHIPS
Relationships between actors and use cases
 represented by directional or nondirectional edges
 May be annotated by stereotypes
May relate two use cases
May relate two actors, or
May relate a use case and an actor

55
 RELATIONSHIPS
 Association
denoted as solid lines or paths.
Arrowheads may be used to indicate who initiates
communication in the interaction.
 Includes
Indicates that the base use case will contain the inclusion
use case.
A base use case defines the location at which the inclusion
use case is included.
Denoted as dashed lines with an open arrow-head
pointing at the inclusion use case and are labelled with
the <<include>> keyword (stereotype).

56
 RELATIONSHIPS …
 Extends
Indicates that the base use case may be augmented by
the extension use case; i.e., the inclusion use case will
augment the base use case if an extension condition is
satisfied.
A base use case defines the extension point.
Denoted
 as dashed lines or paths with an open arrow-head pointing an
extension use case
 labelled with the extension condition in square brackets,
 the <<extend>> keyword (stereotype), and
 the extension point name in parentheses.

57
 RELATIONSHIPS …
 Generalization
 From specialization to generalized use case
 Indicate the specialization use cases are consistent with the
generalized use case and may add additional information.
 A specialized use case may be used in place of a generalized use
case and may use any portions of the interaction of the
generalized use case.
 Denoted as solid lines or paths with a hollow arrow-head pointing
at the generalized use case.
 From specialization to generalized Actor
 The specialized actor are consistent with the generalized actor and
may add additional information.
 A specialized actor may be used in place of a generalized actor
and receives the characteristics of the generalized actor.
 Denoted as solid lines or paths with a hollow arrow-head pointing
at the generalized actor.

58
 System Boundary
 The use case describes the functionality of a system from
an outside point of view – from the users point of view.
 Only the interaction between actors and system are
shown, what happens inside the system is hidden.
 This boundary is clarified by the system boundary
 Defines the scope of what a system will be.
 A system boundary of a use case diagram defines the limits
of the system.
 The system boundary is shown as a rectangle spanning all
the use cases in the system

59
 SYSTEM BOUNDARY
A use case diagram depicting the system
boundary of a clinic application
Clinic
* Make Appointment
*
Patient

Perform Medical
Tests
* *

Doctor
60
 FLOW OF EVENTS
Specify the behavior of a use case by describing
the flow of events in text clearly enough for an
outsider to understand it easily.
Include
How and when the use case starts and ends
When the use case interacts with the actors
What objects are exchanged
The basic flow and alternative flows of the behavior

61
 FLOW OF EVENTS…(major elements)
 Introduction: Describe a quick background of the use case.
 Actors: List the actors that interact and participate in this
use case.
 Actor Description/Definition: Define/Describe each actor.
 Pre-conditions: Pre-conditions that need to be satisfied for
the use case to perform.
 Post-conditions: Define the different states in which you
expect the system to be in, after the use case executes.
 Basic Flow: List the primary events that will occur when this
use case is executed.
 Alternative flows: Any subsidiary events that can occur in
the use case should be separately listed. List each such event
as an alternative flow. A use case can have as many
alternative flows as required.
62
 COMMON MODELING TECHNIQUE
 The most common thing for which you will apply
use case is to model the Functional behavior of an
element ; A system as a whole, a subsystem, or a
class
Focus on what that element does, not how it does
 Reasons for applying use cases to elements
a) By modeling the behavior of an element with use cases,
you provide a way for domain experts to specify its
outside view to a degree sufficient for developers to
construct its inside view.
b) Use cases provide a way for developers to approach an
element and understand it.
c) Use cases serve as the basis for testing each element as
it evolves during development.

63
 Example:
 On-line Bookstore is a web application that can be accessed
by the store’s registered customer, whereby each customer
can order books, review one or more books sold in the book
store, and sell used books to other customers. Before
performing any one of these transactions, the customer must
first log-in into the system using their user id and password
kept in their account. The customer can also take a book
he/she ordered.
 Problems:
 Develop a use case model(system use case)-Provide your
reason to pick “one” as a component of your model
 Document one of the use cases you have identified “sell
used book”
64
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out
Customer Order books
<<include>>

<<include>>
Sell used Log-in
books
<<include>>

Review books

65
 Use case: Sell used books
Main flow of events: -
1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used
books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information
that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are
accurate.
If yes, the CUSTOMER clicks the OK button on the web page.
7. The system updates the USED BOOKS table in the database.

66
 The benefits of basing software
development on use cases
They can
Help to define the scope of the system
Be used to plan the development process
Be used to both develop and validate the requirements
Form the basis for the definition of test cases
Be used to structure user manuals

67
 Use cases must not be seen as a solution
The use cases themselves must be validated
 Using the requirements validation methods.
Some aspects of software are not covered by use case
analysis.
Innovative solutions may not be considered.

68
 To be continued

69