1 / 44

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

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

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

  4. The 9 GRASP Principles • Creator • Expert • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • Protected Variations

  5. Object Responsibilities • A responsibility is an obligation of an object in terms of its behavior.

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

  7. Responsibilities – A Boat Metaphor • What kind of responsibilities do each of the following “objects” have: … • To know. • To do. • To decide.

  8. Responsibilities – A Boat Metaphor Kind of responsibility for: • Captain • To know? • To do? • To decide?

  9. Responsibilities – A Boat Metaphor Kind of responsibility for: • Navigator. • To know? • To do? • To decide?

  10. Responsibilities – A Boat Metaphor Kind of responsibility for: • Compass. • To know? • To do? • To decide?

  11. RDD Example: Apply IE Information 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?”

  12. Fig. 9.2 NextGEN Domain Model

  13. Fig. 17.14 NextGEN Design

  14. IE Example Responsibilities • Sale: knows sale total • SalesLineItem: knows line item subtotal • ProductDescription: knows product price

  15. Fig. 17.17 NextGEN Design

  16. RDD Example: Apply Creator Larman 17.10: NextGEN example “Who should be responsible for creating a new SalesItem instance? Exercise!

  17. Design Principles Design for change

  18. GRASP General Responsibility Assignment Software Patterns. • Information Expert • Creator • Low Coupling • High Cohesion • Controller (still to come, from ch17) • Polymorphism • …

  19. Cohesion • Measure 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?

  20. Levels Of Cohesion

  21. Coupling • Measures the degree of dependency that exists between modules. • Brain storm: • Give examples of code that creates coupling.

  22. Coupling A uses a service/method m of B A 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 object A class X in A has an attribute of type Y defined in B

  23. Coupling A.m() changes an attribute in B via B.setX() A.m() changes a (public) attribute in B directly via assignment A 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 …

  24. How Do I Come Up With a Design? • Given • Product requirements. • Project plan • How do I come up with a design?

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

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

  27. Dataflow Pipes and filters Batch sequential Data-centered Repository Blackboard Virtual Machine Interpreter Rule-based system Call and Return Main program and subroutine Object-oriented (& Data abstraction) Layered Independent Components Communicating processes Client/server Event systems Implicit invocation Explicit invocation Common Architectural Styles [FYI]

  28. Layered Architectural Style Our focus today: • Architectural style: Layered. • References • Larman, Chapter 13. • Fowler, EA. • Briefly, lets review Client-Server

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

  30. Enterprise Application Layers

  31. Enterprise Application Layers Presentation Domain Logic Data Source

  32. Layering – General Scheme Layers • Presentation / Application. • UI. • Generally “thin”. • (Term “application” can be misleading. It does not mean …) • Domain / Business Logic. • Core system functionality. • Technical Services.

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

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

  35. Layers: Functionality Presentation Domain Functionality / services Data Source

  36. Layers: Dependencies Presentation Domain Dependencies Data Source

  37. Layer Dependencies Example

  38. Not permitted in pure style Layering – Pure Style • Pure style: components are permitted to use services of other components in • same layer. • layer immediately below.

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

  40. Where to Run Your Layers EA software Technical Services

  41. EA Layers Refined Presentation Domain Logic Data Source

  42. Presentation Domain Technical services Presentation Application Domain (logic) Low-level domain logic Technical services Foundation. General Layering Scheme Refined

  43. Presentation Domain Technical services Presentation Application Business services Low-level business services Technical services Low-level technical services General Layering Scheme Refined

  44. Layering (Larman) • See Larman Sect 13.6

More Related