Documente Academic
Documente Profesional
Documente Cultură
Process Sale alternate
notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier
«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System
Manage Security
System Manage Users
Administrator use case
. . .
Domain Model
• Domain Model
– Most important classic model in OO Analysis
(Business Object Model)
– Illustrates meaningful concepts in the problem domain
– Representation of real-world things (Concepts), not
software components
– It is a set of static structure diagrams, containing all
the important players (No operations are defined)
– It may show:
• Concepts
• Associations
• Attributes
Domain Model
• A Domain Model is
Item a description of
things in the real
world
*
Stocked-in • A Domain Model is
not a description of
1 the software design
Store
Address • A concept is an
Name idea, thing, or
object.
Domain Model
• Visualization of things in the Domain
– Visual dictionary
– A picture of Business Objects, not of software objects
– Does not contain responsibilities or methods
– Is not a data model
– Why Domain Model
UI Domain
:ClassBInstance
• Collaboration
diagrams
• illustrate object
interactions in a
graph or network
format
Sequence Diagrams
• Lifeline boxes and
vertical lifelines
:Register :Sale • Activation bar for
focus of control
• Messages – time
NewSale()
makeSale() organized
• Reply messages
total()
• Self messages
• Create & destroy
createPayment()
:Payment
clear
destroy()
X
Loops
• loop – with condition
• opt – optional on
:A :B condition
• alt – alternate on
makeNewSale()
condition
loop enterItem() • par – parallel
[more] descTotal() • region – critical with
only one thread
alt
[x<10]
calculateA()
[else] calculateB()
Class Diagrams
• Created in design, it is a diagram showing classes, their
innards, and the associations between them
• It is a final version of a conceptual diagram; A class
diagram differs from a Domain Model by showing
software entities rather than realworld concepts
(Class diagrams in Design are referred to as DCD or
Design Class Diagrams)
• Once the interaction diagrams have been completed it is
possible to identify the specification for the software
classes and interfaces
Design Model Classes
• Innards of a Class
– Class Name
– Attributes Sale
– Methods
date : Date
• The attribute must contain its class isComplete : Boolean
or data type time
Payment
amount : Currency
Inheritance
• Inheritance Payment
allows reuse
amount : Currency
CreditPayment CashPayment
creditCardNumber : int
amountTendered :
expirationDate : Date
Currency
Associations
• There can be many kind of associations
• They all link two classes
• Role names are assigned
• Their purpose is to indicate visibility
Register Sale
Date
isComplete:Boolean
1 Captures 1
time
addLineItem(…)
…… makeLineItem(..)
Influence of Interaction Diagrams
on Class Diagrams
:Register :Sale
makeSale()
currentSale 1
makePayment(…)
…… makePayment(..)
Finding Associations –Common
Associations List
Category Examples
A is a physical/logical part of B SalesLineItem - Sale
A is physically contained in/on B POS - Store
A is logically contained in B ItemDescription - catalog
A is a description of B ItemDescription - Item
A is a line item of a transaction
or report B SalesLineItem - Sale
A is known/logged/recorded/
captured in B Sale - POS
A is a member of B Cashier - Store
... * High-priority associations
Multiplicity
• Multiplicity defines
POS Stocks Sale how many instances of
1 * a type A can be
associated with one
T instance of a type B, at
* a particular moment in
time
T T
5 • For example, a single
1..*
instance of a Store can
T T be associated with
1..40 3,5,8 “many” (zero or more)
Item instances
Naming Associations
• Name an association based
on a TypeName-VerbPhrase-
Store
TypeName format
• Association names should
1
start with a capital letter
Contains
• A verb phrase should be
1..* constructed with hyphens
• The default direction to read
POS
an association name is left to
1 right, or top to bottom.
Captures
1..*
Paid-by
Sale CreditCard
1 1
Multiple Associations Between Two
Types
• It is not uncommon to have multiple associations
between two types
Flies-to 0..1
*
Flight Air[port
Flies-from
* 1
Attributes
• An attribute is a logical data value of an object
• Include the following attributes: those for which the
requirements suggest or imply a need to remember
information.
• For example, a Sales receipt normally includes a date
and time
• The Sale concept would need a date and time attribute
Sale
date
time
Valid Attribute Types
• Keep attributes simple
• The type of an attribute should not normally be a complex
domain concept, such as Sale or Airport
• Attributes in a Domain Model should preferably be:
o Pure data values: Boolean, Date, Number, String, …
o Simple attributes: color, phone number, zip code,
universal product code (UPC), ...
Invalid – not
simple attribute
NextGen POS Domain Model
Recordssaleof
Product
Ledger Product Description
Catalog Contains
1 itemID
1..*
description
1 1
1 price
0..1 Records
Usedby Describes
accounts
Sales for * *
LineItem Store
Item
Stocks
quantity 1 name
address
1
* 1..*
1..*
1
Containedin Logs Houses
1 completed 1..*
Sale * Register
dateTime Capturedon id
0..1 1
/ total
1
1 1
Isfor Workson
Paidby
1 1 1
amountTendered id
System Behavior and
System Sequence Diagrams (SSDs)
• A sequence diagram is a picture that shows, for a
particular scenario of a use case, the events that
external actors generate, their order, and possible
inter-system events
the name could be "NextGenPOS" but "System" keeps it
simple
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
external actor to Process Sale Scenario
system
: Cashier :System
makeNewSale
endSale a message with
parameters
return value(s)
associated with the it is an abstraction
previous message total with taxes
representing the
system event of
an abstraction that entering the
ignores presentation makePayment(amount)
payment data by
and medium some mechanism
the return line is change due, receipt
optional if nothing is
returned
Use Case Diagram
system boundary NextGen POS communication
Process Sale alternate
notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier
«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System
Manage Security
System Manage Users
Administrator use case
. . .
SSDs derived from use cases
Process Sale Scenario
: Cashier :System
makeNewSale
Simple cashonly Process Sale scenario:
loop [ more items ]
1. Customer arrives at a POS checkout enterItem(itemID, quantity)
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier. description, total
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 34 until indicates
done. endSale
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and total with taxes
asks for payment.
7. Customer pays and System handles
payment. makePayment(amount)
...
change due, receipt
Naming System Events and
Operations
• The set of all required system operations is
determined by identifying the system events
– makeNewSale()
– addLineItem(itemID, quantity)
– endSale()
– makePayment(amount)
Choosing events and names
:System
: Cashier
better name
enterItem(itemID, quantity)
scan(itemID, quantity)
worse name