SOEN 343 Software Design

  • View
    44

  • Download
    0

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. Responsibilities, Principles, Patterns. RDD (Responsibility Driven Design) GRASP Principles Cohesion, Coupling Introduction to Patterns and Architecture. - 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

  • Responsibilities, Principles, PatternsRDD (Responsibility Driven Design)

    GRASP PrinciplesCohesion, Coupling

    Introduction to Patterns and Architecture

  • 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 PrinciplesCreatorExpertControllerLow CouplingHigh CohesionPolymorphismPure FabricationIndirectionProtected Variations

  • Object ResponsibilitiesA responsibility is an obligation of an object in terms of its behavior.

  • General Classification of Kinds of Responsibility To know.To do.To decide.

  • Responsibilities A Boat MetaphorWhat kind of responsibilities do each of the following objects have: To know.To do.To decide.

  • Responsibilities A Boat MetaphorKind of responsibility for:CaptainTo know?To do?To decide?

  • Responsibilities A Boat MetaphorKind of responsibility for:Navigator.To know?To do?To decide?

  • Responsibilities A Boat MetaphorKind of responsibility for:Compass.To know?To do?To decide?

  • RDD Example: Apply IEInformation Expert: Give task to the object having the information to perform the task.

    Example: Larman 17.11 NextGEN POS application

    Who should be responsible for knowing the grand total of a sale?

  • Fig. 9.2 NextGEN Domain Model

    entityClass

    Class

    ClassName

    attributes

    operations

    entityClass

    Class

    ClassName

    attributes

    operations

    Records

    *

    1..*

    Records

    1..40

    Records

    *

    1..40

    Note

    Captured-on

    conceptor domain object

    Stocked-in

    Houses

    1..*

    Register

    Item

    association

    Store

    addressname

    Sale

    date time

    Payment

    amount

    SalesLineItem

    quantity

    attributes

    Contained-in

    1..*

    1

    Records-sale-of

    0..1

    1

    Paid-by

    1

    1

    1

    1

    0..1

    1

  • Fig. 17.14 NextGEN Design

    Class

    Records

    *

    1..*

    Records

    1..40

    Records

    1..*

    1

    Contains

    Sale

    time

    SalesLineItem

    quantity

    ProductDescription

    descriptionpriceitemID

    Described-by

  • IE ExampleResponsibilities

    Sale: knows sale total

    SalesLineItem: knows line item subtotal

    ProductDescription: knows product price

  • Fig. 17.17 NextGEN Design

    ClassName

    attributes

    operations

    xxx

    id:Class

    1: msg()

    Note

    msg()

    id:Class

    1: msg()

    *

    Sale

    time...

    getTotal()

    1 *: st = getSubtotal

    : Sale

    t = getTotal

    :ProductDescription

    SalesLineItem

    quantity

    getSubtotal()

    ProductDescription

    descriptionpriceitemID

    getPrice()

    New method

    lineItems[ i ] :SalesLineItem

    1.1: p := getPrice()

  • RDD Example: Apply CreatorLarman 17.10: NextGEN exampleWho should be responsible for creating a new SalesItem instance?

    Exercise!

  • Design Principles

    Design for change

  • GRASPGeneral Responsibility Assignment Software Patterns.Information ExpertCreatorLow CouplingHigh CohesionController (still to come, from ch17)Polymorphism

  • 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?

  • Levels Of Cohesion

  • CouplingMeasures the degree of dependency that exists between modules.

    Brain storm:Give examples of code that creates coupling.

  • 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

  • How Do I Come Up With a Design?GivenProduct requirements.Project plan

    How do I come up with a design?

  • Design Repeat SuccessesHas a (successful) similar product been built?Yes, then reuse domain specific:ArchitecturalStyle (e.g. client/server, database, process control)Patterns.Design Patterns (& idioms).Use Domain model as source of inspiration.

  • Design New Application Area?Has a (successful) similar product been built?No, then choose among general:ArchitecturalStyle (e.g. client/server, database, process control)Patterns.Design Patterns (& idioms).Use Domain model as source of inspiration.

  • Common Architectural Styles [FYI]DataflowPipes and filtersBatch sequentialData-centeredRepositoryBlackboardVirtual MachineInterpreterRule-based systemCall and ReturnMain program and subroutineObject-oriented (& Data abstraction)LayeredIndependent ComponentsCommunicating processesClient/serverEvent systemsImplicit invocationExplicit invocation

  • Layered Architectural StyleOur focus today:Architectural style: Layered.ReferencesLarman, Chapter 13.Fowler, EA.

    Briefly, lets review Client-Server

  • Client-Server (Two-tiered System) most people see tier as implying a physical separation. Client-server systems are often described as two-tier systems [Fowler,p19]

  • Enterprise Application Layers

    id:Class

    Authorize payments

    Database

    Calculate taxes

  • Enterprise Application LayersPresentationDomain LogicData Source

  • Layering General SchemeLayersPresentation / Application.UI.Generally thin.(Term application can be misleading. It does not mean )Domain / Business Logic.Core system functionality.Technical Services.

  • Domain Logic (Layer) also referred to as business logic. It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch [Fowler, p.20]

  • Layered Style CharacteristicsEach layer offers services to layers above.Hence, layers build upon each other to provide increased functionality.

  • Layers: FunctionalityPresentationDomainData SourceFunctionality / services

  • Layers: DependenciesPresentationDomainData SourceDependencies

  • Layer Dependencies Example

    Technical Services

    Text

    Swing

    Log4J

    SOAP

    Domain

    Jess

    Presentation

    Persistence

    POSRuleEngine

    Inventory

    Payments

    ServiceAccess

    Pricing

    Sales

  • Layering Pure StylePure style: components are permitted to use services of other components insame layer.layer immediately below.

  • Where to Run Your Layers[Folwer, pp. 22-24]Your software application??

  • Where to Run Your LayersEA softwareTechnical Services

  • EA Layers RefinedPresentationDomain LogicData Source

  • General Layering Scheme RefinedPresentation

    Domain

    Technical servicesPresentationApplication

    Domain (logic)Low-level domain logic

    Technical servicesFoundation.

  • General Layering Scheme RefinedPresentation

    Domain

    Technical servicesPresentationApplication

    Business servicesLow-level business services

    Technical servicesLow-level technical services

  • Layering (Larman)See Larman Sect 13.6

    Technical Services(AKA Technical Infrastructure, High-level Technical Services)

    Foundation(AKA Core Services, Base Services,Low-level Technical Services/Infrastructure)

    Business Infrastructure(AKA Low-level Business Services)

    Presentation(AKA Interface, UI, View)

    Application(AKA Workflow, Process,Mediation, App Controller)

    Domain(s)(AKA Business, Business Services, Model)

    Class

    Text

    GUI windowsreportsspeech interfaceHTML, XML, XSLT, JSP, Javascript, ...

    handles presentation layer requestsworkflowsession statewindow/page transitionsconsolidation/transformation of disparate data for presentation

    handles application layer requestsimplementation of domain rulesdomain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services

    (relatively) high-level technical services and frameworks Persistence, Security

    low-level technical services, utilities, and frameworksdata structures, threads, math, file, DB, and network I/O

    very general low-level business services used in many business domainsCurrencyConverter

    [BCK98, Fig 5.1 p. 95]

    Larman Fig. 30.4Refine by splitting each layer into two.Alternate names for