Software Design and Modelling
Domain Models &
System Sequence Diagrams
Textbook: 1, 9 & 10
Copyright By PowCoder代写 加微信 powcoder
“It’s all well in practice, but it will never work in theory.” ― anonymous management maxim
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
Week 1 Revisited: Use Cases
Sample UP Artifact Relationships Domain Model
• 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
Use-Case Model
use case names
: Register (itemID, quantity)
Sales LineItem
objects, attributes, associations
scope, goals, actors, features
terms, attributes, validation
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
Require- ments
Use Case Diagram
Use Case Text
Operation: enterItem(…)
Post-conditions: -…
system operations
enterItem (id, quantity)
system events
make NewSale()
Supplementary Specification
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
non-functional reqs, quality attributes
: ProductCatalog
Week 2: Object-Oriented Analysis
Sample UP Artifact Relationships Domain Model
• 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
– Analyse 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
Use-Case Model
use case names
Sales LineItem
objects, attributes, associations
scope, goals, actors, features
terms, attributes, validation
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
Require- ments
Use Case Diagram
Use Case Text
system events
enterItem (id, quantity)
Operation: enterItem(…)
Post-conditions: -…
make NewSale()
Supplementary Specification
system operations
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
non-functional reqs, quality attributes
: Register (itemID, quantity)
: ProductCatalog
OO Analysis, Design, and Development
Problem domain
• Concepts
• Relationships
OO Domain Models
• Static: Domain Class Diagram
• Dynamic: System Sequence Diagram
Conceptual Classes
OO Design Models
Software Classes
OO Programming
Classes in Programming
Text stories
Business Modeling
Use-Case Model
use case names
Sample UP Artifact Relationships Domain Model
Sales LineItem
objects, attributes, associations
scope, goals, actors, features
terms, attributes, validation
Domain Models
Require- ments
Use Case Diagram
Use Case Text
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
system events
Operation: enterItem(…)
Post-conditions: -…
make NewSale()
Supplementary Specification
system operations
enterItem (id, quantity)
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
non-functional reqs, quality attributes
Textbook: 9
: Register (itemID, quantity)
: ProductCatalog
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
Domain Models in UP
Noteworthy attributes Business 1
Noteworthy associations Domain Model
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
Require- ments
Operation Contracts
Process Sale
1. Customer arrives … 2. …
3. Cashier enters item identifier.
Use Case Text
Use-Case Model
Sales LineItem
Operation: enterItem(…)
Post-conditions: -…
Cashier: … Item ID: … …
conceptual classes in the domain inspire the names of some software classes in the design
Domain Model: A Visual Dictionary
• The domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain
concept or domain object
association
Contained-in
Records-sale-of
Sales LineItem
1 Stocked-in
Captured-on
address name
attributes
A partial domain model for POS
A partial domain model for Monopoly
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-4
concept’s symbol
“A sale represents the event of a purchase transaction. It has a date and time.”
concept’s intension
concept’s extension
A Conceptual Class: How to identify it?
Three strategies to find a conceptual class from use cases
1. Identify based on the existing models for common domain problems, e.g., inventory, finance, etc.
– Books: Analysis Patterns by , Data Model Patterns by
2. Use a category list
– See the conceptual class category list in
Table 9.1 in the textbook ( 9) 3. Identify noun phrases
– Care must be applied as words in natural languages are ambiguous
– Do not use as a mechanical noun-to-class mapping
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
Where are transactions recorded? Register, : important FlightManifest, MaintenanceLog
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.
Similar Concepts
• In the problem domain, there might be concepts that look very similar
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.
Partial domain model
– The conceptual classes are not well organized.
– The association between items, books, and video is missing. Same for users
Domain Model: Generalization-Specialization Class Hierarchy (or Class Hierarchy)
• When concepts are very similar, it is valuable to organise them
• Generalization: The activity of identifying commonality among concepts
– Define superclass (general concept)
– Define relationships with subclasses (specialized concepts)
– Conceptual subclasses and superclasses are related
in terms of set membership
Superclass (General Concept)
Subclass (Specialized Concept)
• Why? these are conceptual classes, not software
– Economy of expression
– Reduction in repeated information
– Improved comprehension
Cash Payment
Credit Payment
Check Payment
See more in Textbook Chapter 31
A Domain Class Model
Domain Model with Class Hierarchy
• Organise the similar concepts as subclasses
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.
on loan **1
– yearProduced – due :Date
– returned?
– duration
Partial domain model
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
association name
Records-current
multiplicity
*See Workshop 2 supplementary materials
POS: Partial Domain Model
Contained-in
Records-sale-of
Paid-by 1 1 Is-for
Works-on
Product Description
Records- accounts-
*Describes
Sales LineItem
Logs- completed
Captured-on
CashPayment
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
at tr ib u te s
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.
/ total : Money
derived attribute
POS: Attributes in Model
Contained-in
Records-sale-of
Works-on
Product Description
itemID description price
Records- accounts-
*Describes
Sales LineItem
Logs- completed
Captured-on
name address
dateTime / total
CashPayment
amountTendered
Subclasses vs Attributes
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.
Number of unreturned load should not exceed borrowLimit
loaned to on loan 1**1
– kind :{student, staff, guest} – borrowLimit
– returned?
– yearProduced – due :Date
Partial domain model
No difference in behaviours or attributes so can’t justify different user kinds as different classes.
– duration
Guideline for determining subclasses
Guideline for creating subclasses:
1. Subclass has additional attributes of interest
2. Subclass has additional associations of interest
3. Subclass is operated on, handled, reacted to, or manipulated differently to the other classes in noteworthy ways
Modelling Guidelines:
a) Declare superclasses abstract
b) Append the superclass name to the subclass
Sample UP Artifact Relationships Domain Model
Business Modeling
Use-Case Model
use case names
Sales LineItem
objects, attributes, associations
scope, goals, actors, features
terms, attributes, validation
System Sequence Diagrams
Textbook: 10
Require- ments
Use Case Diagram
Use Case Text
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
system events
Operation: enterItem(…)
Post-conditions: -…
make NewSale()
Supplementary Specification
system operations
enterItem (id, quantity)
re qu ir em e nts
Operation Contracts
System Sequence Diagrams
Design Model
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
non-functional reqs, quality attributes
: Register (itemID, quantity)
: ProductCatalog
Domain Model
Business Modeling
1 1..* date
System Sequence Diagrams (SSDs)
• 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
use case names
Require- ments
Use Case Diagram
Use Case Text
system events
Operation: enterItem(…)
Post-conditions: -…
Process Sale
Sales LineItem
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
system operations
make NewSale()
enterItem (id, quantity)
Operation Contracts System Sequence Diagrams
starting events to design for
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.
4. System records sale line item and «actor»
Process Sale Scenario
makeNewSale
loop [ more items ]
enterItem(itemID, quantity) description, total
Use Case Diagram: POS
SSD for POS Process Sale Scenario
the left on the right
presents item description, price, and
Payment Cashier repeats steps 3-4 until indicates
running total.
Authorization
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
supporting actors
primary actors on
NextGen Process Sale
endSale total with taxes
makePayment(amount) change due, receipt
SSDs: Dynamic Context
• SSD captures dynamic context for system
Use Case Diagram: Monopoly
SSD for a Play Monopoly Game Scenario
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
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.
[ more items ]
enterItem(itemID, quantity) description, total
endSale total with taxes
makePayment(amount) change due, receipt
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.
Process Sale Scenario
makeNewSale
[ more items ]
enterItem(itemID, quantity) description, total
endSale total with taxes
makePayment(amount) change due, receipt
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
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com