SOEN 343 Software Design

1
SOEN 343Software Design

• Section H Fall 2006
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/soen343h-f0
  6.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
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
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
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
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