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
