CS计算机代考程序代写 ER finance Our lecture starts at 9:05am

Our lecture starts at 9:05am
Participate the online lecture using nonverbal icons

SWEN30006
Software Design and Modelling
Domain Models &
System Sequence Diagrams
Textbook: Larman Chapter 1, 9 & 10
“It’s all well in practice, but it will never work in theory.” ― anonymous management maxim
2

Learning Objectives
On completion of this topic, you should be able to:
• •
•
State the purpose of OO Analysis.
Be familiar with static and dynamic OO models
Domain Class Diagrams
– Identify conceptual classes
– Create an initial domain model
– Model appropriate attributes and associations
System Sequence Diagrams (SSD)
– Identify system events
– Create SSDs for use case scenarios
•
3

Week 1 Revisited: Use Cases
• Use Cases are text stories that describe how an actor use a system to meet goals
– A tool to discover and record requirements
• Use case diagrams provides a context of a system and its environment
– A tool to capture the names of use cases, actors, and their relationships
Business Modeling
1 1..*
Use-Case Model
use case names
Sample UP Artifact Relationships Domain Model
Sale
Sales LineItem
…
date
…
quantity
…
objects, attributes, ass oc iat io ns
scope, goals, actors, features
Visi on
Glossary
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Ca shi er
Require- ments
terms, attributes, validation
Use Case Diagram
Use Case Text
Week 1
system events
make NewSale()
enterItem (id, quantity)
Operation: enterItem( )
Post-conditions: -…
system operations
: Cashier
Supplementary Specification
non-functional reqs, quality attributes
: System
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
: Register
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
5

Week 2: Object-Oriented Analysis
Week 2
• Week 2 focuses on object-oriented analysis based on use case text
• Analysis is investigation of the problem & requirements
• Object-oriented analysis is a process of creating a
description of the domain from the perspective of
object.
– Analyze use cases and identify objects – or concepts – in the problem domain
– The concepts and behaviours are captured in the form of Domain Models and Sequence Diagrams
Business Modeling
1 1..*
Use-Case Model
use case names
Sample UP Artifact Relationships Domain Model
Sale
Sales LineItem
…
date
…
quantity
…
objects, attributes, ass oc iat io ns
scope, goals, actors, features
Vision
Glossary
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Ca shi er
Require- ments
terms, attributes, validation
Use Case Diagram
Use Case Text
Week 2
system events
make NewSale()
enterItem (id, quantity)
Operation: enterItem( )
Post-conditions: -…
system operations
: Cashier
Supplementary Specification
non-functional reqs, quality attributes
: System
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
: Register
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
6

OO Analysis, Design, and Development
Problem domain
• Concepts
• Relationships
Use Cases
OO Domain Models
• Static: Domain Class Diagram
• Dynamic: System Sequence Diagram
Conceptual Classes
OO Design Models
• Static
• Dynamic
Software Classes
OO Programming
Classes in Programming
Text stories
7

Sample UP Artifact Relationships Domain Model
Business Modeling
1 1..*
Use-Case Model
use case names
Sale
Sales LineItem
…
date
…
quantity
…
objects, attributes, ass oc iat io ns
scope, goals, actors, features
Visi on
Glossary
Domain Models
Require- ments
terms, attributes, validation
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Ca shi er
Use Case Diagram
Use Case Text
: System
Operation: enterItem( )
Post-conditions: -…
: Cashier
system events
make NewSale()
enterItem (id, quantity)
Supplementary Specification
non-functional reqs, quality attributes
system operations
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
Textbook: Larman Chapter 9
enterItem (itemID, quantity)
: Register
: ProductCatalog
: Sale
Design
9

Domain Models
• OO Analysis includes an identification of the concepts, attributes, and associations that are considered noteworthy in the problem domain – These can be expressed by a domain model
• Definition: A domain model is a representation of real-situation conceptual classes
– Not a software object
– Shows the noteworthy domain concepts or object
– One of OO artifacts
• The UP domain model = UP Business Object Model
– Focus on explaining things and products important to a business domain
• Visual representation: UML class diagram is used to illustrate a domain model
– A domain class diagram provides a conceptual perspective to show conceptual classes, their
attributes and associations with other classes
– No operations (method signatures) are defined in the class diagram
10

Domain Models in UP
Noteworthy attributes Business 1
Noteworthy associations Domain Model
Sale
1..*
Sales LineItem
…
Modeling
Conceptual classes
based on use cases text
conceptual classes – terms, concepts attributes, associations
the domain objects, attributes, and associations that undergo state changes
elaboration of some terms in the domain model
date
…
quantity
…
Require- ments
Operation Contracts
Glossary
Process Sale
1. Customer arrives … 2. …
3. Cashier enters item identifier.
4….
Use Case Text
Use-Case Model
Operation: enterItem( )
Post-conditions: -…
Cashier: Item ID: …
11
conceptual classes in the domain inspire the names of some software classes in the design
Design Model

A Conceptual Class: Definition
• (Informal) Definition: A conceptual class is an idea, thing, or object
– It can be more than a data model. It can have a purely behavioural role in the domain instead of an information role
• (More formal) Definition: A conceptual class may be considered in terms of its symbol, intension, and extension
– Symbol: Words or images representing a conceptual class.
– Intension: The definition of a conceptual class.
– Extension: The set of examples to which the conceptual class applies.
sale-1 sale-3
sale-2
Sale
concept’s symbol
date time
“A sale represents the event of a purchase transaction. It has a date and time.”
concept’s intension
concept’s extension
sale-4
12

A Conceptual Class: How to identify it?
Three strategies to find a conceptual class from use cases
Conceptual Class Category Examples
Business transactions Sale, Payment Guideline: Critical (involve money) Reservation
Physical objects Item, Register Board, Piece, Die
Guideline: esp. for device- Aeroplane controllers or simulations
Containers of things (physical or Store, Bin information) Board
Aeroplane
Where are transactions recorded? Register, Ledger
Guideline: important FlightManifest, MaintenanceLog
1.
2.
3.
Identify based on the existing models for common domain problems, e.g., inventory, finance, etc.
– Books: Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay
Use a category list
– See the conceptual class category list in
Table 9.1 in the textbook (Larman Chapter 9) Identify noun phrases
– Care must be applied as words in natural languages are ambiguous
– Do not use as a mechanical noun-to-class mapping
13

Example: POS
Identify conceptual classes based on a category list
• Role of people or organization: – Customer, Cashier
• Product or services:
– Goods and/or services (rename to item)
• Business transaction: – Sale
• Transaction line items:
– Sale line item
• Description of things: – Item description
• Where is the transaction recorded? – A POS checkout (Register)
Main Success Scenario (or Basic Flow):
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. Price calculated from a set of price rules.
14

Example: Conceptual classes
• The library has users who can borrow items.
• The library holds both books and videos: all items have a title and year of production (and a due date if they have been borrowed), while only books have authors and only videos have a duration
• There are different kinds of users: students, staff, and guests. The only difference between these user types is that they have a different borrowing limit (max number of items they can borrow) which is based on their user type.
• The library keeps track not only of which items are out on loan now, but the complete history of which users borrowed which items for which periods.
17

Associations between Conceptual Classes
• Definition: An association is a relationship between classes that indicate some meaningful and interesting connection
• The following associations should be included:
– Significant in the domain
– Knowledge of the relationship needs to be preserved
– Derived from the Common Associations List (Table 9.2)
-“reading direction arrow”
-it has no meaning except to indicate direction of
reading the association label -often excluded
Register
1
Records-current  Sale 0..1
multiplicity
association name
*See Worshop 2 supplementary materials
18

POS: Partial Domain Model
Contained-in
1 Houses
0..1
0..1
1
Records-sale-of
* 1..*
1
1..*
1 111
Paid-by 1 1 Is-for
 Works-on
Ledger
Product Catalog
Contains
Product Description
1
Used-by *
Stocks
1..*
11
1 for
Records- accounts-
Describes *
Sales LineItem
Store
Item
1
Logs- completed
Captured-on
1..*
1
*
Sale
Register
Customer
Cashier
CashPayment
19

Attributes of Conceptual Classes
• Definition: An attribute is a logical data value of an object.
• Attributes should be included into conceptual classes when the requirements (e.g., use cases) suggest or imply a need to remember information
Main Success Scenario (or Basic Flow):
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. Price calculated from a set of price rules.
attributes
Sale
Date
Time
/ total : Money
derived attribute
20

POS: Attributes in Model
Contained-in
1 Houses
0..1
* 1..*
 Works-on 111
0..1
1
1
Records-sale-of
1
1..*
Paid-by
11
Is-for
Ledger
Product Catalog
1
Used-by *
Stocks
1..*
Contains
Product Description
itemID description price
11
1 for
Records- accounts-
Describes *
Sales LineItem
Store
Item
quantity
name address
1
Logs- completed
Captured-on
1..*
1
*
Sale
id
Register
dateTime / total
Customer
Cashier
id
CashPayment
amountTendered
21

Domain Model: A Visual Dictionary
• The domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain
Sales LineItem
Item
quantity
0..1 1..*
1
1
Stocked-in
Sale
Captured-on 
Store
date time
address name
Register
concept or domain object
Records-sale-of
association
Contained-in
1
Paid-by 1
* 1
1 Houses
1..*
attributes
0..1
1
A partial domain model for POS
A partial domain model for Monopoly
Payment
amount
22

Business Modeling
1 1..*
Use-Case Model
use case names
Sample UP Artifact Relationships Domain Model
Sale
Sales LineItem
…
date
…
quantity
…
objects, attributes, ass oc iat io ns
scope, goals, actors, features
Visi on
Glossary
System Sequence Diagrams
Textbook: Larman Chapter 10
Require- ments
terms, attributes, validation
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Ca shi er
Use Case Diagram
Use Case Text
Operation: enterItem( )
Post-conditions: -…
: Cashier
system events
make NewSale()
enterItem (id, quantity)
Supplementary Specification
non-functional reqs, quality attributes
: System
system operations
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
: Register
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
24

Business Modeling
Sale 1 date
Domain Model
1..* Sales LineItem
System Sequence Diagrams (SSDs)
quantity
. . .
• Definition: A visualisation of the system events that external actors generate, the order of the events, and possible inter-system events
– One SSD is for one particular scenario of a use case
– Helps to identify the external input events to the system (the system events)
– Treats system as a ‘black box’ to describe what the system does without explaining how it does it.
Use-Case Model
Require- ments
Use Case Diagram
p retu
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
Operation: enterItem(…)
Post-conditions: -…
: Cashier
system operations
Operation Contracts
System Sequence Diagrams
25
starting events to design for

SSD: Process Sale scenario of POS use cases
A UML loop interaction frame with a boolean guard
External actor to system
Process Sale Scenario
makeNewSale
System as a black box
An event: A message with parameters
A response (optional): Return value(s) associated with the previous message
:System
: Cashier
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
makePayment(amount) change due, receipt
26

SSD: Process Sale scenario of POS use cases
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.
…
#3-4
: Cashier
#2
Process Sale Scenario
makeNewSale
loop
[ more items ]
enterItem(itemID, quantity) description, total
endSale total with taxes
makePayment(amount) change due, receipt
#4
#5 #6-7
#6-7
27
:System

SSDs: Dynamic Context
• SSD captures dynamic context for system
For a use case context diagram, limit the use cases to user-goal level use cases.
Show computer system actors with an alternate notation to human actors.
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.
: Cashier
Process Sale Scenario
makeNewSale
4. System records sale line item and
presents item description, price, and
«actor»
Payment
:System
loop [ more items ]
enterItem(itemID, quantity) description, total
running total.
Cashier repeats steps 3-4 until indicates
Authorization Service
Cashier
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.
…
endSale total with taxes
makePayment(amount) change due, receipt
SSD for POS Process Sale Scenario
28
NextGen
Process Sale
…
primary actors on supporting actors
Use Case Diagram: POS
the left on the right

SSDs: Dynamic Context
• SSD captures dynamic context for system
Use Case Diagram: Monopoly
SSD for a Play Monopoly Game Scenario
29

Exercise: SSD for Myki Quick Top-up Machine
Quick top-up scenario
1. A traveler taps a Myki card on the reader on the green panel. The machine display the balance of the card.
2. The traveler select the amount of top up from the displayed menu.
3. Then, the traveler taps a credit card to pay.
4. A traveler then taps the Myki card again to load the top up amount into the card. Finally, the machine displays the current balance of the card.
https://www.ptv.vic.gov.au/tickets/myki/travel-with-myki/myki- equipment/top-up-faster-with-a-quick-top-up-machine/
31
Myki: A smart card ticketing system

•
SSD: Inter-system events
SSDs can also illustrate interactions between systems, e.g., POS <--> External credit payment authorizer
Process Sale
Pay by Credit Scenario
For a use case context diagram, limit the use cases to user-goal level use cases.
Show computer system actors with an alternate notation to human actors.
: Cashier
:NextGenPOS System
«actor» :TaxCalculator
«actor» :CreditAuthorization Service
«actor» :Accounts
makeNewSale
«actor» Payment Authorization Service
Cashier
enterItem(itemID, quantity)
description, total
endSale
total with taxes
makeCreditPayment (credNum, expiryDate)
taxLineItems = getTaxes( sale )
reply = requestApproval(request) postReceivable( receivable )
postSale( sale )
41
NextGen
Process Sale
…
primary actors on supporting actors the left on the right

SSDs & Domain Models
• SSDs indicate events which design needs to handle and include associated information with reference to domain model
: Cashier
Process Sale Scenario
makeNewSale
Ledger
Records-sale-of
:System
Product Catalog
Contains
Product Description
itemID description price
1
Used-by *
Stocks
1..*
0..1
Contained-in
11
1 for
Records- accounts-
Describes *
loop [ more items ]
enterItem(itemID, quantity) description, total
Sales LineItem
* 1..*
 Works-on 111
endSale total with taxes
1..*
1
*
Store
quantity
name address
1 Houses
1
1..*
Item
1
Logs- completed
Captured-on
Sale
0..1
1
1
Register
dateTime / total
id
makePayment(amount) change due, receipt
Paid-by
11
Is-for
CashPayment
amountTendered
Customer
Cashier
id
42
ess Sale scenario:
a POS checkout ices to purchase.
sale. identifier.
line item and on, price, and
3-4 until indicates al with taxes
er the total, and System handles
v w
e
m

Summary & Remarks
• Object-oriented analysis concerns on how to describe the problem domain from the perspective of object
• Domain models capture the concepts, attributes, and associations in the domain
– Provide static context of system: A visual dictionary of noteworthy abstractions, domain vocabulary,
and information content of the domain
• System Sequence Diagrams capture the sequence of system events of one scenario in use cases
– Provide dynamic context of system: How actors interact with system (as a black box) and how the system respond
• Domain models & SSDs should be expressed at the abstract level of intention
– Provide essential abstractions in information required to understand the domain in the context of the
current requirements
– Aid people in understanding the domain
43

Lecture Identification
Lecturer: Philip Dart
Semester 1, 2021
© University of Melbourne 2021
These slides include materials from:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, by Craig Larman, Pearson Education Inc., 2005.

Related Posts