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 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 2
Software Modelling Case Study
NextGen POS software modeling
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 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 4
Next Gen POS Analysis
Scope of OOA & D and Process Iteration
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 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 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 7
Next Gen POS Case Study: Analysis
OO Analysis with UML
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 8
Analysis (Requirements): Actors, Goals, System Boundaries
Enterprise Selling Things
Checkout Service
Cashier
POS System
Sales Activity System
The University of 9
Go al:Collect taxesonsales
Sales Tax Agency
Customer
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 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
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 Authorization Service
«actor» Tax Calculator
«actor» Accounting System
«actor» HR System
use case
alternate notation for a computer system actor
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
…
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
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 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
The University of 13
endSale total with taxes
makePayment(amount) change due, receipt
NextGen POS Case Study: Design
OO Design with UML
The University of 14
Business Modeling
Sample UP Artifact Relationships Domain Model
1 1..*
Use-Case Model
use case names
Sale
Sales LineItem
…
date
…
quantity
…
Require- ments
Use Case Diagram
Use Case Text
Cashier
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
system events
: System
make NewSale()
parameters and return value details
Vision
Glossary
Operation: enterItem(…)
Post-conditions: -…
system operations
: Cashier
enterItem (id, quantity)
Supplementary Specification
Operation Contracts System Sequence Diagrams
starting events to design for
: Register
Design Model
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
Next Gen POS:
From Analysis to Design
Requirements Analysis (OOA)
Business modelling – domain models Use case diagrams
Use case description
System Sequence Diagrams
Design (OOD)
Sequence diagrams Class diagrams
The University of 15
NextGen POS: Interaction Diagrams
Sequence Diagram
makePayment(cashTendered)
: Register
: Sale
makePayment(cashTendered)
create(cashTendered)
: Payment
direction of message
Communication Diagram
makePayment(cashTendered)
1: makePayment(cashTendered)
1.1: create(cashTendered)
:Register
:Sale
The University of 16
: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 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 18
NextGen POS: Polymorphic Messages
The University of 19
NextGen POS: Polymorphic Messages (Cont.)
The University of 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
…
Register
1 currentSale
Sale
…
The University of 21
makePayment(…) …
makePayment(…) …
NextGen POS: Design Class Diagram
The University of 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 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 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 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 26