College of Computing and Informatics

Department of Information Systems

Course Title:- System Analysis and

Design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 CHAPTER ONE
System Development

OUTLINE
Introduction to Information System development.
System development methodologies, / Software
life cycle and process model and phase
Problem Identification, Selection and Planning
Phase:
Problem identification
problem definition: symptoms vs problems
prioritizing problems
project initiation and planning
planning tools and techniques
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Gantt and PERT
 Data
The data simply exists and has no meaning
beyond its existence (in itself).
It can exist in any form, usable or not. The
data exists in different formats, such as
text, image, sound, or even video.
Information
Information is data combined with
meaning. Information embodies the
understanding of a relationship as the
relationship between cause and effect
Ex: The temperature dropped 15 degrees,
then it started to rain. According to Ackoff,
information is useful data; it provides
answers
Compiled by: to the questions:
Tilahun.M
sis and Design
System Analy “who,” “what,”
01/23/2025
 Data Vs Information
 Data is a collection of facts, while information puts those facts into context.
 While data is raw and unorganized, information is organized.
 Data, on its own, is meaningless. When it’s analyzed and interpreted, it

becomes meaningful information.

 Data does not depend on information; however, information depends on

data.
 Data typically comes in the form of graphs, numbers, figures, or statistics.

Information is typically presented through words, language, thoughts, and

ideas.
 Data isn’t sufficient for decision-making, but you can make decisions based

on information.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Knowledge
Knowledge can be seen as information combined
with experience, context, and interpretation.
Knowledge constitutes an additional semantic
level derived from information via a process .

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 What is System?
The word System is derived from Greek word
System a, which means an organized relationship
between any set components to achieve some
common cause or objective.
A System is “ an orderly grouping of
interdependent components linked together
according to a plan to achieve a specific goal.”
 Is a group of components that work together in
coordination to achieve a common goal.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Example: Breathing System has components like nose,

mouth, lung, heart and these components work together to

achieve a common goal, that is, to enable humans to live.

 Computer System has components like hardware and software.

These components work together to achieve a common goal,

that is, data processing (converting raw data to information).

 Is an interrelated set of business procedures used with in one

business unit, working together for some purpose.

 The system takes input from outside, processes it, and sends

the resulting output back to its environment

. Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Constraints of a System?

A System must have three basic constraints

A System must have some structure and behavior

which is designed to achieve a predefined objective.

Interdependence and connectivity must exist

among the system components.

The objectives of the organization have a higher

priority than the objectives of its subsystems.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Properties of a System
 A system has the following properties
 Components :are either an irreducible part or an
aggregate of parts, also called a subsystem.
 Interrelated Components: the function of one component
is tied or connected to the functions of the others.
 Boundary : A system has boundary, within which all of its
components are contained and which establishes the
limits of a system, separating it from other systems.
 Purpose :All components work together to achieve the
overall purpose of the system.
 Interfaces :is the point at which the system meets its
environment
and there are also interfaces between subsystems.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Properties of a System cont…
 Environment: The environment is the “super
system” within which an organization operates.
It is the source of external elements that strike on
the system.
 Input :system takes input from its environment in
order to function.
 Output: system returns output to its environment
as a result of its functioning to achieve the
purpose.
 Constraints: are limits to what the system can do
(capacity, speed and capability ), some of these
constraints are imposed inside the system and
others are imposed by the environment.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Properties of a System cont..
System has the following properties

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 System cont...
Based on its interaction with the environment, we
can classify a system in to two.
Open Systems: interact with the environment
freely , taking inputs and returning outputs.
 For example: an information system which must
adapt to the changing environmental conditions.
closed system: A closed system does not interact
with its environment. It is isolated from
environmental influences.
 A completely closed system is rare in reality.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Information Systems

With an understanding of the terms

“information” and “system,” the
definition of an information system is
almost intuitive:
 an Information System (IS) consists of
all the components that work together to
process data and produce information.
 Almost all business information systems
consist of many subsystems with sub goals,
all contributing to the organization’s main
goal.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Information Systems in Organizations

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 TYPES OF INFORMATION SYSTEMS

Transaction Processing Systems (TPS)

 Management Information Systems (MIS)
 Decision Support Systems (DSS)

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
The following diagram illustrates the
various levels of a typical organization.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Transaction Processing System (TPS)

Transaction processing systems are used to

record day to day business transactions of the
organization. They are used by users at the
operational management level.
The main objective of a transaction processing
system is to answer routine questions such as;
 How printers were sold today?
 How much inventory do we have at hand?

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Examples of transaction processing systems
include;
Point of Sale Systems – records daily sales
Payroll systems – processing employees
salary, loans management, etc.
Stock Control systems – keeping track of
inventory levels
Airline booking systems – flights booking
management
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Management Information System (MIS)

 Management Information Systems (MIS) are used by

tactical managers to monitor the organization's current
performance status.
 The output from a transaction processing system is used
as input to a management information system.
 The MIS system analyzes the input with routine
algorithms i.e. aggregate, compare and summarizes the
results to produced reports that tactical managers use
to monitor, control and predict future performance.
 For example, input from a point of sale system can be
used to analyze trends of products that are performing
well and those that are not performing well.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Examples of management information systems include;

 Sales management systems – they get input from the point of

sale system
 Budgeting systems – gives an overview of how much money is
spent within the organization for the short and long terms.
 Human resource management system – overall welfare of
the employees, staff turnover, etc.
 Tactical managers are responsible for the semi-structured
decision. MIS systems provide the information needed to make
the structured decision and based on the experience of the
tactical managers, they make judgment calls i.e. predict how
much of goods or inventory should be ordered for the second
quarter based on the sales of the first quarter.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Decision Support System (DSS)
 Decision support systems are used by senior management to
make non-routine decisions.
 Decision support systems use input from internal systems
(transaction processing systems and management information
systems) and external systems.
 The main objective of decision support systems is to provide
solutions to problems that are unique and change frequently.
 Decision support systems answer questions such as;
 What would be the impact of employees' performance if we
double the production lot at the factory?
 What would happen to our sales if a new competitor entered the
market ?
 Decision support systems use sophisticated mathematical
models, and statistical techniques (probability, predictive
modeling, etc.) to provide solutions, and they are very interactive.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Examples of decision support systems include;

Financial planning systems – it enables managers

to evaluate alternative ways of achieving goals.
The objective is to find the optimal way of achieving
the goal. For example, the net profit for a business is
calculated using the formula Total Sales less (Cost of
Goods + Expenses).
 A financial planning system will enable senior
executives to ask what if questions and adjust the
values for total sales, the cost of goods, etc. to see
the effect of the decision and on the net profit and
find the most optimal way.
Bank loan management systems – it is used to
verify the credit of the loan applicant and predict the
Compiled by: Tilahun.M System Analy 01/23/2025
likelihood of the loan being recovered.
sis and Design
 System Development Methodology
A methodology is a formalized approach to
implementing the SDLC (i.e., it is a list of steps and
deliverable).
System Development Methodology is a
standard process followed in an organization to
conduct all the steps necessary to analyze,
design, implement and maintain information
systems.
System Development Life Cycle (SDLC) is a
conceptual model which includes policies and
procedures for developing systems throughout
their life cycles.
It is also called as Software Development Process.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 SDLC
SDLC is a framework defining tasks performed at
each step in the software development process.
ISO/IEC 12207 is an international standard for
software life-cycle processes. It aims to be the
standard that defines all the tasks required for
developing and maintaining software.
This methodology use :System planning and
selection, Analysis, Design and Implementation
and operation.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Advantage and Dis advantage of Waterfall

The two key advantages of the structured design

waterfall approach are
1. Identifies system requirement long before
programming begins and
2. It minimizes changes to the requirements as the
project proceeds.
The linear nature of the waterfall development
method makes it easy to understand and language.
projects with clear objectives and stable
requirements can best use the waterfall method.
less experienced project managers and project
teams, may benefit the most from using the waterfall
development methodology.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Advantage and Dis advantage of Waterfall cont.…
The two key disadvantages are that the design
must be completely specified before
programming begins and that a long time elapse
between the completion of the system proposal in
the analysis phase and the delivery of the system
(usually many months or years).
The waterfall development method is often slow
and costly due to its rigid structure and tight
controls.
these drawbacks can lead waterfall method users to
explore other software development methodologies

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 2.Parallel Development
General design for the whole system is performed and
then divides the project into a series of distinct sub-
projects that can be designed and implemented in parallel.
The primary advantage of this methodology is that it can
reduce the schedule time to deliver a system; thus, there is
less chance of changes in the business environment causing
rework.
However, the approach still suffers from problems caused by
paper documents.
 It also adds a new problem:
 Sometimes the sub-projects are not completely
independent;
 Design decisions made in one sub-project may affect another,
 The end of the project may require significant integration
efforts.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Rapid Application Development (RAD)
RAD-based methodologies attempt to address both
weaknesses of
structured design methodologies by adjusting the SDLC
phases to get some part of the system developed quickly and
into the hands of the users.
In this way, the users can better understand the system and
suggest revisions that bring the system closer to what is
needed.
1.Phased Development
A phased development–based methodology breaks an overall
system into a series of versions, which are developed
sequentially.
The analysis phase identifies the overall system concept,
and the project team, users, and system sponsor then
categorize the requirements into a series of versions.
The most important and fundamental requirements are
Compiled by: Tilahun.M System Analy 01/23/2025
bundled
sis and into
Designthe first version of the system.
 Phased Development

Once version 1 is implemented, work begins on

version 2. Additional analysis is performed
based on the previously identified
requirements and combined with new ideas
and issues that arose from the users’ experience
with version 1.
Version 2 then is designed and implemented,
and work immediately begins on the next
version.
This process continues until the system is
complete or is no longer in use.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Phase Development cont..

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Rapid Application Development (RAD)
 2.Prototyping
 A prototyping-based methodology performs the analysis,
design, and implementation phases concurrently, and all
three phases are performed repeatedly in a cycle until the
system is completed.

 Advantage:
 Provides a system for the users to interact with, even if it is
not initially ready for use.
 Quick feedback: Prototyping method enables quick feedback
from the client and helps to identify gaps in the initial
requirements or design specifications
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Rapid Application Development (RAD)
cont.…
Reduced risk: By prototyping, many design flaws
and bugs can be identified early in the development
process which can help to reduce the risk of failure.
 Disadvantage:
High scope creep: The client may request changes
or additions to the prototype, leading to the scope of
the project continuously expanding, which can
result in the project taking longer to complete than
expected.
Unsuitable for large projects: Prototyping may not
be suitable for larger projects because of the time
required to create and test multiple prototypes. This
can lead to delays, increased costs, and make the
product less attractive
Compiled by: Tilahun.M
to clients. 01/23/2025
System Analy
sis and Design
 Agile Development
These programming-centric methodologies have
few rules and practices, all of which are fairly easy to
follow.

They focus on streamlining/core the SDLC by

eliminating much of the modeling and
documentation overhead and the time spent on
those tasks.
Examples of agile development methodologies
include extreme programming, Scrum, and the
Dynamic Systems Development Method (DSDM).
Agile Development is used to minimize risk by
developing software in short time boxes which are
called iterations that generally last for one week to
Compiled by: Tilahun.M System Analy 01/23/2025
onesismonth.
and Design
 Agile Development cont…
evelopme
 Teams use the agile development methodology to minimize risk(such
as bugs, cost overruns, and changing requirement) when adding new
functionality.
 In all agile methods, teams develop the software in iterations that contain
mini-increments of the new functionality.
 Pros:
1. The primary benefit of agile software development is that it
allows software to be released in iterations.
2. Iterative releases improve efficiency by allowing teams to find
and fix defects and align expectation early on.
3. They also allow users to realize software benefits earlier, with
frequent incremental improvements.
 Cons:
1. Agile development methods rely on real-time communication, so new
users often lack the documentation they need to get up to speed.
2. They require a huge time commitment from users and are labor
intensive because developers must fully complete each feature with
each iteration
Compiled for user approval
by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Clarity of User Requirements: RAD methodologies
Selecting the Appropriate Development Methodology:

of prototyping and throwaway prototyping are usually

more appropriate when user requirements are unclear
as they provide prototypes for users to interact with
early in the SDLC.
Familiarity with Technology: If the system is
designed without some familiarity with the base
technology, risks increase because the tools may not
be capable of doing what is needed.
System complexity: Complex systems require
careful and detailed analysis and design. Project
teams who follow phased development-based
methodologies tend to devote less attention to the
analysis of the complete problem domain than they
might if they were using
Compiled by: Tilahun.M
other methodologies.
System Analy 01/23/2025
sis and Design
Selecting the Appropriate Development Methodology cont..
 System Reliability: System reliability is usually an important
factor in system development. Throwaway prototyping-based
methodologies are most appropriate when system reliability is
a high priority. Prototyping-based methodologies are generally
not a good choice as they lack careful analysis and design
phases.
 Short Time Schedules: RAD-based methodologies are well
suited for projects with short time schedules as they increase
speed. Waterfall-based methodologies are the worst choice
when time is essential as they do not allow for easy schedule
changes.
 Schedule Visibility: RAD-based methodologies move many of
the critical design decisions earlier in the project;
consequently, this helps project managers recognize and
address risk factors and keep expectations high.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Problem Identification and selection

Is the first phase of systems development life cycle.

It can be:
 Problems in existing system or process.
 New feature required in an existing system.
 A requirement to improve efficiency in the
organization.
During this activity, senior manager, a business
group or an IS manager identifies and assesses
all possible systems development projects that
a business unit could undertake.
Activity: select one title and Identify the problems
about your title.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Problem definition
A problem statement /definition is a concise
description of the problem or issues a project
seeks to address.
The problem statement identifies the current
state , the desired future state and any gaps
between the two.
A problem statement is an important
communication tool that can help everyone who
are working on a project to know what the
problem they need to address is and why the
project is important.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Symptoms vs Problems. . .
Problem and Symptom are two words that are
often confused as words that give similar
purpose, but they are actually not so.
A problem has a solution whereas a symptom
helps you to identify a problem.
Example: Many diseases or problems relating to
health have symptoms. These symptoms help the
doctor to identify the problem relating to health.
If somebody is coughing or sneezing, that
person may have a common cold.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Prioritizing a problem

Project workers may be trying to solve too many

problems at once.
If a problem requires immediate attention, we should
prioritize it over attempting to solve multiple problems
at once.
Here is a simple step to prioritize problems:
1 Make a list.
2 Prioritize urgency and effort.
3 Learn about everything possible.
4 Make schedules visible and transparent.
5 Don’t be afraid to cut tasks.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 How to write a problem statement

The process used to write a problem statement

should involve answering questions using a
method commonly known as 5W2H. The process
involves :
what the problem is.
why it is a problem.
when and where the problem was identified.
who the problem impacts.
how they are impacted by the problem and how
much of an impact the problem has.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
A good statement of the problem may contain

Identify the problem. Begin your statement with

your ideal situation: what the ideal
environment would look like if your problem
didn’t exist.
Describe current gaps: between the ideal and
real situation.
State the consequences of the problem:
used to quantify and support the state of what
the problem is.
Propose addressing the problem.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Project initiation and planning
Projects, have a beginning and an end.
Each project also have defined phases between
the project kickoff and project closeout.
Phases are typically sequential, where the prior
phase is essentially completed before the
beginning of the next phase.
however, phases do not have clear-cut end
dates and some activities in an early phase of
the project will continue into the later phases.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Project initiation and planning cont....
The Project Management Institute (PMI)
identifies four major phases of a project as
characteristics of the project life cycle. Such as
 initiation,
 planning,
 execution,
 and project closeout.
Project initiation is just starting the project, which
includes all the activities necessary to begin planning
the project.
But, planning is organizing and preparing project
activity that includes the development of more
detailed schedules and a budget.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Project planning tools and techniques
Project management is a challenging task
with many complex responsibilities.
Program Evaluation Review Technique
(PERT) and Gantt Charts are the two most
commonly used project management tools.
PERT: is a planning and control tool used for
defining and controlling the tasks necessary
to complete a project.
PERT displays the total project with all
scheduled tasks shown in sequence.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Component of Pert Chart
Critical Path:- it is the longest possible
continuous pathway taken from the initial event
to the terminal event.
critical path in the a PERT chart represents the
longest or the most time consuming path
that is involved in the final completion of a task.
Slack: it is a measure of the excess time and
resources available in achieving an event.
Slack represents the amount of time that one
task can be delayed without affecting the
overall deadline of the task in question.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Object Orientation the new software paradigm
presentation outline

Structured paradigm Vs object oriented

paradigm
The potential benefits of object orientation
The potential drawbacks of object
orientation
The object orientation software process

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Structured paradigm Vs object oriented paradigm
Chapter 2: Object Orientation the new software paradigm

 The structured paradigm is a development strategy based on

the concept that a system should be separated into two parts:

 Data and ;

 Functionality

 Where on the other hand, the main concept behind the object

oriented paradigm is that instead of defining systems as two

separate parts, you now
 Define systems as collection of interacting objects.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 The potential benefits of object orientation

– Popularized in the late 1980’s

– Became the standard in mid – 1990s
Benefits
– Increased reusability
– Increased extensibility
– Improved quality
– Financial benefits
– Increased chance of project success
– Reduced maintenance burden
– Reduced application backlog
– Managed complexity

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Increased Reusability
Through the concepts
Inheritance
Polymorphism
Encapsulation
Modularity
Coupling
Cohesion
What is the essence of reusability and why cant it
be achieved in structured systems development?
What is the advantage of reusability?
How does each of the stated concepts increase
reusability?
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Increased Extensibility
Because classes have both data and
functionality when you add new features to
the system, you only need to make changes
in one place: the applicable class
Structured – change in single business rule
could affect many programs
Objects encapsulate both functionality and
data, making it easier to maintain your
software
Inheritance enables you to reuse existing
behaviors, making it easier to enhance your
software
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Improved Quality
On time, on budget, meet
user expectations
OO devt techniques provide
greater opportunity for users
to participate in the
development process.
Bulk requirement definitions
Essential Use Case and CRC
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Financial Benefits
• The previous benefits are all technical benefits –
giving business benefits of OO
• Better Faster Cheaper (BFC)
• The less code the less effort to maintain
• A system that is easily extensible is easy to
maintain
• System that meets user needs receive fewer
changes
• Benefits of OO are realized throughout the entire
development lifecycle, not just during
programming
• Therefore, because Technical Benefits are achieved
Compiled by: Tilahun.M System Analy
BFC can
sis and be achieved
Design
01/23/2025
Increased Chance of Project
Success
Success - On time, On budget, meeting
user needs
OO is the way to develop systems quickly
and inexpensively

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Reduced Maintenance
Burden
• Problems
– Maintenance Burden – Spending Significant Resources maintaining
software
– Application Backlog – Long waiting list of things to be done making
new projects not to start
• The Maintenance Burden exists for several reasons
– Many systems were developed in the past that are still in use
– System documentation is poor.
– Compared to the standards of today, legacy systems are poorly
built

 Why do you thing the legacy systems are poorly built ?

 How would maintenance burden and application backlog create

problem in a system development lifecycle ?
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Reduced Application Backlog

• 2-5 year AB exists

Project Project System

Proposed Begins Released

Idea
Development
Application Backlog time

Total Implementation Time

• Because OO techniques are more productive,

organizations are able to free up resources sooner
to tackle new projects
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Managed Complexity
You can build complex software from well
designed reusable objects
Expect the software you build today will
need to be changed tomorrow
Well designed object oriented software
enables you to react quickly to changes in
your environment

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Drawbacks of OO
• OO requires greater concentration on requirements
analysis
 You cannot built a system unless you know how it all fit
together (you need to do analysis and design)
 But this fact is often ignored by many developers
• Developers must work closely with users, which is easier
said than done
• Requires a complete change in mindset on the part of
individuals
• Is more than just programming, not easy and not that quick
• Benefits are on the long run
• Demands up-front investments in training, education and
tools
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Drawbacks …
Why is requirement analysis ignored in
reality ?
Why are developers and users far apart in
the system development process?
Describe the change in mindset that is
expected from individuals in OO
Describe how the benefits are assumed to
be in the long run?

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Drawbacks …
 Techniques do not guarantee you will build the
right system
 Necessitates increased testing
 OO is only part of the solution – not a silver bullet
or a panacea
Need CASE tools
Quality Assurance Tasks
Develop user interface tasks

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 The object orientation software process and models

In object-oriented software engineering, the software developer identifies and organizes

the application in terms of object-oriented concepts.
 i.e. prior to their final representation in any specific programming language or
software tools.
 The major phases of software development using object oriented methodology are :
 Object–Oriented Analysis
 Object–Oriented Design
 System Design
 Object design
 Object–Oriented Implementation and Testing

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Object–Oriented Analysis
 In this stage,
 The problem is formulated,
 User requirements are identified,
 A model is built based upon real -world objects.

=> The analysis produces models on how the

desired system should function and how it must be
developed.
=>The models do not include any implementation
details so that it can be understood and examined
by any non–technical application expert.
 Object–Oriented Design :includes two main
stages, namely,
•by:System
Compiled Tilahun.M design
System Analy 01/23/2025
sis and Design
System design
In this stage,
 The complete architecture of the desired
system is designed.
=> The system is visualized as a set of
interacting subsystems that in turn is composed
of a hierarchy of interacting objects, grouped
into classes.
=>Here, the emphasis is on the objects
comprising the system rather than the processes
in the system.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 System design cont.…
Example:
• To represent logical design like, the data flow,
inputs and outputs of the system we can use ER
Diagrams (Entity Relationship Diagrams).
• The static context of the system is designed
using a simple block diagram of the whole system
which is expanded into a hierarchy of subsystems.
• The dynamic context of a system describes how
the system interacts with its environment.
• It is modeled using use case diagrams.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Object design

 In this phase, a design model is developed based on both

the models developed in the system analysis phase and
the architecture designed in the system design phase.
=>All the classes required are identified.
=>The designer decides whether:
 new classes are to be created from scratch.
 any existing classes can be used in their original form, or
 new classes should be inherited from the existing classes.
=>The associations between the identified classes are
established and the hierarchies of classes are identified.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Object design cont.…
Example:
During Object Representation we may use static
and dynamic models
 We will use static models to describe the static
structure of a system using class diagrams and
object diagrams.

We will use dynamic models to describe the

dynamic structure of a system and show the
interaction between classes using interaction
diagrams and state–chart diagrams.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Object–Oriented Implementation and Testing

 In this stage, the design model developed in the

object design is translated into code in an
appropriate programming language or software
tool.

=> The databases are created and the specific

hardware requirements are fulfilled.

=> Once the code is in shape, it is tested using

specialized techniques to identify and remove the
errors in the code.
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Chapter 3. Understanding the Basics Object oriented concepts

Object-Oriented Systems Analysis

and Design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Outline
OO Terminology:
 -- Object, Abstraction , Encapsulation.
Class, Attribute, and Methods (processes,
operations).
Generalization, Inheritance, Polymorphism.
Association., Persistence

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
93
 Object
A business entity (person, agency in
environment, thing, concept) important for
business.

An entity that encapsulates data and

behavior

- Objects are categorized into classes

- Each individual object is an instance of a

2-
94
class
Compiled by: Tilahun.M
Analysis and Design
System
01/23/2025
 Abstraction
Abstraction
Process of including features, attributes and methods that are
of interest to your application and ignore the rest .
It is an analysis issue that deals with what a class knows or
does
Depends on the context in which you define the abstraction
The act of defining the interface of something
Act of painting a clear box around something

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
95
 Encapsulation
The characteristic of object-orientation in
which data and behavior are bundled into a
class and hidden from the outside world

Access to the data and behavior is provided

and controlled through an object’s interface

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
96
 Classes

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
97
 Classes –Example

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
98
 Classes and object

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
99
 Attributes
• Attribute - a named property of a class that
describes a range of values that instances
of the attribute might hold

• Attributes are the way classes encapsulate

data

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
10
0
 Operation/Method
A behavior of an object; what it can do

We use operation and method

interchangeably

Methods are identified and invoked by their

signatures, including name, parameters,
and return type

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
10
1
 2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
10
2
 2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
10
3
 Inheritance & Generalization
• Two or more classes often share the same attributes and/or methods
• Don’t need to write same code repeatedly
• Models “is a” and “is like” relationships
• Enables you to reuse existing data and code easily
• E.g. – STUDENTS have names, addresses and telephone numbers,
vehicles
• PROFESSORS have also the same
• Create a class PERSON having those attributes and make STUDENT
and PROFESSOR inherit from it
• Everything a superclass knows the subclass knows or does it for free
• Generalization: The relationship between a more general (or parent)
class and a more specific (or child) class .The more specific class can
have additional attributes and operations (methods)
2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
10
4
Inheritance
 2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
10
6
 Association
•A relationship between objects or between classes
(special associations).
•Types:

(1) Special associations between classes:

(2) Between objects

1. Special associations between classes:

 Generalization (previous slide)

 Part-Whole associations:

• Aggregation: part-whole relationships where the

part can exist independently of the whole (e.g., Bill
—Item)
Compiled by: Tilahun.M System
2-
Analysis and Design 01/23/2025
10
7
 Association cont..

• Composition: part-whole relationships where the

part and the whole are fully dependent on each
other (e.g., Building—Room)

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
10
8
 Types of Associations:
(2) Between objects

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
10
9
 Polymorphism
The ability of different classes to respond to same messages
in different ways. (Polymorphism = “many forms”.)

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
0
 Polymorphism cont..
The ability of different classes to respond to same messages
in different ways.

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
1
 Component
A replaceable part of a system providing a clearly
defined function through a set of interfaces

Group of classes working together toward a

common end -- a subsystem

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
2
 Component cont..

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
3
 Interface
The point of connection between different
system parts (e.g., components).

Technique by which users of a component

invoke its behaviors and manipulate its
properties

The interface is implemented by method

signatures

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
4
 2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
11
5
 Persistence
• How to store objects to permanent
storage
• The values of the objects as well as
information needed to maintain the
relationships must be saved
permanently
• Also concerned with their retrieval and
deletion
• Two types of objects exist: Persistent
2-and Transient
Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
11
6
 Persistence Tips and Techniques
• Business/domain classes are usually
persistent
• User Interface classes are usually
transitory
• You need to store both attributes and
association

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
7
Persistence
 An object occupies a memory space
and exists for a particular period of
time.
 In traditional programming, the
lifespan of an object was typically the
lifespan of the execution of the
program that created it.
 In files or databases, the object
lifespan is longer than the duration of
11 the process creating the object.
01/23/2025 This
2- Compiled by: Tilahun.M System
Analysis and Design
8
 Persistent Vs Transitory Associations
• Persistent associations are those that are
permanent
– Information to maintain it is saved
– Eg. TAKE, TEACH
• Transitory associations are not saved to
permanent storage and usually involve at
least one transitory objects
– If you are not persisting the object then you
wont be persisting its relationship with other
objects

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
11
9
 Coupling
• Measure of how much two items such as classes or
methods are interrelated
– Coupled: when one class depends on another class
– Loosely Coupled: when one class interacts with another
class but doesn’t know any of the implementation details of
the other class
– Highly Coupled: when one class relies on the
implementation of the other class
• High coupling is a major reason for maintenance
• Increasing the coupling between two items may make
sense for performance reasons
2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
12
0
 Coupling Tips and Techniques
• Avoid high coupling if you can
• Document high coupling thoroughly

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
12
1
 Cohesion
• Measure of how much an item, such as a class or
method, makes sense
• Method - Highly cohesive – it does one thing and one
thing only
– Enroll a student in a course
• Small and cohesive methods that do one thing and
one thing only are easier to understand and
maintain
• Highly cohesive class – one type of object and one
type of object only
– University Information System – Professors instead of
employees
2- Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
12
2
 Package

Group of classes sharing similar

characteristics or purposes (e.g., Sales
package, Accounting package)

2- Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
12
3
 Chapter Four

Gathering User Requirements

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Outline
• Introduction
• How to interview and brainstorm
• Indentify essential use cases
• Define and prototype your system
• Domain modeling using CRC cards
• Supplementary spec
• Modeling Room Organization

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Introduction

• The first Step – not easy

– People don’t want to spend time here
• SME ( Subject Matter Expert ) don’t want to
invest time
• Developers want to get into the “real work” of coding
• Senior Management want to see progress
– Communicate with everyone
• Use Models
– Use Case Modeling – functional tasks
– Domain Modeling – business domain concepts
– User Interface Prototyping – screen, pages, reports …
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Interviewing
• To broaden your understanding of the
application
• To determine who to invite to requirements
modeling sessions
• To identify new or existing requirements
directly for your application

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Pointers for interviewing
• Send ahead agenda
• Verify the Schedule
• Thank the person
• Let the person know his input is important
• Summarize issues
• Ask critical questions
• Ask for missing information
• Don’t Shut down users – “ I have already heard this before
• End by summarizing
• Thank the person again
• Listen than talking
• Identify “needs” vs “wants”

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Brainstorming
• Technique where group of people discuss a
topic and say anything that comes into their
minds about it.
– Rules
• All ideas are good; not judged by the group
• All ideas are owned by the group, not the individual
• All ideas immediately become public property, anybody
is allowed to expand upon them
• Make sure everyone follows the rules
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Potential Issues to discuss in
Brainstorming
• Who is this system for?
• What will they do with the system?
• Why do we do this?
• Why do we do this the way we do?
• What business needs does this system support?
• What do/will our customers want/demand from us?
• How is the business changing
• What is our compactors doing? Why? And how can we do it better?
• Do we need to do this?
• Will the system pay for itself?
• Is the work being performed where it makes most sense?
• How will peoples jobs be affected?
• How can we do this BFC?
• Etc…

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Essential Use Case Modeling
• To model behavioral requirements
• It is one of the two basic flavors
– Essential Use Case – Business/Abstract Use Case
– System Use Case – Concrete/Detailed Use Case
• Intended to capture the essence of problems
through technology free, idealized and abstract
descriptions
• Flexible
• A picture says 1,000 words

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Use Case Diagram for a Simple University

Input Marks

Grade Administrator
Enroll in
Semester

Distribute
Student Transcripts

Registrar
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Drawing Use Case Diagrams
• Collection of use cases, actors, their associations,
a system boundary box (Optional), and packages
(Optional)
• Horizontal Ellipse – Use Cases
• Stick Figures – Actors – role players
• Line – Association and Relationship
• Arrow – Initial invocation (optional)
• Rectangle around use case – Scope of the system
• File Folders – Packages (organized model
elements into groups)
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Identifying Actors
• Anything or anyone that interfaces with your system
• Including people, external systems, and other organizations
• Never part of the system
• Questions help to find actors
– Customer?
– Who obtains information?
– Who provides information?
– Who installs the system?
– Who operates the system?
– Who shuts down the system?
– What other system interacts with our system?
– Does anything happen automatically at preset time?
– Who will supply, use or remove information?
– Where does the system get information?

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Things to consider
• Actors should model roles and not the
physical, real world people.
• Actors don’t model positions
• Describe an actor by actually reflecting its role

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Document Use Cases
• Sections
– Name – purpose of the use case
– Description – summary of a use case
– Actors (optional) – associated with the use case
– Status (optional) – work in progress etc…
– Precondition – conditions that must be met
– Post condition – effect of a use case action
– Extension Points (optional) – covered later
– Included Use Cases (optional) – covered later
– Basic Course of Action – logic followed
– Alternate Course of Action – Infrequently used path
– Change History (optional) – when, who, why modified use cases

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Identifying Use Cases
• Answer the following questions
– What are users trying to accomplish
– To fulfill this role, what do users need to be able to do?
– What are the main tasks of users in this role?
– What information do users in this role need to examine,
create or change?
– What do users in this role need to be informed of by the
system and inform the system about?
• Use Case Scenario – description of a potential business
situation that may be faced by the users of a system

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Essential Use Case Description Example
Name: Enrol in Semester
Description: Enrol an existing student in a seminar for which she is eligible
Preconditions: The Student is registered at the university
Post conditions: The Student will be enrolled in the course she wants if she is eligible and room is available
Basic course of Action:
1. A Students wants to enroll in a seminar
2. The Student submits his name and student number to the registrar
3. The registrar verifies the student is eligible to enroll in semesters at the university according to some
rule
4. The student indicates, from the list of available seminars, the seminar in which she wants to enroll
5. The registrar validates the student is eligible to enroll in the semester according to the business rule
6. The registrar validates the semester fits into the existing schedule of the student
7. The registrar calculates the fees for the seminar,
8. The registrar informs the student of the fees
9. The registrar verifies the student still wants to enroll in the seminar
10. The student indicates he wants to enroll in the seminar
11. The registrar enrolls the student in the seminar
12. The registrar adds the appropriate fees to the students bill
13. The registrar provides the student with a confirmation that he is enrolled
14. The use case ends
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
10 Things to know about Essential
Use Cases
• These are just preliminary use cases
• No time ordering is indicated between use cases
• Customer actors are usually involved in may use cases
• Use Cases are not functions
• No arrowheads are on the associations
• The diagram is too big (7 +/- 2 bubbles)
• Should be functionally cohesive
• Should be temporally cohesive
• Every actor is involved with one use case and vice versa

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 UML packages
• Represents collection of use cases
• By introducing packages, the use case diagram
become simpler and easier to understand
• Each package, in turn, would be documented
by another use case diagram.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Manage Loan and Manage Seminar
Instruct Seminars Manage Fees
Grants and Registration

Enroll in
Seminar

Drop Seminar

Attend
Seminar

Finish Seminar

Notify students of
Compiled by: Tilahun.M schedule
System Analychanges 01/23/2025
sis and Design
 Alternate Course of Action
• Infrequently used path of logic in a use case
• Exception or error condition that must be handled
• Style issues
1. Includes the descriptions of actions that must be met to
invoke the alternate course
2. Identification and numbering scheme is used
3. Each step starts with the letter of the alternate course,
followed by the number of the step in the basic course of
the use case it replaces
4. The last step in each alternate course of should indicate
either that the use case ends or goes to the last step of
the Basic Course of Action

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Example of Courses of Actions
Alternate course A: The student is Not Eligible to Enrol in Seminars
A.3. The registrar determines that student is not Eligible to Enrol in Seminar
A.4 The registrar informs the student she is not eligible to enrol
A.5 The use case ends
Alternate Course B: The Student Does Not Have the Prerequisites
B.5 The registrar determines the student is not eligible to enrol in the seminar
she choose
B.6 The registrar informs the student she does not have the prerequisite
B7. The registrar informs the student of the prerequisites she needs
B8. The use case continues at Step 4 in basic course of action
Alternate Course C: The student decides not to enrol in an available seminar
C4. The student views the list of seminars and does not see one in which she
wants to enrol
C5. The use case
Compiled by: ends
Tilahun.M System Analy 01/23/2025
sis and Design
 Exercise 1.
• Name the Actors for your system
• Identify use cases
• Draw use cases
• Describe the use cases

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Essential User Interface Prototyping
• Place where user directly interacts with systems
• Low fidelity model, or prototype of the UI for your
system
• It represents the general ideas behind the UI, but not
the exact details
• Represents user interface requirements in a
technology-independent manner
• Beginning point of the user interface prototype for
your system
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Differentiating facts about essential UI prototyping

• Focus on your users and their usage of the

system, not system features
• Simple tools including whiteboards, flip chart
paper and sticky notes
• Don’t focus on the design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Tasks in Essential UI P
• Explore system usage
– Use white boards to discuss initial drawings
– Work iteratively
• Model major UI elements – flip chart paper
– Potential screens and reports
• Model minor UI elements (input fields, lists and containers)
– sticky notes
• Explore the usability of your UI
• Learnable, increase user productivity, easy to remember,
supportable
• Explore the relationship between UI elements
• User interface
Compiled flow diagramming
by: Tilahun.M System Analy 01/23/2025
sis and Design
 Example for essential UI
Student Information
Enroll Students in Seminar
Student Help
Number Requester

Student
Name
Display Course Details
Requester Course Seminar Seminar
Number Location Availability

Course Enrollment
Course Searcher Name Requester
Course
Number Course
Description
Course
Name

Search Details Professor

Requester Requester
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Prototype for a Student Transcript
Student Information
Student Number Student Phone Number Student Address Student Full Name

Student Email Period Student Status Payment Status

Amount Owed

Seminars the student ha taken during period of the transcript

Informational Message Footer Information

Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Ensuring System Usability
• Five factors affect usability
– Access : A system should be usable with out help from a person
– Efficacy: System not interfere with or impede use by a skilled worker
– Progression: facilitating advancement in knowledge, skill and facility
– Support: easy, simple, fast and fun
– Context : Real condition and actual environment

• Usability is important because

– By focusing on use and usability your system can be
simpler, smaller and less expensive
– Best systems give pleasure and satisfaction
– Unusable systems lead to request for change
– User are less patient with poorly developed applications

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Ensuring System Usability
• Five factors affect usability
– Access : A system should be usable with out help from a person
– Efficacy: System not interfere with or impede use by a skilled worker
– Progression: facilitating advancement in knowledge, skill and facility
– Support: easy, simple, fast and fun
– Context : Real condition and actual environment

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 User Interface Flow Diagramming
• Helpful to see the bigger picture
• High level interaction between the UI elements of you application
• Also called windows navigation diagrams and context navigation
maps
• Use notations that is a combination of the notation for UML
activity diagram and UML collaboration diagram
• Used for one of the two purposes
– Model the interactions that users have with your software, as defined
in a single use case.
– Gain a high level overview of the UI of your application.
• Derived from your use cases
• Gain an understanding of how the system is expected to work

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Example
: Main Menu

Use enrollment Use Transcript

requester Requester

:Enroll in :Obtain Use

Transcript :Transcript
Seminar Transcript
Requester

Use Professor Use Prerequisite

Information Details Requester
Requester

Use
:Professor Seminar :Seminar
Information Information Information
Requester
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Domain Modeling with
Class Responsibility Collaborator (CRC) Cards

• Task of discovering the classes that represent the

things and concepts pertinent to your problem space
• Nouns and noun phrases from USE CASES are good
sources for domain modeling
• A CRC model is a collection of standard index cards that
have been divided into three sections
– CLASS – collection of similar objects
– RESPONSIBILITY – something that a class knows or does
– COLLABORATOR - another class that a class interacts with
to fulfill its responsibilities

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Layout of a CRC card

CLASS NAME

Responsibilities Collaborators

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Domain Modeling with CRC
• CRC models are well suited for domain
modeling during requirement gathering
• Fundamental techniques employed for design
in the eXtreme programming (XP) software
process
• UML class diagrams are better choice for
domain modeling

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 CLASS
• Represents a collection of similar objects
• Person, Place, Thing, Event or Concept
• Eg. University System
– Students, professors, seminars
• Class names should be Singular noun or
singular noun phrase
• Class names should also be simple

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Responsibility
• Anything a class knows or does
• Eg. – Students have names, addresses and phone
numbers. (KNOWS)
• Students also enroll in seminars, drop seminars
and request transcripts (DOES)
• Classes update their own attributes and nobody
else’s
• A class may not have enough information to do
its responsibilities, need information from other
classes

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Collaboration
• Takes one of two forms
– A request for information or
– A request to do something.
• EG. – The card “Student” requests an
indication from the card “Seminar”
– A request for information
– A request to do something

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 STUDENT

Student Number
Name
Address
Phone Number SEMINAR
Enroll in Seminar
Drop a seminar
Request transcripts

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Steps in Domain Modeling by CRC cards
1. Prepare to CRC Model
– Put together a modeling group of SMEs
– Brainstorm
– Explain the CRC modeling technique
Iteratively Model CRC
– Find classes
– Find responsibilities
– Define collaborators
– Define use cases
– Move the cards around
– Prototype
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Finding Classes
• Actors are potential classes
• Identify the customer
• Follow the money
• Concepts and Events are potential classes
• Major UI elements are potential classes
• Look for three to five main classes right away
• When you think you have identified a class,
create a new card for it immediately
• You are interested in several types of classes

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 The three types of classes
1. Actor Classes – actors that appear in your use case
• People or organization
2. Business Classes – places, things, concepts, and
events that describe what the business is all about
• Concept – Course
• Event – Registration
• Place – Room
3. UI Classes – screens, menus, and reports
• The Major UI elements
• Eg. Student editing screen, registration page, student transcript

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Finding Responsibilities
• Ask yourself what a class does
– Actor Class – Identify the way in which the actor interacts with your
system
– UI Class – accept input from users, retrieve business objects, enable
users to manipulate the business objects, support creation, update,
deletion, and saving of business objects into the system
– Business Class – derived from UI classes or other business classes
(remember the context of your domain)
• Ask yourself what information you need to record about a class
– Actor Class – don’t need to identify information they know about
themselves because they are represented by their corresponding
Business Class
– UI Class – prototype describes all

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Defining Collaborators
• Collaboration must occur
– when a class needs information it doesn’t have
– When a class needs to modify information it doesn’t have
because any given classes can update only the information
it knows
• Things to consider
– There will always be at least one initiator of any given
collaboration
– Sometimes the collaborator does the bulk of the work
– Don’t pass the buck
– New responsibilities may be created to fulfill the
collaboration

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Student Enroll in course <<UI>>
Name
Address
Phone number
Email address Enrollment **See the prototype**
Enrollment
Student number
Average Mark
Record Record
Validate Info
Provide list of course

Student
Name
Address
Phone number
Email address Enrollment
Student number
Average Mark
Record
Validate Info
Provide list of course

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Advantages and Disadvantages of
CRC Modeling

 User participation in system dev’t is • Threatening to systems developers

increased • Difficult to get your SMEs together
 CRC modeling improves communications
between users and developers • You still need to do class modeling
 CRC cards are simple and inexpensive • You need management support
 CRC modeling is nonthreatening to users
 CRC cards are quick and portable
 CRC modeling goes hand in hand with essential
use case modeling and essential UI prototyping
 Gives you good overview of a system
 Leads directly into class modeling
 Enables you to deal with system complexity
one class at a time
 Promotes a common project vocabulary

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
•
Requirement
Prominently display definitions
Tips and Techniques
 Ensure that all stakeholders have a common understanding of key terms and
concepts by displaying definitions clearly.
• Expect to gather requirements throughout the entire software process
• Explain the techniques
• Allow observers
• Use several techniques simultaneously
• Use the terminology of your users
• Keep it low tech
 Simplicity can be powerful. Using basic tools like whiteboards and sticky notes
can facilitate participation and collaboration.
• Keep it fun
• Obtain management support
• Send an agenda ahead a few days before a modeling session
• Don’t be afraid to iterate
• Take a breadth first approach
• Technical support people are good sources of user requirements
• Existing documents
Compiled are a good
by: Tilahun.M source
System of requirements 01/23/2025
Analy
sis and Design
 Business Rules
• Business rules often related to
– access control issues
• Professors are allowed to input and modify the marks
of the students taking the seminars they instruct
– business calculations or operating policies and
• Converting a percentage mark that a student receives
in a course to a letter grade
– principle of your organization
• Expel any student who falls more than two courses in
the same semester
• Compiled by: Tilahun.M
sis and Design
System Analy 01/23/2025
 More on business rules
• Each business rule has an identifier
• Use format of BR#
– Enables to refer easily to business rules in other
development artifices (class models or use cases)
• A good business rule is cohesive: it describes
one and only one concept
– Increase their reusability

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Examples
• BR123 Tenured professors may administer student grades
• BR124 Teaching assistants who have been granted authority by a tenured
professor may administer student grades
• BR177 Table to convert between numeric grades and letter grades
A fully documented business rule
Name Tenured professors may administer student grades
Identifier BR123
Description Only tenure professors are granted the ability …
Example Dr. Rahel Bekele, instructor of Database Systems (INSY
432)may administer the marks of all students enrolled in that
course but not those enrolled in “Introduction to Biology(332)
Source University Policies and Procedures
Doc ID: U1701
Publication date: August 14, 2000
Related rules BR12 Qualifying to teach
BR200 Modifying Final Student Grades
Revision History Defined March
Compiled by: Tilahun.M
2, 2001 by Mr. X
System Analy 01/23/2025
sis and Design Updated October 10, 2001 by Mr. Y
 Got Questions?

The End

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Chapter Five
Object Oriented Analysis
From understanding your users and what they need to understanding the system itself

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Introduction
• Requirement Gathering and analysis are highly
interrelated and iterative
• Essential models evolve into corresponding
analysis artifacts
• Use Case Models – how your users work with
your system
• Sequence Diagrams & activity diagrams – to
flesh out and verify the logic contained in your
use cases
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Analysis Artifacts and their relationships

Essential Use
Case Model Use Case
Model

Business
Rules Sequence
Diagram
Activity
CRC Model Diagram

Class Model

User Interface
Flow Diagram

User Interface
Essential User Prototype
Interface
Compiled by: Tilahun.M
Prototype System Analy 01/23/2025
sis and Design
 System Use Case Modeling
• Difference from essential use case modeling
– High level implementation decisions
• Composed of use case diagrams and documentation describing the use
cases, actors and associations
• Describes a sequence of actions that provide a measurable value to an
actor and is drawn as a horizontal ellipse
• An actor is a person, organization or external system that plays a role in
one or more interactions with your systems
– Drawn as stick figures
• Associations between actors and classes are indicated in use case
diagrams, a relationship exists whenever an actor is involved with an
interaction described by a use case
– Exist between use cases
– Depicted as a line (arrows are optional)
• System Boundary
Compiled Box – Rectangle
by: Tilahun.M around the use cases
System Analy 01/23/2025
sis and Design
 Writing System Use Cases
• Begin with your essential use cases and modify them to reflect the
information captured within your UML sequence diagrams, activity
diagrams and user interface diagrams.
• Rework your use cases to reflect opportunities for reuse applying the UML
stereotypes of <<extend>> and <<include>>
• Two common styles exist for writing use cases
– Narrative style
• Basic and alternate courses of actions are writing one at a time
– Action Response Style
• Advantage: it is easier to see how actors interact with the system and how
the system responds
• Disadvantage: it is harder to understand the flow of logic of the use case

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Action Response Style
STUDENT SYSTEM
1. The student wants to enroll in a 3. The system verifies the student is
seminar eligible to enroll in seminars at the
2. The student inputs his name and university, according to business
student number into the system via rule
some rule 4. the system displays seminar
5. The student indicates the seminar in selection screen” which indicates
which she|he wants to enroll the list of available seminars
6. The system validates the student is
eligible to enroll in the seminar
7. The system validates the seminar fits
into the existing schedule of the
student
8. The system calculates the fees
based on the fee published in the
course catalog applicable student
fees and applicable taxes
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Reuse in Use Case Models

<<extend>>, <<include>> and

inheritance

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Registrar

Student
Enroll in <<include>> Enroll in
University Seminar

<<extends>>

Enroll International Enroll family

Student in member
University

International
Student
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Extend Associations between use cases
• The <<extend>> stereotype is used to indicate an extend association
• It is a generalization relationship where an extending use case continues the
behavior of a base use case
• Accomplishes this by conceptually inserting additional action sequences into the
base use case sequence
• When an extending use case activity sequence is completed the base use case
continues
• Alternate course of the base use case
• Introduce an extending use case when
– The logic for the alternate course of action is at a complexity level similar to that of the
basic course of action
– There is a need for an alternative course for an alternative course of action
• Extension points are placed in based use cases to indicate where the logic
of the extending use case replaces that of the base use case

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Include Associations between Use Cases

• Generalization relationship denoting the

inclusion of the behavior described by another
user case
• Invocation of a use case by another one
• Denoted by the <<include>> stereotype (label)
• Used when a use case needs the behavior of
another

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Good things to know about use case modeling

• Association between actors and use cases imply the

need for interfaces
• You should be able to exit from use case anytime
• Beware of the use case driven type of consultants
and tool vendors
• Include, extend and inheritance associations
between use cases can lead to functional
decomposition if you are not careful

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Use Case Modeling Tips and Techniques
• Write from the point of view of the actor in the active voice
• Write scenario text, not functional requirements
• Use case is neither a class specification nor a data specification
• Don’t forget the user interface
• Create a use case template
• Organize you use case diagrams consistently
• Don’t forget the system response to the actions of actors
• Alternate courses of action are important
• Don’t get hung up on <<include>> and <<extend>> associations
• Use cases drive user documentation
• Use cases drive presentations

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Sequence Diagrams
• Used to model the logic of usage scenarios
• A description of a potential way your system is used
• One entire path through a use case
• Model the flow of logic within your system in a visual manner
• The boxes across the top of the diagram represent classifiers or their
instances, typically uses cases, objects, classes or actors
• Because you can send messages to both objects and classes, objects
respond to messages through the invocation of an operation, and classes
do so through the invocation of static operations, it makes sense to
include both on sequence diagrams
• Because actors initiate and take an active part in usage scenarios, they are
also included in sequence diagrams

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Notations in sequence diagrams
• Objects – format – “name: Classname”
• Classes – format – “ClassName”
• Actors – format – “ActorName”, <<actor>>
• User Interface elements - <<UI>>
• Dashed lines – object lifelines
• Long thin boxes – method invocation boxes indicating that processing is
being performed by the target object/class to fulfill a message
• X at the bottom of a method invocation box – object have been removed
• Messages – labeled arrows
• When the source and target of a message is an object or class the label is
the signature of the method invoked in response to the message
• If either the source or target is a human actor, then the message is labeled
with brief text describing the information being communicated
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 How to draw sequence diagrams
• Identify the scope of the sequence diagram
• List the use case steps down the left hand side
• Introduce boxes for each actor
• Introduce controller classes
• Introduce a box for each major UI element
• Introduce a box for each included use case
• Identify appropriate messages for each use case step
• Add a method – invocation box for each invocation of a method
• Add destruction messages where appropriate
• Add your business classes and objects
• Update your class model
• Update your user interface model
• Update your use case model
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Why and When should you draw sequence diagrams

– Sequence diagrams are a great ways to validate

and flesh out your logic
– To document your design, at least from the point
of view of use cases
– Great mechanism for detecting bottlenecks in your
design.
– Gives a feel for which classes in your application
are going to be complex
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Conceptual Modeling: Class Diagrams
• The mainstay of OOSAD
• Uses many modeling concepts discussed in the
previous chapter
• Shows the class, interrelationship (including
inheritance, aggregation and association), and the
operations and attributes of the classes
• Start by putting the Domain Model (CRC) as a base
• While CRC modeling provides an excellent overview
of a system, it doesn’t provide the details needed to
actually build it
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Conceptual Modeling
• For each CRC model create a concrete class in the class
diagram, with the exception of cards that represent actors
• Collaborations from a user interface class implies a
dependency, whereas collaborations from business domain
classes imply either association or aggregation between the
classes
• Responsibilities are modeled as attributes and methods
• Modeling user interface classes on class diagrams often adds a
lot of clutter without adding much useful information

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Modeling Classes, Methods and Attributes
• Representation of an object, template of which objects are
created
• Modeled as rectangle with three sections
• Model your classes to an appropriate level of detail
– Eg. Take out address as a class
• Class normalization – refactoring the behavior of classes to
increase their cohesion and/or to reduce the coupling
between classes
Name
– Semester and Semester enrollment

Attributes

Compiled by: Tilahun.M System Analy Methods

01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Modeling Associations
• Objects are often associated with other objects
• Modeled as lines connecting the two classes whose instances are involved
in the relationship
• Identifying the multiplicities of an associations is an important part of
modeling it
– Cardinality and optionality
• Indicate the direction in which the label should be read
– When it is not clear which way a label should be read
• Roles may also be indicated only when the information adds value
– It is not clear from the association label what the roles are
– If there is recursive association
– if there are several associations between two classes

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Modeling Dependencies
• Are used to model transitory associations
– When one of the two classes is not persistent
• UI classes
• Dashed arrow
• Transitory classes are not three sectioned boxes
• Only indicate name of the class

EnrollInSeminar
Seminar
<<UI>>

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Documenting Class Models
• Classes – purpose, persistent/transitory, aliases,
references
• Attributes – type, example, range, references
• Methods – pseudo codes, parameters, return values,
preconditions, post conditions, reference
• Inheritance – why?
• Association – label, multiplicities, roles, reference
• Aggregation and composition – same as association

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Conceptual Class Modeling Tips
• You don’t have to get it perfect at the start
• Start at your domain model
• Evolve your class diagram via sequence diagrams
• Focus on the problem space
• Focus on fulfilling the requirements first
• Use meaningful names
• Perform object oriented analysis
• Understand and effectively apply analysis patterns
• Class model in parallel with user interface prototyping

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Activity Diagramming
• Used to model the logic of a
– single operation/method
– Single use case
– Flow of logic of a business process
• Equivalent to DFDs in structured development
• Starting point = filled circle
• Ending point = filled circle with a border
• Processes = Rounded rectangle
• Decision point = Diamond
• Transitions between activities = Arrows
• Start and End of Parallel processes = Thick bars
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 How to draw activity diagrams
• Identify the scope of the activity diagrams
• Add start and end points
• Add activities
• Add transitions from the activities
• Add decision points
• Identify opportunities for parallel activities
• Document activity diagrams

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 User Interface Prototyping
• Iterative analysis technique in which users are actively involved in
the making-up of the UI for a system
• 2 purposes
– Explore the problem space your system addresses
– Explore the solution space of your system
• 4 high level steps in UI prototyping
– Determine Needs
– Build Prototype
– Evaluate Prototype
– Determine if you are finished

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Determine the needs of Users
• Evolve all or part of your essential user interface
prototype
• Convert your hand drawings, flip chart paper and
sticky notes into something a little more substantial
• Begin this process by making platform decisions
– Browser or GUI, Java, mainframe based
• Update other models as you proceed with UI
prototyping

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Building the Prototype
• Use prototyping tool or high level language
– Screen pages
– Reports
• Don’t invest a let of time in making the code
“good” because chances are high you will
scrap large portions of your prototype code
when portions or all of your prototype fail the
evaluation

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Evaluating the prototype
• Evaluation is done by your SMEs to verify that it
meets their needs
• Three basic questions
– What is good about the UI prototype?
– What is bad about the UI prototype?
– What is missing from the UI prototype?
• 4th step
– Scrap parts of it, modify parts, and even add brand new
parts
– Stop this process when it is no longer generating new ideas
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Prototyping Tips and Techniques
• Work with the real users
• Use Prototyping tool
• Get your SMEs to work with the prototype
• Understand the underlying business
• Don’t spend a lot of time making the code good
• Only prototype features that you can actually build
• Get an interface expert to help you design it
• Explain what a prototype is
• Avoid implementation decisions as long as possible

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Next chapter Got Questions?

End of this chapter

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Chapter Six
Object Oriented Design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 WHAT IS DESIGN?
 achieving goals within constraints

 goals
 What is the purpose of the design we are intending to
produce?
 Who is it for?

 Why do they want it ?

 constraints
 What materials must we use ?
 What standards must we adopt?

 How much can it cost ?

 How much time do we have to develop it ?

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Outline
• evolve your analysis model into a design model
• layer the architecture of your system
• develop and design class model
• apply design patterns effectively
• develop state chart diagrams
• develop collaboration diagrams
• develop a component based design
• develop a deployment model
• evolve your UI prototype
• take advantage of common object design tips

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Evolve into design
• Purpose of design is to determine how you are going to
build your system

• Analysis and design are highly interrelated and iterative

• Your analysis class model evolves into your design class
model
• Decide on high level issues
– Do you intent to take a pure object oriented approach Vs
Component based approach
• Pure OO – s/w is built from collection of classes
• Component based – from components (discussed later)
– Will you follow a common business architecture
– Will you follow a common technical infrastructure

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Design Artifacts and their relationships
Use Case State Chart Persistence
Model Diagram Model

Class Model Class Model Deployment

(analysis) (design) Diagram

User Component
Collaboration
Interface Diagram
Diagram
Prototype

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Layering your models
• Organizing your software design into collections of classes or components
that fulfill a common purpose
• Qualities of a good layer
– You should be able to make modifications to any given layer without
affecting any other layers
– Layers should be modularized
• Rewriting layer or replacing
• Collaboration between classes is allowed within a layer
• By restricting the flow of messages to only one direction, you dramatically
increase the portability of your system by reducing the coupling between
class
• All types of classes may interact with system classes
– Fundamental software features such as inter-process communication
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Layering your Models
User Interface Classes

Controller/
Process Classes
System
Classes
Business/Domain Classes

Persistence Classes

Persistent
Compiled by: Tilahun.M
Store
System Analy 01/23/2025
sis and Design
 Layers
• User Interface classes – implements the major UI element of your system
• Business behaviour classes
– Business/domain classes
• Implements the concepts pertinent to your business domain such as “student” or
“seminar”
– Controller/ process classes
• Implements business logic that involves collaborating with several business domain
classes
• Persistence Classes – encapsulate the capability to store, retrieve and
delete object permanently without revealing details of the underlying
storage technology
• System Classes – provide operating system specific functionality for your
applications, isolating your software from the operating system

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 User Interface Layer
• Contains the code for the user interface part of an
application
– Choice of GUI, menu, editing screen, and report classes
• UI for any given system can take on many possible
forms even though the underlying business is still the
same .
• UI classes are often identified as part of you UI
prototyping efforts, as well as sequence modeling
• Often referred to as interface classes or boundary
classes
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 The Controller Process Layer
• Purpose is to implement business logic that
pertains to several objects, particularly objects
that are instances of different classes
• Stereotype <<controller class>>
• Rework of the sequence diagram
– Refactoring of the controller class
• to interact only with business classes
• Introduction of a new user interface class representing
the main menu
• Controller class “EnrollinSeminar”, now only manages
interactions
Compiled by: Tilahun.Mbetween
System business
Analy classes 01/23/2025
sis and Design
 Business Domain Layer
• Also called an analysis or entity class
• Subject Matter Experts (SMEs) are often the
people ho identify these classes
• The business layer enables you to encapsulate
the basic business functionality without having
to concern yourself with user interface, data
management, or system management issues

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Persistence Layer
• Provides the infrastructure for the storage and retrieval of objects
– Helps to isolate your application from changes to your permanent storage
approach
• The persistence layer, by encapsulating data management functionality,
increases the maintainability, extensibility and portability of your
application
• Message from business class layers to the persistence class layer
– “create a new object”, “retrieve this object from the database”, “update this
object” or “delete this object”
• Persistent layer provides access to permanent storage
• Goal – reduce the maintenance effort that is required whenever changes
are made to your database
• The persistence layer isolates you from the impact of changes to your
storage strategy
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 System Layer
• The system layer provides access to the operating
system and non OO resource
• Differences between operating systems can make it
tough if you are writing an application that needs to
work on many different platforms
• Wrap features of an operating system- Port an
application - You need to create classes that wrap
specific features of the operating system
• System classes encapsulate non OO functionality by
wrapping it with OO code
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Class Modeling
• The design class model will reflect the wide variety of technology
decisions you make
• Focus is on the solution domain not on the problem domain
• Introduce change to your class model based on implementation
technologies
• Implement business rules using business rules engine – your business class
will invoke the rule, instead of directly implementing them in methods
• Apply design patterns
• Improve the design quality
• Decide to take component based approach
• Persistence design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Inheritance Techniques
• The sentence rule works 99.9 percent of the time
• Beware of implementation inheritance
• Any kind of class can inherit from any other kind
• You should be able to substitute an instance of a subclass or
an instance of a super class
• Beware of multiple inheritance
• Beware of inheritance based on common data attributes
• Super classes should know nothing of their subclasses
• Factor commonality as high as possible in your class hierarchy
• A subclass should inherit everything

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Association and dependency
• Model the scaffolding for your associations
• Multiplicity must be shown
• Question multiplicities involving minimums and maximums
• Associations and dependencies are inherited
• Collaboration goes hand in hand with relationships
• Model a unidirectional association when collaboration
• Model a dependency when one of the instances is transient
• Model a dependecy when an object interacts only with a
class, but not the instance
• Do not model implied association
• The Liskov substitution principle applies to mirror hierarchies
Compiled by: Tilahun.M System
Analysis and Design 01/23/2025
 Aggregation and Composition
• The advice for association applies to aggregation and
composition
• The sentence rule should make sense for aggregation and
composition
• You should be interested in both the whole and the part
• You need to understand how the whole and the parts
collaborate with each other
• The majority of the interaction is from the whole to the
part
• Don’t confuse inheritance with aggregation
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Modeling Methods During Design
• On design class diagrams, indicate the visibility,
name, parameters, return value, and stereotype of
methods
• Names of parameters, as well as their types and
default values should be indicated for each methods
• Scope of a method, weather it is a static method that
works on the class or an instance method, that works
on instances of the class
– Static Methods are underlined, instance methods are not

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 The Student Class with its methods fully modeled

Student
name
phoneNumber
emailAddress
studentNumber
averageMark

+isEligible(name:string, studentNumber:StudentNumber):boolean
+Student(studentNumber: StudentNumber ): Student <<constructor>>
+ getCoursesTaken (): Vector
+ purchaseParkingPass()
+getAverageMark(): long
- setAverageMark (newAverageMark:long)

The UML format for an operation signature

Visibility name(param1:type1 = default1, ...): return Type <<stereotype>>

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Naming Method
• Use a full description, using mixed case with the first letter of
any non initial word capitalized
• “methodName()”
• First word – strong action verb

Example Names for member function

“Bad” Name “Good “ Name Issue

openAcc() openAccount() An abbreviation was replaced with the full word

to make the meaning clear

mailingLabelPrint() printMailingLabel() The verb was moved to the beginning of the

name to make it active

Purchaseparkingpass() purchaseParkingPass( Mixed case was applied to increase the

) readability of the name

saveTheObject() Save() The name was shortened because the term “the
Compiled by: Tilahun.M System Analy Object” did not add any value
01/23/2025
sis and Design
 Method Visibility
• How a method is accessed by objects
• Three levels of visibility
– Public, Protected and Private
• To reduce coupling within your system, the general
rule of thumb is to be as restrictive as possible when
setting the visibility of a method
– A method doesn’t have to be public, then make it
protected, if it doesn’t have to be protected make it
private

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 UML method visibilities
Visibility Symbol Description Project Usage

A public method can be When the method must be

Public + invoked by any other method accessible by objects and classes
in any other object or class outside of the class hierarchy in
which the method is defined

A protected method can be When the method provides

Protected # invoked by any method in the behaviour that is needed
class in which it is defined or internally within the class
any subclasses of that class hierarchy, but not externally

A private method can only be When the method provides

invoked by other methods in behaviour that is specific to the
Private - the class in which it is class. Private methods are often
defined, but not in the the result of refactoring
subclass
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Modeling Attributes During Design
• Indicate the visibility, name, parameter, return value
and stereotype of attributes(

)
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Modeling Attributes During Design
• Scope
– Static attribute – applicable to a class
– Instance attribute – applicable to an individual instance
• Primitive types are indicated in lowercase. Types that
are classes are indicated in mixed case
• Dependent classes implement fine grained cohesive
behaviour

Visibility name: type = initialValue <<stereotype>>

visibility name[*]: type<<stereotype>>

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Visibility Symbol Description Proper Usage

A public attribute can be accessed by

Public + any other method in any other object or Dont make attributes
public
class

A protected attribute can be accessed

Protected # by any method in the class in which it is Don't make attributes
declared or by any method defined in protected
subclasses of that class

A private attribute can only be accessed All attributes should

Private - by method in the class in which it is be private and
declared but not in the subclass accessed by getter
and setter methods

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 State Chart Modeling
• Objects know things and do things
• Some objects are incredibly more complicated
• The understand complex classes better, particularly those that act in
different manners depending on their state, you should develop one or
more UML state chart diagrams
• Depict the various states that an object may be in and the transitions
between those states
• State – stage in the behaviour pattern of an object
– Initial and final state
• Initial – creation state is the one that an object is in when it is first created
• Transition – progression from one state to another and will be triggered by
an even that is either internal or external to the object
• final state--Actions due to the events

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Here, is an example of the state diagram for
the session of ATM

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 How to draw state diagrams
• Identity the initial/creation state
• Identify the final states
• Identify as many other application, “Real
world” states as possible
• Identify potential sub states
• Identify the transition leaving a state
• Identify the target state to which a transition
leads
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 When and how state diagrams be used
• It is a dynamic modeling technique one that
focuses on identifying the behaviour within you
system

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Collaboration Diagrams
• Depict a birds eye view of the interactions between objects
• Shows the message flow between objects in an OO
application and also imply the basic associations between
classes
• Rectangle – various objects involved that make up the
application
• Lines – represent the relationships (associations, aggregation,
composition, dependencies)
• Optionally you may indicate the sequence number in which
the message

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 A collaboration diagram for a simple university
1: name:=getName()
2: getDescription() 1.1 getName()
3: getLocation()
:Seminar 1.2: getNumber()
4. getSeatsLeft() 1.3: getDescription()
Details 5: getStudentList() :Seminar :Course
<<UI>>

5.n: getInfo
5.1; getInfo
enrollmentN:
enrollment1:
Enrollment
Enrollment
Record
Record
5.n.1:getInfo
5.1.1 getInfo

studentN
Student1
: Student
: Student
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Drawing Collaboration Diagram
• With collaboration diagramming the basic idea is that
you identify
– The scope of the diagram
– The objects
– The relationships between the objects
– The messages passed between the objects
• Draw whenever you want to fully understand the
behavior of an OO application and to show the
objects that makeup the application and the message
flow between them
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Component Modeling
• OO is a preferred foundation from which to build components
• UML includes a component diagrams that can be used to
analyze and design your component based software
• Components are modeled as rectangles with two smaller
rectangles jutting out from the left hand side
• Implement one or more interfaces, modeled using the same
“lollipop” notion that UML class diagrams use
• Components have dependencies on the interfaces of other
components, modeled using the standard UML dependency
notation

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Faciliities

Security
Seminar <<infrastructure>>
Management
<<application>> Student

Persistence
<<infrastructure>>
Seminar

Student
Administration
<<application>>
University DB
Schedule <<infrastructure>>

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 How to develop a component model
• Five steps exist
1. Handle non-business/domain classes
2. Define class contracts
3. Simplify inheritance and aggregation hierarchies
4. Identify domain components
5. Define domain component contracts

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Relational Persistence Modeling
• Useful if you are using relational database
• Used as a mechanism to make your objects
persistent
• Different from the design of a class diagram
• Persistence models are often called data
models or entity relationship (ER) models –
are used to communicate the design of a
database
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
 Keys and object identifiers
• A key uniquely identifies a row in a table
• Primary key – preferred key for a data entity
• Secondary key – alternate way to access rows within a table
• Foreign key – used to maintain relationships between rows
• Use stereotypes - <<primary key>>, <<foreign key>>
• OIDs enable you to simplify your key strategy within a RDB
• Enables you to automate the maintenance of relationships
between objects.
• OID should be unique within a class hierarchy

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Mapping Objects to RDBs
• Mapping Attributes to Columns
– Attributes map to zero or more columns; zero or more attributes map
to a single column
• Mapping Classes to tables
– Not often direct (discussed later)
– Classes map to one or more tables; one or more classes can map to a
single table
• Implementing Inheritance in a Relational Database
– 3 basic choices when mapping inheritance
• Use one data entity for an entire class hierarchy
• Use one data entity per concrete class
• Use one data entity per class

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Mapping Association, Aggregation and
Composition
 Difference between association and
aggregation/composition
 The tightness the objects are bound to each other
 Aggregation/Composition - Anything you do to the
whole in the database, you almost always need to do
to the parts, not the case with association
 Implementing associations in RDB
 Maintained through the use of foreign keys
 Implementing Many to Many Associations
 Use associative table


Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
associative table
example

(paying
taxi)

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
User Interface Design
 Clean up effort - Focuses on applying
common user interface design principles
and techniques
 Complex task, on that requires a wide
range of skills to be successful
 Developers need tohave an understanding
of the basics of user interface design

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
UID principles
 The structure principle
 The simplicity principle
 The visibility principle
 The feedback principle
 The tolerance principle
 The reuse principle

Compiled by: Tilahun.M System

Analysis and Design 01/23/2025
Techniques for improving your
UID
 Consistency, Consistency, Consistency
 Set standards and stick to them
 Explain the rules
 Support both novices and experts
 Navigation between major user interface
items is important
 Navigation within a screen is important
 Word your messages and labels appropriately
 Understand your widgets
 Look at other application with a grain of salt
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
Contd...
 Use color appropriately
 Follow the contrast rule
 Align field effectively
 Expect your users to make mistakes
 Justify data appropriately
 Your design should be intuit able
 Don't create busy user interfaces
 Group things effectively

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
User interface flow diagramming
 Evolve your user interface flow diagram to
reflect the design information being
captured in your user interface prototype
and your sequence diagrams
 User interface implementation choices are
now reflected in the UI flow diagram.
GUI - <<window>> and <<dialogue
box>>
Web based - <<HTML page>>
 The types of transitions between the
various UI elements are also shown
Compiled by: Tilahun.M System Analy 01/23/2025
sis and Design
User Interface Design
Standards and Guideline
 Adopt and industry standard and modify it
as needed
 Follow and enforce the guidelines
 Obtain training in user interface design and
in the guidelines

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
Design Tips
 Focus on the problem not the technique
 Don't forget your technical infrastructure
 Document your style guideline
 Develop a technical prototype
 Requirements then analysis then design and then code
 Use Computer Aided System Engineering (CASE) tools
effectively
 Document complicated things
 Do not over document
 Design for change
 Design for your implementation environment judiciously
 Expect and act on feedback
 Indicate application of patterns

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 chapter Seven

Object Oriented Implementation and Testing

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Introduction
 For information systems of high quality to be developed, testing should be done on every

deliverable, including those created during the inception phase.

 Otherwise, less than quality systems will be delivered to the customer.

 Testing must be done systematically and the results documented so that the project team knows

what has and has not been tested.

 Software testing is a critical element of the ultimate review of specification design and coding.

 Testing is the process of executing a program to find errors. To make our software perform well it

should be error-free. If testing is done successfully it will remove all the errors from the software.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont..
 Testing is the process of finding differences between the expected behavior specified by system

models and the observed behavior of the system.

 The process of analyzing a system or system component to detect the differences between specified

(required) and observed (existing) behavior.

 When differences are found, developers identify the defect causing the observed failure and modify

the system to correct it.

 The goal of testing is to design tests that exercise defects in the system and to reveal problems.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont.…
 Software Testing is a method to check whether the actual software product matches expected

requirements and to ensure that software product is defect free.

 It involves execution of software/system components using manual or automated tools to evaluate one

or more properties of interest.

 The purpose of software testing is to identify errors, gaps or missing requirements in contrast to actual

requirements.
 Testing is checking of the system workability in an attempt to discover errors and avoiding such errors

from the system.

 Testing is a continuous activity during software development.

 In object-oriented systems, testing encompasses three levels, namely, unit testing, subsystem testing, and
system testing.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Unit Testing

 In unit testing, the individual classes are tested. It is seen whether the class attributes are

implemented as per design and whether the methods and the interfaces are error-free.
 This software testing basic approach is followed by the programmer to test the unit of the program.

It helps developers to know whether the individual unit of the code is working properly or not.
 Unit testing is the responsibility of the application engineer who implements the structure.

 Unit testing finds differences between the object design model and its corresponding component.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Subsystem Testing

 This involves testing a particular module or a subsystem and is the responsibility of the subsystem

lead.
 It involves testing the associations within the subsystem as well as the interaction of the subsystem

with the outside.

 A level of the software testing process where individual units are combined and tested as a group

or module.
 The purpose of this level of testing is to expose faults in the interaction between integrated units.

 Subsystem tests can be used as regression tests for each newly released version of the subsystem.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 System Testing
 System testing involves testing the system as a whole and is the responsibility of the quality-

assurance team.
 The team often uses system tests as regression tests when assembling new releases.

 In this method, your software is compiled as a whole and then tested as a whole. This testing

strategy checks the functionality, security, portability, amongst others.

 A level of the software testing process where a complete, integrated system/software is tested. The

purpose of this test is to evaluate the system’s compliance with the specified requirements.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Acceptance Testing
 A level of the software testing process where a system is tested for acceptability.

 The purpose of this test is to evaluate the system’s compliance with the business requirements and
assess whether it is acceptable for delivery.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Why Software Testing is Important?

 Software Testing is Important because if there are any bugs or errors in the software, it can be

identified early and can be solved before delivery of the software product.

 Properly tested software product ensures reliability, security and high performance which further

results in time saving, cost effectiveness and customer satisfaction.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 What are the benefits of Software Testing?
 Cost-Effective: It is one of the important advantages of software testing. Testing any IT project on time

helps you to save your money for the long term. In case if the bugs caught in the earlier stage of
software testing, it costs less to fix.
 Security: It is the most vulnerable and sensitive benefit of software testing. People are looking for

trusted products. It helps in removing risks and problems earlier.

 Product quality: It is an essential requirement of any software product. Testing ensures a quality

product is delivered to customers.

 Customer Satisfaction: The main aim of any product is to give satisfaction to their customers. UI

Testing ensures the best user experience.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Types of Testing

 Manual testing
 The process of checking the functionality of an application as per the customer needs without taking

any help of automation tools is known as manual testing.

 While performing the manual testing on any application, we do not need any specific knowledge of

any testing tool, rather than have a proper understanding of the product so we can easily prepare the
test document.
 Automation testing
 Automation testing is a process of converting any manual test cases into the test scripts with the help

of automation tools, or any programming language is known as automation testing.

 With the help of automation testing, we can enhance the speed of our test execution because here, we

do not require any human efforts. We need to write a test script and execute those scripts.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Types of Testing
 Stress Testing
 Integration Testing  Performance Testing
 Regression Testing  Acceptance Testing
 Smoke Testing  Usability testing
 Alpha Testing  compatibility Testing
 Beta Testing


https://www.geeksforgeeks.org/types-software-testing/
https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_testing_quality_assurance.htm
https://www.geeksforgeeks.org/software-testing-basics/
https://www.javatpoint.com/software-testing-tutorial

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 What is Inspection?
 Software inspection is a control technique for ensuring that the documentation produced during a given

phase remains consistent with the documentation of the previous phases and respects pre-established
rules and standards.
 A core technique in software quality assurance where a group of reviewers independently and

systematically examine software artifacts to find defects.

 The point of inspection is to verify that the installed equipment:

 Complies with relevant standards – this is normally a mark of certification by the installer or manufacturer

 Is the correct type and installed in accordance to the Regulations.

 Not damaged or defective which would cause a safety issue.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Software Maintenance
 Software maintenance is the process of changing, modifying, and updating software to keep up with customer needs.

 Software maintenance is done after the product has launched for several reasons including improving the software

overall, correcting issues or bugs, to boost performance, and more.

 Need for Maintenance – Software Maintenance must be performed in order to:

 Correct faults.

 Improve the design.

 Implement enhancements.

 Interface with other systems.

 Accommodate programs so that different hardware, software, system features, and telecommunications facilities

can be used.
 Retire software.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont.…
 Using the right software maintenance techniques and strategies is a critical part of keeping any software

running for a long period of time and keeping customers and users happy.
 Why is software maintenance important?

 To fix the bugs and errors in the software system.

 To improve the functionality of the software to make your product more compatible with the latest marketing and

business environments.

 To remove outdated functions from your software that is inhibiting your product efficiency.

 To improve your software performance.

 Creating a new piece of software and launching it into the world is an exciting step for any company.

 This means monitoring and maintaining properly. As technology is changing at the speed of light, software must keep

up with the market changes and demands.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Types of Software Maintenance
 The four different types of software maintenance

 Corrective Software Maintenance

 Preventative Software Maintenance

 Perfective Software Maintenance

 Adaptive Software Maintenance

 Corrective software maintenance is necessary when something goes wrong in a piece of software

including faults and errors. These can have a widespread impact on the functionality of the software in
general and therefore must be addressed as quickly as possible.
 Many times, software vendors can address issues that require corrective maintenance due to bug reports that

users send in. If a company can recognize and take care of faults before users discover them, this is an added
advantage that will make your company seem more reputable and reliable.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont.…
Preventative Software Maintenance

 Preventative software maintenance is looking into the future so that your software can keep working as

desired for as long as possible.

 This type of maintenance includes necessary modifications and updating to prevent future problems of

the software.

 Change you make to prevent the occurrence of errors in the future or introducing changes that would

protect the system from future problems.

 It goals to attend problems, which are not significant at this moment but may cause serious issues in

future.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont.…
Perfective Software Maintenance
 As with any product on the market, once the software is released to the public, new issues and ideas come

to the surface.
 Users may see the need for new features or requirements that they would like to see in the software to

make it the best tool available for their needs. This is when perfective software maintenance comes into
play.
 Perfective software maintenance aims to adjust software by adding new features as necessary and

removing features that are irrelevant or not effective in the given software.
 This process keeps software relevant as the market, and user needs, change.

 A software product needs maintenance to support the new features that the users want or to change

different types of functionalities of the system according to the customer demands.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design
 Cont.…
Adaptive Software Maintenance
 Adaptive software maintenance has to do with the changing technologies as well as policies and rules

regarding your software.

 These include operating system changes, cloud storage, hardware, etc. When these changes are

performed, your software must adapt in order to properly meet new requirements and continue to run
well.
 This includes modifications and pupations when the customers need the product to run on new platforms,

on new operating systems, or when they need the product to interface with new hardware and software.

Compiled by: Tilahun.M System Analy 01/23/2025

sis and Design