Upload
violet-stewart
View
256
Download
3
Tags:
Embed Size (px)
Citation preview
OO Methodology
Inception Phase
2
Table of Contents
• Case Study: NextGen POS System
• Introduction to Inception Phase
• Understanding Requirements
• Use-Case Model
• Identifying Other Requirements
3
Case Study : NextGen POS System
• NextGen POS(Point-Of-Sale) system – is a computerized application used to record sales and handle
payments– typically used in a retail store– includes hardware components such as computers, barcode
scanners; and software to run the system– Interfaces to various service applications, such as a third-
party tax calculator and inventory control– must be relatively fault-tolerant
• Architectural Layers
Interface
Application login anddomain objectlayer
Technicalservices layer
Sale Payment
PersistenceFacade
Log
4
Introduction to Inception
• Intent of inception– to establish some initial common vision for the objectives of
the project
– to determine if it is feasible
– to decide if it is worth some serious investigation elaboration
• Duration – one or a few weeks
– If it has been decided beforehand that the project will definitely be done, and it is clearly feasible, it is especially brief and quickly moves to elaboration phase
• Artifacts– Vision and Business Case
– Use-Case Model
– Supplementary Specifications
– Glossary
– Risk List and Risk Management Plan
– Prototypes and Proof-of-concepts
– Iteration Plan
– Phase Plan & Software Development Plan
– Development Case
5
Understanding Requirements
• Requirements are capabilities and conditions to which the system must conform
• Requirement management– a systematic approach to finding, documenting, organizing,
and tracking the changing requirements of a system
• Types of Requirements (FURPS+)– Functional – features, capabilities
– Usability – human factors, help, documentation
– Reliability – frequency of failure, recoverability, predictability
– Performance – response time, throughput, accuracy, resource usage
– Supportability – adaptability, maintainability, internationalization, configurability
– Implementation – resource limitations, languages and tools ...
– Interface – constraints imposed by interfacing with external systems
– Operations – system management in its operational setting
– Packaging
– Legal – licensing and so forth
6
Use-Case Modeling
• Use case modeling is a modeling technique used to describe what a system should do
• Purposes of use case model – to decide and describe the functional requirements of the
system (agreement between the customer and software developer)
– to give a clear and consistent description of what the system should do, so that the model is used as basis for further development phases
– to provide a basis for performing system tests
– to provide the ability to trace functional requirement into actual classes (ease in maintenance)
• Use-case model is described in use-case diagram
• Components in use-case diagram– Actors
– Use cases
– System
7
Use-Case Modeling
• Actors– any entities that reside outside the system interfacing with the
system, such as people, software system, hardware, data stores, or network etc.
– actor is a type, not an instance
– each actor defines a particular role
• A use case is a complete functionality as perceived by an actor
– a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal (need)
– 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
– a use case is always initiated by an actor
– a use case is complete
– a use case describes one aspect of usage of the system
– use cases don not presume any specific design or implementation
– use cases are written in text documents, not diagrams and use-case modeling is an act of writing text, not drawing
8
Use-Case Model
• Use-Case Diagram
Place Order
Customer
Order Processing
9
Writing a Use Case
• Use Case Types – Black-box use cases : they do not describes the internal
workings of the system, its components, or design
– example:
“The system records the sale” (O)
“The system writes the sale to a database” or “The system generates a SQL statement for the sale...” (X)
• Use Case Formats– brief : terse one paragraph summary(main success scenario)
– casual: informal multiple paragraphs that cover verious scenarios
– fully-dressed: all steps and variations are written in detail
• Example of the casual format
Use Case: 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...
Alternative Scenarios:
If the credit authorization is reject, inform the customer and ask for an alternate payment method
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 tax calculator system ....
10
Fully-Dressed Format
Primary Actor:
...
Stakeholders and Interests:
...
Preconditions
...
Postcondtions:
...
Main Success Scenario:
...
Extensions(Alternative Flows):
...
Special Requirements:
...
Technology and Data variations List:
...
Frequency of Occurrence:
...
Open Issues:
...
11
Fully-Dressed Format
• Stakeholders and Interests– The system operates a contract between stakeholders... The
use cases captures all and only the behaviors related to satisfying the stakeholders interests
• Preconditions and Postconditions– preconditions state what must always be true before
beginning a scenario in the use case
– postconditions state what must be true on successful completion of the use case
• Main Success Scenario (Basic Flows)– typical success path that satisfies the interests of the
stakeholders
– not include any conditions or branching
– The steps have one of three kinds:1. an interaction between actors
2. a validation (usually by the system)
3. a state change by the system
12
Fully-Dressed Format
• Extensions (or Alternative Flows)– Extension scenarios are all other scenario or branches from
the main success scenario
– An extension has two parts: the condition and the handling3a. Invalid identifier (condition)
1. System signals error and rejects entry (handling)
– A condition is something that can be detected by the system or arises by an actor
– At the end of extension handling, by default the scenario merges back with the main scenario
– If a particular extension point is quite complex, as in the “paying by credit” extension, the extension can be expressed as a separate use case ( <<extends>> relationship )
• Special Requirements– If a non-functional requirement relates specifically to a use
case, record it with the use case
– These include qualities such as performance, reliability, and usability, and design constraints
– These requirements can be captured in the Supplementary Specification
• Technology and Data Variations List– Technical constraints imposed by a stakeholder (e.g. I/O
tech)
– Early design decision (obvious or unavoidable)
– Variations in data schemes
13
Fully-Dressed Example: 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 for 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 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
Postcondtions: Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated
14
Fully-Dressed Example: Process Sale
Main Success Scenario:
1. Customer arrives at POS checkout with goods and/or services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. System records sale line item and presents item description, prices, and running total.
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 and Inventory system
9. System presents receipt
10. Customer leaves with receipt and goods
15
Fully-Dressed Example: Process Sale
Extensions(Alternative Flows):
3a. Invalid identifier:
1. System signals error and rejects entry
3b. Cashier can enter item category and the quantity
3-6a. Customer asks Cashier to remove an item from the purchase
3-6b. Customer asks Cashier to cancel sale
5a. System detects failure to communicate with external tax calculation system service:
1. System restarts the service on the POS node and continues
1a. 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
....
16
Fully-Dressed Example: Process Sale
Special Requirements:
– Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
– Credit authorization response with 30 seconds 90% of the time
– Somehow, we want robust recovery when access to remote services such as the inventory system is failing
– Language internationalization on the text displayed
Technology and Data variations List:
3a. Item identifier entered by bar code 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 tow 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 differnent businesses?
17
Finding Actors and Use Cases
• Basic Procedure1. Choose the system boundary
2. Identify the primary actors
3. Identify their user goals (EBP guideline)
4. Define use cases that satisfy user goals (one-to-one mapping)
• Identifying actors– Who uses the system?
– Who installs the system?
– Who starts up and shuts down the system?
– Who maintains the system?
– What other systems use this system?
– Who gets information from this system?
– Who provides information to the system?
– Does anything happen automatically at a preset time?
18
Identifying Actors and Use cases
• Identify actors goals and use cases– Find the user goals
– Define a use case for each
• EBP Use Case Guideline– Focus on use cases at the level of elementary business
processes(EBP)
• Elementary Business Processes– 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. Place Order
– Which of these is a valid use case?• Negotiate a Supplier Contract
• Handle Returns
• Log In
• Common use case mistake is defining many uses cases at too low a level, that is, subfunction, or subtask within an EBP. e.g. Log In, Paying by Credit
– What do you do? or
– What are your goals?
19
Identifying Actors and Use cases
• Actor-Goal List
• Define one EBP-level use case for each user goal– exception : GRUD goals ( e.g. Manage<X> )
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
...
Manager start up
shut down
...
Sales
Activity
System
analyze sales
... ... ... ...
20
Use-Case Model
• Use-Case Diagram
NextGen
Manage Users
. . .
Cashier
SystemAdministrator
actor
use case
communicationsystem boundary
Handle ReturnsPayment
AuthorizationService
«actor»Tax Calculator
«actor»Accounting
System
alternatenotation fora computersystem actor
Process Rental
«actor»HR System
Cash In
Process Sale
«actor»Sales Activity
System
Manage Security
Analyze Activity
21
Use Case vs Feature List
• Feature List (low-level detailed)– what system shall do
– long lists do not relate the requirements in a cohesive context
• But, sometimes use cases do not really fit– e.g. application servers, middleware, or back-end systems
• High-level system feature lists are acceptable– to summarize system functionality with a terse, high-level
feature list (system feature in UP Vision Document)• sale capture
• payment authorization(credit, debit, check)
• automatic offline sales processing when external components fail
• real-time transactions, based on industry standards with third-party systems including inventory, accounting, tax calculators, and payment authorization services
• ....
22
Use Cases within the UP
• Use case driven development– requirement are primarily recorded in use cases
– use cases are an important part of iterative planning
– use case realizations drive the design
– use case often influence the organization of user manuals
– use cases drive test models
– etc.
• Use Cases and Iteration Plans– Table 6.1
– In Inception Phase, most use cases identified by name, and only 10% to 20% written in detail
e.g. Process Sale
Handle Returns
– Most use cases(about 80-90%) completed in detail in Elaboration Phase
23
Identifying Other Requirements
• Supplementary Specification captures other requirements, information and constraints not easily captured in the use cases
– FURPS+ requirements
– reports
– hardware and software constraints
– development constraints
– other design and implementation constraints
– internationalization concerns
– documentation
– licensing and other legal concerns
– packaging
– standards
– physical environment
– operational concerns
– domain or business rules
– information in domains of interest