Ooad unit 1

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
OBJECT ORIENTED ANALYSIS & DESIGN
CHAPTER:1 ( OBJECT-ORIENTED ANALYSIS AND DESIGN)
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
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 sampleiterative development processare taken . It includes
 Apply principles and patterns to create better object designs.
 Iteratively follow a set of common activities in analysis and design, based on an agile approach to
the UP as an example.
 Create frequently used diagrams in the UML notation.
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. Design ideas often exclude low-level or "obvious" detail.
1.2What is Object-Oriented Analysis and Design?
Object-Oriented Analysis : It emphasis on finding and describing the objectsor conceptsin the
problem domain. For example, in the case of the flight information system, some of the concepts include
Plane, Flight, and Pilot.
Object-Oriented Design: It emphasis on defining software objects and how they collaborate to
fulfill the requirements. For example, a Plane software object may have a tailNumber attribute and a
getFlightHistory method.
During implementation or object-oriented programming, design objects are implemented, such as
a Plane class in Java.
Figure 1.2. Object-orientation emphasizes representation of objects.

Example: a simple example a "dice game" in which software simulates a player rolling two dice. If the
total is seven, they win; otherwise, they lose.
i) Define Use Cases : Requirements analysis may include stories or scenarios of how people use the
application; these can be written 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
There is an identification of the concepts, attributes, and associations that are considered
important.The result can be expressed in a domain model that shows the important. domain concepts or
objects.
Figure 1.3. Partial domain model of the dice game.
This model illustrates the important concepts Player, Die, and DiceGame, 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 objectstheir 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.4 illustrates an OO software design, by sending
messages to instances of the DiceGame and Die classes.
Notice that although in the real world a player rolls the dice, in the software design the DiceGame
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 are not direct models or simulations of the real
world.
Figure 1.4. Sequence diagram illustrating messages between software objects.
iv) Define Design Class Diagrams: 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.5. Since a play message is sent to a DiceGame object, the DiceGame
class requires a play method, while class Die requires a roll and getFaceValue method.
Figure 1.5. Partial design class diagram.
1.3What is the UML?
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 - describes the structure of a system by showing the system's classes, their
attributes, and the relationships among the classes.
2) Use – Case Diagram - 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 lifespan of 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.
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 the hardware.
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 software system 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 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).

The Meaning of "Class" in Different Perspectives
 Conceptual class real-world concept or thing. A conceptual or essential perspective. The UP
Domain Model contains conceptual classes.
 Software class a class representing a specification or implementation perspective of a software
component, regardless of the process or method.
 Implementation class a class implemented in a specific OO language such as Java.
Basic Concepts of Object Orientation
 Class
 Object
 Attributes
 Methods
 Inheritance
 Encapsulation and Information Hiding
 Polymorphism
 Message
Class :The role of a class is to define the attributes and methods (the state and behavior) of its instances.
The class car, for example, defines the property color.
Each individual car (object) will have a value for this property, such as "maroon,""yellow" or "white."
Class Hierarchy
An object-oriented system organizes classes into subclass-super hierarchy.
At the top of the hierarchy are the most general classes and at the bottom are the most specific.
A subclass inherits all of the properties and methods (procedures) defined in its super class.
Object : The term object was first formally utilized in the similar language to simulate some aspect of
reality. An object is an entity.
It knows things (has attributes)
It does things (provides services or has methods)
Attributes or properties describe object‘s state (data) and methods define its behavior. In an object-
oriented system, everything is an object: numbers, arrays, records, fields, files, forms, an invoice, etc.
An Object is anything, real or abstract, about which we store data and those methods that manipulate the
data.
Conceptually, each object is responsible for itself.
A window object is responsible for things like opening, sizing, and closing itself.
A chart object is responsible for things like maintaining its data and labels, and even for drawing itself.
Attributes :Attributes represented by data type.
They describe objects states
In the Car example the car‘s attributes are:Color, manufacturer, cost, owner, model, etc.,

Methods
Methods define objects behavior and specify the way in which an Object‘s data are manipulated.
In the Car example the car‘s methods are: drive it, lock it, tow it, carry passenger in it. Inheritance
(programming by extension)
Inheritance is a relationship between classes where one class is the parent class of another (derived)
class.
Inheritance allows classes to share and reuse behaviors and attributes. The real advantage of inheritance
is that we can build upon what we already have and, Reuse what we already have
.Multiple Inheritances : OO systems permit a class to inherit from more than one super class.
This kind of inheritance is referred to as multiple inheritance.
Encapsulation and Information Hiding Information hiding is a principle of hiding internal data and
procedures of an object By providing an interface to each object in such a way as to reveal as little as
possible about its inner workings. Encapsulation protects the data from corruption.
Polymorphism Polymorphism means that the same operation may behave differently on different
classes. Example: compute Payroll.
Message Objects perform operations in response to messages.
For example, you may communicate with your computer by sending it a message from handhelp
controller.
CHAPTER 2 (ITERATIVE, EVOLUTIONARY, AND AGILE)
1.4.1What 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.
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 explain OOA/D.
3. The UP is flexible, and can be applied in a lightweight and agile approach that includes practices
from other agile methods
Iterative and Evolutionary Development : A key practice in both the UP and most other modern
methods is iterative 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 (see Figure 2.1). Because feedback and
adaptation evolve the specifications and design, it is also known as iterative and evolutionary
development.
Figure 2.1. Iterative and evolutionary development.

Notice in this example that there is neither a rush to code, nor a long drawn-out design step that
attempts to perfect all details of the design before programming. The system may not be eligible for
production deployment until after many iterations; for example, 10 or 15 iterations.
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.
 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 2.2.
Figure 2.2. Iterative feedback and evolution leads towards the desired system. The requirements
and design instability lowers over time.
Benefits of Iterative Development
 less project failure, better productivity, and lower defect rates; shown by research into iterative and
evolutionary methods
 early rather than late mitigation of high risks (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?
 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 is good.
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.
1.4.2 The Waterfall Lifecycle
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
Percentage of change on software projects of varying sizes.
The Needfor Feedback and Adaptation
In complex, changing systems feedback and adaptation are key ingredients for success.
 Feedback from early development, programmers trying to read specifications, and client 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 schedule and
estimates.
 Feedback from the client and marketplace to re-prioritize the features to tackle in the next
iteration.
1.4.3 What is 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
1.4.4 What are Agile Methods and Attitudes?
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 agilityrapid and flexible response to change.
The Agile Manifesto and Principles
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter time scale.
4. Business people and developers must work together daily throughout the project
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
10. Continuous attention to technical excellence and good design enhances agility
11. . Simplicitythe art of maximizing the amount of work not doneis essential
12. The best architectures, requirements, and designs emerge from self-organizing teams.
13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.

This example assumes there will ultimately be 20 iterations on the project before delivery:
Figure 2.4. Evolutionary analysis and designthe majority in early iterations.
1.5.1 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.
.This is not the old "waterfall" or sequential lifecycle of first defining all the requirements, and then
doing all or most of the design.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 implemented, and high-risk
issues are mitigated.

Figure 2.6. Schedule-oriented terms in the UP.
1.5. 2 The UP Disciplines
Disciplines 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, and so on.There are several disciplines in the UP:
 Business Modeling- The Domain Model artifact, to visualize noteworthy concepts in the
application domain.
 Requirements -The Use-Case Model and Supplementary Specification artifacts to capture
functional and non-functional requirements.
 Design - The Design Model artifact, to design the software objects
What is the Relationship Betweenthe Disciplines and Phases?

Definition: the Development Case: The choice of practices and UP artifacts for a project may be written
up in a short document called the Development Case (an artifact in the Environment discipline).
Discipline Practice Artifact Incep. Elab. Const. Trans.
Iteration
I1 E1..En C1..Cn T1..T2
Business
Modeling
agile modeling
req. workshop
Domain Model
s
Requirements req. workshop
vision box
exercise dot
voting
Use-Case
Model
s r
Vision s r
Supplementary
Specification
s r
Glossary s r
Design agile modeling
test-driven dev.
Design Model s r
SW
Architecture
Document
s
Data Model s r
Implementati
on
test-driven dev.
pair programming
continuous
integration coding
standards
…
Project
Management
agile PM daily
Scrum meeting
…
…
Table 2.1. Sample Development Case. s - start; r - refine
CHAPTER 3. (CASE STUDIES)
1.6 CASE STUDY :
Applications include UI elements, core application logic, database access, and collaboration with
external software or hardware components. This introduction to OOA/D focuses on the core application
logic layer, with some secondary discussion of the other layers.

Why focus on OOA/D in the core application logic layer?
 Other layers are usually very technology/platform dependent. For example, to explore the OO
design of a Web UI or rich client UI layer in Java, we would need to learn in detail about a
framework such as Struts or Swing.
 In contrast, the OO design of the core logic layer is similar across technologies.
 The essential OO design skills learned in the context of the application logic layer are applicable to
all other layers or components.
 The design approach/patterns for the other layers tends to change quickly as new frameworks or
technologies emerge.
Sample layers and objects in an object-oriented system, and the case study focus.
The NextGenPOS 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 (so that the business 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, and so forth.
 we are creating a commercial POS system that we will sell 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.
CHAPTER 4.(INCEPTION IS NOT THE REQUIREMENTS PHASE )
1.7 Inception: 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 detaildone in the service 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.
Table 4.1. Sample inception artifacts.
Activities
in
Inception:
Inception is
a short step
to
elaboration.
It
determines
basic
feasibility,
risk, and
scope, to
decide if the
project is
worth more
serious
investigatio
n.
Activities
and artifacts
in inception
Artifact Comment
Vision and Business
Case
Describes the high-level goals and constraints, the business
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% of
the use cases will be analyzed in detail.
Supplementary
Specification
Describes 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 Plan
Describes the risks (business, technical, resource, 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 Plan
Low-precision guess for elaboration phase duration and effort.
Tools, people, education, and other resources.
Development Case A description of the customized UP steps and artifacts for this
project. In the UP, one always customizes it for the project.

include:
 a short requirements workshop
 most actors, goals, and use cases named
 most use cases written in brief format; 1020% of the use cases are written in fully dressed 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 the technical 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 in elaboration
o For example, a recommendation to buy a tax calculation package.
 high-level candidate architecture and components proposed
o 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
 candidate tools list
CHAPTER : 6 (USE CASES)
1.8.1 Introduction : 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
1.8.2Definition: What are 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.
1.8.3Use 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.
1.8.4Motivation: Why Use Cases?

 Lack of user involvement in software projects is near the top of the list of 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.
1.8.5Definition: Are Use Cases 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
What are Three Kinds of Actors?
An actor is anything with behavior, including the system under discussion (SuD) itself when it
calls upon the services of other systems. 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:
 Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.
o 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.
o 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.
o 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.
1.8.6Three 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 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 "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.
Use Case UC1: Process Sale : Fully DressedFormat 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 debug Cashier
problems.
- Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such
as national, state, and county.
- Payment Authorization Service: Wants to receive digital authorization requests in the correct
format and protocol. Wants to accurately account for their payables to the store.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting and
Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are
recorded.
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules.
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 logs completed sale and sends sale and payment information to the external Accounting
system (for accounting and commissions) and Inventory system (to update inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
1. System enters Manager-authorized mode.
2. Manager or Cashier performs one Manager-mode operation. e.g., cash balance change,
resume a suspended sale on another register, void a sale, etc.
3. System reverts to Cashier-authorized mode.
*b. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and events can be
recovered from any step of the scenario.
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records the error, and enters a clean

state.
1a. Customer or Manager indicate to resume a suspended sale.
1. Cashier performs resume operation, and enters the ID to retrieve the sale.
2. System displays the state of the resumed sale, with subtotal.
2a. Sale not found.
1. System signals error to the Cashier.
2. Cashier probably starts new sale and re-enters all items.
3. Cashier continues with sale (probably entering more items or handling payment).
2-4a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples)
1. Cashier verifies, and then enters tax-exempt status code.
2. System records status (which it will use during tax calculations)
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.
- Somehow, we want robust recovery when access to remote services such the inventory system is
failing.
- Language internationalization on the text displayed.
- Pluggable business rules to be insertable at steps 3 and 7.
- …
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or entering an
authorization code via the keyboard.
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
…
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
- What are the tax law variations?
- Explore the remote service recovery issue.

- What customization is needed for different businesses?
- Must a cashier take their cash drawer when they log out?
- Can the customer directly use the card reader, or does the cashier have to do it?
Format Description:
Scope :It can be either system use case or Business Usecase .
 system use case :A use case describes use of one software system
 business use case: At a broader scope, use cases can also describe how a business is used by its
customers and partners. Such an enterprise-level process description is called a business use case.
Level:Use cases are classified as at the user-goal level or the sub function level, among others.
A user-goal level use case is the common kind that describe the scenarios to fulfill the goals of a primary
actor to get work done.
A subfunction-level use case describes substeps required to support a user goal, and is usually created to
factor out duplicate substeps shared by several regular use cases an example is the subfunction use case
Pay by Credit, which could be shared by many regular use cases.
Primary Actor :The principal actor that calls upon system services to fulfill a goal.
Stakeholders and Interests ListIt satisfies all the stakeholders' interests. by starting with the
stakeholders and their interests before writing the remainder of the use case, we have a method to remind
us what the more detailed responsibilities of the system should be.
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 and Success Guarantees (Postconditions)
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. Typically, a
precondition implies a scenario of another use case, such as logging in, that has successfully completed.
Main Success Scenario and Steps (or Basic Flow)This has also been called the "happy path" scenario,
or the more prosaic "Basic Flow" or "Typical Flow." It describes a typical success path that satisfies the
interests of the stakeholders. Note that it often does not include any conditions or branching.
The scenario records the steps, of which there are three kinds:
1. An interaction between actors.
2. A validation (usually by the system).
3. A state change by the system (for example, recording or modifying something).
Main Success Scenario:

1. Customer arrives at a POS checkout with items to purchase.
3. Cashier enters item identifier.
4. …
Cashier repeats steps 3-4 until indicates done.
5. …
Extensions (or Alternate Flows)
Extension scenarios are branches (both success and failure) from the main success scenario, and so
can be notated with respect to its steps 1…N. For example, at Step 3 of the main success scenario there
may be an invalid item identifier, either because it was incorrectly entered or unknown to the system. An
extension is labeled "3a"; it first identifies the condition and then the response. Alternate extensions at
Step 3 are labeled "3b" and so forth.
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.
An extension has two parts: the condition and the handling.
Guideline: When possible, write the condition as something that can be detected by the system or an
actor.
This extension example also demonstrates the notation to express failures within extensions.
7b. Paying by credit:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment Authorization Service
System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
Performing Another Use Case Scenario
Sometimes, a use case branches to perform another use case scenario. For example, the story Find
Product Help (to show product details, such as description, price, a picture or video, and so on) is a
distinct use case that is sometimes performed while within Process Sale (usually when the item ID can't be
found).

3a. Invalid item ID (not found in system):
1. System signals error and rejects entry.
2. Cashier responds to the error:
2a. …
2c. Cashier performs Find Product Help to obtain true item ID and price.
Special Requirements
If a non-functional requirement, quality attribute, or constraint relates specifically to a use case,
record it with the use case. These include qualities such as performance, reliability, and usability, and
design constraints (often in I/O devices) that have been mandated or considered likely.
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.
- Pluggable business rules to be insertable at steps 2 and 6.
Technology and Data Variations List
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." It is also necessary to understand variations in data schemes, such
as using UPCs or EANs for item identifiers, encoded in bar code symbology.
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.
1.8.7 Guidelines
Guideline1. Write in an Essential UI-Free Style
Guideline : Write use cases in an essential style; keep the user interface out and focus on actor intent.
Essential Style
Assume that the Manage Users use case requires identification and authentication:
1. Administrator identifies self.
2. System authenticates identity.
3. …

The design solution to these intentions and responsibilities is wide open: biometric readers, graphical user
interfaces (GUIs), and so forth.
Concrete StyleAvoid 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:
1. Administrator enters ID and password in dialog box
2. System authenticates Administrator.
3. System displays the "edit users" window
4. …
Guideline2. 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 thinkingsoftware 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 case definition, 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 their goals and
typical situations.
 Focus on understanding what the actor considers a valuable result.
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 actorsthose 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: Brainstorm the primary actors first, as this sets up the framework for further investigation.
the following questions help identify others that may be missed:
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 the system if it
fails?
Who evaluates system activity or
performance?
How are software updates handled? Push or pull update? Who evaluates logs? Are they remotely
retrieved?
In addition to human primary actors, are there any external
software or robotic systems that call upon services of the
system?
Who gets notified when there are errors or
failures?
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 case diagram.
For example:
Actor Goal Actor Goal
Cashier process sales
process rentals
handle returns
cash in
cash out…
System
Administrator
add users
modify users
delete users
manage security
manage system tables…
Manager start up
shut down…
Sales Activity
System
analyze sales and
performance data
… … … …

Is the Cashier or Customer the Primary Actor?
The answer depends on the system boundary of the system under design, and who we are
primarily designing the system for the viewpoint of the POS system the system services the goal of a
trained cashier (and the store) to process the customer's sale.
Figure 6.2. Primary actors and goals at different system boundaries.
The customer is an actor, but in the context of the NextGen POS, not a primary actor; rather, the
cashier is the primary actor because the system is being designed to primarily serve the trained cashier's
"power user" goals. The system does not have a UI and functionality that could equally be used by the
customer or cashier. Rather, it is optimized to meet the needs and training of a cashier.
Second Method to Find Actors and Goals - Event Analysis
Another approach to aid in finding actors, goals, and use cases is to identify external events. What
are they, where from, and why? Often, a group of events belong to the same use case. For example:
External Event From Actor Goal/Use Case
enter sale line item Cashier process a sale
enter payment Cashier or Customer process a sale
…
Step 4: Define Use Cases
In general, define one use case for each user goal. Name the use case similar to the user goalfor
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 CRUD use 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
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 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. 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 measurable business value
qualification.
The Size Test
A use case typically contains many steps, and in the fully dressed format will often require 310
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 sizethe 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
o Much broader and longer than an EBP. Could be modeled as a business use case, rather
than a system use case.
 Handle Returns
o OK with the boss. Seems like an EBP. Size is good.
 Log In
o Boss not happy if this is all you do all day!
 Move Piece on Game Board
o Single stepfails the size test.
1.8.8Applying UML: Use Case Diagrams
 The UML provides use case diagram notation to illustrate the names of use cases and actors, and
the relationships between them
 Use case diagrams and use case relationships are secondary in use case work. Use cases are text
documents. Doing use case work means to write text.
Figure 6.3. Partial use case context diagram.

Guideline
 Use case diagram is an excellent picture of the system context
 It makes a good context diagram that is, showing the boundary of a system, what lies outside of it,
and how it gets used.
 It serves as a communication tool that summarizes the behavior of a system and its actors.
Guideline: Diagramming
Notice the actor box with the symbol «actor». This style is used for UML keywords and
stereotypes, and includes guillemet symbolsspecial single-character brackets («actor», not <<actor>>)
Figure 6.4. Notation suggestions.
Figure 6.5. Alternate actor notation.

USECASE MODELING:
The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case
is a single unit of meaningful work; for example login to system, register with system and create order
are all Use Cases. Each Use Case has a description which describes the functionality that will be built
in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another
Use Case with its own behavior. Use Cases are typically related to 'actors'. An actor is a human or
machine entity that interacts with the system to perform meaningful work. Actors
An Actor is a user of the system. This includes both human users and other computer systems.
An Actor uses a Use Case to perform some piece of work which is of value to the business.
The set of Use Cases an actor has access to define their overall role in the system and the scope of their
action.
Constraints, Requirements and Scenarios
The formal specification of a Use Case includes:
1. Requirements:
These are the formal functional requirements that a Use Case must provide to the end user. They
correspond to the functional specifications found in structured methodologies. A requirement is a
contract that the Use Case will perform some action or provide some value to the system.
2. Constraints:
These are the formal rules and limitations that a Use Case operates under, and includes pre-
post- and invariant conditions. A pre-condition specifies what must have already occurred or be in place
before the Use Case may start. A post-condition documents what will be true once the Use Case is
complete. An invariant specifies what will be true throughout the time the Use Case operates.
3. Scenarios:
Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance.
These are usually described in text and correspond to a textual representation of the Sequence
Diagram.
Chapter :30(RELATING USE CASES )
1.9.1 Introduction
Use cases can be related to each other. For example, a subfunction 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.
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 subfunction use case, and indicate its inclusion.
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: IncludeHandle Credit Payment.
7c. Paying by check: IncludeHandle Check Payment.
…
UC7: Process Rental
…
Extensions:
6b. Paying by credit: IncludeHandle Credit Payment.
…
This is the includerelationship.A slightly shorter (and thus perhaps preferred) notation to indicate an
included use case is simply to underline it or highlight it in some fashion. For example:
UC1: Process Sale
…
Extensions:
7b. Paying by credit: Handle Credit Payment.
7c. Paying by check: Handle Check Payment.
…
Notice that the Handle Credit Paymentsubfunction use case was originally in the Extensions section of the
Process Sale use case, but was factored out to avoid duplication.

 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.
The include relationship could be used:
 to simplify large use case by splitting it into several use cases,
 to extract common parts of the behaviors of two or more use cases.
Use case B is extracted from larger use case A into a separate use case.
Use cases B and C are extracted from larger use case A into separate use cases.
When two or more use cases have some common behavior, this common part could be extracted into a
separate use case to be included back by the use cases with the UML include relationship.
Use case C is extracted from use cases A and B to be reused by both use cases using UML include
relationship.
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.
Example:
Paying by credit: Include Handle Credit Payment
The basic notation is to use the a*, b*, ... style labels in the Extensions section


Checkout use case includes several use cases - Scan Item,
Calculate Total and Tax, and Payment
Deposit Funds and Withdraw Cash use
cases include Customer Authentication use case.
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 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.
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
Paymentsubfunction use case. On the other hand, the use case that is an inclusion, extension, or
UC1: Process FooBars
…
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-11. Customer cancels: Cancel Transaction Confirmation.

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 behavior of some base use case. For example:
UC1: Process Sale (the base use case)
…
Extension Points:VIP Customer, step 1. Payment, step 7.
1.Customer arrives at a POS checkout with goods and/or services to purchase.
…
7.Customer pays and System handles payment.
…
UC15: Handle Gift Certificate Payment (the extending use case)

…Trigger: Customer wants to pay with gift certificate.
Extension Points: Payment in Process Sale.
Level:Subfunction
1. Customer gives gift certificate to Cashier.
2. Cashier enters gift certificate ID.
…
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
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.
Generalization:
Generalization can be defined as a relationship which connects a specialized element with a generalized
element. It basically describes inheritance relationship in the world of objects.
Complicated work and unproductive time is spending in this use case relationship. Use case
experts are successfully doing use case work without this relationship.
Generalization between use cases is similar to generalization between classes; child use
case inherits properties and behavior of the parent use case and may override the behavior of the parent.
Use case include relationship in the Use-Case Model.

Figure 30.2. The extend relationship.
Use Case Relationships Compared
Examples :
This is an example of a business use case diagram which is usually created during Business
Modeling and is rendered here in Rational Unified Process(RUP) notation.
Business actors are Passenger, Tour Guide, Minor (Child), Passenger with Special Needs (e.g.
with disabilities), all playing external roles in relation to airport business.
Business use cases are Individual Check-In, Group Check-In (for groups of tourists), Security
Screening, etc. - representing business functions or processes taking place in airport and serving the
needs of passengers.
Business use cases Baggage Check-in and Baggage Handling extend Check-In use cases, because
passenger might have no luggage, so baggage check-in and handling are optional.

Part –A (2- MARKS)
1. Define -- Actors, Scenarios and Use Cases (A/M-08) (2 Marks)
An actor is something with behaviour, 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.
2. List the types and categories of requirements. (2 Marks)
In the UP, requirements are categorized as the following,
2) Functional - features, capabilities, security.
3) Usability - human factors, help, documentation.
4) Reliability - frequency of failure, recoverability, predictability.
5) Performance - response times, throughput, accuracy, availability, resourceusage.
6) Supportability - adaptability, maintainability, internationalization, configurability.
3. Define – Requirements (2 Marks)
Requirements are capabilities and conditions, to which the system and more broadly, the project
must conform,
1) The UP promotes a set of best practices, one of which is to managerequirements.
2) In the context of changing and unclear stakeholder’s wishes – Managing requirements means
a systematic approach to finding, documenting, organizing, and tracking the changing
requirements of a system.
A prime challenge of requirements analysis is to find, communicate, and remember (To write
down) what is really needed, in a form that clearlyspeaks to the client and development team
members.
4. Define − Inception (2 Marks)

The inception is defined as an envision of product scope, vision, and business case.
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 do all requirements or creates believable estimates or
plans. That happens during elaboration.
5. State the intent of inception phase. (2 Marks)
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.
6. What is generalization? (2 Marks)
Generalization is the activity of identifying commonality among concepts and defining superclass
(general concept) and subclass (specialized concept) relationships.
7. What are association role names? (2 Marks)
Each end of an association is a role, which has various properties, such as:
1. Name
2. Multiplicity
A role name identifies an end of an association and ideally describes the role played by objects in the
association.
8. What is qualified association? (2 Marks)
A qualifier may be used in an association; it distinguishes the set of objects at the far end of the
association based on the qualifier value. An association with a qualifier is a qualified association. For
example, Product Descriptions may be distinguished in a ProductCatalog by their itemID.
9. Write the format to name an association in UML. (2 Marks)
Name in an association is based on a Class Name-Verb Phrase- Class Name format where the
verb phrase creates a sequence that is readable and meaningful.
10. What is multiplicity?
Multiplicity defines how many instances of class A can be associated with one instance of a class B.
Stocks
Store
Item
1 +
11. State the
reason to avoid adding many associations. (2 Marks)
We need to avoid adding too many associations to a domain model. In discrete mathematics, in a
graph with n nodes, there can be associations to other nodes a potentially very large number. A
domain model with 20 classes could have 190 associations’ lines! Many lines on the diagram will
obscure it with "visual noise." Therefore, be parsimonious about adding association lines.
12. What is an association? (2 Marks)
An association is a relationship between classes (more precisely, instances of those classes) that
indicates some meaningful and interesting connection.
13. Draw the UML notation for an association. (2 Marks)
Associations are defined as semantic relationship between two or more classifiers that involve
connections among their instances.

Register Sale
Records-current
14. List the
elements not suitable in adomain model. (2 Marks)
The elements not suitable in a domain model are:
1. Software artifacts, such as a window or a database, unless the domain being modeled are of
software concepts, such as a model of graphical user interfaces.
2. Responsibilities or methods.
15. Why domain model is called as a "Visual Dictionary"? (2 Marks)
The information domain model illustrates could alternatively have been expressed in plain text. But
it's easy to understand the terms and especially their relationships in a visual language, since our
brains are good at understanding visual elements and line connections. Therefore, the domain model is
a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the
domain.
16.What is an elaboration? (M/J − 12) (2 Marks)
Elaboration is used to build the core architecture, resolve the high-risk elements, define most
requirements, and estimate the overall schedule and resources.
16. List the three kinds of actors. (2 Marks)
Actors are roles played not only by people, but by organizations, software, and machines. The
three kinds of external actors in relation to the SuD are,
1) Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.
2) Supporting actor provides a service (for example, information) to the SuD. The automated

38
payment authorization service is an example. Often a computer system, but could be
an organization or person.
3) Offstage actor has an interest in the behaviour of the use case, but is not
primaryor supporting; for example, a government tax agency.
17. What are the preconditions and post conditions of scenarios?(2
Marks)
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. Typically, a precondition implies a scenario of another use
case, such as logging in, that has successfully completed.
Success guarantees (or post conditions) 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.
EXAMPLE:
Preconditions: Cashier is identified and authenticated.
SuccessGuarantee (Postconditions): Sale is saved.
Tax is correctlycalculated.
Accounting and Inventory are updated. Commissions recorded. Receipt is generated.
18. List the steps to find use cases.(N/D-12) (2 Marks)
Use cases are defined to satisfy the goals of the primary actors. Hence, the basic
procedures are,
1) Choose the system boundary
2) Identify the primary actors those that have goals fulfilled through using services of
the system.
3) Identify the goals for each primaryactor.
Define use cases that satisfy user goals; name

Ooad unit 1

More Related Content

What's hot (20)

Similar to Ooad unit 1 (20)

Recently uploaded (20)

Ooad unit 1