Emmerich, W.

Finkelstein, A.

Nentwich, C.

City Research Online

              City, University of London Institutional RepositoryCitation: Nentwich, C., Emmerich, W. and Finkelstein, A. ORCID: 0000-0003-2167-9844 (2002). Edit, compile, debug: from hacking to distributed engineering. Paper presented at the Workshop on Aspect Oriented Design at the 1st International Conference on Aspect Oriented Software Development (AOSD), 22-26 Apr 2002, Enschede, The Netherlands. This is the accepted version of the paper. This version of the publication may differ from the final published version. Permanent repository link:  https://openaccess.city.ac.uk/id/eprint/26484/Link to published version: Copyright: City Research Online aims to make research outputs of City, University of London available to a wider audience. Copyright and Moral Rights remain with the author(s) and/or copyright holders. URLs from City Research Online may be freely distributed and linked to.Reuse: Copies of full items can be used for personal research or study, educational, or not-for-profit purposes without prior permission or charge. Provided that the authors, title and full bibliographic details are credited, a hyperlink and/or URL is given for the original metadata page and the content is not changed in any way. City Research OnlineCity Research Online:            http://openaccess.city.ac.uk/            publications@city.ac.ukEdit, Compile, Debug – From Hacking to Distributed EngineeringChristian Nentwich, Wolfgang Emmerich and Anthony FinkelsteinDepartment of Computer ScienceUniversity College London, London WC1E 6BT{c.nentwich,w.emmerich,a.finkelstein}@cs.ucl.ac.uk1 BackgroundSpecifying a system from different viewpoints, in het-erogeneous design notations, and using a distributedteam, introduces several challenges that test the stateof the art in software engineering. One of these chal-lenges is to check the consistency of such heterogeneousnotations, and to deal with the problem of inconsistencythroughout the lifecycle — including the managementof inconsistency between notations at the same stagesof the lifecycle, such as multiple UML models, and in-consistency between stages, such as the consistency ofdesign and code.We envisage a scenario where developers can executeconsistency checks at arbitrary stages of the lifecycle inorder to get feedback. Developers are presented withreports on the current consistency status, and can de-cide whether or not to take action. Because of the de-synchronised nature of distributed software engineering,we take a lightweight approach that does not require to-tal consistency, but instead fetches specifications whendevelopers are prepared to evaluate consistency, andpoints out inconsistencies without forcing changes.Our most recent work is aimed at providing developerswith a range of choices for repairing documents, andat addressing problems of scalability in checking dis-tributed documents.2 Consistency CheckingTo support the kind of activity outlined above we havedeveloped xlinkit [2], a generic technology for check-ing the consistency of distributed, heterogeneous docu-ments. xlinkit is a fully implemented, working systemthat has been used in several industrial case studies andcan be downloaded at http://www.xlinkit.com.While xlinkit can be used in many application domains,it is very suited to software engineering documents. In[3] we describe the application of xlinkit to checking theconsistency of the design, implementation, and deploy-ment descriptors of Enterprise JavaBeans (EJB)-basedsystems.Consistency is defined in xlinkit through a set of con-straints, called consistency rules. A consistency ruledefines how elements in different documents are inter-related. Figure 1 gives an example of a consistency rule(using xlinkit’s XML rule syntax) that prescribes thatinterfaces that inherit from “EJBObject” must be im-plemented by a class that inherits from “EntityBean”or “SessionBean”.xlinkit returns as its output a set of links that connectinconsistent elements in document. This is an improve-ment on the boolean evaluation of first order formulaebecause the links pinpoint precisely the combination ofelements that causes the inconsistency. Figure 2 showsa link generated by evaluating the sample rule. In thiscase, the link points to only one location, the interfacefor which no corresponding class was found.3 Consistency ManagementConsistency management, the problem of detecting, as-sessing and potentially resolving inconsistency, is a deli-cate topic that is subject to a variety of influences, fromdomain specific ways of accomplishing goals, down toindividual working preferences. Having provided a so-phisticated system for detecting inconsistency, our goalis to specify a very basic, rudimentary mechanism forreporting inconsistencies and for making simple changesin order to remove inconsistencies. Once such a basicmechanism is in place, it can form the infrastructure fora more elaborate consistency management or conflictresolution process that can take into account informa-tion such as workflow, or policies that set priorities fordifferent kinds of specifications to enable overriding.On a very abstract level, we expect a consistency man-1<forall var="i" in="/java/interface[extends/@name=’EJBObject’]"><exists var="c" in="/java/class[../package/@name=$i/../package/@nameand (implements/@name=’EntityBean’ orimplements/@name=’SessionBean’)]"/></forall>Figure 1: Sample xlinkit consistency rule<xlinkit:ConsistencyLink ruleid="javaejb_inter.xml#id(’r2’)"><xlinkit:State>inconsistent</xlinkit:State><xlinkit:Locatorxlink:href="Job.java#/java/interface"/></xlinkit:LinkBase>Figure 2: Sample consistency linkEditCheckRepairReportFigure 3: Consistency management processagement process to look like Figure 3. Developers willdecide to assess the consistency of their documents,make a check, get reports back, and either decide onan action for “repairing” the documents, or defer thedecision and go back to editing. We have already ad-dressed the checking process, and will concentrate onreport generation and repair in the next two sections.4 Report Generationxlinkit’s linking diagnostics, which connect inconsistentelements in distributed specifications and deliver themin the form of an XLink [1] linkbase, are powerful butnot particularly friendly for human consumption. Wehave developed a report generation tool, Pulitzer, thatcan read such linkbases and display marked up infor-mation about the elements that the locators point to.Using Pulitzer it is possible to provide reports similarto traditional compiler error output — but at the inter-viewpoint level! — in a variety of formats. Figure 4shows an HTML report generated after checking an EJBsystem.5 RepairWhen elements in distributed specifications have beenlinked and identified as inconsistent, it should be possi-ble to offer some simple repair choices to developers. Asan example, in our sample rule given above we have aninconsistency because for some Java interface we did notfind a correct implementation. In this case, we could of-fer the developer to automatically introduce a new Javaclass that fulfills the requirements.In general, it is straightforward to enumerate the repairoptions available to developers. One case add elementsto specifications, delete elements, and change proper-ties of elements. When adding or changing elements,one can let developers enter values for the properties ofelements, search the specifications for existing values touse, or fall back to defaults.The challenging task is then not to enumerate repairoptions but to prune them in order to leave only “sen-sible” choices. In our sample rule, we could removethe inconsistency by deleting the offending Java inter-face — although in most cases this would be attackingthe symptom instead of the problem, and would notbe a sensible choice. We believe that the developersresponsible for establishing the constraints should beable to determine which repair actions make no sense.We are planning to analyse the formulae so as to comeup with an exhaustive list of actions and presenting asimple interface for pruning them down.Should this kind of pruning process still result in anoverwhelming number of repair choices, domain specificheuristics can be used to cut them down further. Forexample, it may be possible in a software engineeringsetting to use a “differential” approach that comparesthe consistency status of specifications before and afterthe last consistency check, and uses this information todetermine more precisely which elements may have to2Figure 4: Sample reportbe changed. Whether this approach works or not, byproviding an enumeration of the repair choices based onformula analysis, we will establish a sound infrastruc-ture on top of which such heuristics can be built.6 ScalabilityScalability problems occur in various guises in consis-tency management. A good system must be able toscale as the number of documents and constraints in-creases, and as the size of documents increases. It mustalso be scalable in terms of user-friendliness, by provid-ing mechanisms that simplify the expression of a largenumber of constraints.We are currently working to address the problems ofchecking large documents and large numbers of doc-uments through a variety of means: by providing in-cremental checks, which analyse changes to documentsand minimize the number of constraints that have to berechecked; by implementing a distributed supervisor –worker architecture that can deal with large amounts ofdata; and by using the caching facilities of native XMLdatabases to lower the main memory requirements ofour service. Substantial progress has been made in theseareas.We have also implemented a macro mechanism and apredicate plugin mechanism for our formula languagethat greatly facilitate the expression of a large numberof constraints. We are currently evaluating these fea-tures in case studies.7 ConclusionWe have outlined our current position with regard toachieving a system for managing the consistency of dis-tributed specifications. xlinkit takes a big step in thisdirection by providing a solid base for checking the con-sistency of distributed, heterogeneous documents.We are now working to establish a simple method forsuggesting repair options to developers, without com-promising our view of inconsistency as something thatcannot necessarily be eliminated. We are also evaluat-ing our tools for dealing with scalability problems thatarise as documents sizes and the number of documentsgrow.References[1] S. DeRose, E. Maler, and D. Orchard. XML LinkingLanguage (XLink) Version 1.0. W3C Recommen-dation http://www.w3.org/TR/xlink/, World WideWeb Consortium, June 2001.[2] C. Nentwich, L. Capra, W. Emmerich, andA. Finkelstein. xlinkit: a Consistency Checking andSmart Link Generation Service. ACM Transactionson Internet Technology, 2001. To appear.[3] C. Nentwich, W. Emmerich, and A. Finkelstein.Flexible Consistency Checking. Research note, Uni-versity College London, Dept. of Computer Science,2001. Submitted for Publication.3

Edit, compile, debug: from hacking to distributed engineering

UCL Discovery

Edit, Compile, Debug { From Hacking to Distributed EngineeringChristian Nentwich, Wolfgang Emmerich and Anthony FinkelsteinDepartment of Computer ScienceUniversity College London, London WC1E 6BTfc.nentwich,w.emmerich,a.finkelsteing@cs.ucl.ac.uk1 BackgroundSpecifying a system from dierent viewpoints, in het-erogeneous design notations, and using a distributedteam, introduces several challenges that test the stateof the art in software engineering. One of these chal-lenges is to check the consistency of such heterogeneousnotations, and to deal with the problem of inconsistencythroughout the lifecycle | including the managementof inconsistency between notations at the same stagesof the lifecycle, such as multiple UML models, and in-consistency between stages, such as the consistency ofdesign and code.We envisage a scenario where developers can executeconsistency checks at arbitrary stages of the lifecycle inorder to get feedback. Developers are presented withreports on the current consistency status, and can de-cide whether or not to take action. Because of the de-synchronised nature of distributed software engineering,we take a lightweight approach that does not require to-tal consistency, but instead fetches specications whendevelopers are prepared to evaluate consistency, andpoints out inconsistencies without forcing changes.Our most recent work is aimed at providing developerswith a range of choices for repairing documents, andat addressing problems of scalability in checking dis-tributed documents.2 Consistency CheckingTo support the kind of activity outlined above we havedeveloped xlinkit [2], a generic technology for check-ing the consistency of distributed, heterogeneous docu-ments. xlinkit is a fully implemented, working systemthat has been used in several industrial case studies andcan be downloaded at http://www.xlinkit.com.While xlinkit can be used in many application domains,it is very suited to software engineering documents. In[3] we describe the application of xlinkit to checking theconsistency of the design, implementation, and deploy-ment descriptors of Enterprise JavaBeans (EJB)-basedsystems.Consistency is dened in xlinkit through a set of con-straints, called consistency rules. A consistency ruledenes how elements in dierent documents are inter-related. Figure 1 gives an example of a consistency rule(using xlinkit's XML rule syntax) that prescribes thatinterfaces that inherit from \EJBObject" must be im-plemented by a class that inherits from \EntityBean"or \SessionBean".xlinkit returns as its output a set of links that connectinconsistent elements in document. This is an improve-ment on the boolean evaluation of rst order formulaebecause the links pinpoint precisely the combination ofelements that causes the inconsistency. Figure 2 showsa link generated by evaluating the sample rule. In thiscase, the link points to only one location, the interfacefor which no corresponding class was found.3 Consistency ManagementConsistency management, the problem of detecting, as-sessing and potentially resolving inconsistency, is a deli-cate topic that is subject to a variety of inuences, fromdomain specic ways of accomplishing goals, down toindividual working preferences. Having provided a so-phisticated system for detecting inconsistency, our goalis to specify a very basic, rudimentary mechanism forreporting inconsistencies and for making simple changesin order to remove inconsistencies. Once such a basicmechanism is in place, it can form the infrastructure fora more elaborate consistency management or conictresolution process that can take into account informa-tion such as workow, or policies that set priorities fordierent kinds of specications to enable overriding.On a very abstract level, we expect a consistency man-1<forall var="i" in="/java/interface[extends/@name='EJBObject']"><exists var="c" in="/java/class[../package/@name=$i/../package/@nameand (implements/@name='EntityBean' orimplements/@name='SessionBean')]"/></forall>Figure 1: Sample xlinkit consistency rule<xlinkit:ConsistencyLink ruleid="javaejb_inter.xml#id('r2')"><xlinkit:State>inconsistent</xlinkit:State><xlinkit:Locatorxlink:href="Job.java#/java/interface"/></xlinkit:LinkBase>Figure 2: Sample consistency linkEditCheckRepairReportFigure 3: Consistency management processagement process to look like Figure 3. Developers willdecide to assess the consistency of their documents,make a check, get reports back, and either decide onan action for \repairing" the documents, or defer thedecision and go back to editing. We have already ad-dressed the checking process, and will concentrate onreport generation and repair in the next two sections.4 Report Generationxlinkit's linking diagnostics, which connect inconsistentelements in distributed specications and deliver themin the form of an XLink [1] linkbase, are powerful butnot particularly friendly for human consumption. Wehave developed a report generation tool, Pulitzer, thatcan read such linkbases and display marked up infor-mation about the elements that the locators point to.Using Pulitzer it is possible to provide reports similarto traditional compiler error output | but at the inter-viewpoint level! | in a variety of formats. Figure 4shows an HTML report generated after checking an EJBsystem.5 RepairWhen elements in distributed specications have beenlinked and identied as inconsistent, it should be possi-ble to oer some simple repair choices to developers. Asan example, in our sample rule given above we have aninconsistency because for some Java interface we did notnd a correct implementation. In this case, we could of-fer the developer to automatically introduce a new Javaclass that fullls the requirements.In general, it is straightforward to enumerate the repairoptions available to developers. One case add elementsto specications, delete elements, and change proper-ties of elements. When adding or changing elements,one can let developers enter values for the properties ofelements, search the specications for existing values touse, or fall back to defaults.The challenging task is then not to enumerate repairoptions but to prune them in order to leave only \sen-sible" choices. In our sample rule, we could removethe inconsistency by deleting the oending Java inter-face | although in most cases this would be attackingthe symptom instead of the problem, and would notbe a sensible choice. We believe that the developersresponsible for establishing the constraints should beable to determine which repair actions make no sense.We are planning to analyse the formulae so as to comeup with an exhaustive list of actions and presenting asimple interface for pruning them down.Should this kind of pruning process still result in anoverwhelming number of repair choices, domain specicheuristics can be used to cut them down further. Forexample, it may be possible in a software engineeringsetting to use a \dierential" approach that comparesthe consistency status of specications before and afterthe last consistency check, and uses this information todetermine more precisely which elements may have to2Figure 4: Sample reportbe changed. Whether this approach works or not, byproviding an enumeration of the repair choices based onformula analysis, we will establish a sound infrastruc-ture on top of which such heuristics can be built.6 ScalabilityScalability problems occur in various guises in consis-tency management. A good system must be able toscale as the number of documents and constraints in-creases, and as the size of documents increases. It mustalso be scalable in terms of user-friendliness, by provid-ing mechanisms that simplify the expression of a largenumber of constraints.We are currently working to address the problems ofchecking large documents and large numbers of doc-uments through a variety of means: by providing in-cremental checks, which analyse changes to documentsand minimize the number of constraints that have to berechecked; by implementing a distributed supervisor {worker architecture that can deal with large amounts ofdata; and by using the caching facilities of native XMLdatabases to lower the main memory requirements ofour service. Substantial progress has been made in theseareas.We have also implemented a macro mechanism and apredicate plugin mechanism for our formula languagethat greatly facilitate the expression of a large numberof constraints. We are currently evaluating these fea-tures in case studies.7 ConclusionWe have outlined our current position with regard toachieving a system for managing the consistency of dis-tributed specications. xlinkit takes a big step in thisdirection by providing a solid base for checking the con-sistency of distributed, heterogeneous documents.We are now working to establish a simple method forsuggesting repair options to developers, without com-promising our view of inconsistency as something thatcannot necessarily be eliminated. We are also evaluat-ing our tools for dealing with scalability problems thatarise as documents sizes and the number of documentsgrow.References[1] S. DeRose, E. Maler, and D. Orchard. XML LinkingLanguage (XLink) Version 1.0. W3C Recommen-dation http://www.w3.org/TR/xlink/, World WideWeb Consortium, June 2001.[2] C. Nentwich, L. Capra, W. Emmerich, andA. Finkelstein. xlinkit: a Consistency Checking andSmart Link Generation Service. ACM Transactionson Internet Technology, 2001. To appear.[3] C. Nentwich, W. Emmerich, and A. Finkelstein.Flexible Consistency Checking. Research note, Uni-versity College London, Dept. of Computer Science,2001. Submitted for Publication.3

English

Flexible Consistency Checking. Research note,

xlinkit: a Consistency Checking and Smart Link Generation Service.

XML Linking Language (XLink) Version 1.0. W3C Recommendation http://www.w3.org/TR/xlink/, World Wide Web Consortium,

Edit, compile, debug: from hacking to distributed engineering

Abstract

Similar works

Full text

Available Versions

City Research Online

UCL Discovery