Object Oriented Analysis Design-UNIT 1 Lecture Material.pdf

notes

1. CS2513- OBJECT ORIENTED ANALYSIS & DESIGN
UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS




Introduction

Object Oriented analysis and design skills are essential for the creation of well-designed, robust, and
maintainable software using OO technologies and languages such as Java or C#.

Requirements analysis and OOA/D needs to be presented and practiced in the context of some
development process. In this case, an agile (light, flexible) approach to the well-known Unified
Process (UP) is used as the sample iterative development process are taken .

What is Analysis and Design?

Analysis (do the right thing )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?
Design (do the thing right ) 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.

What is Object-Oriented Analysis and Design?

Object-oriented Analysis : Emphasis on finding and describing the objects or concepts in the
problem domain.
For example, in the case of the flight information system, some of the concepts include Plane, Flight,
and Pilot.
For example, in the case of the library information system, some of the concepts include Book,
Library, and Patron

Object-oriented Design : Emphasis on defining software objects and how they collaborate to
fulfill the requirements.
For example, a Plane software object may have a tail Number attribute and a get FlightHistory
method.
For example, in the library system, a Book software object may have a title attribute and a getChapter
method

During implementation or object-oriented programming, design objects are implemented, such as a
Plane and book class in Java.
Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use Case –Case study –
the Next Gen POS system, Inception -Use case Modelling – Relating Use cases – include, extend and
generalization – When to use Use-cases

3. UNIFIED PROCESS

What is the UP?

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 combines commonly accepted best practices, such as an iterative lifecycle and risk-driven
development, into a cohesive and well-documented process description.

3 Key Aspects of UP:

1) Use-case driven
In UP, use cases are used to capture the functional requirements to define the
contents of the iterations.

2) Architecture-centric
UP supports different models of architecture, among that one of the architecture is
baseline architecture which is the foundation of remaining software development.

3) Iterative and incremental
The development Process is organized into a series of short, fixed-length (for
example, three-week) mini-projects called iterations; the outcome of each is a tested,
integrated, and executable partial system. Each iteration includes its own requirements
analysis, design, implementation, and testing activities.

Iterative and Evolutionary
The system grows incrementally over time, iteration by iteration, and thus this
approach is also known as iterative and incremental development (see Figure 2.1). Because feedback
and adaptation evolve the specifications and design, it is also known as iterative and evolutionary
development.

4. Benefits of Iterative Development (UP) :

 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 (technical, requirements, objectives, usability,
and so forth) .
 early visible progress.
 early feedback, user engagement, and adaptation, leading to a refined system that more closely
meets the real needs of the stakeholders .
 managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and
complex steps.
 the learning within an iteration can be methodically used to improve the development process
itself, iteration by iteration.

What is Iteration Time boxing?

Iterations are time-boxed, or fixed in length. For example, if the next iteration is chosen to be three
weeks long, then the partial system must be integrated, tested, and stabilized by the scheduled date-
date slippage is illegal. If it seems that it will be difficult to meet the deadline, the recommended
response is to de-scope-remove tasks or requirements from the iteration, and include them in a future
iteration, rather than slip the completion date.

What are Agile Methods?

Agile development methods usually apply time boxed iterative and evolutionary development, employ
adaptive planning, promote incremental delivery, and include other values and practices that encourage
agility rapid and flexible response to change.

UP Phases

A UP project organizes the work and iterations across four major phases:
1. Inception - approximate vision, business case, scope, vague estimates.
2. Elaboration - refined vision, iterative implementation of the core architecture, resolution of high
risks, identification of most requirements and scope, more realistic estimates.
3. Construction - iterative implementation of the remaining lower risk and easier elements, and
preparation for deployment.
4. Transition - beta tests, deployment.

1. Inception Phase:
Envision the product scope, vision, and business case.
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.

5.  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

Example:
Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in
serious investigations?
The purpose of inception stage is not to define all the requirements. The Up is not the waterfall
and the first phase inception is not the time to create believable estimates or plans. That happens
during elaboration.
The intent of inception is to establish some initial common vision for the objectives of the project,
determine if it is feasible, and decide if it is worth some serious investigation in elaboration. It can
be brief.
2. 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).
An analysis is done to determine the risks, stability of vision of what the product is to become,
stability of architecture and expenditure of resources.
The plan approved by the project management, and funding authority, and the resources required for
the elaboration phase have been allocated
Main Activities:
 Define the architecture.
Project plan is defined. The process, infrastructure and development environment are
described.
 Validate the architecture.
 Baseline the architecture.

To provide a stable basis for the bulk of the design and implementation effort in the
construction phase

6. A detailed software development plan, with an updated risk assessment, a management plan, a
staffing plan, a phase plan showing the number and contents of the iteration , an iteration plan, and a
test plan.
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.

3. Construction Phase:
The Construction phase is a manufacturing process. It emphasizes managing resources and
controlling operations to optimize costs, schedules and quality.
This phase is broken into several iterations.
 The product and artifacts of the previous iteration. The iteration plan must state the iteration
specific goals
 Risks being mitigated during this iteration.
 Defects being fixed during the iteration.
Construction – Activities:
 Develop and test components.
Components required satisfying the use cases, scenarios, and other functionality for the
iteration are built. Unit and integration tests are done on Components.
 Manage resources and control process.
 Assess the iteration
Satisfaction of the goal of iteration is determined

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, timeboxed
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 Overview diagrams. The Initial
Operational Capability Milestone marks the end of the Construction phase.

4. Transition phase: The transition phase is the phase where the product is put in the hands of its
end users. It involves issues of marketing, packaging, installing, configuring, supporting the user-
community, making corrections, etc.
The product and artifacts of the previous iteration, and in particular a software product sufficiently
mature to be put into the hands of its users.

7. Transition – Activities:
 Test the product deliverable in a customer environment.
 Fine tune the product based upon customer feedback
 Deliver the final product to the end user
 Finalize end-user support material
An update of some of the previous documents, as necessary, the plan being replaced by a “post-
mortem” analysis of the performance of the project relative to its original and revised success criteria.

A brief inventory of the organization’s new assets as a result this cycle.
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.

8. 3.UML DIAGRAMS





 The UML is the standard diagramming notation for drawing or presenting pictures .
 This standard is given by Object Management Group(OMG – is a industry standard body for
object oriented related standard) in 1997 with UML1.0
 Founders of UML -1)Grady Booch 2) Ivar Jacobson 3) Jim Rumbaugh
 The complete standard is available in www.omg.org


UML Diagrams are














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 the existing code in UML
diagrams.
2) Forward engineering - for code generation .
o If reverse engineering, a UML tool reads the source or binaries and generates
(typically) UML package, class, and sequence diagrams. These "blueprints" can help
the reader understand the big-picture elements, structure, and collaborations.
o Before programming, some detailed diagrams can provide guidance for code
generation (e.g., in Java), either manually or automatically with a tool. It's common
that the diagrams are used for some code, and other code is filled in by a developer
while coding (perhaps also applying UML sketching).
 UML as programming language : Executable code will be automatically generated.
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing
and documenting the artifacts of software systems, as well as for business modeling and other
non-software systems.

1) Use case Diagram
2) Class Diagram
3) Package Diagram
4) Behavioral Diagram
4.1) Interaction Diagram
a) Sequence Diagram
b) Communication Diagram
4.2) State Chart Diagram
4.3) Activity Diagram
5) Implementation Diagram
5.1) Component Diagram
5.2) Deployment Diagram

9. Three Perspectives to Apply UML:
The same UML class diagram notation can be used to draw pictures of concepts in the real
world or software classes in Java.
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).


Case study – the Next Gen POS system
 The NextGen POS system is a computerized application used to record the sales and handle
payments.
 This system is normally used at retail shops for handling the payment and sales.
 A POS system is a replacement for a cash register that adds many computer services to the
traditional cash register. Most retail stores now use POS systems.
 This system consists of hardware components such as computers, barcode reader, printer and
software to run the system.
 This system is also connected to other services such as inventory management system,
Payment validation system or tax calculator system.
 These systems must be relatively fault tolerant(i.e) even if remote services are temporarily
unavailable, they must be capable of capturing sales and handling atleast cost payments.
 The POS system must be connected to varied interfaces.
 A POS system must support multiple and varied client side terminal and interfaces.
 The POS system should support the clients having personal computers, touch screen monitors,
PDA, wireless communication media and so on.
 The POS system must be flexible and customized enough to add or delete any new
component.

10. 2 . INCEPTION

Introduction : Inception is the initial short step to establish a common vision and basic scope for
the project. It will include analysis of 10% of the use case , analysis of the critical non functional
requirements , creation of business case and preparation of the development environment.

 Determine the product scope, vision and business case.
 Purpose is to decide whether to proceed with development not to define requirements.
 Only key requirements are investigated.

PROBLEM STATEMENT:
Do the stakeholders have basic agreement on the vision of the project and is it worth investing.

INCEPTION ARTIFACTS:
1. VISION AND BUSSINESS CASE
 Describes the high level goals and constraints , the business case and provide an
executive summary.
 Estimate of costs and expected benefit stated in financial terms.
2. USE CASE MODEL
 Describes the functional and related non functional requirements.
 The names of most of the expected use cases and actors.
3. SUPPLEMENTARY SPACIFICATION
 Describes the non functional requirements that do not appear elsewhere.
 Functional requirements describe the functionality of the product.
4. GLOSSARY
 Describes the key terms in the business domain
5. RISK PLAN
 Describes the risks and ideas for their mitigation or response.
6. PROTOTYPES/PROOF OF CONCEPTS
 These may be developed to clarify the vision, or to validate technical ideas.
7. ITERATION PLAN
 Describes what to do in the first iteration of the product.
 Usually implements the core functionality of the product.
 Eliminate biggest risk first.
8. PHASE/SOFTWARE DEVELOPMENT PLAN
 A low precision guess for the duration and effort of the elaboration.
 Includes tools, people, training and other resources required.
 May also be called a Resource Plan.

11. 9. DEVELOPMENT CASE
 A description of the Unified Process steps and artifacts for the project.
 The UP is always customized for each project.

4.USE CASE

Use cases are text stories, widely used to discover and record functional requirements. Use cases are
requirements, primarily functional or behavioral requirements that indicate what the system will do.
Use cases are text documents , not diagrams and usecase modeling is primarily an act of writing text
, not drawing diagrams. stories, widely used to discover and record functional requirements

Definition: Actors, Scenarios, and Use Cases

Actor: An actor is something with behavior, such as a person (identified by role), computer system,
or organization; for example, a cashier.

Scenario: A scenario is a specific sequence of actions and interactions between actors and the
system; it is also called a use case instance. It is one particular story of using a system, or one path
through the use case; for example, the scenario of successfully purchasing items with cash, or the
scenario of failing to purchase items because of a credit payment denial.

Usecase: A use case is a collection of related success and failure scenarios that describe an actor
using a system to support a goal.
For example, here is a casual format use case with alternate scenarios

Handle Returns
Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the
POS system to record each returned item ...
Alternate Scenarios:
If the customer paid by credit, and the reimbursement transaction to their credit account is rejected,
inform the customer and pay them with cash.
If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the
identifier code (perhaps it is corrupted).
If the system detects failure to communicate with the external accounting system.




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. Primary and supporting actors will appear in the action steps of
the use case text. Actors are roles played not only by people, but by organizations, software, and
machines.
There are three kinds of external actors in relation to the SuD(System under Development):
NOTE: Black-box use cases are the most common and recommended kind; they do not describe the
internal workings of the system, its components, or design.





1. Primary actor
2. Supporting actor
3. Offstage actor

12. Primary actor has user goals fulfilled through using services of the SuD.
For example, the cashier. Why identify? To find user goals, which drive the use cases.
Supporting actor provides a service (for example, information) to the SuD.
The automated payment authorization service is an example. Often a computer system, but could be
an organization or person. Why identify? To clarify external interfaces and protocols.
Offstage actor has an interest in the behavior of the use case, but is not primary or supporting; for
example, a government tax agency. Why identify? To ensure that all necessary interests are identified
and satisfied. Offstage actor interests are sometimes subtle or easy to miss unless these actors are
explicitly named.
Three Common Use Case Formats :
1)Brief - one-paragraph summary, usually of the main success scenario. The prior Process Sale
example was brief.
Example Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the
POS (Point of Sale) system to record each purchased item. The system presents a running total and
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.
2)Casual - Informal paragraph format. Multiple paragraphs that cover various scenarios. The prior
Handle Returns example was casual.
Example:
Handle Returns : Main Success Scenario: A customer arrives at a checkout with items to return. The
cashier uses the POS system to record each returned item …
Alternate Scenarios: If the customer paid by credit, and the reimbursement transaction to their credit
account is rejected, inform the customer and pay them with cash.
If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the
identifier code (perhaps it is corrupted)
. If the system detects failure to communicate with the external accounting system,
3) fully dressed - All steps and variations are written in detail, and there are supporting sections, such
as preconditions and success guarantees.

13. Example:
Use Case Section Comment
Use Case Name Process Sale
Scope Next Generation POS System
Level
1. User Goal Level
2. Sub Function 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.
Preconditions Cashier is identified and authenticated
Success Guarantee

Sale is saved , Tax is correctly calculated , Accounting and
Inventory are updated . Commission is recorded. Receipt is
generated , Payment Authorization approval are recorded.
Main Success
Scenario
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
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated
6. Cashier tells customer the total and asks for payment
7. Customer pays and system handles payment
8. System log completed sale and sends sale and payment
information to the external accounting system and inventory

14. system
9. System presents receipt
10. Customer leaves with receipt and goods
Extensions 3a. Invalid Item ID
1. System signals error and reject entry
2. Cashier responds to the error
2a. There is a human readable itemID
Special Requirements Touch Screen UI on a large flat on a large panel monitor.
Credit Authorization response within 30 seconds 90 % of the
time.

To Find Use Cases:
Use cases are defined to satisfy the goals of the primary actors.
Hence, the basic procedure is:











Use Case Diagram:
It is an excellent picture of the system context . It is good context diagram showing the boundary of
the system what lies outside of it & how it gets used. Serves as a communication tool that summarizes
the behavior of a system & its actors.
UML Notations:
Name Symbol Description
1. Choose the system boundary. Is it just a software application, the hardware and application
as a unit, that plus a person using it, or an entire organization?
2. Identify the primary actors those that have goals fulfilled through using services of the
system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually,
usergoal level use cases will be one-to-one with user goals, but there is at least one exception,
as will be examine

15. Actor


anything with behavior
Non-human
Actor





Non human actors are
usually not primary users,
and thus are usually
shown on the right, not the
left.
Use case A set of scenarios that
describing an interaction
between a user and a
system, including
alternative
System











A system is shown as a
rectangle, labeled with the
system name.
Actors are outside the
system.

Use cases are inside the
system.

The rectangle shows the
scope or boundary of the
system.
Association
Relationship
An association is the
communication path
between an actor and the
use case that it
participates in.
It is shown as a solid line
include

dashed line with an open
arrow pointing from the
base use case to the
inclusion use case. The
keyword «include» is
attached to the connector.
Extend

dashed line with an open
arrowhead pointing from
the extension use case to
the base use case. The
arrow is labeled with the
keyword «extend»

<<actor>>

16. generalize

Generalization is shown as
a directed arrow with a
triangle arrowhead.
The child use case is
connected at the base of
the arrow. The tip of the
arrow is connected to the
parent use case.



Tests To Find Useful Use Cases
There are several rules of thumb, including:






The Boss Test : To check for achieving results of measurable value If an use case is not strongly
related to achieving results of measurable value then it fails in BOSS test .
For Example Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is
your boss happy?, If not, the use case fails the Boss Test.

The EBP Test: An Elementary Business Process (EBP) is a term from the business process
engineering field, defined as: “ EBP is similar to the term user task in usability engineering, although
the meaning is less strict in that domain”. A task performed by one person in one place at one time,
in response to a business event, which adds measurable business value and leaves the data in a
consistent state, e.g., Approve Credit or Price Order [original source lost]. The EBP Test is similar
to the Boss Test, especially in terms of the measurable business value qualification.

The Size Test: A use case typically contains many steps, and in the fully dressed format will often
require 3- 10 pages of text, Defining a use case called “ Enter an Item ID” fails in size test , because
of its length in fully dressed text, it would be extremely short. single step usecases fails in size test.

RELATING USE CASES – INCLUDE, EXTEND, GENERALIZE

Use cases can be related to each other. Three types of relationships are





The include Relationship:

Separating some partial behavior that is common across several usecases .This is simply
refactoring and linking text to avoid duplication.
The Boss Test
The EBP Test
The Size Test

1.The include Relationship
2.The extend Relationship
3.The generalize Relationship

17. Use case include is a directed relationship between two use cases which is used to show that
behavior of the included use case (the addition) is inserted into the behavior of the including (the
base) use case.

For example :Paying by credit occurs in several use cases like Process Sale, Process Rental .
Rather than duplicate this text, it is desirable to separate it into its own subfunction use case, and
indicate its inclusion




<<include>>




<<include>>


Concrete, Abstract, Base, and Addition Use Cases:
A concrete use case is initiated by an actor and performs the entire behavior desired by the actor .
For example, Process Sale is a concrete use case.
An abstract use case is never instantiated by itself; it is a subfunction use case that is part of another
use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is
always part of another story, such as Process Sale.
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. Process Sale is a base use case with respect to the included Handle
Credit Payment sub function use case.
Addition Use case the use case that is an inclusion, extension, or specialization is
called an addition use case. Handle Credit Payment is the addition use case in the include
relationship to Process Sale.
Addition use cases are usually abstract. Base use cases are usually concrete.

HANDLE CREDIT
PAYMENT
PROCESS RENTAL
PROCESS SALE

18. Example 2:

The extend Relationship:
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 .
If use case text should not be modified & continually modifying use case is a maintenance headache
, in that case we can use extend relationship
For example:

This is an example of an extend relationship. The use of an extension point, and that the extending
use case is triggered by some condition. Extension points are labels in the base use case which the

19. extending use case references as the point of extension, so that the step numbering of the base use
case can change without affecting the extending use case.






Generalize:
Generalization is a relationship between two entities such that one entity (child) inherits the
functionality of another entity (parent). It can exist between two actors or two use cases. The
behavior of the ancestor is inherited by the descendant. This is used when there is common behavior
between two use cases and also specialized behavior specific to each use case.
• there might be a use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”,
“Pay by Bank Balance” etc.




USE CASE DIAGRAM FOR NEXTGEN POS SYSTEM: