Controlling the Complexity of Software Designs Karl Lieberherr
Controlling the Complexity of Software Designs § Karl Lieberherr § College of Computer and Information Science § Northeastern University
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. 2
Thesis Lavalife. com Always talk to strangers § The Law of Demeter for Concerns (Lo. DC) helps you to better apply, explain and understand Aspect-Oriented Software Development (AOSD) § Lo. DC: Talk only to your (stable) friends who contribute to your concerns. 4 AOSD: Modularizing crosscutting concerns. 3
Supporting Claims § Current AOSD tools (Aspect. J, Demeter, etc. ) provide support for following the Lo. DC. § The Lo. DC explains the idea behind aspects. § The Lo. DC leads to structure-shyness which leads to better AOSD. 4
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 5
Meta thesis § I have a simple way to explain something complex that is important to you. § Grounded on familiar Lo. D. § Lo. D is good for object-oriented software development, Lo. DC is good for aspectoriented software development. 6
What is AOSD? § Modularize concerns whose ad hoc implementation would be scattered across many classes or methods. § Modularize crosscutting concerns. 7
What is AOP § An approach to programming that deals with modularizing concerns that cut across the dominant decomposition. § Lo. DC is an approach to pro 8
interface Shape. I extends Remote { double get_x() throws Remote. Exception ; void set_x(int x) throws Remote. Exception ; double get_y() throws Remote. Exception ; void set_y(int y) throws Remote. Exception ; double get_width() throws Remote. Exception ; void set_width(int w) throws Remote. Exception ; double get_height() throws Remote. Exception ; void set_height(int h) throws Remote. Exception ; void adjust. Location() throws Remote. Exception ; void adjust. Dimensions() throws Remote. Exception ; } public class Shape implements Shape. I { protected Adjustable. Location loc; protected Adjustable. Dimension dim; public Shape() { loc = new Adjustable. Location(0, 0); dim = new Adjustable. Dimension(0, 0); } double get_x() throws Remote. Exception { return loc. x(); } void set_x(int x) throws Remote. Exception { loc. set_x(); } double get_y() throws Remote. Exception { return loc. y(); } void set_y(int y) throws Remote. Exception { loc. set_y(); } double get_width() throws Remote. Exception { return dim. width(); } void set_width(int w) throws Remote. Exception { dim. set_w(); } double get_height() throws Remote. Exception { return dim. height(); } void set_height(int h) throws Remote. Exception { dim. set_h(); } void adjust. Location() throws Remote. Exception { loc. adjust(); } void adjust. Dimensions() throws Remote. Exception { dim. adjust(); } } class Adjustable. Location { protected double x_, y_; public Adjustable. Location(double x, double y) { x_ = x; y_ = y; } synchronized double get_x() { return x_; } synchronized void set_x(int x) {x_ = x; } synchronized double get_y() { return y_; } synchronized void set_y(int y) {y_ = y; } synchronized void adjust() { x_ = long. Calculation 1(); y_ = long. Calculation 2(); } } class Adjustable. Dimension { protected double width_=0. 0, height_=0. 0; public Adjustable. Dimension(double h, double w) { height_ = h; width_ = w; } synchronized double get_width() { return width_; } synchronized void set_w(int w) {width_ = w; } synchronized double get_height() { return height_; } synchronized void set_h(int h) {height_ = h; } synchronized void adjust() { width_ = long. Calculation 3(); height_ = long. Calculation 4(); } } Modularization of crosscutting concerns public class Shape { protected double x_= 0. 0, y_= 0. 0; protected double width_=0. 0, height_=0. 0; Write this Instead of writing this Crista Lopes 1995 double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjust. Location() { x_ = long. Calculation 1(); y_ = long. Calculation 2(); } void adjust. Dimensions() { width_ = long. Calculation 3(); height_ = long. Calculation 4(); } } coordinator Shape { selfex adjust. Location, adjust. Dimensions; mutex {adjust. Location, get_x, set_x, get_y, set_y}; mutex {adjust. Dimensions, get_width, get_height, set_width, set_height}; } portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjust. Location() {}; void adjust. Dimensions() {}; } 9
The Intuition behind Aspects aspects expected provided Mira Mezini (1998) classes adapters 10
Scattering: count number of classes to which color goes ordinary program C 1 C 2 aspect-oriented prog. structure-shy functionality Concern 1 object structure Concern 2 synchronization Concern 3 C 3 11
AOSD as an Emerging Technology § First I want to position AOSD as an important emerging technology. 4 Statement from IBM at AOSD 2004. 4 A case study of Aspect. J usage from a paper by Colyer and Clement at AOSD 2004. Also used by Lo. DC explanation. 12
Daniel Sabbah’s (IBM VP for Software) A Part of Conclusions at AOSD 2004 § AOSD’s time has come. 4 The Software Industry needs it, and IBM is using it now. § IBM is taking AOSD very seriously 4 From a technical and business perspective 4 AOSD has development impact today across all major IBM brands – • Tivoli, Web. Sphere, DB 2, Lotus, Rational 4 Takeup in IBM is growing – no longer a “push”; there is now a lot of pull from across IBM’s development teams 13
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. 14
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. 15
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. 16
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! 17
Logging in Aspect. J When What. To. Do aspect Simple. Logging{ Log. File l; pointcut traced(): call(void *. update()) || call(void *. repaint()); before(): traced(){ l. log(“Entering: ”+ this. Join. Point); } } May affect Hundreds of Classes 18
Manual alternative § Mistakes that happened: 4 Some extra methods may be logged. 4 Some methods are forgotten to be logged. 4 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. 19
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 20
The Lo. D and Lo. DC § Lo. D: Talk only to your friends. 4 Control information overload 4 How to organize inside a set of concerns. § Lo. DC: Talk only to your friends who contribute to your concerns. 4 Better control of information overload and control tangling. 4 Separate ouutside concerns. § Lo. DC implies Lo. D. 21
Lo. DC and Contracting § Contracting buyer, contracting provider § Crosscutting interaction pattern § Contracting benefits 4 More agile 4 Better service, Amortization Talk only to your friends that contribute to your concerns 22
Talk only to your friends you Law of Demeter (Lo. D) FRIENDS 23
OO interpretation of Lo. D § Talk only to your friends 4 Class form: you = method of class, talk = use, friends = preferred supplier classes 4 Object form: you = method of object, talk = send message, friends = preferred supplier objects 24
Preferred supplier objects of a method § the immediate parts of this (computed or stored) § the method’s argument objects (which includes this) § the objects that are created directly in the method 25
Lo. D 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 Lo. D and serves as a conceptual guideline for you to approximate. 26
Explaining Lo. DC § 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. Lo. DC = Talk only to your friends who contribute to your concerns 27
Lo. DC: 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 don’t contribute to your concerns through a complex request. 4 Such a complex request (e. g. , Simple. Logging) may modularize many communications that would otherwise be scattered across many classes and methods. 28
contributing friends Law of Demeter for Concerns (Lo. DC) you FRIENDS 29
contributing friends Law of Demeter for Concerns (Lo. DC) FRIENDS l: Log. File you coordinates Complex request 30
Use Logging example to explain Lo. DC § 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. Lo. DC = Talk only to your friends who contribute to your concerns 31
Aspect. J When What. To. Do aspect Simple. Logging{ Log. File l; pointcut traced(): call(void *. update()} || call(void *. repaint(); before(): traced(){ l. log(“Entering: ”+ this. Join. Point); } } § How does Aspect. J support the Lo. DC? § Inserting calls l. log() manually would violate Lo. DC because logging is an intrusive new concern that is not part of the current concerns. 32
Aspect. J provides general purpose support for Lo. DC. § You: object § Talk: Method calls § Friends contributing to concerns: method calls (Base. App) § Concerns: 4 Old: Base. App 4 New: When. And. What. To. Do § Coordinates: execution points in Base. App § Examples: 4 void before (): execution_points_in_Base. App() 4 Weave: ajc Base. App. java When. And. What. To. Do. java 33
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 34
Demeter Motivation § V. Basili 1996: classes with less coupling are less error prone. § Demeter reduces the coupling in two stages: 4 Following the Law of Demeter using standard object-oriented techniques eliminates bad coupling. 4 Traversal strategies reduce the coupling further by coupling only with (distant) stable friends. 35
Basili’s 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 36
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. 37
Hypothesis § H-CBO: Highly coupled classes are more fault-prone than weakly coupled classes. 38
Result § Indeed, highly coupled classes are more fault-prone than weakly coupled classes. 4 Corollary: Classes that follow the Lo. D are less coupled and are therefore less fault-prone. 39
Booch and the Law of Demeter (Lo. D) 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. 40
Rumbaugh and the Law of Demeter (Lo. D) 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. 41
Agreement that Lo. D Good Idea § How to follow Lo. D: good solutions exist but not widely known. Two approaches to following Lo. D: 4 OO approach 4 Structure-shy approach • Traversal support 42
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. 43
Stable Preferred supplier objects of a method § the stable parts of this (computed or stored) 4 Parts reachable by a “short” traversal specification derived from the requirements § the method’s argument objects (which includes this) § the objects that are created directly in the method 44
Structure-shy Following Lo. D A C FRIENDS a S X c b B a : From S to A b : From S to B c : From S via X to C 45
Stable Friends Requirement: count all persons waiting at any bus stop on a bus route strategy: from Bus. Route via Bus. Stop to Person Bus. Route buses Bus. List 0. . * Bus villages Village. List 0. . * Village Bus. Stop. List bus. Stops 0. . * Bus. Stop waiting passengers Person. List 0. . * 46
Following the Lo. D (example by David Bock). § Instead of using (in class Paper. Boy) 4 customer. wallet. money; 4 customer. apartment. kitchen. Cabinet. mo ney; 4 customer. apartment. bedroom. mattress. money; § Widen the interface of Customer but decrease coupling. int Customer. get. Payment(. . ) § Stable friend is Money in: From Customer to Money. 47
Equation System Equation. System equations used. Variables = from Equation. System through -> *, rhs, * to Variable Equation_List Ident * Equation lhs Variable Numerical rhs Expression * Expression_List Simple args op Compound Add Lo. D 48
From Aspect. J (1997) back to Demeter (1992) Aspect. J § When (pointcut) Demeter (e. g. , DJ) § When (visitor signature) 4 set of execution points of any method, … 4 set of execution points of traversal methods 4 rich set of primitive pointcuts: this, target, call, … + set operations 4 specialized for traversals (nodes, edges) 4 when to enhance § What. To. Do (advice) 4 how to enhance 4 when to enhance § What. To. Do (visitor body) 4 how to enhance 49
Aspect. J When What. To. Do aspect Simple. Logging{ Log. File l; pointcut traced(): call(void *. update()) || call(void *. repaint()); before(): traced(){ l. log(“Entering: ”+ this. Join. Point); } } Java+DJ class Source{ Hash. Set collect(Class. Graph cg) {return (Hash. Set) cg. traverse(this, “from Source to Target”, new Visitor(){ … ; public void before (Target h) { … } public void start() {…}}); } } 50
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 51
Java+DJ When What. To. Do class Source{ Hash. Set collect(Class. Graph cg) {return (Hash. Set) cg. traverse(this, “from Source to Target”, new Visitor(){ … ; public void before (Target h) { … } public void start() {…}}); } } § How does DJ support the Lo. DC? § Inserting calls manually at Source and Target would violate the Lo. DC because our current concern is only Where. To. Go. 52
Java+DJ When What. To. Do class Source{ Hash. Set collect(Class. Graph cg) {return (Hash. Set) cg. traverse(this, “from Source to Target”, new Visitor(){ … ; public void before (Target h) { … } public void start() {…}}); } } § How does DJ support the Lo. DC? § Inserting traversal calls manually into all classes between Source and Target would violate the Lo. DC because the collect functionality is a new concern. 53
How does DJ support the Lo. DC? § It provides special purpose support for the Where. To. Go concern and for the When. And. What. To. Do concern relative to the Where. To. Go concern. 54
Demeter. § You: object § Talk: method calls § Friends c. c. : traversal method calls (Where. To. Go) § Concerns: 4 Old: Where. To. Go 4 New: When. And. What. To. Do § Coordinates: objects and object parts § Examples: 4 void before (Class_Where. To. Go host) 4 Class. Graph. traverse (obj, Where. To. Go, When. And. What. To. Do); 55
Subject-oriented Programming. § You: object § Talk: refer to members § Friends c. c. : members of a concern § Concerns: 4 New: behavior cutting across several classes § Coordinates: objects and object members 56
Leads to or helps explain/implement Controlling Structure Is-a Information Shyness Overload Overview Separation of concerns Aspect. J Automata Theory Lo. DC Composition Filters Traversal Strategies Aspects Demeter Complex Requests Adaptation Dilemma Subjects Visitors Lo. DC = Talk only to your friends that contribute to your concerns 57
More on strategies § Three layers of graphs: 4 Selector language: strategy graphs 4 Meta information: class graphs 4 Instances: object graphs § View all three graphs as automata § Product of non-deterministic automata 58
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 59
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 60
An Empirical Study of the Demeter System Pengcheng Wu and Mitchell Wand Northeastern University AOSD 04, SPLAT Workshop 61
Motivation § Collect evidence to support the claim: The Demeter system improves the 4 comprehensibility of software systems. 4 structure-shyness of software systems. 62
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 Demeter’s traversal strategies: the Demeter. J Compiler. It has 413 classes, 80 traversals on ASTs. 63
How complex are those traversals? 64
How complex are those traversals? (cont. ) 65
Traversal strategies improve comprehensibility § How to measure the improvement? Abstractness of a traversal strategy = Length(Method. Call. Paths)/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. 66
The abstractness metric 67
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. 68
Implementing the Lo. D in Aspect. J Supplier Target. Bin. Stack Aspect Diagram Immediate. Part. Bin Argument. Bin Checker Locally. Constructed. Bin Requirements: uses pointcuts Return. Value. Bin Global. Preferred. Bin Statistics Good Separation of Concerns in Law of Demeter Checker Lo. D – Lo. DC – aspects – Lo. D checking with aspects 69
Outline § Motivation, Thesis § What is AOSD? § AOSD as an emerging technology (reports from IBM) § The Lo. D and Lo. DC § Aspect. J supports Lo. DC § Introduction to Demeter § Demeter supports Lo. DC § From Lo. D to structure-shyness and better AOSD § Information hiding and Lo. DC § Open Problems § Conclusions 70
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 71
Strengthening Information Hiding may change in limits Implementation Interface Representation Independence Client Structure-Shy Programming Information Hiding 72
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. 73
Decoupling of Interface § We summarize the commonalities and differences between information hiding and structure-shy programming into two principles. 4 Representation-Independence Principle: the representation of objects can be changed without affecting clients. 4 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. 74
Structure-shyness in Aspect. J § Many Aspect. J programs are structure-shy (designed for a family of Java programs) 4 Context: Java program or its execution tree (lexical joinpoints or dynamic join points) § Features enabling structure-shyness: 4 *, . . (wildcards) 4 cflow, + (graph transitivity) 4 this(s), target(s), args(a), call (…), … (inheritance as wild card) • pc(Object s, Object t): this(s) && target(t) && call(… f …) 75
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(Q 1) to P(Q 2). § Application of the rule: Reusing a piece of software in a new context requires retesting. 76
Examples for Adaptation Dilemma § Aspect. J: After change to the base program an aspect suddenly misbehaves (e. g. , our Law of Demeter checker written in Aspect. J). § Demeter: After a change to the class graph, a traversal strategy suddenly misbehaves (e. g. , adding a new edge introduces many more undesired paths). 77
Crosscutting and Lo. DC § AOSD is about modularizing crosscutting concerns whose ad-hoc implementation would be scattered across many classes or methods. § Lo. DC does not talk directly about crosscutting but experience shows that the complex request influences often many classes and methods. 78
A different application of Lo. DC: Language extension and aspects § The Lo. DC (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’) 79
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’? 80
Language extension and aspects § Issues: 4 Interaction between multiple extensions. 4 What kind of context information is available at coordinates? 4 Deriving aspect language from grammar difference between G and G’. Is aspect language complete? 81
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 Aspect. J, Aspect. Werkz, Spring AOP Framework, JBoss-AOP, JAC, Demeter. J etc. (see http: //www. aosd. net) are happy to work with AOP abstractions. 82
AOSD techniques are popular § One reason is that AOSD abstractions produce a lot of code that would be 4 tedious and error-prone to write by hand 4 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. 83
Open issues § How to follow Lo. DC: There are many open questions 4 Suitable high-level coordinate systems 4 Study limited forms of aspects. E. g. , the D*J tools: Demeter. J, DAJ. 4 Interaction between aspects. Concern-shyness. 4 Reasoning about aspects, e. g. , what is the resource consumption of an aspect. 4 Managing the Adaptation Dilemma. 84
Conclusions § AOSD is an important emerging technology to control the complexity of software designs. § The Lo. DC is a suitable style rule helpful to explain better apply, explain and understand AOSD. § Properly following the Lo. DC (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! 85
Outline § Industry trend toward on demand Business 4 IBM’s Customers and their Changing Requirements 4 IBM’s Own Transformation § Aspect Oriented Software Development § Driving AOSD Technology within IBM § Future Activities around AOSD § Challenges § Conclusion & Questions 86
Deepening Integration of IT with Business Emerging On Demand Computing Model Traditional The Internet On Demand Structured Calculations Data Processing Transactions Open Standards Connectivity Flexibility Simplicity Modular Components easily defined and manipulated Dynamic definition and operations 87
On An (inter)enterprise whose business processes integrated end-to-end across the company and with key partners, suppliers and customers—can respond with speed to any customer demand, market opportunity or external threat. 88
The Need to Become More Horizontal Business Processes Product Lifecycle Management Procurement Category Management/ Merchandising SCM / Retail Operations Partner Relationship Mgmt. Bridging the gap between business transformation and IT. IT Sophistication 89
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 90
Core Technology Investment § Investing in core technologies 4 Aspect. J™ • • AO technology for the Java™ language Aspect. J 1. 1 recently awarded a Software Development Magazine Jolt Productivity Award 4 AJDT • Development environment for Aspect. J 4 CME • Cross-artefact, cross life-cycle capability § To provide the underpinning capability for internal, and external exploitation § All are Eclipse based, Open Source projects 91
Enhancing the quality and serviceability of software Delivering higher quality code through capturing and enforcing architectural standards and best practices: API Scanner Application Deployed Application Unit (EAR) Deployer / System Administrator Scanner Report 210 deprecation warnings 5 obsoletion errors 3 contraventions Application Developer Contravention Data -in human-readable form -for development tools API Contravention Scanner legend Web. Sphere Platformsupplied Productsupplied Scanner rules database (Deprecated, Deleted, Illegal Interfaces) Aspects Package/Class Map Rules & Filters Messages Conversion scripts Product Deployment Tools (version N) 92
Reengineering software – IBM’s and IBM’s customers Componentization Investigation: Refactoring the Web. Sphere Container § Concern Modelling § Visualization Run Query Analyse Query Report Alter EJB Support definition? Refactor a component § Concern-based queries 4 At one point, Query capability reported > 1000 links to resolve § Refactoring using OO and Aspect. J 93
Reengineering software – IBM’s and IBM’s customers Componentization Investigation: Refactoring the Web. Sphere Container § Scale of the exercise 4 15000 java source files. Around 1500 packages. 90 components, largest components around 250 kloc. 4 Substantial entanglement complexity § The tools stood up to the test 4 compiled > 20, 000 files with Aspect. J 4 build time ok 4 queries ran fast 4 Was an early use of CME query capabilities § Success!! 94
Reengineering software – IBM’s and IBM’s Componentization – Realizing the Shared Capabilities of IBM’s customers Software Portfolio Product Offerings Product Specific Investment Tivoli New or Enhanced Capabilities Web. Sphere DB 2 Lotus New or Enhanced Capabilities Shared Components Re-factor to SWG Product Offerings Shared Capabilities Componentization Tivoli Web. Sphere DB 2 Lotus Initial Base Product 95
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 96
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 97
Future § Continuous improvement in core technologies 4 Focus on extending cross artefact capability • Through CME 4 Drive use up the software stack • With Solution Aspects; with integration into Rational Tools § Broader technology exploitation across and within the products 4 For critical Qualities of Service 4 To enable componentization needed for customer (and IBM) flexibility 98
Future § Bringing the next level of AO value and capability to customers requires: 4 first class support in design and development tools • E. g. , Rational Development tools 4 first class support in the core runtime servers • E. g. , Web. Sphere Application Server, Portal Server, BI Server, etc. 4 first class representation in the programming model. • E. g. , Rational XDE Developer § And – bringing value to the level of Business Modelling 99
Challenges for the AOSD Research Community § Scalability through ‘complexity reduction’ 4 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 4 Essential for robust, full-solution integration 4 CME is an important start § Organizational Flexibility 4 “Organizational aspects” (e. g. , Problem Determination, or Serviceability, organizations) are assisted with AOSD technology 100 • It is a transformational technology
Challenges for the AOSD Research Community § Standards: Do we need them? 4 For commercial adoption at the end-user level – Yes. 4 Standards will be important to allow customers, ISV’s to have flexibility and to preserve investment § Complexity versus Simplification. 4 Does AOSD really help reduce complexity? • Need work toward gaining understanding of this question • But clearly WE think it DOES 4 AOSD introduces its own learning curve • Consequences for industrial adoption? • Who will be the practitioners? 101
Our Conclusions § AOSD’s time has come. 4 The Software Industry needs it, and IBM is using it now. 4 Our customers stand to benefit significantly. § IBM is taking AOSD very seriously 4 From a technical and business perspective 4 AOSD has development impact today across all major IBM brands – • Tivoli, Web. Sphere, DB 2, Lotus, Rational 4 Takeup in IBM is growing – no longer a “push”; there is now a lot of pull from across IBM’s development teams 4 Future impact will become more visible in IBM’s runtimes and in development tools 102
Trademarks § Aspect. J 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 NT, Biz. Talk, 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 Pro, 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. § AIX, AS/400, Blue Gene, Blue. Drekar, Lotus, Tivoli, Rational, XDE, Z/OS, DB 2, Deep Blue, Deskstar, Discoverylink, IBM, Microdrive, OS/390, Scrollpoint, Serve. RAID, Thinkpad, Trans. Note, Travelstar, Ultrastar, Websphere, Workpad, are all trademarks and registered trademarks of International Business Machines Corporation in the United States and/or other countries. 103
Thank You! § Questions? 104
§ old 105
Demeter 1. § You: object § Talk: Refer to parts § Friends: stable parts § Concern: 4 New: Where. To. Go § Coordinates: object parts § Examples: 4 From Bus. Route via Bus. Stop to Person Talk only to your stable friends that contribute to your concerns 106
contributing friends Law of Demeter for Concerns (LODC) FRIENDS you coordinates 107
contributing friends Law of Demeter for Concerns (LODC) FRIENDS new you coordinates 108
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 Representation Independence Shy Programming Information Hiding 109
Why object form is needed A B D E = = B D E. D. E. . class A { void f() { this. get_b(). get_d(). get_e(); } } 110
Object Form A B D E = = B D E. D. E. . a 1: A class A { void f() { this. get_b(). get_d(). get_e(); } } b 1: B d 1: D d 2: D e 2: E e 3: E e 1: E not a preferred supplier object 111
Object Form A B D E = = B D E. D. E. . a 1: A b 1: B d 2: D class A { void f() { this. get_b(). get_d(). get_e(); } } e 3: E e 2: E is a preferred supplier object (through aliasing) 112
§ Commonality between summing and logging 113
Leads to or helps explain/implement Controlling Structure Is-a Information Shyness Overload Overview Separation of concerns Aspect. J Automata Theory Lo. DC Traversal Strategies Aspects Demeter Complex Requests Adaptation Dilemma Subjects Visitors Lo. DC = Talk only to your friends that contribute to your concerns 114
OO interpretation of Lo. D § Talk only to your friends 4 Class form: you = method of class, talk = use, friends = preferred supplier classes 4 Object form: you = method of object, talk = send message, friends = preferred supplier objects 115
Lo. D 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 Lo. D and serves as a conceptual guideline for you to approximate. 116
Preferred supplier objects of a method § the immediate parts of this (computed or stored) § the method’s argument objects (which includes this) § the objects that are created directly in the method 117
Talk only to your friends you Law of Demeter (Lo. D) FRIENDS 118
§ Aspectual algorithms § Self application 4 Develop design tools for aspectual algorithms 4 Apply design tools to our design tool algorithms themselves 119
Leads to or helps explain/implement Controlling Structure Is-a Information Shyness Overload Overview Separation of concerns Aspect. J Automata Theory Lo. DC Composition Filters Traversal Strategies Aspects Demeter Complex Requests Adaptation Dilemma Subjects Visitors Lo. DC = Talk only to your friends that contribute to your concerns 120
- Slides: 120