Samuel - Object-Oriented Systems Analysis and Design

Object-Oriented Systems
Analysis and Design

By Dr. Samuel Asferaw
2021/2022
1. Introduction:
Principles of Object
Oriented Technology
07/05/2022 OOSAD DBU 2021/2022 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
• 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 4

Object-Oriented Overview
• Object-oriented techniques work well in
situations where complicated systems are
undergoing continuous maintenance,
adaptation, and design
• There are two ways to model object-oriented
systems
– Coad and Yourdon methodology
– The Unified Modeling Language (UML)
07/05/2022 OOSAD DBU 2021/2022 5

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

Object-Oriented Programming…
• Six ideas characterize object-oriented
programming (continued):
– Inheritance, a new class created from another
class
– Polymorphism, meaning that a derived class
behavior may be different from the base class
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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 from outside
the class or component
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 10

Inheritance
• The two types of classes involved in any
inheritance relationship are the base class and
the derived class
• 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 13

Five General Types of Objects
• There are five general types of objects:
– Tangible things
– Roles
– Incidents
– Interactions
– Specifications details
07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 15

of Objects…
objects is justified …
– 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
07/05/2022 OOSAD DBU 2021/2022 16

of Objects…
objects is justified …
– Objects do not duplicate attributes and services
that could be derived from other objects in the
system
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 19

CRC Cards
• Class, responsibilities, and collaborators (CRC)
cards are used to represent the
responsibilities of classes and the interaction
between the classes
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 29

• 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
07/05/2022 OOSAD DBU 2021/2022 30

• 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 behavior of the system and
its interactions with the actors
07/05/2022 OOSAD DBU 2021/2022 31

Categories of Structural Things…
– 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
07/05/2022 OOSAD DBU 2021/2022 32

Categories of Structural Things…
– Nodes, which represent a piece of hardware on
which your system executes
• Components are physically deployed on nodes
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 34

Types of Relationships
• There are two types of relationships that hold
things together:
– Structural
– Behavioral
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 41

Behavioral Diagrams
• Behavioral diagrams describe the interaction
between people and a use case
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 45

Assignment
• 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
07/05/2022 OOSAD DBU 2021/2022 46
2. Business
Modeling /Domain
Analysis/
07/05/2022 OOSAD DBU 2021/2022 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,
– what work the business performs, and
– how it performs that work.
07/05/2022 OOSAD DBU 2021/2022 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, and
business rules.
07/05/2022 OOSAD DBU 2021/2022 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 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!
07/05/2022 OOSAD DBU 2021/2022 50
Modeling Business Disciplines
Four distinct business modeling disciplines
• Business process models

• Business motivation models
• Business organization models
• Business rule models
07/05/2022 OOSAD DBU 2021/2022 51

Modeling Business Disciplines …
Business Process Models
• Capture how a business performs its work, the

step-by-step activities that are performed
07/05/2022 OOSAD DBU 2021/2022 52

Business Motivation Models
• Capture the goals and strategies of a business

• What a business is attempting to do and how
those attempts fit into its changing environment
07/05/2022 OOSAD DBU 2021/2022 53

Business Organization Models
• Capture who performs the work in an organization

and with whom they interact with, both inside the
organization and outside.
07/05/2022 OOSAD DBU 2021/2022 54

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.
07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 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:
• Taking patient information
• Patient examination
• Patient referral to labs and ray
• Ray imaging
• Ray image reporting
07/05/2022 OOSAD DBU 2021/2022 57

Integrating the four disciplines…
Example
any hospital includes the business process of emergency
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
07/05/2022 OOSAD DBU 2021/2022 58

Integrating the four disciplines…
Example
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)
07/05/2022 OOSAD DBU 2021/2022 59

Integrating the four disciplines …
Example
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)
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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 form of requirements for end users
07/05/2022 OOSAD DBU 2021/2022 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…
07/05/2022 OOSAD DBU 2021/2022

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.

07/05/2022 OOSAD DBU 2021/2022
So, how do you model the
business?
07/05/2022 OOSAD DBU 2021/2022

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)
07/05/2022 OOSAD DBU 2021/2022
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 and refined in elaboration.
07/05/2022 OOSAD DBU 2021/2022

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 .
07/05/2022 OOSAD DBU 2021/2022
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!”
07/05/2022 OOSAD DBU 2021/2022
3. Requirements Gathering
/Requirements Engineering/
07/05/2022 OOSAD DBU 2021/2022 70

What is requirement?
• A requirement is a statement about an
intended product that specifies what it should
do or how it should perform.
• Goal: To make as specific, unambiguous, and
clear as possible.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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 for
a particular product OOSAD DBU 2021/2022
07/05/2022 73
Sources of Requirements Gathering
• Users
• Reports
• Forms
• Procedures and documents
• Etc
07/05/2022 OOSAD DBU 2021/2022 74

Data Gathering Techniques
• Interviews
• Questionnaires
• Focus groups and workshops
• Naturalistic Observation
• Studying documentation
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 77

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
07/05/2022 OOSAD DBU 2021/2022 78

Interviews …
• Preparing for the Interview
– Confirm place/time
– Review areas to be covered
– Encourage interviewee to bring reference
materials
07/05/2022 OOSAD DBU 2021/2022 79

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
07/05/2022 OOSAD DBU 2021/2022 80

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.
07/05/2022 OOSAD DBU 2021/2022 81

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!
07/05/2022 OOSAD DBU 2021/2022 82
• 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)
07/05/2022 OOSAD DBU 2021/2022 83

Generic Interview Template
07/05/2022 OOSAD DBU 2021/2022 84

Generic Interview Template…
07/05/2022 OOSAD DBU 2021/2022 85

07/05/2022 OOSAD DBU 2021/2022 86

07/05/2022 OOSAD DBU 2021/2022 87

Generic Interview Template (Cont’d)
07/05/2022 OOSAD DBU 2021/2022 88

07/05/2022 OOSAD DBU 2021/2022 89

07/05/2022 OOSAD DBU 2021/2022 90

07/05/2022 OOSAD DBU 2021/2022 91

07/05/2022 OOSAD DBU 2021/2022 92

07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 97

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.
07/05/2022 OOSAD DBU 2021/2022 98

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
07/05/2022 OOSAD DBU 2021/2022 99
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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 101
Requirements Specification and
Documentation
• Data interpretation and analysis
• Task descriptions
• Task analysis
• Requirements management
• Requirements Specification
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 104

Task Analysis
• Task analysis is used mainly to investigate an
existing situation
• Many techniques, the most popular is

Hierarchical Task Analysis (HTA)
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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

Step 1, 3, 4 have no subtasks, but
Step 2 has subtasks
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 109

Use Cases
• Use Cases
– Use Cases 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
07/05/2022 OOSAD DBU 2021/2022 110

Use cases…
How to avoid many words in the requirement
description ?
• Try graphical description. For example,
Actors----------------------Use Cases
Administrator --------- Arrange a Meeting
07/05/2022 OOSAD DBU 2021/2022 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.

07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 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 ...
07/05/2022 OOSAD DBU 2021/2022 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!
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 118

Examples
07/05/2022 OOSAD DBU 2021/2022 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…
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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 supports browser and Sidecar
07/05/2022 OOSAD DBU 2021/2022 129

Use Case Diagram for Quiz System
TakeQuiz
QuizTaker
CheckGrades
RequestRegrade
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 131
Relationships Between Use Cases:
<<includes>>
TakeQuiz <<includes>>
Authenticate
QuizTaker
CheckGrades <<includes>>
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 133

Example 3: Detailed Process Use Cases
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 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

07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.]
* 07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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…
07/05/2022 OOSAD DBU 2021/2022 142

How to Manage changing requirements
• Single channel of change control/Change Control Board (CCB).
• Keep track
history of
requirements
• Maintain
version control
• More…
07/05/2022 OOSAD DBU 2021/2022 143

4. OO Basic Concepts
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 145

OO Basic Concepts...
• Information hiding – use encapsulation to
restrict external visibility
• OO encapsulates the data, provides limited
access, visibility
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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)
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 152

07/05/2022 OOSAD DBU 2021/2022 153

• 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
07/05/2022 OOSAD DBU 2021/2022 154

Hierarchy Class Example
Attributes
Subclass has access to these
Operations
Subclass has access to these
07/05/2022 OOSAD DBU 2021/2022 155

• 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
07/05/2022 OOSAD DBU 2021/2022 156

• 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 161

• 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
07/05/2022 OOSAD DBU 2021/2022 162

• 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
07/05/2022 OOSAD DBU 2021/2022 163

• 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 166

• 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
07/05/2022 OOSAD DBU 2021/2022 167

• 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 170

Example
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 172
Example…
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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!
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 179

5. Object Oriented
Analysis
07/05/2022 OOSAD DBU 2021/2022 180

Object Oriented Analysis
• OO Analysis Overview
• Identify Entity – Domain Modeling
• Assigning Responsibilities
07/05/2022 OOSAD DBU 2021/2022 181

OO Analysis Overview
• Understanding Analysis
• Analysis Versus Design
• Object Oriented Analysis
• Three ways to do Object Oriented Analysis
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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/.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 187

Identify Entity – Domain Modeling
• Visualizing Concepts
• Adding Associations
• Adding Attributes
• Modeling Generalization
• Refining the Domain Model
07/05/2022 OOSAD DBU 2021/2022 188

VISUALIZING CONCEPTS
• Domain Models
• Conceptual Class Identification
• Domain Modeling Guidelines
• Modeling the Unreal world
• Specification of Conceptual Classes
• UML Notation v.s. Methodology
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 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 2021/2022 193

Example: Domain Model
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 196

Conceptual Class Modeling Guidelines
• How to Make a Domain Model/Analysis Class Diagram/?
– 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 2021/2022 200

Example: Specification or Description Conceptual Classes
OOSAD DBU 2021/2022 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 2021/2022 202

Adding Association
• Associations
• The UML Association Notation
• Finding Associations
• Association Guidelines
• Naming Associations
• Multiple Associations Between Two Types
• Associations and Implementation
• Example
07/05/2022 OOSAD DBU 2021/2022 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 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 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
07/05/2022 OOSAD DBU 2021/2022 210

Example-Applying the Category of Associations
Checklist
07/05/2022 OOSAD DBU 2021/2022 211

Adding Attributes
• Attributes VS. Associations
• No Attributes as Foreign Keys
07/05/2022 OOSAD DBU 2021/2022 212

Attributes VS. Associations
• The attributes in a domain model should preferably be
simple attributes or data types.
07/05/2022 OOSAD DBU 2021/2022 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.
07/05/2022 OOSAD DBU 2021/2022 214

Modeling Generalization
• Noun Phrase Identification from the Use Cases
• Generalization
• Defining Conceptual Superclasses and Subclasses
• Abstract Conceptual Classes
07/05/2022 OOSAD DBU 2021/2022 215

Example
Noun Phrase Identification from

the Use Cases Description
07/05/2022 OOSAD DBU 2021/2022 216

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 2021/2022 217

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 2021/2022 218

Generalization-Specialization Class Hierarchy
• The concepts CashPayment, CreditPayment, and Check

Payment are all very similar.
07/05/2022 OOSAD DBU 2021/2022 219

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
07/05/2022 OOSAD DBU 2021/2022 220
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.
07/05/2022 OOSAD DBU 2021/2022 221

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.
07/05/2022 OOSAD DBU 2021/2022 222
Example subclass partitions
07/05/2022 OOSAD DBU 2021/2022 223

Abstract Conceptual Classes
07/05/2022 OOSAD DBU 2021/2022 224

Abstract Class Notation in the UML
07/05/2022 OOSAD DBU 2021/2022 225

Refining the Domain Model
• Association Classes
• Aggregation and Composition
• Roles as Concepts vs. Roles in Associations
• Qualified Associations
• Reflexive Associations
07/05/2022 OOSAD DBU 2021/2022 226

Association Classes
07/05/2022 OOSAD DBU 2021/2022 227

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...
07/05/2022 OOSAD DBU 2021/2022 228
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
07/05/2022 OOSAD DBU 2021/2022 229

Composition
• A form of aggregation with strong ownership and
coincident lifetimes
– The parts cannot survive without the whole/aggregate
Whole Part
Student Schedule
Composition
07/05/2022 OOSAD DBU 2021/2022 230

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).
07/05/2022 OOSAD DBU 2021/2022 231

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.
07/05/2022 OOSAD DBU 2021/2022 232

Reflexive Associations
 A concept may have an association to itself; this is known
as a reflexive association
07/05/2022 OOSAD DBU 2021/2022 233

Responsibilities
• Responsibilities
• Responsibility-Driven Design
• CRC Cards
07/05/2022 OOSAD DBU 2021/2022 234

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.
07/05/2022 OOSAD DBU 2021/2022 235
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).
07/05/2022 OOSAD DBU 2021/2022 236
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.
07/05/2022 OOSAD DBU 2021/2022 237

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).
07/05/2022 OOSAD DBU 2021/2022 238
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
07/05/2022 OOSAD DBU 2021/2022 239

Summary: Finding Entity/Analysis 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 (save for later)
07/05/2022 OOSAD DBU 2021/2022 240

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
07/05/2022 OOSAD DBU 2021/2022 242

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
07/05/2022 OOSAD DBU 2021/2022 243

OOA and OOD…
07/05/2022 OOSAD DBU 2021/2022 244

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
07/05/2022 OOSAD DBU 2021/2022 245

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
07/05/2022 OOSAD DBU 2021/2022 246

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 { }
07/05/2022 OOSAD DBU 2021/2022 247

Design Class – example
07/05/2022 OOSAD DBU 2021/2022 248

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
07/05/2022 OOSAD DBU 2021/2022 249

Example – class hierarchy
07/05/2022 OOSAD DBU 2021/2022 250

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
07/05/2022 OOSAD DBU 2021/2022 251

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
– Sequence diagram
– Collaboration diagram
• Two are equivalent in power
07/05/2022 OOSAD DBU 2021/2022 252
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
07/05/2022 OOSAD DBU 2021/2022 253

Example – Sequence Diagram
Objects participating in an interaction
Time
07/05/2022 OOSAD DBU 2021/2022 254

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
07/05/2022 OOSAD DBU 2021/2022 255

Example – Collaboration Diagram
07/05/2022 OOSAD DBU 2021/2022 256

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
07/05/2022 OOSAD DBU 2021/2022 257

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
07/05/2022 OOSAD DBU 2021/2022 258

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
07/05/2022 OOSAD DBU 2021/2022 259

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
07/05/2022 OOSAD DBU 2021/2022 260

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
07/05/2022 OOSAD DBU 2021/2022 261
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
07/05/2022 OOSAD DBU 2021/2022 262

Restaurant example: Initial classes
07/05/2022 OOSAD DBU 2021/2022 263

07/05/2022 OOSAD DBU 2021/2022 264
Restaurant example: a sequence diagram
07/05/2022 OOSAD DBU 2021/2022 265

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
07/05/2022 OOSAD DBU 2021/2022 266

Example 2: Word Count Problem…
File
name
History
getword() Counter
isEof()
addWord()
count
exists()
increment()
display()
Word
string
setstring()
getstring()
07/05/2022 OOSAD DBU 2021/2022 267

Example 2: Word Count Problem
Collaboration Diagram
Check
Read Get
For
File words
Uniqueness
Increment
Add to
Count
History
07/05/2022 OOSAD DBU 2021/2022 268

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
07/05/2022 OOSAD DBU 2021/2022 269

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
07/05/2022 OOSAD DBU 2021/2022 270

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
07/05/2022 OOSAD DBU 2021/2022 271

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 2021/2022 272

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
273
OOSAD DBU 2021/2022

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 2021/2022 274

Class Diagram
Investment
1
m Transaction
m
Portfolio
1
m
Security Debit Credit

1
Bank Deposit Shares
07/05/2022 OOSAD DBU 2021/2022 275

associations for action Create/Delete/Edit Transaction
OOSAD DBU 2021/2022 276

Class diagram with classes and associations
OOSAD DBU 2021/2022 277

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.
278
OOSAD DBU 2021/2022
Sequence diagram for principle action Create Portfolio
OOSAD DBU 2021/2022 279

Sequence diagram for principle action Delete Transaction
280
OOSAD DBU 2021/2022
Sequence diagram for action Compute Net Worth of
Investment/Portfolio/Security
OOSAD DBU 2021/2022 281

Sequence diagram for action Load current prices from the
Internet
OOSAD DBU 2021/2022 282

Sequence diagram for action Set/Check/Delete Alerts
283
OOSAD DBU 2021/2022
Sequence diagram for action Validate User
OOSAD DBU 2021/2022 284

7. UML: Unified Modeling
Language
(Reading Assignment)
OOSAD DBU 2021/2022 285

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
07/05/2022 OOSAD DBU 2021/2022 286

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)
07/05/2022 OOSAD DBU 2021/2022 287

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
07/05/2022 OOSAD DBU 2021/2022 288

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
07/05/2022 OOSAD DBU 2021/2022 289
Different Levels of Specifying Classes
07/05/2022 OOSAD DBU 2021/2022 290

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”
07/05/2022 OOSAD DBU 2021/2022 291

Other variations in Class specifications
• Use of
templates,
interfaces, and
types
• Can even specify
body of methods
07/05/2022 OOSAD DBU 2021/2022 292

Components of Class Diagrams
• Multiplicities
– How many of
each?
• Labels to indicate
how reference is
viewed
• Role and
Association
classes
07/05/2022 OOSAD DBU 2021/2022 293

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
07/05/2022 OOSAD DBU 2021/2022 294

Qualifiers
• Serves to describe an instance variable that
partitions the relationship.
07/05/2022 OOSAD DBU 2021/2022 295

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’)
07/05/2022 OOSAD DBU 2021/2022 296

Simple Use Case Diagram
Reserve book
Borrow book
Return book
07/05/2022 OOSAD DBU 2021/2022 297

Use Case Diagram with Multiple
Actors
07/05/2022 OOSAD DBU 2021/2022 298

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
07/05/2022 OOSAD DBU 2021/2022 299

Example Use Case Diagram
(Advanced Features)
07/05/2022 OOSAD DBU 2021/2022 300

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.
07/05/2022 OOSAD DBU 2021/2022 301

Example Sequence Diagram
07/05/2022 OOSAD DBU 2021/2022 302

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"
07/05/2022 OOSAD DBU 2021/2022 303

Example State Diagram
07/05/2022 OOSAD DBU 2021/2022 304

Other Kinds of UML Diagrams
• Collaboration Diagrams
– An alternative to sequence diagrams for
describing the flow of messages between objects
07/05/2022 OOSAD DBU 2021/2022 305

Other kinds of UML Diagrams
• Activity Diagrams
– Alternative to
statecharts
07/05/2022 OOSAD DBU 2021/2022 306

Other kinds of UML Diagrams
• Implementation
Diagrams
– Down at the detail level
• What piece of code goes
where?
• How are they connected?
07/05/2022 OOSAD DBU 2021/2022 307

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
07/05/2022 OOSAD DBU 2021/2022 308

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
07/05/2022 OOSAD DBU 2021/2022 309

Student Registration Class Diagram
Student Transcript
1 1
transcript courseGrades
major * 1
schedule
Registrar gradeForCourse:
registrar Section takenCourse:
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
07/05/2022 OOSAD DBU 2021/2022 310
Partial Use Case Diagram
Apply for
Admission
Enroll in
the University Admissions
Student Enroll in
a Course
Withdraw
from a Course
07/05/2022 OOSAD DBU 2021/2022 311

States of a Student
Apply [ Must be accepted first ]
Enrolled
EnrollInClass ( Add a Transcript )
Withdraw Registered AddCourse
Graduate [ All courses must be completed ]
07/05/2022 OOSAD DBU 2021/2022 312

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
07/05/2022 OOSAD DBU 2021/2022 313

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!
07/05/2022 OOSAD DBU 2021/2022 314

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
)
07/05/2022 OOSAD DBU 2021/2022 315

Microsoft Visio
07/05/2022 OOSAD DBU 2021/2022 316

UML studio 7.1
07/05/2022 OOSAD DBU 2021/2022 317

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
07/05/2022 OOSAD DBU 2021/2022 318

Thank You !
07/05/2022 OOSAD DBU 2021/2022 319

Samuel - Object-Oriented Systems Analysis and Design

Uploaded by

Copyright:

Available Formats

Samuel - Object-Oriented Systems Analysis and Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Samuel - Object-Oriented Systems Analysis and Design

Uploaded by

Copyright:

Available Formats

Object-Oriented Systems

Analysis and Design

07/05/2022 OOSAD DBU 2021/2022 2

• 1995-2003: Grady Booch (Rational

07/05/2022 OOSAD DBU 2021/2022 4

07/05/2022 OOSAD DBU 2021/2022 5

07/05/2022 OOSAD DBU 2021/2022 6

07/05/2022 OOSAD DBU 2021/2022 7

07/05/2022 OOSAD DBU 2021/2022 8

• Another name for property is attribute

07/05/2022 OOSAD DBU 2021/2022 9

07/05/2022 OOSAD DBU 2021/2022 10

07/05/2022 OOSAD DBU 2021/2022 11

07/05/2022 OOSAD DBU 2021/2022 12

07/05/2022 OOSAD DBU 2021/2022 13

07/05/2022 OOSAD DBU 2021/2022 14

07/05/2022 OOSAD DBU 2021/2022 15

07/05/2022 OOSAD DBU 2021/2022 16

07/05/2022 OOSAD DBU 2021/2022 17

07/05/2022 OOSAD DBU 2021/2022 18

07/05/2022 OOSAD DBU 2021/2022 19

07/05/2022 OOSAD DBU 2021/2022 20

07/05/2022 OOSAD DBU 2021/2022 21

– Responsibilities evolve into methods or operations

07/05/2022 OOSAD DBU 2021/2022 22

• UML (Unified Modeling Language) is the result

07/05/2022 OOSAD DBU 2021/2022 23

• UML has three categories:

07/05/2022 OOSAD DBU 2021/2022 24

07/05/2022 OOSAD DBU 2021/2022 25

• The steps required to create a use case model

07/05/2022 OOSAD DBU 2021/2022 26

• Creating a use case model, continued

07/05/2022 OOSAD DBU 2021/2022 27

07/05/2022 OOSAD DBU 2021/2022 29

07/05/2022 OOSAD DBU 2021/2022 30

07/05/2022 OOSAD DBU 2021/2022 31

07/05/2022 OOSAD DBU 2021/2022 32

07/05/2022 OOSAD DBU 2021/2022 33

07/05/2022 OOSAD DBU 2021/2022 34

07/05/2022 OOSAD DBU 2021/2022 35

07/05/2022 OOSAD DBU 2021/2022 36

07/05/2022 OOSAD DBU 2021/2022 37

• There are four active behavioral relationships:

07/05/2022 OOSAD DBU 2021/2022 38

• Types of active behavioral relationships,

07/05/2022 OOSAD DBU 2021/2022 39

07/05/2022 OOSAD DBU 2021/2022 40

07/05/2022 OOSAD DBU 2021/2022 41

07/05/2022 OOSAD DBU 2021/2022 42

07/05/2022 OOSAD DBU 2021/2022 43

07/05/2022 OOSAD DBU 2021/2022 44

07/05/2022 OOSAD DBU 2021/2022 45

07/05/2022 OOSAD DBU 2021/2022 47

• A business model is a simple representation of the

• Business models are useful for understanding

07/05/2022 OOSAD DBU 2021/2022 48

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

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