SE616 – Software
|
|
Lecture |
Based
on Larman (Chaps 1 -6)
OBJECT-ORIENTED
ANALYSIS AND DESIGN
Applying UML and
Patterns in OOA/D
Emphasis:
·
how to assign responsibilities to objects
·
frequently used UML notation
·
common design patterns
·
how to think in objects
·
how to design object-oriented systems
System Design Questions:
·
How should responsibilities be
allocated to classes of objects?
·
How should objects interact?
·
What classes should do what?
Topics and
skills covered:
·
Apply
principles and patterns to create better object designs.
·
Follow
a set of common activities in analysis and design, based on the Unified Process
as an example.
·
Create
frequently used diagrams in the UML notation.
Assigning
Responsibilities
- Single practical skill: assign
responsibilities to software components.
- One
activity that must be performed-either while drawing a UML diagram or
programming
- It
strongly influences software’s:
- Robustness
- Maintainability
- Reusability
What Is Analysis
and Design?
- Analysis emphasizes an investigation
of the problem and requirements, rather than a solution.
- Design emphasizes a conceptual
solution that fulfills the requirements, rather than its
implementation
- Analysis
and design have been summarized in the phrase do the right thing
(analysis), and do the thing right (design).
What Is
Object-Oriented Analysis and Design?
·
Object-oriented
analysis - emphasis on finding and describing
the objects -or concepts- in the problem domain.
·
Object-oriented
design - emphasis on
defining software objects and how they collaborate to fulfill the requirements.
Example
Dice game - a player rolls two die. If the total
is seven, win – otherwise lose.
Define Use Cases
·
Requirements analysis may include a
description of related domain processes; these can be written as use cases.
·
Use cases are written stories
·
Popular tool in requirements analysis and are
an important part of the Unified Process.
·
e.g.
brief version of the Play a Dice Game use case:
Play a Dice
Game:
A player picks up and rolls the dice. If the dice face value
total seven, they win; otherwise, they lose.
Define a Domain Model
- Object-oriented
analysis is concerned with creating a description of the domain from the
perspective of classification by objects
- Decomposition
of the domain involves identification of the noteworthy:
- Concepts
- Attributes
- Associations
- Result
expressed in a domain model - illustrated
in a set of diagrams that show domain concepts or objects.
Partial domain model of the dice game
- Model
illustrates the concepts Player, Die, and DiceGame,
with their associations and attributes.
- Domain
model is not a description of software objects; it is a visualization of
concepts in the real-world domain.
Define Interaction Diagrams
- Object-oriented
design is concerned with defining software objects and their
collaborations.
- Interaction
diagram is common notation to illustrate collaborations
- Interaction
diagram shows the flow of messages between software objects,
and thus the invocation of methods.
- e.g., the interaction diagram illustrates the
essential step of playing, by sending messages to instances of the DiceGame and Die classes.
Interaction
diagram illustrating messages between software objects
·
Note:
although a real world player rolls the dice, in the software
design the DiceGame object "rolls"
the dice (i.e., sends messages to Die objects).
Define Design Class Diagrams
·
Dynamic view of collaborating objects -
interaction diagrams
·
Static view of the class definitions -
design class diagram.
·
Design class diagrams illustrate
the attributes and methods of the classes.
·
e.g., inspection of the dice game interaction
diagram leads to the partial design class diagram
o
Since a play message is sent to a DiceGame object, the DiceGame
class requires a play method
o
Class Die requires a roll and getFaceValue method
·
In contrast to the domain model, this diagram
does not illustrate real-world concepts; rather, it shows software classes.
Partial design class diagram
The UML
The Unified Modeling Language (UML) is
a language for specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business modeling and other
non-software systems.
o
The UML emerged as the de facto and de jure standard
diagramming notation for object-oriented modeling.
o
It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to
combine the diagramming notations from their two popular methods-the Booch and OMT (Object Modeling Technique) methods.
o
Later joined by Ivar
Jacobson, the creator of the Objectory method, and as a group came to be known as the three
amigos.
o
Many others contributed to the UML, perhaps
most notably Cris Kobryn, a
leader in its ongoing refinement.
o
The UML was adopted in 1997 as a standard by
the OMG (Object Management Group, an industry standards body),
ITERATIVE DEVELOPMENT AND
THE UNIFIED PROCESS
o Iterative
development is a skillful approach to software development that lies at the
heart of how OOA/D
o The
Unified Process is an example iterative process for projects using OOA/D
o The
Unified Process (UP) is a popular software development process for building
object-oriented systems.
o UP
combines commonly accepted best practices, such as an iterative lifecycle and
risk-driven development, into a cohesive and well-documented description.
Most Important UP Idea:
Iterative Development
o Development
is organized into a series of short, fixed-length (for example, four week)
mini-projects called iterations
o Outcome
of each iteration is a tested, integrated, and
executable system.
o Each iteration includes its own requirements analysis,
design, implementation, and testing activities.
o The
iterative lifecycle is based on the successive enlargement and refinement of a
system through multiple iterations, with cyclic feedback and adaptation
o Other
Names for Iterative Development:
o incremental
development
o spiral
development
o evolutionary
development
Iterative and incremental development
Embracing Change:
Feedback and Adaptation
o Each iteration involves choosing a small subset of the
requirements, and quickly designing, implementing, and testing.
o In
early iterations the choice of requirements and design may not be exactly what
is ultimately desired.
o Swiftly
taking a small step before all requirements are finalized leads to rapid
feedback
o Early
feedback is very important - rather than speculating on the correct
requirements or design, feedback from building and testing provides insight and
opportunity to modify or adapt understanding of the requirements or design.
o Work
proceeds through a series of structured build-feedback-adapt cycles.
Iterative feedback and adaptation leads
towards the desired system
Benefits of Iterative
Development
o early
mitigation of high risks (technical, requirements, objectives, usability, etc)
o early
visible progress
o early
feedback, user engagement, and adaptation, leading to a refined sys tem that more
closely meets the real needs of the stakeholders
o managed
complexity; the team is not overwhelmed by "analysis paralysis" or
very long and complex steps
o the
learning within an iteration can be methodically used to improve the
development process itself, iteration by iteration
Iteration Length and Timeboxing
o The
UP recommends an iteration length between two and six weeks.
o Small
steps, rapid feedback, and adaptation are central ideas in iterative
development:
o Much
less than two weeks, and it is difficult to complete sufficient work to get
meaningful through-put and feedback
o Much
more than six or eight weeks, and the complexity becomes rather overwhelming,
and feedback is delayed.
o Iterations
are timeboxed or fixed in length.
o e.g.
if the next iteration is chosen to be four weeks long, then the partial system should
be integrated, tested, and stabilized by the scheduled date.
o If
it will be difficult to meet the deadline, remove tasks or requirements from
the iteration, and include them in a future iteration.
o Massive
teams (e.g. several hundred developers) may require longer than six-week
iterations to compensate for the overhead of coordination and communication;
o Still
no more than three to six months is recommended.
Additional UP Practices
and Concepts Best
o Best
practice : use object technologies, including OOA/D
and object-oriented programming.
o Other
best practices and key concepts in the UP include:
o tackle
high-risk and high-value issues in early iterations
o continuously
engage users for evaluation, feedback, and requirements
o build
a cohesive, core architecture in early iterations
o continuously
verify quality; test early, often, and realistically
o apply
use cases
o model
software visually (with the UML)
o carefully
manage requirements
o practice
change request and configuration management
The UP Phases and
Schedule-Oriented Terms
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.
Schedule-oriented terms in the UP.
The UP Disciplines
(formally called Workflows)
o The
UP describes work activities
o Informally,
a discipline is a set of activities (and related artifacts) in one
subject area
o In
the UP, an artifact is the general term for any work product: code, Web
graphics, database schema, text documents, diagrams, models, etc.
o There
are several disciplines in the UP:
o Business
Modeling—
§ single application development, includes domain
object modeling.
§ large-scale business analysis or business process
reengineering, includes dynamic modeling of the business processes across the
entire enterprise.
o Requirements—Requirements
analysis for an application, such as writing use cases
and identifying non-functional requirements.
o Design—All
aspects of design, including the overall architecture, objects, databases,
networking, and the like.
More UP disciplines
o In
the UP, Implementation means programming and building the system
o The
Environment discipline refers to establishing the tools and customizing
the process for the project— setting up the tool and process environment.
Disciplines and Phases
o During one iteration - work goes on in most or all
disciplines.
o Relative
effort across these disciplines changes over time.
o Early
iterations tend to apply greater relative emphasis to requirements and design,
and later ones less so, as the requirements and core design stabilize through a
process of feedback and adaptation.
Above chart:
- Changing
relative effort with respect to the phases
- In
elaboration the iterations have a relatively high level of
requirements and design work, with some implementation.
- During
construction, the emphasis is heavier on implementation and lighter
on requirements analysis.
Process Customization and
the Development Case
Optional Artifacts
o Some
UP practices and principles are invariant, such as iterative and risk-driven
development, and continuous verification of quality.
o Key
insight into the UP is that all activities and artifacts (models, diagrams, documents,
...) are optional
o Select
a small subset of artifacts that a projects particular problems and needs.
o In
general, focus on a small set of artifacts that demonstrate high practical
value.
The Development Case
o The
choice of UP artifacts for a project may be written up in a short document
called the Development Case (an artifact in the Environment discipline).
The Agile UP
o Methodologists
speak of processes as heavy vs. light, and predictive vs. adaptive.
o A heavy
process is a pejorative term meant to suggest one with the following
qualities:
o many
artifacts created in a bureaucratic atmosphere
o rigidity
and control
o elaborate,
long-term, detailed planning
o predictive
rather than adaptive
o A predictive
process attempts to plan and predict the activities and resource (people)
allocations in detail over a relatively long time span, such as the majority of
a project.
o An
adaptive process accepts change as an inevitable driver and encourages
flexible adaptation
o An
agile process implies a light and adaptive process, nimble in response
to changing needs.
o The
UP was:
o Not
meant to be either heavy or predictive
o Meant
to be adopted and applied as an agile process.
o Some
examples of how this applies:
§ Prefer
a small set of UP activities and artifacts. Some projects will benefit from
more than others, but, in general, keep it simple.
§ Since
the UP is iterative, requirements and designs are not completed before
implementation. They adaptively emerge through a series of iterations, based on
feedback.
§ There
isn't a detailed plan for the entire project. There is a high level plan
(called the Phase Plan) that estimates the project end date and other major milestones, but
it does not detail the fine-grained steps to those milestones.
§ A
detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done
adaptively from iteration to iteration.
CASE STUDY: THE
NEXTGEN POS SYSTEM
The NextGen POS System
§ The case study is the NextGen point-of-sale (POS) system:
o A POS system is a computerized
application used (in part) to record sales and handle payments
o It includes hardware components such
as a computer and bar code scanner, and software to run the system.
o It interfaces to various service
applications, such as a third-party tax calculator and inventory control.
o 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.
o 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.
o 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.
o 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.
Architectural
Layers and Case Study Emphasis
o A typical object-oriented information
system is designed in terms of several architectural layers or subsystems
o
User Interface—graphical interface;
windows.
o
Application Logic and Domain
Objects-software objects representing domain concepts (for example, a software
class named Sale) that fulfill application
requirements.
o
Technical Services—general purpose objects and
subsystems that provide
supporting technical services, such as interfacing with a database or
error logging. These services are usually application-independent and reusable
across several systems.
o
The NextGen case
study primarily emphasizes the problem domain objects, allocating
responsibilities to them to fulfill the requirements of the application.
o
Object-oriented design is also applied to
create a technical service subsystem for interfacing with a database.
o
In this design approach, the UI layer has
very little responsibility; it is said to be thin. Windows do not
contain code that performs application logic or processing. Rather, task
requests are forwarded on to other layers.
INCEPTION
Most projects require a short initial step in which the
following kinds of questions are explored:
- What is the vision and business case for this
project?
- Feasible?
- Buy and/or build?
- Rough estimate of cost:
Is it $10K-100K or in the millions?
- Should we proceed or stop?
·
The purpose of the inception step is
to do just enough investigation:
o
to
form a rational, justifiable opinion of the overall purpose and feasibility of
the potential new system
o
decide if it is worthwhile
to invest in deeper exploration (the purpose of the elaboration phase).
·
Should be relatively short for most projects
- one or a few weeks long.
·
The
intent of inception phase is to:
o
establish
some initial common vision for the objectives of the project,
o
determine
if it is feasible
o
decide if it is worth some serious
investigation in elaboration.
What Artifacts May
Start in Inception?
Artifact
|
Comment
|
|
Vision and Business Case |
Describes high level goals and constraints, the business case,
and provides an executive summary |
|
Use-Case Model |
Describes the functional requirements |
|
Supplementary Specification |
Describes other requirements |
|
Glossary |
Key domain terminology |
|
Risk List and Risk Management Plan |
Describes the business, technical, resource, schedule risks, and
ideas for their migration and response |
|
Prototypes and proof-of-concept |
To clarify the vision and validate technical ideas |
|
Iteration Plan |
Describes what to do in the first elaboration iteration |
|
Phase Plan and 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 the
project. |
Isn't That a Lot of
Documentation?
o
Create artifacts that add value for the
project
o
Artifact are used for thinking not just
documenting
o
Record artifacts digitally and online rather than on paper.
o
UP artifacts from previous projects can be
reused on later ones.
o
All UP projects will organize artifacts the
same way, with the same names (Risk List, Development Case, and so on).
UNDERSTANDING
REQUIREMENTS
o
Requirements are
capabilities and conditions to which the system and the project must conform
o
Prime challenge of requirements work is to
find, communicate, and record what is needed, in a form that clearly speaks to
the client and development team members.
o
The UP promotes a set of best practices, one
of which is manage requirements.
o
a systematic approach to finding,
documenting, organizing, and tracking the changing requirements of a system
o One study of
factors on challenged projects revealed that 37% of factors related to problems
with requirements, making requirements issues the largest single contributor to
problems
Types of
Requirements
Requirements categorized according to the FURPS+ model:
- Functional—features, capabilities, security.
- Usability—human factors, help,
documentation.
- Reliability—frequency of failure,
recoverability, predictability.
- Performance—response times, throughput,
accuracy, availability, resource usage.
- Supportability—adaptability, maintainability,
internationalization, configurability.
The
"+" in FURPS+ indicates ancillary and sub-factors, such as:
o
Implementation—resource
limitations, languages and tools, hardware, ...
o
Interface—constraints imposed by interfacing
with external systems.
o
Operations—system management in its operational
setting.
o
Packaging
o
Legal—licensing and so forth.
·
Some of these requirements are collectively
called the quality attributes, quality requirements, or the "-ilities" of a system.
·
These include:
o usability,
o reliability
o performance
o supportability.
·
Requirements are categorized as functional
(behavioral) or non-functional (everything else)
USE-CASE
MODEL: WRITING REQUIREMENTS
IN CONTEXT
·
Use cases are a widely used mechanism to
discover and record requirements (especially functional);
·
Writing use cases—stories of using a
system—is an excellent technique to understand and describe requirements.
·
The UP defines the Use-Case Model
within the Requirements discipline.
Goals and Stories
·
Customers and end users have goals (also
known as needs in the UP)
·
Use cases are a mechanism to help keep it simple
and understandable for all stakeholders.
·
Informallyuse-cases are
stories of using a system to meet goals.
·
Brief format use case:
Process Sale: A customer arrives at a checkout with
items to purchase. The cashier uses the POS system to
record each purchased item. The system presents a running total and
line-item details. The customer enters payment information, which the system
validates and records. The system updates inventory. The customer receives a
receipt from the system and then leaves with the items.
Use Cases and
Adding Value
Informal
definitions:
·
An
actor is something with behavior, such as a
person (identified by role), computer system, or organization
·
A
scenario is a specific sequence of actions and interactions between actors
and the system under discussion also called a use case instance.
o It is one particular story of using a
system, or one path through the use case
·
A
use case is a collection of related success and failure scenarios that
describe actors using a system to support a goal.
·
e.g.
casual format use case that includes some alternate scenarios:
Handle
Returns
Main
Success Scenario: A
customer arrives at a checkout with items to return. The cashier uses the POS
system to record each returned item ...
Alternate
Scenarios:
If
they paid by credit, and the reimbursement transaction to heir
credit account is rejected, inform the customer
and pay them
with cash.
If the item identifier is not found in
the system, notify the Cashier and suggest manual entry of the identifier code
(perhaps it is corrupted).
If the system
detects failure to communicate with the external accounting system,
o
An alternate, but similar definition of a use
case:
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
.
o
The phrasing "an observable result of
value" is
subtle but important, because it stresses the attitude that the system behavior
should emphasize providing value to the user.
Use Cases and
Functional Requirements
o
Use cases are primarily functional
requirements that indicate what the system will do.
o
In terms of FURPS+ they emphasize the
"F" (functional or behavioral)
o
In the UP use cases are the central mechanism
that is recommended for their discovery and definition.
o
Use
cases define a promise or contract of how a system will behave.
o
Use cases are text documents, not diagrams.
o Use-case modeling is primarily an act of
writing text, not drawing.
o
However, the UML defines a use case diagram to illustrate the names of use
cases and actors, and their relationships
Use
Case Types and Formats
Black-Box Use Cases and System
Responsibilities
o Black-box use cases are the most common and
recommended
o They do not describe the
internal workings of the system, its components, or design.
o
The system is described as having responsibilities
o
Software elements have responsibilities and
collaborate with other elements that have responsibilities.
o
By defining system responsibilities with
black-box use cases, it is possible to specify:
o
what the system must do (the functional
requirements) without deciding
o
how it will do
it (the design).
Formality
Types
- Use cases
are written in different formats, depending on need.
- Use cases are written in varying degrees of
formality:
- brief—terse
one-paragraph summary, usually of the main success scenario.
- casual—informal
paragraph format. Multiple paragraphs that cover various scenarios.
- fully
dressed—the
most elaborate. All steps and variations are written in detail with
supporting sections, such as preconditions and success guarantees.
Fully
Dressed Example: Process Sale – NextGen Case Study
·
Fully
dressed use cases show more detail and are structured
·
Give
deep understanding of the goals, tasks, and requirements.
·
In
the NextGen POS case study, they would be created during one of the early requirements
workshops in a collaboration of the system analyst, subject matter experts, and
developers.
usecases.org Format
Various
format templates are available for fully dressed use cases.
Most widely
used and shared format is the template available at www.usecases.org.
Following example
illustrates this style.
larman pg
50-52
Use Case UC1:
Process Sale
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 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.
-
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 (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, 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.
2.
Cashier starts a new sale.
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.
3-6a:
Customer asks Cashier to remove an item from the purchase:
1.
Cashier enters item identifier for removal from sale.
2.
System displays updated running total.
3-6b.
Customer tells Cashier to cancel sale:
1.
Cashier cancels sale on System.
3-6c.
Cashier suspends the sale:
1.
System records sale so that it is available for retrieval on any POS terminal.
4a.
The system generated item price is not wanted (e.g.,
Customer complained about something and is offered a lower price):
1.
Cashier enters override price.
2.
System presents new price.
5a.
System detects failure to communicate with external tax calculation system
service:
1.
System restarts the service on the POS node, and continues.
1
a. System detects that the service does not restart.
1.
System signals error.
2.
Cashier may manually calculate and enter the tax, or cancel the sale.
5b.
Customer says they are eligible for a discount (e.g., employee, preferred
customer):
1.
Cashier signals discount request.
2.
Cashier enters Customer identification.
3.
System presents discount total, based on discount rules.
5c.
Customer says they have credit in their account, to apply to the sale:
1.
Cashier signals credit request.
2.
Cashier enters Customer identification.
3.
Systems applies credit up to price=0, and reduces remaining credit.
6a.
Customer says they intended to pay by cash but don't have enough cash:
1a.
Customer uses an alternate payment method.
1b. Customer tells Cashier to cancel sale.
Cashier cancels sale on System.
7a. Paying by cash:
1
Cashier enters the cash amount tendered.
2
System presents the balance due, and releases the cash drawer.
3.
Cashier deposits cash tendered and returns balance in cash to Customer.
4.
System records the cash payment.
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.
3.
System receives payment approval and signals approval to Cashier.
3a.
System receives payment denial:
1.
System signals denial to Cashier.
2.
Cashier asks Customer for alternate payment.
4.
System records the credit payment, which includes the payment approval.
5
System presents credit payment signature input mechanism.
6.
Cashier asks Customer for a credit payment signature. Customer enters
signature.
7c.
Paying by check...
7d.
Paying by debit...
7e.
Customer presents coupons:
1
Before handling payment, Cashier records each coupon and System reduces price
as appropriate. System records the used coupons for accounting reasons.
-1a. Coupon entered is not for any purchased item:
1.
System signals error to Cashier.
9a.
There are product rebates:
1.
System presents the rebate forms and rebate receipts for each item with a
rebate.
9b.
Customer requests gift receipt (no prices visible):
1.
Cashier requests gift receipt and System presents it.
Special Requirements:
-Touch screen Ul 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:
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.
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.
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?
Explaining
the Sections
Preface Elements
·
Many
optional preface elements are possible:
o Only place elements at the start which
are important to read before the main success scenario.
o Move extraneous "header"
material to the end of the use case.
Primary Actor: The principal actor that calls upon
system services to fulfill a goal.
Important:
Stakeholders and Interests List
·
This
list suggests and bounds what the system must do.
·
The [system] operates a contract between
stakeholders, with the use cases detailing the behavioral parts of that
contract
·
The use case, as the contract for behavior,
captures all and only the behaviors related to satisfying the
stakeholders' interests
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 beginning a scenario in the use case.
·
A precondition implies a scenario of another
use case that has successfully completed
·
Preconditions communicate noteworthy
assumptions that the use case writer thinks readers should be alerted to.
Success guarantees (or postconditions) state what must be true on successful
completion of the use case—either the main success scenario or some alternate
path. The guarantee should meet the needs of all stakeholders.
Preconditions: Cashier is identified and
authenticated.
Success
Guarantee (Postconditions): Sale is
saved. Tax is correctly calculated.
Accounting
and Inventory are updated. Commissions recorded. Receipt is generated.
Main
Success Scenario and Steps (or Basic Flow)
·
Also called the "happy path"
scenario, or "Basic Flow."
·
Describes the typical success path that
satisfies the interests of the
stakeholders.
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 (e.g., recording or modifying something).
Main Success Scenario:
1. Customer arrives at a POS
checkout with items to purchase.
2. Cashier
starts a new sale.
3. Cashier
enters item identifier.
4. ...
Cashier
repeats steps 3-4 until indicates done.
5.
...
Extensions
(or Alternate Flows)
·
Extensions
indicate all other scenarios or branches, both success and failure.
·
The combination of the happy path and
extension scenarios should satisfy "nearly" all the interests of the
stakeholders. .
·
Extension scenarios are branches from the
main success scenario, and so can be notated with
respect to it.
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:
o the condition
o the handling
·
Write
the condition as something that can be detected by the system or an
actor.
o e.g.:
5a. System
detects failure to communicate with external tax calculation system service:
5a. External
tax calculation system not working:
o
Former style is preferred because this is
something the system can detect; the latter is an inference.
·
Extension handling can be summarized in one
step, or include a sequence,
e.g.,
3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters the item
identifier for removal from the sale.
2. System
displays updated running total.
·
Sometimes an extension point is complex- express the
extension as a separate use case.
e.g.
7b. Paying by credit:
1. Customer enters their
credit account information.
2. System
requests payment validation from external Payment Authorization Service System.
2a. System detects failure to
collaborate with external system:
1. System signals error to
Cashier.
2. Cashier
asks Customer for alternate payment.
3....
·
To describe an extension condition as
possible during any (or most) steps, the labels *a, *b, ..., can be used.
*a. At any time,
System crashes:
In order to
support recovery and correct accounting, ensure all transaction sensitive state
and events can be recovered at any step in the scenario.
1. Cashier restarts the
System, logs in, and requests recovery of prior state.
2. System
reconstructs prior state.
Special
Requirements
·
If
a non-functional requirement, quality attribute, or constraint relates
specifically to a use case, record it with the use case.
e.g. performance, reliability, usability,
and design constraints (often in I/O devices) that have been mandated or considered
likely.
Special Requirements:
o
Touch screen Ul on
a large flat panel monitor. Text must be visible from 1 meter.
o
Credit authorization response within 30 seconds
90% of the time.
o
Language internationalization on the text
displayed.
o
Pluggable business rules to be insertable at steps 2 and 6.
Technology
and Data Variations List
·
Often
technical variations in how something must be done
·
Record
in the use case.
e.g. a technical constraint imposed by a
stakeholder regarding input or output technologies
"The
POS system must support credit account input using a card reader and the
keyboard."
·
This
list is the place to record such variations.
·
Record variations in the data that may be
captured at a particular step.
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.
Goals and Scope of
a Use Case
·
How
should use cases be discovered?
·
At what level and scope should use cases be
expressed?
Use Cases for
Elementary Business Processes
Which of these is a valid use case?
• Negotiate a Supplier
Contract
• Handle Returns
•
Log
In
·
What is a useful level to express use cases
for application requirements analysis?
Guideline: The EBP Use Case
For
requirements analysis for a computer application, focus on use cases at the
level of elementary business processes (EBPs).
·
EBP - term from the business process
engineering field
·
Defined as:
A task performed by one person in one place at one time,
in response to a business event, which adds measurable business value and
leaves the data in a consistent state
e.g., Approve Credit or Price Order [original source
lost].
·
It's not a single small step like
"delete a line item" or "print the document."
·
It is the main success scenario - five or ten
steps.
·
It doesn't take days and multiple sessions,
like "negotiate a supplier contract;" it is a task done during a
single session.
·
It comes to a resolution in which the system
and data are in a stable and consistent state.
Reasonable Violations of the EBP Guideline
·
Useful to create separate "sub" use
cases representing subtasks or steps within a base use case.
·
Do this to find the dominant level of use cases
in requirements analysis for an application
e.g. a subtask
or extension such as "paying by credit" may be repeated in several
base use cases.
·
Separate this into its own
use case (that does not satisfy the EBP guideline) and link it to several base use
cases, to avoid duplication of the text.
Use Cases and Goals
·
Actors
have goals (or needs) and use applications to help satisfy them.
·
An
EBP-level use case is called a user goal-level user case, to emphasize
that it serves to fulfill a goal of a user of the system, or the primary actor.
·
Recommended
procedure:
1.
Find the user goals.
2.
Define a use case for each.
·
Use
case for a user goal should reflect its name
e.g.
Goal: capture or process a sale
Use
case: Process
Sale.
Note that because of this symmetry, the EBP
guideline can be equally applied to decide if a goal or a use case is at a
suitable level.
Example: Applying
the EBP Guideline
·
As
the system analyst responsible for the NextGen system
requirements discovery, you are investigating user goals.
·
The
conversation goes like this: During a requirements workshop:
System
analyst: "What
are some of your goals in the context of using a POS system?"
Cashier: "One, to quickly log in. Also, to capture sales."
System
analyst: "What do
you think is the higher level goal motivating logging in?"
Cashier: "I'm trying to identify myself
to the system, so it can validate that I'm allowed to use the system for sales
capture and other tasks."
System
analyst: "Higher
than that?"
Cashier: "To prevent theft, data
corruption, and display of private company information."
·
Analyst's
strategy - find higher level user goals that still satisfy the EBP guideline
1. "Prevent theft,
..." is higher than a user goal; it may be called an enterprise
goal, and is not an EBP.
2.
"identify
myself and be validated" is closer to the user goal level.
§
But is it at the EBP level?
§
secondary goal in the service of doing
something useful,
3.
"capture a
sale" fits the criteria of being an EBP or user goal.
4.
"cashing
in", in which a cashier inserts their own cash drawer tray into the
terminal, logs in, and tells the system how much cash is in drawer.
5.
Cashing In is an EBP-level (or user goal level)
use case
6.
log in step,
rather than being a EBP-level use case, is a subfunction
goal in support of the goal of cashing in.
Subfunction Goals and Use Cases
o
"identify
myself and be validated" (or "log in") is a goal at a lower
level, called a subfunction goal
o Use cases only occasionally written
for these subfunction goals
o The number and granularity of use
cases influences the time and difficulty to understand, maintain, and manage
the requirements.
o Most common motivation to express a subfunction goal as a use case is when the subfunction is repeated in or is a precondition for
multiple user goal-level use cases.
This in fact
is probably true of "identify myself and be validated," which is a
precondition of most, if not all, other user goal-level use cases.
Consequently,
it may be written as the use case Authenticate User.
Goals
and Use Cases Can Be Composite
o Goals are usually composite
- enterprise level - "be
profitable"
- supporting intermediate goals -
"sales are captured"
- supporting subfunction
goals - "input is valid”
o Use cases can be written at different levels
to satisfy these goals, and can be composed of lower level use cases.
Finding Primary
Actors, Goals, and Use Cases
·
Use
cases are defined to satisfy the user goals of the primary actors.
·
Basic
procedure:
- 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?
- Identify the primary actors—those that have user goals
fulfilled through using services of the system.
- For each, identify their user
goals. Raise
them to the highest user goal level that satisfies the EBP guideline.
- 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: Choosing the System Boundary
- For 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.
Steps 2 and 3: Finding Primary Actors and Goals
Emphasize
brainstorming the primary actors first, as this sets
up the framework for further investigation.
Reminder Questions to Find Actors and Goals
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
- 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?
- Who
evaluates logs?
- Push or
pull update
- Are they
remotely retrieved?
Primary
and Supporting Actors
- Primary
actors
have user goals fulfilled through using services of the system.
- Supporting
actors
provide services to the system
- Focus on
finding the primary actors, not the supporting ones.
The Actor-Goal List
- Record the primary actors and their user goals in an
actor-goal list.
- It should be a section in the Vision artifact
- e.g.:
The Sales Activity System is a remote application that
will frequently request sales data from each POS node in the network.
Step 4: Define Use Cases
- Define one EBP-level use case for each user goal.
- Name the use case similar to the user goal
- e.g.: Goal: process a sale; Use Case: Process Sale.
- Name
use cases starting with a verb.
Need for Communication and Participation
·
The
NextGen POS team is writes use cases in multiple
requirements workshops over a series of short development iterations, incrementally
adding to the set, and refining and adapting based on feedback.
·
Subject
matter experts, cashiers, and programmers actively participate in the writing
process.
·
Written
requirement specifications give the illusion of correctness; they are not.
· Ongoing personal communication is critical
Actors
·
An actor is anything with behavior
·
Primary and supporting actors will
appear in the action steps of the use case text.
·
Actors are not only roles played by people,
but organizations, software, and machines.
·
There are three kinds of external actors:
• Primary actor—has user
goals fulfilled through using services.
• Supporting actor—provides a
service (for example, information)
• Offstage actor—has an interest
in the behavior of the use case, but is not primary or supporting
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.