Object Oriented Analysis and Design

Analysis – Analysis emphasizes an investigation of the problem and requirements.

Design -  Design emphasizes a conceptual solution that fulfills the requirements.

What is an Object ?
• An object is a thing, an entity, a noun, anything you can imagine that has its own
identity.
• Some objects are living, some aren’t.
Example: a car, a person, a house, a table, a dog, a pot plant or a raincoat.
• All object have attributes: for example, a car has a manufacturer, a model number,
a color and a price.
• Objects also have behavior : a car can move from one place to another a dog can
bark.
• In Object-oriented software, real world objects migrate into code.
• In programming terms, our objects become stand-alone modules with their own
knowledge and behavior. ( their own data and processes)
• Each object has certain knowledge, in the form of attributes, and it knows how to
perform certain operations for the benefit of the rest of the program.
• For example, a person object might know its title, first name, last name, DOB and
address; it would be able to change its name, move a new address, tell us how old
it is, and so on.

Why Object Orientation ?

1. Objects are easier for people to understand.
2. Specialists can communicate better.
3. Data and processes are not artificially separated.
4. Code can be reused more easily.
5. Object orientation is mature and well proven.
 UNIT-I
 Introduction to Object Oriented Analysis and Design(OOAD):
• Object oriented analysis and design is a software engineering approach which models the
system as interacting objects.
• Each object represents a system entity which plays a vital role in building of that system.
What will you Learn ?
It helps developers and students to learn skills essential for the creation of well-designed,
robust, and maintainable software using OO technologies and languages as Java or C#.
learning goal of OOAD
•  A critical ability in OO development is to skillfully assign responsibilities to software objects.
 Analysis
• Analysis emphasizes an investigation of the problem and requirements, rather than a
solution.
• EX : if a new online trading system is desired, how will it be used? What are it functions?

 In Software development, we are primarily concerned with two forms of analysis.
 
1. Requirements Analysis is an investigation of the requirements.
2. Object – Oriented Analysis is an investigation of the domain objects.
• Analysis means - do the right thing

 
Design
•  Design emphasizes a conceptual solution (in software and hardware) that fulfills
the requirements. A design is not an implementation, although a good design can
be implemented when it is complete.
•   For example, a description of a data base schema and software objects.
•  Design means - Do the thing right
 Object Oriented Analysis
•  The Object Oriented Analysis emphasis on finding and describing the objects- or
concepts- in the problem domain.
•  In a Library Information System, some of the concepts include Book, Library, and
 
Patron.
Object Oriented Design
•  The Object Oriented Design emphasis is defining software objects and how they
collaborate to fulfill the requirements.
•   For example, a plane software object may have tailNumber attribute and a
getFlightHistory method.
 
Fig. Class diagram for Passport Automation System
 Plane

tailNumber

getFlightHisory()

Public class Plane

{
private String tailNumber;
public List getFlightHistory() { …… }
}

Fig. Object – Orientation emphasizes representation of objects.

The purpose of OO analysis and design can described as: ( from the web)
 Identifying the objects of a system.
 Identify their relationships.
 Make a design which can be converted to executables using OO languages.

There are three basic steps where the OO concepts are applied and implemented. The
steps can be defined as

OO Analysis --> OO Design --> OO implementation using OO languages

UML – UNIFIED MODELING LANGUAGE:
• The Unified Modeling Language is a visual language for specifying, constructing
and documenting the artifacts of systems.
• The word visual is a key point – the UML is the de facto standard diagramming
notation for drawing or presenting pictures (with some text) related to software.

 Three Ways to Apply UML

 In three ways people apply UML are introduced:
1.UML as sketch
2.UML as blueprint
3.UML as programming language
1.UML as sketch Informal and incomplete diagrams (often hand sketched on
whiteboards) created to explore difficult parts of the problem or solution space,
exploiting the power of visual languages.
 
2. UML as blueprint Relatively detailed design diagrams used either for
1.Reverse engineering to visualize and better understanding existing code in
UML diagrams, or for
  2. Code generation (forward engineering). – Before programming, some
detailed diagrams can provide guidance for code generation, either manually or
automatically with a tool.
3. UML as programming language - Complete executable specification of a software
system in UML.
Executable code will be automatically generated.

Three Perspectives to Apply UML:

  1.Conceptual perspective - the diagrams are interpreted as describing things
in a situation of the real world or domain of interest.
2. Specification (software) perspective - the diagrams (using the same
notation as in the conceptual perspective) describe software abstractions or
components with specifications and interfaces, but no commitment to a particular
implementation (for example, not specifically a class in C# or Java).
3. Implementation (software) perspective - the diagrams describe software
implementations in a particular technology (such as Java).

 
 
 Conceptual Perspective (Domain
Model): Raw UML class diagram
Dice Game 1 Includes 2 Die notation used to visualize real – world
faceValue concepts.

DiceGame Die Specification or Implementation

die1: Die faceValue : int Perspective (Design Class Diagram):
die2: Die getFaceValue() : int
Raw UML class diagram notation
used to visualize software elements
play() roll()

Different perspectives with UML

The Meaning of “Class” in Different Perspectives:
In the raw UML, the rectangular boxes shown in figure above are called
classes, but this term encompasses variety of phenomena – physical things,
abstract concepts, software things, events, and so forth.
Example:

DiceGame Die
die1: Die faceValue : int
2
die1: Die
getFaceValue() : int
play() roll()

1. A method superimposes alternative terminology on top of the raw UML.

2. For example, in the UP (Unified Process), when the UML boxes are drawn in the
Domain Model, they are called domain concepts or conceptual classes; the
Domain Model shows a conceptual perspective.
3. In the UP, when UML boxes are drawn in the Design Model, they are called design
classes; the Design Model shows a specification or implementation perspective, as
desired by the modeler.
To keep things clear, we will use class-related terms consistent with the UML and the
UP, as follows:
• Conceptual class – real-world concept or thing. A conceptual or essential
perspective. The UP Domain Model contains conceptual classes.
• Software class – a class representing a specification or implementation
perspective of a software component, regardless of the process or method.
• Implementation class - a class implemented in a specific OO language such as
Java.
What are the Unified process (UP) phases?
Unified Process:
• A Software development process describes an approach to building, deploying,
and possibly maintaining software.
• The Unified Process has emerged as a popular iterative software development
process for building object oriented systems.
• In particular, the Rational Unified Process or RUP, a detailed refinement of the
Unified Process, has been widely adopted.
• The UP is very flexible and open, and encourages including skillful practices from
other iterative methods, such as from Extreme Programming (XP), scrum, and so
forth.

What is Iterative and Evolutionary Development ?

• A key practice in both the UP and most modern method is iterative development.
• In this lifecycle approach, development is organized into a series of short, fixed-
length (for example, 3 weeks) mini-projects called iterations.
• The outcome of each is a tested, integrated, and executable partial system.
• Each iteration includes its own requirement analysis, design, implementation and
testing activities.
• The system grows incrementally over time, iteration by iteration, and thus this
approach is also known as iterative and incremental development. Because
feedback and adaptation evolve the specification and design, it is also known as
iterative and evolutionary development.

Benefits of Iterative Development:

• Less project failure, better productivity, and lower defect rates; shown by research
into iterative and evolutionary methods
• Early rather than late mitigation of high risks
• Early visible progress
• Early feedback, user engagement, and adaptation, leading to a refined system that
more closely meets the real needs of the stakeholders.
What are the UP phases?
The Unified Process has emerged as a popular iterative software development
process for building object oriented systems.
1. A UP project organizes the work and iterations across four major phases:
a. Inception approximate vision, business case, scope, vague estimates.
b. Elaboration refined vision, iterative implementation of the core architecture,
resolution of high risks, identification of most requirements and scope, more
realistic estimates.
c. Construction iterative implementation of the remaining lower risk and easier
elements, and preparation for deployment.
d. Transition beta tests, deployment.
2. This is not the old "waterfall" or sequential lifecycle of first defining all the
requirements, and then doing all or most of the design.
3. Inception is not a requirements phase; rather, it is a feasibility phase, where just
enough investigation is done to support a decision to continue or stop.
4. Similarly, elaboration is not the requirements or design phase; rather, it is a phase
where the core architecture is iteratively implemented, and high-risk issues are
mitigated.
5. Above figure illustrates common 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 At this point,
point when some subset of the final (delta) between the system is

significant decision product. The end of the releases of 2 released for

or evaluation occurs. each iteration is a subsequent production
minor release. iterations. use.

Fig. Scheduled – oriented terms in the UP

6. Notice that one development cycle (which ends in the release of a system into
production) is composed of many iterations.
INCEPTION:
7. The intent of inception is to establish some initial common vision for the
objectives of the project .
8. Inception is 1 week long for most projects.
9. During inception lightweight use case analysis is performed at least the names of
most use cases and actors should be identified.
10. Most use cases are written in brief format.
11. Most influential and risky quality requirements are identified.
12. Technical proofs of concept prototypes of any tricky parts of the use cases are
written.
13. High level architecture and components are proposed.
14. Plan for the first iteration is written.
15. Recommendations are made on what components to buy/build/reuse.
ELABORATION:
1. Build the core architecture, resolve the high-risk elements, define most
requirements and estimate the overall schedule and resources.
2. Adaptively design, implement and test the core and risky parts of the architecture
during early iterations.
3. Programming and testing should be started early.
4. Adapt based on feedback from test, users and developers.
5. Elaboration consists of between two and four iterations long and has heavy use
case analysis.
CONSTRUCTION:
6. Iterative implementation of the remaining lower risk and easier elements.
7. Preparation for deployment.
TRANSITION:
8. Beta tests, deployment, performance tuning and user training.
9. Optimization (performance improvement) should be left always at the end.
10. During transition there is no development to add functionality, unless is small and
absolutely essential.
What are the UP Disciplines ?
The UP describes work activities, such as writing a use case, within disciplines
– a set of activities( and related artifacts) in one subject area, such as the activities
within requirement analysis.
There are several disciplines in the UP, they are
1. Business Modeling – The Domain Model artifact, to visualize noteworthy concepts
in the application domain.
2. Requirements – The Use-Case Model and Supplementary Specification artifacts to
capture functional and non – functional requirements.
3. Design – The Design Model artifacts, to design the software objects.
Sample UP disciplines are
1. Business Modeling
2. Requirements
3. Design
4. Implementation
5. Test
6. Deployment
7. Configuration & Change Management
8. Project management, Enviroment
Case Study - The NextGEN POS System:
1. The first case study is the NextGen point-of-sale (POS) system.
2. A POS system is a computerized application used (in part) to record sales and
handle payments; it is typically used in a retail store.
3. It includes hardware components such as a computer and bar code scanner, and
software to run the system.
4. It interfaces to various service applications, such as a third-party tax calculator and
inventory control.
5. These systems must be relatively fault-tolerant; that is, even if remote services are
temporarily unavailable (such as the inventory system), they must still be capable
of capturing sales and handling at least cash payments (so that the business is not
crippled).
6. A POS system increasingly must support multiple and varied client-side terminals
and interfaces
7. These include a thin-client Web browser terminal, a regular personal computer
with something like a Java Swing graphical user interface, touch screen input,
wireless PDAs (Personal Digital Assistants), and so forth.
8. Furthermore, we are creating a commercial POS system that we will sell to
different clients with disparate needs in terms of business rule processing.
9. Each client will desire a unique set of logic to execute at certain predictable points
in scenarios of using the system, such as when a new sale is initiated or when a
new line item is added.
10. Therefore, we will need a mechanism to provide this flexibility and customization.
11. Using an iterative development strategy, we going to proceed through
requirements, OO analysis, design and implementation.

INCEPTION:
Introduction:
12. Inception is the initial short step to establish a common vision and basic scope for
the project.
13. 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 so that programming can start in the following
elaboration phase.
14. Only key requirements are investigated.
15. Purpose is to decide whether to proceed with development, not to define
requirements.
What is inception?
• Most projects require a short initial step in which the following kinds of questions
are explored:
1. What is the vision and business case for this project?
2. Feasible?
3. Buy and/or build?
4. Rough unreliable range of cost: Is it $10K - 100K or in the millions?
5. Should we proceed or stop?
• The purpose of the inception phase is not to define all the requirements.
• Most requirements analysis occurs during the elaboration phase, in parallel with
early production-quality programming and testing.
1. Thus, the inception phase should be relatively short for most projects, such as one
or a few weeks long.
2. Indeed, on many projects, if it is more than a week long, then the point of
inception has been missed: It is to decide if the project is worth a serious
investigation (during elaboration), not to do that investigation.
Example Oil Business: Analogy
In the oil business, when a new field is being considered, some of the steps include:
a. Decide if there is enough evidence or a business case to even justify exploratory
drilling.
b. If so, do measurements and exploratory drilling.
c. Provide scope and estimate information.
d. Further steps…
2. The inception phase is like step one in this analogy.
3. In step one people do not predict how much oil there is, or how much cost or
effort is needed to extract it.
4. In UP terms, the realistic exploration step is the elaboration phase.
6. The preceding inception phase is akin to a feasibility study to decide if it is even
worth investing in exploratory drilling.
7. Only after exploration (elaboration), we have the data and insight to make
somewhat believable estimates and plans.
Inception Artifacts:
Table 1.1 lists common inception( or early elaboration) artifacts and indicates the
issues they address.

Artifact Comment
Describes the high level goals and
Vision and Business Case constraints, the business case, and provides
an executive summary.
Describes the functional requirements.
During inception, the names of most use
Use-Case Model cases will be identified, and perhaps10% of
the use cases will be analyzed in detail.

Describes other requirements, mostly non-

functional. During inception, it is useful to
have some idea of the key non-functional
Supplementary Specification
requirements that have will have a major
impact on the architecture.

Describes Key domain terminology, and

Glossary data dictionary

Risk List & Risk Management Plan
Prototypes and proof- of -concepts
Iteration Plan
Phase Plan & Software Development Plan
Development Case
Describes the risks (business, technical,
resource, schedule) and ideas for their
mitigation or response.
To clarify the vision, or to validate technical
ideas.
Describes what to do in the first
elaboration iteration.
Low precision guess for the duration and
effort of the elaboration. Includes tools,
people, training and other resources.
A description of the Unified Process steps
and artifacts for the project. Note that the
UP is always customized for each project.

• These artifacts are only partially completed in this phase. They will be
iteratively refined in subsequent iterations.
You Didn’t Understand Inception When…..
1. It is more than "a few" weeks long for most projects.
2. There is an attempt to define most of the requirements.
3. Estimates or plans are expected to be reliable.
4. You define the architecture (this should be done iteratively in elaboration).
5. You believe that the proper sequence of work should be: 1) define the
requirements; 2) design the architecture; 3) implement.
6. There is no Business Case or Vision artifact.
7. All the use cases were written in detail.
8. None of the use cases were written in detail; rather, 10 -20% should be written in
detail to obtain some realistic insight into the scope of the problem.
How much UML need during Inception?
• The purpose of inception is to collect just enough information to establish a
common vision, decide, if moving forward is feasible, and if the project is worth
serious investigation in the elaboration phase.
• As such, perhaps beyond simple UML use case diagrams, not much diagramming
is warranted.
• There is more focus in inception on understanding the basic scope and 10% of the
requirements, expressed mostly in text forms.
USE CASE MODEL:
What is Use Cases?
1. Use cases are text stories, widely used to discover and record requirements.
2. Use cases are not diagrams, they are text.
3. They influence many aspects of a project – including OOA/D – will be input to
many subsequent artifacts.
Example:
Here is an example brief format use case:
Process Sale: A customer arrives at a checkout with items to purchase. The cashier
uses the POS system to record each purchased item. The system presents a running
total and line-item details. The customer enters payment information, which the
system validates and records. The system updates inventory. The customer receives
a receipt from the system and then leaves with the items.

What is actor?
• An actor is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.
.
What is scenario?
1. A scenario is a specific sequence of actions and interactions between actors and
the system.
2. It is also called a use case instance. It is one particular story of using a system, or
one path through the use case  
3. A use case is a collection of related success and failure scenarios that describe an
actor using a system to support a goal.
4. For example, the scenario of successfully purchasing items with cash, or the
scenario of failing to purchase items because of a credit payment denial.
Use cases and the Use-Case Model
5. Use cases are text documents, not diagrams, and use-case modeling is primarily
an act of writing text, not drawing diagrams.
6. The UP defines the Use-case Model within the requirement discipline.
7. The Use-Case Model may optionally include a UML use case diagram to show the
names of use cases and actors, and their relationship.
8. This gives a nice context diagram of a system and its environment. It also provides
a quick way to list the use cases by name.
What is the necessary for use case?
9. Simple and familiar storytelling makes it easier, especially for customers, to
contribute and review goals.
3. Use cases are good way to help, keep it simple, and make it possible for domain
experts or requirement donors to themselves write (or participate in writing) use
cases.
4. They emphasize goals and the user perspective.

What are Three Kinds of Actors?

An actor is anything with behavior, including the system under discussion (SuD)
itself when it calls upon the services of other systems.
5. Primary Actor - has user goals fulfilled through using services of the SuD.
Example -the cashier.
2. Supporting Actor-Provides service (for example, information) to the SuD.
Example – The automated payment authorization service is an example. Often a
computer system, but could be an organization or person.
3. Offstage Actor- has an interest in the behavior of the use case, but is not primary
or supporting.
Example - a government tax agency.
What are Three Common Use Case Formats?
1. Brief:
o Terse one-paragraph summary, usually of the main success scenario.
• When? During early requirements analysis, to get a quick sense of subject
and scope. May take only a few minutes to create.
2. Casual:
o Informal paragraph format. Multiple paragraphs that cover various scenarios.
• When? As above.
3. Fully dressed:
o All steps and variations are written in detail, and there are supporting sections,
such as preconditions and success guarantees.
Template for fully dressed use case:

Use Case Section Comment

Use Case Name Start with a verb.
Scope The system under design.
Level "user-goal" or "subfunction"
Primary Actor Calls on the system to deliver its services.

Stakeholders and Interests
Preconditions
Success Guarantee
Main Success Scenario
Extensions
Special Requirements
Technology and Data Variations List
Frequency of Occurrence
Miscellaneous
Who cares about this use case, and what
do they want?
What must be true on start, and worth
telling the reader?
What must be true on successful
completion, and worth telling the reader.
A typical, unconditional happy path
scenario of success.
Alternate scenarios of success or failure.
Related non-functional requirements.
Varying I/O methods and data formats.
Influences investigation, testing, and
timing of implementation.
Such as open issues.
Example for fully dressed use case format:

Use Case UC1: Process Sale

Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer
shortages are deducted from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort. Wants easily
visible display of entered items and prices. Wants proof of purchase to support
returns.
- Company: Wants to accurately record transactions and satisfy customer
interests
 - Wants to ensure that Payment Authorization Service payment receivables are
recorded. Wants some fault tolerance to allow sales capture even if server
components (e.g., remote credit validation) are unavailable.
- Government Tax Agencies: Want to collect tax from every sale. May be multiple
agencies, such as national, state, and county.

Preconditions: Cashier is identified and authenticated.

Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated.

Accounting and Inventory are updated. Commissions recorded. Receipt is
generated. Payment authorization approvals are recorded.

Main Success Scenario (or Basic Flow):

1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running
total. Price calculated from a set of price rules.
Extensions (or Alternative Flows):
a. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and
events can be recovered from any step of the scenario.
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. System reconstructs prior state.
Special Requirements:
1. Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
2. Credit authorization response within 30 seconds .
3. -Somehow, we want robust recovery when access to remote services such the
inventory system is failing.
Technology and Data Variations List:
4. Manager override entered by swiping an override card through a card reader, or
entering an authorization code via the keyboard.
5. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
Open issues:
6. What are the tax law variations?
7. What customization is needed for different businesses?
8. Must a cashier take their cash drawer when they log out?
Use Case Name:
• Each use case should have a name that indicates what value (or goal) is achieved by
the actor's interaction with the system
Naming Use Cases:
1. Must be a complete process from the viewpoint of the end user.
2. Usually in verb-object form, like Buy Pizza
3. Use enough detail to make it specific
4. Use active voice, not passive
5. From viewpoint of the actor, not the system
Types of Use Case:
6. High Level Use Case (Brief)
o Name, Actors, Purpose, Overview
7. Expanded Use Case (Fully Dressed)
o Add System Events and System Responses
8. Essential Use Case (Black Box)
o Leave out technological implications
9. Real Use Case (White Box)
o Leave in technology
Guidelines for Drawing Usecases:
Actor:
An actor is an idealized user of a system
Actors can be users, processes, and other systems.
Represent human Actor:

Represent Non Human Actor:

1. Non human actors usually represented as a rectangle  
2. Non human actors are usually not primary users.

<<Inventory system>>
Use Case:
A use case is a coherent unit of externally visible functionality provided by a system and
expressed by a sequence of messages
Symbol:

Create a
Requirement
Diagram
Relating use cases:
1. Several use cases can be related to each other.
2. Organizing use cases into relationship has no impact on the behavior or requirements
of the system.
3. It is simply an organization mechanism to improve communication and comprehension
of the use cases, reduce duplication of text, and improve management of the use case
documents.
The various relationships in use cases are

Association

Extend <<extend>>
1. Include 
Generalization
2. Extend
Uses <<uses>>
3.Generalization
Include <<include>>
 

Fig. Relationships in Use Cases

The include Relationship:
1. In UML modeling, an include relationship is a relationship in which one use case
(the base use case) includes the functionality of another use case (the inclusion
use case).
2. The include relationship supports the reuse of functionality in a use case model.
3. Include relationships insert additional behavior into a base use case.
You can add include relationships to your model to show the following situations:
4. The behavior of the inclusion use case is common to two or more use cases.
5. The result of the behavior that the inclusion use case specifies, not the behavior
itself, is important to the base use case.
As the following figure illustrates, an include relationship

<<include>>

Inclusion Use Case Base Use Case

The following figure illustrate Use Case A includes Use Case B
Use Case B
Use Case A
1.
1.
2
2
3.
3.
4.
4. Include Use
5.
Case B
5.

The Extend Relationship:

1. The idea is to create an extending or addition use case, and within it, describe
where and under what condition it extends the behavior of some base use case.
2. Extend puts additional behavior in a use case that does not know about it.
3. In UML modeling, you can create extension points for the base use case.
4. These extension points identify where the behavior of an extension use case can
be inserted into the base use case.
5. It is shown as a dotted line with an arrow point and labeled <<extend>>.
In this case, a customer can request a catalog when placing an order.
Example:

Place <<extend>> Request

Order
Catalog

The generalize Relationship :

1. Generalization is a relationship between a general use case and a more specific
use case that inherits features to it.
2. It is shown as a solid line with a closed arrow point.
3. Here, the payment process is modified for cash and charge cards.
Example:

Pay Cashier

Pay Cash Charge Purchase

Various relationships among use cases:

Classify type
of
Appointmen appointment <<include>>
t

Doctor <<uses>> <include>>

Collect
Doctors’ preinformation
<<extend>>
availability

<<include>>
cancel
appointment
Fix
appointment

Validate user

Generalization:

Check password Voice recognition