Multi-dimensional Separation of Concerns in Hyperspace

Size: px

Start display at page:

Download "Multi-dimensional Separation of Concerns in Hyperspace"

Patrick Howard
5 years ago
Views:

1 Multi-dimensional Separation of Concerns in Hyperspace IBM Thomas Watson Research Center 1 Resources W. Harrison, H. Ossher & P. Tarr: The Beginning of a Graphical Environment for Subject-Oriented Programming, ECOOP 97 workshop on Aspect-Oriented Programming, Finland, June P. Tarr, H. Ossher, W. Harrison & S.M. Sutton: N Degrees of Separation: Multi-Dimensional Separation of Concerns, ECOOP 98 workshop on Aspect-Oriented Programming, Belgium, June S. Clarke, W. Harrison, H. Ossher & P. Tarr: Separating Concerns throughout the Development Lifecycle, ECOOP 99 workshop on Aspect-Oriented Programming, Lisbon, June H. Ossher & P. Tarr: Multi-Dimensional Separation of Concerns in Hyperspace, ECOOP 99 workshop on Aspect-Oriented Programming, Lisbon, June H. Ossher, W. Harrison, F. Budinsky & I. Simmonds: Subject- Oriented Programming: Supporting Decentralized Development of Objects. 2 1

2 Resources (cont.) H. Ossher & P. Tarr: On the Need for On-Demand Remodularization, ECOOP 2000 workshop on Aspects and Separation of Concerns, France, June 2000 H. Ossher and P. Tarr: Multi - Dimensional Separation of Concerns in Hyperspace, Research report No. RC 21452(96717)16APR99. I. Rouvellou, S.M. Sutton Jr. & S. Tai: Multidimensional Separation of Concerns in Middleware, ICSE 2000 workshop on Multi- Dimensional Separation of Concerns in Software Engineering, Limerick, Ireland, June K. Ostermann, G. Kniesel: Independent Extensibility - an Open Challenge for AspectJ and Hyper/J, ECOOP 2000 H. Ossher & P. Tarr: Multi-Dimensional Separation of Concerns and the Hyperspace Approach. P. Tarr & H. Ossher: Hyper/J TM User and Instalation Manual. 3 At the beginning... Machine Code Assembler Modular Languages Functional Languages ADL Separation of Concerns Aspects Composition Filters SOP etc. 4 2

3 Intro Seperation of concerns means ability to: identity encapsulate manipulate only those part of software that are relevant to a particular concept Reduce software development complexity Criterion for decomposition Varies over time due to the particular context development activities stage of the software lifecycle developers... not appropriate for all contexts 5 Features printing, persistence... Related Works Aspects cross-cutting & code tangling Roles Viewpoints... ==> only one dominant decomposition impossible to switch to other dimension 6 3

4 The Goals Multiple, arbitrary dimensions of concerns. Separation along these dimensions simultaneously. Ability to: Modify concerns Add new concerns remove a concern dynamically. printing, persistence... Result: On-demand remodularization 7 Background & Motivation Simple Software Engineering Environment (SEE) a:=b+5 syntax correct a=16 Display Check Eval := a + b 5 8 4

5 Scenario Classes: Expression Literal Binary Operator (+, -, *, /) Unary Operator (+, -). Operations: create get/set eval display check 9 Concerns Classes Features: kernel, display, check, evaluation Artifacts: requirement, design, code, test plan Configuration: mix and match Feature: style checking is a new concern Logging Design Pattern

6 The Tyranny of the Dominant Decomposition Different decomposition have different properties, both good and bad. Different dimensions are useful for different reasons, at different times. Anticipation causes ulcers. Multiple dimensions, simultaneously. 11 Breaking the Tyranny Ability to identity and encapsulate any dimension simultaneously. Ability to identify new concern and new dimension of concern incrementally. Developers must not be required to know about any concerns that do not affect their particular activities. Ability to represent and manage overlapping and interacting concerns. On-demand remodularization: ability to inpose new decompositions on existing software. 12 6

7 The Hyperspace 13 Concern Space of Units Software consists of artifacts, which comprise descriptive material in suitable languages. A unit is a syntactic construct in such a language declaration, statement, state chart, class, interface primitive units vs. compound units. A concern space encompasses all units in some body of software. 14 7

8 The Concern Matrix Units are organized in a multidimensional matrix axe = dimension point on an axe = one concern in that dimension the coordinate of the units = set of concerns it affects, each unit affect exactly one concern in each dimension hyperplane = single concern within some dimension. special none concern for each dimension. 15 Formalization A hyperspace is a tuple (U, M, H) U: a set of units M: a concern matrix H: set of hypermodules The unit set induced by concern c: U(c) = {u U c(u) Dimension of concern = set of concerns whose unit sets partition U The none concern for dimension d, N d : important: units that are unaffected by evoltionary changes within its dimesion. 16 8

9 Formalization... Concern matrix is a tuple (C,D) C: set of concerns D: set of concern dimension Every concern in C is in exactly one dimension in D Every dimension in D partitions U. 17 Hyperslice & Hypemodules Hyperslice = set of units Hypermodule = group of hyperslices Hyperslice required to be declaratively complete ==> Separation of declaration from implementation Correspondence constraint: Each declaration unit in a systém must correspond to compatible implementaton(s) in some other hyperslice. 18 9

10 Hyperslice & Hypermodule... hyperslices are concerns required to be declarative complete. special dimension for all hyperlices ==> hyperslice dimension. hyperslice may affect a concern (overlap) Hypermodule is a tuple (HS, CR) HS: set of hyperslices CR: set of composition relationship 19 The Hyper/J Hyperspace for Java 20 10

11 Project specification hyperspace DemoHyperspace composable class demo.objectdimension.*; composable class demo.stylechecker.*; composable class demo.observer.*; Concern mapping package com.ibm.hyperj.expressionsee: operation display: operation check: operation eval: Hyper/J Intro None concerns are created automatically. Feature.Kernel Feature.Display Feature.Check Feature.Eval 21 Hyper/J Intro... Hypermodules: hypermodule SEE_With_Display_And_Check hyperslices: Feature.Kernel, Feature.Display, Feature.Check relationships: mergebyname 22 11

12 Hyper/J Example 2 hypermodule DemoSEE hyperslices: Feature.Kernel, Feature.Check, Feature.Display, Feature.Eval, Feature.StyleChecker, Feature.Logging; relationships: mergebyname; equate operation Feature.Kernel.process, Feature.Check.check_process,Feature.Display.display_proces, Feature.Eval.eval_process; bracket "{~_,~<*" with (before Feature.Logging.LoggedClass._beforeInvoke ($ClassName, $OperationName), after Feature.Logging.LoggedClass._afterInvoke ($ClassName, $OperationName), "*"); set summary function for action DemoSEE.BinaryOperator.check to action DemoSEE.Expression.summarizeCheck; end hypermodule; 23 The Hyper/J in details Class file specification class package1.classname1, package1.classname2; composable class package2.* except package2.someclass; composable file c:\users\smith\someproject\* uncomposable class java.lang.*, java.io.*; Concern mapping package java.lang: Feature.Library; package someproject.util: Feature.Utilities; class someproject.util.myclass: Optimization.UtilityOptimizations; interface java.util.enumeration: OtherDimension.SomeConcern; operation display: Feature.Display; field foovar: Feature.Foo; Hypermodule Specification hypermodule hypermodulename hyperslices: relationships: mergebyname noncorrespondingmerge overridebyname; other relationships; 24 end hypermodule; 12

13 The Hyper/J in details... Composition Strategy mergebyname: units that have the same name are to correspond, and are to be connected by a merge relationship. noncorrespondingmerge: units in different hyperslices with the same name are not to correspond, and hence are not to be connected. overridebyname: units with the same name are correspond and are to be connected by an override relationship (last unit). 25 The Hyper/J in details... Equate equate class SomeDimension.SomeConcern.SomeClass, ; equate operation Feature.kernel.process, Feature.Check.check_process Indicates a set of units that match each other, to correspond, even their names do not match. Order order action SomeDimension.SomeConcern.SomeClass.foo before action SomeOtherDimension.SomeOtherConcern.SomeClass.foo; Rename rename class HypermoduleName.SomeClass to SomeNewName 26 13

14 Bracket: bracket foo* with The Hyper/J in details... {before Feature.Logging.LoggedClass.invokedBefore($ClassName) after Feature.Logging.LoggedClass.invokeAfter($OperationName), * ; Set of operations in hypermodule in the hypermodule that will bu bracketed (pre/post action) before and/or methods that are to bracket the indicated methods class match pattern Summary set summary fuction for action DemoSEE.NumberLiteral.check to DemoSEE.Expression.sumarizeCheck; by default, the return value is the return value of the last method of which is composed. 27 Current Hyper/J Limitation Java predefined class (Object, String...) cannot be composed. noncorrespondingmerge general composition strategy does not work correctly and has been disabled. merge and override composition relationships do not work. nomerge composition works only on operations order relationship work correctly only for actions summary function must be static classes in the composed hyperslices are public, in a single top-level package

15 Hyper/J versus AspectJ package billingsystem class Invoice { void deliver() { class SpecialInvoice extends Invoice { class InvoiceClient { Invoice Invoice = new Invoice(); void foo() { Invoice.deliver(); 29 Hyper/J versus AspectJ... package billingsystem; class MailExtensionAspect { introduction Invoice { void sendmail() { static advice (Invoice invoice) : void print & invoice { before { invoice.sendmail(); 30 15

16 Hyper/J versus AspectJ... package extension; public class Invoice { public void sendmail() { public void deliver() { sendmail(); hypermodule extendedbillingsystem hyperslices: Feature.billingsystem, Feature.extension; relationships: mergebyname; end hypermodule; 31 Hyper/J versus AspectJ... AspectJ: in-place modification destructive: original class is no longer exists if only clients should use the modified class, it fails. Hyper/J Client migration existing classes are not modified maintenance problem 32 16

17 Conclusion Comprehensibility need only to examine the hyperplane containing ability to identify concern on ongoing basis separate simultaneously all concerns of importance. Do not restrict the nature or number of dimensions Evolvalibility, limited impact of change and traceability additive rather than invasive change extension, customization and extraction of hyperslices 33 THE END 34 17

Multi-Dimensional Separation of Concerns and IBM Hyper/J

Multi-Dimensional Separation of Concerns and IBM Hyper/J Technical Research Report Barry R. Pekilis Bell Canada Software Reliability Laboratory Electrical and Computer Engineering University of Waterloo