Wollo University

College of Informatics
Department of Information System

Object Oriented System Analysis and Design

(OOSAD)
Eyob Temesgen (MSc.)

1
Outline:
• Chapter 1- Introduction to System Development
– Overview of system development, types of system development approach’s?
– SDLC , System Characteristics , Software process models
• Chapter 2 -Understanding the Basics Object oriented
concepts
– Object, class, class relationship, Inheritance , abstraction, encapsulation,
polymorphism, Interface and Abstract Class
• Chapter 3- Requirement Gathering
– Collecting and organizing users requirement- WHAT- User needs
• Chapter 4- Requirement Analysis
– Analyzing and modeling requirements-WHAT System
• Chapter 5- Design, Implementation , Testing &
Maintenance

2
 System Development
System development ultimate objectives
Problem solving
Supporting processes
Participants and roles in system/software
production
– Users
– Mangers (owners)
– Analysts
– Designers
– Programmers
– Consultants
3
 Terminologies

• The product
– Information system
– Software
• The process
– System development
– Software engineering

4
 What is System?
 System is a collection of components that work together to
realize some objectives.
• Breathing system
• Solar system
• Clock
• Information System etc..

 What is Software ?
5
 Computer programs, data structures and associated documentation.
What are the attributes of good system/software?
6

• The software should deliver the required functionality and

performance to the user and should be maintainable,
dependable and acceptable.
– Maintainability
• Software must evolve to meet changing needs;
– Efficiency
• Software should not make wasteful use of system
resources;
– Dependability
• Software must be trustworthy;
– Acceptability (meet users requirement)
• Software must accepted by the users for which it was
designed.
• This means it must be understandable, usable and
compatible with other systems.
What are the attributes of good system/software?
(Cont..)

– Usability
– Users can learn it and fast and get their job done
easily
– Reliability
– It does what it is required to do without failing
– Reusability
– Its parts can be used in other projects, so
reprogramming is not needed

7
Characteristics/components of a system

 Subsystems - Input
 Interrelated components - Output
 Purpose - Interface
 Constraints - Boundary
 Characteristics/components of a system
• Interrelated components
• Dependence of one subsystem on one or more
subsystems
• Boundary
• The line that marks the inside and outside of a system
and that sets off the system form its environment
 System characteristics

• Purpose
• The overall goal or function of a system
• Environment
• Everything external to a system that interacts with the
system
• Interface
• Point of contact where a system meets its environment
or where subsystems meet each other.
 System characteristics

• Constraints
– Limit of a system that it can achieve
• Input
• Whatever a system takes from its environment in order
to fulfill its purpose
• Output
• Whatever a system returns from its environment in
order to fulfill its purpose
 Interface

Environment
Components

Input

Output
Boundary

Interrelationship
A fast food restaurant as a system: Example
Environments: customers, food distribution, banks, etc.

Storage Office

Inputs: Outputs:
Food Prepared
,labor, Kitchens food
Dining
cash, Room
etc.
Trash
Etc.
Contour

Boundary
interrelationship
 Software Development Life Cycle
 SDLC has several clearly defined phases
• Requirements Gathering What does the user want?
• Analysis Understanding/documenting requirements
• Design Planning a possible solution
• How we are going to implement the solution?
• Implementation Building a solution
• Testing the implementation Ensuring it meets
requirements
• Requirements gathering and systems analysis are
performed iteratively.
• Design/Implementation/Testing are done sequentially.
14
 Approaches to System/Software Development
 Procedural (Structural) Paradigm
 Large programs are divided into smaller programs known as
functions.
 Modeling process and data separately
 Data move openly around the system from function to function.
 Suitable for small sized software
 Object Oriented Paradigm
 Things are made up of objects
 Objects are identified having data and methods
 Is a software development strategy based on the idea of
building systems/software from reusable components called
objects
 Data is hidden and cannot be accessed by external function.

 Best suited to the broadest set of applications 15

 Object Oriented software development
paradigm
• An approach to the solution of problems in
which all computations are performed in the
context of objects.
– The objects are instances of classes, which:
• are data abstractions
• contain procedural abstractions that operate on
the objects
– A running program can be seen as a collection of
objects collaborating to perform a given task

16
 OOA & OOD
• OOA:- The procedure of identifying software
engineering requirements and developing software
specifications in terms of a software system’s object
model.
• The difference between object-oriented analysis and
other forms of analysis is that in OO approach :
 Requirements are organized around objects which
integrates
 Data
 Functions

17
 Tasks in Object oriented Analysis (OOA)
• Identifying objects
• Clarifies and document the requirements of a system
• Organizing the objects by creating object model diagram
• Defining the internals of the objects, or object attributes
• Defining the behaviour of the objects, i.e., object actions
• Describing how the objects interact
 common models used in OOA are use cases and Object
models
What are use cases?
What is object model?

18
 Object oriented Design (OOD)
(Cont..)
• involves implementation of the conceptual model produced during
object-oriented analysis.
• In OOD, concepts in the analysis model which are
technology−independent are mapped into
– implementing classes
– Implementation of associations
– constraints are identified
– interfaces are designed
Two types of OOD
 System design
 Object design
 System Design: the complete architecture of the desired system
 Object design: design model is developed based on both the models
developed in the system analysis phase and the architecture designed
19
 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 20
 Increased Reusability
• Through the concepts
– Inheritance
– Polymorphism
– Encapsulation assignment 1
– 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?
• See if you can find examples in each of your projects. 21
 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
• Provide . examples to the application of extensibility, an
advantage of OO
22
 Improved Quality
• On time, on budget, meet user expectations
• New project could re-use already tested system
with some new additional features
• Faster development of software and lower cost
of development allows more time and resources
to be used in the verification of the software.
• OO devt techniques provide greater opportunity
for users to participate in the development
process.
• Bulk requirement definitions
– Essential Use Case and CRC models 23
 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
• The reuse of software also lowers the cost of development.
• 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 BFC
can be achieved
• What were the technical benefits?
• How would the technical benefits lead to business
benefits? 24
 Increased Chance of Project Success
• Success - On time, On budget, meeting user
needs
• OO is the way to develop systems quickly and
inexpensively

25
 Reduced Maintenance Burden
• The primary goal of object-oriented development is the assurance
that the system will enjoy a longer life while having far smaller
maintenance costs.
• 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, if it exists at all
– Compared to the standards of today, legacy systems are poorly
built
• How would maintenance burden and application backlog
create problem in a system development lifecycle?
26
 Reduced Application Backlog

• 2-5 year AB exists

Project Project System

Idea Proposed Begins Released

Application Backlog Development time

Total Implementation Time

• Because OO techniques are more productive,

organizations are able to free up resources sooner to
tackle new projects
• Explain the figure in this slide.
27
 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

28
 Drawbacks of OO
• Demands up-front investments in training, education and
tools, learning curve,
• Requires a greater concentration on requirement analysis
which is often ignored in reality
• 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
• Techniques do not guarantee you will build the right
system.
•

29
 The Object Oriented Software Process Lifecycle

Deliver Maintain and Support

Initiate Construct
Define and Test in
validate
Model
Test in
the Large Release
Justify initial
requirement
the Small Support
s

Define Initial Identity Defects

Management
Define
Infrastructure
Generalize Program Rework Assess and
Documents Enhancements

Assure quality, Manage the Project, Train and Educate, Manage People, Manage Risk, Manage Reuse,
Manage Metrics, Manage Deliverables, Manage Infrastructure

30
Work flows (Phases)- in object orientation

– Basic workflows (not to stick to a single

process model or methodology)- just in
object orientation
• Each workflow is a set of activities that various
project workers perform

31
 Cont…
• The workflows are: -
– Requirements-elicitation (gathering)
• Requirement definition
– captures the functional and non functional
requirements of the new system
• Tries to understand what users need
• aims at building mainly the essential use case model
and CRC (class responsibility collaboration)
• Outcome: Understanding users through Use-case
Diagram, CRC, Essential UI prototyping , Supplementary
specification

32
 Cont…
– Analysis
• Structuring, analyzing and modeling requirements
• aims at understanding the system and building the
analysis model
• helps the developer refine and structure the functional
requirements captured through essential use-case model
• Outcome: Determining what the system should do and
look like through System Use case, Class/Object Diagram,
Sequence Diagram, Activity diagram and UI prototyping.

33
 Cont…
– Design
• Focus on how to make the analysis a reality
• defines how things will be built
• aims at building the design model
– describes the physical realisations of the use cases
from the use-case models and the contents of the
analysis model
– Outcome: Design level class diagram, Collaboration
Diagram, sate chart diagram, component diagram,
deployment diagram, persistent model; extending the
UML

34
 Software Process Models
 The models specify the stages and order of a process. So,
think of this as a representation of the order of
activities of the process and the sequence in which they
are performed.
– Waterfall model
– Agile model
– Spiral model
– Iterative model
– Incremental model
– V model
– RAD model
– Prototype model
35
Waterfall model

36
Agile

37
Factors in Choosing a Software Process
– Project requirements
– Project size
– Project complexity
– Cost of delay
– Customer involvement
– Familiarity with technology
– Project resources

38
Thank You!!

39