Object Oriented Analysis and

Design
Focus of OOAD in the core application
logic layer?

• Other layers are usually very technology/platform dependent.

• OO design of the core logic layer is similar across technologies.

• Deals with how the data flows, how decisions are made, and

how rules and algorithms are applied.(adding products to a

shopping cart, calculating the total price, applying discounts,)

• The design approach for the other layers tends to change

quickly as new frameworks or technologies emerge(ui/ux, db)

Focus on OOA/D in the core
application logic layer?
 Case Study-1

• The NextGen point-of-sale (POS) system

• Used in retail stores to handles sales and payments

• It includes hardware, like a computer and bar code

scanner, and software to run the system

• Its incudes third-party tax calculator and inventory

control
Software Development Lifecycle (SDLC)
• Inception
• Requirements
• Specifications
• Design
• Coding
• Testing
• Release (Deployment)
• Maintenance

5
 Inception

• Every software starts with Inception

• Short step to establish common vision
• Inception is not the requirement phase
• It will include analysis of perhaps 10% of the use
cases, analysis of the critical non-functional
requirement, creation of a business case, and
preparation of the development environment

6
 Inception

• What is the vision and business case for this

project?
■ Feasible?
■ Buy and/or build?
■ Rough unreliable range of cost: Is it $10K–100K
or in the millions?
■ Should we proceed or stop?

7
 Requirements
User Requirements
 Thisdocument will describe in detail about what is
expected outcome of the software product from the
user's perspective.
 The wordings of this document will be in the same tone that
of a user

Software Requirements Specification (SRS)

A team of business analysts, who are having a good
domain or functional expertise, will go to the clients
place and gets to know the activities that are to be
automated and prepares a document based on user
requirements and it is called as SRS
 Specifications are in fact an analysis of the user
requirements 8
 Design
High Level Design (HLD)
 List of modules and a brief description of each module
 Brief functionality of each module
 Interface relationship among modules
 Dependencies between modules
 Database tables identified along with key element
 Overall architecture diagrams along with technology details

Low Level Design (LLD)

 Details functional logic of the module (in pseudo code)
 Database tables, with all elements, including their type and size
 All interface details with complete API references (both requests and
responses)
 All dependency issues (Error message Listings)
9
 Complete input and outputs for a module
Coding
• Converting the pseudo code into
a programming language in the
specified platform
• Guidelines
to be followed for the
naming convention of
procedures, variables,
commenting methods etc.
• Bycompiling and correcting
the errors, all syntax error are
removed 10
 Testing Levels
• Unit Testing

 Programs will be tested at unit level

 Developers will perform the test

• Integration Testing

 When all the individual program units are tested in the unit testing phase
and all units are clear of any known bugs, the interfaces between those
modules will be tested

 Ensure that data flows from one piece to another piece

• System Testing

 After all the interfaces are tested between multiple modules, the
whole set of software is tested to establish that all modules work together
correctly as an application

 Put all pieces together and test

• Acceptance Testing


11
Clients test software at their place (in real-time or simulated environment)
Release to Production and Warranty Period

• When clients during the acceptance testing

do not find substantial problems, then they
will accept the software and start using
it

• Bug Fixes during the warranty period – we

cannot charge customer for this.

• Go Live Process means the product is

used on live servers (in Production)
12
 Maintenance Phase
Bug fixing(adding products issue)
Upgrade(improve , OS, DBMS version)
Enhancement(users to receive email)

After some time, the software may

become outdated and will reach a point
that it cannot be used
At that time, it will be replaced by
another software which is superior to that
13
Plan Driven
• Plan
Driven processes are
processes where all of the
process activities are planned in
advance and progress is
measured against this plan, like
Waterfall Model. Aerospace or Medical software

• follows sequence(requirements, design, coding, testing,

maintenance), and the progress is

monitored against a pre-defined

plan.(step-by-step method)
 Agile Processes

• Inagile processes, planning

incremental and it is easier to
change the plan and the software
to reflect changing customer
requirement
 Cont.

• Inpractice, most practical

processes include elements of both
plan-driven and agile approaches.
• Differenttypes of system need
different software processes.
• Mobile app (Agile)
• Banking software system(Plan-driven with
Agile)
Example
• Plan-driven Process
• Waterfall Model

• Agile Process
 Incremental Model
Major problems in software developments …

The requirements The developers This is how the This is how the problem
specification was understood it in problem was is solved now
defined like this that way solved before.

That is the program after This is how the program is

described by marketing This, in fact, is what the
debugging
department customer wanted … ;-)
The Waterfall Model

19
 Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway
 Waterfall Model Assumptions
1. The requirements are knowable in advance of
implementation.
2. The requirements have no unresolved, high-risk
implications
 e.g., risks due to choices, cost, schedule, performance,
safety, security, user interfaces, organizational impacts
3. The nature of the requirements will not change very
much
 During development; during evolution

4. The requirements are compatible with all the key

system stakeholders’ expectations
 e.g., users, customer, developers, maintainers,
investors
5. The right architecture for implementing the
requirements is well understood.
6. There is enough calendar time to proceed sequentially. 21
 Incremental development
• Rather than deliver the system as a single
delivery, the development and delivery is
broken down into increments with each
increment delivering part of the required
functionality
• User requirements are prioritised and the
highest priority requirements are included in early
increments

• Once the development of an increment is

started, the requirements are frozen though
requirements for later increments can continue to
evolve
 Incremental development
advantages
• Customer value can be delivered with each increment, so system

functionality is available earlier

• Early increments act as a prototype to help bring about

requirements for later increments

• Lower risk of overall project failure

• The highest priority system services tend to receive the most

testing
Incremental Models: Incremental(CPMCD,
communication, planning, modeling, construction, deployment)

24
25
26
When to use Incremental models?

• Requirements of the system are clearly understood

• When demand for an early release of a product

arises

• When the system is large, and building and testing

the complete system at once is too complex.

• When high-risk features and goals are involved

• Such methodology is more in use for web

application and product-based companies
27
Incremental Models: RAD Model
Rapid Application Development

28
 Business Modeling
Defines the business process and information
flow.
The information flow among business functions
is modeled in a way that answers the following
questions: What information drives the business
process? What information is generated? Who
generates it? Where does the information go?
Who processes it?

i.e. How accounts are managed, how transactions are

processed, and the overall business objectives (like,
improving transaction speed, enhancing security).

29
 Data Modeling
Identifies all the data elements and their
relationships.
The information flow defined as part of the
business modeling phase is refined into a set of
data objects that are needed to support the
business. The characteristics (called attributes)
of each object are identified and the
relationships between these objects defined.
(customer data (accounts, balances, transaction history) and
how these elements interact/relationship with each other .)

30
 Process Modeling

Represents the processes and workflows that

the system will automate.
The data objects defined in the data modeling
phase are transformed to achieve the
information flow necessary to implement a
business function. Processing descriptions are
created for adding, modifying, deleting, or
retrieving a data object.

(checking account balance, validating details,

executing the transfer, and updating
transaction history.) 31
 Application Generation

Automated tools are used to build the software

from the data and process models ,(code generation,
prototyping).

application generation tools for UI and database

operations (like retrieving or updating account
information) without manual coding, speeding
up the development process.
 Testing and Turnover
• Ensures the application works as expected,
followed by handing it over to the user.

• For a banking app, testing would involve

validating that account balances are
updated correctly after every transaction,
transfers work as expected, and security
features like two-factor authentication are
functioning.
34
 When to use RAD Methodology?
• When a system needs to be produced in a short span of time (2-3
months)
• When the requirements are known
• When the user will be involved all through the life cycle
• When technical risk is less
• When there is a necessity to create a system that can be
modularized in 2-3 months of time
• When a budget is high enough to afford designers for modeling
along with the cost of automated tools for code generation

35
Drawbacks of RAD
• In Sufficient Human Resources
• Developers and customer’s commitment for rapid-
fire activities
• Modularization
• Difficult to achieve High Performance
• High user feedback dependence

36
Evolutionary Process Models
Evolutionary models are iterative. They are
characterized in a manner that enables software
engineers to develop increasingly more complete
versions of the software.

37
Prototyping

38
• The different phases of Prototyping model are:
• 1.Communication
In this phase, developer and customer meet and discuss the overall
objectives of the software.

2. Quick design
• Quick design is implemented when requirements are known.
• It includes only the important aspects like input and output format of
the software.
• It focuses on those aspects which are visible to the user rather than
the detailed plan.
• It helps to construct a prototype.
• 3. Modeling quick design
• This phase gives the clear idea about the development of software
because the software is now built.
• It allows the developer to better understand the exact requirements.
• 4. Construction of prototype
The prototype is evaluated by the customer itself. 39
• 5. Deployment, delivery, feedback
 If the user is not satisfied with current prototype, then it refines according to
the requirements of the user.

• The process of refining the prototype is repeated until all

the requirements of users are met.

• When the users are satisfied with the developed prototype then the
system is developed on the basis of final prototype.

40
41
The Spiral Model

42
The Spiral Model

43
Analysis of Spiral Model
• Strengths
 Easy to test
 Easy to maintain

• Weaknesses
 For large-scale software only
 For internal software only

44
45
 Comparison of Process Models
Aspect Waterfall Agile RAD Incremental Spiral Prototype

Initial Flexible,
Defined at Evolve Can evolve Initial idea,
Requirem requirement refined in
the start, with user based on refined in
ents s, refined in each
rigid feedback feedback prototypes
increments spiral

Rapid Iterative,
Iterative Incremental Iterative
Developm Sequential, prototypin focusing
and , sequential with risk
ent Style linear g and on quick
flexible components analysis
iteration prototypes
User
Moderate to
Involvem Minimal High High High High
high
ent

Very high, Medium, High, High,

Low, hard High,
designed accommoda changes allows
Flexibility to adapt to encourage
for tes gradual made per requireme
changes s changes
flexibility changes spiral nt changes
 Incremen
Aspect Waterfall Agile RAD Spiral Prototype
tal

Continual At the end

Continuou Continuou
After each testing After each of each
Testing s, in each s in each
phase with increment spiral
sprint prototype
prototypes iteration

Usually
Can be
lower Can vary, Moderate Higher due Higher,
higher due
upfront, typically to high to risk due to
Cost to
high if manageab depending analysis iterative
prototypin
changes le on project costs prototypes
g
needed

Moderate,
Low,
Medium to more Low,
focused on
Documen low, document focuses on
High rapid High
tation depends ation as functionali
prototypin
on project increment ty
g
s grow