LoD

Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Smaller, More Evolvable Software: An Introduction to the Demeter Method: 

Smaller, More Evolvable Software: An Introduction to the Demeter Method Karl J. Lieberherr Northeastern University College of Computer Science lieber@ccs.neu.edu/www.ccs.neu.edu/home/lieber

The Law of Demeter (LoD) and how it should be used in CUBE: 

Copyright, 1996 © Dale Carnegie & Associates, Inc. The Law of Demeter (LoD) and how it should be used in CUBE

Overview: 

Overview Introduction to Demeter Law of Demeter Principle How it was used at Citibank, JPL etc. Recommendation Benefits, Review of Benefits Close

Thanks to Industrial Collaborators/Sponsors: 

Thanks to Industrial Collaborators/Sponsors IBM: Theory of contracts, Adaptive Programming Citibank, SAIC: Adaptive Programming Mettler Toledo: OO Evolution Xerox PARC: Aspect-Oriented Programming (Gregor Kiczales et al.) supported by DARPA (EDCS) and NSF

What is Demeter: 

What is Demeter A high-level interface to object-oriented programming and specification systems Demeter System/OPL = Demeter Method + Demeter Tools/OPL So far: OPL = {Java, C++, Perl, Borland Pascal, Flavors} Demeter Tools/OPL = Demeter/OPL

History: Many good things come from Zurich: 

History: Many good things come from Zurich Hades (HArdware DEScription language by Niklaus Wirth at ETH Zurich) Zeus (a brother of Hades, a silicon compilation language developed at Princeton University/MIT, implemented at GTE Labs; predecessor of VHDL) Demeter (a sister of Zeus, used to implement Zeus, started at GTE Labs) 1982 82-85 1985-

History: 

History Law of Demeter First traversal specifications Synchronization as an aspect Fast and general compilation algorithm APPCs (Adaptive Plug-and-Play Components) 1990 1993 1996/97 1987 1998

Law of Demeter: 

Law of Demeter What is it: Style Rule for building systems. Proposed by my research group: The Demeter Research Group in 1987, published in 1988. Covered in many major books on OO design and programming.

Law of Demeter Principle: 

Law of Demeter Principle Each unit should only use a limited set of other units: only units “closely” related to the current unit. “Each unit should only talk to its friends.” “Don’t talk to strangers.” Main Motivation: Control information overload. We can only keep a limited set of items in short-term memory.

Law of Demeter: 

Law of Demeter FRIENDS

“closely related”: 

“closely related”

Application to OO: 

Application to OO Unit = method closely related = methods of class of this/self and other argument classes methods of immediate part classes (classes that are return types of methods of class of this/self) In the following we talk about this application of the Law of Demeter Principle to OO: example follows in a few slides.

Citibank Quote: Law of Demeter: 

Citibank Quote: Law of Demeter The Law of Demeter forms one of the cornerstones of the design approach of the Global Finance Application Architecture (quote from: Global Finance Application Architecture: Business Elements Analysis, Oct. 1991, Citibank confidential document) Widely used in big projects, for example, at JPL for the Mars exploration software.

Jet Propulsion Laboratory(JPL) Quote: Law of Demeter: 

Jet Propulsion Laboratory(JPL) Quote: Law of Demeter The Law of Demeter … has taken a firm hold in many areas of JPL. Major systems which have used LoD extensively include … Mars Pathfinder Software (begun in 1993). We are going to use LoD as a foundational software engineering principle for the X2000 Europa orbiter mission.

What others say about the Law of Demeter: 

What others say about the Law of Demeter Two examples: Booch Rumbaugh

Booch and the Law of Demeter : 

Booch and the Law of Demeter Context Chapter: Classes and Objects, Section: On Building Quality Classes and Objects, Subsection: Choosing Relationships

Booch and the Law of Demeter : 

Booch and the Law of Demeter Quote: The basic effect of applying this Law is the creation of loosely coupled classes, whose implementation secrets are encapsulated. Such classes are fairly unencumbered, meaning that to understand the meaning of one class, you need not understand the details of many other classes.

Rumbaugh and the Law of Demeter : 

Rumbaugh and the Law of Demeter Context Chapter: Programming Style, Section: Extensibility

Rumbaugh and the Law of Demeter : 

Rumbaugh and the Law of Demeter Quote: Avoid traversing multiple links or methods. A method should have limited knowledge of an object model. A method must be able to traverse links to obtain its neighbors and must be able to call operations on them, but it should not traverse a second link from the neighbor to a third class.

Law of Demeter (alternative formulation) : 

Law of Demeter (alternative formulation) A method should have limited knowledge of an object model. Leads to another Demeter favorite: Use grammars to define both class structure and an application-specific language. See the Structure-Shy Object Pattern.

Agreement that LoD Good Idea: 

Agreement that LoD Good Idea How to follow LoD: good solutions exist but not widely known. Two approaches to following LoD: OO approach Adaptive approaches Traversal support APPC Demeter/Java

The Law of Demeter (cont.) Violation of the Law : 

The Law of Demeter (cont.) Violation of the Law class A {public: void m(); P p(); B b; }; class B {public: C c; }; class C {public: void foo(); }; class P {public: Q q(); }; class Q {public: void bar(); }; void A::m() { this.b.c.foo(); this.p().q().bar();}

Violations: Dataflow Diagram: 

Violations: Dataflow Diagram A B C 1:b 2:c P Q 3:p() 4:q() foo() bar() m

OO Following of LoD: 

OO Following of LoD A B C 1:b c P Q 3:p() q() foo() bar() m 2:foo2() 4:bar2() foo2 bar2

Adaptive Following of LoD : 

Adaptive Following of LoD void A::m() { (C) Traversal.long_get(this,”A->C”).foo(); (Q) Traversal.long_get(this,”A->Q”).bar();} void A::m() { this.b.c.foo(); this.p().q().bar();} // violation

Law of Demeter: 

Law of Demeter FRIENDS

What if your friends are far away?: 

What if your friends are far away? You pay them to travel to you or you send an agent to them to collect the information you need. Approximate Directions: You give them or your agent directions about what kind of information to collect but you don’t care about accidental details of the travel. Detailed Directions: You give them or your agent detailed travel directions.

Adaptive Following LoD: 

Adaptive Following LoD FRIENDS S A b C X a:From S to A b:From S to B c:From S via X to C a c

Traversal strategies create friends: 

Traversal strategies create friends Class Traversal is an intermediate class between classes that need to communicate Traversal.long_get(Object o, Strategy s)

Are not friends for accidental reasons: 

Are not friends for accidental reasons Other classes exist for other reasons Ideal class graph: all are friends, even “far” away classes.

Adaptive Following LoD: Key idea: 

Adaptive Following LoD: Key idea Introduce an ideal class graph Write current behavior in terms of ideal class graph Map ideal class graph flexibly into concrete class graph using traversal strategies

Slide32: 

Adaptive Following of LoD: Key Idea

Slide33: 

Z C1 C2 C3 C4 C5 Collab-1 Collab-2 Collab-3 Collab-4 OOAD Implementation Motivation

Slide34: 

“OO technology has not met its expectations when applied to real business applications partly due to the fact that there is no place where to put higher-level operations which affect several objects. … if built into the classes involved, it is impossible to get an overview of the control flow. It is like reading a road map through a soda straw'’ [Lauesen, IEEE Software, April ‘98] What is the Problem?

SE Group at UBI Lab: 

SE Group at UBI Lab Important work done there: Framework integration Role modeling

Slide36: 

C1 C2 C3 C4 C5 P1 P2 P3 C1 C3 C2 C4 APPL 1 APPL n Design Goal: Adaptiveness

Slide37: 

C1 C2 C3 C4 C5 P1 P2 P3 APPL 1 APPL 1 C2 C3 C4 C5 C1 Design Goal: Adaptiveness

Recommendation: 

Recommendation I recommend that the CUBE project use the Law of Demeter Principle in OO designs and programs and that the Law of Demeter be followed in an adaptive, collaboration-based style (Demeter style). Justfication: Works well for Citibank, JPL, Hewlett-Packard and many other companies.

Benefits of following Law of Demeter in Demeter Style: 

Benefits of following Law of Demeter in Demeter Style robustness to changes shorter programs design matches program more understandable code partially automated evolution keep all benefits of OO technology improved productivity Applicable to design and documentation of your current systems with immediate benefits.

Benefits Review: 

Benefits Review Robustness to changes: Elimination of violations of LoD in OO style leads to many tiny methods. Statistics from (Wilde, Matthews, Huitt, 1993): More than half of the member functions and methods have fewer than two C++ statements or four Smalltalk lines of code. Those tiny methods will be generated.

Benefits Review: 

Benefits Review Shorter programs : Tiny methods observed by Wilde et al. don’t have to be written and maintained. Programs get shorter.

UML Class Diagram: 

UML Class Diagram BusRoute BusStopList BusStop BusList Bus PersonList Person passengers buses busStops waiting 0..* 0..* 0..*

Traversal Strategy: 

Traversal Strategy BusRoute BusStopList BusStop BusList Bus PersonList Person passengers buses busStops waiting 0..* 0..* 0..* from BusRoute through BusStop to Person find all persons waiting at any bus stop on a bus route

Robustness of Strategy: 

Robustness of Strategy BusRoute BusStopList BusStop BusList Bus PersonList Person passengers buses busStops waiting 0..* 0..* 0..* from BusRoute through BusStop to Person VillageList Village villages 0..* find all persons waiting at any bus stop on a bus route

Benefits Review: 

Benefits Review Design matches program: Because each behavior is written for an ideal class graph behavior is well encapsulated and easier to understand because of noise elimination.

Benefits Review: 

Benefits Review Partially automated evolution: tiny traversal methods are automatically regenerated when structure changes. Programmer needs to test them.

Benefits Review: 

Benefits Review Keep all benefits of OO technology: all code is written in plain Java with a traversal package added. You can use all good ideas of OO technology.

Benefits Review: 

Benefits Review Improved productivity: Several testimonials. Example: Hewlett-Packard Printer Installation Software is written in Demeter Style using C++. Televised Demeter class with student in Vancouver, Canada, lead to prototype. Prototype was so successful that entire package was re-implemented.

Dangers if Law of Demeter Principle not followed adaptively: 

Dangers if Law of Demeter Principle not followed adaptively CUBE might get as hard to maintain as ABACUS because structural information will be duplicated many times. CUBE code will be tangled: hard to understand and to maintain.

Slide50: 

During implementation separate issues are mixed together During maintenance individual issues need to be factored out of the tangled code

Cross-cutting of components and aspects: 

Cross-cutting of components and aspects ordinary program structure-shy functionality structure synchronization better program Components Aspect 1 Aspect 2

Close: 

Close I recommend that the Law of Demeter Principle be used in a Demeter Style in the CUBE project. Benefits: More flexible and simpler programs that can more easily be adapted to new business needs.

More details: 

More details Traversal support Strategy graphs APPCs

Traversal Support for Java: class Traversal: 

Traversal Support for Java: class Traversal static Object long_get(Object o, Strategy s); static Iteration long_collect(Object o, Strategy s); static Object traverse(Object o, Strategy s, Visitor v[]);

Traversal Support for Java: 

Traversal Support for Java static X long_get(Object o, Strategy s); starting at object o, traverse down following s and return target object of s s must have a single target and s must specify unique path

Traversal Support for Java: 

Traversal Support for Java static Iteration long_collect(Object o, Strategy s); starting at object o traverse following s and return the collection of target objects of s.

Traversal Support for Java: 

Traversal Support for Java static Object traverse(Object o, Strategy s, Visitor v[]); starting at object o traverse down following s and execute the visitors in v. Return the object returned by first visitor.

Traversal Support: visitors: 

Traversal Support: visitors class SampleVisitor extends Visitor{ // local variables public SampleVisitor(); // initialize public void before(Visited host); public void after (Visited host); public void before_z(X source, Y dest); public void after_z (X source, Y dest); Object get_return_val(); public void start(); public void finish(); }

Traversal Support: visitors: 

Traversal Support: visitors abstract class Visitor { // GENERATED CODE EXAMPLE public Visitor() {super();} public void start() { } public void finish() { } public void before(Visited host); public void after (Visited host); public void before_p(Q source, H dest); public void after_p (Q source, H dest); … }

Refinement definition: 

Refinement definition A graph G is a refinement-instance of a graph S, if S is a connected subgraph of the pure transitive closure of G with respect to the node set of S.

Pure transitive closure: 

Pure transitive closure The pure transitive closure of G=(V,E) with respect to a subset W of V is the graph G*=(V,E*), where E*={(i,j): there is a W-pure path from vertex i to vertex j in G}. A W-pure path from i to j is a path where i and j are in W and none of the inner points of the path are in W.

Slide63: 

A A B B C C D D E E F F G1 G2 G1 refinement G2 refinement: connectivity of G2 is in pure form in G1 Allows extra connectivity.

The APPC Pattern: 

The APPC Pattern Benefiting from advances in component software technology using standard languages

Design patterns and programming language features: 

Design patterns and programming language features They are conceptually equivalent. Useful to explain language features using design pattern terminology. Danger of design patterns: workarounds needed to implement them can be tedious. Patterns are only used if benefit outweighs the cost.

Motivation: 

Motivation New component software ideas have a big acceptance threshold if they require non-standard language extensions. Use many of the good ideas with standard languages and suitable libraries/frameworks without language extension. Describe ideas using pattern terminology for easy reuse by designers/programmers.

The APPC Pattern: 

The APPC Pattern Benefiting from advances in component software technology using standard languages

Slide68: 

A C B View Map Host A C B X

Design patterns and programming language features: 

Design patterns and programming language features They are conceptually equivalent. Useful to explain language features using design pattern terminology. Danger of design patterns: workarounds needed to implement them can be tedious. Patterns are only used if benefit outweighs the cost.

Motivation: 

Motivation New component software ideas have a big acceptance threshold if they require non-standard language extensions. Use many of the good ideas with standard languages and suitable libraries/frameworks without language extension. Describe ideas using pattern terminology for easy reuse by designers/programmers.

APPC:Intent: 

APPC:Intent Filter out noise from implementations: Describe popular behavior in terms of an idealized class structure (ideal class graph = view), using traversal strategy graphs and visitors as appropriate. Map idealized class structure to concrete class structure using traversal strategy graphs as appropriate.

APPC:Motivation: 

APPC:Motivation Have an encapsulated unit for behavioral abstraction for new behavior covering multiple classes. Concrete class structures are overworked and to favor reusability each behavior should be expressed in terms of an idealized class structure that is mapped flexibly into a concrete class structure.

Motivation: 

Motivation ICG/CCG approach not only favors reusability, but it also makes programs simpler. Program towards an abstract structure. Distinguish between "IS-A" and "PLAYS-THE-ROLE-OF" relationships.

Motivation: 

Motivation Make visitor pattern more flexible. Reuse with different class structures or multiple times in same class structure.

APPC:Applicability: 

APPC:Applicability Use to implement "popular" behaviors. Whenever you have a class hierarchy (IS-A) and a behavior assignment to classes (PLAYS-THE-ROLE-OF) so that the IS-A structure cross-cuts the behavior assignment.

APPC:Applicability: 

APPC:Applicability Whenever the implementation of a behavior uses classes that are not central to the behavior.

APPC:Structure: 

APPC:Structure Strategy graph, expansion Ideal class graph, expansion Class graph An APPC has local data and functions and a constructor and an upstream and downstream interface.

APPC:Structure: 

APPC:Structure An APPC provides an implementation for a set of functions (the upstream interface) that modify classes that implement the downstream interface of the APPC.

APPC:Implementation: 

APPC:Implementation Code runs in CCG objects. Demeter/Java also uses this approach

APPC:Implementation: 

APPC:Implementation Mapping from ICG to CCG is best specified with Traversal Support for Java.

Law of APPCs: 

Law of APPCs The downstream interface must be a set of pure abstract functions. Clients of the APPC must not use the downstream interface.

Law of APPCs: 

Law of APPCs The implementation of the popular functions must be protected against changes by the client classes.

Law of APPCs: 

Law of APPCs The implementation of popular functions is allowed to use the DI/UI/local methods and methods of classes returned by the DI/UI/local methods and nothing more (Application of Law of Demeter Principle). Less restrictive but it is ok to have violations of standard LoD.

Simulating APPCs: 

Simulating APPCs Translate UI into Java interface. Assigning to class structure: use delegation to ego objects.

authorStream Live Help