Controlling the Complexity of Software Designs

1
Controlling the Complexity of Software Designs

• Karl Lieberherr
• College of Computer and Information Science
• Northeastern University

2
My first conference experience

• 3. ICALP 1976 Edinburgh, U.K.
• S. Michaelson, Robin Milner (Eds.) Third
  International Colloquium on Automata, Languages
  and Programming, University of Edinburgh, July
  20-23, 1976. Edinburgh University Press.

3
Thesis
Lavalife.com Always talk to strangers

• The Law of Demeter for Concerns (LoDC) helps you
  to better apply, explain and understand
  Aspect-Oriented Software Development (AOSD)
• LoDC Talk only to your (stable) friends who
  contribute to your concerns.
• AOSD Modularizing crosscutting concerns.

4
Supporting Claims

• Current AOSD tools (AspectJ, Demeter, etc.)
  provide support for following the LoDC.
• The LoDC explains the idea behind aspects.
• The LoDC leads to structure-shyness which leads
  to better AOSD.

5
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

6
Meta thesis

• I have a simple way to explain something complex
  that is important to you.
• Grounded on familiar LoD.
• LoD is good for object-oriented software
  development, LoDC is good for aspect-oriented
  software development.

7
What is AOSD?

• Modularize concerns whose ad hoc implementation
  would be scattered across many classes or
  methods.
• Modularize crosscutting concerns.

8
What is AOP

• An approach to programming that deals with
  modularizing concerns that cut across the
  dominant decomposition.
• LoDC is an approach to pro

9
Modularization of crosscutting concerns
Instead of writing this
Crista Lopes 1995
10
The Intuition behind Aspects
Mira Mezini (1998)
aspects
classes
expected
provided
adapters
11
Scattering count number of classes to which
color goes
ordinary program
aspect-oriented prog.
structure-shy functionality
Concern 1
C1
object structure
C2
Concern 2
synchronization
C3
Concern 3
12
AOSD as an Emerging Technology

• First I want to position AOSD as an important
  emerging technology.
• Statement from IBM at AOSD 2004.
• A case study of AspectJ usage from a paper by
  Colyer and Clement at AOSD 2004. Also used by
  LoDC explanation.

13
Daniel Sabbahs (IBM VP for Software) A Part of
Conclusions at AOSD 2004

• AOSDs time has come.
• The Software Industry needs it, and IBM is using
  it now.
• IBM is taking AOSD very seriously
• From a technical and business perspective
• AOSD has development impact today across all
  major IBM brands
• Tivoli, WebSphere, DB2, Lotus, Rational
• Takeup in IBM is growing no longer a push
  there is now a lot of pull from across IBMs
  development teams

14
How is AOSD technology currently used?

• Large-scale AOSD for Middleware
• Adrian Colyer and Andrew Clement
• IBM UK, in Proceedings AOSD 2004.
• From the Abstract
• We also wanted to know whether aspect-oriented
  techniques could scale to commercial project
  sizes with tens of thousands of classes, many
  millions of lines of code, hundreds of
  developers, and sophisticated build systems.

15
From Large Scale AOSD for Middleware

• 2. HOMOGENEOUS CROSSCUTTING
• CONCERNS
• In the middleware product-line used as the basis
  for this part of the study, there are multiple
  standards (policies) that are applied across
  product-line members.
• Note we focus on the tracing and logging policy.

16
From Large Scale AOSD for Middleware

• The crosscutting concerns captured by these
  policies are homogeneous in nature whilst there
  is broad scattering, the scattered logic is very
  similar in each location.

17
From Large Scale AOSD for Middleware

• The tracing and logging requirements for the
  product-line are captured in an extensive policy
  document. We were able to capture the policy in
  an abstract aspect that defined both when and how
  tracing was to be performed.
• Each component in the product-line then only
  needed to supply a concrete sub-aspect specifying
  where to trace.
• Note They applied AOSD to many other concerns!

18
Logging in AspectJ
When WhatToDo
May affect Hundreds of Classes
aspect SimpleLogging LogFile l pointcut
traced() call(void .update())
call(void .repaint()) before()traced()
l.log(Entering thisJoinPoint)
19
Manual alternative

• Mistakes that happened
• Some extra methods may be logged.
• Some methods are forgotten to be logged.
• Some logging methods may not be properly guarded.
• From Colyer/Clement The aspect-based solution
  gave a more accurate and more complete
  implementation of the tracing policy All of
  these mistakes are the natural consequence of
  asking humans to perform mundane and repetitive
  work.

20
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

21
The LoD and LoDC

• LoD Talk only to your friends.
• Control information overload
• How to organize inside a set of concerns.
• LoDC Talk only to your friends who contribute to
  your concerns.
• Better control of information overload and
  control tangling.
• Separate ouutside concerns.
• LoDC implies LoD.

22
LoDC and Contracting

• Contracting buyer, contracting provider
• Crosscutting interaction pattern
• Contracting benefits
• More agile
• Better service, Amortization

Talk only to your friends that contribute to your
concerns
23
Law of Demeter (LoD)
Talk only to your friends
you
24
OO interpretation of LoD

• Talk only to your friends
• Class form you method of class, talk use,
  friends preferred supplier classes
• Object form you method of object, talk send
  message, friends preferred supplier objects

25
Preferred supplier objects of a method

• the immediate parts of this (computed or stored)
• the methods argument objects (which includes
  this)
• the objects that are created directly in the
  method

26
LoD Formulation (object form)

• Inside a method M we must only call methods of
  preferred supplier objects (for all executions of
  M).

Expresses the spirit of the basic LoD and serves
as a conceptual guideline for you to approximate.
27
Explaining LoDC

• Base application deals with set of concerns Cs.
• A new concern D needs to be dealt with that
  requires additional method calls.
• Those method calls, although they may be to a
  friend, do not contribute to Cs.
• Therefore, the calls required by D need to be
  factored out.

LoDC Talk only to your friends who contribute
to your concerns
28
LoDC Talk only to your friends who contribute to
your concerns.

• When your concerns change the set of contributing
  friends changes.
• You talk to friends that dont contribute to your
  concerns through a complex request.
• Such a complex request (e.g., SimpleLogging) may
  modularize many communications that would
  otherwise be scattered across many classes and
  methods.

29
Law of Demeterfor Concerns (LoDC)
you
30
Law of Demeterfor Concerns (LoDC)
contributing friends
FRIENDS
lLogFile
you
coordinates
Complex request
31
Use Logging example to explain LoDC

• Base application deals with a set of concerns Cs
  different from Logging.
• The logging object, although it may be a friend,
  does not contribute to Cs.
• Therefore, the calls to the logging object need
  to be factored out.

LoDC Talk only to your friends who contribute
to your concerns
32
AspectJ
When WhatToDo

• aspect SimpleLogging
• LogFile l
• pointcut traced()
• call(void .update()
• call(void .repaint()
• before()traced()
• l.log(Entering
• thisJoinPoint)

• How does AspectJ support the LoDC?
• Inserting calls l.log() manually would violate
  LoDC because logging is an intrusive new concern
  that is not part of the current concerns.

33
AspectJ provides general purpose support for LoDC.

• You object
• Talk Method calls
• Friends contributing to concerns method calls
  (BaseApp)
• Concerns
• Old BaseApp
• New WhenAndWhatToDo
• Coordinates execution points in BaseApp
• Examples
• void before () execution_points_in_BaseApp()
• Weave ajc BaseApp.java WhenAndWhatToDo.java

34
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

35
Demeter Motivation

• V. Basili 1996 classes with less coupling are
  less error prone.
• Demeter reduces the coupling in two stages
• Following the Law of Demeter using standard
  object-oriented techniques eliminates bad
  coupling.
• Traversal strategies reduce the coupling further
  by coupling only with (distant) stable friends.

36
Basilis work

• Basili et al., A Validation of Object-Oriented
  Design Metrics As Quality Indicators,IEEE TSE
  Vol. 22, No. 10, Oct. 96
• Predictors of fault-prone classes?
• 8 medium sized information management systems

37
Metric

• CBO metric coupling between object classes a
  class is coupled to another one if it uses its
  member functions and/or instance variables. CBO
  number of classes to which a given class is
  coupled.

38
Hypothesis

• H-CBO Highly coupled classes are more
  fault-prone than weakly coupled classes.

39
Result

• Indeed, highly coupled classes are more
  fault-prone than weakly coupled classes.
• Corollary Classes that follow the LoD are less
  coupled and are therefore less fault-prone.

40
Booch and the Law of Demeter (LoD)

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

41
Rumbaugh and the Law of Demeter (LoD)

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

42
Agreement that LoD Good Idea

• How to follow LoD good solutions exist but not
  widely known. Two approaches to following LoD
• OO approach
• Structure-shy approach
• Traversal support

43
Motivation for traversal strategies

• Talk only to your stable friends who contribute
  to your concerns.
• A friend is stable if its definition is unlikely
  to change.
• A stable friend may not be an ordinary preferred
  supplier. It may be a distant stable friend.

44
Stable Preferred supplier objects of a method

• the stable parts of this (computed or stored)
• Parts reachable by a short traversal
  specification derived from the requirements
• the methods argument objects (which includes
  this)
• the objects that are created directly in the
  method

45
Structure-shy Following LoD
C
A
FRIENDS
a
S
X
c
b
a From S to A b From S to B c From S via
X to C
B
46
Stable Friends
Requirement count all persons waiting at any
bus stop on a bus route
strategy from BusRoute via BusStop to Person
BusRoute
BusStopList
villages
buses
VillageList
busStops
0..
0..
BusStop
BusList
Village
waiting
0..
passengers
Bus
PersonList
Person
0..
47
Following the LoD (example by David Bock).

• Instead of using (in class PaperBoy)
• customer.wallet.money
• customer.apartment.kitchen.kitchenCabinet.money
• customer.apartment.bedroom.mattress.money
• Widen the interface of Customer but decrease
  coupling. int Customer.getPayment(..)
• Stable friend is Money in From Customer to
  Money.

48
Equation System
usedVariables from EquationSystem
through -gt ,rhs, to Variable
EquationSystem
equations
Equation_List
Ident

lhs
Equation
Variable
Numerical
rhs
Expression_List
Simple
args
Expression

LoD
op
Add
Compound
49
From AspectJ (1997) back to Demeter (1992)
Demeter (e.g., DJ)
AspectJ

• When (pointcut)
• set of execution points of any method,
• rich set of primitive pointcuts this, target,
  call, set operations
• when to enhance
• WhatToDo (advice)
• how to enhance

• When (visitor signature)
• set of execution points of traversal methods
• specialized for traversals (nodes, edges)
• when to enhance
• WhatToDo (visitor body)
• how to enhance

50
AspectJ JavaDJ
When WhatToDo

• aspect SimpleLogging
• LogFile l
• pointcut traced()
• call(void .update())
• call(void .repaint())
• before()traced()
• l.log(Entering
• thisJoinPoint)

• class Source
• HashSet collect(ClassGraph cg)
• return (HashSet)
• cg.traverse(this,
• from Source to Target,
• new Visitor()
• public void before
• (Target h)
• public void start() )

51
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

52
JavaDJ
When WhatToDo

• class Source
• HashSet collect(ClassGraph cg)
• return (HashSet)
• cg.traverse(this,
• from Source to Target,
• new Visitor()
• public void before
• (Target h)
• public void start() )

• How does DJ support the LoDC?
• Inserting calls manually at Source and Target
  would violate the LoDC because our current
  concern is only WhereToGo.

53
JavaDJ
When WhatToDo

• class Source
• HashSet collect(ClassGraph cg)
• return (HashSet)
• cg.traverse(this,
• from Source to Target,
• new Visitor()
• public void before
• (Target h)
• public void start() )

• How does DJ support the LoDC?
• Inserting traversal calls manually into all
  classes between Source and Target would violate
  the LoDC because the collect functionality is a
  new concern.

54
How does DJ support the LoDC?

• It provides special purpose support for the
  WhereToGo concern and for the WhenAndWhatToDo
  concern relative to the WhereToGo concern.

55
Demeter.

• You object
• Talk method calls
• Friends c.c. traversal method calls (WhereToGo)
• Concerns
• Old WhereToGo
• New WhenAndWhatToDo
• Coordinates objects and object parts
• Examples
• void before (Class_WhereToGo host)
• ClassGraph.traverse (obj, WhereToGo,
• WhenAndWhatToDo)

56
Subject-oriented Programming.

• You object
• Talk refer to members
• Friends c.c. members of a concern
• Concerns
• New behavior cutting across several classes
• Coordinates objects and object members

57
Overview
Leads to or helps explain/implement
Controlling Information Overload
Separation of concerns
Structure Shyness
Is-a
AspectJ
Automata Theory
Composition Filters
LoDC
LoD
Traversal Strategies
Visitors
Aspects
Demeter
Adaptation Dilemma
Subjects
Complex Requests
LoDC Talk only to your friends that contribute
to your concerns
58
More on strategies

• Three layers of graphs
• Selector language strategy graphs
• Meta information class graphs
• Instances object graphs
• View all three graphs as automata
• Product of non-deterministic automata

59
Product of non-deterministic automata

• Product of strategy graph and class graph
  produces traversal graph encapsulating a set of
  paths in class graph
• Product of traversal graph and object graph
  produces subgraph of object graph where traversal
  visits

60
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

61
An Empirical Study of the Demeter System

• Pengcheng Wu and Mitchell Wand
• Northeastern University
• AOSD 04, SPLAT Workshop

62
Motivation

• Collect evidence to support the claim The
  Demeter system improves the
• comprehensibility of software systems.
• structure-shyness of software systems.

63
System overview

• Problem addressed manual implementation of a
  traversal on a complex object structure is
  tedious and error-prone. E.g., AST traversal.
• Solution have a high-level description of
  traversals, then generate the code!
• The largest software system using Demeters
  traversal strategies the DemeterJ Compiler. It
  has 413 classes, 80 traversals on ASTs.

64
How complex are those traversals?
65
How complex are those traversals? (cont.)
66
Traversal strategies improve comprehensibility

• How to measure the improvement?
• Abstractness of a traversal strategy
• Length(MethodCallPaths)/Length(Strategy)
• The larger the ratio is, the more abstract the
  strategy is, then the more details are left out
  and the better comprehensibility we achieve.

67
The abstractness metric
68
Result

• Traversals on complex object structures tend to
  be complex too.
• High level description of traversals helps
  improve the comprehensibility of the traversal
  concerns.
• The improvements are nontrivial.
• At least in this application following the Law
  of Demeter using traversal strategies leads to
  structure-shyness.

69
Implementing the LoD in AspectJ
Supplier
Aspect Diagram
ImmediatePartBin
TargetBinStack
ArgumentBin
Checker
LocallyConstructedBin
uses pointcuts
ReturnValueBin
Requirements
Statistics
GlobalPreferredBin
Good Separation of Concerns in Law of Demeter
Checker
LoD LoDC aspects LoD checking with aspects
70
Outline

• Motivation, Thesis
• What is AOSD?
• AOSD as an emerging technology (reports from IBM)
  
• The LoD and LoDC
• AspectJ supports LoDC
• Introduction to Demeter
• Demeter supports LoDC
• From LoD to structure-shyness and better AOSD
• Information hiding and LoDC
• Open Problems
• Conclusions

71
How is information hiding different from
structure-shyness

• CACM May 1972 A technique for the specification
  of software modules Hide implementation data
  structures.
• Later CACM Dec. 1972 Secret design decision
  which a module hides from all the others.
• Shyness hide a concern (e.g., structure)

information hiding implementation detail hiding
72
Strengthening Information Hiding
may change in limits
may change
Implementation
Interface
Client
Structure-Shy Programming
Representation Independence
Information Hiding
73
Problem with Information Hiding

• Structure-Shy Programming builds on the
  observation that traditional information hiding
  is not hiding enough. Traditional information
  hiding isolates the implementation from the
  interface, but does not decouple the interface
  from its clients.

74
Decoupling of Interface

• We summarize the commonalities and differences
  between information hiding and structure-shy
  programming into two principles.
• Representation-Independence Principle the
  representation of objects can be changed without
  affecting clients.
• Shy-Programming Principle the interface of
  objects can be changed within certain limits
  without affecting clients.
• It is important to notice that the
  Shy-Programming Principle builds on top of the
  Representation-Independence Principle.

75
Structure-shyness in AspectJ

• Many AspectJ programs are structure-shy (designed
  for a family of Java programs)
• Context Java program or its execution tree
  (lexical joinpoints or dynamic join points)
• Features enabling structure-shyness
• , .. (wildcards)
• cflow, (graph transitivity)
• this(s), target(s), args(a), call (),
  (inheritance as wild card)
• pc(Object s, Object t)
• this(s) target(t) call( f )

76
Adaptation Dilemma

• When a parameterized program abstraction P(Q) is
  given with a broad definition of the domain of
  the allowed actual parameters, we need to retest
  and possibly change the abstraction P when we
  modify the actual parameter, i.e., we move from
  P(Q1) to P(Q2).
• Application of the rule Reusing a piece of
  software in a new context requires retesting.

77
Examples for Adaptation Dilemma

• AspectJ After change to the base program an
  aspect suddenly misbehaves (e.g., our Law of
  Demeter checker written in AspectJ).
• Demeter After a change to the class graph, a
  traversal strategy suddenly misbehaves (e.g.,
  adding a new edge introduces many more undesired
  paths).

78
Crosscutting and LoDC

• AOSD is about modularizing crosscutting concerns
  whose ad-hoc implementation would be scattered
  across many classes or methods.
• LoDC does not talk directly about crosscutting
  but experience shows that the complex request
  influences often many classes and methods.

79
A different application of LoDC Language
extension and aspects

• The LoDC (and AO) applies to defining languages
  in general.
• Language L(G) defined by grammar G covering
  concern C.
• New enhancing concern C, need new grammar G.
• We would like to enhance s in L(G) to turn it
  into s in L(G) by using an aspect sentence d.
• s s d (to cover concerns C C)

80
Language extension and aspects

• Need a coordinate system in G to point to the
  places where G extends G.
• Coordinate system is used to place the
  enhancements into the sentences.
• How can we derive the aspect language from the
  pair G,G?

81
Language extension and aspects

• Issues
• Interaction between multiple extensions.
• What kind of context information is available at
  coordinates?
• Deriving aspect language from grammar difference
  between G and G. Is aspect language complete?

82
AOSD techniques are popular

• The high-level program abstractions used in AOSD
  are different than traditional'' abstractions
  because of the analogous adaptation they cause.
• AOSD practitioners using tools such as AspectJ,
  AspectWerkz, Spring AOP Framework, JBoss-AOP,
  JAC, DemeterJ etc. (see http//www.aosd.net) are
  happy to work with AOP abstractions.

83
AOSD techniques are popular

• One reason is that AOSD abstractions produce a
  lot of code that would be
• tedious and error-prone to write by hand and
• the code would be scattered over many methods and
  not pluggable.
• Instead of labeling AOSD abstractions as wrong or
  breaking modularity, it is much better to find
  good ways of working with them.

84
Open issues

• How to follow LoDC There are many open questions
• Suitable high-level coordinate systems
• Study limited forms of aspects. E.g., the DJ
  tools DemeterJ, DJ, DAJ.
• Interaction between aspects. Concern-shyness.
• Reasoning about aspects, e.g., what is the
  resource consumption of an aspect.
• Managing the Adaptation Dilemma.

85
Conclusions

• AOSD is an important emerging technology to
  control the complexity of software designs.
• The LoDC is a suitable style rule helpful to
  explain better apply, explain and understand
  AOSD.
• Properly following the LoDC (finding good
  decompositions into separable aspects that are
  loosely coupled) is still an issue with many
  questions attached. But the AOSD community will
  ultimately succeed in addressing those questions.
  

Thank you!
86
Outline

• Industry trend toward on demand Business
• IBMs Customers and their Changing Requirements
• IBMs Own Transformation
• Aspect Oriented Software Development
• Driving AOSD Technology within IBM
• Future Activities around AOSD
• Challenges
• Conclusion Questions

87
Deepening Integration of IT with
BusinessEmerging On Demand Computing Model
Traditional
The Internet
On Demand
Structured Calculations Data Processing Transactio
ns
Open Standards Connectivity Flexibility Simplicity
Modular Components easily defined and
manipulated Dynamic definition and operations
88
On
An (inter)enterprise whose business processes
integrated end-to-end across the company and
with key partners, suppliers and customerscan
respond with speed to any customer demand,
market opportunity or external threat.
89
The Need to Become More Horizontal
Business Processes
Partner Relationship Mgmt.
Category Management/ Merchandising
Product Lifecycle Management
SCM / Retail Operations
Procurement
Bridging the gap between business transformation
and IT.
IT Sophistication
90
IBM Roadmap
2003 2004 2005 2006
New Services Offerings

NOW
Reengineering Software Engineering
Reengineering Software
Enhancing the quality of software
Driving Organizational Acceptance/Adoption
Core Technology
91
Core Technology Investment

• Investing in core technologies
• AspectJ
• AO technology for the Java language
• AspectJ 1.1 recently awarded a Software
  Development Magazine Jolt Productivity Award
• AJDT
• Development environment for AspectJ
• CME
• Cross-artefact, cross life-cycle capability
• To provide the underpinning capability for
  internal, and external exploitation
• All are Eclipse based, Open Source projects

92
Delivering higher quality code through capturing
and enforcing architectural standards and best
practices API Scanner Application
Enhancing the quality and serviceability of
software
Deployer /
Application
Deployed
System Administrator
Developer
Application
Scanner Report
Unit (EAR)
Contravention Data
210
deprecation
warnings
-in human-readable form
5
obsoletion
errors
-for development tools
3
contraventions
API Contravention
Scanner
legend
Aspects
Scanner rules
Package/Class Map
WebSphere
database
Rules Filters
Platform-
(Deprecated, Deleted,
Messages
supplied
Illegal Interfaces)
Conversion scripts
Product-
supplied
Product Deployment Tools (version N)
93
Componentization Investigation Refactoring the
WebSphere Container
Reengineering software IBMs and IBMs customers

• Concern Modelling
• Visualization
• Concern-based queries
• At one point, Query capability reported gt 1000
  links to resolve
• Refactoring using OO and AspectJ

94
Reengineering software IBMs and IBMs customers
Componentization Investigation Refactoring the
WebSphere Container

• Scale of the exercise
• 15000 java source files. Around 1500 packages.
  90 components, largest
  components around 250kloc.
• Substantial entanglement complexity
• The tools stood up to the test
• compiled gt 20,000 files with AspectJ
• build time ok
• queries ran fast
• Was an early use of CME query capabilities
• Success!!

95
Componentization Realizing the Shared
Capabilities of IBMs Software Portfolio
Reengineering software IBMs and IBMs customers
96
Re-engineering Software Engineering
Solution Level Aspects
Consider this Insurance Broker application
dependent on Insurance company Web Services. Many
distinct artefacts, e.g., Web Service can be
called from BPEL and EJB.

• Examples of Solution Level Monitoring and
  Measurement Aspects
• Generate a business event every time a customer
  requests a price quote over 500
• Measure how long it takes to update customer
  details in the database

CME will provide the underpinning cross-artefact
capability
97
IBM Roadmap
2003 2004 2005 2006
New Services Offerings

FUTURE
Reengineering Software Engineering
Reengineering Software
Enhancing the quality of software
Driving Organizational Acceptance/Adoption
Core Technology
98
Future

• Continuous improvement in core technologies
• Focus on extending cross artefact capability
• Through CME
• Drive use up the software stack
• With Solution Aspects with integration into
  Rational Tools
• Broader technology exploitation across and within
  the products
• For critical Qualities of Service
• To enable componentization needed for customer
  (and IBM) flexibility

99
Future

• Bringing the next level of AO value and
  capability to customers requires
• first class support in design and development
  tools
• E.g., Rational Development tools
• first class support in the core runtime servers
• E.g., WebSphere Application Server, Portal
  Server, BI Server, etc.
• first class representation in the programming
  model.
• E.g., Rational XDE Developer
• And bringing value to the level of Business
  Modelling

100
Challenges for the AOSD Research Community

• Scalability through complexity reduction
• Commercial software is large and complex
• Experience with Container refactoring, and with
  legacy re-engineering provide some experience and
  challenges in tool scaling
• But future (and legacy) applications may well be
  even larger
• Cross Artefact Querying and Composition
• Essential for robust, full-solution integration
• CME is an important start
• Organizational Flexibility
• Organizational aspects (e.g., Problem
  Determination, or Serviceability, organizations)
  are assisted with AOSD technology
• It is a transformational technology
• What is the right organizational structure?
• Who owns cross-cutting code?

101
Challenges for the AOSD Research Community

• Standards Do we need them?
• For commercial adoption at the end-user level
  Yes.
• Standards will be important to allow customers,
  ISVs to have flexibility and to preserve
  investment
• Complexity versus Simplification.
• Does AOSD really help reduce complexity?
• Need work toward gaining understanding of this
  question
• But clearly WE think it DOES
• AOSD introduces its own learning curve
• Consequences for industrial adoption?
• Who will be the practitioners?

102
Our Conclusions

• AOSDs time has come.
• The Software Industry needs it, and IBM is using
  it now.
• Our customers stand to benefit significantly.
• IBM is taking AOSD very seriously
• From a technical and business perspective
• AOSD has development impact today across all
  major IBM brands
• Tivoli, WebSphere, DB2, Lotus, Rational
• Takeup in IBM is growing no longer a push
  there is now a lot of pull from across IBMs
  development teams
• Future impact will become more visible in IBMs
  runtimes and in development tools

103
Trademarks

• AspectJ is a trademark of Palo Alto Research
  Center Incorporated
• Java and all Java-based trademarks are trademarks
  of Sun Microsystems, Inc. in the United States,
  other countries, or both.
• Microsoft, Windows, Windows NT, BizTalk, and the
  Windows logo are trademarks of Microsoft
  Corporation in the United States, other
  countries, or both.
• Gartner is a registered trademark of Gartner,
  inc., or its Affiliates
• Solaris is a trademark of Sun Microsystems, Inc.
  in the United States, other countries, or both.
• UNIX is a registered trademark of The Open Group
  in the United States and other countries.
• Intel, Pentium, Pentium Pro, Pentium II, Pentium
  III are trademarks or registered trademarks of
  Intel Corporation or its subsidiaries in the US
  and other countries.
• HP-UX is a registered trademark of Hewlett
  Packard Company.
• Linux is a registered trademark of William R.
  Della Croce, Jr. (last listed previous owner was
  Linus Torvalds)
• "SAP is the trademark of SAP AG in Germany and in
  several other countries.

104
Thank You!

• Questions?

105

• old

106
Demeter 1.

• You object
• Talk Refer to parts
• Friends stable parts
• Concern
• New WhereToGo
• Coordinates object parts
• Examples
• From BusRoute via BusStop to Person

Talk only to your stable friends that contribute
to your concerns
107
Law of Demeterfor Concerns (LODC)
contributing friends
FRIENDS
you
coordinates
108
Law of Demeterfor Concerns (LODC)
contributing friends
FRIENDS
new
you
coordinates
109
Protect Against Changes.

• Protection against changes in data representation
  and interfaces. Traditional technique
  information-hiding is good to protect against
  changes in data representation. Does not help
  with changes to interfaces.
• Need more than information hiding to protect
  against interface changes restriction through
  shy programming, called Adaptive Programming (AP).

Implementation
Interface
Client
Shy Programming
Representation Independence
Information Hiding
110
Why object form is needed
A B D E. B D. D E. E .
class A void f() this.get_b().get_d().ge
t_e()
111
Object Form
A B D E. B D. D E. E .
a1A
b1B
d1D
e1E
d2D
e2E
class A void f() this.get_b().get_d().ge
t_e()
e3E
not a preferred supplier object
112
Object Form
A B D E. B D. D E. E .
a1A
b1B
d2D
e2E
class A void f() this.get_b().get_d().ge
t_e()
e3E
is a preferred supplier object (through aliasing)
113

• Commonality between summing and logging

114
Overview
Leads to or helps explain/implement
Controlling Information Overload
Separation of concerns
Structure Shyness
Is-a
AspectJ
Automata Theory
LoDC
LoD
Traversal Strategies
Visitors
Aspects
Demeter
Adaptation Dilemma
Subjects
Complex Requests
LoDC Talk only to your friends that contribute
to your concerns
115
OO interpretation of LoD

• Talk only to your friends
• Class form you method of class, talk use,
  friends preferred supplier classes
• Object form you method of object, talk send
  message, friends preferred supplier objects

116
LoD Formulation (object form)

• Inside a method M we must only call methods of
  preferred supplier objects (for all executions of
  M).

Expresses the spirit of the basic LoD and serves
as a conceptual guideline for you to approximate.
117
Preferred supplier objects of a method

• the immediate parts of this (computed or stored)
• the methods argument objects (which includes
  this)
• the objects that are created directly in the
  method

118
Law of Demeter (LoD)
Talk only to your friends
you
FRIENDS
119

• Aspectual algorithms
• Self application
• Develop design tools for aspectual algorithms
• Apply design tools to our design tool algorithms
  themselves

120
Overview
Leads to or helps explain/implement
Controlling Information Overload
Separation of concerns
Structure Shyness
Is-a
AspectJ
Automata Theory
Composition Filters
LoDC
LoD
Traversal Strategies
Visitors
Aspects
Demeter
Adaptation Dilemma
Subjects
Complex Requests
LoDC Talk only to your friends that contribute
to your concerns