Object Oriented Software Analysis and Design

Wolkite University
College Of Computing and Informatics

Department of Software Engineering
Object Oriented Software Analysis and

Design
Chapter II
Part-I
Modeling using UML
Understanding modeling tools in System/Software development
Chapter Objective
• To be familiar with UML diagrams
• To appreciate different aspects modeling
process in system development
Compiled By: Aliazar D.

OO METHODOLOGIES
• During the early 90s, there were around 50 O-O
methodologies among them:
– Rumbaugh’s Object Modeling Technique (OMT): Class and
Associations
– Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),
– Booch Method : Categories and Subsystems
– 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

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

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.

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

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

OMT – Object Modeling Technique by Jim Rumbaugh OMG-Object Management Group
Booch – categorizing and subsystems by Grady Booch WWW-World Wide Web
OOPSLA-Conferenece on O-O Programming systems, Languages and applications

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.

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

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.

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

UML STRUCTURE
UML
Building Common Architecture

mechanisms
blocks
Building blocks Common Architecture
– Things mechanisms  Use-Case View
– Relationships • Specifications  Logical View
– Diagrams • Adornments  Process View
• Common Divisions  Implementation View
• Extensibility Mechanisms  Deployment View

BUILDING BLOCKS OF UML
1. Things – the abstractions (The objects)
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. An notational things – explanatory parts of UML: Note

Cont..
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 (employed)
Cont..
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)

Cont..
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.

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

Cont..
The most commonly used UML diagrams are:
– Use case diagram, describing how the system is
used.
• The starting point for UML modeling.
– Activity diagram.
• Each use case may create one activity diagram.

Cont..
– Sequence diagram, showing the sequence
of activities and class relationships.
• Each use case may create one or more
sequence diagrams.
• A collaboration diagram is an alternative to a
sequence diagram.

Cont..
– Class diagram, showing 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.

Overview of UML Diagrams

RULES OF UML
UML’s building blocks should be put together to develop a
well-formed model.
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.

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
Transaction
important aspects of the element.
+execute() • Every element in the UML’s notation starts with a basic symbol,
+rollback()
#priority() to which can be added a variety of adornments to that symbol.
-timestamp()

Cont..
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.

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.

Cont..
Software architecture is not only concerned with
architecture and behavior, but also with usage,
functionality, performance, resilience, reuse,
comprehensibility, economic and technology
constraints, and aesthetic 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
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

• 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 distribution
throughput delivery
installation
• Each view focused on a particular aspect of the system, are stand alone and interact with each
other

• 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

• 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, statechart diagram (dynamic)

• 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

• 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
Functional Model
Use Case Diagram
Essential
System
USE CASE MODEL
• Use cases are the first and primary means and a
standard technique for gathering requirements in
many modern software development
methodologies.
• 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.

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

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

System Use case Modeling
The system use case talks 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.

Use case Components
• Diagram with the following components
– Actors
– Use cases
– Boundary
– Relationship (Associations, include or use, Extend)
• Documentation
– For each use case using the standard template

USE CASE DIAGRAM
• Shows the relationship between actors and
use cases in a system
• A use case diagram for a system consists of :
– The system boundary
– Actors
– Use cases
– Relationships (among use cases, among actors,
and between actors and use cases)

On-line Bookstore System
Register
Order books
Customer
Sell used
books
Review books
Use Case Functional Requirements 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
The first is Essential usecase diagram and the latter is System usecase
diagram!

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.

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

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.

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

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.

Cont..
• Actors are external to the system. Actors interact with the
system.
• 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 portray roles in the system.
Doctor Patient Student

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.
• A use case describes what a system does; not how.
• To identify Use cases list the discrete business
functions in your problem statement - potential
use case.
• Remember that identifying use cases is a discovery
rather than a creation.

Cont..
 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 the 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.
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

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.

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.

RELATIONSHIPS
• Relationships between actors and use
cases
• are represented by directional or non-
directional edges
• May be annotated by stereotypes
– May relate two use cases
– May relate two actors, or
– May relate a use case and an actor

Cont..
• 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).
Cont..
• 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.
<<extend>>
• E.g. (CustID)

Cont..
 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.

Cont..
Place Order «extends»
___________ Place rush oder
set priority
<<includes>>
Check password
<<includes>>
Track Order
Validate User
Retinal Scan
The diagram shows the Includes, extends, and Generalization (From

specialization to generalized use case) relationships.

Cont..
Library User (Patron)
Faculty Members NonAcademic Staff Students External User
2ndYear 3rdYear 4thYear 5thYear Postgraduate
The diagram shows the Generalization (From specialization to

generalized Actor) relationship.
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

SYSTEM BOUNDARY
A use case diagram depicting the system
boundary of a clinic application
Clinic
* Make Appointment
*
Patient
Perform Medical
Tests
* *
Doctor
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

Use cases must not be seen as a
panacea
– 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.

To continued on
Structural Model:
Class/Object diagram
Question ?
? Compiled By: Aliazar D.
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

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.

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
1. 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.
2. Use cases provide a way for developers to
approach an element and understand it.
3. Use cases serve as the basis for testing each
element as it evolves during development.
Good Practice
• Develop a use case diagram at different
levels wherever appropriate.
• It Minimizes complexity
– System level
– Module level
– Class
– Interface
– etc

HINTS AND TIPS: For developing use cases
• The goal is to develop a well-structured use case
that:
– Names a single identifiable, and reasonably
atomic behavior of the system or part of the
system.
– Factors common behavior by pulling such
behavior from other use cases that it includes.
– Factors variants by pushing such behavior into
other use cases that extend it.
– Describes the flow of events clearly enough for
an outsider to easily understand it.
– Is described by a minimal set of scenarios that
specify the normal and variant semantics of the
use case.
HINTS AND TIPS
• A well-structured use case diagram

– Is focused on communicating one aspect of a
system’s static use case view.
– Contains only those use cases that are essential
to understanding that aspect.
– Provides detail content with its level of
abstraction.
– Is not so minimalist as to misinform the reader
about semantics that are important.

Quiz
 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:
1, Develop a use case model(Essential and system use case)-Provide your
reason to pick “one” as a component of your model
2, Document one of the use cases you have identified “sell used book”

On-line Bookstore System
Register
<<extend>>
(CustID) Check out
Customer Order books
<<include>>
<<include>>
Sell used Log-in
books
<<include>>
Review books

• 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.

Object Oriented Software Analysis and Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented Software Analysis and Design

Uploaded by

Copyright:

Available Formats

Wolkite University

College Of Computing and Informatics

Object Oriented Software Analysis and

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

• A language whose vocabulary and rules

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Building Common Architecture

Compiled By: Aliazar D.

Compiled By: Aliazar D.

B. Association – a structural relationship that describes

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Systems development using UML can be made simpler by the

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Design view Implementation view

behavior Use case view

Process view Deployment view

performance system topology

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

The system use case talks more or less same concept

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Use Case Functional Requirements Diagram

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Alternative Course of Action A: The item is not available in store

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Doctor Patient Student

Compiled By: Aliazar D.

Compiled By: Aliazar D.

 Use cases have the following characteristics:

Compiled By: Aliazar D.

Compiled By: Aliazar D.

Compiled By: Aliazar D.