1. SOEN 343 Software 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 1.Creator 2.Expert 3.Controller 4.Low Coupling 5.High Cohesion 6.Polymorphism 7.Pure Fabrication 8.Indirection 9.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 –T–To know? –T–To do? –T–To decide?

9. Kind of responsibility for: Navigator. –To know? –To do? –To decide?

10. Responsibilities – A Boat Metaphor Kind of responsibility for: Compass. –T–To know? –T–To do? –T–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. Common Architectural Styles [FYI] 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

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. 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 Data Source Functionality / services

36. Layers: Dependencies Presentation Domain Data Source Dependencies

37. Layer Dependencies Example

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

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. General Layering Scheme Refined Presentation Domain Technical services Presentation Application Domain (logic) Low-level domain logic Technical services Foundation.

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

44. Layering (Larman) See Larman Sect 13.6