Object-Oriented Systems

Analysis and Design

By Dr. Samuel Asferaw
2018/2019
 1. Introduction:
Principles of Object Oriented
Technology

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 2

History of the Unified Modeling Language) (UML)

• 1975-1988: object-oriented modeling

languages, a new genre of object-oriented
programming languages and increasingly
complex applications//OOP
• 1989-1994: increasing of object-oriented
methods (from fewer then 10 to more than
50), “method wars”. Booch, Jacobson's
OOSE, Rumbaugh's OMT, Fusion, Shlaer-
Mellor, and Coad-Yourdon methods.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 3
 History of the UML…

• 1995-2003: Grady Booch (Rational

Software Corporation), Ivar Jacobson
(Objectory), and James Rumbaugh
(General Electric) began to adopt ideas
from each other's methods. UML 0.8 … 1
• 2004-…: UML 2.0.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 4

 Object-Oriented Overview

• Object-oriented techniques work well in

situations where complicated systems are
undergoing/go through continuous
maintenance, adaptation, and design
• There are two ways to model object-oriented
systems
– Coad and Yourdon methodology
– The Unified Modeling Language (UML)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 5

 Object-Oriented Programming
• Six ideas characterize object-oriented
programming:
– An object, which represents a real-world thing or
event/element
– A class, or group of related objects
– Messages, sent between objects
– Encapsulation, only an object makes changes
through its own behavior

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 6

 Object-Oriented Programming…

• Six ideas characterize object-oriented

programming (continued):
– Inheritance, a new class created from
another class
– Polymorphism, meaning that a derived/sub
class class behavior may be different from
the base class/super class
– ability to take multiple forms.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 7

 Terminology

• Class refers to a template for a group of

individual objects with common attributes and
common behavior
• The difference between an Object and a Class
is that the class defines shared attributes and
behaviors of objects
• An object is an instance or occurrence of a
class

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 8

 Terminology…

• Another name for property is attribute

• Another name for method is operation
• Interface means the behavior of a class or
component that is noticeable/visible from outside
the class or component

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 9

 Encapsulation

• Encapsulation changes the manner in which

data is updated by programs because data can
only be changed via the services that
encapsulate the data.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 10

 Inheritance

• The two types of classes involved in any

inheritance relationship are the base
class/super and the derived class/sub
• Multiple inheritance means there will be
multiple occurrences of the base type of class
in the inheritance relationship
• Polymorphism only occurs where there is
inheritance

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 11

 Five-Layer Model

• Object oriented analysis and design is based

on a five-layer model:
– Class/object layer notes the classes and
objects
– Structure layer captures various structures
of classes and objects, such as one-to-many
relationships and inheritance.
– Attribute layer details the attributes of
classes
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 12
 Five-Layer Model…

• Five-layer model, continued

– Service layer notes messages and object behaviors
– Subject layer divides the design into
implementation units or team assignments

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 13

 Five General Types of Objects

• There are five general types of objects:

– Tangible things
– Roles
– Incidents
– Interactions
– Specifications details

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 14

 Criteria to Determine Need for a New Class of
Objects
• Criteria to determine whether a new class of
objects is justified
– There is a need to remember the object
– There is a need for certain behaviors of the object
– An object has multiple attributes
– A class has more than one object instantiation
• Unless it is a base class (abstract super class)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 15

Criteria to Determine Need for a New Class of
Objects…
• Criteria, continued
– Attributes have a meaningful value for each
object in a class
– Services behave the same for every object
in a class
– Objects implement requirements that are
derived from the problem setting

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 16

Criteria to Determine Need for a New Class of
Objects…
• Criteria, continued
– Objects do not duplicate attributes and services
that could be derived from other objects in the
system

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 17

 Methods

• Services (or methods or procedures) must be

analyzed. Activities are
– Object state analysis, showing changes of state
– Service specification: creating, storing, retrieving,
connecting, accessing, and deleting objects
– Message specification, consisting of control and
data flow

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 18

 Major Components of Object-Oriented
Design Activities

• Object-oriented design activities are grouped

into four major components:
– The problem domain component
– The human interface component

– The data management component

– The task management component

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 19

 CRC Cards

• Class, responsibilities, and collaborators

(CRC) cards are used to represent the:-
• Responsibilities of classes and the interaction
between the classes.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 20

 Creating CRC Cards

• Analysts create CRC cards by

– Finding all the nouns and verbs in a problem
statement
– Identify and refine responsibilities into smaller and
smaller tasks, if possible

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 21

 Creating CRC Cards…

• Creating CRC cards, continued

– The group determines how tasks are fulfilled by

objects or interacting with other things
– Responsibilities evolve into methods or operations

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 22

 The Unified Modeling Language (UML)

• UML (Unified Modeling Language) is the

result of a collaboration of individual object-
oriented methods that has been adopted as a
standard for modeling object-oriented
systems
• It differs from the Coad and Yourdon OOA-
OOD in the way that it breaks down objects
and their relationships

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 23

 The Unified Modeling Language (UML)…

• UML has three categories:

– Things, the objects
– Relationships, the glue that holds things together
– Diagrams, categorized as either structure or
behavioral

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 24

 Use Case

• A use case describes three things:

– An actor (user) that initiates an event
– An event that triggers a use case
– The use case that performs the actions triggered by
the event

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 25

 Steps for Creating a Use Case Model

• The steps required to create a use case

model are:
– Review the business specifications and
identify the actors within the problem
domain
– Identify the high-level events and develop
the primary use cases that describe the
events and how actors initiate them.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 26

 Steps for Creating a Use Case Model…

• Creating a use case model, continued

– Review each primary use case to determine
possible variations of flow through the use case
– Develop the use case documents for all
primary use cases and all important use case
scenarios
– Move to UML diagramming techniques to
complete the systems analysis and design

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 27

 Two General Groupings of Things

• There are two general groupings of things in UML:

– Structural things that define the conceptual and
physical structures of an O-O system and are
described by nouns
– Behavioral things, the verbs of a UML model that
represent the behavior of the system and the
states of the system before, during, and after the
behaviors occur.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 28

 Categories of Structural Things

• There are seven categories of structural things

• The first five are conceptual or logical:
– Classes
– Interfaces
– Collaborations
– Use cases
– Control or active classes
• The last two are physical in nature
– Components
– Nodes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 29

 Categories of Structural Things

• Seven categories of structural things:

– Classes, which have properties or attributes
and methods or operations
– Interfaces, the behavior of a class or
component of a system that is noticeable from
outside the class or component

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 30

 Categories of Structural Things

• Seven categories, continued

– Collaborations, which describe the interactions
of two or more things in a system that perform a
behavior that is more than any one of the things
can do alone
– Use cases, which describe a series of actions that
demonstrate a distinct/different behavior of the
system and its interactions with the actors

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 31

 Categories of Structural Things…

• Seven categories, continued

– Control or active classes

• A control class can initiate and control an independent
flow of activity within the system
– Components, which are a physical part of a system that
represents the services and interfaces implemented by the
elements contained within that component, including
software code.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 32
 Categories of Structural Things…

• Seven categories, continued

– Nodes, which represent a piece of hardware on
which your system executes
• Components are physically deployed on nodes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 33

 Behavioral Things

• Behavioral things consist of

– Interactions, or messages sent between a set of
objects within the system to perform a specific
task
– State machine, a series of states that an object
goes through in response to actions within the
system

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 34

 Types of Relationships

• There are two types of relationships that hold

things together:
– Structural
– Behavioral

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 35

 Types of Structural Relationships

• There are four types of structural

relationships:
– Dependencies, where one thing affects another
thing that uses it
– Aggregations, which show how the whole object is
composed of the sum of its parts
– Associations that describe structural connections
between things

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 36

 Types of Structural Relationships

• Four types of structural relationships, continued

– Generalizations, which describe a relationship
between a general kind of thing and a more
specific kind of thing, used for modeling class
inheritance and specialization

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 37

 Types of Active Behavioral Relationships

• There are four active behavioral relationships:

– Communicates is used to connect an actor to a use
case
– Includes describes the situation where a use case
contains a behavior that is common to more than
one use case

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 38

 Types of Active Behavioral Relationships

• Types of active behavioral relationships,

continued
– Extends describes the situation where one
use case possesses the behavior that allows
the new use case to handle a variation or
exception
– Generalizes implies that one thing is more
typical than the other thing

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 39

 UML Structural Diagrams

• UML structural diagrams include

– Class diagrams used to model the static structural
design of a system
– Object diagrams portray the state of class instances
and their relationships at a point in time

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 40

 UML Structural Diagrams…

• UML structural diagrams, continued

– Component diagrams show an overview of the
system architecture
– A deployment diagram illustrates the physical
implementation of the system, including the
hardware.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 41

 Behavioral Diagrams

• Behavioral diagrams describe the interaction

between people and a use case

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 42

 Behavioral Diagrams…

• Behavioral Diagrams include

– Use case diagrams, showing the actors and the use
cases
– Sequence diagrams that depict a succession of
interactions between object instances over time
and they show the processing described in use case
scenarios
– Activity diagrams show the flow of activities
within a process.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 43

 Behavioral Diagrams..

• Behavioral Diagrams, continued

– Collaboration diagrams illustrate a sequence of
object interactions showing the organization of the
objects during the interactions
– State chart diagrams show the states of an object
and the events and conditions that trigger a
transition from one state to another

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 44

 Steps Used in UML

• The steps used in UML are

– Define the use case model
– Define the object model
– Continue UML diagramming to model the system
during the systems analysis phase
– Begin system design by refining UML diagrams
and using them to derive classes and their
properties (attributes) and methods

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 45

 Project One
• Paper Review
Or
• Case Study
– Chapter 8 System Architecture: Satellite-Based
Navigation
– Chapter 9 Control System: Traffic Management
– Chapter 10 Artificial Intelligence: Cryptanalysis
– Chapter 11 Data Acquisition: Weather Monitoring
Station
– Chapter 12 Web Application: Vacation Tracking System
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 46
 2. Business
Modeling /Domain
Analysis/

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 47

 What is a business model?

• A business model is a simple representation of the

complex reality of a particular organization.
• Business models are useful for understanding
– How a business is organized,
– who interacts with whom,
– what goals and strategies are being pursued, followed
– what work the business performs, and

– how it performs that work.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 48
 What is a business model?...

 By business model we do not mean “how the company makes

money”.

 we mean a model that describes the details of a business: its

 Goals,
 Organizations,
 Motivations,
 Business processes,
 Business rules.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 49

 Business Modeling

• We need to learn how to create a business model that represents the

reality of a business.
• Creating a good business model is a complex skill, and like any complex
skill, it requires time, knowledge, practice, and patience to learn.
• Why Undertake assume/start Business Modeling?
– The new standard for software development is to understand the
business domain before or in parallel with development of an
application. Why?
• Because: Applications must ‘fit’ within the organization!

• Because Goals /objectives

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 50
 Modeling Business Disciplines

Four distinct business modeling disciplines

• Business process models
• Business motivation models
• Business organization models
• Business rule models

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 51

 Modeling Business Disciplines …

Business Process Models

• Capture how a business performs its work,

• the step-by-step activities that are performed

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 52

 Modeling Business Disciplines …

Business Motivation Models

• Capture the goals and strategies of a business

• What a business is attempting/try's to do and how
those attempts fit into its changing environment

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 53

 Modeling Business Disciplines …

Business Organization Models

• Capture who performs the work in an organization
and with whom they interact with, both inside the
organization and outside.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 54

 Modeling Business Disciplines …

Business Rule Models

• Capture the constraints on a business

– The external constraints from regulations and laws,
– The internal constraints from policies, rules, and
other guidance.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 55

 Integrating the four disciplines

• The four disciplines represent four dimensions that

should be reflected in the business model:
• What is the process (BPM),
• How does it serve goals (BMM),
• Who should do what (BOM),
• What rules govern the people while implementing
the process (BRM)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 56

 Integrating the four disciplines …

Example
• Any hospital includes the business process of emergency
admission.
• To completely model this business process the BPM will
model all activities: step by step activities
• Taking patient information
• Patient examination
• Patient referral to labs and ray
• Ray imaging
• Ray image reporting

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 57

 Integrating the four disciplines…

Example
• Any hospital includes the business process of emergency
admission.
• To completely model this business process the BMM will
show the link with the hospital goals :
• Taking patient information
• Patient examination
• Patient referral to labs and ray
• Ray imaging
• Ray image reporting

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 58

 Integrating the four disciplines…

Example
• Any hospital includes the business process of emergency
admission.
• To completely model this business process the BOM will link
each activity with the department that should perform it :

• Taking patient information (emergency nurse)

• Patient examination (emergency physician)
• Patient referral to labs and ray (emergency physician)
• Ray imaging (ray imaging technician)
• Ray image reporting (ray image physician)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 59

 Integrating the four disciplines …

Example
• Any hospital includes the business process of emergency
admission.
• To completely model this business process the BRM will
show the laws, policies, procedures and rules in performing
each activity:
• taking patient information (privacy rules)
• Patient examination (clinical procedures)
• Patient referral to labs and ray tests (referral procedures)
• Ray imaging (safety policies)
• Ray image reporting (privacy + timing policies)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 60

 Modeling Standards

• Standards are important in business modeling.

• A model created by one group of people should be

understandable by others.
• Others should be able to update the model when business
circumstances change.
• Models created in one modeling tool should be readable and
changeable by other tools.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 61
 Business value of business models

Business Models are requirements for software development

• Requirements provide a description of what a proposed software

application should do
• Without detailed requirements, application development projects fail

• Business models capture this detail in a way that is understandable to

both the business users and the software developers
• Business users do not need to understand how the system will be
created; they need to understand how it will support their need
• Business models are a better
By Dr. Samuel Asferaw
form
OOSAD DBU
of2018/2019
requirements for end users 62
 Sources of Domain Knowledge
• To perform business modeling (domain analysis), we need to gather
information from a number of sources.

• Sources of Domain Knowledge:

– High-level problem statements;
– Overall / Expert Vision of the Enterprise documented somewhere…
– All about the organization
– Any model or document that describes the problem space and the
desires and needs of the stakeholders
• Quarterly reports
• Interviews
• Questionnaires
• Personal Research
• Web pages with services offered or their philosophy, etc…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019

 Terms

• Business user – customers, vendors, partners – represented

by ‘business actors’
• Business processes –
– represented by business use cases;
• Business workers –roles played by different workers of the
business
• Business Entities: ‘Things’ organizations manage/produce.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019

 So, how do you model the
business?

By Dr. Samuel Asferaw OOSAD DBU 2018/2019

 So, how do you model the business?
Business Modeling Scenarios
• Scenario 1 – Organization Chart
– Build a simple organization chart of business and
its processes to get a good understanding of the
application you are building.
– Where does the application fit? To which
organizations or part of organizations might it
impact?
• Emphasis is on ‘the organization.’
– (This is done as part of the software engineering
process - perhaps part of the inception phase)
By Dr. Samuel Asferaw OOSAD DBU 2018/2019
 So, how do you model the business?
Business Modeling Scenarios
• Scenario 2 – Domain Modeling
– 1. Business Use Case Model
– 2. Business Object Model

– Domain Modeling is typically part of the software

engineering project and is performed during inception
and elaboration phases – but is definitely started in
inception/start/beginning and refined in elaboration.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019

 So, how do you model the business?...

1. Business Use Case Model

– Simple in structure .
– Shows relationship between business use cases – in
general and business users (business actors).
• A few small business use case diagrams are shown.
– Contains business actors (roles external to the business
such as customers, existing systems, devices, triggers, etc.)
and
– Contains business use cases (business processes)
(Business Use Case Diagrams plus specifications)
– Each use cases and actors who interact with each
business use case are identified .
By Dr. Samuel Asferaw OOSAD DBU 2018/2019
 So, how do you model the business?...

2. Business Object Model

– Much more detailed than the business use case model
– Includes the business use case realizations
– Includes interacting roles and entities involved.
– These are at higher levels of abstraction than
application use cases will be.
– e.g. A class at business level represents a responsibility
in an organization.
– A class represents a business entity, such as Customer,
Book, Inventory Item, Salesperson, etc.
– Each business use case is realized with business actors
and business entities.
– Remember: this is all about the “organization!”
By Dr. Samuel Asferaw OOSAD DBU 2018/2019
 3. Requirements Gathering
/Requirements Engineering/

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 70

 What is requirement?

• A requirement is a statement about an

intended/planned product that specifies what
it should do or how it should perform.
• Goal: To make as
• specific,
• unambiguous, and
• clear as possible.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 71

 Why do we need Requirements?

• When 38 IT professionals in the UK were asked

about which project stages caused failure,
respondents mentioned “requirements
definition” more than any other phase.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 72

What requirements should be gathered?
• Functional: What the system should do.
• Non-Functional: what constraints there are on the system
development. (For example, a work processor runs on different
platforms)
• Data requirements: Capture the type, volatility, size/amount,
persistence, accuracy and the amounts of the required data.
• Environmental requirements: a) context of use b) Social
environment (eg. Collaboration and coordination) c) how good
is user support likely to be d) what technologies will it run on
• User Requirements: Capture the characteristics of the intended
user group.
• Usability Requirement: Usability goals associated measures
By Dr.for
SamuelaAsferaw
particular productOOSAD DBU 2018/2019 73
 Sources of Requirements Gathering

• Users
• Reports
• Forms
• Procedures and documents
• Etc

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 74

 Data Gathering Techniques

• Interviews
• Questionnaires
• Focus groups and workshops
• Naturalistic Observation
• Studying documentation

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 75

 Data Gathering Techniques …
• Interviews -- Five Basic Steps
– Selecting Interviewees
– Designing the Interview Guide
– Preparing for the Interview
– Conducting the Interview
– Post-Interview Follow-up
• Each of these steps is ripe with opportunities for
injecting bias. Is bias a bad thing? Why or why not?
Which step takes the longest?
• Interviews involve asking someone a set of questions.
Often interviews are face-to-face, but they do not have
to be.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 76
 Data Gathering Techniques…

Interviews …
• Selecting Interviewees
– Should be representative of all users
– Recall the effects of bias
– Types of samples
• Convenient
• Random sample
• Purposeful sample
• Stratified sample
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 77
 Data Gathering Techniques…
Interviews …
• Designing the Interview Guide
1. Overall Questioning Strategies
• From General, narrowing to specific topic (preferred)
– E.g. Tell me about DBU, then Courses, then Course Information,
then enrollment numbers
• From Specific topic, moving to General
– E.g. Enrollment numbers on Course Info page to DBU in general
2. Types of Interview Questions
• Open-Ended
– No pre-specified answers
• Close-Ended
– Respondent is asked to choose from a set of specified responses

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 78

 Data Gathering Techniques…

Interviews …
• Preparing for the Interview
– Confirm place/time
– Review areas to be covered
– Encourage interviewee to bring reference materials

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 79

 Data Gathering Techniques…

Interviews …
• Conducting the Interview
– Gather facts, opinions and speculations
– Avoid bias when phrasing questions, e.g. phrasing
in ways that imply a wrong or right answer
– Never take sides on an issue
– Tape record with individual and organizational
permission

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 80

 Data Gathering Techniques…

Interviews …
• Conducting the Interview
– Assume tape recording will not work, which means you
must simultaneously
• Follow the interview guide, and
• Listen very carefully to what is being said, and
• Observe body language and emotions, and
• Separate facts from opinions, and
• Take notes, and
• Plan the next question/flow of the interview
• THIS IS VERY DIFFICULT TO DO CORRECTLY AND MUST
BE PRACTICED.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 81

 Data Gathering Techniques…

Interviews …
• Conducting the Interview--practical tips
– Don’t worry, be happy
– Pay attention
– Summarize key points
– Be succinct and honest
– Give interviewee time to ask questions
– Be sure to thank the interviewee
– End on time
– And, don’t ask unnecessary questions!
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 82
 Data Gathering Techniques…

• Post Interview
– Consider asking for more time if necessary
– Confirm major points identified with interviewee

– Look for Gaps and New Questions

– Type up notes within 24 hours (preferably
immediately after the interview is over.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 83

 Generic Interview Template

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 84

 Generic Interview Template…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 85

 Generic Interview Template…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 86

 Generic Interview Template…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 87

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 88

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 89

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 90

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 91

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 92

 Generic Interview Template (Cont’d)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 93

 Tips for a Successful Interview
1. Prepare an appropriate context-free interview,
and write it down briefly in a notebook for
reference during the interview.
2. Review the questions just prior to the interview.
3. Before the interview, research the background of
the stakeholder and the company to be
interviewed.
4. Don't bore the interviewee with questions you
could have answered in advance. On the other
hand, it wouldn't hurt to briefly verify the
answers with the interviewee.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 94
 Data Gathering Techniques …

• Questionnaires: Series of questions designed

to elicit specific information.
• The questions may require different kinds of
answers:
• some require a simple Yes/No, others may
require to choose from a set of pre-supplied
answers.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 95

 Data-gathering techniques…

• Focus groups and workshops: Interviews tend to be

one on one, and elicit only one person’s perspective.
It can be very helpful to get a group of stakeholders
together to discuss issues and requirements.

• Naturalistic Observation: It can be very difficult for

humans to explain what they do or to even describe
accurately how they achieve a task.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 96

 Data-gathering Techniques …

• Naturalistic Observation:
– Spend time with stakeholders in their day-to-day tasks,
observing work as it happens
– Gain insights into stakeholders’ tasks
– Good for understanding the nature and
context of the tasks
– But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 97

 Data-gathering Techniques …
Document/Procedure Analysis
– Procedures and rules are often written down in a
manual and these are a good source of data about the
steps involved in an activity and any regulations
governing a task.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 98

 Data-gathering Techniques …

Document/Procedure Analysis …
• Great starting point
– Gets analyst quickly up to speed with user jargon
– Can create preliminary models, e.g. DFDs or ERDs
• Types of information to be discovered:
– Problems with existing system
– Opportunity to meet new need
– Organizational direction
– Names of key individuals
– Values of organization
– Special information processing circumstances
– Reasons for current system design
– Rules for processing data
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 99
 Data-gathering Techniques …
Document/Procedure Analysis …
• Four types of useful documents
– Written work procedures
• Describes how a job is performed
• Includes data and information used and created in the process of
performing the job or task
– Business form
• Explicitly indicate data flow in or out of a system
– Report
• Enables the analyst to work backwards from the report to the data
that generated it
– Description of current information system

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 100

 Summary
• There are many techniques for gathering information about functional requirements

• Use a combination of data gathering techniques

For example: use observation to understand the context, interviews to target

specific user groups, questionnaires to reach a wider population, and focus groups

to build a consensus view

• To minimize bias it is a good idea to use more than one technique

– Consider the pros and cons of each

• Theoretically you should gather information until saturation, i.e. you learn nothing

new

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 101

 Requirements Specification and
Documentation
• Data interpretation and analysis
• Task descriptions
• Task analysis
• Requirements management
• Requirements Specification

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 102

 Data Interpretation and Analysis

• What: structure and record description of

requirement
• When: Start soon after data gathering session
– because experience will be fresh in mind

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 103

 Data Interpretation and Analysis…
• Main Requirement analysis models in object-
oriented systems
– Use cases diagrams:
consists of actors and use cases,
– Class diagrams
– More…
• How to develop those diagrams?
UML tools( useful in practice)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 104

 Task Analysis

• Task analysis is used mainly to investigate an

existing situation

• Many techniques, the most popular is

Hierarchical Task Analysis (HTA)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 105

 Hierarchical Task Analysis

• Idea is simple!
Involves breaking a task down into subtasks,
then sub-sub-tasks and so on. These are
grouped as plans which specify how the tasks
might be performed in practice

• Start with a user goal which is examined and

the main tasks for achieving it are identified

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 106

 Example of Hierarchical Task Analysis
0.In order to borrow a book from the library
1. go to the library
2. find the required book
2.1 access library catalogue
2.2 access the search screen
2.3 enter search criteria
2.4 identify required book
2.5 note location
3. go to correct shelf and retrieve book
4. take book to checkout counter

Note: start with a user goal

Step1, 3, 4 have no subtasks, but
Step 2 has subtasks

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 107

 Task Descriptions

• Scenarios
– An informal narrative story of users.
– Natural way to explain.
• Use cases
– show interaction with a system
– show detailed understanding of the interaction

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 108

 Scenarios
• Scenario
– is a tool used during requirements analysis to
walk through a specific interaction with a
proposed system.
– Usually the first step in establishing requirement
– an informal narrative story of users
– Describe
• what users are doing or
• How to achieve something
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 109
 Use Cases
• Use Cases
– a special kind of scenario that breaks down
system requirements into user functions
– Use Case is a sequence of events performed
by a user
– Interaction between user and a system
– Use to Capture Requirements

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 110

 Use cases…
How to avoid many words in the requirement
description ?

• Try graphical description. For example,

Actors----------------------Use Cases

Administrator --------- Arrange a Meeting

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 111

 Capture Requirements: Use Cases …

• The Use Case model is at the conceptual center of the entire approach
because it drives everything else that follows.

– Should follow the existence of a good, solid domain model and

identification of features the application is to accommodate.

– Use Case development drives Analysis (preliminary design)

– Drives Design Modeling – refine analysis model into a detailed design

model using objects identified in creating the analysis model.

– Drives Testing!

– Requirements Tracing – involves tracing features to specific interactions

via use cases.

• Use Cases drive entire development effort.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 112/12
 Use Cases …
• Use Cases are sequences of actions that an actor (usually a
person’s role, but certainly can be an external entity like another
external system or a device) performs with an expectation of
achieving a particular result; gets value.
• Always use present tense very in active voice. VERB…OBJECT in
naming a Use-Case: Maintain User Status,
• Model Requirements:
– Use Case Diagrams
– Use Case Specifications
• Diagram is only a graphical model associating Use Cases with
actors.
• Capture Use Cases (that is, the interactions) via Use Case Narrative
(Use Case ‘Scripts’) (Use Case Specifications)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 113/12

 Role of Use Cases
• The Use Cases are clearly the major artifacts of Requirements
Gathering efforts.
• Use Cases – great for communications
– contain the essence of desired interactions.
– no jargon as found in DFDs, ERDs, etc.
• Particularly good for Functional and to a much lesser degree
(in some cases) non-functional requirements (performance,
extensibility, maintainability, backup, recovery, security,
persistency, distribution, etc.) But these latter requirements
are normally documented in a Supplementary Specification
Document…
• Good for ensuring requirements traceability – because they
are used for design, testing, construction, delivery, and ...
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 114/12
 Role of Use Cases…
• When used to drive the lifecycle, they assure
stakeholders that all use cases are being
addressed in the development effort.
• Use cases discourage premature design. If the
use cases narrative has several steps before
responding to the user, this is a tip off that we
are undertaking too much designing…STOP!
• Remember: these are still the WHATS of the
application!
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 115/12
Use Case Diagrams and Specification in UML

• A diagram is the graphical representation of a set of

elements, usually rendered as a connected graph of
vertices:
• (things) and arcs (relationships).
• Each diagram is supported by technical documentation
that specifies in more detail the model represented by the
diagram.
•A diagram without documentation is of little value.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 116

 Actor and Use Case Diagram

• An actor is a user of a system in a

particular role.
BookBorrower
An actor can be human or an external
system.

Borrow book • A use case is a task that an actor

needs to perform with the help of the
system.

Use cases make more precise the concept of viewpoint analysis.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 117

 Use Cases and Actors
• A scenario is an instance of a use case
• Actor is role, not an individual
(e.g., librarian can have many roles)
• Actor must be a "beneficiary" of the use case
(e.g., not librarian who processes book when
borrowed)
In UML, the system boundary is the set of use cases.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 118

 Examples

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 119

 Example 1

Scenario for shared calendar

• In an informal interview, one potential user answered the question
” How to arrange a meeting
among several people
in the shared-calendar system ?”

• A simple scenario for this system:

User :
– types in all the names of the meeting participants
– length of the meeting
– when is the meeting
– where is the meeting.
System:
– checks against the individuals’ calendars and the central departmental
calendar
– More…
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 120
 Use case for shared calendar
A sequence of events to arrange a meeting Use Case:
• 1. The user chooses the option to arrange a meeting.
• 2. The system prompts user for the names of attendees.
• 3. The user types in a list of names.
• 4. The system checks that the list is valid.
• 5. The system prompts the user for meeting constraints.
• More steps…
Note: Number indicates the steps,
shows how user and system will interact.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 121

 Use case diagram example
• Use case diagram for the shared calendar system
• 3 use cases and 2 actors (Using the UML tool)
 Example 2

The requirements are being developed for a system that

will enable university students to take quizzes online from
their own rooms using a Web browser.
Create a scenario for a typical student.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 123

 Scenario: a Typical Student
Individual: Abebe Alemu (AA), MSc student at DBU, major in
Information Systems, Dorm location Block 001.
Equipment: Dell laptop attached to DBU dormitory network. Firefox
2.0 browser and Sidecar authentication system installed.
Scenario:
1. AA powers up computer and authenticates using Sidecar.
2. AA starts browser and types URL of Quiz system.
3. Quiz system displays list of options.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 124

 Scenario (continued)
4. AA selects IS 7100 Quiz 1.
5. A list of questions is displayed, each marked to indicate whether
completed or not.
6. AA selects a question and specifies whether he will submit a
new answer or edit a previous answer.
7. For the first question, he is submitting a new answer. He has a
choice whether to type the solution into the browser or to attach
a separate file. He decides to attach a file.
8. For the second question, he is editing a previous answer. He
chooses to delete a solution previously typed into the browser,
and to replace it with an attached file.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 125

 Scenario (continued)
9. AA has now completed the quiz. He selects an option that
submits the quiz to the grading system.
10. AA now wishes to change a solution. The system does not
permit changes once the solution has been submitted.
11. AA logs off.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 126

 Modeling Scenarios as Use Cases

A scenario is useful in discussing a proposed

system with a client, but needs to be generalized
as part of the requirements modeling.
A use case provides such a model.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 127

 Specification of Use Case
Use Case Name: TakeQuiz
Actor(s): QuizTaker
Flow of events:
1. QuizTaker connects to the Quiz server.
2. Quiz server checks whether student is already authenticated and
transfer to Sidecar for authentication if necessary.
3. QuizTaker selects a quiz from a list of options.
4. QuizTaker repeatedly selects a question and either types in a
solution, attaches a file with a solution, edits a solution or
attaches a replacement file.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 128

 Specification of Use Case (continued)
Flow of events (continued):
5. QuizTaker either submits completed quiz or saves current state.
6. If a completed quiz is submitted, Quiz server checks that all
questions have been attempted and either sends
acknowledgement to QuizTaker, or saves current state and
notifies QuizTaker of incomplete submission.
7. QuizTaker logs out.
Entry conditions:
1. QuizTaker must have DBU NetID.
2. Computing requirements: DBUNet supported browser and
Sidecar
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 129
 Use Case Diagram for Quiz System

TakeQuiz

QuizTaker
CheckGrades

RequestRegrade

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 130

 Use Cases for Quiz System…

SetQuiz

Instructor
Grade

Note that an actor is a role. Regrade

For example: An individual can be a
QuizTaker on one occasion and an
Instructor at a different time.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 131
 Relationships Between Use Cases:
<<includes>>

TakeQuiz <<includes>>

Authenticate
QuizTaker
CheckGrades <<includes>>

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 132

 Relationships Between Use Cases:
<<extends>>

<<extends>>
ConnectionFails
QuizTaker TakeQuiz

<<include>> is used for events that are in the flow of events

of the source use case.
<<extends>> is used for exceptional conditions, especially
those that can occur at any time.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 133

 Example 3: Detailed Process Use Cases

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 134

 Use Case Documentation: General

Characteristics of documentation:
accurate and kept current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
Documentation is expensive --> Quality not volume
Scenarios are useful to validate use cases and the design
of a system.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 135

 Documentation of Requirements
Specification: Purpose
1. Document that describes the requirements to the
stakeholders in a precise manner
• Expressed in the terms that the stakeholders understand
• As precise and specific as possible
• Comprehensible from many viewpoints
• Reviewed by stakeholders so that they understand
implications
• Must be clear about assumptions (things left out)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 136

 Requirements Specification: Purpose

2. It describes the requirements to the implementers

• As precise and specific as possible
• Expressed in terms that they understand
• Comprehensible to new team members

3. It records the requirements for the future

• An essential part of system evolution

4. It may be a contractual document

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 137
 Requirements Specification: Details
Requirements must be specific
Examples -- university admissions system
Requests for information received by email must be answered
within one business day.
An admissions officer who is talking to an applicant by
telephone must be able to retrieve the applicant's records
within 10 seconds.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 138

 Requirements Specification: Process
The client must understand the requirements specification.
• Do not assume that anybody has read a document.
• Do not assume that anybody understands a document.
Go through the requirements specification with the
client, line by line.
It is usual for the client and developer to sign the requirements
document when it is agreed.
[Compare with the plans to build a house. This is the
specification of the system that you are about to build.]

* By Dr. Samuel Asferaw OOSAD DBU 2018/2019 139

 How to document requirement?
• Requirement of description documents
– Natural language and graphical
– Widely accepted, consistent format

• Use tools to help

– Software<IBM Rational RequisitePro>
automating effective tool, template

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 140

 Requirements Analysis v. System Design
Dilemma.
• Requirements analysis should make minimal assumptions about
the system design.
• But the requirements definition must be consistent with
computing technology and the resources available.
In practice, analysis and design are interwoven. However:
1. Do not allow the requirements analysis to prejudge the system
design.
2. Do not allow assumptions about the design to influence the
requirements analysis.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 141

 Requirements Management
• What is it?
– a systematic approach to eliciting, organizing, and
documenting the requirements of the system,
– a process that establishes and maintains changing
requirements.
– Important and helpful for real projects
• Common problems
– No.1: Can’t track change
– No.2: Difficult to write
– More…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 142

 How to Manage changing requirements
• Single channel of change control/Change Control Board (CCB).

• Keep track
history of
requirements
• Maintain
version control
• More…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 143

 4. OO Basic Concepts

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 144

 OO Basic Concepts
• Encapsulation – grouping of related ideas into
one unit which we can refer to by a single
name
– Eg. procedures, functions, packages
• In OO, object is the unit; encapsulates state
and provides interface to access and modify

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 145

 OO Basic Concepts...
• Information hiding – use encapsulation to
restrict external visibility
• OO encapsulates the data, provides limited
access, visibility

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 146

 OO Basic Concepts…
• State retention – functions, procedures do not
retain state; an object is aware of its past and
maintains state
• Identity – each object can be identified and
treated as a distinct entity
• Behavior – state and services together define
the behavior of an object, or how an object
responds

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 147

 OO Basic Concepts..
• Messages – through which a sender object
conveys to a target object a request
• For requesting, O1
– must have – a handle for O2
• name of the operation
• information on operations that O2 requires
• General format O2.method(args)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 148

 OO Basic Concepts..
• Classes – a class is a stencil from which objects are
created; defines the structure and services.
– A class has
• An interface which defines which parts of an object can
be accessed from outside
• Body that implements the operations
• Instance variables to hold object state
• A class defines the attributes and operations
• Objects and classes are different; class is a type, object is
an instance
• State and identity is of objects
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 149
 OO Basic Concepts – Access
• Operations in a class can be
 Public: accessible from outside
 Private: accessible only from within the class
 Protected: accessible from within the class and
from within subclasses
 + is public, - is private, # is protected
• There are some constructor and destructor
operations
– Used to modify attributes
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 150
 OO Basic Concepts – Inheritance
• Inheritance is unique to OO
– not there in function-oriented languages/models
• Inheritance by class B from class A is the facility by
which B implicitly gets the attributes and operations
of A as part of itself
• Attributes and methods of A are reused by B
• When B inherits from A, B is the subclass or derived
class and A is the base class or superclass

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 151

 OO Basic Concepts – Inheritance…
• A subclass B generally has a derived part
(inherited from A) and an incremental part (is
new)
• Hence, B needs to define only the incremental
part
• Creates an “is-a” relationship
– objects of type B are also objects of type A

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 152

 OO Basic Concepts – Inheritance…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 153

 OO Basic Concepts – Inheritance…
• The inheritance relationship between classes forms a
class hierarchy
• In models, hierarchy should represent the natural
relationships present in the problem domain
• In a hierarchy, all the common features can be
accumulated in a superclass
• An existing class can be a specialization of another
existing general class – is also called generalization-
specialization relationships

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 154

 Hierarchy Class Example
Attributes
Subclass has access to these

Operations
Subclass has access to these

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 155

 OO Basic Concepts – Inheritance…
• Strict inheritance – a subclass takes all
features of parent class
• Only adds features to specialize it
• Non-strict: when some of the features have
been redefined
• Strict inheritance supports “is-a” cleanly and
has fewer side effects

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 156

 OO Basic Concepts – Inheritance…
• Single inheritance – a subclass inherits from
only one superclass
– Class hierarchy is a tree
• Multiple inheritance – a class inherits from
more than one class
– Can cause runtime conflicts
– Repeated inheritance - a class inherits from a class
but from two separate paths

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 157

 OO Basic Concepts – Inheritance and
Polymorphism
• Inheritance brings polymorphism, i.e. an object can be
of different types
• An object of type B is also an object of type A
• Hence an object has a static type and a dynamic type
– Implications on type checking
– Also brings dynamic binding of operations which allows
writing of general code where operations do different things
depending on the type

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 158

 Module Level Concepts
• Basic modules are classes
• During design key activity is to specify the
classes in the system being built
• Correctness of design is fundamental
• But design should also be “good” – efficient,
modifiable, stable, …
• Can evaluate a design using coupling,
cohesion, and open-closed principle

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 159

 OO Basic Concepts – Coupling
• Coupling is an inter-module concept, captures
the strength of interconnection between
modules
• More tightly coupled the modules, the more
they depend on each other, more difficult to
modify one
• Low coupling is desirable for making systems
understandable and modifiable
• In OO, three types of coupling exists –
interaction, component, and inheritance

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 160

 OO Basic Concepts – Coupling…
• Interaction coupling occurs due to methods of
a class invoking methods of other classes
– Like calling of functions
– Worst form if methods directly access internal
parts of other methods
– Still bad if methods directly manipulate variables
of other classes
– Passing information through temporary variables
is also bad

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 161

 OO Basic Concepts – Coupling…
• Least interaction coupling if methods
communicate directly with parameters
– With least number of parameters
– With least amount of information being passed
– With only data being passed
• I.e. methods should pass the least amount of
data, with least number of parameters

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 162

 OO Basic Concepts – Coupling…
• Component coupling – when a class A has
variables of another class C
– A has instance variables of C
– A has some parameters of type C
– A has a method with a local variable of type C
• When A is coupled with C, it is coupled with all
subclasses of C as well
• Component coupling will generally imply the
presence of interaction coupling also

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 163

 OO Basic Concepts – Coupling…
• Inheritance coupling – two classes are
coupled if one is a subclass of other
• Worst form – when subclass modifies a
signature of a method or deletes a method

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 164

 OO Basic Concepts – Cohesion
• Cohesion is an intra-module concept
• Focuses on why elements are together
– Only elements tightly related should exist together in a
module
– This gives a module clear abstraction and makes it easier to
understand
• Higher cohesion leads to lower coupling – many
interacting elements are in the module
• Goal is to have higher cohesion in modules
• Three types of cohesion in OO – method, class, and
inheritance

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 165

 OO Basic Concepts – Cohesion…
• Method cohesion – why different code
elements are together in a method (like
cohesion in functional modules)
– Highest form is if each method implements a clearly
defined function with all elements contributing to
implementing this function
– Should be able to state what the module does by a
simple statement

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 166

 OO Basic Concepts – Cohesion…
• Class cohesion – why different attributes and
methods are together in a class
– A class should represent a single concept with all
elements contributing towards it
– Whenever multiple concepts encapsulated,
cohesion is not as high
– A symptom of multiple concepts – different groups
of methods accessing different subsets of
attributes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 167

 OO Basic Concepts – Cohesion…
• Inheritance cohesion – focuses on why
classes are together in a hierarchy
– Two reasons for subclassing
• generalization-specialization
• reuse
– Cohesion is higher if the hierarchy is for
providing generalization-specialization

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 168

 Open-closed Principle
• Principle: Classes should be open for extension
but closed for modification
– Behavior can be extended to accommodate new
requirements, but existing code is not modified
– I.e. allows addition of code, but not modification of
existing code
– Minimizes risk of having existing functionality stop
working due to changes – a very important
consideration while changing code
– Good for programmers as they like writing new
code

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 169

 Open-closed Principle…
• In OO this principle is satisfied by using
inheritance and polymorphism
• Inheritance allows creating a new class to
extend behavior without changing the original
class
• This can be used to support the open-closed
principle
• Consider example of a client object which
interacts with a printer object for printing

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 170

 Example

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 171

 Example…
• Client directly calls methods on Printer1
• If another printer is to be allowed
– A new class Printer2 will be created
– But the client will have to be changed if it wants to
use Printer 2
• Alternative approach
– Have Printer1 a subclass of a general Printer
– For modification, add another subclass Printer 2
– Client does not need to be changed
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 172
 Example…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 173

 Liskov’s Substitution Principle
• Principle: Program using object O1 of base
class C should remain unchanged if O1 is
replaced by an object of a subclass of C
• If hierarchies follow this principle, the open-
closed principle gets supported

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 174

 Unified Modeling Language (UML) and
Modeling
• UML is a graphical notation useful for OO
analysis and design
• Allows representing various aspects of the
system
• Various notations are used to build different
models for the system
• OOAD methodologies use UML to represent
the models they create

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 175

 Modeling
• Modeling is used in many disciplines –
architecture, aircraft building, …
• A model is a simplification of reality
• A good model includes those elements that
have broad effect and omits minor elements
• A model of a system is not the system!

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 176

 Why build models?
• Models help us visualize a system
• Help specify the system structure
• Gives us a template that can guide the
construction
• Document the decisions taken and their
rationale

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 177

 Modeling
• Every complex system requires multiple
models, representing different aspects
• These models are related but can be studied
in isolation
• Eg. Architecture view, structural view,
electrical view, plumbing view of a building
• Model can be structural, or behavioral

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 178

 Views in an UML
• Different views
– A use case view
– A design view
– A process view
– Implementation view
– Deployment view
• We will focus primarily on models for design
– class diagram, interaction diagram, etc.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 179

 5. Object Oriented
Analysis

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 180

 Object Oriented Analysis
• OO Analysis Overview
• Identify Entity – Domain Modeling
• Assigning Responsibilities

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 181

 OO Analysis Overview
• Understanding Analysis
• Analysis Versus Design
• Object Oriented Analysis
• Three ways to do Object Oriented Analysis

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 182

 Understanding Analysis
• In software engineering, analysis is the process of
converting the user requirements to system specification
– system means the software to be developed.
• System specification, also known as the logic structure, is
the developer’s view of the system.
• Function-oriented analysis – concentrating on the
decomposition of complex functions to simply ones.
• Object-oriented analysis – identifying objects and the
relationship between objects.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 183

 Understanding Analysis…
• The goal in Analysis is to understand the problem
– to begin to develop a visual model of what you are trying
to build, independent of implementation and technology
concerns.
• Analysis focuses on translating the functional
requirements into software concepts.
– The idea is to get a rough cut at the objects that
comprise our system, but focusing on behavior (and
therefore encapsulation).
– We then move very quickly, nearly seamlessly into
“design” and the other concerns.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 184

 Analysis Versus Design
• Analysis • Design
– Focus on – Focus on
understanding the understanding the
problem solution
– Idealized design – Operations(methods)
– Behavior/logic/ and Attributes
– System structure – Close to real code
– Functional – Object lifecycles
requirements – Non-functional
– A small model requirements
– A large model

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 185

 Object Oriented Analysis
• Identifying objects:
– Using concepts, CRC cards, stereotypes, etc.
• Organising the objects:
– classifying the objects identified, so similar objects can later be
defined in the same class.
• Identifying relationships between objects:
– this helps to determine inputs and outputs of an object.
• Defining operations of the objects:
– the way of processing data within an object.
• Defining objects internally:
– information held within the objects /attributes/.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 186

Three ways to do Object Oriented Analysis
• Conceptual model (Larman)
– Produce a “light” class diagram.
• CRC cards (Beck, Cunningham)
– Index cards and role playing.
• Analysis model with stereotypes (Jacobson)
– Boundaries, entities, control.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 187

 Identify Entity – Domain Modeling
• Visualizing Concepts
• Adding Associations
• Adding Attributes
• Modeling Generalization
• Refining the Domain Model

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 188

 VISUALIZING CONCEPTS
• Domain Models
• Conceptual Class Identification
• Domain Modeling Guidelines
• Modeling the Unreal world
• Specification of Conceptual Classes
• UML Notation v.s. Methodology

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 189

 Domain Models
• A domain model is a representation of real-world conceptual classes
– not a representation of software components.
– not a set of diagrams describing software classes,
– not software objects with responsibilities.
• A domain model is a visual representation of conceptual classes or
real-world objects in a domain of interest
– They have also been called conceptual models, domain object
models, and analysis object models.
• Using UML notation, a domain model is illustrated with a set
of class diagrams in which no operations/methods/ are
defined. It may show:
• domain objects or conceptual classes
• associations between conceptual classes
• attributes of conceptual classes
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 190
 Domain Models…
• Software problems can be complex;
– Decomposition (divide-and-conquer) is a common strategy to
deal with this complexity by division of the problem space into
comprehensible units.
– In structured analysis, the dimension of decomposition is by
processes or functions.
– However, in object-oriented analysis, the dimension of
decomposition is fundamentally by things or entities in the
domain.
• A central distinction between object-oriented and
structured analysis is: division by conceptual classes
(objects) rather than division by functions.
• A primary analysis task is to identify different concepts in
the problem domain and document the results in a
domain model
 Domain Models…
• The domain model illustrates conceptual classes or
vocabulary in the domain.
• Domain Models are not models of software components.
The following elements are not suitable in a domain
model:
– Software artifacts, such as a window or a database, unless the
domain being modeled is of software concepts, such as a model
of graphical user interfaces.
– Responsibilities or methods.
• Informally, a conceptual class is an idea, thing, or object.
 Domain Models…
• More formally, a conceptual class may be considered in
terms of its symbol, intension, and extension
– Symbol—words or images representing a conceptual class.
– Intension—the definition of a conceptual class.
– Extension—the set of examples to which the conceptual class
applies.

OOSAD DBU 2018/2019 193

 Example: Domain Model

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 194

 Conceptual Classes Identification
• A conceptual class is a real-world concept or thing; a conceptual or
essential perspective.
• A conceptual class is not an implementation class, such as a class
that can be implemented in an OO language such as Java or C++.
That comes much later(or in design phase).
• A useful guideline in identifying conceptual classes:
– It is better to over specify a domain model with lots of fine-grained
conceptual classes than to under specify it.
• Strategies to Identify Conceptual Classes.
– Use a conceptual class category list.
– Start finding conceptual classes with Noun Phrase Identification from the
requirements document
• At the noun or Noun Phrase filtering stage we are looking for
conceptual classes.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 195
Conceptual Class Category List Examples
Physical or tangible objects Register, Airplane
Specifications or descriptions of things ProductSpecification, FlightDescription
Places Store, Airport
Transactions Sale, Payment, Reservation
Transaction line items SalesLineItem
Roles of people Cashier, Pilot
Containers of other things Store, Bin, Airplane
Things in a container Item, Passenger
Other computer or electro-mechanical CreditPaymentAuthorizationSystem
systems external to the system AirTrafficControl
Organizations SalesDepartment, ObjectAirline
Events Sale, Payment, Meeting, Flight, Crash, Landing
Rules and policies RefundPolicy
CancellationPolicy
Catalogs ProductCatalog, PartsCatalog
Records of finance, work, contracts, legal Receipt, Ledger, EmploymentContract,
matters MaintenanceLog
Financial instruments and services LineOfCredit, Stock
Manuals, documents, reference papers, DailyPriceChangeList , RepairManual
books

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 196

 Domain Modeling Guidelines
• How to Make a Domain Model
– 1. List the candidate conceptual classes using the Conceptual
Class Category; Use a noun phrase identification techniques
related to the current requirements under consideration.
– 2. Draw them in a domain model.
– 3. Add the associations necessary to record relationships for
which there is a need to preserve some memory.
– 4. Add the attributes necessary to fulfill the information
requirements.
• On Naming and Modeling Things
– use the vocabulary of the domain when naming conceptual
classes and attributes.
• For example, if developing a model for a library, name the customer
a "Borrower“ —the terms used by the library staff.
– the domain model should exclude things not in the problem
domain under consideration.
 Domain Modeling Guidelines…
• A Common Mistake in Identifying Conceptual Classes
– Perhaps the most common mistake when creating a domain model is to
represent something as an attribute when it should have been a concept.
– A rule of thumb to help prevent this mistake is:
• If we do not think of some conceptual class X as a number or text in
the real world, X is probably a conceptual class, not an attribute.
• As an example, should store be an attribute of Sale, or a separate
conceptual class Store?
– In the real world, a store is not considered a number or text - the term
suggests a legal entity, an organization, and something occupies space.
Therefore, Store should be a concept.
• As another example, consider the domain of airline reservations.
Should destination be an attribute of Flight, or a separate conceptual
class Airport?
– In the real world, a destination airport is not considered a number or text—it
is a massive thing that occupies space. Therefore, Airport should be a concept.
 Modeling the Unreal World
• Some software systems are for domains that find very little
analogy in natural or business domains;
– software for telecommunications is an example.
• It is still possible to create a domain model in these
domains, but it requires a high degree of abstraction and
stepping back from familiar designs.
• For example, here are some candidate conceptual classes
related to a telecommunication switch:
– Message, Connection, Port, Dialog, Route, Protocol.
 Specification or Description Conceptual Classes
• Add a specification or description conceptual class (for
example, ProductSpecification) when:
– There needs to be a description about an item or service,
independent of the current existence of any examples of those
items or services.
– Deleting instances of things they describe (for example, Item)
results in a loss of information that needs to be maintained, due
to the incorrect association of information with the deleted
thing.
– It reduces redundant or duplicated information.

OOSAD DBU 2018/2019 200

Example: Specification or Description Conceptual Classes

OOSAD DBU 2018/2019 201

 UML Notation v.s. Methodology
• The UML simply describes raw diagram types, such as class diagrams
and sequence diagrams. It does not superimpose a method or
modeling perspective on these.
• Rather, a process (such as the UP) applies raw UML in the context of
methodologist-defined models.
• Three perspectives and types of models:
– Conceptual perspective
• the diagrams are interpreted as describing things in the real world or domain
of interest.
– Specification perspective
• the diagrams are interpreted as describing software abstractions or
• components with specifications and interfaces, but no commitment to a
particular implementation (for example, not specifically a class in C# or Java).
– Implementation perspective
• the diagrams are interpreted as describing software implementations in a
particular technology and language (such as Java).

OOSAD DBU 2018/2019 202

 Adding Association
• Associations
• The UML Association Notation
• Finding Associations
• Association Guidelines
• Naming Associations
• Multiple Associations Between Two Types
• Associations and Implementation
• Example

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 203

 Associations
• An association is a relationship between types (or more
specifically, instances of those types) that indicates some
meaningful and interesting connection
• In the UML associations are defined as "the semantic
relationship between two or more classifiers that involve
connections among their instances.“
 The UML Association Notation
• An association is represented as a line between classes with an
association name.
– The association is inherently bidirectional, meaning that from instances of
either class, logical traversal to the other is possible
– This traversal is purely abstract; it is not a statement about connections
between software entities
– The ends of an association may contain a multiplicity expression indicating
the numerical relationship between instances of the classes
– An optional "reading direction arrow" indicates the direction to read the
association name; it does not indicate direction of visibility or navigation
 Finding Associations
• Start the addition of
associations by using the
Common Associations List
– It contains common
categories that are usually
worth considering.
• Here are some high-
priority association
categories that are
invariably useful to include
in a domain model:
– A is a physical or logical part
of B.
– A is physically or logically
contained in/on B.
– A is recorded in B.

OOSAD DBU 2018/2019 206

 Association Guidelines
• Focus on those associations for which knowledge of the
relationship needs to be preserved for some duration
("need-to-know" associations).
• It is more important to identify conceptual classes than to
identify associations.
• Too many associations tend to confuse a domain model
rather than illuminate it. Their discovery can be time-
consuming, with marginal benefit.
• Avoid showing redundant or derivable associations.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 207

 Naming Associations
• Name an association based on a TypeName-
VerbPhrase-TypeName format where the verb
phrase creates a sequence that is readable and
meaningful in the model context.
Multiple Associations Between Two Types
• Two types may have multiple associations between
them;
– this is not uncommon.
 Associations and Implementation

• During domain modeling, an association is not a

statement about data flows, instance variables, or object
connections in a software solution;
• it is a statement that a relationship is meaningful in a
purely conceptual sense—in the real world

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 210

Example-Applying the Category of Associations
Checklist

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 211

 Adding Attributes
• Attributes VS. Associations
• No Attributes as Foreign Keys

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 212

 Attributes VS. Associations
• The attributes in a domain model should preferably be
simple attributes or data types.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 213

 Design Creep: No Attributes as Foreign Keys
• Attributes should not be used to relate conceptual classes in
the domain model.
• The most common violation of this principle is to add a kind
of foreign key attribute, as is typically done in relational
database designs, in order to associate two types.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 214

 Modeling Generalization

• Noun Phrase Identification from the Use Cases

• Generalization
• Defining Conceptual Superclasses and Subclasses
• Abstract Conceptual Classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 215

Noun Phrase Identification from the Use Cases
Use Case UC1: Process Sale
b. Paying by credit:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment
Authorization Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. System receives payment approval and signals approval to Cashier.
3a. System receives payment denial:
1. System signals denial to Cashier.
2. Cashier asks Customer for alternate payment.
4. System records the credit payment, which includes the payment approval.
5. System presents credit payment signature input mechanism.
6. Cashier asks Customer for a credit payment signature. Customer enters
signature.

OOSAD DBU 2018/2019 216

 Noun Phrase Identification from the Use Cases…

Use Case UC1: Process Sale

c. Paying by check:
1. The Customer writes a check, and gives it and their driver's license to
the Cashier.
2. Cashier writes the driver's license number on the check, enters it,
and requests check payment authorization.
3. Generates a check payment request and sends it to an external Check
Authorization Service.
4. Receives a check payment approval and signals approval to Cashier.
5. System records the check payment, which includes the payment
approval.

OOSAD DBU 2018/2019 217

Generalization-Specialization Class Hierarchy

• The concepts CashPayment, CreditPayment, and Check

Payment are all very similar.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 218

 Conceptual Subclass Definition

 All Payment subclasses must conform to having an

amount and paying for a Sale.
100% Rule
The subclass must conform to 100% of the superclass's:
• attributes
• associations
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 219
 Conceptual Subclass Set Conformance

 CreditPayment should be a member of the set of

Payments.
 CheckPayment is a kind of Payment.

 Is-a Rule
All the members of a subclass set must be members of their superclass set.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 220

 What Is a Correct Conceptual Subclass?

 Create a conceptual subclass of a superclass

when:
 The subclass has additional attributes of interest.
The subclass has additional associations of interest.
The subclass concept is operated on, handled, reacted to, or
manipulated differently than the superclass or other subclasses,
in ways that are of interest.
The subclass concept represents an animate thing (for example,
animal, robot) that behaves differently than the superclass or
other subclasses, in ways that are of interest.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 221
 Example subclass partitions

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 222

 Abstract Conceptual Classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 223

 Abstract Class Notation in the UML

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 224

 Refining the Domain Model
• Association Classes
• Aggregation and Composition
• Roles as Concepts vs. Roles in Associations
• Qualified Associations
• Reflexive Associations

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 225

 Association Classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 226

 Association Classes…

 Clues that an association class might be useful in a

domain model:
An attribute is related to an association.
Instances of the association class have a life-time dependency on the
association.
There is a many-to-many association between two concepts, and information
associated with the association itself...
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 227
 Aggregation
• A special form of association that models a whole-
part relationship between an aggregate (the whole)
and its parts

Whole Part

Student Schedule

Aggregation

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 228

 Composition
• A form of aggregation with strong ownership and
coincident lifetimes
– The parts cannot survive without the whole/aggregate

Whole Part

Student Schedule

Composition

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 229

 Roles as Concepts vs. Roles in Associations
 In a domain model, a real-world role—especially a human role—may be modeled
in a number of ways, such as a discrete concept (roles as concepts), or expressed as
a role in an association (roles in associations).

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 230

 Qualified Associations
 A qualifier may be used in an association; it distinguishes
the set of objects at the far end of the association based on
the qualifier value.
 An association with a qualifier is a qualified association.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 231

 Reflexive Associations
 A concept may have an association to itself; this is known
as a reflexive association

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 232

 Responsibilities
• Responsibilities
• Responsibility-Driven Design
• CRC Cards

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 233

 Responsibilities
• The UML defines a responsibility as "a contract or
obligation of a classifier"
• A knowing or doing service or group of services
provided by an element (such as a class or
subsystem);
• A responsibility embodies one or more of the
purposes or obligations of an element.
• A popular way of thinking about the design of
software objects and also larger-scale components is
in terms of responsibilities, roles, and
collaborations.
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 234
 Responsibilities
• Doing responsibilities of an object include:
– doing something itself, such as creating an object or doing a
calculation
– initiating action in other objects
– controlling and coordinating activities in other objects
• Knowing responsibilities of an object include:
– knowing about private encapsulated data
– knowing about related objects
– knowing about things it can derive or calculate
• For example
– "a Sale is responsible for creating SalesLineItems" (a doing),
– "a Sale is responsible for knowing its total" (a knowing).
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 235
 Responsibility-Driven Design (RDD)
• A general metaphor for thinking about OO software
design
• RDD leads to viewing an OO analysis & design as a
community of collaborating responsible objects.
• RDD also includes the idea of collaboration.
– Responsibilities are implemented by means of methods that
either act alone or collaborate with other methods and
objects.
• In RDD, Responsibilities are related to the obligations
or behavior of an object in terms of its role.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 236

 CRC cards
• CRC stands for Class-Responsibility-Collaborator. They look
like: Name Responsibilities
Collaborators

– one per class, which shows its responsibilities and with which
other class(es) it must collaborate in order to fulfill each
responsibility.
– Write a brief description of the class on the back of the card.
• CRC cards are useful in detecting responsibilities of objects
(developed by Kent Beck and Ward Cunningham).

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 237

 CRC Cards - Example
• In this example, class Foo must collaborate with
(send messages to) classes X & Y in order to fulfill its
responsibility to be able to “do something.”

CLASS NAME Foo RESPONSIBILITIES

Do something
COLLABORATIONS
Classes X & Y

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 238

 Summary: Finding Entity Classes
• Use use-case flow of events as input
• Key abstractions of the use case
• Traditional, filtering nouns approach
– Underline noun clauses in the use-case flow of
events
– Remove redundant candidates
– Remove vague candidates
– Remove actors (out of scope)
– Remove implementation constructs
– Remove attributes (save for later)
– Remove operations

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 239

6. Object Oriented
Design
 Object Orientation
• Traditional procedural systems separate data
and procedures, and model these separately
• Object orientation –views data and functions
together; data abstraction is the basis
• The purpose of OO design is to define the
classes in the system to be built and their
relationships

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 241

 OOA and OOD
• In Object Oriented Analysis (OOA) we model the
problem, while in Object Oriented Deisgn (OOD) we
model the solution

• Often OOA structures are subsumed in the solution

domain structures

• The line between OOA and OOD is not fixed

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 242

 OOA and OOD…

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 243

 Object Oriented Design

• Covered concepts
– Classes and objects
– Encapsulation
– State, behavior, identity
– Relationships among objects
– Inheritance and polymorphism
• Covered constraints
– Coupling
– Cohesion
• Covered tools
– Class diagrams
– Sequence diagrams

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 244

 Class Diagrams
• Classes are the basic building blocks of an OO
system as classes are the implementation
units also
• Class diagram is the central piece in an OO
design. It specifies
– Classes in the system
– Association between classes
– Subtype, supertype relationship

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 245

 Class Diagram…
• Class itself represented as a box with name,
attributes, and methods
• There are conventions for naming
• If a class is an interface, this can be specified
by <<interface>> stereotype
• Properties of attributes/methods can be
specified by tags between { }

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 246

 Design Class – example

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 247

 Generalization-Specialization

• This relationship leads to class hierarchy

• Can be captured in a class diagram
– Arrows coming from the subclass to the superclass
with head touching super
– Allows multiple subclasses
– If specialization is done on the basis of some
discriminator, arrow can be labeled

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 248

 Example – class hierarchy

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 249

 Association/aggregation
• Classes have other relationships
• Association: when objects of a class need
services from other objects
– Shown by a line joining classes
– Multiplicity can be represented
• Aggregation: when an object is composed of
other objects
– Captures part-whole relationship
– Shown with a diamond connecting classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 250

 Interaction Diagrams
• Class diagrams represent static structure of the
system (classes and their relationships)
• Do not model the behavior of system
• Behavioral view
– shows how objects interact for performing actions
(typically a use case)
• Interaction is between objects, not classes
• Interaction diagram in two styles
– Collaboration diagram
– Sequence diagram
• Two are equivalent in power
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 251
 Sequence Diagram
• Objects participating in an interaction are
shown at the top
• For each object a vertical bar represents its
lifeline
• Message from an object to another,
represented as a labeled arrow
• If message sent under some condition, it can be
specified in bracket
• Time increases downwards, ordering of events
is captured

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 252

 Example – Sequence Diagram
Objects participating in an interaction
Time

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 253

 Collaboration Diagram
• Also shows how objects interact
• Instead of timeline, this diagram looks more like
a state diagram
• Ordering of messages captured by numbering
them
• Is equivalent to sequence diagram in modeling
power

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 254

Example – Collaboration Diagram

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 255

 Other Diagrams
• Class diagram and interaction diagrams most
commonly used during design
• There are other diagrams used to build
different types of models
– State Diagrams
– Activity Diagrams

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 256

 State Diagrams
• Dynamic model to represent behavior of an
individual object or a system
• Shows the states of an object and transitions
between them
• Helps understand the object – focus only on
the important logical states
• State diagrams can be very useful for
automated and systematic testing

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 257

 Activity Diagrams
• Another method for modeling the dynamic
behavior
• Describes the sequence of activities, and
parallel behavior in a system
– Activity represented by ovals, dependence shown
by inputs/outputs
• Variant of a state diagram – captures the
state of the system and transitions

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 258

 OO Design Using UML
• Many OOAD methodologies have been
proposed
• They provide some guidelines on the steps to
be performed
• Basic goal is to identify classes, understand
their behavior, and relationships
• Different UML models are used for this
• Often UML is used, methodologies are not
followed strictly

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 259

 OO Design Using UML
• Basic steps
– Identify classes, attributes, and operations from use
cases
– Define relationships between classes
– Make dynamic models for key use cases and use
them to refine class diagrams
– Make a functional model and use it to refine the
classes
– Optimize and package
• Class diagrams play the central role; class
definition gets refined as we proceed
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 260
 Example 1: Restaurant Scenario
• Customer read the menu
• Customer places the order
• Order is sent to the kitchen for preparation
• Ordered items are served
• Customer requests for a bill for the order
• Bill is prepared for this order
• Customer is given the bill
• Customer pays the bill

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 261

 Restaurant example: Initial classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 262

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 263
 Restaurant example: a sequence diagram

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 264

 Example 2: Word Count Problem
• System prompts for the file name; user enters
the file name
• System checks for existence of file
• System reads the words from the file
• Systems prints the count

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 265

 Example 2: Word Count Problem…
File

name
History
getword() Counter
isEof()
addWord()
count
exists()
increment()
display()

Word

string
setstring()
getstring()

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 266

 Example 2: Word Count Problem
Collaboration Diagram

Check
Read Get
For
File words
Uniqueness

Increment
Add to
Count
History

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 267

 Summary
• OO is a newer paradigm, slowly replacing the
functional approach
• OO models both data and functions
• UML is a notation that is used often to model
systems in an OO manner
• UML provides various diagrams for modeling the
structure, dynamic behavior, etc.
• Through UML modeling, design for the system can be
developed

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 268

 Example 3 OO Design
PIMS/Personal Investment System/

• Help investors keep track of their investments

• Determine rate of return
– On individual investments
– On overall portfolio
• Determine net worth of portfolios

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 269

 Example 3 OO Design – PIMS…
• Investor can have many portfolios
• Portfolio can have many investments
• Investor can invest and withdraw any amount of money at any time
– Dates and amounts are tracked by PIMS
• Get current value of each investment from Web site
• Invest in instruments with fixed interest rates
– Alert to notify pending maturity dates
• Save information about the portfolio
• Edit entered data
• View any portfolio
– Summary
– Detailed
• Provide security
• Determine rate of return
– For each investment
– Overall for each portfolio
– Total investments
– Compute on monthly basis

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 270

 Example 3 OO Design – PIMS…
Basic Classes

Class Principle Responsibility

Investment Manages computations regarding total investment.
Portfolio Manages computations regarding a Portfolio.
Security Manages computations related to a security.
Transaction Manages computations and stores attributes related to a transaction.

GUI Manages the Graphical User Interface.

NetLoader Manages downloading current prices of shares from the Internet.
Current Value Manages current value of shares.
System
Alerts Manages alerts.
SecurityManager Manages user validation.
DataRepository Manages all file operations. It is an interface between the main modules
and the database (which in our case is done using file system.)

OOSAD DBU 2018/2019 271

 Example 3 OO Design – PIMS…
Inheritance Structure

Two kinds of securities Two kinds of transactions

Bank: interest bearing buy: exchange cash for security
Shares: trading/dividends sell: exchange security for cash

OOSAD DBU 2018/2019 272

Example 3 OO Design – PIMS…
Aggregation Structure

An investment consists of many portfolios

A portfolio can consist of many different

securities

Many transactions can act on a single

security

OOSAD DBU 2018/2019 273

 Example 3 OO Design – PIMS…
Class Diagram
Investment

1
m Transaction
m
Portfolio

1
m

Security Debit Credit

1

Bank Deposit Shares

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 274

 Example 3 OO Design – PIMS…
associations for action Create/Delete/Edit Transaction

OOSAD DBU 2018/2019 275

 Example 3 OO Design – PIMS…
Class diagram with classes and associations

OOSAD DBU 2018/2019 276

 Example 3 OO Design – PIMS…
Basic Actions
Actions

Create/Delete/Rename Portfolio/Security.

Create/Delete/Edit Transactions.

Calculate Net Worth of Investment/Portfolio/ Security.

Calculate Rate of Investment of a security.

Load Current Prices from the Internet.

Check/Set/Delete Alerts.

Validate User.

277
OOSAD DBU 2018/2019
 Example 3 OO Design – PIMS…
Sequence diagram for principle action Create Portfolio

OOSAD DBU 2018/2019 278

 Example 3 OO Design – PIMS…
Sequence diagram for principle action Delete Transaction

279
OOSAD DBU 2018/2019
 Example 3 OO Design – PIMS…
Sequence diagram for action Compute Net Worth of
Investment/Portfolio/Security

OOSAD DBU 2018/2019 280

 Example 3 OO Design – PIMS…
Sequence diagram for action Load current prices from the
Internet

OOSAD DBU 2018/2019 281

 Example 3 OO Design – PIMS…
Sequence diagram for action Set/Check/Delete Alerts

OOSAD DBU 2018/2019 282

 Example 3 OO Design – PIMS…
Sequence diagram for action Validate User

OOSAD DBU 2018/2019 283

7. UML: Unified Modeling
Language

OOSAD DBU 2018/2019 284

 UML: Unified Modeling Language
• Story:
– What UML is for
– Some of the main diagrams are and what you use
them for
• Class diagrams and class forms
• Use Case Diagrams
• Sequence (Event) Diagram
• State Diagrams
– An example

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 285

 UML: Unified Modeling Language
• Developed by the “Three Amigos”: Grady
Booch, Jim Rumbaugh, Ivar Jacobson
– Each had their own development methodology
– More or less emphasis on notation and process
• UML is a notation and a process
– Diagrams and notation from UML 1.3 Definition
(http://www.rational.com)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 286

 Diagrams
• Class diagrams: Represents static structure
• Use case diagrams: Sequence of actions a
system performs to yield an observable result
to an actor
• Sequence diagrams: Shows how groups of
objects interact in some behavior
• State diagrams: Describes behavior of system
by describing states of an object

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 287

 Class Diagrams
• Better name: “Static structure diagram”
– Doesn’t describe temporal aspects
– Doesn’t describe individual objects: Only the
overall structure of the system
• There are “object diagrams” where the boxes
represent instances
– But rarely used—other diagrams serve the role of
describing object interaction better
– When used, object diagrams describe static
structure, like a data structure
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 288
 Different Levels of Specifying Classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 289

 Notation in Class Boxes
• Abstract classes (and operations) in italics
• + is public, - is private, # is protected
• Can also specify stereotypes or compartments
– “constructors” or “query”
– “controller”

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 290

 Other variations in Class specifications

• Use of
templates,
interfaces, and
types
• Can even specify
body of methods

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 291

 Components of Class Diagrams
• Multiplicities
– How many of
each?
• Labels to indicate
how reference is
viewed
• Role and
Association
classes

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 292

 Navigability and Aggregations
• Navigability
– Who owns/contains/has who?
– Arrows not strictly required
• Aggregation: Open diamond
– “Part-of” relationship, but disagreement
• Composition:
closed diamond
– Part can only
belong to whole

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 293

 Qualifiers
• Serves to describe an instance variable that
partitions the relationship.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 294

 Use Case Diagrams

• Means of capturing requirements

• Document interactions between user(s) and
the system
– User (actor) is not part of the system itself
– But an actor can be another system
• An individual use case represents a task to be
done with support from the system (thus it is
a ‘coherent unit of functionality’)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 295

 Simple Use Case Diagram

Reserve book

Borrow book

Return book

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 296

 Use Case Diagram with Multiple
Actors

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 297

 Use Cases
• Are actually defined as text, including
descriptions of all of the normal and exception
behavior expected
• Do not reveal the structure of the system
• Collectively define the boundaries of the
system to be implemented
• Provide the basis for defining development
iterations

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 298

 Example Use Case Diagram
(Advanced Features)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 299

 Sequence (Event) Diagrams
• Shows individual objects and how they
interact
• Describes
– Lifelines of objects
– Who sends what messages when
– Can also describe sending messages to self ("self-
delegation")
– Can describe guards, notes, etc.

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 300

 Example Sequence Diagram

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 301

 State Diagrams
• Describe all the possible states a particular
object can get into, and the events that lead to
those changes
• Also called a "statechart"

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 302

 Example State Diagram

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 303

 Other Kinds of UML Diagrams
• Collaboration Diagrams
– An alternative to sequence diagrams for
describing the flow of messages between objects

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 304

 Other kinds of UML Diagrams

• Activity Diagrams
– Alternative to
statecharts

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 305

 Other kinds of UML Diagrams

• Implementation
Diagrams
– Down at the detail level
• What piece of code goes
where?
• How are they connected?

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 306

 UML in Real Practice

• You don't typically use all the diagrams

– You'll choose between them based on preference and
particular situation
• You typically use many diagrams
– A single use case may not capture all scenarios
– If you are going to use statecharts, there are probably lots
of objects with states
– Each sequence/collaboration diagram only shows one
interaction

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 307

 Example: Student Registration System

• Not going to do all the diagrams

– Not all types, not even all that completely specify
the system
• But this is an application you know, so the
examples may help make sense

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 308

 Student Registration Class Diagram

Student Transcript
1 1
transcript courseGrades
major * 1
Registrar gradeForCourse:
schedule Section takenCourse:
registrar courses
1
enrollInClass: course * 1 sectio
gradeInCourse: daysAndTime ns
getSectionsF
takenCourse: roster enrollInSection:
or:
* addStudent dropFromSection:
removeStudent * 1 * CourseGrade

11 *1 * course
Department 1 * grade
Course termEnrolled
1..3 * *
courses name
requiredCourses number
department
creditHours 0..3
prerequisites
By Dr. Samuel Asferaw OOSAD DBU 2018/2019 309
 Partial Use Case Diagram

Apply for
Admission

Enroll in
the University Admissions

Student Enroll in
a Course

Withdraw
from a Course

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 310

 States of a Student
Apply [ Must be accepted first ]
Enrolled

EnrollInClass ( Add a Transcript )

Withdraw Registered AddCourse

Graduate [ All courses must be completed ]

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 311

 Sequence Diagram: Registering for Course

aStudent theRegistrar aSection theTranscript

getSectionsFor:

return sections

enrollInSection:
takenCourse: prerequisite
takenCourse: prerequisite
state of prereq
have prereq
addStudent:

enrolled enrolled

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 312

 Process to Representations

• OOA
– CRC Cards (but they’re not officially UML)
– Use Cases
• OOD
– Just about all of the rest
– But variations—some detail is later
• OOP
– Can actually go UML->code with some tools!

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 313

 UML Modeling Tools

• Rational Rose (www.rational.com) by IBM

• UML Studio 7.1 ( http://www.pragsoft.com/) by Pragsoft
Corporation
Capable of handling very large models (tens of thousands of
classes). Educational License US$ 125.00; Freeware version.
• Microsoft Visio
• Dia: open source, much like visio.
(http://www.gnome.org/projects/dia/)
• ArgoUML (Open Source; written in java ) (
http://www.apple.com/downloads/macosx/development_tools/
argouml.html
)
• Others (
http://www.objectsbydesign.com/tools/umltools_byCompany.h
tml
)

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 314

 Microsoft Visio

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 315

 UML studio 7.1

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 316

 References
1. UML Distilled: A Brief Guide to the Standard Object Modeling Language
Martin Fowler, Kendall Scott

2. Practical UML --- A Hands-On Introduction for Developers

3. http://www.togethersoft.com/services/practical_guides/umlonlinecourse/

4. OO Concepts in UML. Dr. David A. Workman, School of EE and CS. UCF.

5. Software Engineering Principles and Practice. Second Edition; Hans van Vliet.

6. http://labs.cs.utt.ro/labs/acs/html/lectures/4/lecture4.pdf

7. http://www.agilemodeling.com/

8. http://www.visual-paradigm.com/VPGallery/diagrams/index.html

9. http://bdn.borland.com/article/0,1410,31863,00.html

10.http://en.wikipedia.org/wiki/Unified_Modeling_Language

11.http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm

By Dr. Samuel Asferaw OOSAD DBU 2018/2019 317