1

CHAPTER ONE
Introduction to
Structured SAD vs OO-SAD

Mulugeta G..
 2

Definition of Basic Terms and Concepts

• System Analysis and Design

• is a study in which we learn how to analyze an existing system

and create a better one

• a standard set of activities, methods, best practices, deliverables,

and automated tools that stakeholders use to develop and

maintain information systems.
• System AD is used to analyze, design and implement
improvements in the functioning of businesses that can be
accomplished through use of computerized information systems.
 3

Definition of Basic Terms and Concepts

• System Analysis and Design

• It is based on two skills (knowledge)

• Understanding of organizations objectives, structure and process

(domain Knowledge)
• Knowledge of how to exploit information technology for advantage

• Out come of such SAD

• An application software (information systems) to improve employee

efficiency

• From the definition it is easy to understand that ‘System’,

specifically ‘information system’ is a core concept.

 4

Definition of Basic Terms and Concepts

• What exactly is a System?

• A system is an interrelated set of components with an identifiable

boundary, working together for some purpose.

• Other Important system concepts

• Living Vs Non-living systems

• Open Vs. Closed systems- depends whether the system needs to adapt to the

environment as the environment changes. Most ISs are open systems. Take a
watch as an example.
• Decomposition- being able to break down a system in to its components. It

also helps to build different parts of the system at different times or by

different individuals.
• Modularity- relatively uniform size components or chunks.
 5

Definition of Basic Terms and Concepts

• Other Important system concepts

• Coupling- the extent to which subsystems are dependent on each

other. As much as possible the subsystems should not be very

much coupled in order to.
• Cohesion- the extent to which a module or a subsystem performs a

single function. When we have highly cohesive modules each

module accomplishes one and only one function. This makes the
module reusable in future programs.
• Example: It is possible to transplant a heart or kidney.
 6

Definition of Basic Terms and Concepts

• Systems Thinking

• Is a mind set or way of viewing a world as a system

• it helps to see the big picture; it also pays to break problems

down to their components to avoid complexity.

• Minimize the effect a change in one module will have on another.

• “A system is bigger than the sum of its components”

• Example: Laptop

• It emphasize on the relationship and the process that go inside

rather than constituent part or just the sum of the parts

 7

Characteristics of a System
• Components - either a complex part or an aggregate of parts,

subsystem
• Interrelated Components - the function of one is tied to the

function of the other

• Boundary - the limits of the system with in which the system is

contained, and that separates it from other systems. Components

within the boundary can be changed.
• Purpose - The components work together to achieve some

overall purpose: the system’s reason for existence

 8

Characteristics of a System
• Environment- Everything outside the system’s boundary

• Interfaces- the point at which the system meets its environment

• Input- What the system takes in from the environment to

function
• Output - The result of the function of the system

• Constraints- limits to the system in terms of its capacity

• Example: Thinking about a car as a system helps us determine

what the problem is and fix it by breaking the system down in to

its components.
 9

Overview of Structured SAD

• Structured SAD is characterized by the following points:

• It is a top-down approach

• It is a model building activity.

• It uses unique notation to create models that represent information (data and

control) flow and content, system functionality and behavior, and depict the
essence of what must be built.
• It views a system in terms of what it is intended to do and then develop

models of procedures and data.

• It focus upon the flow of data within a system

• It is action oriented (data flow diagrams); or data oriented (entity-

relationship diagrams); but not both

 10

Overview of Structured SAD

• Some Problems of Structured Analysis and Design

• Real systems do not follow top-bottom approach

• It gives more emphasis on coding than on analysis

• The resulting system demands more maintenance cost, i.e. 56%

of the errors are made at the initial determination of users’

requirements and 81% of maintenance cost is spent on these early
requirement definition errors.
• It emphasizes more on functionality than on data which leads to

poor extendibility and modifiability.

 11

Overview of Structured SAD

• Some Problems of Structured Analysis and Design

• Systems developed using a function/data method often becomes

difficult to maintain because of its principle. All functions must

know how the data is stored (or the data structure). As a result it
becomes difficult to understand the program as we are often not
interested in data format, but only in the functionality.
• To change the data structure, we must modify all the

functions relating to the structure.

• Systems developed using such methods often become quite

unstable; a slight modification will generate major consequences.

 12

Overview of OO-SAD
• Object-oriented analysis and design (OOAD) is a software

engineering approach that models a system as a group of interacting

objects.
• Each object represents some entity of interest in the system being

modeled, and is characterized by its class, its state (data elements),

and its behavior.
• Various models can be created to show the static structure, dynamic

behavior, and run-time deployment of these collaborating objects.

• There are a number of different notations for representing these

models, such as the Unified Modeling Language (UML).

 13

Overview of OO-SAD
• Object-oriented analysis (OOA)

• Applies object-modelling techniques to analyze the functional

requirements for a system.

• Focuses on what the system does

• Object-oriented design (OOD)

• Elaborates the analysis models to produce implementation

specifications.
• Focuses on how the system does it.
 14

Overview of OO-SAD
• Object-oriented Systems

• An object-oriented system is composed of objects.

• The behavior of the system results from the collaboration of those

objects.
• Collaboration between objects involves them sending messages to

each other.
• Sending a message differs from calling a function in that when a target

object receives a message, it itself decides what function to carry out to

service that message.
• The same message may be implemented by many different functions,

the one selected depending on the state of the target object.

 15

Overview of OO-SAD
• Object-oriented Analysis

• Object-oriented analysis (OOA) looks at the problem domain,

with the aim of producing a conceptual model of the information

that exists in the area being analyzed.
• Analysis models do not consider any implementation constraints

that might exist, such as concurrency, distribution, persistence, or

how the system is to be built.
• Implementation constraints are dealt during object-oriented

design (OOD).
• Analysis is done before the Design.
 16

Overview of OO-SAD
• Object-oriented Analysis

• The sources for the analysis can be:

• Written requirements statement

• Formal vision document

• Interviews with stakeholders or

• Other interested parties.

• The result of object-oriented analysis is a description of what the

system is functionally required to do, in the form of a

“conceptual model”.
 17

Overview of OO-SAD
• Object-oriented Analysis

• Presented as a set of use cases, one or more UML class diagrams,

and a number of interaction diagrams.

• It may also include some kind of user interface mock-up.

• The purpose of object oriented analysis is

• To develop a model that describes computer software as it

works to satisfy a set of customer defined requirements.

 18

Overview of OO-SAD
• Object-oriented Design

• Transforms the conceptual model produced in object-oriented analysis to

take account of the constraints imposed by the chosen architecture and

any non-functional – technological or environmental – constraints, such
as transaction throughput, response time, run-time platform, development
environment, or programming language.
• The concepts in the analysis model are mapped onto implementation

classes and interfaces.

• The result is a model of the solution domain, a detailed description of

how the system is to be built.

 19

Overview of OO-SAD
• Object-oriented Design
• In object oriented thinking, a system is considered as a collection
of classes and objects and the relationships that tie them together.
• It de-emphasizes procedures.
• The focus shifts from modeling business processes and data
separately to combining data and procedures into objects.
• Users can more easily understand objects than traditional
representations of a system.
• Objects more accurately reflect reality in a model. Objects
reduce the “semantic gap” between reality and a model.
• Objects localize changes to the model.
• Objects are believed to more closely model the real world
• It is becoming state-of-the-art, “and it is the way of the future”.
 20

Benefits of OO-SAD
• The object method can provide the following potential
benefits
• Reusability: reduce the time and cost of writing software as well as
the incidence of defects.
• Reduced Application Backlog and Maintenance Burdon.
• Maintenance costs are lowered by reducing multiple maintenance
changes and this in turn reduces the waiting time for new projects to
be started.
• Manage Complexity by abstraction
• Tackle more challenging problems
• Improves analyst and problem domain interaction.
• Increase internal consistency across analysis, design and
programming
• Build specifications resilient to change
 21

Characteristics of Object-Oriented Systems

• Six ideas characterize object-oriented systems’ programming:

• Object: represents a real-world thing or event

• Class: group of related objects

• Messages: sent between objects

• Encapsulation: only an object makes changes through its own

behavior
• Inheritance: a new class created from another class

• Polymorphism: meaning that a derived class behavior may be

different from the base class

 22

Characteristics of Object-Oriented Systems

• Object

• is an instance or occurrence of a class

• is a person, place, event, or thing about which we want to capture

information.
• Each object has properties (or attributes) and behaviors -- things

that they can do -- which are described by methods (or operations).

• Classified into three: entity objects, interface objects and control

objects.
• do not use primary or foreign keys, instead each instance is

assigned a unique identifier (UID) when it is created.

 23

Characteristics of Object-Oriented Systems

• Class

• Is a general template we use to define and create specific instances

or objects.
• Refers to a template for a group of individual objects with
common attributes and common behavior
• The difference between an Object and a Class is that the class

defines shared attributes and behaviors of objects

 24

Characteristics of Object-Oriented Systems

 25

Characteristics of Object-Oriented Systems

• Classes are arranged in a hierarchy

• Superclasses or general classes are at the top

• Subclasses or specific classes are at the bottom

• Subclasses inherit attributes and methods from the superclasses

above them
• Classes with instances are concrete classes

• Abstract classes only produce templates for more specific classes

 26

Characteristics of Object-Oriented Systems

• Classes are arranged in a hierarchy

 27

Characteristics of Object-Oriented Systems

• Inheritance is when a new class is created from another class.
• The original class is the parent or base class.
• The new class is the child or derived class.
• The child class receives the attributes and methods of the parent
class.
• Polymorphism only occurs where there is inheritance
 28

Characteristics of Object-Oriented Systems

• Polymorphism : Many forms

• A message can be interpreted differently by different classes of

objects
• e.g. A ‘Create_Record’ message is essentially the same thing, but

causes ‘Create_Patient_Record’ by a ‘Patient_Database’ object, or

‘Create_Doctor_Record’ by a ‘Healthcare_Staff_Database’ object
• Polymorphism: meaning that a derived class behavior may be

different from the base class

 29

Polymorphism (Many Forms)

 30

Characteristics of Object-Oriented Systems

• Encapsulation

• The message is sent without considering how it will be implemented

• The object can be treated as a “black-box”

• Encapsulation changes the manner in which data is updated by programs

because data can only be changed via the services that encapsulate the data
• Helpful Hint….’Compile’
• C Classes
• O Objects
• M Methods and Messages
• P Polymorphism
• I Inheritance
• E Encapsulation
 31

Object-Oriented SDLC

• Involves the phases/processes that a software developer goes through

when developing new software.

• It consists of five basic phases:

1. System planning includes initial investigation

2. System analysis includes requirements capture/elicitation

3. System design
4. System construction and implementation includes system testing
5. System deployment
 32

Object-Oriented SDLC
• Every system development models that have been developed
incorporates these basic Phases into their model,
ex: - Waterfall Model, Iterative Model, Unified Process etc
• Waterfall Model – typical of SDLC
 33

Object-Oriented SDLC
• Iterative across life cycle phases
 34

Object-Oriented SDLC
• Spiral life cycle model
 35

Object-Oriented SDLC
• The Unified Process
 36

Object-Oriented SDLC

• The Unified Process also called iterative and incremental life cycle,

typical in object oriented approach, sees each cycle as containing five

phases:
• Inception- Establish the business case for the project

• Elaboration- Establish a project plan and a sound architecture

• Construction- Grow the system

• Transition- Testing and validating

• Production -Supply the system to its end users

• Within each phase are a number of iterations.

 37

Object-Oriented SDLC

• Five workflows cut across the set of four phases. Each workflow is a

set of activities that various project workers perform.

• The workflows are: -

• Requirements

• Aims at building the use case model

• Captures the functional requirements of the new system

• Outcome: Use-case Diagram

 38

Object-Oriented SDLC
• Analysis
• Aims at building the analysis model
• Helps the developer refine and structure the functional
requirements captured within the use-case model
• Outcome: Class/Object Diagram, Sequence/Collaboration Diagram
• Design
• Aims at building the design model
• Describes the physical realizations of the use cases from the use-
case models and the contents of the analysis model
• Outcome: Sequence/Collaboration Diagram, Interfaces and
Classes, extending the UML
• Aims at building the deployment model
 39

Object-Oriented SDLC

• Aims at building the deployment model

• Defines the physical organization of the system in terms of

computational nodes (geographical locations)

• Defines how things will be built
• Outcome: Deployment diagram

• Implementation

• Aims at building the implementation model

• Describes how elements of the design model are packaged into

software components, i.e. source code etc

• Outcome: Component diagram
 40

Object-Oriented SDLC

• Test

• Performs unit, integration and system tests

• Use test cases, that are derived directly from use-cases

• Types: black-box testing and white box testing

• Deployment

• Defines how system will be built and put into operation

• Uses the deployment model built during the design workflow

• Provide for a smooth transition from the old system to the newly

constructed system
 41

Object-Oriented SDLC
Inception
• it’s the first of five phases.
• This phase has several goals:
• To describe the initial requirements
• To develop and justify the business case for the system
• To determine the scope of your system
• To identify the people, organizations, and external systems that will
interact with your system
• To develop an initial risk assessment, schedule, and estimate for
your system
• To develop an initial tailoring of the Unified Process to meet your
exact needs
 42

Object-Oriented SDLC
Elaboration
• The Elaboration phase has the following goals:

• To produce a proven, architectural baseline for your system

• To progress your requirements model to the "80% completion

point"
• To develop a coarse-grained project plan for the entire Construction

phase
• To ensure that the critical tools, processes, standards, and

guidelines have been put in place for the Construction phase

• To understand and eliminate the high-priority risks of your project
 43

Object-Oriented SDLC
Construction
• The Construction phase has several goals:
• To describe the remaining requirements
• To flesh out the design of your system
• To ensure that your system meets the needs of its users and fits into
your organization’s overall system portfolio
• To complete component development and testing, including both
the software product and its documentation
• To minimize development costs by optimizing resources
• To achieve adequate quality as rapidly as possible
• To develop useful versions of your system
 44

Object-Oriented SDLC
Transition
• The team will focus on testing and validating your complete system
• Final product baseline (also known as a production baseline) of your
system
• Training materials for your system
• Documentation, including user manuals, support documentation, and
operations documentation
• The phase is concluded with the Product Release milestone.
• To pass this milestone you must show that your users are satisfied
with the system and that show that the actual expenditures versus the
planned expenditures are still acceptable.
 45

Object-Oriented SDLC
Production
• Here you will focus on operating your system and supporting your
users working with it.
• This includes
• monitoring the system and acting appropriately to ensure continued
operation;
• operating and maintaining relevant jobs, logs, and supporting
systems;
• responding to help requests, error reports, and feature requests by
users; and
• managing your change control process so that defects and new
features may be prioritized and assigned to future releases.
• Appropriate metrics summarizing system usage, system performance,
and user satisfaction
 46

?
END OF CHAPTER ONE
Next: Chapter Two: Modeling using UML