Reusability of Concerns

Reusability of ConcernsAndreas Speck Elke Pulverm¨u ller Mira Mezini Wilhelm-Schickard-Institute for Computer ScienceUniversity of T¨u bingen72076T¨u bingen,Germanyspeck pulvermu@informatik.uni-tuebingen.deUniversity of Siegen57068Siegen,Germanymira@informatik.uni-siegen.deAbstractVarious recent approaches aim at improving the appli-cation of the separation of concerns principle by introduc-ing new system units.Although they seem to have the po-tential to improve the system development process,addi-tional challenges evolve.This paper addresses some chal-lenges concerning the reusability of these new system units. Our considerations about reusability are twofold.First, the independence of these system units is regarded on the mechanism level.Second,the composition validation prob-lem emerging from the composition of these new and also reusable system units is investigated.The problems are il-lustrated by means of two examples.1Introduction and Problem Classification Common to recent approaches exploring the future be-yond“objects”is that they all aim at a better separation of concerns.Besides objects,they introduce new units encap-sulating concerns along additional dimensions.In this paper we comprise these units in the term“units of concerns”.Though the introduction of new units of concerns is an important step towards a better separation of concerns,the developer is faced with new problems.In this paper we address one of these problems:the reusability with respect to the new units of concerns and the combination of reusable units of concerns in the same application.Supportive to our discussion we introduce a classifica-tion for the various problems and requirements which ap-pear when aiming at a good separation of concerns.Infig-ure1we divide a system(consisting of concerns)into two layers:1.Conceptual or Design LayerThe higher conceptual layer titled“Units of Concerns”deals with the design of concerns.The design issues are the static architecture and arrangement of concerns (combinations),their dynamic behavior(interactions) and their internal structure and composition.The design would be supported by an abstract,unify-ing model for the different concrete approaches.This leads to the problem determining to what extent it is possible to handle the concepts independent to the technology layer.2.Technology or Mechanism LayerThe lower layer embraces mechanisms for the im-plementation of concerns(e.g.subject-oriented pro-gramming SOP,aspect-oriented programming AOP, compositionfilters CF,adaptive programming AP).The object-oriented paradigm and these different ap-proaches with their introduced linguistic or extra-linguistic constructs to support the application of the separation of concerns principle can be classified mainly into this layer.Typical for these technologies is that they have to support the design,i.e.they have toprovide means for the combination and the interaction of the units of concerns(including objects)as well as means for the reuse of the units of concerns.Challenging problems on this level deal,for instance, with the questions“What mechanisms should be pro-vided to realize/improve the separation of concerns principle?”,“What implementation guidelines and id-ioms aid to achieve a good separation of concerns?”.On each level,a set of experienced problems and a set of derived requirements to deal with these problems can be identified.For each instance in the problem set one to many requirements can be derived.Each such problem or require-ment on the conceptual level may yield several problems, respectively requirements,on the technology and mecha-nism level.In our work we experienced reusability both as a key re-quirement for a good separation of concerns and as a re-quirement difficult to achieve.We use the introduced sys-tem and problem hierarchy to classify and illustrate two facets of reusability.Reusability on the technology level deals mainly with suitable mechanisms,constructs or id-ioms to achieve reusability whereas the layer above con-centrates on design for reusability with respect to the whole unit(i.e.not referring to concrete mechanisms).2Reusability on the Technology and Mecha-nisms LevelIndependence of system units or of the units of concerns, respectively,is a property crucial to their reusability.Simi-lar to the principles of modular system design the coupling between system units(including the new units of concerns) should be minimized while the cohesion should be maxi-mized.Primarily this is a conceptual requirement.From this conceptual requirement a concrete requirement for the mechanisms and technology level can be derived.On the mechanisms level,it should be possible to implement units of concerns in separate constructs with minimum knowl-edge about each other.An example demonstrates this problem or requirement, respectively,on the mechanism layer.There,aspects[4] are used to separate distribution-related code from problem domain-related code.This reduces complexity by avoiding confusion caused by a mixture and improves reusability of problem domain code.Infigure2the simplified example is outlined to show the problem.The application realizes clients which send their requests to a server.This server returns a simple string.De-tails on the example and its implementation can be found in [11].Distribution is achieved by using JavaIDL(from Sun Microsystems)which is a nearly CORBA(Common Ob-ject Request Broker Architecture)-compliant[9]ORB im-plementation.CORBA-related code is extracted and local-ized into aspects written in AspectJ0.4beta7[14].The example implementation consists of four units. These are the Server Code and the aspects ServerName,ServerString and ServerComm.The Server Code im-plements the server which manages the client requests to the servant.The latter exposes services(here the get() method).The aspects encapsulate all CORBA-related code. To expose a service,the client has to obtain an initial ref-erence to the server.This can be done either via a name server or via afile-based solution(the stringified refer-ence is stored in afile which is accessible for clients and server).Aspect ServerName encapsulates the CORBA-related code realizing the name server-based solution while aspect ServerString separates the code for thefile-based solution.Aspect ServerComm implements the endless loop waiting for client requests.This example implementation reveals the problem men-tioned above:In AspectJ0.4beta7,each advice construct names the method which is advised and the class embracing this method(e.g.aspect ServerName advises method main of class Server).Similarly,method introductions name the class into which this new method has to be introduced. Therefore,the link or join point,respectively,between as-pect and class is expressed in the implementation of the as-pect.The reuse of aspect ServerComm,for instance,in another context is desirable but not possible without code changes in this implementation.The conclusions which can be drawn from this exam-ple is that a concrete mechanism introducing new constructs for new units of concerns should aim at maximum indepen-dence between the constructs even on the implementation level.Such a construct can be called independent on the mechanism/technology level if neither the new constructs require to contain any knowledge about other system units (e.g.classes)nor vice versa.A composition tool has to resolve this independence in a specific application.The question how and when to resolve it(e.g.at run-time or at compile-time)is a matter of technology and mechanism design.For our current implementations of a repository for As-pectJ aspects we transform them so that the result does not contain any explicit knowledge about the base class to which the aspect will be applied.Aspects modified in this way can be stored(independent from the context they may be embedded in future)into a database representing the as-pect repository.Afterwards they can be queried by other objects and reused if desired.In the moment they are cho-sen from the aspect repository the code is re-transformed, i.e.the formerly removed dependencies to a certain class are re-injected according to the querying object.A helpful classification for the degree of independence on this mechanism level in a certain application can be found in[3].In[5]the notion of aspectual components and connec-tors are introduced.Aspectual components extend adaptive plug-and-play components(AP&P)[8]with a modification interface that turns them into an effective tool for the sepa-ration of concerns.Part of the concept of aspectual compo-nents are the connectors which encapsulate the join points in a separate construct(which also introduces a new dimen-sion in the separation of concerns).While both the units of concerns(called aspectual components)and classes be-come reusable,the connectors are bound to a specific appli-cation and thus usually not reusable.Connectors decouple the main system units improvingflexibility with respect to reuse.The connectors compose these independent units and are thus by concept application-dependent.A similar but less detailed proposal to extract the join points from aspects can be found in[2].3Reusability on the Design and Concept LevelAn example for reusability on the design level may be a visualization system for automation devices as shown in figure3.In this application the devices of a manufacturing cell are displayed on a remote workstation or PC.Hence the device controllers are connected to the visualization system via a LAN.(Here,the example is simplified for demonstra-tion purposes.A more detailed description of such systems may be found in[13]and[12]).In the following we concentrate on the visualization sys-tem.It consists of a basic system(including the Visualiza-tion,the dynamic Control,the User Interface and the Com-munication).The other parts(grey shaded)are the addi-tional units of concerns we focus.These units may be in-serted into the system or omitted.They represent models of the displayed(types of)devices.Infigure3,for instance, SCARA SR60Robot Arm Model captures the model of a certain type of robot arm called Bosch SCARA SR60.This unit of concerns can be used for all real robot arms of type Bosch SCARA SR60.Moreover,thefigure shows units of concerns representing peripheral device models for certain types of real peripheral devices.These are Selectron DIOC digital I/O unit and Lenze electro motor,respectively.All these units of concerns depicted infigure3reflect only a subset of all possible real devices.To represent these models,the units of concerns con-tain the knowledge about the architecture and functionality (e.g.the robot kinematics)of certain types of devices.This knowledge is crucial to the visualization and display of the arm position or states of the devices.The robot arm model (here SCARA SR60Robot Arm Model)unit contains the arrangement of the joints and the axis as well as their be-havior.This unit of concerns interpretes the data from the real robot in order to compute the robot motions and calls the Visualization.This results in displaying a virtual robot arm reflecting the real one.Similarly,the peripheral device models(here Selectron DIOC digital I/O unit-peripheral Device Model and Lenze electro motor-peripheral Device Model)know about thereal peripheral devices.All peripheral device models are devices to support the robot,e.g.a transfer system or the robot gripper.As opposed to the robot arm model the pe-ripheral device models use the User Interface to display the state of the device.The capability of the visualization platform(ranging from powerful workstations to small industrial grade PCs) differs very much.Therefore the visualization base sys-tem(including the Visualization,the dynamic Control,the User Interface and the Communication)has to be adapted to the performance of the visualization hardware.How-ever,the models of the controlled devices(e.g.SCARA SR60Robot Arm Model,Selectron DIOC digital I/O unit -peripheral Device Model and Lenze electro motor-pe-ripheral Device Model)are independent from the different visualization base systems and may be reused.Each type of device requires a corresponding and appropriate unit of concerns which is adapted to this type.For different devices which are of the same type the same unit of concerns can be reused.The problem revealed by the example above concerns the dependency structure between the system units.The combination of the system units or the units of concerns, respectively,is not arbitrary.This fact affects the reusabil-ity.In the case of reuse the developer has to take care about the various relationships both between units of concerns and between units of concerns and objects or the system,respec-tively.This is done manually at the moment.The following rules and constraints for the combination of the units of concerns can be identified for our example (this is only a subset of all dependencies):At least one device has to be inserted otherwise the visualization does not display anything and is useless.At most one robot arm can be visualized in one system.Thus,robot arm models are mutually-exclusive.This is due to the fact that only one robot arm is mounted in one manufacturing cell.Some robot arm types require a certain peripheral de-vice of a predefined set of peripheral devices.Often such a device is needed as their end effector(e.g.grip-per).It is crucial to make these relationships and dependencies somehow explicit.Dependency rules which proved to be necessary for our work are the following:1.not A1:A not-clause expresses that the unit of con-cerns with name A1is not allowed to be woven into the class instance or into the system,respectively.2.requires A1:Weaving the unit A1into the class in-stance is mandatory.This rule may also have multi-ple arguments(e.g.requires A1A2A3)indicating that at least one of these units of concerns is mandatory (in the example either A1or A2or A3is mandatory).3.xor A1A2:This expression indicates that either A1or A2may be woven into a class instance but never both of them.4.and A1A2:An and-clause expresses that A1and A2have to be woven together into the same class instance.After exploring the types of dependencies and relation-ships,the concrete dependencies for a set of system units have to be found(as outlined above for our example)and expressed.The identification of the dependencies is a prob-lem comparable to the feature interaction problem.Insert-ing a new feature poses the question whether and which un-desirable effects/impacts this feature has to the remainder of the application.Only a small subset of those impacts and invalid relationships can be detected by a weaver,pre-processor or compiler.In certain cases it may happen that the insertion indicates no error but the fault emerges at some time and somewhere during execution.Although this is a problem on the conceptual level,it can be supported by certain technologies or by a separate tool.Solutions to detect the dependencies between features can be found in the research on feature interaction.In[10]a way is illustrated to express these relationships during spec-ification based onfinite state automata.Research on GenV oca generators addresses the compo-sition validation problem for systems composed of compo-nents from reuse libraries[1].These ideas may be also em-ployed in multi-dimensional approaches.We recently developed further support for the system de-veloper.In our solution we assumed that the dependencies are known in advance.Our work was driven by the ob-servation that with a growing number of aspects,manual control of these dependencies becomes error-prone or even impossible.We use assertions[7],[6]indicating incorrect system unit combinations.The simplified procedure reflecting this solution is de-picted infigure4Assertion code is inserted into the system units.Af-ter composing these units and during execution this code checks the validity of the composition.A knowledge base containing all the information about valid and invalid com-positions is queried for this purpose.4ConclusionThis paper illustrates by means of two examples two problems we experienced in our work.Thefirst problem concerns the reusability on the technology and mechanisms level.Introduced implementation constructs aiming at a better separation of concerns should allow to produce sys-tem units which are independent to each other to a large Although this seems to be a simplification,we believe that most de-cisions about the validity of a relationship are not a question of syntax or semantic but pragmatic.Thus a computer can only support but never solve this point automatically.Knowledge Basecontaining theDependency rules extent.The second problem demonstrated at a robot vi-sualization example deals with unavoidable or even desir-able dependencies and relationships between the units on the conceptual level.Both problems are important issues when aiming at reusability.Existing solutions to these problems are listed.While the existing solutions to achieve independence on the mecha-nism level seem to be helpful to a large extent,the solutions for the composition validation problem(the dependencies on the concept level)of multi-dimensional approaches are only afirst step towards an overall solution. References[1] D.Batory and position Validation and Sub-jectivity in GenV oca Generators.In IEEE Transactions onSoftware Engineering,pages67–82,1997.[2] A.Beugnard.How to make Aspects re-usable,a Proposi-tion.In Proceedings of the Aspect-Oriented ProgrammingWorkshop at ECOOP99,1999.[3]M.A.Kersten and G.C.Murphy.Atlas:A Case Study inBuilding a Web-based Learning Environment using Aspect-oriented Programming.OOPSLA,1999.[4]G.Kiczales,mping, A.Mendhekar, C.Maeda,C.Lopes,J.-M.Loingtier,and J.Irwin.Aspect-OrientedProgramming.In Lecture Notes in Computer Science LNCS1241,ECOOP.Springer-Verlag,June1997.[5]K.Lieberherr,D.Lorenz,and M.Mezini.Programmingwith Aspectual Components.Technical Report NU-CCS-99-01,Northeastern University,March1999.[6] B.Meyer.Applying“Design by Contract”.IEEE Computer,25(10):40–51,October1992.[7] B.Meyer.Object-Oriented Software Construction.PrenticeHall PTR,Upper Saddle River,NJ,second edition,1997. [8]M.Mezini and K.Lieberherr.Adaptive Plug-and-Play Com-ponents for Evolutionary Software Development.In ACMSIGPLAN notices,Conference Proceedings OOPSLA’98,volume33,October1998.[9]Object Management Group.The Common Object RequestBroker:Architecture and Specification,February1998. [10]L.Pazzi.Explicit Aspect Composition by Part-Whole State-charts.In Proceedings of the Aspect-Oriented Programming Workshop at ECOOP’99,1999.[11] E.Pulverm¨u ller,H.Klaeren,and A.Speck.Aspects in Dis-tributed Environments.In Proceedings of the International Symposium on Generative and Component-Based Software Engineering GCSE’99,Erfurt,Germany,September1999.[12] ponent-based Control System.In Proceed-ings of ECBS’2000,Int’l IEEE Symposium and Workshop on Engineering of Computer Based Systems,ECBS,Edin-burgh,2000.IEEE Computer Society Press.[13] A.Speck and H.Klaeren.RoboSiM:Java3D Robot Vi-sualization.In Proceedings of IECON’99,The25th An-nual Conference of the IEEE Industrial Electronics Society, pages821–826,San Jose,CA,1999.IEEE Press.[14]XEROX Palo Alto Research Center,.Homepage of AspectJ,2000.。