1 / 24

SOEN 343 Software Design

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.

fran
Télécharger la présentation

SOEN 343 Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Larman’s Design Process

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

  5. Domain Model and Domain Layer Low representational gap

  6. Concepts Fig. 9.3

  7. Conceptual classes Fig. 9.5

  8. 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 ProductDescription

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

  10. Associations See Table 9.2

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

  12. GUIDELINES: Attributes • Why??

  13. EXAMPLE: Domain Model

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

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

  16. Context within artefacts

  17. Context with SSDs

  18. 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. [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]

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

  20. 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]

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

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

  23. Writing Postconditions Document • Instance creation and deletion “A SalesLineItem sli was created” • Attribute change of value “sli.quantity became quantity” Note: quantity is an operation parameter • 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.

  24. Guidelines • Identify system operations from the SSDs. • For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. • To describe the postconditions, document • Instance creation and deletion • Attribute modification • Links formed and broken Use past tense for postconditions. Remember to document the forming of links!

More Related