lOMoARcPSD|15579617

CS8592 OOAD UNIT 1 Notes

OOAD (Anna University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by hema kesaven ([email protected])
 lOMoARcPSD|15579617

UNIT I UNIFIED PROCESS AND USE CASE DIAGRAMS

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

1. Introduction to OOAD with OO Basics

 List the advantage of Object Oriented Development.(2)

 Delineate Object-Oriented Analysis and Design(2)[NOV/DEC 2021, NOV/DEC
2020]

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 object oriented analysis and design is presented

and practiced in the context of some development process. An agile (light, flexible)
approach to the well- known Unified Process (UP) is used as the sample iterative
development process. It includes the following rules

 Apply principles and patterns to create better object designs.

 Iteratively follow a set of common activities in analysis and design, based on an
agileapproach to the UP as an example.
 Create frequently used diagrams in the UML notation.

Object-Oriented Analysis and Design

Object-oriented analysis, is an emphasis of finding and describing the objects or

concepts in the problem domain. For example, in the case of the library information
system, some of the concepts include Book, Library, and Patron.
Object-oriented design, is an emphasis of defining software objects and how
they collaborate to fulfill the requirements. For example, in the library system, a Book
software object may have a title attribute and a get Chapter method (see Figure 1.1)

Finally, during implementation or object-oriented programming, design objects

are implemented, such as a Book class in Java.

Fig 1.1 Object Oriented emphasizes representation of objects

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Example:

i) Define Use Cases : Requirements analysis may include stories or scenarios of

how people use the application. It is referred as use cases. They are a popular tool in
requirements analysis. For example, the Play a Dice Game use case:

Play a Dice Game: Player requests to roll the dice. System presents results: If
the dice face value totals seven, player wins; otherwise, player loses.

ii) Define a Domain Model

Object-oriented analysis is concerned with creating a description of the domain

from the perspective of classification by objects. A decomposition of the domain
involves an identification of the concepts, attributes, and associations. The result in
the domain model expresses the domain concepts or objects.

For example, a partial domain model is shown in Fig 1.2

Figure 1.2 Partial domain model of the dice game

This model illustrates the important concepts of Player, Die, and Dice Game,
with their associations and attributes. It is a visualization of the concepts or mental
models of a real- world domain. Thus, it has also been called a conceptual object
model.

iii) Assign Object Responsibilities and Draw Interaction Diagrams

Object-oriented design is concerned with defining software objects their

responsibilities and collaborations. It shows the flow of messages between software
objects, and thus the invocation of methods.

For example, the sequence diagram in Figure 1.3 illustrates an Object oriented

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

software design, by sending messages to instances of the Dice Game and Die classes.

In the real world a player rolls the dice, in the software design the Dice
Game object "rolls" the dice (that is, sends messages to Die objects). Software
object designs and programs do take some inspiration from real-world domains, but
they arenot direct models or simulations of the real world.

Sequence diagram illustrating messages between software objects.

Fig 1.3 Interaction diagram illustrating between software objects

iv) Define Design Class Diagrams:

In addition to a dynamic view of collaborating objects shown in interaction

diagrams,it is useful to create a static view of the class definitions is usefully shown with
a design class diagram. This illustrates the attributes and methods of the classes.
For example, in the dice game, an inspection of the sequence diagram leads to
the partial design class diagram shown in Figure 1.4. Since a play message is sent to a
DiceGame object, the DiceGame class requires a play method, while class Die requires
a roll and get FaceValue method.

Fig 1.4 Partial design class diagram.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

2. UNIFIED PROCESS

 Explain in detail about Iterative and Evolutionary Development of unified

process with a suitable example?

 Define Unified Process Model? Exemplify the iterations, NOV/DEC 2021]

2.1 Unified Process:

The unified process model (or UPM) is an iterative, incremental, architecture-

centric, and use-case driven approach to software development. Unified Process is based
on the enlargement and refinement of a system through multiple iterations, with cyclic
feedback and adaptation.

The UP combines commonly accepted best practices, such as an iterative

lifecycle and risk-driven development, into a cohesive and well-documented
process description.

UP for three reasons

1. The UP is an iterative process.
2. UP practices provide an example structure for how to do and thus how to
explainOOAD.
3. The UP is flexible, and can be applied in a lightweight and agile
approach thatincludes practices from other agile methods
Iterative and Evolutionary Development

 In this lifecycle approach, development 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.
 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 specifications and design, it is also known
as iterative and evolutionary development.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Fig 1.5 Iterative and evolutionary development.

To Handle Change on an Iterative Project

 Each iteration involves choosing a small subset of the requirements, and

quickly designing, implementing, and testing
 In addition to requirements clarification, activities such as load testing will
prove if the partial design and implementation are on the right path, or if in the
next iteration, a change in the core architecture is required.

Fig 1.6 Iterative feedback and evolution leads towards the desired system.

The requirements anddesign instability lowers over time.

 Work proceeds through a series of structured build-feedback-adapt cycles. in

early iterations the deviation from the "true path" of the system (in terms of its
final requirements and design) will be larger than in later iterations. Over time,
the system converges towards this path, as illustrated in Figure

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Benefits of Iterative Development

 less project failure, better productivity, and lower defect rates; shown by
researchinto 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 thatmore closely meets the real needs of the stakeholders
 managed complexity; the team is not overwhelmed by "analysis paralysis"
or verylong and complex steps
 the learning within an iteration can be methodically used to improve the
developmentprocess itself, iteration by iteration

Iteration Time boxing

 Most iterative methods recommend an iteration length between two and six
weeks.
 Small steps, rapid feedback, and adaptation are central ideas in iterative
development; long iterations subvert the core motivation for iterative
development and increase project risk.
 A very long time-boxed iteration misses the point of iterative development.
Short isgood.

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 completiondate.
In a waterfall lifecycle process there is an attempt to define all or most of the
requirements before programming. It is strongly associated with

 high rates of failure

 lower productivity
 higher defect rates

Fig 1.7 Percentage of change on software projects of varying sizes.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

The Need for Feedback and Adaptation

In complex, changing systems feedback and adaptation are key ingredients for
success.
 Feedback from early development, programmers trying to read
specifications, andclient demos to refine the requirements.
 Feedback from tests and developers to refine the design or models.
 Feedback from the progress of the team tackling early features to refine the
scheduleand estimates.
 Feedback from the client and marketplace to re-prioritize the features to
tackle in thenext iteration.

Risk-Driven and Client-Driven Iterative Planning

The UP encourages a combination of risk-driven and client-driven iterative

planning. This means that the goals of the early iterations are chosen to 1) identify and
drive down the highest risks, and 2) build visible features that the client cares most
about.
Risk-driven iterative development includes more specifically the practice of
architecture-centric iterative development, i.e early iterations focus on building,
testing, and stabilizing the core architecture
2.2 UNIFIED PHASES:
A UP project organizes the work and iterations across four major phases:
1. Inception - Inception is a feasibility phase where enough investigation is done to
support a decision to continue or stop. It includes
• Approximate vision
• Business case
• Scope
• Vague estimates
2. Elaboration - Elaboration is the phase where the core architecture is
iteratively implemented. Here the high risk issues are mitigated.
Elaboration includes
• Refined vision
• Iterative implementation of the core architecture
• Resolution of high risks
• Identification of most requirements and scope
• More realistic estimates
3. Construction – It involves iterative implementation of the remaining lower
risk and easierelements, and preparation for deployment.
4. Transition – It involves beta tests, deployment.
Inception is not a requirements phase; rather, it is a feasibility phase, where
investigation is done to support a decision to continue or stop.
Similarly, elaboration is a phase where the core architecture is iteratively

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

implemented,and high-risk issues are mitigated.

Figure 1.8 Schedule-oriented terms in the UP.

2.3 UP Disciplines

Disciplines is a set of activities (and related artifacts) in one subject area, such
as the activities within requirements analysis. In the UP, an artifact is the general
term for any work product: code, Web graphics, database schema, text documents,
diagrams, models.
There are several disciplines in the UP

Fig 1.9 UP Disciplines

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

 Business Modeling - The Domain Model artifact, to visualize the concepts in

the application domain.
 Requirements - The Use Case Model and Supplementary Specification
artifacts tocapture functional and non-functional requirements.
 Design - The Design Model artifact, to design the software objects.

Relationship Between the Disciplines and Phases

Fig 1.10 Disciplines and phases

Development Case:
The choice of practices and UP artifacts for a projectmay be written up in a short
document called the Development Case (an artifact in the Environment discipline).

Discipline Practi Artifact Incep. Elab. Const. Trans.

ce
I1 E1..En C1..Cn T1..T2
Iteration
Business agile modeling Domain Model
s
Modeling req.workshop
Requirements req. workshop Use-Case
s r
vision box exercise Model
dot voting Vision s r
Supplementar
s r
ySpecification
Glossary s r
Design agile modeling Design Model s r
test-driven dev.
SW
Architectur s
eDocument
Data Model s r

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Implementation test-driven dev. …

pair programming
continuous
integrationcoding
standards
Project agile PM daily …
Management Scrummeeting
…

Table 1.1 Sample Development Case of UP Artifacts s-start; r – refine

3. UML DIAGRAMS

 Deliberate different notations of UML diagrams in detail.(13)[NOV/DEC 2021]

UML (Unified Modeling Language)

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

and documenting the artifacts of systems. The word visual in the definition is a key
point -the UML is the de facto standard diagramming notation for drawing or
presenting pictures. The standard is managed, and was created, by the Object
Management Group. It was first added to the list of OMG adopted technologies in
1997.

UML is composed of 9 graphical diagrams:

1) Class Diagram – It describes the structure of a system by showing the

system's classes, their attributes, and the relationships among the classes.

2) Use Case Diagram – It describes the functionality provided by a system in

terms of actors, their goals represented as use cases, and any dependencies
among those use cases.
3) Behavior Diagram
a. Interaction Diagram
i. Sequence Diagram - shows how objects communicate with each
other in terms of a sequence of messages. Also indicates the
lifespanof objects relative to those messages.
ii. Communication diagram:- how the interactions between
objects or parts in terms of sequenced messages.

b. State Chart Diagram - describes the states and state transitions of the
system.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

c. Activity Diagram - describes the business and operational step-by-step

workflows of components in a system. An activity diagram shows the
overall flow of control.
4) Implementation Diagram
a. Component Diagram - describes how a software system is split up into
components and shows the dependencies among these components.

b. Deployment Diagram - describes the hardware used in system

implementations and the execution environments and artifacts
deployed on thehardware.

Three Ways to Apply UML

 UML as sketch : Informal and incomplete diagrams 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 : UML tool reads the source or binaries and

generates UML package, class, and sequence diagrams to visualize and better
understanding of existing code in UML diagrams .

2) Forward Engineering : code generation . 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

 UML as programming language : Complete executable specification of a

softwaresystem in UML. Executable code will be automatically generated

Three Perspectives to Apply UML

The same UML class diagram notation can be used to draw pictures of concepts in
the realworld 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).

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Fig 1.12 The Meaning of "Class" in Different Perspectives

 Conceptual class is a real-world concept or thing. A conceptual or essential

perspective.The UP Domain Model contains conceptual classes.
 Software class is a class representing a specification or implementation
perspective ofa software component, regardless of the process or method.
 Implementation class is a class implemented in a specific OO language such as
Java.

4. USE CASE

 List any two common ways to relate use cases and give suitable examples.(2)
[NOV/DEC 2020]

Use Case Diagrams:

A use case describes a function that a system performs to achieve the user’s goal. A
use case must yield an observable result that is of value to the user of the system.

Purpose of use case:

 Determine the requirements of the system

 Describe what the system should do
 Provide a basis for testing to ensure that the system works as intended

Actor:

An actor represents a role of a user that interacts with the system that you are
modelling. The user can be a human user, an organization, a machine, or another
external system.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Example 1: Use case diagram for Passport Automation System

Example 2: Use case diagram for Library Management System

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

5.CASE STUDY

 Generalize the concepts of Next Gen POS system? Briefly

explain about Inception Phase.(13)

Applications can collaborate with other software or hardware components and contain
user interface (UI) components, core application logic, database access, and database
access. With some discussion of the other layers in support, this OOAD introduction
mostly focuses on the fundamental application logic layer.

NEXTGEN POS SYSTEM

The NextGen POS(Point of Sale) System

 A POS system is a computerized application used (in part) to record sales and
handlepayments; 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
andinventory 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 (so that thebusiness is not crippled).

A POS system increasingly must support multiple and varied client-side terminals and
interfaces. 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.

Create a commercial POS system that sells to different clients with disparate needs in
terms of business rule processing. 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. Therefore, we will need a mechanism to
provide this flexibility and customization.

Using an iterative development strategy, we are going to proceed through requirements,

object-oriented analysis, design, and implementation.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

6.INCEPTION

 What artifacts may start in Inception? How much UML is required during
Inception?(10)

The purpose of the inception phase is not to define all the requirements, or
generate a believable estimate or project plan. Most requirements analysis occurs
during the elaboration phase, in parallel with early production-quality programming
and testing.
 Inception ( in one sentence ) - Envision the product scope, vision, and business
case.
 It may include the first requirements workshop, planning for the first
iteration, and then quickly moving forward to elaboration. Common
inception artifacts and indicates the issues they address.
 For example, the Use-Case Model may list the names of most of the expected
use cases and actors, but perhaps only describe 10% of the use cases in detail
done in theservice of developing a rough high-level vision of the system scope,
purpose, and risks.
 Note that some programming work may occur in inception in order to create
"proof of concept" prototypes, to clarify a few requirements via UI-oriented
prototypes, and to do programming experiments for key "show stopper"
technical questions.
Artifact Comment
Vision and Business Describes the high-level goals and constraints, the business
Case case,and provides an executive summary.
Use-Case Model Describes the functional requirements. During inception,
the names of most use cases will be identified, and perhaps
10% ofthe use cases will be analyzed in detail.
Supplementar Describes other requirements, mostly non-functional.
ySpecification During inception, it is useful to have some idea of the key
non- functional requirements that have will have a major
impact onthe architecture.
Glossary Key domain terminology, and data dictionary.
Risk List & Risk Describes the risks (business, technical, resource, schedule)
Management andideas for their mitigation or response.
Plan
Prototypes and proof- To clarify the vision, and validate technical ideas.
of-concepts
Iteration Plan Describes what to do in the first elaboration iteration.
Phase Plan & Low-precision guess for elaboration phase duration
Software andeffort. Tools, people, education, and other
Development Plan resources.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Development Case A description of the customized UP steps and artifacts for

thisproject. In the UP, one always customizes it for the
project.

Table 1.2 Sample inception artifacts.

Activities in Inception:

Inception is a short step to elaboration. It determines basic feasibility, risk, and

scope, todecide if the project is worth more serious investigation.

Activities and artifacts in inception include:

 A short requirements workshop

 Most actors, goals, and use cases named
 Most use cases written in brief format; 10-20% of the use cases are written
in fullydressed detail to improve understanding of the scope and
complexity
 Most influential and risky quality requirements identified
 Version one of the vision and supplementary specification written
 Risk list
 Technical proof-of-concept prototypes and other investigations to
explore thetechnical feasibility of special requirements
 User interface-oriented prototypes to clarify the vision of functional requirements
 Recommendations on what components to buy/build/reuse, to be
refined inelaboration
For example, a recommendation to buy a tax calculation package.
 High-level candidate architecture and components proposed
This is not a detailed architectural description, and it is not meant to be
final or correct. Rather, it is brief speculation to use as a starting point of
investigation in elaboration.
For example, "A Java client-side application, no application server,
Oracle for the database,” In elaboration, it may be proven worthy, or
discovered to be a poor idea and rejected.
 Plan for the first iteration

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

7. USECASE MODELLING

 Elaborate use case modeling process with suitable examples.(13)[NOV/DEC

2020]
 Classify the various format of use case and use case template with an
example.(8)
 Explain the Guidelines for writing and finding use cases.(8)
 Explain the benefits and concepts of use case and use case model and analyze
the relating use cases have in ATM system(13)

Use cases are text stories, widely used to discover and record requirements. use cases
are text stories of some actor using a system to meet goals. There are 3 formats to
represent the use case
I) Brief Format
II) Casual Format
III) Fully Dressed Format

Definition: Actors, Scenarios, and Use Cases

An actor is something with behavior, such as a person (identified by role),

computer system, or organization; for example, a cashier.

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.
A use case is a collection of related success and failure scenarios that describe
an actor using a system to support a goal.

Use Cases and the Use-Case Model

 Use cases are text documents, not diagrams, and use-case modeling is
primarily an act of writing text, not drawing diagrams.
 There are also the Supplementary Specification, Glossary, Vision, and Business
Rules. These are all useful for requirements analysis.
 The Use-Case Model may optionally include a UML use case diagram to show
the names of use cases and actors, and their relationships. 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.

Motivation: Use Cases

 Lack of user involvement in software projects is near the top of the list of

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

reasons for project failure. Use cases are a good way to help keep it simple, and
make it possible for domain experts or requirement donors to themselves
write use cases.
 Another value of use cases is that they emphasize the user goals and
perspective; we ask the question "Who is using the system, what are their
typical scenarios of use, and what are their goals?" This is a more user-centric
emphasis compared to simply asking for a list of system features.

Definition: Functional Requirements

Use cases are requirements, primarily functional or behavioral

requirements that indicate what the system will do. A related viewpoint is that a use
case defines a contract of how a system will behave.

Three Kinds of Actors:

An actor is anything with behaviour, 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:

1. 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.
2. 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.
3. 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

 Brief - Terse one-paragraph summary, usually of the main success

scenario. The prior Process Sale example was brief. It was created during early
requirements analysis, to get a quick sense of subject and scope. May take only
a few minutes to create.
 Example : 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

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

leaves with the items. Notice that use cases are not diagrams, they are text.

 Casual - Informal paragraph format. Multiple paragraphs that cover various

scenarios. It was created during early requirements analysis, to get a quick
sense of subject and scope. May take only a few minutes to create.

Example : Handle Returns Usecase

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 . If the system detects failure to communicate with the
external accounting system,

Fully Dressed - All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees. It was created , after many use
cases have been identified and written in a brief format, then during the first
requirements workshop a few (such as 10%) of the architecturally significant and high-
value use cases are written in detail.

Use Case Section Comment

Use Case Name Start with a verb.
Scope The system under design.
Level "user-goal" or "sub function"
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
tellingthe 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 Varying I/O methods and data formats.
VariationsList
Frequency of Occurrence Influences investigation, testing, and timing of
implementation.
Miscellaneous Such as open issues.
Table 1.3 Use case template

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Use Case UC1: Process Sale : Fully Dressed Format Example

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. Wants automatic and fast
update of accounting and inventory.
Manager: Wants to be able to quickly perform override operations, and easily
debugCashier problems.
Government Tax Agencies: Want to collect tax from every sale. May be
multipleagencies, such as national, state, and county.

Payment Authorization Service: Wants to receive digital authorization requests in

thecorrect format and protocol, wants to accurately account for their payables to the
store. Preconditions: Cashier is identified and authenticated.

Success Guarantee (or Post conditions): Sale is saved. Tax is correctly

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

Guidelines For Use Case Modelling:

Guideline 1. Write in an Essential UI-Free Style

Guideline : Write use cases in an essential style; keep the user interface out and
focus onactor intent.

Essential Style

Assume that the Manage Users use case requires identification and authentication:

Administrator identifies self.

System authenticates identity.3. …

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

The design solution to these intentions and responsibilities is wide open: biometric
readers,graphical user interfaces (GUIs), and so forth.

Concrete Style Avoid During Early Requirements Work

In contrast, there is a concrete use case style. In this style, user interface
decisions are embedded in the use case text. The text may even show window screen
shots, discuss window navigation, GUI widget manipulation and so forth. For example:

Administrator enters ID and password in dialog box

System authenticates Administrator.
System displays the "edit users" window
4. …

Guideline 2. Write Terse Use Cases : Delete "noise" words. Even small changes
add up,such as "System authenticates…" rather than "The System authenticates…"

Guideline 3 : Write Black-Box Use Cases : 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. Rather, the system is described as having
responsibilities, which is a common unifying metaphorical theme in object-oriented
thinking software elements have responsibilities and collaborate with other elements
that have responsibilities.

Black-box style Not Recommended

The system records the sale. The system writes the sale to a database. …or (even worse):

The system generates a SQL INSERT statement for the sale…

Guideline 4 : Take an Actor and Actor-Goal Perspective : Here's the RUP use
casedefinition, from the use case founder Ivar Jacobson:

A set of use-case instances, where each instance is a sequence of actions a

system performs that yields an observable result of value to a particular actor. It
stresses two attitudes during requirements analysis:

 Write requirements focusing on the users or actors of a system, asking

about theirgoals and typical situations.
 Focus on understanding what the actor considers a valuable result.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Guideline 5: To Find Use Cases

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

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, user-
goal level use cases will be one-to-one with user goals, but there is at least one exception,
as will be examined.

Step 1: Choose the System Boundary

The POS system itself is the system under design; everything outside of it is
outside the system boundary, including the cashier, payment authorization service,
and so on. For example, is the complete responsibility for payment authorization
within the system boundary? No, there is an external payment authorization service
actor.

Steps 2 and 3: Find Primary Actors and Goals

Guideline: Identify the primary actors first, as this sets up the framework for
furtherinvestigation. The following questions helps to identify other actors .

Who starts and stops the system? Who does system administration?
Who does user and security management? Is "time" an actor because the system
does something in response to a time
event?
Is there a monitoring process that restarts Who evaluates system activity or
thesystem if it fails? performance?
How are software updates handled? Push or pull Who evaluates logs? Are they
update? remotely retrieved?
In addition to human primary actors, are there any Who gets notified when there are
external software or robotic systems that call upon errors or failures?
services of the system?

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Representing Goals of an Actor :

There are at least two approaches:

1. Draw them in a use case diagram, naming the goals as use cases.
2. Write an actor-goal list first, review and refine it, and then draw the
use casediagram.

For example:

Actor Goal Actor Goal

Cashier Process sales System Add users
process Administrator modify users
rentals delete users
handle manage security
returns cash manage system
in tables…
cash out…
Manager start up Sales Activity analyze sales and
shut down… System performance data
… … … …

Step 4: Define Use Cases

In general, define one use case for each user goal. Name the use case similar
to theuser goal for example,

Goal: process a sale; Use Case: Process Sale.

Start the name of use cases with a verb. A common exception to one use
case per goal is to collapse CRUD (create, retrieve, update, delete) separate goals
into one CRUDuse case, idiomatically called Manage <X>. For example, the goals
"edit user," "delete user," and so forth are all satisfied by the Manage Users use
case.

Guideline 6: Tests To Find Useful Use Cases

There are several rules of thumb, including:

 The Boss Test

 The EBP Test
 The Size Test

The Boss Test : To check for achieving results of measurable value

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

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, which implies it is not
strongly related to achieving results of measurable value. It may be a use case at some
low goal level,but not the desirable level of focus for requirements analysis.

The EBP Test

 An Elementary Business Process (EBP) is a term from the business

processengineering field, defined as:

EBP is similar to the term user task in usability engineering, although the
meaningis less strict in that domain. Focus on use cases that reflect EBPs.

 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
 The EBP Test is similar to the Boss Test, especially in terms of the
measurablebusiness 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. A common mistake in use case modeling is to define
just a single step within a series of related steps as a use case by itself, such as defining
a use case called Enter an Item ID. You can see a hint of the error by its small size the
use case name will wrongly suggest just one step within a larger series of steps, and if
you imagine the length of its fully dressed text, it would be extremely large.

Example: Applying the Tests

 Negotiate a Supplier Contract

 Much broader and longer than an EBP. Could be modeled as a
business usecase, rather than a system use case.
 Handle Returns
 OK with the boss. Seems like an EBP. Size is good.
 Log In
 Boss not happy if this is all you do all day!
 Move Piece on Game Board
 Single step fails the size test.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

8.RELATING USE CASES

 With suitable example explain the use case include relationship and extend relationship.(13)
[NOV/DEC 2020]

Use cases can be related to each other. For example, a sub function use case such as Handle
Credit Payment may be part of several regular use cases, such as Process Sale and Process
Rental.

It is simply an organization mechanism to (ideally) improve communication and

comprehension of the use cases, reduce duplication of text, and improve management of
the use case documents

Example

Regular use cases like Process Sale. Process Rental can have sub functions use case like
HandleCredit Payment.

Relationship among use cases

• Improves communication and comprehension of use cases
• Reduces duplication of text
• Improves management of use case document
Writing the use case text is highly essential. This improves comprehension and reduces
duplication.

Kinds of relationships
1. The include Relationship
2. The extend Relationship
3. The generalize Relationship

1.The include 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.. Rather than duplicate this text, it is
desirable to separate it into its own sub function use case, and indicate its inclusion.

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.

Notice that the Handle Credit Payment sub function use case was originally in the

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Extensions section of the Process Sale use case, but was factored out to avoid duplication.

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.

UC7: Process Rental

Extensions: 6b. Paying by credit: Include Handle Credit Payment.

UC12: Handle Credit Payment

Level: Sub function Main Success Scenario:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment Authorization Service
System, and requests payment approval.
3. System receives payment approval and signals approval to Cashier.
4 . .Extensions:
2 2a . System detects failure to collaborate with external system:
1 1 . System signals error to Cashier.
2 Cashier asks Customer for alternate payment.

Using include with Asynchronous Event Handling

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

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. 2-1 1 .
Customer cancels: Cancel Transaction Confirmation.

Use cases and use the include relationship when

They are duplicated in other use cases.
A use case is very complex and long, and separating it into subunits aids
comprehension.

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 . These are the elementary business process use cases. For example, Process
Sale is a concrete use case.

 An abstract use case is never instantiated by itself; it is a sub function 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.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

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

 On the other hand, 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.
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 behaviour of some base use case. For example:

UC1: Process Sale (the base use case)

Extension Points: VIP Customer, step 1 . Payment, step 7. Main Success Scenario:
1 1. Customer arrives at a POS checkout with goods and/or services to purchase.
2 …..
…
7. Customer pays and System handles payment.
…

Fig 1.13 Use case include relationship in the Use-Case Model

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Fig 14 The Extend Relationship

3.The Generalization Relationship

 In the context of use case modeling the use case generalization refers to the
relationship which can exist between two use cases and which shows that one use
case (child) inherits the structure, behavior, and relationships of another actor
(parent).

 The child use case is also referred to the more specialized use case while the parent
is also referred to as the more abstract use case of the relationship.
 For those of you familiar with object oriented concepts: use cases in UML are
classes and the generalization is simply the inheritance relationship between two
use cases by which one use case inherits all the properties and relationships of
another use case.
 You can use the generalization relationship when you find two or more use cases
which have common behavior/logic. In this instance, you can describe the common
parts in a separate use case (the parent) which then is specialized into two or more
specialized child use cases.
Example:
If you are creating a payment system which allows students of a training provider to pay
for courses both on-line and by phone, there will many things in common between the two
scenarios: specifying personal info, specifying payment info, etc. However, there would
also be differences between the two. So, the best way to accomplish this is to create one
use case (the parent) which contains the common behaviour and then create two
specialized child use cases which inherit from the parent and which contain the
differences specific to registering on-line and by phone.

9. WHEN TO USE USECASE DIAGRAM

UML use case diagrams are ideal for:
 Representing the goals of system-user interactions
 Defining and organizing functional requirements in a system
 Specifying the context and requirements of a system
 Modelling the basic flow of events in a use case Reverse engineering.
 Forward Engineering.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

Fig.15 Online shopping System

Use case diagrams are valuable for visualizing the functional requirements of a system that
will translate into design choices and development priorities. They also help identify any
internal or external factors that may influence the system and should be taken into
consideration. Use case diagrams specify the events of a system and their flows. But use
case diagram never describes how they are implemented. Use case diagram can be
imagined as a black box where only the input, output, and the function of the black box is
known. Although use case is not a good candidate for forward and reverse engineering,
still they are used in a slightly different way to make forward and reverse engineering. The
same is true for reverse engineering. Use case diagram is used differently to make it
suitable for reverse engineering. In forward engineering, use case diagrams are used to
make test cases and in reverse engineering use cases are used to prepare the requirement
details from the existing application.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

ACTIVITY SHEET

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

ACTIVITY SHEET

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

QUESTION BANK
PART-A

1. What are the three ways and perspectives to Apply UML? [ MAY/JUNE 2015,
NOV/DEC 2015, NOV/DEC 2016, APR/MAY 2017]
2. Define Design Class Diagrams [NOV/DEC 2015,MAY/JUNE 2016]
3. What is Object-Oriented Analysis and Design? [APR/MAY 2011,MAY/JUNE 2013,
NOV/DEC 2013, MAY/JUNE 2014, APR/MAY 2017]
4. What is Inception?
5. Define Use case. [ NOV/JUN 2013, NOV/DEC 2011, APR/MAY 2018]
6. What Tests Can Help Find Useful Use Cases? [ MAY/JUNE 2016,NOV/DEC 2016]
7. Distinguish between method and message in object? [ MAY/JUNE 2015, NOV/DEC
2015]
8. What are the primary goals in the design of UML? [ NOV/DEC 2016]
9. List out the phases of unified process.[NOV/DEC 2021]
10. Define Object Oriented Analysis and Design.[NOV/DEC 2021]

PART-B

1. What do you mean by unified process in OOAD? Explain the phases with suitable
diagrams?
[ APR/MAY 2011,NOV/DEC 2011,MAY/JUNE 2012, NOV/DEC 2012,MAY/JUNE
2013, NOV/DEC 2013, NOV/DEC 2015, MAY/JUNE 2016,NOV/DEC 2016,
APR/MAY 2017, NOV/DEC 2017, NOV/DEC 2021]

2. List various UML diagrams and explain it.[MAY/JUNE 2014, NOV/DEC

2015,APR/MAY 2017]
3. What is UML Activity Diagram? Using an example explain the features of basic UML
activity diagram notation. [NOV/DEC 2013, MAY/JUNE 2016, NOV/DEC 2016]
4. Deliberate different notations of UML diagrams in detail.[NOV/DEC 2021]
5. With suitable example explain the use case include relationship and extend
relationship. [NOV/DEC 2020]
6. Elaborate use case modeling process with suitable examples.[NOV/DEC 2020]
7. Classify the various format of use case and use case template with an example.
8. Explain the Guidelines for writing and finding use cases.

9. Explain the benefits and concepts of use case and use case model and analyze the
relating use cases have in ATM system

10. What artifacts may start in Inception? How much UML is required during Inception?
11. Explain in detail about Iterative and Evolutionary Development of unified process
with a suitable example

12. Generalize the concepts of Next Gen POS system? Briefly explain
about Inception Phase.

Downloaded by hema kesaven ([email protected])

 lOMoARcPSD|15579617

PART-C
1. A mobile device has to be fitted with an alarm clock. The clock has a display unit
to show the time of day. Using buttons, the user can set the hours and minutes
fields individually. It supports a 24-hour display. It is possible to set one or two
alarms. When an alarm fires, it will sound some noise. The user can turn it off, or
choose to ‘snooze’. If the user does not respond at all the alarm will turn off
itself after 2 minutes. ‘Snoozing’ means to turn off the sound, but the alarm will
fire again after some minutes of delay. This ‘snoozing time’ is pre-adjustable.
Identify the functional requirements for the clock and model it with a use case
diagram.[NOV/DEC 2020]
2. A mobile device has to be fitted with an alarm clock. The clock has a display unit
to show the time of day. Using buttons, the user can set the hours and minutes
fields individually. It supports a 24-hour display. It is possible to set one or two
alarms. When an alarm fires, it will sound some noise. The user can turn it off, or
choose to ‘snooze’. If the user does not respond at all the alarm will turn off
itself after 2 minutes. ‘Snoozing’ means to turn off the sound, but the alarm will
fire again after some minutes of delay. This ‘snoozing time’ is pre-adjustable.
Identify the functional requirements for the clock and model it with a use case
diagram. [NOV/DEC 2021]

Downloaded by hema kesaven ([email protected])