Click here to load reader

SOEN 343 Software Design

  • 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

Text of SOEN 343 Software Design

  • SOEN 343Software DesignSection H Fall 2006Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

  • MiscellaneousDomain Modeling: Larman ch 9

    Use case modeling: Larman ch 6

    Operation Contracts: Larman ch 11

  • Larmans Design Process

    Class

    Cashier

    Class

    Records

    1..*

    (1)msg()

    output

    x: Class

    *

    1..40

    *

    1..40

    Records

    (1)msg()

    Cashier

    Buying Items

    DD file

    (1)msg()

    ClassName

    attributes

    operations

    1

    *

    : System

    Require-ments

    Business Modeling

    Design

    enterItem(id, quantity)

    Domain Model

    Use-Case Model

    Process Sale

    1. Customer arrives ...2. ...3. Cashier enters item identifier.

    Design Model

    system operations

    Use Case Text

    System Sequence Diagrams

    Operation: enterItem()

    Post-conditions:- . . .

    Operation Contracts

    Sale

    date. . .

    SalesLineItem

    quantity

    1..*

    . . .

    makeNewSale()

    system events

    . . .

    1

    Cashier

    : Register

    enterItem(itemID, quantity)

    : ProductCatalog

    d = getProductDescription(itemID)

    addLineItem( d, quantity )

    : Sale

    Register

    Sample UP Artifact Relationships

    Process Sale

    : Cashier

    use case names

    Use Case Diagram

    ...

    makeNewSale()enterItem(...)...

    ProductCatalog

    ...

    getProductDescription(...)...

    non-functional requirements

    domain rules

    item details, formats, validation

    SupplementarySpecification

    Glossary

    functional requirements that must be realized by the objects

    ideas for the post-conditions

    starting events to design for, and detailed post-condition to satisfy

    inspiration for names of some software domain objects

  • DEFINITION & MOTIVATION: Domain ModelA 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

    Store

    role

    records

    *

    Class

    records

    1..40

    ClassName

    attributes

    operations

    role

    Drag the side handles to change the width of the text block.

    *

    Class

    ClassName

    attributes

    operations

    1

    1

    Note

    Payment

    amount: Money

    Payment

    amount

    getBalance(): Money

    Sale

    date: DatestartTime: Time

    Sale

    getTotal(): Money. . .

    datetime

    Pays-for

    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.

    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

    Class

    Note

    Sale

    dateTime

    visualization of a real-world concept in the domain of interest

    it is a not a picture of a software class

    Class

    Note

    ClassName

    attributes

    operations

    SalesDatabase

    software artifact; not part of domain model

    avoid

    Sale

    datetime

    software class; not part of domain model

    avoid

    print()

  • Conceptual classes Fig. 9.5

    Class

    Note

    Class

    Sale

    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-3

    sale-2

    sale-4

    concept's extension

  • Guidelines9.5reuse existing model; use category list (see Table 9.1) identify noun phrases9.9 Include Report Objects, eg Receipt9.10 Think like a mapmaker9.11 How to model the unreal world9.13 Description class, eg ProductDescription

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

  • AssociationsSee Table 9.2

  • UML and GUIDELINES: AttributesShow only simple relatively primitive types as attributes.

    Connections to other concepts are to be represented as associations, not attributes.

  • GUIDELINES: AttributesWhy??

  • EXAMPLE: Domain Model

  • Ch 6: Use casesReview: done in SOEN 342see separate slides

    Remember: use cases in context

  • Ch 11: Operation ContractsAim: Define system operations via contracts

    OperationMethod

    InvariantPreconditionPostcondition

  • Context within artefacts

    Class

    Cashier

    Class

    Records

    1..*

    (1)msg()

    output

    x: Class

    *

    1..40

    *

    1..40

    Records

    (1)msg()

    Cashier

    Buying Items

    DD file

    : System

    Require-ments

    Business Modeling

    Design

    enterItem(id, quantity)

    Domain Model

    Use-Case Model

    Process Sale

    1. Customer arrives ...2. ...3. Cashier enters item identifier.

    Design Model

    system operations

    Use Case Text

    System Sequence Diagrams

    Operation: enterItem()

    Post-conditions:- . . .

    Operation Contracts

    Sale

    date. . .

    SalesLineItem

    quantity

    1..*

    . . .

    makeNewSale()

    system events

    . . .

    1

    Cashier

    : Register

    enterItem(itemID, quantity)

    : ProductCatalog

    spec = getProductSpec( itemID )

    addLineItem( spec, quantity )

    : Sale

    Sample UP Artifact Relationships

    Process Sale

    : Cashier

    use case names

    Use Case Diagram

    Vision

    SupplementarySpecification

    Glossary

    requirements that must be satisfied by the software

    ideas for the post-conditions

    starting events to design for, and more detailed requirements that must be satisfied by the software

    the domain objects, attributes, and associations that undergo changes

  • Context with SSDs

    1: msg()

    Class

    Cashier

    (1)msg()

    output

    x: Class

    Note

    [guard]

    [guard]

    [guard]

    [guard]

    [guard]

    [guard]

    [guard]

    [guard]

    enterItem(itemID, quantity)

    :System

    endSale()

    makePayment(amount)

    makeNewSale()

    these input system events invoke system operations

    the system event enterItem invokes a system operation called 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

    : Cashier

    description, total

    total with taxes

    change due, receipt

    [ more items ]

    loop

    Process Sale Scenario

  • UML DefinitionsEventA 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]

  • DefinitionsContractA contract specifies detailed changes, as a result of a system operation, to objects in the domain model using pre-conditions and post-conditions.

    Contract FormatOperation: 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 SystemDescribe 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 ObjectInvariantIs a condition which is always true about the state of the system (or object)

    Note: the state is only defined in between execution of operationsHence, invariant only has to be true before and after each operation, not during an operation

  • PostconditionDefinitionThe 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 operationThey are the effect, ie observations about state of domain objects when the operation is finished.Ie, what not how

  • Writing PostconditionsDocumentInstance creation and deletionA SalesLineItem sli was createdAttribute change of v

Search related