Upload
linus
View
53
Download
0
Embed Size (px)
DESCRIPTION
SOEN 6011 Software Engineering Processes. Section SS Fall 2007 Dr 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). - PowerPoint PPT Presentation
Citation preview
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);...}}