SOEN 6011 Software Engineering Processes

SOEN 6011Software Engineering Processes

Section SS Fall 2007Dr Greg Butler

http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

Week 8• GRASP Principles• Design and use case realization• Design patterns

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.

The 9 GRASP Principles1. Creator2. Information Expert3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations

Information Expert

• “… expresses the common ‘intuition’ that objects do things related to the information they have.”

• Assign the responsibility for “knowing” [something] to the object (class) that has the information necessary to fulfill the responsibility.

Creator

• Assign to class B the responsibility to create an instance of class A if– B aggregates A objects.– B contains A objects.– B records instances of A objects.– B closely uses A objects.– B has the initializing data that will be passed

to A when it is created.

GRASP: Polymorphism Principle

Larman:• When related alternatives or behaviors

vary be type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies.

• (This principle was illustrated last week with the Animal hierarchy.)

PATTERN: Controller (Larman 17.13)

Problem: What object in the domain (or application coordination layer) receives requests for work from the UI layer?

System operations (see SSD): major input events to the system

The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operations message.

Note that UI objects delegate system operation request to a controller.

PATTERN: Controller (Larman 17.13)

Solution: Assign the responsibility to a class representing one of the following choices:

• A façade controller, which represents1. the overall system2. A root object3. A device that the software is running within, or4. A major subsystem

• A use case or session controller which represents a use case scenario in which the system operation occurs

Encapsulation• A programming/design language

mechanism.• A packaging / scoping mechanism for

names– Names can refer to data, types, …– Especially, a means of packaging data.

Data

Access points at interface

Information Hiding

• Design principle by which a module is assigned a “secret”.

• A module’s secret is usually– A design decision.

• What type of design decisions might we want to hide from the clients of a module?

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?

Coupling

• Measures the degree of dependency that exists between modules.

Coupling

A 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

Coupling

A.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

…

Pure FabricationProblem: Existing objects, ie domain

objects, are not appropriate to have the responsibilitySolution suggested by Information Expert not

appropriateMight violate high cohesion, low coupling

Solution: Fabricate (ie create, make up) a new object to hold the responsibility

GRASP: Pure Fabrication

• Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept—something made up, to support high cohesion, low coupling, and reuse.

• Can you think of an example from EA?

GRASP: Pure FabricationDesign of objects

– Representational decomposition– Behavorial decomposition

It’s OK for OO software to have objects representing behaviour, ie use case, process, function, strategy, TSBut do not overdo it

All GoF design patterns are Pure Fabrications

IndirectionProblem: How to assign responsibility to

avoid direct coupling? How to de-couple objects?

Solution: Assign responsibility to an intermediatory object to mediate between the two components

Example: Adapter patternIntermediatory to external tax calculators

Fig. 25.10

: Sale :TaxMasterAdapter

taxes = getTaxes( s )

t = getTotal

the adapter acts as a level of indirection to external systems

TCP socket communication

xxx...

«actor»:TaxMasterSystem. . .

Indirection“Most problems in computer science can be

solved by another level of indirection”

GRASP Protected Variations• Problem:

How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesireable impact on other elements?

• Solution:Identify points of predicted variation or instability; assign responsibility to create a stable interface around them.

Core PV Mechanisms

• Encapsulation.• Interfaces.• Polymorphism.• Indirection, …

(Note: we are speaking of mechanisms, not principles)

Patterns apply principles, e.g. …

Protected VariationMechanism

Low Coupling Mechanism

IndirectionMechanism

Adapter

Pure Fabrication

PolymorphismExample

GoF Design Patterns

GRASP Principles

High CohesionMechanism

GRASP: InterrelationshipsProtected Variation

Mechanism

Low Coupling Mechanism

IndirectionMechanism

Adapter

Pure Fabrication

PolymorphismExample

GoF Design Patterns

GRASP Principles

High CohesionMechanism

Week 8• GRASP Principles• Design and use case realization• Design patterns

Design Model

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Vision Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

Domain Model

**

SupplementarySpecification

Use-Case Model

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view)

interaction diagrams(a dynamic view)

UIpackage diagramsof the logical architecture(a static view) Domain

Tech Services

Design Model

• What are the users doing? (Jacobson)• What are the objects in the real world?

(Rumbaugh)• What objects are needed for each use case?

(Jacobson)• How do the objects collaborate with each

other? (Jacobson and Booch)• How will we implement real-time control?

(state models)• How are we really going to build this system?

(Booch)

Domain Model and Domain LayerLow representational gap

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.

This reduces the representational gap.

This is one of the big ideas in object technology.

inspires objects

and names in

SSDs, System Operations & Layers

Domain

UI

Swing

ProcessSaleFrame

...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System: Cashier

endSale()

description, total

makeNewSale()

the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer

Designing for Visibility

• Fact: To send a message to B, A must have visibility to B. It doesn’t happen by “magic.”

• Kinds of visibility:– Attribute– Parameter– Local– Global

Larman ch 19

Attribute Visibility

:Afoo()

: B

bar := getBar( )

{public void foo(){ .. bar = myB.getBar() ...}}

class A{ ... private B myB; ...}

Parameter Visibility

2: bar(spec)foo()

1: spec := getSpecification(id)

:A : B

: C

Local Visibility

: Afoo()

: B

spec := getSpecification( itemID )

{foo(){...// local visibility via assignment of returning objectProductSpecification spec = myB.getSpecification(id);...}}