OOAD

UNIT I

Introduction to OOAD – What is OOAD? – What is UML? What are the Unified Process (UP)

phases - Case study – the NextGen POS system, Inception -Use case Modeling - Relating Use

cases – include, extend and generalization.

INTRODUCTION TO OOAD

Analysis - emphasizes an investigation of the problem and requirements, rather than a

solution. For example, if a new online trading system is desired, how will it be used? What are

its functions?

"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the

requirements) or object-oriented analysis (an investigation of the domain objects).

Design - emphasizes a conceptual solution (in software and hardware) that fulfills the

requirements, rather than its implementation. For example, a description of a database schema

and software objects.

The term is best qualified, as in object-oriented design or database design.

Object-oriented systems - An object-oriented system is composed of objects. The

behavior of the system results from the collaboration of those objects. Collaboration between

objects involves those sending messages to each other. Sending a message differs from calling a

function in that when a target object receives a message, it itself decides what function to carry

out to service that message. The same message may be implemented by many different

functions, the one selected depending on the state of the target object.

The implementation of "message sending" varies depending on the architecture of the system

being modeled, and the location of the objects being communicated with.

Object-oriented analysis – Object-oriented analysis (OOA) looks at the problem

domain, with the aim of producing a conceptual model of the information that exists in the area

being analyzed. Analysis models do not consider any implementation constraints that might

exist, such as concurrency, distribution, persistence, or how the system is to be built.

Implementation constraints are dealt during object-oriented design (OOD). Analysis is done

before the Design.

The sources for the analysis can be a written requirements statement, a formal vision document,

and interviews with stakeholders or other interested parties. A system may be divided into

multiple domains, representing different business, technological, or other areas of interest, each

of which are analyzed separately.

The result of object-oriented analysis is a description of what the system is functionally required

to do, in the form of a conceptual model. That will typically be presented as a set of use cases,

one or more UML class diagrams, and a number of interaction diagrams. It may also include

some kind of user interface mock-up. The purpose of object oriented analysis is to develop a

model that describes computer software as it works to satisfy a set of customer defined

requirements.

Object-oriented design - Object-oriented design (OOD) transforms the conceptual model

produced in object-oriented analysis to take account of the constraints imposed by the chosen

architecture and any non-functional – technological or environmental – constraints, such as

transaction throughput, response time, run-time platform, development environment, or

programming language.

The concepts in the analysis model are mapped onto implementation classes and interfaces. The

result is a model of the solution domain

WHAT IS OOAD?

Object-oriented analysis and design (OOAD) - is a software engineering approach that

models a system as a group of interacting objects. Each object represents some entity of interest

in the system being modeled, and is characterized by its class, its state (data elements), and its

behavior. Various models can be created to show the static structure, dynamic behavior, and run-

time deployment of these collaborating objects. There are a number of different notations for

representing these models, such as the Unified Modeling Language (UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional

requirements for a system. Object-oriented design (OOD) elaborates the analysis models to

produce implementation specifications. OOA focuses on what the system does, OOD on how the

system does it.

WHAT IS UML?

Three ways to apply UML

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.

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.

UML as Programming Language - Complete executable specification of a software

system in UML. Executable code will be automatically generated, but is not normally

seen or modified by developers; one works only in the UML "programming language."

Three Perspectives to apply UML

Conceptual perspective – the diagrams are interpreted as describing things in a situation

of the real world or domain of interest.

Specification perspective - the diagrams describe software abstractions or components

with specifications and interfaces.

Implementation Perspective - the diagrams describe software implementations in a

particular technology (such as Java).

The Unified Modeling Language is a visual language for specifying, constructing and

documenting the artifacts of systems.

Figure 1. Different perspectives with UML.

WHAT IS THE UNIFIED PROCESS (UP) PHASES?

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.

The Unified Process divides the project into four phases:

Inception

Elaboration

Construction

Transition

Inception Phase

Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception

Phase is long then it may be an indication of excessive up-front specification, which is contrary

to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

Establish a justification or business case for the project

Establish the project scope and boundary conditions

Outline the use cases and key requirements that will drive the design tradeoffs

Outline one or more candidate architectures

Identify risks

Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.

Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy majority of the

system requirements. However, the primary goals of Elaboration are to address known risk

factors and to establish and validate the system architecture. Common processes undertaken in

this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with

only basic notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable Architecture

Baseline. This is a partial implementation of the system which includes the core, most

architecturally significant, components. It is built in a series of small, time-boxed iterations. By

the end of the Elaboration phase the system architecture must have stabilized and the executable

architecture baseline must demonstrate that the architecture will support the key system

functionality and exhibit the right behavior in terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the

Construction phase. At this point the plan should be accurate and credible; since it should be

based on the Elaboration phase experience and since significant risk factors should have been

addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the system is built

on the foundation laid in Elaboration. System features are implemented in a series of short, time-

boxed iterations. Each iteration results in an executable release of the software. It is customary to

write full text use cases during the construction phase and each one becomes the start of a new

iteration. Common UML (Unified Modeling Language) diagrams used during this phase include

Activity, Sequence, Collaboration, State (Transition) and Interaction diagrams.

The Initial Operational Capability Milestone marks the end of the Construction phase.

Transition Phase

The final project phase is Transition. In this phase the system is deployed to the target users.

Feedback received from an initial release (or initial releases) may result in further refinements to

be incorporated over the course of several Transition phase iterations. The Transition phase also

includes system conversions and user training. The Product Release Milestone marks the end of

the Transition phase.

Agile Unified Process (AUP)

It is a simplified version of the IBM Rational Unified Process (RUP).

It describes a simple, easy to understand approach to developing business application

software using agile techniques and concepts yet still remaining true to the RUP.

The AUP applies agile techniques including test driven development (TDD), Agile

Modeling, agile change management, and database refactoring to improve productivity

CASE STUDY – THE NEXTGEN POS SYSTEM

The Case study allows us to concentrate on learning fundamental OOA/D, requirements

analysis, UML and patterns, rather than explaining the problems.

NextGen point-of-sale (POS) system.

A POS system is a computerized application used (in part) to record sales and handle

payments; it is typically used in a retail store.

It includes hardware components such as a computer and bar code scanner, and software

to run the system.

It interfaces to various service applications, such as a third-party tax calculator and

inventory control.

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.

A POS system increasingly must support multiple and varied client-side terminals and

interfaces.

INCEPTION

How long is inception?

The intent of inception is to establish some initial common vision for the objective

of the project, determine if it is feasible and decide if it is worth.

It may include the first requirement workshop, Planning for the first iteration and

then quickly moving forward to elaboration.

What Artifacts may start in Inception?

Inception is the initial short step to establish a common vision and basic scope for the

project. 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.

Inception in one sentence: Envision the product scope, vision, and business case.

Table 1 lists common inception (or early elaboration) artifacts and indicates the issues

they address.

Artifact CommentVision and Business Case

Describes the high-level goals and constraints,

the business case, and provides an executive

summary.

Use-Case ModelDescribes the functional requirements. During

inception, the names of most use cases will be

identified, and perhaps 10% of the use cases

will be analyzed in detail.

Supplementary SpecificationDescribes other requirements, mostly non-

functional. During inception, it is useful to

have some idea of the key non-functional

requirements that have will have a major

impact on the architecture.

Glossary Key domain terminology, and data dictionary.

Risk List & Risk Management PlanDescribes the risks (business, technical,

ressource, and schedule) and ideas for their

mitigation or response.

Prototypes and proof-of-concepts To clarify the vision, and validate technical

ideas.

Iteration Plan Describes what to do in the first elaboration

iteration.

Phase Plan & Software Development PlanLow-precision guess for elaboration phase

duration and effort. Tools, people, education,

and other resources.

Development CaseA description of the customized UP steps and

artifacts for this project. In the UP, one always

customizes it for the project.

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.

USE CASE MODELINGS

The UP defines the Use-Case Model within the Requirements discipline. Primarily, this

is the set of all written use cases; it is a model of the system's functionality and environment.

Use cases are text documents, not diagrams, and use-case modeling is primarily an act of

writing text, not drawing diagrams.

A Use Case Model describes the proposed functionality of a new system. A Use Case

represents a discrete unit of interaction between a user (human or machine) and the system.

Example: such as Create Account or View Account Details.

Use cases are requirements, primarily functional or behavioral requirements that indicate

what the system will do. Use case defines a contract of how a system will behave.

Why use cases?

It is simple and makes it possible for the domain experts or requirement to themselves

write use cases.

It emphasize the user goals and perspective

Strength of use case is the ability to scale both up and down in terms of sophistication

and formality. Each Use Case describes the functionality to be built in the proposed

system, which can include another Use Case's functionality or extend another Use Case

with its own behavior.

A Use Case description will generally includes:

General comments and notes describing the use case.

Requirements - The formal functional requirements of things that a Use Case must

provide to the end user, such as <ability to update order>. These correspond to the

functional specifications found in structured methodologies, and form a contract that the

Use Case performs some action or provides some value to the system.

Constraints - The formal rules and limitations a Use Case operates under, defining what

can and cannot be done. These include:

o Pre-conditions that must have already occurred or be in place before the use case

is run; for example, <create order> must precede <modify order>

o Post-conditions that must be true once the Use Case is complete; for example,

<order is modified and consistent>

o Invariants that must always be true throughout the time the Use Case operates; for

example, an order must always have a customer number.

Scenarios – Formal, sequential descriptions of the steps taken to carry out the use case, or

the flow of events that occur during a Use Case instance. These can include multiple

scenarios, to cater for exceptional circumstances and alternative processing paths. These

are usually created in text and correspond to a textual representation of the Sequence

Diagram.

Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but

graphically portrayed.

Additional attributes, such as implementation phase, version number, complexity rating,

stereotype and status.

Actors

Use Cases are typically related to 'actors', which are human or machine entities that use

or interact with the system to perform a piece of meaningful work that helps them to

achieve a goal. The set of Use Cases an actor has access to define their overall role in the

system and the scope of their action.

There are three kinds of external actors.

Primary actor has user goals.

Example: the cashier.

Supporting actor provides a service (for example, information).

Example: The automated payment authorization service. Often a computer system, but could be an organization or person.

Offstage actor has an interest in the behavior of the use case

Example: a government tax agency.

Use cases can be written in different formats and levels of formality:

brief: Terse one-paragraph summary, usually of the main success scenario.

casual: Informal paragraph format. Multiple paragraphs that cover various scenarios.

fully dressed: All steps and variations are written in detail, and there are supporting

sections, such as preconditions and success guarantees.

Fully dressed Use case: Example – Process Sale

Fully dressed use cases show more detail and are structured; they dig deeper. Various

format templates are available for detailed use cases.

Here's the template:

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 Who cares about this use case, and what do they want?

Preconditions What must be true on start, and worth telling the reader?

Success Guarantee What must be true on successful completion, and worth

telling the reader.

Main Success Scenario A typical, unconditional happy path scenario of success.

Extensions Alternate scenarios of success or failure.

Special Requirements Related non-functional requirements.

Technology and Data Variations List Varying I/O methods and data formats.

Frequency of Occurrence Influences investigation, testing, and timing of implementation.

Miscellaneous Such as open issues.

What does the Section mean?

Scope: The scope bounds the system (or systems) under design

EX - Scope: NextGen POS application

Level: use cases are classified as at the user-goal level or the sub function level

EX - Level: user goal

Primary Actor: The principal actor that calls upon system services to fulfill a goal.

EX - Primary Actor: Cashier

Stakeholders and Interests List Important: This list is more important and practical than may

appear at first glance. It suggests and bounds what the system must do.

EX - 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.

- …

Preconditions: state what must always be true before a scenario is begun in the use case.

Preconditions are not tested within the use case; rather, they are conditions that are assumed to

be true.

EX - Preconditions: Cashier is identified and authenticated.

Success Guarantees (Postconditions): state what must be true on successful completion of the

use case either the main success scenario or some alternate path. The guarantee should meet the

needs of all stakeholders.

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

Accounting and Inventory are updated. Commissions recorded. Receipt is generated.

Main Success Scenario and Steps (or Basic Flow): Also called “Basic Flow" or "Typical

Flow." It describes a typical success path that satisfies the interests of the stakeholders.

EX - Main Success Scenario:

1. Customer arrives at a POS checkout with items to purchase.

2. Cashier starts a new sale.

3. Cashier enters item identifier.

4. …

Cashier repeats steps 3-4 until indicates done.

5. …

Extensions (or Alternate Flows): Extensions are important and normally comprise the majority

of the text. They indicate all the other scenarios or branches, both success and failure.

EX - Extensions:

3a. Invalid identifier:

1. System signals error and rejects entry.

3b. There are multiple of same item category and tracking unique item identity not important

(e.g., 5 packages of veggie-burgers):

1. Cashier can enter item category identifier and the quantity.

Special Requirements: If a non-functional requirement, quality attribute, or constraint relates

specifically to a use case, record it with the use case

EX - Special Requirements:

- Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.

- Credit authorization response within 30 seconds 90% of the time.

- Language internationalization on the text displayed.

Technology and Data Variations List: Often there are technical variations in how something

must be done, but not what, and it is noteworthy to record this in the use case. A common

example is a technical constraint imposed by a stakeholder regarding input or output

technologies. For example, a stakeholder might say, "The POS system must support credit

account input using a card reader and the keyboard."

EX - Technology and Data Variations List:

3a. Item identifier entered by laser scanner or keyboard.

3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.

7a. Credit account information entered by card reader or keyboard.

7b. Credit payment signature captured on paper receipt. But within two years, we predict many

customers will want digital signature capture.

Relating Use cases – include, extend and generalization

Include Relationship: This is the most common and important relationship.

It is common to have some partial behavior that is common across several use cases.

For example, the description of paying by credit occurs in several use cases, including

Process Sale, Process Rental, Contribute to Lay-away Plan, and so forth. Rather than duplicate

this text, it is desirable to separate it into its own sub-function use case, and indicate its inclusion.

This is simply refactoring and linking text to avoid duplication

Example: UC1 Process Sale

Main Success Scenario:

1.Customer arrives at a POS checkout with goods and/or services to purchase.

…

7.Customer pays and System handles payment.

…

Extensions:

7b. Paying by credit: Include Handle Credit Payment.

7c. Paying by check: Include Handle Check Payment.

…

Fig 2 Use case include relationship in the Use-Case Model.

Using include with Asynchronous Event Handling:

The basic notation is to use the a*, b*, ... style labels in the Extensions section.

Example - UC1: Process FooBars

Main Success Scenario:

1. …

Extensions:

a*. At any time, Customer selects to edit personal information: Edit Personal Information.

b*. At any time, Customer selects printing help: Present Printing Help.

Terminology:

Concrete use case: A concrete use case is initiated by an actor and performs the entire behavior

desired by the actor. These are the elementary business process use cases.

Example - Process Sale is a concrete use case.

Abstract use case: An abstract use case is never instantiated by itself; it is a subfunction use

case that is part of another use case.

Example - Handle Credit Payment

Base use case: A use case that includes another use case, or that is extended or specialized by

another use case is called a base use case.

Example - Process Sale

Addition use case: The use case that is an inclusion, extension, or specialization is called an

addition use case.

Example - Handle Credit Payment

Addition use cases are usually abstract.

Another use of the include relationship is to describe the handling of an asynchronous event,

such as when a user is able to, at any time, select or branch to a particular window, function,

or Web page, or within a range of steps.

Base use cases are usually concrete.

Fig 2. UML notation for the include relationship

Extend Relationship: Suppose a use case's text should not be modified (at least not

significantly) for some reason. Perhaps continually modifying the use case with myriad new

extensions and conditional steps is a maintenance headache, or the use case has been base lined

as a stable artifact, and can't be touched. How to append to the use case without modifying its

original text?

Example: UC15: Handle Gift Certificate Payment

Trigger: Customer wants to pay with gift certificate.

Extension Points: Payment in Process Sale.

Level: Sub-function

Main Success Scenario:

1. Customer gives gift certificate to Cashier.

2. Cashier enters gift certificate ID.

…

Fig 3. UML notation for the extend relationship

Generalization Relationship: The concepts CashPayment, CreditPayment, and CheckPayment

are all very similar. In this situation, it is possible (and useful[1]) to organize them (as in Figure

32.1) into a generalization-specialization class hierarchy (or simply class hierarchy) in which

the superclass Payment represents a more general concept, and the subclasses more specialized

ones.

Fig 4. Generalization – Specialization Hierarchy

Generalization is the activity of identifying commonality among concepts and defining

superclass (generals concept) and subclass (specialized concept) relationships. It is a way to

construct taxonomic classifications among concepts which are then illustrated in class

hierarchies.

Identifying a superclass and subclasses is of value in a domain model because their

presence allows us to understand concepts in more general, refined and abstract terms. It leads to

economy of expression, improved comprehension and a reduction in repeated information.

In the UML, the generalization relationship between elements is indicated with a large

hollow triangle pointing to the more general element from the more specialized one. Either a

separate target or shared target arrow style may be used.

Fig 5. Class hierarchy with separate and shared arrow notations