13
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647- w2006.html

COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

Embed Size (px)

Citation preview

Page 1: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

COMP 6471Software Design Methodologies

Winter 2006

Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/comp647-w2006.html

Page 2: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

Ch 11: Operation Contracts

Aim: Define system operations via contracts

OperationMethod

InvariantPreconditionPostcondition

Page 3: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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

Page 4: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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

Page 5: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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]

Page 6: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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.

Page 7: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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]

Page 8: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

Example: State of CUWMEObjects

– users is the set of all User objects– roles is the set of all Role objects– projects is the set of all Project objects– Plus files, documents, …

Links– u works_on p for User and Project objects– p owns d for Project and Document objects– d is_stored_as f for Document and File objects– …

Object States– Document d has state “reviewed”– p.activity[3].status = “completed”– …

Page 9: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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

Page 10: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

Example Invariants of CUWME(These depend on your abstractions/assumptions.)

Each document is owned by exactly one project.

Each project owns exactly one document.

Each user has precisely one role in a given project.

A user may only access documents owned by the projects that a user is working on.

A document may be stored in more than one file.

A file has only a single location.

Page 11: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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”

Page 12: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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.

Page 13: COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler gregb/home/comp647-w2006.html

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!