Upload
fran
View
36
Download
1
Embed Size (px)
DESCRIPTION
SOEN 343 Software Design. Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html. Miscellaneous. Domain Modeling: Larman ch 9 Use case modeling: Larman ch 6 Operation Contracts: Larman ch 11. Larman’s Design Process. - PowerPoint PPT Presentation
Citation preview
SOEN 343Software Design
Section H Fall 2006
Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html
Miscellaneous
Domain Modeling: Larman ch 9
Use case modeling: Larman ch 6
Operation Contracts: Larman ch 11
Larman’s Design Process
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
d = getProductDescription(itemID)
addLineItem( d, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
SupplementarySpecification
Glossary
starting events to design for, and detailed post-condition to satisfy
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.
inspiration for names of some software domain objects
functional requirements that must be realized by the objects
ideas for the post-conditions
Register
...
makeNewSale()enterItem(...)...
ProductCatalog
...
getProductDescription(...)...
1*
non-functional requirements
domain rules
item details, formats, validation
DEFINITION & MOTIVATION: Domain Model
• A Domain Model visualizes, using UML class diagram notation, noteworthy concepts or objects.– It is a kind of “visual dictionary.”– Not a picture of software classes.
• It helps us identify, relate and visualize important information.
• It provides inspiration for later creation of software design classes, to reduce “representational gap.”
Domain Model and Domain LayerLow representational gap
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.
Domain layer of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.
Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.
This reduces the representational gap.
This is one of the big ideas in object technology.
inspires objects
and names in
Concepts Fig. 9.3
Sale
dateTime
visualization of a real-world concept in the domain of interest
it is a not a picture of a software class
SalesDatabase software artifact; not part of domain modelavo
id
software class; not part of domain model
Sale
datetime
print()
avoid
Conceptual classes Fig. 9.5Sale
datetime
concept's symbol
"A sale represents the event of a purchase transaction. It has a date and time."
concept's intension
sale-1
sale-3sale-2
sale-4
concept's extension
Guidelines9.5
reuse existing model;
use category list (see Table 9.1)
identify noun phrases
9.9 Include Report Objects, eg Receipt
9.10 Think like a mapmaker
9.11 How to model the ‘unreal’ world
9.13 Description class, eg ProductDescription
GUIDELINES: Associations
• Only add associations for noteworthy relationships. Literally, those for which making a “note” is worthy or business motivated.
Video
...Rents
Influenced-by
1
1..*
1 Loan Policy
...
Customer
...
Important association.Need to remember.
Low value association.Possible, but so what?
AssociationsSee Table 9.2
UML and GUIDELINES: Attributes
• Show only “simple” relatively primitive types as attributes.
• Connections to other concepts are to be represented as associations, not attributes.
P aym ent
date : D atetim e : T im eam ount : M oney
attribu tes
GUIDELINES: Attributes
• Why??
Video
...
Rents1 1..*Customer
...Better
Video
renter : Customer
Customer
rentedVideos: List of VideoWorse
EXAMPLE: Domain Model
Catalog
VideoDescription
titlesubjectCategory
VideoRental
dueDatereturnDatereturnTime
CashPayment
amount : Money
Video
ID
Stocks
Rents
Rents-from
Pays-for
Initiates
Owns-a
Described-by
Membership
IDstartDate
11
1..*
1
1
1
1..*
1
1
*
1
1
1
*1*
Pays-for-overdue-charges
RentalTransaction
date
LoanPolicy
perDayRentalChargeperDayLateCharge
Determines-rental-charge
1
Defines
1..*
*
1..*
1
1
* *
VideoStore
addressnamephoneNumber
Customer
addressnamephoneNumber
1
1
1..*
Records-rental-of
0..1
1
Has Maintains
*
1
1
Ch 6: Use cases
Review: done in SOEN 342
see separate slides
Remember: use cases in context
Ch 11: Operation Contracts
Aim: Define system operations via contracts
OperationMethod
InvariantPreconditionPostcondition
Context within artefacts
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
Vision
SupplementarySpecification
Glossary
starting events to design for, and more detailed requirements that must be satisfied by the software
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.
the domain objects, attributes, and associations that undergo changes
requirements that must be satisfied by the software
ideas for the post-conditions
Context with SSDs
: Cashier
enterItem(itemID, quantity)
endSale()
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale()
these input system events invoke system operations
the system event enterItem invokes a system operationcalled enterItem and so forth
this is the same as in object-oriented programming when we say the message foo invokes the method (handling operation) foo
[ more items ]loop
:System
Process Sale Scenario
UML DefinitionsEvent
A significant or noteworthy occurrence.
OperationAn operation is a specification of a transformation or query that an
object may be called to execute. [RJB1999]
Signature of an operation specifies the name, parameters, and return type (and exceptions thrown).
Pre-conditions and post-conditions are UML constraints specified using OCL (Object Constraint Language).
Method[A method is] the implementation of an operation. It specifies the
algorithm or procedure associated with an operation [OMG 2003]
DefinitionsContract
A contract specifies detailed changes, as a result of a system operation, to objects in the domain model using pre-conditions and post-conditions.
Contract Format– Operation: name and parameters of operation.– Cross References: use cases that involve the operation.– Preconditions: noteworthy assumptions about the state of the
system or object in the domain model before execution of the operation.
– Postconditions: The state of objects in the domain model after completion of the operation.
StateA state is the condition of an object (or system) at a moment in
time.
Describing the State of a System
Describe the objects in the system
Describe the links (relationships) between the objects
Describe the properties of each object (ie the state of the object)= the (abstract) values of the object attributes
[as in a state machine]
Invariant of a System or Object
InvariantIs a condition which is always true about the
state of the system (or object)
Note: the state is only defined in between execution of operations
Hence, invariant only has to be true before and after each operation, not during an operation
Postcondition
DefinitionThe postconditions describe changes in the state of
objects in the domain model. Domain model state changes include instances created, associations formed or broken, and attributes changed.
Note: postconditions are not actions to be performed during the operation
They are the effect, ie observations about state of domain objects when the operation is finished.
Ie, “what” not “how”
Writing PostconditionsDocument
1. Instance creation and deletion“A SalesLineItem sli was created”
2. Attribute change of value“sli.quantity became quantity”
Note: quantity is an operation parameter
3. Association links formed and broken“sli was linked to the current Sale”
“sli was linked with a productDescription based on itemID match”
Use past tense.
Guidelines1. Identify system 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, construct a contract.
3. To describe the postconditions, document1. Instance creation and deletion
2. Attribute modification
3. Links formed and broken
Use past tense for postconditions.
Remember to document the forming of links!