CS616 – Software Engineering II

Lecture 3

 

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

What Is Analysis and 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

 

Partial domain model of the dice game

 

 

Define Interaction Diagrams

 

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:

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:

 

·       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:

 

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

 

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

 

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:

  1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization?
  2. Identify the primary actors—those that have user goals fulfilled through using services of the system.
  3. For each, identify their user goals. Raise them to the highest user goal level that satisfies the EBP guideline.
  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: Choosing the System Boundary

 

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:

 

Primary and Supporting Actors

 

The Actor-Goal List

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

 

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.