A Description Model for Software Evolution Services

Jan Jelschen, Johannes Meier, Marie-Christin Ostendorp, Andreas WinterCarl von Ossietzky Universität Oldenburg, Germany

{jelschen, meier, ostendorp, winter}@se.uni-oldenburg.de

Abstract—Software evolution encompasses a widevariety of activities to analyze, reverse engineer, trans-form, and visualize software systems, requiring prop-erly integrated tool support. Many tools are available,however, most implement only a single technique, andoffer little to no interoperability. Towards a service-oriented integration approach, this paper presents aservice description model, developed along two casestudies, as a basis for cataloging and standardizingactivities and techniques as services. As proof-of-concept, a prototype has been implemented, realizingone of the case studies.

Keywords—Software Evolution, Tool Interoper-ability, Service-Orientation

I. INTRODUCTIONSoftware systems continue to evolve after

their initial deployment. Over time, thesesystems “erode”, and become harder to main-tain, yet often embody a substantial businessvalue for their owning companies. Therefore,effort has to be spent on keeping softwaresystems evolvable.

To this end, software evolution offers ac-tivities and associated techniques to analyze,reverse engineer, transform, and visualizesoftware systems. Due to the large size ofindustry-scale software systems, these activi-ties have to be tool-supported to be feasible.There are many tools available, however,most implement only a single technique, andoffer little to no means for interoperability.Most tool suites, which combine several tech-niques (e.g. Bauhaus [1]), focus on activitiesfor program comprehension only, and offerno means for project-specific tailoring.

Borchers [2] observes that a largeamount of the tool infrastructure is project-independent, yet goal-specific tailoring isalways necessary, as well. Building suchtoolchains requires hand-written “glue logic”and ad-hoc functionality (e.g. to transformdata formats, or make control flow deci-sions), which yields tightly-coupled tools,little reusability, and inflexible projects. Ide-ally, software evolution practitioners should

be enabled to focus on their project-specificgoals and activities as much as possible, andnot having to consider tool integration issues.

To facilitate this, software evolution activ-ities have to be described on a high level,to abstract from concrete implementations,focus on specifying required functionalities,and standardize them. The approach pur-sued by the authors is based on taking aservice-oriented view to model and decom-pose software evolution activities on a con-ceptual, implementation-agnostic level, andsubsequently fill a catalog of software evo-lution services, which can serve as the basisfor a component-based framework to largelyautomate integration. Envisioned is a solutionto allow practitioners to model only theirproject’s workflows in terms of required ser-vices and their coordination, and generate anintegrated solution by mapping services toconcrete implementations which abide by theservices’ specifications.

In this paper, a description model for soft-ware evolution services is developed alongtwo case studies, modeling the activitiesof architecture reconstruction and softwaremeasurement as services, to identify the in-formation required to comprehensively spec-ify and catalog services. A service modelof software measurement was created, and aprototypical realization using existing com-ponents was implemented for validation.

The remainder of this paper is outlinedas follows: Section II presents the generalidea of using a service-oriented approach tosoftware evolution tool interoperability, andSection III discusses related work. Section IVintroduces the case studies, and requirementsderived from them. The service descriptionmodel based on them is introduced in Sec-tion V. Section VI describes the proof-of-concept implementation of the software mea-surement case study. The paper closes witha summary and an outlook in Section VII.

II. SERVICE-ORIENTED TOOLINTEROPERABILITY

In this paper, a service-oriented view to-wards tool interoperability is taken. The coreidea is to identify software evolution activ-ities and the techniques and tools used tocarry them out, and to lift them onto the ab-stract, generic, and implementation-agnostic,yet rigid functional description level of ser-vices. This leads to a software evolutionservice catalog, serving as taxonomy of thefield, as reference for standardized interfaces,and by extension, as basis for an automatedtool integration framework.

The approach is referred to as SENSEI(Software EvolutioN SErvices Integration),and embodies the following vision: A ser-vice catalog, containing abstract, generic, yetrigorous descriptions of software evolutionservices, is used to pick the services requiredto support the project’s activities and achieveits goals. A service orchestration is modeled,defining how the selected services are coor-dinated to interact with each other. A compo-nent registry provides a mapping between ab-stract services and concrete implementationsby tools. These are encapsulated in, or devel-oped as, components, conforming to the com-ponent model of an underlying framework.A set of model transformations embodiesthe mapping to a specific implementationtechnology. With all these artifacts, a model-driven code generator produces the requiredplatform-specific code which realizes toolintegration.

The final result is a set of tools integratedinto an application framework able to executethe specified software evolution processes.

SENSEI is based on concepts from ser-vice-oriented, component-based, and model-driven software engineering paradigms. Inparticular, there is a clear and importantdistinction to be made between abstract ser-vices, which only contain a specification ofa functionality with standardized interfaces,and components, which provide actual im-plementations and conform to the realizedservices’ interfaces.

III. RELATED WORKA project which shares several ideas with

SENSEI is SOFAS [3]. It also introducesservices, although here, the term is closelyrelated to the implementation technology,namely RESTful web services. Similar toSENSEI, it aims at integrating tools by or-chestrating services into workflows. It fur-ther shares the concepts of a composer toenact orchestrations, and a service catalogwith SENSEI. The approach is restricted tosoftware analysis activities, which is explic-itly exploited by making assumptions abouttheir uniformity. It is focused on the actualframework and the services it can provide,and less on providing a generic, technology-independent concept as SENSEI is.

SENSORIA [4] was a large researchproject running for five years until 2010,aimed at creating a comprehensive softwareengineering approach for software systemsbased on service-oriented architecture. It de-veloped many concepts for service-orientedengineering, one being the model-driven gen-eration of integrated software systems fromhigher-level descriptions like BPEL-based or-chestrations [3]. The project was neither fo-cused on software evolution, nor was toolinteroperability its central concern, though.

Similar ideas lie at the core of work byKraemer et al. [5], [6], who also aim toautomate the mapping of orchestrations toexecutable code, and closing the gap be-tween high-level, process-oriented modelingand the implementation level, using model-driven techniques. Their approach involvestransforming an orchestration as a UML ac-tivity diagram into a UML state machine, asan intermediate step to generate code.

Another approach for model-driven toolintegration, aimed at software developmenttoolchains, is ModelBus [7], and the relatedreference technology platform defined in theCESAR project [8]. Its use cases are the in-tegration of tools like requirements manage-ment software, integrated development envi-ronments, software modeling tools, etc.

Also in the domain of integrating soft-ware development tools are the works byBiehl et al. [9]. It is similar to SENSEI in

several regards, e.g. it is based on servicesand their orchestration (using their domain-specific tool integration language TIL), andmodel-driven techniques to derive executabletoolchains, for which they also chose SCA astarget platform (compare Section VI). Theyaddress a different domain, with use casesfrom embedded software development. Dis-covery and description of relevant services,their cataloging and their standardization isnot addressed.

In summary, approaches for tool integra-tion in domains other than software evolutiondo exist, and are in part built around similarideas as SENSEI. These ideas, e.g. usingservices and their orchestration as high-leveldescriptions, and model-driven techniquesto derive (component-based) toolchains havetherefore been proven practical means fortool interoperability. However, these ap-proaches have been tailored for different ap-plication domains. The approaches knownto the authors explicitly addressing softwareevolution are less generic than SENSEI, ordo not cover the whole field. Moreover, nostandardization of services is offered, suchthat implementations of conceptually equalservices will still be incompatible, impedingreuse and the flexibility, e.g. to exchangeone implementation for another without anychanges to the integration logic. To achievethis level of interoperability, SENSEI aims toestablish a catalog of software evolution ser-vices, including a seamless approach to theorchestration of appropriate implementations.

IV. CASE STUDIESTo develop and refine the service descrip-

tion model needed to capture all relevantinformation of a catalog of software evolu-tion services, and an integration frameworkbased thereon, two case studies have beenconducted, aimed at identifying services andthe kind of information needed to fully de-scribe them.

Each case study analyses a well-established software evolution activity:architecture reconstruction, and softwaremeasurement, respectively. A literaturesurvey was performed to discover differentvariants, derive a generic process describing

the activity, and to identify sub-activities.The software evolution activity was thenmodeled in terms of services, starting outwith a basic description model focusedon services’ inputs, outputs, and possibledecomposition.

As guidance, two different modeling per-spectives were considered:

Software Evolution Activity as a Ser-vice. This is an outside view of a service.It is concerned with the service’s interface(its expected inputs, provided outputs, andutilized data structures) and its semantics.It contains the information expected to befound in the service catalog.

Services for Software Evolution Activi-ties. This is an inside view of service. Whileit does not make any implementation-specificassumptions, it does describe a service on aprocess-oriented level in terms of used sub-services. Its consideration therefore helps toidentify the services relevant to the activity.It contains the information expected in ageneric service orchestration.

New requirements for the service descrip-tion model were derived from issues whicharose while modeling the case studies’ ac-tivities. Primarily these features deal withproviding more flexibility in service orches-tration. These requirements, in turn, havebeen the basis for the design of the de-scription model. In the following, the casestudies on modeling architecture reconstruc-tion (Section IV-A) and software measure-ment (Section IV-B) as services are brieflypresented. Next, the resulting requirementsare described (Section IV-C).

A. Architecture ReconstructionEvolving software systems are subject

to continuous change. Modifications to bemade to account for changing requirementsor system environment often clash with theexisting structure, and erode it over time.Documentation often becomes outdated orgets lost, so that the system’s architecturehas to be reconstructed out of the underlyingsource code. This aspect can be realized withclustering algorithms, on which this casestudy is focused. An architecture reconstruc-tion taxonomy by Ducasse and Pollet [10]

extracted

data

Selection Algorithm

Similarity

Measure

clustered

data

Selection

transform transformed

data

Clustering

Execution

metric querying

source

code

parser

visuali-

zation data flow

usage

service

artifact

Figure 1: Services for architecture reconstruction.

In Out

Algorithm

input data (to beclustered), cut-point, similaritymeasure

clustereddata

SimilarityMeasure

input datacalculatedsimilarityvalues

ClusteringExecutionService

algorithm, simi-larity measure

clustereddata

Figure 2: Inputs and outputs of services forarchitecture reconstruction (Wiggerts [16]).

names several alternative techniques. Cluster-ing algorithms group similar entities such asclasses or methods into clusters. A similaritymeasure determines the closeness of entities.

There are many different clustering algo-rithms and tools in literature: Well-knownalgorithms and tools are MoJo presentedby Tzerpos et. al [11], Bunch by Mitchelland Mancoridis [12], Craft introduced byMitchell et al. [13] to evaluate clusteringalgorithms, ACDC by Tzerpos et al. [14],and one of the most recent tools is SCuVpublished by Xu et al. [15]. For maximumflexibility, it is desirable to have a clusteringservice able to work with different clusteringalgorithms and input data formats.

A possible way to realize such a ser-vice reusing pre-existing services is shownin Figure 1. In an initial step, a parserextracts information from source code andstores entities and their relationships in adata format suitable for further calculations.

The first step in the clustering service itselfis to select a proper clustering algorithmand similarity measure, since both affect thequality of the clustering result [17]. Dueto the fact that this is not a trivial task,selection services offer a meaningful support:They embody a selection approach for clus-tering algorithms as, for example, presentedby Shtern and Tzerpos [18]. After choosingthe algorithm and a similarity measure, atransformation of the extracted data into theinput data format of the chosen algorithmhas to be done. Providing these selectionservices allows for more scalability of servicerealization regarding efficiency and precision.A possible transformation can be chosen atruntime. The transformed data is transferredto the clustering execution service, where itcan be decomposed into clusters by executingthe algorithm and similarity measure chosenpreviously. This service may utilize furthersub-services, like metrics and querying toevaluate properties of clustering entities, orthe chosen similarity measure. In the end, theclustered data is visualized using an existingvisualization service.

Based on a classification by Wig-gerts [16], the input and output parametersdepicted in Figure 2 have to be specifiedin the service catalog for the new services.Modeled this way, the clustering service isable to realize all existing clustering algo-rithms and to execute them with differentinput data formats.

B. Software MeasurementDuring the software development and evo-

lution process, it is difficult to evaluate the

input

model transform target

model input parser

findQuery query

code

query

result querying

metric findTarget

input

Figure 3: Services for software measurement.

quality and quantities of software artifacts toguarantee the quality of the whole softwareproduct, including the development processitself. Software metrics provide considerablehelp to measure the quality and quantity ofsoftware artifacts, and aid in program com-prehension and directing further evolutionof the software. The IEEE defines a metricas “A function whose inputs are softwaredata and whose output is a single numericalvalue that can be interpreted as the degreeto which software possesses a given attributethat affects its quality” [19].

The input depends on the current soft-ware development phase. During analysis itis important to measure the quality of agiven requirement specification or other doc-umentation, whereas during implementationit is more significant to determine the qualityof the source code. Possible input data formetrics are therefore documentation as wellas source code. The wide range of possibleinput data formats can be seen in the classi-fication of Fenton and Pfleeger [20].

This aspect means that a metrics servicehas to be flexible concerning the input datastructure. Nevertheless, it is significant tohave a uniform service for the calculation ofsoftware metrics, due to the fact that softwaremeasurement affects all phases of softwaredevelopment, and thereby affects various de-velopers and employees with different skills.Having a uniform service eases the skilladaption to new metrics.

An approach to realize software measure-ment using services is depicted in Figure 3.The metric service needs two inputs: Themetric, and the input to measure it on. Asa first step, a parser extracts the input datainto a format that can be used for furthercalculations. Due to the fact that the in-put format can be documentation as well

as source code, or other resources of thesoftware project, an appropriate parser hasto be chosen. Therefore, the input has toprovide information about the grammar andthe format of the input – for example inform of a meta-model. The parser providesthe input model that can be used for furthercalculations.

Metrics cannot always work directly onthe data provided by a parser, e.g. McCabe’scyclomatic complexity [21] is defined overcontrol-flow graphs. In these cases, a trans-formation has to be executed to get the targetmodel as input for the metric calculation.A way to resolve to an appropriate trans-formation service from the required inputdata structure of the chosen metric has tobe found. Here, this is represented by thefindTarget service.

The querying service queries the targetmodel to get the value of the chosen metric.Again, a means to resolve metric names tosuitable query expressions has to be pro-vided. This lookup is represented by thefindQuery service. After this step, the chosenquery code can be executed with the helpof the querying service on the target modelto deliver the query result as result of thesoftware measurement.

C. RequirementsThe case studies have been used to dis-

cover requirements for a service descriptionmodel. In the following, observations regard-ing needed structures to properly model soft-ware evolution services, and recurring mod-eling patterns are described. Each paragraphis summarized by a requirement, which inturn forms the basis of the service descriptionmodel subsequently designed (Section V).

1) Service Hierarchy: Besides the devel-opment of the service description model,which determines what kind of information

goes into the service catalog, and how it isstructured, another major goal of the casestudies was the discovery of relevant (sub)-services (to actually fill the catalog). Thishas been done by breaking down the mainsoftware evolution activities under study intothe steps to be taken to perform them, anddescribe them as services, as well. Decom-posing services into sub-services revealed,for example, services central to softwaremeasurement, namely metrics and querying,can be reused for architecture reconstruction.

Furthermore, including this hierarchicalinformation in the service catalog is usefulto organize it, and help catalog users findthe right services for their tasks. Modelingservices hierarchically also facilitates infor-mation hiding to handle complex services.→ The service description model must pro-vide a means to arrange services in a decom-position hierarchy based on service usagerelations. (1)

2) Service Variability: In both case stud-ies, services have been modeled in a ratherabstract fashion. For example, both case stud-ies require a parser service, which is whatone would be looking for in a service catalog.In a given usage scenario, however, a specificparser, capable of parsing source code inthe programming language(s) of the systemunder study is needed. As another example,consider the metric service from the softwaremeasurement case study, which has two such“degrees of freedom”: one determines whichmetrics it should be able to calculate (asit cannot be expected that all implementa-tions support every possible metric there is),the other what data structures it is able toprocess. There is also an interdependencybetween the two, since metrics are definedover certain data structures.→ The service description model must pro-vide a means to model abstract services, andto describe all possible instances. (2)

3) Data Abstraction Level: As a conse-quence of the different service abstractionlevels required, it must also be possible tomodel input and output data accordingly. Forexample, for the generic parser service, theinput data structure is source code, and the

output data structure an abstract syntax tree(AST). On this level, both data structurescannot be described in much more detail thanthis. If a usage scenario is given, though, i.e.it is known that the parser must support theJava programming language as input, thenthe input data structure is known to be con-forming to the Java language specification,and an appropriate Java meta model can bedefined for the resulting AST.→ The service description model must pro-vide a means to model data structures, ar-range them in specialization / generalizationhierarchies, and establish relationships be-tween service instances and corresponding,specialized data structures. (3)

4) Higher-Order Services: In the archi-tecture reconstruction case study, it proveduseful to be able to delay service resolutionuntil runtime: Here, the actual clustering al-gorithm is selected based on requirementsof the specific task at hand, and passedas an argument to the clustering executionservice. Assuming the algorithm itself is alsorepresented as a service, this would make theclustering execution service a higher-orderservice (in analogy to higher-order functions,which take functions as arguments). The al-gorithm cannot be chosen completely auto-matically, requiring a corresponding input tothe clustering execution service. The selec-tion of an appropriate algorithm can be tool-supported, though (in the case study e.g. byimplementing the selection process proposedby Shtern and Tzerpos [18]), leading to theidentification of selection services.

In a similar fashion, the findTarget serviceidentified in the software measurement casestudy has to instantiate the generic transfor-mation service with a concrete one at run-time, based on inputs. The findQuery serviceis modeled more simply, only looking up datato parameterize the querying service.→ The service description model must pro-vide a means to delay service resolution untilruntime. (4)

5) Service Types: Both case studiesshowed that, besides services stemming fromthe problem domain, e.g. clustering for archi-tecture reconstruction, a need for additional

Figure 4: The service description model.

services arose for purely technical reasons,e.g. data transformation services. This is con-sidered an important distinction: technical is-sues should be hidden from the orchestrationdesigner, who is tasked with designing theworkflows of his software evolution projectto have them tool-supported, as much aspossible. A tool builder, who is concernedwith implementing a service in a component,might be more interested in technical sub-services he might be able to utilize. In thisregard, a distinction between these differenttypes of services helps to organize the servicecatalog. Another reason to differentiate alongthese lines is reusability: mixing in technicalaspects into a domain-specific service makesit hard to reuse, while the technical part can-not be reused independently, at all (cmp. soft-ware “blood types” by Siedersleben [22]).

Among the more auxiliary services en-countered, some recurring patterns could beobserved: the most obvious helper servicesare data transformations. Further helper ser-vices are those to resolve to concrete ser-vice instances at runtime, like findQuery. Itmight be desirable to keep such auxiliaryfunctionality hidden away from practitioners,and have the integration framework take careof these aspects automatically, if possible.

→ The service description model must pro-vide a means to classify different types ofservices. (5)

V. SERVICE DESCRIPTION MODELBased on the requirements from the

case studies, and in continuation of previ-ous work [23], a service description modelwas designed, to capture all interoperability-relevant properties of software evolution ser-vices. The model is depicted in Figure 4.It can be explained from three viewpoints,each explained in the following: the servicecatalog viewpoint (Section V-A), the ser-vice orchestration viewpoint (Section V-B),and the component mapping viewpoint (Sec-tion V-C). An approach taking artifacts fromall three viewpoints and automatically de-riving a toolchain integration solution isbriefly sketched, as well (Section V-D).The software measurement case study hasbeen modeled according to the newly devel-oped model, and serves as ongoing example.Based on this model, a prototypical integra-tion solution has been realized (Section VI).

A. Service CatalogThis viewpoint describes services as listed

in a service catalog, and therefore roughlycorresponds to the “as-a-service” perspec-tive. Each artifact of this viewpoint is anentry in the service catalog. The table inFigure 5 depicts a simplified example, listinga brief description of the service’s semantics,type, input and output data structures, capa-bility classes, and constraints (see below).

To keep the catalog clear and uncluttered(Requirement 2), these services ought to be

generic, e.g. by having a single service Cal-culateMetric, instead of one service for eachpossible combination of supported metricsand programming languages. To this end,each Service may define several Capability-Classes, describing variation points alongwhich concrete manifestations may differ.In the aforementioned example, this wouldbe the sets of supported metrics and pro-gramming languages, respectively. A capa-bility class aggregates a set of capabilities,and is defined with all possible elementsin the service catalog. The capability classprogramming language, for example, wouldcontain Java, C++, COBOL, and so on.

The capability approach implies a require-ment for a corresponding mechanism on datastructures (Requirement 3). Data structurescan therefore form generalization hierarchies,and be marked abstract (requiring a non-abstract subtype at runtime). This way, anabstract AST data structure can be specializedto a JavaAST or a COBOL_AST, essentiallyintroducing polymorphism. Notice that thereare usually direct interdependencies betweenthe actual data structures which are handledby a service instance, and its required ca-pabilities. Services therefore have to spec-ify how a service instance’s capabilities de-termine its concrete input and output datastructures, using constraints. In the examplein Figure 5, they express the correspondencebetween ProgrammingLanguage capabilitiesand input data structures, and that instancesof the CalculateMetric service can only cal-culate those metrics for which they possessthe corresponding capability. A capabilityclass with a prime (′) indicates a referenceto a specific subset chosen at design time,as opposed to the whole capability classcontaining all possible capabilities.

To fulfill Requirement 5 and distinguishbetween different kinds of services, they havea ServiceType, based on the way they areused (cmp. Siedersleben [22], or Cohen [24]for similar classification schemes): Activityservices embody a software evolution activ-ity, e.g. architecture reconstruction or soft-ware measurement, and are always aimed ata specific goal. Technical services realize and

CalculateMetricDescription Calculates a metric (pro-

vided by its name) oversource code and returns theresult as a single real num-ber.

Type Activity

Input code : SourceCodemetric : MetricEnum

Output result : RealCapabilityClasses

ProgrammingLanguageAvailableMetrics

Constraints∀x: x ∈ AvailableMetrics′ ⇐ metric = xJava ∈ ProgrammingLanguage′ ⇐

typeOf(code) = JavaCodeCOBOL ∈ ProgrammingLanguage′ ⇐

typeOf(code) = COBOLCode

Figure 5: CalculateMetric as a service.

support activities, and are possibly applica-ble to different ends, but are not directlyuseful on their own. For example, formalconcept analysis is an alternative techniqueto be used for architecture reconstruction inplace of clustering [10]. However, neithertechnique would usually be performed as anend in itself, but rather in the context ofa concrete, goal-oriented activity. An evenmore primitive form are auxiliary services,which are only necessary for integration pur-poses, e.g. resolving concrete services (andcorresponding components) based on inputdata at runtime, like the findQuery service ofthe software measurement case study does.Auxiliary services are simple by nature, andmight not require dedicated components im-plementing them, but rather have the nec-essary logic be created as required by anautomated integration framework. The tasksof auxiliary services can be modeled declar-atively as constraints, keeping orchestrationsclean from integration-related concerns.

B. Service OrchestrationThis viewpoint captures the artifacts

which are created when orchestrating ser-vices, i.e. coordinating existing services towork together to support a specific softwareevolution activity (“services-for” perspec-

Figure 6: Orchestration of service instances to calculate several COBOL and Java metrics.

tive), and thereby forming a more complexservice. The central concept of this viewpointis ServiceInstance: it represents a service in aconcrete usage scenario, with only a subset ofall possible capabilities of the generic catalogservice. Service instances are orchestratedusing an appropriate orchestration (process,workflow) description language, or a subsetthereof, e.g. UML Activities, BPMN [25],BPEL [26], or YAWL [27]. These languagesprovide concepts like data flows, decisionnodes, etc. which have not been incorporatedin the model in Figure 4.

Each artifact of this viewpoint is an or-chestration of service instances, a high-leveldescription of a software evolution activityto be tool-supported. Figure 6 shows an ex-ample of an orchestration for the Calculate-Metric service using an UML activity di-agram, extended by small dark squares todepict capability classes. Here, the capabilityclasses have been subset to have this serviceinstance support calculating McCabe, Hal-stead, and a “methods-per-class” (MPC) met-ric on Java and COBOL code. There are morecapabilities to be set on the sub-services,however, except for the QueryLanguage,which has been fixed to GReQL [30], theycan be derived from the outer service’s capa-bilities. Constraints can be used to expresstheir relationships. Also, this orchestrationcontains no auxiliary services, as opposedto the initial model of the software mea-surement case study (findTarget, findQuery).Constraints can be used in their stead, pro-viding a solution to Requirement 4. Thefollowing constraint is an example excerptof a constraint on the service orchestrationlevel to derive a concrete query expres-sion from capabilities (the chosen Query-

Language: GReQL) and runtime data (thechosen metric: McCabe):

1 C a l c u l a t e M e t r i c . m e t r i c = " McCabe "2 ∧ GReQL ∈ Query . QueryLanguage ⇒3 Query . que ry =4 " c o u n t ( E{ Con t ro lF low } ) −5 c o u n t (V{ B a s i c B l o c k } ) +6 c o u n t (V{ P r o c e d u r e } ) * 2"

Decomposition of services into sub-services (Requirement 1) is also viewed atthe orchestration level. To support this inthe description model, the composite pat-tern [28] has been applied over class Service(in, by analogy, over class Component). Thecomposition is based on service usage: acomplex service is decomposed into thosesub-services it can use to realize its func-tionality. On the service catalog level, thisis a purely hypothetical relationship, servinge.g. as a hint for tool developers whichservices might useful when implementing acomplex service instance. A tool developermight still choose to ignore this, and realizea service instance monolithically. Lookingat the orchestration viewpoint, the relation-ship is visible, as an orchestration showsall service instances it is using. However,whether a used service instance is realizedby a single, monolithic component, or canbe decomposed itself into more basic sub-services, can be handled completely transpar-ent. The other way around, orchestrations canalso be seen as establishing more complex,composite service instances from more basicones. By generalizing from service instancesback to services, such services can then beplaced in the service catalog again.

C. Component MappingThis viewpoint associates service in-

stances with actual implementations in the

form of Components. Like services, com-ponents can be hierarchically decomposedinto AtomicComponents and more complexCompositeComponents. As components can-not be expected to realize the generic ref-erence services of the catalog directly, i.e.supporting all possible capabilities, the map-ping is done by having a component refer-ence one or more service instances, whichrepresent provided services, and the extendto which they are realized. Notice that thisviewpoint does not model actual components,but references them to establish the mappingto services.

Each artifact of this viewpoint is an entryin a registry, recording a mapping between aconcrete component (containing a tool), con-forming to a specific component framework,and a service instance, representing the im-plemented service and supported capabilities.

D. Toolchain IntegrationUsing an artifact from each viewpoint

– a service orchestration modeling the de-sired workflow to be tool-supported, a ser-vice catalog containing the definitions ofthe services used, and a component registry,providing mappings to implementations forthose services – the creation of an appropriatetoolchain can be automated. This can bedone using model transformations to realizea code generator. It requires two sets oftransformations: one to map to a specificintegration platform, e.g. a component frame-work like Service Component Architecture(SCA) [29], and another one to derive datatypes from data structures by selecting anappropriate data representation technology,e.g. TGraphs [30], SDO [31], or EMF [32].

A component registry is assumed to onlycontain components conforming to the sameframework for this to work. The data rep-resentation may vary, though. Requiring allcomponents to use the same data representa-tion technology might be too constraining,especially for integrating already existingtools. Encapsulating such tools in a simplecomponent wrapper is comparatively easy,while changing the data representation wouldeither require to have tools adapted internally,or to use data format transformations. Such

transformations are best kept separate fromcomponents for reusability.

The output of the code generator is anapplication conforming to the selected inte-gration platform, containing all the requiredcomponents implementing service instancesused in the orchestration, plus one additionalcomponent, called a composer, which is re-sponsible for enacting the orchestration.

VI. VALIDATIONAs a proof-of-concept, the Calculate-

Metric service, as orchestrated in Figure 6,has been realized based on Apache Tuscany’sService Component Architecture (SCA) im-plementation [33]. SCA-conforming compo-nents were implemented for all the utilizedsub-services, and mapped, appropriately:ParseComponent implements the Parser ser-vice, TransformComponent the Transforma-tor service, and QueryComponent the Queryservice. Parsers by pro et con for COBOLand Java [34] were used, JGraLab’s [30]GReQL facilities provided querying, aswell as data representation in the form ofTGraphs. Rudimentary transformations im-plemented previously [35] were used to cre-ate control flow graphs from abstract syntaxtrees of COBOL and Java programs. Forthis prototype, no automatic code genera-tion was used, yet. Instead the job of themodel-driven code generator has been carriedout manually, i.e. a composer component(MetricComponent) to enact the orchestrationas designed, as well as all the necessary SCAconfiguration artifacts, were written by hand.There is also a FindQueryComponent, whichimplements the lookup of queries for metrics,derived from corresponding constraints.

Figure 7 depicts a screenshot of the pro-totype project, opened in the developmentenvironment. To the left, the package ex-plorer lists the service interfaces and classesimplementing the components. In the cen-ter, a visualization of an SCA compositefile is shown, which wires up componentswith their dependencies – here, the Metric-Component in its role as composer is de-pendent on all other services, to be ableto invoke them and pass data along. Theright-hand side shows a code snippet of the

Figure 7: Screenshot of the prototype viewed in an IDE, showing wired-up SCAcomponents, and a code snippet from the implementation.

MetricComponent’s implementation. In thepane at the bottom, the tail of the output ofa test run can be seen, reporting a McCabevalue of 6 for a Java test application.

The prototype works and shows that SCAis a viable target platform. While imple-menting, attention was paid to only derivethe hand-written logic from the service-levelartifacts created according to the model.

VII. CONCLUSIONThis paper presented two case studies to

model software evolution activities as ser-vices, and the description model derived fromit, as a step towards the SENSEI-catalog ofsoftware evolution services for tool interop-erability. A basic method has been devised toconduct the case studies. It is based on twodifferent perspectives on software evolutionactivities – viewing them as a service, andlooking at services for them. The case studiesare further guided by the goals of servicereusability, interoperability, and automationof tool integration. While the main goal herewas to elicit requirements and derive a ser-vice description model, the same method canbe applied to discover and describe furtherservices to fill the catalog.

The central contribution of this paper isthe developed service description model. Itenables the creation of a catalog of softwareevolution services, aimed at providing stan-dardized service interfaces for software evo-

lution activities and techniques, and servingas basis for the implementation of a tool inte-gration framework. The description model in-troduces service capabilities, which enable ageneric description of services, while allow-ing practitioners to designate their specificrequired capabilities for a given project’stool support, and tools to specify providedcapabilities. Constraints on these capabilitiescan be used to model their interdependencies,and relations with services’ data structuresin a declarative way. This facilitates therealization of a framework automating toolintegration by mapping service orchestrationsto concrete components, and resolving theassociated constraints to wire them up.

REFERENCES

[1] A. Raza, G. Vogel, and E. Plödereder,“Bauhaus–a tool suite for program analysisand reverse engineering,” in Reliable SoftwareTechnologies – Ada Europe 2006, LNCS 4006.Berlin, Heidelberg: Springer, 2006, pp. 71–82.

[2] J. Borchers, “Erfahrungen mit dem Einsatzeiner Reengineering Factory in einem großenUmstellungsprojekt,” HMD Themenheft Migra-tion, vol. 34, no. 194, pp. 77–94, Mar. 1997.

[3] G. Ghezzi and H. C. Gall, “A frameworkfor semi-automated software evolutionanalysis composition,” Automated SoftwareEngineering, vol. 20(3), pp. 463–496, 2013.

[4] M. Wirsing and M. Hölzl, Eds., Rigorous Soft-ware Engineering for Service-Oriented Sys-tems, LNCS. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2011, vol. 6582.

[5] F. A. Kraemer and P. Herrmann, “TransformingCollaborative Service Specifications into

Efficiently Executable State Machines,” EASST,vol. 6, 2007.

[6] F. A. Kraemer, H. Samset, and R. Braek,“An Automated Method for Web ServiceOrchestration Based on Reusable BuildingBlocks,” in IEEE International Conference onWeb Services. 2009, pp. 262–270.

[7] C. Hein, T. Ritter, and M. Wagner, “Model-driven tool integration with modelbus,” inWorkshop Future Trends of Model-Driven De-velopment, 2009.

[8] E. Armengaud, M. Zoier, and A. Baumgart,“Model-based toolchain for the efficientdevelopment of safety-relevant automotiveembedded systems,” SAE World Congress& Exhibition, 2011.

[9] M. Biehl, J. El-Khoury, F. Loiret, andM. Törngren, “On the modeling and generationof service-oriented tool chains,” Software &Systems Modeling, Sep. 2012.

[10] S. Ducasse and D. Pollet, “Softwarearchitecture reconstruction: A process-orientedtaxonomy,” Software Engineering, IEEE TSE,vol. 35, no. 4, pp. 573–591, 2009.

[11] V. Tzerpos and R. C. Holt, “Mojo: A distancemetric for software clusterings,” in Proceedingsof the Sixth Working Conference on ReverseEngineering. Washington, DC, USA: IEEEComputer Society, 1999.

[12] B. S. Mitchell and S. Mancoridis, “On theautomatic modularization of software systemsusing the bunch tool.” IEEE TSE, vol. 32, no. 3,pp. 193–208, 2006.

[13] B. S. Mitchell and S. Mancoridis, “Craft: Aframework for evaluating software clusteringresults in the absence of benchmark decompo-sitions,” in Proceedings of the Eighth WorkingConference on Reverse Engineering. Washing-ton, DC, USA: IEEE Computer Society, 2001.

[14] V. Tzerpos and R. C. Holt, “ACDC : An al-gorithm for comprehension-driven clustering,”in Proc. of the 7th Working Conf. on ReverseEngineering. IEEE, 2000, pp. 258–267.

[15] X. Xu, S. Huang, Y. Xiao, and W. Wang, “Scuv:a novel software clustering and visualizationtool.” in SPLASH, G. T. Leavens, Ed. ACM,2012, pp. 29–30.

[16] T. A. Wiggerts, “Using clustering algorithmsin legacy systems remodularization.” in WCRE,1997, pp. 33–43.

[17] M. Trifu, “Architecture-aware, adaptive cluster-ing of object-oriented systems,” Master’s the-sis, Forschungszentrum Informatik Karlsruhe,September 2003.

[18] M. Shtern and V. Tzerpos, “Methods for se-lecting and improving software clustering al-gorithms.” in ICPC. IEEE Computer Society,2009, pp. 248–252.

[19] IEEE, “IEEE standard for a softwarequality metrics methodology,” 1998.http://cow.ceng.metu.edu.tr/Courses/downloadcourseFile.php?id=2681

[20] N. E. Fenton and S. L. Pfleeger, SoftwareMetrics: A Rigorous and Practical Approach,

2nd ed. Boston, MA, USA: PWS, 1998.[21] T. McCabe, “A Complexity Measure,” IEEE

TSE, no. 4, pp. 308–320, 1976.[22] J. Siedersleben, Moderne Software-Architektur:

Umsichtig planen, robust bauen mit Quasar.Dpunkt.Verlag GmbH, 2004.

[23] J. Jelschen, “Discovery and Description ofSoftware Evolution Services,” SoftwaretechnikTrends, vol. 33, no. 2, pp. 59–60, May 2013.

[24] S. Cohen, “Ontology and Taxonomy ofServices in a Service-Oriented Architecture,”The Architecture Journal (Online Publication),vol. 11, Apr. 2007. http://msdn.microsoft.com/en-us/architecture/bb410935

[25] “Business Process Model and Notation(BPMN) Version 2.0,” 2011. http://www.omg.org/spec/BPMN/2.0/PDF/

[26] D. Jordan, J. Evdemon, A. Alves, A. Arkin,S. Askary, C. Barreto, B. Bloch, F. Curbera,M. Ford, Y. Goland, A. Guízar, N. Kartha,C. K. Liu, R. Khalaf, D. König, M. Marin,V. Mehta, S. Thatte, D. van der Rijn,P. Yendluri, and A. Yiu, “Web ServicesBusiness Process Execution Language Version2.0,” 2007. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

[27] A. H. M. ter Hofstede, W. M. P. van der Aalst,M. Adams, and N. Russell, Modern BusinessProcess Automation: YAWL and Its SupportEnvironment. Berlin: Springer, 2010.

[28] E. Gamma, R. Helm, R. Johnson, and J. Vlis-sides, Design patterns: elements of reusableobject-oriented software. Addison-Wesley Pro-fessional, 1995.

[29] M. Edwards and M. Chap-man, “Service Component Architec-ture Assembly Technical Committee,”2013. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly

[30] J. Ebert, “Metamodels Taken Seriously: TheTGraph Approach,” in 12th European Conf.on Software Maintenance and Reengineering,K. Kontogiannis, C. Tjortjis, and A. Winter,Eds. IEEE, 2008, pp. 2–2.

[31] R. Barack and F. Budinsky, “Service DataObjects (SDO) Version 3.0 Comittee Draft 02,”2009. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo#technical

[32] D. Steinberg, F. Budinsky, M. Paternostro,and E. Merks, EMF: Eclipse ModelingFramework, ser. The Eclipse Series, E. Gamma,L. Nackman, and John Wiegand, Eds.Addison-Wesley Professional, 2008.

[33] S. Laws, M. Combellack, R. Feng, H. Mahbod,and S. Nash, Tuscany SCA in Action. ManningPublications, 2011.

[34] U. Erdmenger and D. Uhlig, “Ein Translator fürdie COBOL-Java-Migration,” Softwaretechnik-Trends, vol. 31, no. 2, 2011.

[35] J. Jelschen and A. Winter, “A Toolchainfor Metrics-based Comparison of COBOLand Migrated Java Systems,” SoftwaretechnikTrends, vol. 32, no. 2, 2012.