Transcript Use-Case Model : Adding Detail with operation contracts

Use-Case Model : Adding
Detail with operation contracts
Larman ch. 11
Larman ch. 11
1
UP artifacts
Partial artif acts,
ref ined in each
iteration.
Sam ple UP Artifacts
Domain
Model
Business
Modeling
*
*
the domain objects,
attributes, and
associations that undergo
state changes
Use-Case Model
:System
foo( x )
Requirements
Glossary
...
bar( y )
text
use
cases
use
case
diagrams
sy stem
sequence
diagrams
system
operations
sy stem
operation
contracts
Design Model
Design
Larman ch. 11
the system operations
are handled by
designing software to
fulfill the post-conditions
of the contracts
Sof tware
Architecture Doc.
2
Operation contracts
• Part of the use-case model
– Analyze technique
• Use cases are the primary mechanism in UP to
describe system behavior
• Contracts help define system behavior
– Adds more details
– Contracts may not be needed.
• Objectives
– Define operation contracts with Post conditions
– Relate contracts to the Domain Model and the UseCase Model.
Larman ch. 11
3
System operations handle system
events
:Sy stem
: Cashier
enterItem(itemID, quantity )
System events invoke systems
Operations.
description, total
* [more items]
endSale()
total with taxes
The System event makeNewSale
invokes a System operation
called makeNewSale
makePay ment(amount)
change due, receipt
Larman ch. 11
4
Contracts CO2 : enterItem
•
Operation :
– Name of operation and parameters
– enterIOtem(itemID: ItemID, quantity : integer)
•
Cross Refernce :
– Optional use case this operation can occur within
– Use Cases : Process Sale
•
Preconditions :
– Assumptions about the state of the system before execution of the operation
– There is a sale underway
•
Postconditions :
–
–
–
–
–
The state of the objects in the domain model after completion of the operation
A SalesItem instanse sli was created (instance creation)
Sli was associated with the current Sale (association formed)
Sli.quantity became quantity (attribute modification)
Sli was associated with a ProductsSpecification, based on itemID match
(association formed)
Larman ch. 11
5
Postconditions
• Describe changes in the state of objects
in the domain model that are true when
the operation has finished.
• They are not actions to be performed during the
operation
• Postconditions fall into these categories :
– Instance creation and deletion
– Attribute modification
– Associations (UML links) formed and broken.
Larman ch. 11
6
WHAT !!!
• Focus on WHAT must happen in terms of
objects in the Domain Model.
– What instances can be created ?
– What associations can be formed ?
– What attribute can be modified ?
• Don’t describe HOW it is archived.
Larman ch. 11
7
Contracts leads to….
• It is common to discover
– new conceptual Classes
– Attributes
– Associations
• Don’t be limited to the prior definition of
the Domain Model
Larman ch. 11
8
Guidelines : Contratcs
1. Identifying operations from the SSDs.
2. For system operations that are complex and
perhaps subtle in their results, or which are not
clear in the use case, constructs a contract.
3. To describe the postconditions, use the
following categories :
•
•
•
Instance creation and deletion
Attribute modification
Associations formed and broken
Larman ch. 11
9
Postconditions : past tense
• Notice that the statements are expressed
in the past tense :
– A SalesLineItem sli was created (instance
operation)
– Sli was associated with the current Sale
(association formed)
Larman ch. 11
10
NextGen POS example
• P. 185-186
Larman ch. 11
11
Artifact relationships
Domain Model
Sale
Sales
LineItem
1..*
1
date
...
...
...
quantity
the domain objects, attributes, and
associations that undergo state changes
domain objects
Use-Case Model
: Sy stem
Operation: makeNewSale
Process Sale
1. Customer
arriv es ...
2. ...
3. Cashier
enters item
identif ier.
4....
: Cashier
system
events
make
NewSale()
Post-conditions:
-...
enterItem
(id, quantity )
system
operations
Operation: enterItem
endSale()
Post-conditions:
- A SalesLineItem instance
sli was created
-...
makePay ment
(amount)
Contracts
System Sequence Diagrams
Use Cases
some ideas and inspiration for the postconditions derive from the use cases
requirements that
must be satisfied by
the design of the
software
in addition to the use cases,
requirements that must be
satisfied by the design of the
software
Design Model
: Register
: ProductCatalog
: Sale
enterItem
(itemID, quantity )
spec := getProductSpec( itemID )
addLineItem( spec, quantity )
...
Larman ch. 11
12