Introduction to Object Oriented Software Analysis and Design

Chapter 1
Introduction to OOSAD
2
Chapter one - Objective
Review of Software, Systems and System

thinking.
Structured Vs object oriented paradigm
The potential benefits of object orientation
The potential drawbacks of object orientation
The object oriented software process models
04/09/2023 Chapter 1 Introduction to OOSAD
3
1. What is System, System thinking??

A system is an interrelated set of business procedures (or
components) used within one business unit, working together
to achieve some purpose.
 Read about the 7 important characteristics of a system.??
Systems thinking is the ability to see organizations and

information systems as systems.
Systems thinking provides a framework from which to see the
important relationships among information systems, the
organizations they exist in, and the environment in which the
organizations themselves exist.
4
Systems, System thinking cont’d…
Important systems concepts:

 Decomposition- Breaking a system into smaller subsystems
(Components).
 Modularity- This is a direct result of decomposition. It refers
to dividing a system into chunks or modules of a relatively
uniform size
 Coupling: Subsystems should be as independent as possible
(Loose Coupling)
 Cohesion: This is the extent to which a subsystem performs a
single function- separation of concern (Highly Cohesiveness)
5
Software – Product Vs Process

 The product
 Information system
 Software
 The process
 System development
 Software engineering

6
Software Cont’d…
System development ultimate objectives
Problem solving
Supporting processes
Participants and roles in system/software production

 Users
 Managers (owners)
 Analysts
 Designers
 Programmers
 Consultants
7
Factors Initiating Software Development -
Scenarios initiating system/software

development
 Real problem on the day-to-day task
 By end users
 Looking for effectiveness and efficiency
 By managers
 Sensing new opportunities and technologies
 By technical personnel
8
The Inherent Nature of Software Complexity

Some software systems are not complex.
These are the largely forgettable applications that
are specified, constructed, maintained, and used by
the same person( Amateur or Professional).
This is not to say that all such systems are crude and
inelegant, nor do we mean to belittle their creators.
Such systems tend to have a very limited purpose
and a very short life span.
9
The Inherent Nature of Software Complexity Cont’d…
More interested in the challenges of developing what

we will call industrial-strength software.
 Applications that exhibit a very rich set of behaviors
 Applications that maintain the integrity of hundreds of thousands of records of
information while allowing concurrent updates and queries.
 Systems for the command and control of real-world entities, such as the routing
of air or railway traffic.
Such Complex Software systems tend to have a long life span,
and over time, many users come to depend on their proper
functioning.
Distinguishing characteristic of industrial- 10
strength software –Complex Systems
Complex systems are Intensely difficult, if not impossible for the

individual developer to comprehend all the subtleties of its design.
The complexity of such systems exceeds the human intellectual
capacity.
Unfortunately, this complexity we speak of seems to be an
essential property of all large software systems.
We may master how to solve this complexity, but we cannot avoid.
Hence, the complexity of large software is an essential property,
not an accidental one.

11
Inherent complexity derives from four elements
 The complexity of the problem domain

 Changing Requirement and Competing needs of diverse stakeholders
The difficulty of managing the development process.

 Team management and coordination
The flexibility possible through software.

 Flexibility to develop software the way you want it. labor-intensive. No strict
standards like in engineering artifacts
The problems of characterizing the behavior of discrete systems

 Uncontrollable inter-state phase in using digital discrete systems which could
corrupt our systems accidentally (if proper event interaction between the different
objects is not carefully crafted).
12
Attributes of Complex Systems
There are five common characteristics of

Complex Systems.
 Hierarchic Structure
 Frequently, complexity takes the form of a hierarchy, whereby a
complex system is composed of interrelated subsystems that
have in turn their own subsystems, and so on, until some lowest
level of elementary components is reached.( System thinking?!)
 The architecture of a complex system is a function of its
components as well as the hierarchic relationships among these
components.
Hierarchical(Canonical) form of complex 13
systems

14
Attributes of Complex Systems Cont’d…
Relative Primitives
 The nature of the primitive components of a
complex system is relative(subjective).
 The choice of what components in a system are
primitive is relatively arbitrary and is largely up to
the discretion of the observer of the system.
 What is primitive for one observer may be at a
much higher level of abstraction for another.
15
Attributes of complex systems Cont’d…
Separation of Concerns
 Hierarchic systems are decomposable because they can be
divided into identifiable parts(nearly decomposable because
their parts are not completely independent).
 Intracomponent linkages are generally stronger than
intercomponent linkages.(Loose Coupling and High Cohesion)
 This difference between intra- and intercomponent
interactions provides a clear separation of concerns among
the various parts of a system, making it possible to study
each part in relative isolation.
16
Common Patterns
 Hierarchic systems are usually composed of only
a few different kinds of subsystems in various
combinations and arrangements.
 In other words, complex systems have common
patterns.
 These patterns may involve the reuse of small
components.
17
Stable Intermediate Forms

 Complex systems tend to evolve over time
 A complex system that works is consistently found
to have evolved from a simple system that worked
 As systems evolve, objects that were once
considered complex become the primitive objects
on which more complex systems are built

18
Software Complexity –Solution

 The complexity of the software systems we are asked to develop is increasing,
yet there are basic limits on our ability to cope with this complexity.
 Hence we need a mechanism to cope with this complexity.
 The technique of mastering complexity has been known since ancient times: “divide et
impera (divide and rule)”
 Hence, solution is Decomposition
 Two types
 Algorithmic -top-down structured design, and so we approach decomposition – as a simple
algorithmic decomposition where in each module in the system denotes a major step in some
overall process.
 Object-Oriented -according to the key abstractions ( concepts) in the problem domain. Rather
than decomposing the problem into steps such as Get formatted update and Add checksum, we
can identify objects such as Master File and Checksum, which derive directly from the vocabulary
of the problem domain

OO Decomposition vs Algorithmic Decomposition
 Algorithmic Decomposition  OO Decomposition
04/09/2023 Chapter 1 Introduction to OOSAD 19

20
Characteristics of Good Software

21
Software Quality and the Stakeholders View
Customer: User:
solves problems at easy to learn;
an acceptable cost in efficient to use;
terms of money paid and helps get the work done
resources used
QUALITY
SOFTWARE
Developer: Development manager:

easy to design; sells more and
easy to maintain; pleases customers
easy to reuse its parts while costing less
to develop and maintain

22
Software Failure Crisis
“The "software crises" came about when people

realized the major problems in software development
were … caused by communication difficulties and the
management of complexity” (Budd)
Evidence over the years has shown that some of the
most common reasons software projects fail center
around poor or nonexistent communication between
the key stakeholders.(Booch)
23

24
Software Industry Success status( 2004)
 How well are systems built?

 Total Failure 15%
 “Challenged” 51%
 Successful 34%
 In 1994 “Successful” was only 17%!

 Challenged means…
 Failure to meet time, budget, or critical
features/requirements
25
Software Industry Success Status( 2017)
Project Management Institute(PMI)- Pulse

of the Profession 2018 Report
 The traditional measures of scope, time, and cost
are no longer sufficient.
 Determining project success, need to look at
levels of benefits realization maturity as well as
the traditional measures.

26
2. Structed vs OO development Approaches

 Structured Paradigm
 Structured methods for design were developed in the 1970s and
1980s and were the precursor to the UML and object-oriented
design.
 Modeling process and data separately
 Suitable for small sized software
 Object Oriented Paradigm
 Things are made up of objects
 Objects are identified as having data and function
 Is a software development strategy based on the idea of building
systems/software from reusable components called objects

27
Structured (Paradigm)Approach
The structured paradigm is a development strategy based on
the concept that a system should be separated into two parts:
data (modeled using a data model) and functionality (modeled
using a process model).
 applications in which data are separate from behavior both in the design
model and in the system implementation (that is, the program)
Examples of structured technologies include the COBOL,

BASIC and FORTRAN programming languages.
Is it also possible to do structured programming with any of
the modern programming language??- find out
28
Structured Analysis and Design Cont’d…
Philosophy of structured analysis and design

 Analysts attempt to divide large, complex problems
into smaller, more easily handled ones. “Divide and
Conquer”
 Top-Down approach to program development
 Functional view of the problem.
 Analysts use graphics to illustrate their ideas
whenever possible
29
Structured analysis and design Cont’d…
Goals of SAD
 Improve quality and reduce the risk of system
failure
 Establish concrete requirements specifications
and complete requirements documentation
 Focus on Reliability, Flexibility, and
Maintainability of system

30

 Elements of Structured Analysis and Design
 Essential Model: Model of what the system must do.
 Does not define how the system will accomplish its purpose.
 Is a combination of the environmental and behavioral model
 Environmental Model
 Defines the scope of the proposed system.
 Defines the boundary and interaction between the system and the outside
world.
 Composed of: Statement of Purpose, Context Diagram, and Event List.

31
Essential Model Cont’d…

 Behavioral Model
 Model of the internal behavior and data entities of the
system.
 Models the functional requirements.
 Composed of Data Dictionary, Data Flow Diagram,
Entity Relationship Diagram, Process Specification, and
State Transition Diagram.

32
Implementation Model
 Maps the functional requirements to the hardware
and software.
 Determines which functions should be manual and
which should be automated.
 Defines the Human-Computer Interface.
 Defines non-functional requirements.
 Tool: Structure Charts
33
Structured analysis and design
 Advantages of structured analysis and design

 Visual, so it is easier for users/programmers to
understand
 Makes good use of graphical tools
 A mature technique
 Simple and easy to understand and implement

34
Structured Analysis and Design Cont’d…
Disadvantages of Structured analysis and

design
 Not enough user-analyst interaction
 It depends on dividing system to sub systems but
it is hard to decide when to stop decomposing

35
OO Paradigm (Approach)
The object-oriented (OO) paradigm (pronounced

“para-dime”) is a development strategy based on the
concept that systems should be built from a collection
of reusable parts (components) called objects
Examples of OO languages and technologies include
the Smalltalk, Java, C#, and C++ programming
languages and the Enterprise JavaBeans (EJB)
framework.

36
OO Paradigm Cont’d…
The main concept behind the object-oriented paradigm is

that
 Instead of defining systems as two separate parts (data and
functionality), you now define systems as a collection of interacting
objects.
 Objects do things (that is, they have functionality) and they know
things(they have data).
 It requires a different way of thinking about decomposition –OO
Decomposition as opposed to algorithmic(functional) decomposition.
 A bottom-up approach to program development

37
Benefits are Greater:

 Productivity
 Reliability
 Maintainability
 Manageability

38
Direct mapping of concepts in the problem domain to
software units and their interfaces
Viewing the world as objects is more natural since it is closer
to the way humans think
Objects are more stable than functions…
Supports information hiding, data abstraction, and
encapsulation
Easily modified, extended, and maintained…
 if your product was designed correctly
39
OO Model is a “new” way of thinking about what it

means to compute and how information can be
structured
Systems are viewed as set of cooperating objects
that encapsulate structure and behavior in a
hierarchical construction (Canonical Form)
Functionality achieved by messages passing
between objects.
40
 For system/software developer in object orientation

the following are important
 Object oriented Programming
 Object Oriented Analysis, design
 Object Oriented CASE tools

41
Object-Oriented analysis and design Cont’d…
Process of progressively developing

representation of a system component (or
object) through the phases of analysis, design
and implementation
The model is abstract in the early stages
As the model evolves, it becomes more and
more detailed and concrete.
42
 Object-Oriented systems development life cycle

 The Object-Oriented development life cycle consists of
progressively developing an object representation through three
phases analysis, design, and implementation.
 Analysis Phase
 Object-oriented analysis is a popular approach that sees a system from the
viewpoint of the objects themselves as they function and interact
 Model of the real-world application is developed showing its important
properties
 Model specifies the functional behavior of the system independent of
implementation details

43
Design Phase
 Analysis model is refined and adapted to the environment
 Can be separated into two stages
 System design
 Concerned with overall system architecture
 Object design
 Implementation details are added to system design
Implementation Phase
 Design is implemented using a programming language or
database management system
Structured analysis and design vs. object oriented 44
analysis and design
Similarities
 Both SAD and OOAD had started off from programming
techniques.
 Both techniques use graphical design and graphical tools to
analyze and model the requirements.
 Both techniques provide a systematic step-by-step process for
developers
 Both techniques focus on documentation of the requirements

Structured analysis and design vs. object oriented 45
analysis and design
Differences
 SAD is Process-Oriented
 OOAD combines data and the processes
 OOAD encapsulates as much of the system’s data
and processes into a single construct called
objects, while SAD separates between them.

46
Summary of Structured vs OO Paradigms

 Structured analysis treats data and processes as separate components
 The Environmental Model:
- Statement of Purpose, Context Diagram, and Event List
 The Behavioural Model:

- Data Flow Diagram, Process Specification, Data
Dictionary, and Entity-Relationship Diagram
 The Implementation Model:

- Structure Diagram
 Object-oriented (O-O) analysis, combines data and processes into objects.

-The Object-Oriented development life cycle consists of progressively developing an object representation
through three phases of analysis, design, and implementation
47
3. The OO Software Process Models

Software Process:
 A structured set of activities required to develop a software system( product).
 i.e. the steps we go through to develop a software product is called a
software process.
 We have many different software processes, but all involve the
following activities.
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and
implementing the system;
 Verification and Validation – checking that the software does what the
customer wants;
 Evolution – changing the system in response to changing customer needs.
48
Software Process - Activities

 Real software processes are inter-leaved sequences of
 technical,
 collaborative and
 managerial activities
with the overall goal of specifying, designing, implementing,
testing(verification and validation), and maintaining a software system.
The four basic software process activities: specification,

development, verification and validation and evolution are
organized differently in different development processes.
In the waterfall model, they are organized in sequence, whereas
in incremental development they are inter-leaved.
49
Software Process Activities - Specification

 The process of establishing what services are required and the constraints on
the system’s operation and development.
 Requirements Engineering Process
 Feasibility study
 Is it technically and financially feasible to build the system?
 ROI, product Vision, what market share are we after? Urgency of development?
 Requirements elicitation and analysis
 What do the system stakeholders require or expect from the system?
 Recognition that the client must be satisfied. Have checkbook.
 Requirements Specification
 Defining the requirements in detail. These are the ‘what’s of a system!!!
 Requirements Validation
 Checking the validity of the requirements
 Are they feasible, testable, sufficient, necessary, consistent ...

50
The Requirements Engineering Process

51
Software Processes Activities - Software Design and Implementation
 The process of converting the system specification into an

executable system.
 Software Design (inputs are: specifications)
 Design a software structure that realizes the specification
 Implementation
 Translate this model / structure into an executable application
 Programming is the implementation of the design.
 The activities of design and implementation are closely related and
may be inter-leaved and definitely are using many modern
development processes. (more to come on this)

A General Model of the Design Process
52

53
Software Process Activities - Software Validation

 Involves checking and review processes and system testing.
 Verification and validation (V & V) is intended to show that a system
conforms to its specification and meets the requirements of the system
customer.
 Look up the difference between verification and validation??
 Verification is the process of checking that a software achieves its goal without any bugs
Verification means Are we building the product right?
 Validation is the process of checking whether the software product is up to the mark or in other words product has high
level requirements. Validation means Are we building the right product?

System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by
the system.
 Testing is the most commonly used “V & V” activity.

 Test First Development approach integrates testing, programing and
debugging.
54
Software Process Activities - Software Validation(2)
 Stages of Test Specifications and Testing

55
Software Evolution
Software is inherently flexible and can change.
As requirements change through changing business
circumstances, the software that supports the
business must also evolve and change.
Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new (greenfield engineering is rare).

56
4. Systems Development Methodology

 Systems Development methodology is a set of comprehensive guidelines
for SDLC that includes specific models, tools, and techniques.
 Models: Are representations of an important aspect of the real world.
Sometimes, the term abstraction is used because we abstract (separate
out) an aspect that is of particular importance .
 Tools: Are software support tools that help create models or other
components required in the project. Integrated development
environments (IDEs) include many tools to help with programming tasks.
 Techniques: Are collections of guidelines that helps an analyst complete
an activity or task

57
Models, Tools, and Techniques Cont’d…

Some models of system components
 Flowchart
 Data flow diagram (DFD)
 Entity-relationship diagram (ERD)
 Structure chart
 Use case diagram
 Class diagram
 Sequence diagram
Some models used to manage the development process

 Gantt chart
 Organizational hierarchy chart
 Financial analysis models – Net Present Value(NPV), payback period
58
Models, Tools and Techniques Cont’d…
Examples of Tools.
 Project management application
 Drawing/graphics application
 Word processor/text editor
 Visual modeling tool
 Integrated development environment (IDE)
 Database management application
 Reverse-engineering tool
 Code generator tool
59
Models, Tools and Techniques Cont’d…

Examples of Techniques
 Strategic planning techniques
 Project management techniques
 User interviewing techniques
 Data-modeling techniques
 Relational database design techniques
 Structured programming technique
 Software-testing techniques
 Process modeling techniques
 Domain modeling techniques
 Use case modeling techniques
 Object-oriented programming techniques
 Architectural design techniques
 User-interface design techniques
60
Methodology (Models, tools and Techniques)

61
4.1 Software Process Model

Software development life cycle (SDLC) encompasses the
phases/processes that a software developer goes through when
developing software.
Phases: Systems Planning and Selection  Systems Analysis  Systems
Design Systems Implementation and Operation.
A software process model is an abstract representation of a software

process. It presents a description of a software process from a
particular SDLC Methodology perspective
Software Process descriptions involve activities such as specifying a
data model, designing a user interface, etc. and the ordering of these
activities.
Plan-driven and Agile Software Processes 62
a.k.a. Heavy-Weight vs Light-Weight Process Models
Plan-driven processes are process models where all of the process activities
are planned in advance and progress is measured against this plan.
 Plan drives everything!
 Separate and distinct phases of specification and development.
In agile processes, planning is incremental and it is easier to change the

process to reflect changing customer requirements.
 Specification and development are interleaved
In practice, most practical processes include elements of both plan-driven

and agile.
There are no right or wrong software processes!
 Fit/unfit, more or less useful are possible judgments

63
Plan Driven vs Agile Processes - Characteristics

Agile Plan Driven
Project is small (5–10 people). Project is large (more than 10 people).
Experienced teams with a wide range of Teams include varied capabilities and skill
abilities and skills take part sets.
Project is an in-house project, and the team is Project is of strategic importance (e.g., an
co-located. enterprise initiative); scope crosses the
organization. Teams are geographically
distributed and/or outsourced.
System is new, with lots of unknowns. System is well understood, with a familiar
scope and feature set.
Requirements and environment are volatile, Requirements are fairly stable (low change
with high change rates. rates) and can be determined in advance.
Relationship with customer is close and System is large and complex, with critical
collaborative. safety or high reliability requirements.
Customer is readily available, dedicated, and Project stakeholders have a weak relationship
co-located.
04/09/2023 with the development
Chapter 1 Introduction toteam.
OOSAD
64
Plan Driven vs Agile Processes - Characteristics

Agile Plan Driven
Rapid value and high-responsiveness are Focus is on strong, quantitative process
required. improvement.
High trust environment exists within the External legal concerns (e.g., contracts,
development teams, between the liability, formal certification against specific
development teams, and with the customer. industry standards) exist.
End-user environment is flexible. Predictability and stability of process are
important.
Definition and management of process are
important.

65
Software Process Models cont’d…

There are hundreds of different process
models to choose from
 The following are some common examples
 Waterfall, • 
 Spiral • 
 Rapid prototyping • 
 Agile methods: extreme programming (XP), Scrum,
RUP
66
4.2 Heavy-Weight Software Process
Example: The Waterfall Model

 Plan-driven model.
 Separate and distinct phases of specification and development.
 Heavily oriented towards documentation (documentation-intensive)
 Progress often measured through documentation completion and
reviews (many)
 Lockstep approach
 Little chance for Change!
 Oftentimes discover major flaws too late.
 Delivered as Big Bang
67
Waterfall Phases

68
Waterfall Problems

69
Waterfall Problems Cont’d…

There are separate identified phases in the waterfall model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway(lockstep
nature) . In principle, a phase has to be complete before
moving onto the next phase.
But many issues are true too, such as risk addressing.
70
Waterfall Model Problems
 Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer
requirements.
 Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the
design process.
 However, Few business systems have stable requirements.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
 In those circumstances, the plan-driven nature of the waterfall model
helps coordinate the work.

Iterative and Incremental (Evolutionary) 71
development
It is a cyclic software development process developed in response to the weaknesses of the
waterfall model.
Evolutionary Developments can be
Type 1: Exploratory Development: customer assisted development that evolves a product from
ignorance to insight, starting from core, well understood components.(Spiral Model, Agile
Methods…are examples)
Type 2: Throwaway Prototyping: customer assisted development that evolves requirements
from ignorance to insight by means of lightweight disposable prototypes.( Rapid Prototyping is
an example)
Iteration is an essential part of the current Rational Unified Process(RUP), the Dynamic Systems
Development Method(DSDM), Extreme Programming(XP) and generally the agile software
development.
Iterative and incremental development is the case where the functionality of the system is
developed in a successive series of releases (iterative) of increasing completeness (incremental)

Iterative and Incremental (Evolutionary) 72
development

73
Boehm’s Spiral Model - heavyweight model

 Process is represented as a spiral rather than as a sequence of activities with
backtracking.
 Extends waterfall model by adding iteration to explore/manage risk
 Each loop in the spiral represents a phase in the process. Thus, the
innermost loop might be concerned with system feasibility, the next loop
with requirements definition, the next loop with system design, and so on.
 No fixed phases such as specification or design - loops in the spiral are chosen
depending on what is required.
 Risks are explicitly assessed and resolved throughout the process.
 This was the motivation behind developing the Spiral Model – Risk
 Key idea: on each iteration, identify and solve the sub-problems with the
highest risk.
74
Boehm’s Spiral Model of the Software Process

75
Boehm’s Spiral Model of the Software Process

76
Spiral Model- the Sectors
Objective setting
 Specific objectives for the phase are identified.
Risk assessment and reduction

 Risks are assessed and activities put in place to reduce the key risks.
Development and validation

 A development model for the system is chosen which can be any of
the generic models. Development takes place.
Planning
 The project is reviewed and the next phase of the spiral is planned.
77
Spiral Model Usage Context

It is a software development process combining elements of
both prototyping-in-stages and sequential waterfall models
 combines advantages of top-down and bottom-up concepts.
is intended for large, expensive and complicated projects.

Spiral model has been very influential in helping people think
about iteration in software processes and introducing the
risk-driven approach to development.
In practice, however, the model is rarely used as published
for practical software development.
78
Rapid Prototyping - Heavyweight Model
 Building a scaled-down working version of the system

 Analysts work with users to determine the initial & basic
requirements for the system.
 The analyst then quickly builds a prototype.
 When the prototype is complete, the users work with him/her &
tell what they like & don’t like about it.
 The analyst uses this feedback  improve the prototype & takes
the new version back to the users
 This iterative process continues until the users are
relatively satisfied.
79
Rapid Prototyping Cont’d…

 Advantages:
 Users are involved in the A&D process
 Captures requirements in concrete form, rather than verbal/abstract
form
 Disadvantages
 Insufficient analysis
 User confusion of prototype and finished system
 Developer misunderstanding of user objectives
 Developer attachment to prototype
 Excessive development time of the prototype
 Expense of implementing prototyping
80
Great Dissatisfaction with Heavy-Weight Models

Delivered late,
over budget,
Failure to meet functional and non-functional requirements,
not responsive to change,

poor assessment of risk, ....
Discovery of major problems late….
Thinking about Process…..Want to refine the way we develop systems
Hierarchy:
Successful, Challenged; Failed
Few systems totally successful
Many ‘challenged’
Too many failures
Many famous practitioners starting to look at process in more detail
How can we do better?
81
4.3 Agile Methods – lightweight Methods

82
Agile Manifesto ( Agile Principles)

83
Different Agile Development Methodologies
RUP
SCRUM
XP
FDD
DSDM
Kanban
Crystal
84
The Unified Process(UP)
The unified process (Jacobson, Booch, and Rumbaugh

1999) is a framework from which software development
processes are instantiated,
 Two such instantiations are the
 Rational Unified Process(RUP)
 A four-phased (inception, elaboration, construction, transition), prescriptive
process whose scope is software development process
 Is also one of the most popular realizations of the iterative approach for
object-oriented development.
 Enterprise Unified Process (EUP)
 Extends RUP to make it a full-fledged IT process( beyond development)
85
Rational Unified Process(RUP) Model

Is based on the process of UML and standard OOAD.
Unlike the waterfall model where phases are equated with process
activities, phases in the RUP are more closely related to business rather
than technical concerns.
Four Phases
 Inception
 Elaboration
 Construction
 Transition
These indicate the state of the system at each phase NOT the activities
involved at that point in development
86
RUP Process Perspectives
The RUP recognizes that conventional process

models present a single view of the process.
In contrast, the RUP is normally described from three
perspectives:
1. A dynamic perspective, which shows the phases of the model over
time.
2. A static perspective, which shows the process activities that are
enacted.
3. A practice perspective, which suggests good practices to be used
during the process.
87
Rational Unified Process(RUP)- Phases

Phases (stages) of Development
 Inception – the initial work required to set up and agree terms
for the project. Includes establishing the business case
 Feasibility, Basic risk assessment, Scope of the system to be
delivered
 Elaboration
 Construction
 Transition

88
Rational Unified Process(RUP)

 Inception
 Elaboration – deals with putting the basic architecture of the system in
place
 All main project risks are identified
 Develop an understanding of the problem domain and the system architecture.
 Construction
 Transition

89

 Inception
 Elaboration
 Construction – involves bulk of work on building the
system
 System design, programming and testing
 Ends with beta-release of system
 Transition

90

 Inception
 Elaboration
 Construction
 Transition – process involved in transferring the system to the clients
and users
 Deploy the system in its operating environment

91
Rational Unified Process(RUP) - Workflows

 The activities implied by the stages in a traditional structured process modelling
approach are referred to as Workflows in the (RUP) object-orientated approach.
 RUP Workflows -
Basic Workflows:
 Business modelling
 Requirements
 Analysis
 Design
 Implementation
 Testing
 Deployment
Support Workflows
 Configuration and Change Management
 Project Management
 Environment

92
RUP Phases and Workflows – interactions

93
Schedule-oriented terms in the UP

development cycle
iteration phase
inc. elaboration construction transition
milestone release increment final production

release
An iteration end- A stable executable The difference
point when some subset of the final (delta) between the At this point, the
significant decision product. The end of releases of 2 system is released
or evaluation each iteration is a subsequent for production use.
occurs. minor release. iterations.

RUP- Phases, Milestones, workflows and 94
Iterations overtime

95
The shifting focus of Iteration rounds

96
RUP Basic Workflows

Workflow Description
Business modelling The business processes are modelled using business use cases
Requirements Actors who interact with the system are identified and use cases are
developed to model the system requirements.
Analysis and A design model is created and documented using architectural models,
design component models, object models, and sequence models.
Implementation The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design
models helps accelerate this process.
Testing Testing is an iterative process that is carried out in conjunction with

implementation. System testing follows the completion of the
implementation.
Deployment A product release is created, distributed to users, and installed in their

04/09/2023 workplace Chapter 1 Introduction to OOSAD
97
RUP Support Workflows

Workflow Description
Configuration and change This supporting workflow manages changes to the
management system
Project management This supporting workflow manages the system
development
Environment This workflow is concerned with making appropriate
software tools available to the software development
team.

98
Rational Unified Process(RUP) –iteration cycles

Iterative Process -
 Workflows may be carried out during any phase of the system
development
 In each phase, a range of workflows (activities) may be carried out
several times before moving on to the next phase.
 The concept of an iteration is pretty much the same across most
software development methods. What differs is the recommended
duration for each iteration.
 XP recommends that iterations be one or two weeks long, if possible.
 SCRUM specifies that all iterations (sprints) should be 30 days
long.
 RUP recommends that iterations be two to six weeks long.

Enterprise Unified Process(EUP)- Enactment of RUP – read more if interested 99

100
The Enterprise Unified Process

 Extends the Rational Unified Process.
 Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the
entire information technology (IT) lifecycle.
 The extensions include two new phases,

 Production and
 Retirement, and
 Several new disciplines have also been included:

 Operations and Support and
 the seven enterprise disciplines (
 Enterprise Business Modeling,
 Portfolio Management,
 Enterprise Architecture,
 Strategic Reuse,
 People Management,
 Enterprise Administration, and
 Software Process Improvement)
101
OO Software development process best practices
The practice perspective on the RUP describes good

software development practices that are recommended for
use in systems development.
Six fundamental best practices are recommended:
 Develop software iteratively.
 Manage requirements Explicitly
 Use component-based architectures(re-usable)
 Visually model software.
 Verify software quality.
 Control changes to software
102
Water fountain for OO Software Development
Water fountain life cycle

describes the inherent
iterative and incremental
qualities of object-oriented
development methods

End of Chapter 1
04/09/2023 Chapter 1 Introduction to OOSAD 103

Introduction to Object Oriented Software Analysis and Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction to Object Oriented Software Analysis and Design

Uploaded by

Copyright:

Available Formats

Chapter 1

Chapter one - Objective

Review of Software, Systems and System

1. What is System, System thinking??

Systems thinking is the ability to see organizations and

Systems, System thinking cont’d…

Important systems concepts:

Software – Product Vs Process

04/09/2023 Chapter 1 Introduction to OOSAD

Participants and roles in system/software production

Factors Initiating Software Development -

Scenarios initiating system/software

The Inherent Nature of Software Complexity

The Inherent Nature of Software Complexity Cont’d…

More interested in the challenges of developing what

strength software –Complex Systems

Complex systems are Intensely difficult, if not impossible for the

04/09/2023 Chapter 1 Introduction to OOSAD

Inherent complexity derives from four elements

 The complexity of the problem domain

The difficulty of managing the development process.

The flexibility possible through software.

The problems of characterizing the behavior of discrete systems

Attributes of Complex Systems

There are five common characteristics of

04/09/2023 Chapter 1 Introduction to OOSAD

Attributes of Complex Systems Cont’d…

Attributes of complex systems Cont’d…

Attributes of complex systems Cont’d…

Attributes of complex systems Cont’d…

Stable Intermediate Forms

04/09/2023 Chapter 1 Introduction to OOSAD

Software Complexity –Solution

04/09/2023 Chapter 1 Introduction to OOSAD

04/09/2023 Chapter 1 Introduction to OOSAD 19

Characteristics of Good Software

04/09/2023 Chapter 1 Introduction to OOSAD

Software Quality and the Stakeholders View

Developer: Development manager:

04/09/2023 Chapter 1 Introduction to OOSAD

Software Failure Crisis

“The "software crises" came about when people

04/09/2023 Chapter 1 Introduction to OOSAD

Software Industry Success status( 2004)

 How well are systems built?

 In 1994 “Successful” was only 17%!

Software Industry Success Status( 2017)

Project Management Institute(PMI)- Pulse

04/09/2023 Chapter 1 Introduction to OOSAD

2. Structed vs OO development Approaches

04/09/2023 Chapter 1 Introduction to OOSAD

Examples of structured technologies include the COBOL,

Structured Analysis and Design Cont’d…

Philosophy of structured analysis and design

Structured analysis and design Cont’d…

04/09/2023 Chapter 1 Introduction to OOSAD

Structured analysis and design Cont’d…

04/09/2023 Chapter 1 Introduction to OOSAD

Structured analysis and design Cont’d…

Essential Model Cont’d…

04/09/2023 Chapter 1 Introduction to OOSAD

Structured analysis and design Cont’d…

Structured analysis and design