SOEN 343 Software Design Section H Fall 2006

  • Slides: 24
Download presentation
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http: //www. cs.

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http: //www. cs. concordia. ca/~gregb/home/soen 343 h-f 06. html

Miscellaneous Domain Modeling: Larman ch 9 Use case modeling: Larman ch 6 Operation Contracts:

Miscellaneous Domain Modeling: Larman ch 9 Use case modeling: Larman ch 6 Operation Contracts: Larman ch 11

Larman’s Design Process

Larman’s Design Process

DEFINITION & MOTIVATION: Domain Model • A Domain Model visualizes, using UML class diagram

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 Layer Low representational gap

Domain Model and Domain Layer Low representational gap

Concepts Fig. 9. 3

Concepts Fig. 9. 3

Conceptual classes Fig. 9. 5

Conceptual classes Fig. 9. 5

Guidelines 9. 5 reuse existing model; use category list (see Table 9. 1) identify

Guidelines 9. 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 Product. Description

GUIDELINES: Associations • Only add associations for noteworthy relationships. Literally, those for which making

GUIDELINES: Associations • Only add associations for noteworthy relationships. Literally, those for which making a “note” is worthy or business motivated.

Associations See Table 9. 2

Associations See Table 9. 2

UML and GUIDELINES: Attributes • Show only “simple” relatively primitive types as attributes. •

UML and GUIDELINES: Attributes • Show only “simple” relatively primitive types as attributes. • Connections to other concepts are to be represented as associations, not attributes.

GUIDELINES: Attributes • Why? ?

GUIDELINES: Attributes • Why? ?

EXAMPLE: Domain Model

EXAMPLE: Domain Model

Ch 6: Use cases Review: done in SOEN 342 see separate slides Remember: use

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 Operation Method Invariant Precondition

Ch 11: Operation Contracts Aim: Define system operations via contracts Operation Method Invariant Precondition Postcondition

Context within artefacts

Context within artefacts

Context with SSDs

Context with SSDs

UML Definitions Event A significant or noteworthy occurrence. Operation An operation is a specification

UML Definitions Event A significant or noteworthy occurrence. Operation An operation is a specification of a transformation or query that an object may be called to execute. [RJB 1999] 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]

Definitions Contract A contract specifies detailed changes, as a result of a system operation,

Definitions Contract 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. State A 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

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 Invariant Is a condition which is always true

Invariant of a System or Object Invariant Is 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 Definition The postconditions describe changes in the state of objects in the domain

Postcondition Definition The 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 Postconditions Document 1. Instance creation and deletion “A Sales. Line. Item sli was

Writing Postconditions Document 1. Instance creation and deletion “A Sales. Line. Item 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 product. Description based on item. ID match” Use past tense.

Guidelines 1. Identify system operations from the SSDs. 2. For system operations that are

Guidelines 1. 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, document 1. Instance creation and deletion 2. Attribute modification 3. Links formed and broken Use past tense for postconditions. Remember to document the forming of links!