Software Design and Construction 1 SOFT2201 / COMP9201
Self Learning Case Study: Next Gen Point-of-Sale (POS) System
School of Computer Science
The University of Sydney
Page 1
Copyright warning
COMMONWEALTH OF AUSTRALIA Copyright Regulations 1969 WARNING
This material has been reproduced and communicated to you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the Act).
The material in this communication may be subject to copyright under the Act. Any further copying or communication of this material by you may be the subject of copyright protection under
the Act.
Do not remove this notice.
The University of Sydney Page 2
Software Modelling Case Study
NextGen POS software modeling
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 3
Next Gen Point-of-Sale (POS) System
• A POS is a computerized application used (in part) to record sales and handle payments
– Hardware: computer, bar code scanner
– Software
– Interfaces to service applications: tax calculator, inventory control
– Must be fault-tolerant (can capture sales and handle cash payments even if remote
services are temporarily unavailable
– Must support multiple client-side terminals and interfaces; web browser terminal, PC with
appropriate GUI, touch screen input, and Wireless PDAs
– Used by small businesses in different scenarios such as initiation of new sales, adding
new line item, etc.
The University of Sydney Page 4
Next Gen POS Analysis
Scope of OOA & D and Process Iteration
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney Page 5
Next Gen POS – Scope (Analysis & Design)
User Interface
minor focus
explore how to connect to other layers
primary focus of case studies
explore how to design objects
secondary focus
application logic layer
other layers or components
Sale
Logging …
Payment
Database Access …
The University of Sydney
Page 6
Iteration and Scope – Design and Construction
Iteration 1
Introduces just those analysis and design skills related to iteration one.
Iteration 2
Additional analysis and design skills introduced.
Iteration 3 Likewise.
The University of Sydney
Page 7
Next Gen POS Case Study: Analysis
OO Analysis with UML
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 8
Analysis (Requirements): Actors, Goals, System Boundaries
Enterprise Selling Things
Checkout Service
Cashier
POS System
Sales Activity System
Go al:Collect taxesonsales
Sales Tax Agency
Customer
The University of Sydney
Page 9
Go al:Buyi tems
Go al:Analyzesales andperformancedata
Go al:Processsales
NextGen POS: Process Sale Use Case Description
Use case UC1: Process Sale Primary Actor: Cashier Stakeholders and Interests:
-Cashier: Wants accurate and fast entry, no payment errors, …
-Salesperson: Wants sales commissions updated.
…
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions):
-Sale is saved. Tax correctly calculated.
…
Main success scenario (or basic flow):
Extensions (or alternative flows): [see next slide] Special requirements: Touch screen UI, … Technology and Data Variations List:
-Identifier entered by bar code scanner,… Open issues: What are the tax law variations? …
The University of Sydney
Main success scenario (or basic flow):
The Customer arrives at a POS checkout with items to purchase.
The cashier records the identifier for each item. If there is more than one of the same item, the Cashier can enter the quantity as well.
The system determines the item price and adds the item information to the running sales transaction. The description and the price of the current
item are presented.
On completion of item entry, the Cashier indicates to the POS system that item entry is complete.
The System calculates and presents the sale total.
The Cashier tells the customer the total.
The Customer gives a cash payment (“cash tendered”) possibly greater
than the sale total.
Extensions (or alternative flows):
If invalid identifier entered. Indicate error.
If customer didn’t have enough cash, cancel sales transaction.
Page 10
Next Gen POS Use Case Diagram
system boundary
Customer
actor Cashier
Manager
«actor» Sales Activity System
System Administrator
NextGen POS
Process Sale
Handle Returns
Cash In
Analyze Activity
Manage Security
Manage Users
communication
UC1: Process Sale
…Main Success Scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.
…
7. Customer pays and System handles
payment
Extensions:
7b. Paying by credit: Include Handle Credit Payment.
7c. Paying by check: Include Handle Check Payment
UC7: Process Rental …
Extensions:
6b. Paying by credit: Handle Credit Payment. …
The University of Sydney
Payment Authorization Service
«actor» Tax Calculator
«actor» Accounting System
«actor» HR System
use case
alternate notation for a computer system actor
…
Page 11
NextGen POS Analysis: Domain Model
A conceptual perspective model Partial domain model drawn with UML class diagram
It shows conceptual classes with key associations
0..1
Contained-in
1 *
1 Houses 1..*
1
1
3 Works-on 111
1..*
Records-sale-of
0..1
Paid-by
11
Is-for
Ledger
Product Catalog
11
1 for
Records- accounts-
Describes *
1
Used-by *
Stocks
1..*
Contains
itemID description price
Sales LineItem
Store
quantity
1
Logs- completed
Captured-on
name address
Item
1..*
1
*
Product Description
Sale
id
Register
dateTime / total
Customer
Cashier
id
CashPayment
amountTendered
The University of Sydney
Page 12
NextGen POS Analysis: System Sequence Diagram (SSD)
: Cashier
Process Sale Scenario
makeNewSale
:System
Simple cash-only Process Sale scenario:
1. Customer arrives at a 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.
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.
…
loop
[ more items ]
enterItem(itemID, quantity) description, total
endSale total with taxes
The University of Sydney
Page 13
makePayment(amount) change due, receipt
NextGen POS Case Study: Design
OO Design with UML
The University of Sydney Page 14
Next Gen POS:
From Analysis to Design
Requirements Analysis (OOA)
Business modelling – domain models Use case diagrams
Use case description
System Sequence Diagrams
Business Modeling
Sample UP Artifact Relationships Domain Model
Sale 1 1..* Sales LineItem
date …
. . .
. . .
quantity
Require- ments
Use Case Diagram
Operation: enterItem(…)
Post-conditions: -…
parameters and return value details
Use-Case Model
Vision
Glossary
Supplementary Specification
Cashier
Process use Sale case
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Use Case Text
system events
: System
make NewSale()
enterItem (id, quantity)
names
: Cashier
system operations
Operation Contracts
System Sequence Diagrams
starting events to design for
Design (OOD)
Sequence diagrams Class diagrams
The University of Sydney
: Register
Design Model
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
Page 15
NextGen POS: Interaction Diagrams
: Register
: Sale
Sequence Diagram
makePayment(cashTendered)
makePayment(cashTendered)
Communication Diagram
makePayment(cashTendered)
1: makePayment(cashTendered)
1.1: create(cashTendered)
direction of message
create(cashTendered)
: Payment
The University of Sydney
Page 16
:Register
:Sale
:Payment
NextGen POS: Sequence Diagrams
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered)
: Payment
1. The message makePayment is sent to an instance of a Register. The sender is not identified
2. The Register instance sends the makePayment message to a Sale instance.
3. The Sale instance creates an instance of a Payment.
The University of Sydney
How the skeleton of the Sale class should look like?
Page 17
NextGen POS: Sequence Diagram (Iteration)
: Sale
t = getTotal
lineItems[i] : SalesLineItem
loop
st = getSubtotal
The University of Sydney Page 18
NextGen POS: Polymorphic Messages
The University of Sydney Page 19
NextGen POS: Polymorphic Messages (Cont.)
The University of Sydney Page 20
NextGen POS: Interaction and Class Diagrams
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
messages in interaction diagrams indicate operations in the class diagrams
classes identified in the interaction diagrams are declared in the class diagrams
The University of Sydney
Page 21
…
Register
1 currentSale
Sale
…
makePayment(…) …
makePayment(…) …
NextGen POS: Design Class Diagram
The University of Sydney Page 22
NextGen POS: Collection of Attributes
Sale
time: DateTime
lineItems : SalesLineItem [1..*]
or
lineItems : SalesLineItem [1..*] {ordered}
…
SalesLineItem
…
…
Two ways to show a collection attribute
Sale
1..*
lineItems {ordered, List}
time: DateTime
…
SalesLineItem
…
…
The University of Sydney
Page 23
notice that an association end can optionally also have a property string such as {ordered, List}
NextGen POS: Methods
Register
…
endSale()
enterItem(id, qty) makeNewSale() makePayment(cashTendered)
«method»
// pseudo-code or a specific language is OK public void enterItem( id, qty )
{
ProductDescription desc = catalog.getProductDescription(id);
sale.makeLineItem(desc, qty); }
The University of Sydney Page 24
NextGen POS: Dependency
the Sale has parameter visibility to a ProductDescription, and thus some kind of dependency
ProductDescription
…
…
Sale
…
updatePriceFor( ProductDescription ) …
SalesLineItem
…
…
1..* lineItems
The University of Sydney
Page 25
Next Gen POS: Composite Aggregation
SalesLineItem instance can only be part of one composite (Sale) at a time.
The composite has sole responsibility for management of its parts, especially creation and deletion
Composition (or Composite Aggregation is a strong kind of whole-part aggregation.
Use composition over aggregation as the latter was deemed by UML creators as “Placebo”
The University of Sydney
Page 26