24
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/ soen343h-f06.html

SOEN 343 Software Design

  • Upload
    fran

  • View
    37

  • 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

Page 1: SOEN 343 Software Design

SOEN 343Software Design

Section H Fall 2006

Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

Page 2: SOEN 343 Software Design

Miscellaneous

Domain Modeling: Larman ch 9

Use case modeling: Larman ch 6

Operation Contracts: Larman ch 11

Page 3: SOEN 343 Software Design

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

Page 4: SOEN 343 Software Design

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.”

Page 5: SOEN 343 Software Design

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

Page 6: SOEN 343 Software Design

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

Page 7: SOEN 343 Software Design

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

Page 8: SOEN 343 Software Design

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

Page 9: SOEN 343 Software Design

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?

Page 10: SOEN 343 Software Design

AssociationsSee Table 9.2

Page 11: SOEN 343 Software Design

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

Page 12: SOEN 343 Software Design

GUIDELINES: Attributes

• Why??

Video

...

Rents1 1..*Customer

...Better

Video

renter : Customer

Customer

rentedVideos: List of VideoWorse

Page 13: SOEN 343 Software Design

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

Page 14: SOEN 343 Software Design

Ch 6: Use cases

Review: done in SOEN 342

see separate slides

Remember: use cases in context

Page 15: SOEN 343 Software Design

Ch 11: Operation Contracts

Aim: Define system operations via contracts

OperationMethod

InvariantPreconditionPostcondition

Page 16: SOEN 343 Software Design

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 17: SOEN 343 Software Design

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 18: SOEN 343 Software Design

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 19: SOEN 343 Software Design

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 20: SOEN 343 Software Design

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 21: SOEN 343 Software Design

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 22: SOEN 343 Software Design

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 23: SOEN 343 Software Design

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 24: SOEN 343 Software Design

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!