Download presentation
Presentation is loading. Please wait.
Published byJessica Norton Modified over 8 years ago
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
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.