3/25/2023

Chapter Content
Chapter One: Introduction Introduction Object oriented system
development methodology.
Software development  Why an object oriented
process models  Overview of the unified
approach.
Course Title: Software Engineering Software Process  An object-oriented
Software life cycle philosophy
 Basic concepts of an object
and process models Attributes of an object, its state
and properties.

Instructor: Belilign Teferi

3/25/2023 Chapter One: Introduction 2

1.1 Introduction: Overview of Software

Introduction: Characteristics of software
Definition
To gain more understanding of software, it is important
1.Software is instructions on computer programs to examine its characteristics that make it different
that when executed provide desired function and from hardware.
performance  When hardware is built the human creative process
2.Software is a data structure that enables the (analysis, design, construction, testing) is ultimately
instructions to adequately manipulate information translated into a physical form. If we build a new
computer, our initial sketches, formal design
3.Software is a document that describes the drawings, and bread boarded prototype evolve into a
operations and use of instructions physical product (chips, circuit boards, power supplies
etc.). Software is a logical system than physical one.
Therefore, it is obvious that software has different
characteristics compared to hardware:

3/25/2023 Chapter One: Introduction 3 3/25/2023 Chapter One: Introduction 4

 3/25/2023

Characteristics of software… Characteristics of software contd..

Software is developed or engineered; it is not

manufactured in the classical sense. The failure rate for hardware depicted by a “bathtub
In both software development and hardware manufacturing curve”
high quality is achieved through good design, but the  indicates that hardware exhibits relatively high failure rates
manufacturing phase for hardware can introduce quality early in its life (these failures are often attributable to design or
problems that is nonexistent ( or easily corrected) for manufacturing defects); defects are corrected and the failure
software. rate drops to a steady state level ( ideally quite low) for some
Both activities are dependent on people, but the period of time.
relationship between people applied and work  But as time passes the failure rate rises again as hardware
accomplished is entirely different. components suffer from the cumulative effects of dust,
Both activities requires the construction of a “product” but vibration, abuse, temperature extremes, and many other
the approaches are different environmental maladies. Simply the hardware begins to wear
Software costs are concentrated in engineering. This means out
that software projects cannot be managed as if they were  Unlike hardware, software is not susceptible to the
manufacturing projects environmental maladies that cause hardware to wear out

3/25/2023 Chapter One: Introduction 5 3/25/2023 Chapter One: Introduction 6

Characteristics of software contd.. Characteristics of software contd..

Failure Rate :idealized curve

The failure rate curve for software should take the  Before the curve can return to the original steady-state failure
form of the “idealized curve” rate, another change is requested, causing the curve to spike
 The curve indicates that undiscovered defects will cause high again. Slowly, the minimum failure rate level begins to rise.
failure rates early in the life of a program. Hence the software is deteriorating due to change
 However, these are corrected (ideally without introducing
other errors) and the curve flattens as shown. The idealized
curve is a gross oversimplification of actual failure models for
software.
 Generally, software doesn’t wear out rather it deteriorates.
During its life software will undergo change (maintenance). As
changes are made, it is likely that some new defects will be
introduced, causing the failure rate curve to spike as shown in
the actual curve shown below

3/25/2023 Chapter One: Introduction 7 3/25/2023 Chapter One: Introduction 8

 3/25/2023

Characteristics of software contd.. Characteristics of software contd..

When a hardware component wears out, it is replaced

Bathtub Curve Idealized curve by a spare part. There are no software spare parts.
Every software failure indicates an error in design or in
increased failure
rate due to side effects the process through which design was translated into
Failure
rate machine executable code. Therefore, software
maintenance involves considerably more complexity
change
that hardware maintenance
actual curve

idealized curve

Time

3/25/2023 Chapter One: Introduction 9 3/25/2023 Chapter One: Introduction 10

1.2. Software Development Process Models 1.2.1 History of Software Development

System Development refers to all activities that go into Early stage

producing an information systems solution.  In the early days of computing, software development was mainly a
single-person task.
System development activities consists of system
 The problem to be solved (very often of a mathematical nature) was
analysis, modeling, design, implementation, testing and well understood, and there was no distinction between the
maintenance. programmer and the end user of the application (software).
A software development methanoyl is a series of  The end users (very often a scientist or an engineer) developed their
own software
processes that, if followed , can lead to the
development of an application.  The application, by today’s standards, was rather simple. Thus software
development consisted only of coding in some low level language.
The software process describe how the work is to be  They code and fix method
carried out to achieve the original goal based on the
system requirements. Further each process consists of
a number of steps and rules that should be performed
during development.

3/25/2023 Chapter One: Introduction 11 3/25/2023 Chapter One: Introduction 12

 3/25/2023

History of … History of …

New software development age

Code and Fix model  As hardware capacity grew, the desire to apply computers in more
 It’s a development process that is neither precisely formulated application domains, such as business administration, let to
nor carefully controlled. software being used in less and less understood environments.
 A sharp separation arose between software developers and end
 Software production in this model consists of the iteration of two users. End users with little or no technical background in science
steps and mathematics, such as sales agents and personnel
 Write the code and administrators, could not be expected to develop their own
 Fix it to eliminate errors, enhance existing functionality, or add applications, due to both
new features  Software is developed not for personal use, but for people with
little or no back ground in computers. Sometimes software is
 This model is weak. developed in response to a request from a specific customer; other
 In particular, after a sequence of changes, the code structure becomes times , it is developed for the general market. Both of these
so messy that subsequence fixes become harder to apply and the situations add new dimensions to the software that were not
results become less reliable. present in the previous age. Now software is a product that must be
 These problems, however, were not that much serious by the fact that
marketed, sold and installed on different machines at different
sites. Users must be trained in its use and must be assisted when
software were rather simple and the application were well understood something unexpected happens.
by the engineers.

3/25/2023 Chapter One: Introduction 13 3/25/2023 Chapter One: Introduction 14

History of … History of …

New software development age New software development age

 Software is developed not for personal use, but for people  Another sharp difference from the previous age is that
with little or no back ground in computers. software development has become a group activity. Group
work requires carefully taught-out organizational structures
 Sometimes software is developed in response to a request and standard practices, in order to make it possible to predict
from a specific customer; other times , it is developed for the and control developments.
general market.  The code and fix process model was inadequate to deal with
the new software age.
 Both of these situations add new dimensions to the software
 First, the increased size of the systems being developed
that were not present in the previous age. made it difficult to manage the complexity in an
 Now software is a product that must be marketed, sold and unstructured way.
installed on different machines at different sites. Users must  This problem was made worse by the turnover of software
personnel working on projects.
be trained in its use and must be assisted when something
 Adding new people to an ongoing project was extremely
unexpected happens. difficult because of the poor documentation available to
guide them in the task of understanding the application
properly.

3/25/2023 Chapter One: Introduction 15 3/25/2023 Chapter One: Introduction 16

 3/25/2023

History of … History of …

New software development age New software development age

 Inadequacy of the code and fix process model…  The failure of the code and fix process model led to the recognition
 Second, fixing code was difficult because no anticipation of change of the so-called software crisis (caused by the fact that large
was taken into account before the start of coding. Similarly it was software projects were universally over budget and behind
difficult to remove errors that required major structuring of the
existing code. These problems underscored the need for the schedule) and, in turn, contribute to the birth of software
design phase prior to coding engineering as a discipline (to address software crisis).
 Another problem that makes the code and fix process model
inadequate to the new age is that frequent discovery, after the Software Crisis
system is developed, that the software did not match the user’s  It is also known as software affliction
expectations. So the product either was rejected or had to be
redeveloped to achieve the desired goals. Software development  The term includes a set of problems that are encountered in the
becomes a sort of never ending activity. development of computer software. The problems are not limited
 As a result, the development process was unpredictable and to software that doesn’t function properly. Rather, the affliction
uncontrollable, and products were completed over schedule and encompasses problems associated with how we develop software,
over budget and did not meet quality expectations. Consequently,
it was realize that a more detailed and careful analysis of the how we maintain a growing volume of existing software and how
requirements necessary before design and coding started. we can keep pace with the growing demand for more software.

3/25/2023 Chapter One: Introduction 17 3/25/2023 Chapter One: Introduction 18

History of … History of …
 Software Crisis
 Software Crisis
 Causes:
 Problems: 1. Software is a logical rather than a physical system element; therefore,
success is measured by the quality of a single entity rather than by the
1. Schedule and cost estimates are often grossly inaccurate. quality of many manufactured entities.
2. The “productivity” of software people hasn’t kept pace with 2. The intellectual challenge of software development is certainly one cause of
the affliction that affects software but the problems discussed above have
demand for their services. been caused by more mundane human failings.
3. The quality of software is sometimes less than adequate 3. A good manager can manage any project. If he or she is willing to learn
milestones that can be used to measure progress, apply effective methods
4. With no solid indication of productivity, we can’t accurately of control, disregard mythology and become conversant in rapidly changing
evaluate the efficiency of new tools, methods or standards technology.
4. Communication between managers and customers, software developers,
5. The software maintenance task devours the majority of all support staff etc. can break down because the special characteristics of
software cost software and the problems associated with its development are
misunderstood
5. The software people responsible for tapping that potential often change
when is discussed and resist change when it is introduced

3/25/2023 Chapter One: Introduction 19 3/25/2023 Chapter One: Introduction 20

 3/25/2023

1.2.2 Software processes and Models Software processes…

From the era of software crisis it was learnt that having structured process Software processes in software engineering refer to the methods
models for system developments is a must to bring change in the software and techniques used to develop and maintain software.
development industry. It then became the birth of Software Engineering as a
discipline. In software engineering, a software development process is a
process of dividing software development work into smaller, parallel,
What is Software Engineering?
or sequential steps or sub-processes to improve design and/or
1. is the field of computer science that deals with the building of software product management. It is also known as a software development
systems that are so large or so complex that they are built by a team or
teams of engineers. Usually these systems exist in multiple versions and
life cycle (SDLC) or Model.
are in service for many years. During their life time, they undergo many To solve actual problems in an industry setting, a software engineer
changes: to fix defects, to enhance existing features, to add new or a team of engineers must incorporate a development strategy
features, to remove old features or to be adapted to run in a new that encompasses the process, methods and tools layers required to
environment. solve the problem. This strategy often referred to as a process model
2. More precisely, the IEE STD 610.12-1990’s standard glossary for or a software engineering paradigm.
software engineering terminology (ANSI) defines software engineering s
the application of systematic, disciplined quantifiable approach to the
development, operation and maintenance of software.

3/25/2023 Chapter One: Introduction 21 3/25/2023 Chapter One: Introduction 22

Software processes… Software processes…

A software process model is an abstraction of the actual process, There are various types of software process models
which is being described. It can also be defined as a simplified
representation of a software process. Each model represents a for software Engineers to choose from, taking factors
process from a specific perspective. Basic software process
models on which different type of software process models can such as budget, requirement nature, technology used,
be implemented: complexity of the problem etc. into consideration.
Boehm [1988] the goal of structured process models for system  Waterfall Model
development are to determine the order of stages involved in
software development evolution, and to establish the transition  Incremental Process Models( the incremental model and the RAD model)
criteria for progressing from one stage to the next. These include  Evolutionary Models(prototyping, the spiral model and concurrent
completion criteria for the current stage plus choice criteria and development Model)
entrance criteria for next stage. According to this view point,
 Specialized Process Models (component based development, formal
process models have a twofold effect:
methods model and aspect oriented software development)
 They provide guidance to system development on the order in which
the various technical activities should be carried out within a project  Unified Process Model
 They provide framework for managing development and maintenance,  Agile Process Models( scrum, XP, TDD and FDD )
in that they enable us to estimate resources, define intermediate
milestones, and monitor progress.

3/25/2023 Chapter One: Introduction 23 3/25/2023 Chapter One: Introduction 24

 3/25/2023

Software processes… Software processes…

Waterfall Model Waterfall Model: processes
 It was introduced by Winston Royce in 1970 and is currently the most  Requirement Gathering: All possible requirements of the system to be
commonly used model for software development developed are captured in this phase.
 It is also referred to as a linear-sequential life cycle model.
 Requirement analysis and Specification ( what to solve) : All collected
 It is very simple to understand and use. requirements are analyzed, modeled and documented in a requirement
 It is based on developing software in a set of sequential phases. specification doc. Some of the things to be done in this phase are
 Each phase must be completed before the next phase can begin and  Identifying the functional ( what the product does) and the non functional
there is no overlapping in the phases requirements ( qualities that the product has to posses)
 Expressing the functionalities and behaviors using models
 It is the most straight forward model and it is document driven ( at the  Defining requirements for system test procedure
end of each phase a document is produced that will be used in the next  System Design (How to solve): The requirement specifications from first
phase) phase are studied in this phase and system design is prepared. System
 It views software development as series of processes that are expected Design helps in
to be done only once for the project. They are to be done in the proper  Specifying hardware and system requirements
order and the results are  Defining High level/architectural design: deals with overall module structure and
organization, rather than the details of the modules
 One of the most critical features of the Waterfall Model is that the phases do  Detailed design: High level design is refined by designing each module in detail.
not overlap.

3/25/2023 Chapter One: Introduction 25 3/25/2023 Chapter One: Introduction 26

Software processes… Software processes…

Waterfall Model: processes.. Waterfall Model: processes..
 Implementation or coding: With inputs from system design, the system is  Maintenance: There are some issues which come up in the client
first developed in small programs called units, which are integrated in the environment. To fix those issues patches are released. Also to enhance the
next phase. Each unit is developed and tested for its functionality which is product some better versions are released. Maintenance is done to deliver
these changes in the customer environment. It is actually a lifelong process
referred to as Unit Testing. and considered as the most costly phase of the model. Maintenance can
 Integration and Testing: All the units developed in the implementation be in either of the three forms below
phase are integrated into a system after testing of each unit. Then the  Integration and Testing: All the units developed in the implementation
entire system is tested for any faults and failures. The system is tested by phase are integrated into a system after testing of each unit. Then the
using the requirement specification document released at the early stage. entire system is tested for any faults and failures. The system is tested by
Testing can be carried out by different ways using the requirement specification document released at the early stage.
 Alpha testing: Carried out by test team inside the organization Testing can be carried out by different ways
 Beta testing: Performed by a selected group of friendly customers  Alpha testing: Carried out by test team inside the organization
 Beta testing: Performed by a selected group of friendly customers
 Acceptance testing: Performed by the customers who finance the product  Acceptance testing: Performed by the customers who finance the product
 Deployment of system: Once the functional and non functional testing is  Deployment of system: Once the functional and non functional testing is
done, the product is deployed in the customer environment or released done, the product is deployed in the customer environment or released
into the market. into the market.

3/25/2023 Chapter One: Introduction 27 3/25/2023 Chapter One: Introduction 28

 3/25/2023

Software processes… Software processes…

Pros and Cons of Waterfall Model
Pros Cons

 Simple and easy to understand and use  No working software is produced until late during the life cycle.
 Easy to manage due to the rigidity of the  High amounts of risk and uncertainty.
model.  Not a good model for complex and object-oriented projects.
 Each phase has specific deliverables and  Poor model for long projects.
a review process.  Not suitable for the projects where requirements are at a
 Phases are processed and completed one moderate to high risk of changing. So risk and uncertainty is high
at a time. with this process model.
 Works well for smaller projects where  It is difficult to measure progress within stages.
requirements are very well understood.  Cannot accommodate changing requirements.
 Clearly defined stages.  No working software is produced until late in the life cycle.
 Well understood milestones.  Adjusting scope during the life cycle can end a project.
 Easy to arrange tasks.  Integration is done as a "big-bang. at the very end, which doesn't
 Process and results are well allow identifying any technological or business bottleneck or
documented. challenges early.
3/25/2023 Chapter One: Introduction 29 3/25/2023 Object Oriented System Analysis and Design 30

Software processes… Process Models……: Prototyping

When should we use waterfall Model?

The Software Prototyping refers to building software
Every software developed is different and requires a application prototypes which display the functionality
suitable SDLC approach to be followed based on the internal of the product under development but may not actually
and external factors. Some situations where the use of hold the exact logic of the original software.
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed.
Software prototyping is becoming very popular as a
 Product definition is stable. software development model, as it enables to
 Technology is understood and is not dynamic. understand customer requirements at an early stage of
 There are no ambiguous requirements. development.
 Ample resources with required expertise are available to support the
product. It helps get valuable feedback from the customer and
 The project is short. helps software designers and developers understand
 Works well for projects that are repeats of earlier works like new about what exactly is expected from the product under
versions of a software development
 Quite suitable for developing products with which the development
team have experience with similar projects.

3/25/2023 Object Oriented System Analysis and Design 31 3/25/2023 Object Oriented System Analysis and Design 32
 3/25/2023

Process Models…… Prototyping: Dimension

Process Models……: Prototyping

 Horizontal prototype displays the user interface for the

Prototype is a working model of software with some product and gives a broader view of the entire system,
limited functionality. without concentrating on internal functions.
The prototype does not always hold the exact logic  are used to get more information on the user interface level
used in the actual software application and is an extra and the business requirements. It can even be presented in
effort to be considered under effort estimation. the sales demos to get business in the market.
Prototyping is used to allow the users evaluate  Vertical prototype on the other side is a detailed
developer proposals and try them out before elaboration of a specific function or a sub system in the
implementation. product.
It also helps understand the requirements which are  technical in nature and are used to get details of the exact
user specific and may not have been considered by the functioning of the sub systems. For example, database
developer during product design requirements, interaction and data processing loads in a
given sub system.

3/25/2023 Object Oriented System Analysis and Design 33 3/25/2023 Object Oriented System Analysis and Design 34

Process Models…….Phases in Prototyping Process Models…… Types of software Prototyping

 Basic Requirement Identification: involves understanding the very basics product  Throwaway/Rapid Prototyping: Throwaway prototyping is also
requirements especially in terms of user interface. The more intricate details of the called as rapid or close ended prototyping. This type of
internal design and external aspects like performance and security can be ignored at
this stage. prototyping uses very little efforts with minimum requirement
 Developing the initial Prototype: The initial Prototype is developed in this stage, analysis to build a prototype. Once the actual requirements are
where the very basic requirements are showcased and user interfaces are provided. understood, the prototype is discarded and the actual system is
These features may not exactly work in the same manner internally in the actual developed with a much clear understanding of user
software developed and the workarounds are used to give the same look and feel to requirements.
the customer in the prototype developed.
 Review of the Prototype: The prototype developed is then presented to the customer
and the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under  Evolutionary Prototyping: Evolutionary prototyping also called
development. as breadboard prototyping is based on building actual
 Revise and enhance the Prototype: The feedback and the review comments are functional prototypes with minimal functionality in the
discussed during this stage and some negotiations happen with the customer based on beginning. The prototype developed forms the heart of the
factors like, time and budget constraints and technical feasibility of actual future prototypes on top of which the entire system is built.
implementation. The changes accepted are again incorporated in the new Prototype
developed and the cycle repeats until customer expectations are met. Using evolutionary prototyping only well understood
requirements are included in the prototype and the
requirements are added as and when they are understood.

3/25/2023 Object Oriented System Analysis and Design 35 3/25/2023 Object Oriented System Analysis and Design 36
 3/25/2023

Process Models…… Types of software Prototyping

 Incremental Prototyping: Incremental prototyping

refers to building multiple functional prototypes of Quick

the various sub systems and then integrating all the plan

available prototypes to form a complete system.

communication

Modeling

 Extreme Prototyping: Extreme prototyping is used in

Quick design

the web development domain. It consists of three

sequential phases. First, a basic prototype with all the
existing pages is presented in the html format. Then Deployment Fig: Evolutionary
the data processing is simulated using a prototype delivery &
feedback Construction
Prototype

services layer. Finally the services are implemented

of prototype

and integrated to the final prototype. This process is

called Extreme Prototyping used to draw attention to
the second phase of the process, where a fully
functional UI is developed with very little regard to
the actual services.
3/25/2023 Object Oriented System Analysis and Design 37 3/25/2023 Object Oriented System Analysis and Design 38

Fig: Throwaway Prototype Pros and Cons of prototyping

Pros Cons
Requirement Elicitation
or Gathering  Increased user involvement in the product  Risk of insufficient requirement analysis owing

Quick Prototype Design even before implementation to too much dependency on prototype
 Since a working model of the system is  Users may get confused in the prototypes and
Prototype displayed, the users get a better understanding actual systems.
Implementation
of the system being developed.  Practically, this methodology may increase the
Prototype Evaluation
By Customer  Reduces time and cost as the defects can be complexity of the system as scope of the
detected much earlier. system may expand beyond original plans.
REQUIREMENTS FOR
Requirements NO CORRECTIONS, CHANGES
Fulfilled ?
 Quicker user feedback is available leading to  Developers may try to reuse the existing
AND ADDITIONS
YES better solutions. prototypes to build the actual system, even
System Design , Coding
and Testing  Missing functionality can be identified easily when its not technically feasible
 Confusing or difficult functions can be  The effort invested in building prototypes may
System Deployment
identified be too much if not monitored properly
SYSTEM OPERATION
AND MAINTENANCE

3/25/2023 Chapter One: Introduction 39 3/25/2023 Object Oriented System Analysis and Design 40
 3/25/2023

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

In Incremental model, iterative process starts with a Iterative process starts with a simple
simple implementation of a small set of the software implementation of a subset of the software
requirements and iteratively enhances the evolving
versions until the complete system is implemented requirements and iteratively enhances the
and ready to be deployed. evolving versions until the full system is
An iterative life cycle model does not attempt to implemented.
start with a full specification of requirements. At each iteration, design modifications are made
Instead, development begins by specifying and and new functional capabilities are added.
implementing just part of the software, which is then
reviewed in order to identify further requirements. The basic idea behind this method is to develop a
This process is then repeated, producing a new system through repeated cycles (iterative) and in
version of the software at the end of each iteration of smaller portions at a time (incremental).
the model.

3/25/2023 Object Oriented System Analysis and Design 41 3/25/2023 Object Oriented System Analysis and Design 42

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

Iterative and Incremental development is a During each iteration, the development module goes
combination of both iterative design or iterative through the requirements, design, implementation and
method and incremental build model for testing phases
development. Each subsequent release of the module adds function
to the previous release.
 "During software development, more than one
The process continues till the complete system is ready
iteration of the software development cycle may as per the requirement.
be in progress at the same time." and "This The key to successful use of an iterative software
process may be described as an "evolutionary development lifecycle is rigorous validation of
acquisition" or "incremental build" approach." requirements, and verification & testing of each version
In incremental model the whole requirement is of the software against those requirements within each
cycle of the model.
divided into various builds.

3/25/2023 Object Oriented System Analysis and Design 43 3/25/2023 Object Oriented System Analysis and Design 44
 3/25/2023

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

The advantage of this model is that there is a working

model of the system at a very early stage of
development which makes it easier to find functional or
design flaws. Finding issues at an early stage of
development enables to take corrective measures in a
Fig: Incremental limited budget.
Model
The disadvantage with this SDLC model is that it is
applicable only to large and bulky software
development projects. This is because it is hard to
break a small software system into further small
serviceable increments/modules.

3/25/2023 Object Oriented System Analysis and Design 45 3/25/2023 Object Oriented System Analysis and Design 46

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

Pros Cons
 Some working functionality can be developed quickly  More resources may be required. Pros Cons
 Although cost of change is lesser but it is  With every increment operational product is delivered.  Not suitable for smaller projects.
and early in the life cycle.
not very suitable for changing  Issues, challenges & risks identified from each increment can be  Management complexity is more.(
 Results are obtained early and periodically.
requirements. utilized or applied to the next increment.
unknown schedules, budgets and
 Parallel development can be planned.  Risk analysis is better.
 More management attention is required. deliverables)
 Progress can be measured.  It supports changing requirements.
 System architecture or design issues may
 End of project may not be known,
 Less costly to change the scope/requirements. arise because not all requirements are
 Initial Operating time is less.
Better suited for large and mission-critical projects. which is a risk.
 Testing and debugging during smaller iteration is easy. gathered in the beginning of the entire life 

cycle.
 During life cycle software is produced early which facilitates  Highly skilled resources are required
 Risks are identified and resolved during iteration; and
 Defining increments may require definition customer evaluation and feedback. for risk analysis.
each iteration is an easily managed milestone.
of the complete system.
 Budget is spread in to the versions so that initial delivery costs  Project’s progress is highly dependent
 Easier to manage risk - High risk part is done first.
are much lower
upon the risk analysis phase.

3/25/2023 Object Oriented System Analysis and Design 47 3/25/2023 Object Oriented System Analysis and Design 48
 3/25/2023

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

When is best to Use incremental model? When is best to Use incremental model?
Requirements of the complete system are clearly defined
and understood. There are some high risk features and goals which may
change in the future (when it is too risky to develop the
Major requirements must be defined; however, some
functionalities or requested enhancements may evolve with overall system as one block).
time. (some requirements may change during the project With software applications that are regarded by the users
life cycle)
with doubt. Early increments can create the necessary early
With lengthy projects. consensus on the usefulness of the application.
There is a time to the market constraint.
When there is budget constraint to complete the whole
A new technology is being used and is being learnt by the
development team while working on the project. project once
Resources with needed skill set are not available and are
planned to be used on contract basis for specific iterations.

3/25/2023 Object Oriented System Analysis and Design 49 3/25/2023 Object Oriented System Analysis and Design 50

1.3. Object Oriented Information System

Development Methodology
1.3.1 Orthogonal View of a software
Information systems are an outgrowth of a process of
organizational problem solving. An information system is
built as a solution to some type of problem or set of Two Approaches, exist to develop a software
problems the organization perceives it is facing. system :Traditional Approach (structured view)
Systems development refers to all the activities that go into &Modern Approach(Objected-Oriented View)
producing an information systems solution to an The traditional approach views a system as a
organization problem or opportunity. collection of programs where as the object oriented
System development activities consists of system analysis, view consider a systems as a collection of
modeling, design, implementation, testing and interacting objects.
maintenance.
A software development methodology is a series of
processes that, if followed , can lead to the development of
an application

3/25/2023 Object Oriented System Analysis and Design 51 3/25/2023 Chapter One: Introduction 52
 3/25/2023

1.3.2 System Development Paradigm System development

Depending on how we view the system the system development Traditional Approach( Structured Approach)
approach also can be structured or object oriented approach.  Views a system in terms of what it is intended to do and
The Structured Approach then develop models of procedures and data.
 Views a system in terms of what it is intended to do and then  Is a strategy based on the concept that a system should
develop models of procedures and data. be separated into two parts: data(modeled using a
 Is a strategy based on the concept that a system should be data/ persistence model) and functionality( modeled
separated into two parts: data(modeled using a data/ using a process model)
persistence model) and functionality( modeled using a
process model)
 Structured methods are: Action oriented (data flow
diagrams); or Data oriented (entity-relationship
 Structured methods are action oriented (data flow diagrams);
diagrams); But not both
or data oriented (entity-relationship diagrams); But not both
 Therefore using structured approach we develop applications  Therefore using structured approach we develop
in which data are separated from behavior in both the design applications in which data are separated from behavior
model and implementation phase. in both the design model and implementation phase.

3/25/2023 Object Oriented System Analysis and Design 53 3/25/2023 Object Oriented System Analysis and Design 54

System development.. OO system development..

OO Approach
Modern Approach: OO software development
 In the 1990s, Coad incorporated behavioral ideas to object-
Methodology oriented methods.
 Took its shape from the initial concept of a new programming  The other significant innovations were Object Modelling
approach, while the interest in design and analysis methods came Techniques (OMT) by James Rumbaugh and Object-Oriented
much later. Software Engineering (OOSE) by Ivar Jacobson.
 The object-oriented paradigm The first object–oriented language
was Simula (Simulation of real systems) that was developed in 1960
The approach
by researchers at the Norwegian Computing Center.  De-emphasizes procedures. The focus shifts from modeling
 In 1970, Alan Kay and his research group at Xerox PARK created a
business processes and data to combining data and
procedures into objects.
personal computer named Dynabook and the first pure object-
oriented programming language (OOPL) - Smalltalk, for  system is considered as a collection of classes and objects and
programming the Dynabook. the relationship among them.
 In the 1980s, Grady Booch published a paper titled Object Oriented  A development strategy based on the concept that systems
Design that mainly presented a design for the programming should be built from a collection of reusable components
language, Ada. In the ensuing editions, he extended his ideas to a called objects.
complete object–oriented design method.
3/25/2023 Object Oriented System Analysis and Design 55 3/25/2023 Object Oriented System Analysis and Design 56
 3/25/2023

OO system development.. OO system development..

OO Approach Object-oriented System analysis and Design
 Object is a concept that encapsulate data as well as their behaviour. (OOAD) is a popular technical approach for
 Each object has attributes (properties) and method (procedures) analyzing, designing an application, or system by
 Objects grouped in to classes and object is responsible for itself.
applying the object oriented paradigm and visual
Proponents of object-oriented development claim that users can modeling throughout the development life cycles
more easily understand objects than traditional representations of a
system. for better communication and product quality.
Object oriented analysis and design are based on these objects and Object-oriented programming (OOP) is a method
are believed to model the real world better than previous methods, based on the concept of “objects", which are data
which describe a system in terms of inputs, outputs, and data flows.
structures that contain data, in the form of fields
However, some research show that objects oriented software
development methods may be more difficult to use for specifying often known as attributes; and code, in the form of
information requirements than traditional structured methods. procedures, often known as methods

3/25/2023 Object Oriented System Analysis and Design 57 3/25/2023 Object Oriented System Analysis and Design 58

OO system development.. OO system development..

Why Object Orientation? Benefits
 Improved Quality
Using Object oriented approach has so many benefits:  Quality systems are on time, on budget and meet or exceed the
expectations of their users. Improved quality comes from increased
 Increase the level of abstraction participation of users in systems development. OO development
 Modeling the real world and provides us with the stronger techniques provide greater opportunity for users to participate in the
equivalence of the real world‘s entities (objects). development process.
 Increased reusability  Financial Benefits
 Object orientation enables us to build better faster and cheaper(BFC) systems
 OO paradigm provides opportunities for reuse through the concepts of
inheritance, polymorphism, encapsulation, modularity, coupling and  Increased chance of project success
cohesion
 Reduce maintenance burden
 Objects are reusable; hence reduce the time and cost of writing software
as well as the incidence of defects.  Managed complexity
 we can build complex software from a well-designed reusable objects.
 Faster development
 Increased Extensibility  Adapts to changing requirement
 Because classes have both data and functionality when you add a new features  Seamless transition among different phases of software
to the system, you only need to make changes in one place: the applicable class development.
 Encouragement of good programming technique

3/25/2023 Object Oriented System Analysis and Design 59 3/25/2023 Object Oriented System Analysis and Design 60
 3/25/2023

1.3.3. Understanding Basics of Object

OO system development.. Orientation
Though it has listed of benefits, opponents of OO claims the 1. Objects:
following list of drawbacks An object is a real-world element in an object–oriented
environment that may have a physical or a conceptual existence.
 OO requires a greater concentration on requirements, analysis and Objects can be modelled according to the needs of the
design application.i,.e an object might be a person, place, thing, event,
 Developers must work closely with users concept, screen or report.
 Many OO benefits are long-term
An object has state, behavior, and identity;
 Identity that distinguishes it from other objects in the system.
 OO demands up-front investments in training, education and tools
 State that determines the characteristic properties of an object as
well as the values of the properties that the object holds.
 Behavior that represents externally visible activities performed by
an object in terms of changes in its state.
 The terms instance and object are interchangeable".
 In practical terms, this means that an object is defined by the messages
it can receive and send; the methods that handle these messages
comprise the object's sole interface to the outer world.

3/25/2023 Object Oriented System Analysis and Design 61 3/25/2023 Object Oriented System Analysis and Design 62

Understanding Basics of.. Understanding Basics of..

2. Class: Examples University Registrar System
The structure and behaviors of similar objects are If we take one class Student- Student class has ID, Name, DoB etc as attributes
and addCourse(), dropCourse, reigisterfoCourse(), etc as a method
defined in their common class; so we can define class
One instance of the class Student Objectstudent an Object having the
as following behaviours
 A group of related objects. i.e Objectstuden_Id=IT/001/2011, Objectstuden_Name= Lemma, etc… is an
 A software abstraction of similar objects Object
 A template from which objects are created 3. Instantiation
 To create objects from class definitions
The constituents of a class are 4. Abstraction
 A set of attributes for the objects that are to be  The process of extracting the essential characteristics of an item. Class is
instantiated from the class. Generally, different objects constructed from objects through abstraction.
of a class have some difference in the values of the 5. Method and Attribute
attributes. Attributes are often referred as class data.  A method can be thought as either a function or procedure.
 A set of operations that portray the behavior of the  It is a process implemented by a class that performs an action of value.
objects of the class. Operations are also referred as  Attribute: something that the class knows
functions or methods.

3/25/2023 Object Oriented System Analysis and Design 63 3/25/2023 Object Oriented System Analysis and Design 64
 3/25/2023

Understanding Basics of.. Understanding Basics of..

6. Data Hiding  The subclass can inherit or derive the attributes and
 Typically, a class is designed such that its data (attributes) can be
accessed only by its class methods and insulated from direct outside methods of the super-class(es) provided that the
access. This process of insulating an object’s data is called data hiding or superclass allows so. Besides, the subclass may add its own
information hiding. attributes and methods and may modify any of the super-
7. Encapsulation class methods.
 is the process of binding both attributes and methods together within a  Inheritance defines an “is – a” relationship
class. Through encapsulation, the internal details of a class can be hidden
from outside. It permits the elements of the class to be accessed from  Types of Inheritance
outside only through the interface provided by the class. The same is true
of a package. a. Single Inheritance − A subclass derives from a single superclass.
8. Inheritance b. Multiple Inheritance − A subclass derives from more than one super-classes.
 Inheritance is the mechanism that permits new classes to be created out c. Multilevel Inheritance − A subclass derives from a super class which in turn
of existing classes by extending and refining its capabilities. is derived from another class and so on.
 The existing classes are called the base classes/parent classes/super- d. Hierarchical Inheritance − A class has a number of subclasses each of which
classes, and the new classes are called the derived classes/child may have subsequent subclasses, continuing for a number of levels, so as to
classes/subclasses. form a tree structure.
e. Hybrid Inheritance − A combination of multiple and multilevel inheritance
so as to form a lattice structure

3/25/2023 Object Oriented System Analysis and Design 65 3/25/2023 Object Oriented System Analysis and Design 66

Understanding Basics of..

9. Polymorphism
Polymorphism is originally a Greek word that means the ability to
take multiple forms.
In object-oriented paradigm, polymorphism implies using
operations in different ways, depending upon the instance they
are operating upon.
Polymorphism allows objects with different internal structures to
have a common external interface. Polymorphism is particularly
effective while implementing inheritance.
Example: Let us consider two classes, Circle and Square, each with
a method findArea(). Though the name and purpose of the
methods in the classes are same, the internal implementation,
i.e., the procedure of calculating area is different for each class.
When an object of class Circle invokes its findArea() method, the
operation finds the area of the circle without any conflict with the
findArea() method of the Square class.

3/25/2023 Object Oriented System Analysis and Design 67 3/25/2023 Object Oriented System Analysis and Design 68
 3/25/2023

Understanding Basics of..

10. Generalization and Specialization
 Generalization and specialization represent a hierarchy of relationships
between classes, where subclasses inherit from super-classes.
A. Generalization
 In the generalization process, the common characteristics of classes
are combined to form a class in a higher level of hierarchy, i.e.,
subclasses are combined to form a generalized super-class. It
represents an “is – a – kind – of” relationship. For example, “car is a
kind of land vehicle”, or “ship is a kind of water vehicle”.
B. Specialization
 Specialization is the reverse process of generalization. Here, the
distinguishing features of groups of objects are used to form
specialized classes from existing classes. It can be said that the
subclasses are the specialized versions of the super-class.
 The following figure shows an example of generalization and
specialization.

3/25/2023 Object Oriented System Analysis and Design 69 3/25/2023 Object Oriented System Analysis and Design 70

Understanding Basics of.. Understanding Basics of..

11. Abstract Vs Concrete Class 13. Persistence:
 Abstract Class: A class that does not have objects instantiated from it.
 Concrete Class: A class that has objects instantiated from it  The storing of objects to permanent storage, for
12. Coupling and Cohesion example files, databases etc.
 Coupling 14. Persistence Vs Transitory Objects
 is a measure of how much two items such as classes or methods are
interrelated Persistence Object: An object saved to permanent
 When one class depends on another class, we say they are strongly storage
coupled.
 When one class interact with another class but doesn’t know any of the Transitory object: An object not saved to permanent
implementation of another class, we say they are loosely coupled. storages
 Loosely coupled components are desirable for good designed systems.
 Cohesion
Ex StudentsRegistartionForm1 is transitory object and
 is a measure of how much an item, such as a class or method makes ObjectStudent1 is Persistence object
sense.
15. Pattern:
 A good measure of cohesiveness of something is how long it takes to
describe in one sentence, the longer it takes the less cohesive it likely is.  A reusable solution to a common problem taking
Classes and methods are expected to be highly cohesive. relevant forces into account.
3/25/2023 Object Oriented System Analysis and Design 71 3/25/2023 Object Oriented System Analysis and Design 72
 3/25/2023

References
1. Brahmin, Ali (1999), Object oriented System development, McGraw Hill, USA.
2. Roger Pressman. 2010. Software Engineering: A Practitioner’s Approach. 6th
Edition. McGraw-Hill.
3. Ambler, S. W. (2004). The Object primer: The Application Developer’s Guide
to Object Orientation and the UML 3rd edition. New York. Cambridge
University Press

3/25/2023 Object Oriented System Analysis and Design 73