Click here to load reader

SOEN 6011 Software Engineering Processes

  • View
    43

  • Download
    0

Embed Size (px)

DESCRIPTION

SOEN 6011 Software Engineering Processes. Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html. Week 8. GRASP Principles Design and use case realization Design patterns. Responsibility-Driven Design (RDD). - PowerPoint PPT Presentation

Text of SOEN 6011 Software Engineering Processes

  • SOEN 6011Software Engineering ProcessesSection SS Fall 2007Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

  • Week 8GRASP PrinciplesDesign and use case realizationDesign patterns

  • Responsibility-Driven Design (RDD)Detailed object design is usually done from the point of view of the metaphor of:Objects have responsibilitiesObjects collaborateResponsibilities are an abstraction.The responsibility for persistence.Large-grained responsibility.The responsibility for the sales tax calculation.More fine-grained responsibility.

  • The 9 GRASP PrinciplesCreatorInformation ExpertControllerLow CouplingHigh CohesionPolymorphismPure FabricationIndirectionProtected Variations

  • Information Expert expresses the common intuition that objects do things related to the information they have.Assign the responsibility for knowing [something] to the object (class) that has the information necessary to fulfill the responsibility.

  • CreatorAssign to class B the responsibility to create an instance of class A ifB aggregates A objects.B contains A objects.B records instances of A objects.B closely uses A objects.B has the initializing data that will be passed to A when it is created.

  • GRASP: Polymorphism PrincipleLarman:When related alternatives or behaviors vary be type (class), assign responsibility for the behaviorusing polymorphic operationsto the types for which the behavior varies.(This principle was illustrated last week with the Animal hierarchy.)

  • PATTERN: Controller (Larman 17.13)Problem: What object in the domain (or application coordination layer) receives requests for work from the UI layer?

    System operations (see SSD): major input events to the system

    The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operations message.

    Note that UI objects delegate system operation request to a controller.

  • PATTERN: Controller (Larman 17.13)Solution: Assign the responsibility to a class representing one of the following choices:A faade controller, which representsthe overall systemA root objectA device that the software is running within, orA major subsystemA use case or session controller which represents a use case scenario in which the system operation occurs

  • EncapsulationA programming/design language mechanism.A packaging / scoping mechanism for namesNames can refer to data, types, Especially, a means of packaging data.

    Data

  • Information HidingDesign principle by which a module is assigned a secret.A modules secret is usuallyA design decision.

    What type of design decisions might we want to hide from the clients of a module?

  • CohesionMeasure of the degree of relatedness that elements within a module share.Degree to which the tasks performed by a single module are functionally related.

    Brain storm:Why put procedures/methods together within a module/class?

  • CouplingMeasures the degree of dependency that exists between modules.

  • CouplingA uses a service/method m of BA passes on an object o returned from B.m()A provides visibility of B to C by returning a reference to B in A.getB()A.m( B b, )A calls C.m(B b ) which expects a B objectA class X in A has an attribute of type Y defined in B

  • CouplingA.m() changes an attribute in B via B.setX()A.m() changes a (public) attribute in B directly via assignmentA changes a flag in B (ie an attribute which controls execution decisions in B; ie behaviour of B as seen by others)A and B both refer to an object o, and A can change o

  • Pure FabricationProblem: Existing objects, ie domain objects, are not appropriate to have the responsibilitySolution suggested by Information Expert not appropriateMight violate high cohesion, low coupling

    Solution: Fabricate (ie create, make up) a new object to hold the responsibility

  • GRASP: Pure FabricationAssign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain conceptsomething made up, to support high cohesion, low coupling, and reuse.

    Can you think of an example from EA?

  • GRASP: Pure FabricationDesign of objectsRepresentational decompositionBehavorial decompositionIts OK for OO software to have objects representing behaviour, ie use case, process, function, strategy, TSBut do not overdo it

    All GoF design patterns are Pure Fabrications

  • IndirectionProblem: How to assign responsibility to avoid direct coupling? How to de-couple objects?Solution: Assign responsibility to an intermediatory object to mediate between the two components

    Example: Adapter patternIntermediatory to external tax calculators

  • Fig. 25.10

    Store

    role

    records

    *

    Class

    Class

    records

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

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

    Select box and type. Control handles change width & height of box.

    Select oval andtype. Control handles change width & height of oval.

    msg()

    Sale

    entityClass

    id:Class

    1: msg()

    msg()

    msg()

    msg()

    1: msg()

    xxx

    1: msg()

    Note

    id:Class

    Note

    id:Class

    Cashier

    newClass

    the adapter acts as a level of indirection to external systems

    . . .

    xxx

    TCP socket communication

    ...

    : Sale

    :TaxMasterAdapter

    taxes = getTaxes( s )

    t = getTotal

    actor:TaxMasterSystem

  • IndirectionMost problems in computer science can be solved by another level of indirection

  • GRASP Protected VariationsProblem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesireable impact on other elements?Solution: Identify points of predicted variation or instability; assign responsibility to create a stable interface around them.

  • Core PV MechanismsEncapsulation.Interfaces.Polymorphism.Indirection,

    (Note: we are speaking of mechanisms, not principles)

  • Patterns apply principles, e.g.

    ClassName

    attributes

    operations

    Note

    interfaceFoo

    foo()

    Note

    Records

    1

    *

    1..*

    role

    Class

    Low Coupling Mechanism

    IndirectionMechanism

    Adapter

    Pure Fabrication

    PolymorphismExample

    GoF Design Patterns

    GRASP Principles

    High CohesionMechanism

    Protected VariationMechanism

  • GRASP: Interrelationships

    ClassName

    attributes

    operations

    Note

    interfaceFoo

    foo()

    Note

    Records

    1

    *

    1..*

    role

    Class

    Low Coupling Mechanism

    IndirectionMechanism

    Adapter

    Pure Fabrication

    PolymorphismExample

    GoF Design Patterns

    GRASP Principles

    High CohesionMechanism

    Protected VariationMechanism

  • Week 8GRASP PrinciplesDesign and use case realizationDesign patterns

  • Design Model

    Class

    Cashier

    Class

    Records

    1..*

    (1)msg()

    output

    x: Class

    *

    1..40

    *

    1..40

    Records

    (1)msg()

    Cashier

    Buying Items

    DD file

    DD file

    Cashier

    Buying Items

    *

    ClassName

    attributes

    operations

    1

    Require-ments

    Business Modeling

    Design

    Design Model

    : Register

    enterItem(itemID, quantity)

    : ProductCatalog

    spec = getProductSpec( itemID )

    Register

    ...

    Sample UP Artifact Relationships

    Vision

    SupplementarySpecification

    Glossary

    The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

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

    Domain Model

    Use-Case Model

    ProductCatalog

    ...

    getProductSpec(...)...

    class diagrams(a static view)

    interaction diagrams(a dynamic view)

    UI

    package diagramsof the logical architecture(a static view)

    Domain

    Tech Services

  • What are the users doing? (Jacobson)What are the objects in the real world? (Rumbaugh)What objects are needed for each use case? (Jacobson)How do the objects collaborate with each other? (Jacobson and Booch)How will we implement real-time control? (state models)How are we really going to build this system? (Booch)

  • 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

Search related