VbTrace: using view-based and model-driven development to ... · process concerns that multiplies...

Softw Syst ModelDOI 10.1007/s10270-009-0137-0

THEME SECTION

VbTrace: using view-based and model-driven developmentto support traceability in process-driven SOAs

Huy Tran · Uwe Zdun · Schahram Dustdar

Received: 15 January 2009 / Revised: 24 September 2009 / Accepted: 6 October 2009© Springer-Verlag 2009

Abstract In process-driven, service-oriented architectures,there are a number of important factors that hinder the trace-ability between design and implementation artifacts. First ofall, there are no explicit links between process design andimplementation languages not only due to the differences ofsyntax and semantics but also the differences of granular-ity. The second factor is the complexity caused by tangledprocess concerns that multiplies the difficulty of analyzingand understanding the trace dependencies. Finally, there isa lack of adequate tool support for establishing and main-taining the trace dependencies between process designs andimplementations. We present in this article a view-based,model-driven traceability approach that tackles these chal-lenges. Our approach supports (semi-)automatically elicitingand (semi-)formalizing trace dependencies among processdevelopment artifacts at different levels of granularity andabstraction. A proof-of-concept tool support has been real-ized, and its functionality is illustrated via an industrial casestudy.

Keywords Software traceability · View-based ·Model-driven · Process-driven SOA · Tool support

Communicated by Prof. Richard Paige.

H. Tran (B) · U. Zdun · S. DustdarInstitute of Information Systems, Distributed Systems Group,Vienna University of Technology, Argentinier Str. 8/184-1,1040 Vienna, Austriae-mail: [email protected]

U. Zdune-mail: [email protected]

S. Dustdare-mail: [email protected]

1 Introduction

In a process-driven, service-oriented architecture (SOA) thenotion of process is central [16]. A typical process consists ofa control flow and a number of tasks to accomplish a certainbusiness goal. Each task performs either a service invoca-tion or a data processing task. Processes can be deployedin a process engine for enactment and monitoring. Figure 1illustrates a small-scale process-driven SOA [16]. Processengines access service-based message brokers, e.g., offeredby Enterprise Service Buses, via service-based process inte-gration adapters. Service-based business application adapt-ers are used as bridges between the brokers and back-endcomponents, such as databases or legacy systems.

Business processes are often designed in highly abstractand primarily notational modeling languages such as BPMN[42], EPC [20], or UML Activity Diagrams [40]. Processdesigns are suitable for business experts to represent domain-and business-oriented concepts and functionality but mostlynon-executable because many technical details are missing.Thus, IT experts necessarily need to be involved in the pro-cess development to transform the process designs into exe-cutable specifications. For example, IT experts can translateabstract, high-level concepts of process designs into concrete,fine-grained elements in executable process languages suchas BPEL [36] and specify the process interfaces in web ser-vice description language (WSDL) [56]. Additional deploy-ment configurations might also need to be defined in order tosuccessfully deploy and execute the implemented processes.

Understanding trace dependencies between process designand implementation is vital for change impact analysis,change propagation, documentation, and many other activ-ities [49]. Unfortunately, artifacts created during the pro-cess development life cycle likely end up being disconnectedfrom each other. This impairs the traceability of development

123

H. Tran et al.

Fig. 1 Illustrative small-scaleprocess-driven SOA

Process Integration Adapter

Message Broker

Business Application Adapter A

Business Application Adapter B

Business Application A

Business Application B

Process Engine

Ser

vice

1

Ser

vice

2

Ser

vice

3

Ser

vice

4

Ser

vice

1

Ser

vice

2

Ser

vice

3

Ser

vice

4

Ser

vice

1

Ser

vice

2

Ser

vice

3

artifacts. We identify the following important factors thatcomplicate the establishing and maintenance of trace depen-dencies:

• There are no explicit links between process design andimplementation languages. This lack of dependency linksis caused by not only syntactic and semantic differencesbut also the difference of granularity as these languagesdescribe a process at various levels of abstraction.

• A substantial complexity is caused by tangled processconcerns. Either the process design or implementationcomprises numerous tangled concerns such as the controlflow, data processing, service invocations, transactions,fault and event handling, etc. As the number of servicesor processes involved in a business process grows, thecomplexity of developing and maintaining the businessprocesses also increases along with the number of invo-cations, data exchanges, and cross-concern references,and therefore, multiplies the difficulty of analyzing andunderstanding the trace dependencies.

• There is a lack of adequate tool support to create andmaintain trace dependencies between process designs andimplementations.

To illustrate the aforementioned factors we use the well-known Travel Booking process [18]. Figure 2 shows the pro-cess development scenario from design to implementationand deployment. We summarize the statistics of the complex-ity in terms of the number of elements as well as their depen-dencies in Table 1. Even though the syntactic and semanticdifferences are omitted in Fig. 2, the elements representedin executable process languages (here: BPEL and WSDL)are more concrete and of much finer granularity than thedesign counterparts (here expressed in BPMN). Practically,abstract, high-level model elements are often described orimplemented by one or many technology-specific elements.For instance, a Data Object in BPMN is often representedby the corresponding variable in BPEL and the message type

Interaction

DataHandling

Transaction

BPEL

MessageService Interface

Schema

WSDL+XML Schema

Service Binding

FlowPartner

LinkTypes

Process descriptors Service endpoints

Design (BPMN)

Implementation (WSBPEL)

Deployment configuration

Fig. 2 The travel booking process development

from WSDL or the XML Schema type. In addition, someartifacts which are necessary for describing specific fea-tures in process implementation or for successfully deployingthe process have no corresponding elements in the processdesign. For instance, there are no corresponding design con-cepts or elements for the correlation of service invocations inBPEL, service bindings and service endpoints in WSDL, toname but a few. Existing process development approaches ortools merely support the stakeholders in importing, parsing,validating, and referencing elements between languages ofthe same level of abstraction, for instance, between BPEL,WSDL, and XML Schema, but have no support for crossreferences between process designs and implementations.

123

VbTrace: Using view-based and model-driven development

Table 1 Complexity anddependency statistics of theTravel Booking process

Design (BPMN) Implementation (BPEL) Deployment (PDD)

Task 7 BPEL activity 13 Partner reference 5

Correlation 7 Endpoint reference 4

Control structure 3 Control flow 12 Service reference 5

Control edge 11

Data object 3 BPEL variable 10

Association 11 Message 11

XML data type 11

Data handling 30

Partner (pool) 6 PartnerLink 5

Partner link 9 PartnerLinkType 5

PortType 5

Role 5

Binding 4

Service 4

Total element: 19 Total element 85 Total element 14

Dependency 31 Dependency 104 Dependency 20

Cross-concern 20 Cross-concern 49 Cross-concern 20

The complexity caused by numerous tangled process con-cerns such as the control flow, service and process inter-actions, data handling, transactions, and so forth, hindersthe understanding and analyzing of trace dependencies.Table 1 also shows the statistics of the cross-concern depen-dencies of process design (20/31), process implementa-tion (49/104), and deployment configuration (20/20). Thesenumbers mean: In order to thoroughly understand or analyzea certain concept of either a process design or an implemen-tation, the developer has to go across numerous dependenciesbetween various concerns, some of which are even not suit-able for the developer’s expertise and skills.

We present a view-based, model-driven traceabilityapproach that supports stakeholders in (semi-)automati-cally creating and maintaining traceability between processdesigns and implementations and/or deployment configura-tions. In the context of this article, BPMN [42], a standardfor business process modeling, is used as a representativeexample of a process design language, whilst BPEL [36] andWSDL [56], which are very popular process/service model-ing descriptions used by numerous companies today, are usedas representative examples for languages for implementingexecutable processes. Although establishing trace dependen-cies alone is not sufficient for tasks like change impact analy-sis or change propagation, it crucially lays the foundation forany such tasks. In this sense, our approach presented in thisarticle is the initial effort that overcomes the aforementionedchallenges to support (semi-)automatically eliciting as wellas (semi-)formalizing trace dependencies among model arti-facts in model-driven development (MDD) at different levelsof granularity and abstraction. The (semi-)formalization of

the trace dependencies is one of the features needed for theinteroperability of tools utilizing them.

In our approach, we exploit the notion of views and themodel-driven stack introduced in our previous work [52,54]in order to separate process representations (e.g. processdesigns or implementations) into different (semi-)formal-ized view models. In this way, stakeholders can be providedwith tailored perspectives by view integration mechanisms[52,54] according to their particular needs, knowledge andexperience. This is a significant step toward the support ofadapting process representations and trace relationships toparticular stakeholder interests. Additionally, view modelsare also organized into appropriate levels of abstraction:high-level, abstract views are suitable for business expertswhilst low-level, technology-specific views are mostly usedby IT experts. Given these levels of abstraction, processdesigns are adequately aligned with the abstract view mod-els, and the implementation counterparts are lined up withthe technology-specific view models. This can be done in a(semi-)automatic manner using the view-based reverse engi-neering approach described in [53]. Such mappings producetrace dependencies between designs and the view models,and between the view models and the source code that imple-ments the processes. These dependencies are parts of thetraceability meta-model which is the key component of ourtraceability approach. Moreover, the traceability meta-modelalso supports stakeholders in capturing intrinsic dependen-cies between view models and view elements.

This article is organized as follows. In Sect. 2 we brieflyintroduce the View-based Modeling Framework (VbMF)[52,54]. Next, Sect. 3 presents our view-based, model-driven

123

H. Tran et al.

Fig. 3 Overview of theview-based modelingframework ([17,52,54])

Core Model

FlowView Model

CollaborationView Model

InformationView Model

BpelCollaborationView Model

BpelnformationView Model

Technology-specific Layer

Abstract Layer

TransactionView Model

extends extends extendsextends

horizontal dimensionmastering the complexity of tangled process concerns

vert

ical

dim

ensi

on

brid

ging

abs

trac

tion

leve

ls

BpelFlowView Model

extends extends extends

traceability approach along with the details of the traceabil-ity meta-model. A CRM Fulfillment process from an indus-trial case study is exemplified to illustrate our traceabilityapproach and the realization of the approach in Sect. 4. ThenSect. 5 discusses related work. Finally, Sect. 6 summarizesour main contributions.

2 View-based modeling framework for process-drivenSOAs

In this section, we briefly introduce the View-based Model-ing Framework (VbMF) [52,54] that is the foundation of ourtraceability approach described in the next section. VbMFexploits the notion of views to separate the various processconcerns in order to reduce the complexity of process-drivenSOA development and enhance the flexibility and extensi-bility of the framework. VbMF offers a number of model-ing artifacts, such as view models and view instances (orviews for short) organized in two levels of abstraction (seeFig. 3). Each view embodies a number of view elements andtheir relationships that represent a business process from aparticular perspective. View elements and their relationshipsare precisely specified by a view model. In other words, aview model is a (semi)-formalization of a particular processconcern and the views conforming to that view model areconcrete instances of the process concern.

VbMF initially provides three foundational (semi-)for-malizations for representing a business process which are theFlowView, CollaborationView and InformationView models.The FlowView model describes the orchestration of processactivities, the CollaborationView model specifies the inter-actions with other processes or services, and the Informa-tionView model elicits data representations and processingwithin processes as well as messages exchanges. However,VbMF is not merely bound to these view models but can

be extended to capture other concerns, for instance, humaninteraction [17], data access and integration [31], transac-tions, and fault and event handling [54]. VbMF view modelsare derived from fundamental concepts and elements of theCore model. Therefore, these concepts of the Core modelare the extension points of the view-based modeling frame-work [52,54]. In our traceability approach, we exploit thisfeature of the VbMF Core model to derive trace dependen-cies between different views and between views and viewelements.

In addition, VbMF introduces a model-driven stack whichis a realization of the model-driven development (MDD) par-adigm [12,51]. The model-driven stack separates the viewmodels into abstract and technology-specific layers. In thisway, business experts, who mostly work with the high levelview models, can better capture, manipulate, and analyzedomain- and business-oriented concepts and knowledge asthe technical details have been abstracted away. For specifictechnologies, such as BPEL and WSDL, VbMF providesextension view models which add details to the abstract viewmodels that are required to depict the specifics of these tech-nologies [52,54]. These extension views belong to the tech-nology-specific layer shown in Fig. 3.

The view models and view instances are manipulated viaa number of components provided in VbMF (see Fig. 4). TheView/Instance Editors are derived from the VbMF view mod-els. Using these editors, a new view model can be developedfrom scratch by deriving from the Core model, or an existingview model can be extended with some additional features toform a new view model. Moreover, these editors also supportstakeholders in creating new view instances or editing exist-ing instances. Last but not least, the editors enables stakehold-ers to integrate relevant view instances in order to produce aricher view or a more thorough view of a certain business pro-cess [52,54]. Code Generators use the technology-specificview instances to generate executable code. Before gener-ating outputs, the code generators validate the conformity

123


Process DescriptionLanguage Syntax &

Semantics

View Instance

View Model

Process Descriptions(BPEL, WSDL, XML

Schema, etc.)

SchematicExecutable

Code

Reverse engineering tool-chain

Forward engineering tool-chain

ViewInterpreter

CodeGenerator

View/InstanceEditor

generates

creates,extends

uses integrates

uses

generates

produces

based on

defined in

interpretsbased on

Fig. 4 VbMF forward and reverse engineering tool-chains

of the input views against the corresponding view models.View Interpreters are leveraged to extract views from legacyprocess descriptions. These components of VbMF shape theforward engineering and reverse engineering tool-chains forprocess-driven SOA development.

In the VbMF forward engineering tool-chain abstractviews are designed first. Then, by using View/Instance Edi-tors, these instances are manipulated or refined down totheir lower level counterparts, the technology-specific viewinstances. The Code Generators uses the technology-spe-cific view instances to produce schematic process code and/ornecessary configuration code. In our traceability approach,View/Instance Editors and Code Generators need to beextended such that they can automatically establish tracedependencies between view models, between view modelsand view elements, and between different view elements. Thegenerated schematic code might need some manually writtencode (so-called individual code) to fulfill a certain businesslogic [51]. Our approach supports developers in establish-ing and maintaining those relationships via the traceabilitymeta-model.

In the reverse engineering tool-chain, the View Interpret-ers take as input legacy process descriptions and extract moreappropriate representations, i.e. process views, out of thelegacy code. These process views can be used in the for-ward engineering tool-chain for re-generating certain partsof the process code. During the reverse engineering process,high-level, abstract views and low-level, technology-specificviews can be recovered from the existing code. This way,

the reverse engineering approach helps stakeholders to getinvolved in process re-development and maintenance at dif-ferent abstraction levels [53]. The View Interpreters playa central role in the reverse engineering tool-chain. In thescope of this article we extend the View Interpreters from[53] for transforming process implementations in terms ofBPEL and WSDL code, or process deployment descriptorsin XML, onto VbMF technology-specific views. Other ViewInterpreters are developed to map process designs in terms ofBPMN diagrams onto VbMF abstract views. Relevant tracedependencies generated by these mappings are tracked andrecorded in the traceability meta-model, the (semi-)formal-ized representation of trace dependencies in our approach.

To summarize, the view-based modeling approach real-ized in VbMF is the foundation for dealing with the complex-ity of various tangled concerns in business processes, i.e., thesecond challenge we mentioned above in Sect. 1. Moreover,the model-driven stack in VbMF is the basis to organize viewmodels into adequate levels of abstraction, and therefore, todeal with the differences of granularity at these abstractionlevels. In the next section, we present our key contributions,the view-based, model-driven traceability approach, alongwith the traceability meta-model and the supporting mech-anisms and tools for establishing and maintaining the tracedependencies.

The concepts and mechanisms mentioned above have beenrealized as a view-based modeling framework [52–54]. Inthis modeling framework, view models are based on EclipseEcore, a MOF-compliant meta-model [9]. The code gener-ation templates have been developed using openArchitec-tureWare’s XPand and Xtend languages [43]. The VbMFtooling also provides a number of tree-based view editorsfor manipulating view instances. These tree-based view edi-tors are extended for producing corresponding relationshipsbetween views and view elements and used for illustrationpurposes in this article.

3 View-based, model-driven traceability framework

3.1 Fundamentals of the view-based, model-driventraceability framework

In the previous section we introduce the view-based model-ing framework (VbMF) which supports stakeholders in mod-eling and developing processes using various perspectiveswhich are tailored for their particular needs, knowledge, andskills at different levels of abstraction. We propose in thissection our view-based, model-driven traceability approach(VbTrace) in terms of a traceability framework which is anadditional dimension to the model-driven stack of VbMF (seeFig. 5).

123

H. Tran et al.

Fig. 5 View-based,model-driven traceabilityapproach as an additionaldimension of VbMF

Vflow

V1abstract

V1 technology-specific

Vie

w-b

ased

Mo

del

-dri

ven

T

race

abili

ty F

ram

ewo

rk

V2abstract


Process implementation and deployment

CA1 CA2 CA3 CA4 CA5

DAProcess designs

Legend DA: Design artifact V: View models CA:Code artifact

Intrinsic trace dependencies Generated trace dependencies

VbMF


VbTrace supports stakeholders in establishing and main-taining trace dependencies between the process designs andimplementations (i.e., process code artifacts) via VbMF. Thetrace dependencies between process design and abstract,high-level views and those between low-level, technology-specific views and code artifacts can be automatically derivedduring the mappings of process designs and implementationsinto VbMF views using an extended version of the view-based reverse engineering approach presented in [53]. Thesetrace dependencies are represented by the solid arrows inFig. 5. The relationships between a view and its elementsare intrinsic whilst the relationships between different viewsare established by using the name-based matching mecha-nism for integrating views [52,54]. These relationships areindicated in Fig. 5 by dashed lines because they are merelyderived from the view models and mechanisms provided byVbMF [52,54]. Therefore, in this article we will concen-trate more on the former kind of trace dependencies, i.e.,the trace dependencies between process designs and imple-mentations and view models. Nonetheless, the case study inSect. 4 will illustrate a complete consolidation of the afore-mentioned kinds of trace dependencies as a whole. In thesubsequent sections, we present the view-based traceabilitymeta-model that is a (semi-)formalization of trace depen-dencies between process development artifacts. Based onthe traceability meta-model, we extend and use the com-ponents and mechanisms provided by VbMF to shape aview-based, model-driven traceability framework that sup-ports stakeholders in (semi-)automatically establishing andmaintaining the corresponding trace dependencies.

3.2 View-based traceability meta-model

At the heart of VbTrace, we devise a traceability meta-model that provides concepts for precisely eliciting tracedependencies between process development artifacts. Thistraceability meta-model is designed to be rich enough forrepresenting trace relations from process design to imple-mentation and be extensible for further customizations andspecializations. Figure 6a shows the conceptual overview ofthe meta-model that defines a TraceabilityModel containinga number of TraceLinks. There are two kinds of TraceLinksrepresenting the dependencies at different levels of granu-larity: ArtifactTraces describing the relationships betweenartifacts such as BPMN diagrams, view models, BPEL andWSDL files, and so on; ElementTraces describing the rela-tionships between elements of the same or different artifactssuch as BPMN notations, view elements, BPEL activities,WSDL messages, XML Schema elements, and so forth. Thesource and target of an ArtifactTrace are ArtifactReferenc-es each of which consisting of either the location path, thenamespace URI, or the UUID1 of the corresponding artifact.An artifact may contain a number of elements described bythe ElementReference meta-class. Every ElementReferenceholds either an XPath expression [55] or a UUID which is auniversal reference of the underlying actual element.

Each ElementTrace might adhere to some TraceRatio-nales that comprehend the existence, semantics, causalrelations, or additional functionality of the link. The

1 UUID: Universally unique identifier.

123


TraceabilityModel

1..*source

ElementTrace

xpath: Stringuuid: String

ElementReference

*

link

ArtifactTraceelementTrace

*

target1..*

description: String

TraceRationale

*

annotated with

TraceLink

location: StringnsURI: Stringuuid: String

ArtifactReference

target11source

Code

element

*

element

*

SchematicCode

CodeFragmentelement

*

*

contains

FormalizeGenerateExtend Use

path: StringlineStart: IntegerlineEnd: Integer

FragmentPosition

position

1

DesignElement

ViewElement

Design

ViewModel

ViewToView

ViewToCode

DesignToView

CodeToCode

ViewElementPair

DesignViewPair

ViewCodePair

CodeFragmentPair

(a) Conceptual traceability meta-model

(b) View-based traceability meta-model

RelationTypeRole

Depend ConflictSatisfy

Fig. 6 VbTrace meta-models: (a) the conceptual traceability meta-model, and (b) the view-based, model-driven traceability meta-model

TraceRationale is open for extension and must be spe-cialized later depending on specific usage purposes, forinstance, for reasoning on trace dependencies concerning thetraceability types: dependency, require, transform, extend,generalize/refine, implement, generate, use, etc., [40,49] orsetting up dependency priorities or development roles associ-ated with the trace link. Figure 6b depicts the extensibility ofTraceRationales by a number of concrete realizations such asRole standing for stakeholders roles and RelationType whichis further specialized by several types of commonly usedtrace dependencies [40,49].

The traceability meta-model explained so far providesabstract and generic concepts shaping the basis for a typicaltraceability approach. In the context of our traceabilityapproach, these abstract concepts are refined to representtrace dependencies of the various view models at differentlevels of granularity (see Fig. 6b). We devise four concretetypes of TraceLinks: DesignToViews represent traceabilitybetween process designs and VbMF, ViewToViews describeinternal relationships of VbMF, i.e., relationships betweenview models and view elements, ViewToCodes elicit thetraceability from VbMF to process implementations, andfinally, CodeToCodes describe the relationships between thegenerated schematic code and the associated individual code.

Languages used for designing processes typically com-prise highly abstract, notational elements that businessexperts are familiar with. A process design artifact presentedin the traceability meta-model by the Design meta-class.Each Design includes several DesignElements standing forprocess design notational elements. The mapping from pro-cess designs onto the VbMF abstract layer produces tracelinks of the DesignToView type. Moreover, each Design-ToView maintains one or many DesignViewPairs which areresponsible for tracing the mapping relationships at the levelof elements, i.e., mapping from design elements to viewmodel elements.

One of the important modeling artifacts provided byVbMF is the ViewModel that embodies a number of ViewEle-ments. Because there is probably a dependency between twoview models, we use ViewElementPairs to capture the rela-tionships between view elements of those view models in afine-grained manner. In particular, a ViewToView inherits thetwo associations from its parent ArtifactTrace and holds anumber of ViewElementPairs standing for the finer granular-ity of the traceability among view model elements.

In VbMF, the technology-specific view models are rarelydeveloped from scratch but might be gradually refinedfrom existing abstract view models (see [52,54]). As such,

123

H. Tran et al.

extracting of trace links is straightforward because VbMFprovides the necessary information concerning model refine-ments. The technology-specific view models can also beextracted from process implementations using the reverseengineering approach from [53,54]. In contrast, processimplementations (i.e., code artifacts) can be automaticallyproduced from technology-specific view models by VbMFcode generators. By extending the reverse engineering inter-preters and the code generators, we obtain the relevant tracelinks in terms of ViewToCodes, and even finer grained rela-tionships at the level of code fragments by using ViewCode-Pairs that keep references from ViewElements to generatedCodeFragments. A CodeArtifact is composed of one or manyCodeFragments each of which might contain other code frag-ments. For instance, a WSDL [56] file is a CodeArtifact thathas a number of fragments such as XML schema definition,message types, service interfaces, service bindings, and ser-vice implementations.

Code artifacts generated from the model-driven stack ofVbMF are mostly schematic recurring code that needs to beaugmented by manually written code, for instance, using thepatterns suggested in [51]. Therefore, the traceability meta-model provides another concept for code association, theCodeToCode meta-class. Each CodeToCode should hold areference between a certain SchematicCode and one of itsrequired manually written Code instances.

Last but not least, the abstract TraceRationale concept isrealized and extended by, but not limited to, a number ofpopular trace relationships such as Extend, Generate, Imple-ment and Use that can be employed to augment the semanticsof the trace dependencies explained above. Additional ratio-nales or semantics can be derived in the same manner for anyfurther requirements.

-- artifact-to-artifact tracescontext DesignToView inv:source.isKindOf(Design) and target.isKindOf(

ViewModel)context ViewToViewinv: source.isKindOf(ViewModel) and target.

isKindOf(ViewModel)context ViewToCodeinv: source.isKindOf(ViewModel) and target.

isKindOf(Code)context CodeToCodeinv: source.isKindOf(SchematicCode) and target

.isKindOf(Code)-- element-to-element tracescontext DesignViewPair-- each source must be an element of container

’s sourcesinv: source->forAll(container.source.element

->includes(source))-- each target must be an element of container

’s targetsinv: target->forAll(container.target.element

->includes(target))

context ViewElementPair-- similar to those for DesignViewPairinv: source->forAll(container.source.element

->includes(source))inv: target->forAll(container.target.element

->includes(target))context ViewCodePair-- each source must be an element of container

’s sourcesinv: source->forAll(container.source.element

->includes(source))-- each fragment must belong to the set of

container’s fragmentsinv: fragment->forAll(container.fragment

->includes(fragment) or container.fragment->collect(subFragment)->includes(fragment))

context CodeFragmentPair-- each fragment must belong to the set of

container’s fragmentsinv: fragment->forAll(container.fragment

->includes(fragment) or container.fragment->collect(subFragment)->includes(fragment))

inv: fragment->forAll(container.fragment->includes(fragment) or container.fragment->collect(subFragment)->includes(fragment))

Listing 1 OCL constraints for the traceability meta-model

Note that the relationships between Design and Desig-nElement, between View and ViewElement, and betweenCode and CodeFragment in the traceability meta-model aremerely presented for clarification purpose because thoserelationships can be straightforwardly derived from processdesign artifacts, VbMF modeling artifacts, and code artifacts,respectively. Toward more strictly modeling of aforemen-tioned traceability links, Listing 1 presents OCL constraints[41] for the meta-classes of the traceability meta-model thatare required for specifying more precise semantics as well asfor the verification of traceability model instances built uponthe meta-model.

In summary, the traceability meta-model provides essen-tial concepts for eliciting trace dependencies at differentabstraction levels ranging from process design artifacts toabstraction levels of VbMF view models down to code arti-facts of process implementations. Each trace link betweentwo levels of abstraction can also support elicitation ofthe differences of granularity, such as pairing design ele-ments and view elements, or view elements and code frag-ments. Furthermore, the traceability meta-model is open forextension to finer granularity by deriving new subclasses ofpairings such as DesignViewPair, ViewElementPair, andViewCodePair, or for adding new higher or lower abstrac-tion levels by deriving new sub-types of the TraceLink, Arti-factTrace, or ElementTrace meta-classes. In the subsequentsections, we present the view-based traceability architec-ture along with the components and mechanisms that sup-ports stakeholders in (semi-)automatically establishing and

123


ModelRepository

Extended Code Generator

View models,instances

Extended View-based interpreters

Process implementations (BPEL, WSDL)

Process deployment descriptions

VbTraceDesignToView

Technology specific

view instances

Codegenerationtemplates

Process implementations and deployments

Code(manually

written code)

Schematic Recurring Code

Legacy process

descriptions

ViewToCode

Process designs

Process design supporting tools

(BPMN Designers)

Abstractview

instances

ViewToCode

View/Instance Editors

View models,instances

ViewToView

VbMF specific flows VbTrace flowsLegend:

VbTracemodel

Fig. 7 View-based, model-driven traceability framework architecture

maintaining the trace dependencies based on the concepts ofthe aforementioned meta-model.

3.3 View-based, model-driven traceability frameworkarchitecture

The view-based, model-driven traceability framework archi-tecture shown in Fig. 7 extends the components of VbMF(see Fig. 4) in order to acquire traceability relationships. Forinstance, the extended View/Instance Editors produces tracelinks between view models, between view models and ele-ments, as well as between elements of different view mod-els. These relationships, as mentioned above, are intrinsicparts of VbMF views, and therefore, are straightforwardlyextracted. In addition, the extended View Interpreters can beutilized for collecting trace dependencies between processdesigns and view models, and between view models extractedfrom process implementations and the corresponding imple-mentations. Last but not least, the extended Code Generatorcan establish trace links from view models used for gener-ating executable process code to the resulting source codeartifacts. These extended components retrieve the aforemen-tioned trace dependencies and deliver them to the VbTraceas instances of the traceability meta-model. The traceabil-ity meta-model and its instances are models themselves,and therefore, can be persisted in the model repository ofVbMF for later use and maintenance. The model repositoryis one of our ongoing works, but beyond the scope of thisarticle.

3.4 View-based modeling and traceability tool-chain

The traceability meta-model and components mentionedabove are essential parts forming the view-based model-ing and traceability tool-chain shown in Fig. 8. In thistool-chain, process design are mapped into VbMF abstractviews whilst process implementations are aligned withVbMF technology-specific views by extending the view-based reverse engineering approach presented in [53,54].During these mappings, the extended view-based interpret-ers are able to establish the relevant trace dependenciesDesignToViews and ViewToCodes, respectively, as well as thefine-grain relationships that are DesignViewPairs and View-CodePairs.

Nonetheless, the ViewToCodes and ViewCodePairs canalso be derived in the course of the generation of processimplementations (e.g., BPEL and WSDL code) and deploy-ment configurations (e.g., process descriptors for deployingand executing processes in the ActiveBPEL, an open sourceBPEL engine [1]), from VbMF technology-specific views.The transformation templates specify the rules for genera-tion code from VbMF models. We extend these templates togenerate the relevant trace dependencies between the viewmodels, view elements, and the generated code artifacts andcode fragments.

In the following sections, we elaborate on extending theview-based interpreters and code generation templates usingsome scenarios in which trace dependencies are establishedby using our extended code generators and extended view-based interpreters.

123

H. Tran et al.

Process design Abstract views

Code Generator

Process implementation

Deployment configuration

Transformation templates

Technology-specific views

Fig. 8 View-based modeling and traceability tool-chain

3.4.1 Establishing trace dependencies using extendedview-based interpreters

The view-based reverse engineering approach [53] can be uti-lized for extracting VbMF views from existing process imple-mentations in BPEL and WSDL. We extend this approachsuch that the relevant trace dependencies are also establishedduring the course of the reverse engineering process. Fig-ure 11a presents an excerpt of the FlowView interpreter inJava code that can extract AtomaticTasks of the FlowViewfrom BPEL code. In addition, we instrument additional Javacode for creating trace dependencies between the BPEL codefragment and the resulting AtomicTasks. The generated tracedependencies are parts of the Traceability model shown inFig. 9b. This approach can also be applied for the otherview-based interpreters such as the CollaborationView, In-formationView, BpelCollaborationView, and BpelInforma-tionView interpreters [53] in order to automatically establishthe relevant trace dependencies between BPEL and WSDLdescriptions and VbMF views. For better supporting stake-holders in reasoning and analyzing the resulting trace depen-dencies, for instance, change impact analysis, Generate andFormalize are automatically annotated to each trace depen-dency.

Although the view-based reverse engineering approachpresented in [53] is exemplified using process implementa-tion languages such as BPEL and WSDL, it is extensible andapplicable for mapping the concepts of a process design intoVbMF abstract views. Let us recall that VbMF view modelsat the abstract layer are intentionally designed for businessexperts. As a result, the concepts embodied in these viewmodels have a close relationship to the elements of languagesused for designing processes, such as BPMN, UML Activ-ity Diagram, EPCs, and so on. A minor difference of thesehigh-level view interpreters to the view interpreters men-tioned above is that we realize the view-based reverse

engineering approach using openArchitectureWare Xpandand Xtend languages [43] due to their sufficient transforma-tion mechanisms. Figure 10a shows an excerpt of the tem-plate-based transformation rules written in XPand languagethat maps a BPMN Data Object into a Business Object ele-ment of the InformationView. In addition, the transformationrules also generate relevant trace dependencies between thedesign and view elements. We illustrate in Fig. 10b a part ofthe traceability model comprising two DesignToView tracelinks between the design and the FlowView of the CRM Ful-fillment process from the case study presented in Sect. 4.These trace dependencies are augmented with the Formalizeof type TraceRationale.

3.4.2 Establishing trace dependencies using extended codegenerators

Code generation (or so-called model-to-code transforma-tion) is an important step of any realization of the MDDparadigm to gain productivity and ensure better softwarequality [51]. The results of code generation process areoften the schematic, recurring code that shapes the skel-eton of the software or systems. Some manually writtencode (aka individual code) might augment the generatedschematic code in order to realize the individual parts ofthe business logic [51]. VbMF provides a template-basedcode generation approach that is able to generate schematicimplementations of processes in terms of BPEL and WSDLdescriptions. This approach has been realized in VbMFusing the openArchitectureWare Xpand and Xtend languages[43]. We extend the template-based code generation rules inVbMF such that the trace dependencies between the involvedviews, view elements, and generated code fragments areautomatically established. Figure 11a presents an excerptof the VbMF code generation rules for generating BPEL<invoke> elements from VbMF technology-specific views

123


Fig. 9 Illustration of extractingVbMF views from BPEL codeand establishing the relevanttrace dependencies

Fig. 10 Illustration of mappingBPMN designs to VbMFabstract views and establishingrelevant trace dependencies

along with our instrumented rules for generating trace depen-dencies. The resulting trace dependencies are illustrated inFig. 11b containing a ViewToCode trace link between theVbMF BpelCollaborationView and BPEL <invoke> frag-ment extracted from the case study (see Sect. 4). Although

these trace dependencies are generated in the oppositedirection to those extracted from the reverse engineeringof process implementations, they share similar semanticsand rationales of the trace relations that are Generate andFormalize.

123

H. Tran et al.

Fig. 11 Generating BPEL codefrom VbMF technology-specificviews and establishing relevanttrace dependencies

4 Tool support and case study

In this section, we illustrate the realization of the aforemen-tioned concepts in VbTrace via the CRM Fulfillment processadapted from an industrial case study concerning customercare, billing and provisioning systems of an Austrian Inter-net Service Provider (cf. [11] for more details). The processis designed using BPMN and implemented using process-driven SOA technology: BPEL and WSDL. BPMN, BPEL,and WSDL are used for exemplification because these arelikely the most popular process and service description lan-guages, which are widely adopted in research and industrytoday. Nevertheless, our approach is not limited to those but isgenerally applicable for other process-driven SOA technol-ogies. To illustrate the process deployment configurations,we exemplify a specific BPEL engine, namely, ActiveBPEL,and develop the necessary configurations for the deployment,enactment and monitoring of the CRM Fulfillment process.

In the subsequent sections, we first quickly introduce thetool support for our traceability approach. Next, we presentin detail the case study and important steps of establishingand maintaining appropriate traceability meta-data between

process designs and VbMF, among VbMF views, andbetween VbMF views and process implementations. At theend of this section, we introduce a sample of using trace-ability path derived from the traceability model for betterunderstanding and analyzing the relationships of processdevelopment artifacts.

4.1 View-based, model-driven integrated developmentenvironment

A proof-of-concept of view-based, model-driven approachhas been implemented in [52–54] using the Eclipse Model-ing Framework (EMF) [9] and openArchitectureWare MDDFramework [43]. In this article we have realized the conceptsof our view-based, model-driven traceability approach pre-sented based on the aforementioned VbMF implementationand integrated them with VbMF in terms of an view-based,model-driven integrated development environment. In orderto effectively reuse and extend VbMF concepts and mecha-nisms, the traceability framework is derived from the EMFEcore meta-model. The biggest advantage of using EclipseModeling Framework is that we gain better interoperability

123


Fig. 12 The development of CRM Fulfillment process in view-based, model-driven integrated environment: (1) The process design in BPMNModeler (2) VbMF views, (3) Traceability view, and (4) Generated process implementation

with the Eclipse BPMN Modeler [19] which is developedbased on EMF Ecore.

For the sake of demonstration, we use the BPMN dia-grams designed in the Eclipse BPMN Modeler to representthe process design, and extend the tree-based editor gener-ated by EMF for presenting and manipulating Traceabilitymodels from now on. The components of our traceabilityframework, such as Extended Code Generators and ExtendedView-based Interpreters (see Fig. 7), are derived from corre-sponding VbMF components (see Fig. 4) using the mecha-nisms described in Sect. 3.4.

4.2 CRM Fulfillment process

The CRM Fulfillment process is a part of the customer rela-tionship management (CRM), billing, and provisioning sys-tems of an Austrian Internet Service Provider [11]. The mainbusiness functionality of the CRM Fulfillment process is tohandle a customer order of the company’s bundle of Inter-net and telecom services including a network subscriberline (e.g., xDSL), email addresses, Web-based administra-tion (VMX), directory number, fax number, and SIP URLfor VoIP communications. The process uses a wide vari-ety of in-house services and services provided by various

partners. The company has developed and deployed in-houseservices for customer relationship information management,assigning fax numbers, SIP URLs, and mail boxes, initializ-ing VMX, and sending postal invoices to customers.

The process uses a credit bureau service provided by athird party business partner of the financial institution thatacquires, stores, and protects credit information of individ-ual and companies. The credit bureau service can verify acustomer’s payment account for accuracy and validity andcharge the payment according to the customer’s purchaseorder. Customer premise equipment (CPE) partners supplyservices for ordering and shipping home modems or routers.Telecom partners offer services for checking, assigning, andmigrating customer directory numbers (DN). These servicesexpose their functionalities in terms of WSDL interfaces thatcan be orchestrated using BPEL processes.

Figure 12 shows the design of the CRM Fulfillment pro-cess in terms of a BPMN diagram in Eclipse BPMN Mod-eler. The process is initiated as a customer places a purchaseorder. Then, the customer relationship management serviceis invoked to update the customer’s profile. Next, the processinvokes a bank service to validate the customer’s accountvalidity. In case a negative confirmation is issued from thebank service, e.g., because the account number is invalid or

123

H. Tran et al.

UpdateCustomerProfile

VerifyBankAccount

CreateMailbox

AssignSIP

MigrateDN

InitializeVMX

ShipCPE

CheckDN

AssignDN

SendInvoice

ReceiveCustomer Order

ReplyOrder Confirmation

CancelCustomerOrder Assign

Fax

ChargeCustomer Account

CRM Fulfillment process design The CRM Fulfillment FlowView (c)(b)(a) CRM Traceability model

Fig. 13 Illustration of mapping CRM Fulfillment process design (left) onto VbMF FlowView (right), and establishing trace dependencies (middle)

the owner and account do not match, the order will be can-celed. Otherwise, the positive confirmation will trigger thesecond branch in which the process continues with a numberof concurrent activities to fulfill customer order’s requestsand deliver networking equipments, e.g., home modems orrouters, to the customer’s shipping address. For the sakeof simplicity, we assume that those activities finish withouterrors. After all of these activities finished, the customer’spayment account is charged and a postal invoice will be sentto customer’s billing address.

4.3 CRM Fulfillment process development and traceability

Figure 12 depicts one of development perspective of the CRMFulfillment process using our view-based, model-driven inte-grated environment, which is an Eclipse-based workbench.The stakeholders can create and manipulate process views inthe various VbMF view editors or extract views from processdesigns and implementations using the built-in view-basedreverse engineering. Given these process views, stakeholderscan generate process implementations such as process code inBPEL, service interfaces of processes in WSDL and processdeployment configurations by using the predefined template-based code generation rules. Moreover, the code generationtemplates can also be customized according to further needsby using the the XPand language editor [43]. In addition, thetrace dependencies established during the course of processdevelopment are presented to the stakeholders in the Trace-ability view.

The subsequent sections present the various scenariosto demonstrate how relevant trace dependencies betweenprocess designs and VbMF views, between VbMF views,

and between VbMF views and process implementations areestablished during the course of modeling and developingthe CRM Fulfillment process.

4.3.1 Scenario 1: Traceability between process design andVbMF views

The CRM Fulfillment process design is a BPMN diagramthat comprises a number of notational elements such as apool, tasks, data objects, and sequential flow connectors (seeFig. 12). For the sake of readability and demonstration, weadapt the design of CRM Fulfillment process and omit theData Objects which are irrelevant in this scenario.

In the context of process-driven SOAs, VbMF leveragesthe FlowView model as the central notation because thismodel represents the orchestration of the process activities[52,54]. We demonstrate the mapping of the BPMN designonto the FlowView of the CRM Fulfillment process alongwith the trace dependencies established during the mapping(see Fig. 13) by using the approach mentioned in Sect. 3.4.The trace dependencies includes trace links at coarse-grainedlevels, i.e., between the BPMN diagram and the FlowViewmodel, or at finer granularities, e.g., between a BPMN taskand a FlowView’s Atomic Task, between a BPMN Gate-wayDataBasedExclusive and a conditional switch, namely,Exclusive of the FlowView, and so on. Taking the sameapproach of mapping the CRM Fulfillment process designonto the FlowView, we have developed more view-basedinterpreters for extracting abstract view models from the pro-cess design and establishing tracing relationships.

Note that VbMF is a realization of the separation ofconcerns principle [52,54]. In VbMF, the FlowView model

123


CRM Fulfillment CollaborationView The CRM FulfillmentBpelCollaborationView

(c)(b)(a) CRM Traceability model

Fig. 14 Illustration of establishing traceability (middle) of model refinements from the CRM CollaborationView (left) to the BpelCollaborationView(right)

merely represents the control structures, i.e., the orchestra-tion concern of business processes that describe the executionorder of process activities in order to accomplish a certainbusiness goal. However, the FlowView does not contain anydetails of these tasks. Other views, according to their specificsyntaxes and semantics, provide the concrete definitions ofeach of FlowView’s tasks. For instance, a service invocationtask of the FlowView is realized in a CollaborationView oran extension of the CollaborationView whilst a data process-ing task is defined in an InformationView or an extensionof the InformationView. In this way, the FlowView modelaims at supporting stakeholders, especially business experts,to quickly design the business functionality by orchestratingnamed activities rather than being stuck with other detailssuch as performing remote invocations, activity compensa-tion, and so on. These details are accordingly defined inabstract view models and/or refined down to technology-specific view models by the relevant IT experts. As a con-sequence, these views, regardless whether they are abstractor technology-specific, can be integrated with the FlowViewusing the view integration mechanism [52,54] in order to pro-duce richer views or a thorough view of the whole processwith respect to the particular needs, knowledge, and skills ofstakeholders.

4.3.2 Scenario 2: Traceability between VbMF views

View models at the abstract layer of VbMF are intention-ally designed for business experts alike who are not familiaror able to work with the technical details. As such, thesemodels supplement the FlowView with adequate concepts

and perspectives. In other words, the abstract views canbe considered platform-independent models (PIMs) [12,51]that have close relationships with process designs rather thanthe implementation counterparts. In the model-driven stackof VbMF, an abstract view can be gradually refined down toits corresponding technology-specific view. For instance, theBpelCollaborationView is a stepwise refinement of the moreabstract CollaborationView (cf. [52,54]). Thus, refinementrelationships are important for tracing from process design toimplementations. We track these relationships by using tracelinks of the type ViewToView for supporting the traceabilitybetween two view models, and a number of ViewElement-Pairs each of which holds references to the correspondingview elements.

Figure 14 shows an illustration of establishing the tracedependencies out of the refinement of the CRM Collabo-rationView (Fig. 14a) down to the CRM BpelCollabora-tionView (Fig. 14c) described by the ViewToView and itsconstituent ViewElementPairs. For the sake of readability, weonly present a number of selected trace dependencies and usethe arrows to depict the links described by each dependency.Each trace dependency is augmented with the Refine of typeTraceRationale.

Additionally, VbMF views can be integrated to producericher views. For instance, a certain stakeholder might needto see the orchestration of the CRM Fulfillment processactivities along with the interactions between the processand other processes or services. The combination of theFlowView model and either the CollaborationView or theBpelCollaborationView based on the name-based matchingapproach described in [52,54] can offer such a perspective.

123

H. Tran et al.

Fig. 15 Illustration of establishing trace dependencies (middle) of an integration of CRM FlowView (left) and BpelCollaborationView (right)

Figure 15 shows an illustration of establishing the trace rela-tionships out of such combinations. The main purpose ofview integration is to enhance the flexibility of VbMF forproviding various adapted and tailored perspectives of theprocess model. Because those perspectives might be usedby the stakeholders for analyzing and manipulating the pro-cess model, we track down the relationships caused by theabove-mentioned combination in the traceability accordingto specific stakeholders’ actions and augment them with theDependency type.

4.3.3 Scenario 3: Traceability between VbMF viewsand process implementations

In the previous sections, we illustrate the methods for estab-lishing the traceability path connecting the CRM Fulfill-ment process design to VbMF view models at the abstractlayer down to the technology-specific layer. The relation-ships between view models and process implementations,however, can be achieved in two different ways. On theone hand, schematic code of process implementations orprocess deployment descriptors can be generated from thetechnology-specific views (such as the BpelCollaboration-View, BpelInformationView, etc.) at the final step of VbMFforward engineering tool-chain [52,54]. On the other hand,the reverse engineering can also automatically extract viewmodels from existing (legacy) process implementations [53].Regardless of using any of these methods, the trace depen-dencies need to be recorded to maintain appropriate relation-ships between view models and process implementations tofully accomplish the traceability path from process designsto the implementation counterparts (see Fig. 16).2

2 For the sake of readability, we omitted irrelevant elements and name-space bindings in the BPEL and WSDL code and process deploymentconfigurations.

Furthermore, a number of process engine specific descrip-tors are necessary for successfully deploying and executingthe CRM Fulfillment process. In this article, ActiveBPELis exemplified as the reference process engine to deploy andexecute the CRM Fulfillment process in this article. Utilizingthe extended code generators mentioned in Sect. 3.4, VbMFcan generate the process deployment descriptors and estab-lish the trace links. Figure 17 depicts the trace dependenciescreated during the course of generating process deploymentdescriptor required by the ActiveBPEL engine from VbMFviews.

4.4 Leveraging VbTrace—a sample traceability path

Establishing trace dependencies alone is not sufficient fortasks like change impact analysis, change propagation, arti-fact understanding, and so on, it is the important factorfor supporting any such tasks [49]. In this section, weexamine a sample traceability path based on the traceabil-ity model created in the previous sections to illustrate howour traceability approach can support these tasks. Figure 18depicts a simple traceability path from the CRM Fulfillmentprocess design through the VbMF framework to the pro-cess implementations. The traceability path comprises thetrace dependencies between the process design and VbMFviews mentioned in Sect. 4.3.1 followed by the relation-ships among VbMF views retrieved in Sect. 4.3.2. Theprocess implementation is reached at the end of the trace-ability path by using the trace dependencies between VbMFtechnology-specific views and process code described inSect. 4.3.3.

Let us assume that there is a business expert working onthe BPMN Modeler in order to analyze the CRM Fulfill-ment process functionality and change the process design.These changes must be accordingly reflected in the processimplementations in BPEL and WSDL and even in process

123


Fig. 16 Illustration of establishing traceability (3) between VbMF views (1) and process implementations (2)

Fig. 17 Illustration of establishing traceability (3) between VbMF views (1) and process deployment descriptors (2)

deployment configuration. Without our traceability approach,the IT experts have to look into the BPMN diagram andmanipulate BPEL, WSDL code and process descriptors man-ually. This is time consuming, error-prone and complexbecause there is no explicit links between these languages.In addition, the stakeholders have to go across numerousdependencies between various tangled concerns, some ofwhich might be not relevant to the stakeholders expertise(cf. the statistics in Fig. 2). Using our approach, the business

experts can analyze and manipulate business processes byusing either the process designer or the VbMF abstract viewssuch as the FlowView, CollaborationView, InformationView,and so on, depending on their needs and knowledge. TheIT experts, who mostly work on either technology-specificviews or process code, can better analyze and assess coarse-grained or fine-grained implications of these changes basedon the traceability path connecting the process design andimplementation at different levels of granularity.

123

H. Tran et al.

ReceiveCustomer Order

CRM Fulfillment Diagram

CRM CollaborationView

CRM BpelCollaboration

View

«Code»crm.bpel

«Interaction»ReceiveCustomerOrder

«receive»ReceiveCustomerOrder

CRM FlowView

«AtomicTask»ReceiveCustomerOrder

1 2

3

Legend

Artifact traces

Element traces

Fig. 18 Illustration of a traceability path from the CRM Fulfillment process design (1) through VbMF views (2) to process implementations (3)

5 Related work

Being extensively studied in literature and industry, depen-dency relationships between designs and implementationsare often used for tracing through development artifacts,supporting change impact analysis, artifacts understand-ing, and other tasks [49]. Spanoudakis and Zisman [49]presented a summary of the state-of-the-art traceabilityapproaches that focus on the tracing between stakehold-ers and requirements [14], between requirements [4,14,21,23,45,47,60], between requirements and designs [8,10,22,23,46,47], between designs presented in [10,21,47,59],between requirements and code [6,10,29,47], and betweencode artifacts [47]. There are only a few approaches forsupporting traceability between designs (e.g., UML Classdiagrams) and code [8,10,23,29,47]. Each of the afore-mentioned design-to-code traceability approaches, however,merely focus on specific types of dependencies, for instance,overlap relations [10], evolution relations [8,29,47], andgeneralization/refinement relations [23]. These approachesdo not mention the extensibility to other types of dependen-cies or the ability to cover different levels of granularity oftrace dependencies.

The difference of abstraction and granularity and thediversity of language syntaxes and semantics hinder theautomation of establishing and maintaining the traceabilitybetween high-level artifacts, such as requirements or designspecifications, and very low-level artifacts, such as execut-able code. There are few promising efforts on supportingautomatic generation of trace dependencies that use infor-mation retrieval techniques [5,6,15,25,26,30] or rule-basedtraceability [28,46,50]. To the best of our knowledge, the

traceability retrieved from the aforementioned approachesdoes not cover the difference of granularity at multiple lev-els of abstraction, which is the first challenge we describedin Sect. 1. In addition, [24,47] suggested that a traceabilityapproach only supports the representation of different tracedependencies between artifacts, but the interpretation, analy-sis, and understanding of the relationships extremely dependon the stakeholders. According to his specific needs, knowl-edge, and experience, a stakeholder might be interested indifferent types of dependencies of different levels of abstrac-tion. Most of traceability approaches described above, except[14], have not provided adequate support for different stake-holder interests.

Recently, model-driven development (MDD) [12,51],which gradually gains widespread adoption in bothindustry and research, provides an efficient paradigm topotentially reconcile the difference of granularity at variouslevels of abstraction by introducing a number of interme-diate (semi)-formal modeling layers, such as the platform-independent models (PIMs) and platform-specific models(PSMs) [12,38]. Each modeling layers can provide differentabstractions of systems and software which are tailored tospecific stakeholders’ knowledge and experience. Moreover,model transformations provide better facilities for the auto-mation of creating and maintaining traceability relationships[2,13]. A number of research approaches have exploitedthese advantages for establishing and maintaining trace-ability between development artifacts [3,7,27,35,37,57], toname but a few, in order to support reducing the gap betweendesign and implementation.

The lightweight traceability approach TRACES proposedin [3] can support tracing requirements across different

123


models and levels of abstraction. Based on the assumptionthat each artifact has a unique identifier, and code is fully gen-erated from the models ( which is hard to achieve in reality[51]) TRACES offers mechanisms for eliciting traceabilitylinks from requirements to models, i.e., PIM and PSM, andfrom the models to code. Mäder et al. [27] analyze and clas-sify Unified Process (UP) artifacts to establish a traceabilitylink model that helps in (semi)-automatically establishingand verifying traceability links in Unified Process develop-ment projects along with a set of rules for management ofthe links. Leveraging model transformations, Naslavsky et al.[35] propose an approach for creating fine-grained traceabil-ity among model-based testing artifacts in order to supportresult evaluation, coverage analysis, and regression testing.Oldevik and Neple [37] present an approach for handlingtext-based traceability links in model-to-code transforma-tions (aka code generations) which is a key contribution toOMG MOF Model to Text Transformation standardizationeffort [39]. This approach provides a meta-model includ-ing a set of concepts for traceability between model ele-ments and locations in code artifacts. The correspondingpart of our traceability meta-model, i.e., the trace dependen-cies between views and code artifacts, is inspired by [37].Walderhaug et al. [57] present a generic approach for trace-ability in MDD aiming to enhance sharing and integrating oftraceability information from different development tools.The authors propose a high-level representation of the trace-ability process in the course of software development thatprovides general concepts for representing different kindsof stakeholders and artifacts used for traceability, such astrace model, trace repository, and the interactions betweenthe stakeholders and these artifacts. Bondé et al. [7] proposean approach that offers a traceability meta-model for repre-senting the relations between artifacts and the transformationoperations associated with these relations. Once the trace-ability is accomplished, it then can be used to enforce theinteroperability of models at different levels of abstraction,for instance, between a PIM and PSM.

Our work has the commonalities with the MDD-basedtraceability approaches in using traceability meta-models for(semi-)formalizing trace dependencies in order to enhancethe interoperability of tools. In contrast to the related work,we introduce the combination of the separation of concernsprinciples realized by the notion of views and the separa-tion of abstraction levels realized by the MDD paradigmas a better solution for supporting traceability in process-driven SOAs. We exploit the notion of views to efficientlyrepresent different process concerns such that stakeholdersare provided with tailored perspectives by view integrationmechanisms according to their specific needs, knowledge,and experience. This is a significant step toward the supportof adapting process representations and trace dependencies

to particular stakeholder interests. In addition, the separationof abstraction levels offers appropriate intermediate layers togradually bring the business experts working at high levelsof abstraction close to the IT experts working at lower lev-els of abstraction. Using the separation of process concernsin terms of (semi-)formalized views and the view integrationmechanism, the refinement between two adjacent abstractionlevels can be alleviated in a better and more flexible manner.Obviously, the relationships between our modeling artifactssuch as views and view elements are intrinsic and can beretrieved straightforwardly from the view models.

Leveraging these modeling concepts and mechanisms,we perform the mapping of process designs (here: BPMN)onto high-level, abstract views and process implementa-tions (here: BPEL and WSDL) onto low-level, technology-specific views and devise a traceability meta-model that isrich enough to represent the trace dependencies from designto implementation through different abstraction levels anddifferent granularity. Furthermore, our framework is quiteopen for extensibility, such as adding more traceability rela-tionships at finer granularity with adequate specializationsof the ArtifactTrace and the ElementTrace, adding moreintermediate view model layer, or adding more appropriatespecializations of the TraceRationale meta-class to supportenhancing traceability reasoning or change impact analysis.

In the area of process-driven development, there are anumber of approaches that define transformations betweendifferent languages [32–34,44,48,58]. These approachespartially provide the link between process design and imple-mentation. However, most of these approaches focus on onlyone process concern, namely, the orchestration concern, andignore other significant ones, such as collaborations, dataprocessing, fault handling, and so on. As a consequence, eachof these approaches is applicable for transforming of controlstructures of two specific kinds of languages, for instance,BPMN and BPEL [44,48], EPC and BPEL [33,58], and soforth. As a consequence, these approaches offer neither theextensibility to support the various process concerns, exceptthe control flow, nor the traceability of these concerns of pro-cesses. Nonetheless, our traceability approach benefits fromdifferent algorithms described originally in those approachesfor mapping the control flow of process design onto our Flow-View model (cf. Scenario 1).

Table 2 presents qualitative comparisons of our view-based, model-driven traceability approach, VbTrace, and anumber of selected related approaches which are most closelyrelated to VbTrace, such as the MDD-based traceabilityapproaches that utilize model-driven paradigm with mod-eling layers ranging from high-level into low-level and/orexploit model transformations for traceability between designand implementation [3,27,37,57]. The comparison criteriaare adapted from [49].

123

H. Tran et al.

Tabl

e2

The

com

pari

son

ofre

late

dw

ork

TR

AC

ES

byA

lesk

yet

al.

UP

trac

eabi

lity

byM

äder

etal

.M

odel

-bas

edte

stin

gby

Nas

lavs

kyet

al.

M2T

byO

ldev

iket

al.

Gen

eric

MD

Dtr

acea

bilit

yby

Wal

derh

aug

etal

.

VbT

race

Supp

ortf

orm

ultip

letr

ace

rela

tions

[3]

offe

rsth

eR

efer

ence

orR

ealiz

ere

latio

nsbe

twee

nre

quir

emen

tsan

dm

odel

san

dth

eG

ener

ate

rela

tions

betw

een

mod

els

and

code

.Rea

lize

rela

tions

can

bein

ferr

edfr

omab

ove

rela

tions

.

[27]

focu

ses

onfo

urtr

ace

rela

tions

:Refi

ne,

Rea

lize,

Ver

ify,

and

Defi

ne.

[35]

conc

entr

ates

the

trac

ere

latio

nsbe

twee

nm

odel

san

dte

star

tifac

ts.

[37]

focu

ses

onth

etr

ace

rela

tions

betw

een

mod

els,

i.e.,

PSM

s,an

dte

xtge

nera

ted

from

the

mod

els,

i.e.,

Gen

erat

ere

latio

ns.

As

[57]

pres

ents

ahi

ghle

vela

ndge

neri

cso

lutio

nto

trac

eabi

lity

for

MD

D,n

oco

ncre

tetr

ace

depe

nden

cies

are

cons

ider

ed.T

hus,

furt

her

effo

rts

are

requ

ired

tosp

ecia

lize

and

adap

tthe

trac

eabi

lity

and

repo

sito

rym

odel

sto

part

icul

arne

eds.

Supp

ortm

ultip

lere

latio

nty

pes

byth

ean

nota

tion

ofad

equa

teT

race

Rat

iona

les

(cf.

Sect

.3.2

).

Gen

erat

ion

oftr

ace

rela

tions

Cre

atio

nof

expl

icit

trac

eabi

lity

links

betw

een

requ

irem

ents

and

mod

els

isth

ere

spon

sibi

lity

ofth

em

odel

er.T

race

abili

tylin

ksca

nal

sobe

auto

mat

ical

lyre

trie

ved

from

code

gene

ratio

n.

Tra

cede

pend

enci

esar

ees

tabl

ishe

dw

ithad

equa

tein

terv

entio

nsof

stak

ehol

ders

ofU

P.

The

gene

ratio

nof

test

case

san

dre

leva

nttr

acea

bilit

ym

odel

iscu

rren

tlym

anua

l.

Tra

cede

pend

enci

esar

eau

tom

atic

ally

gene

rate

dfr

omm

odel

-to-

code

tran

sfor

mat

ions

.

[57]

mer

ely

refe

rsto

othe

rtr

acea

bilit

yap

proa

ches

for

achi

evin

gtr

ace

depe

nden

cies

such

as[3

7].

Tra

cede

pend

enci

esbe

twee

npr

oces

sde

sign

and

view

s,be

twee

nvi

ews

and

code

are

acco

mpl

ishe

d(s

emi-

)aut

omat

ical

ly,

betw

een

view

san

dvi

ewel

emen

tsar

ere

trie

ved

stra

ight

forw

ardl

y(c

f.Se

ct.4

.3).

Rel

atio

nre

pres

enta

tion

[3]

does

note

xplic

itly

pres

enta

form

aliz

atio

nof

trac

ede

pend

enci

es.

Exi

stin

gU

ML

nota

tiona

lele

men

tsar

eus

edfo

rre

pres

entin

gtr

ace

depe

nden

cies

.Tra

cede

pend

enci

esar

est

ored

inth

eso

urce

code

asan

nota

tions

.

The

trac

eabi

lity

mod

elde

scri

bes

the

rela

tions

hips

achi

eved

ina

typi

calm

odel

tran

sfor

mat

ion

and

ispe

rsis

ted

asan

Eco

rem

odel

.

[37]

defin

esa

met

a-m

odel

prov

idin

ga

seto

fco

ncep

tsfo

rtr

acea

bilit

ybe

twee

nm

odel

elem

ents

and

loca

tions

inco

dear

tifac

ts.

Anu

mbe

rof

high

leve

lm

eta-

mod

els

are

defin

edto

repr

esen

tge

nera

lcon

cept

sof

trac

eabi

lity,

such

astr

ace

mod

el,a

rtif

act

type

,tra

cety

pe,e

tc.a

sw

ella

sth

est

akeh

olde

rsin

tera

ctio

ns.

(Sem

i-)f

orm

aliz

edre

pres

enta

tion

inte

rms

ofa

rich

,ext

ensi

ble

trac

eabi

lity

met

a-m

odel

aim

ing

atsu

ppor

ting

inte

rope

rabi

lity

and

shar

ing

oftr

ace

depe

nden

cies

(cf.

Sect

.3.2

).

123


Tabl

e2

cont

inue

d

TR

AC

ES

byA

lesk

yet

al.

UP

trac

eabi

lity

byM

äder

etal

.M

odel

-bas

edte

stin

gby

Nas

lavs

kyet

al.

M2T

byO

ldev

iket

al.

Gen

eric

MD

Dtr

acea

bilit

yby

Wal

derh

aug

etal

.

VbT

race

Supp

orta

dapt

atio

nof

stak

ehol

der

inte

rest

sN

otsu

ppor

ted

yet.

Not

supp

orte

dye

t.N

otsu

ppor

ted

yet.

Not

supp

orte

dye

t.[5

7]of

fers

anu

mbe

rof

pre-

defin

edst

akeh

olde

rsro

les,

such

asde

velo

per,

trac

eus

er,t

race

abili

tym

anag

er,a

ndto

olsu

pplie

r,w

hoin

volv

ein

the

MD

Dpa

radi

gmbu

tdoe

sno

tpro

vide

mec

hani

sms

tosu

ppor

tthe

adap

tatio

nof

trac

ede

pend

enci

esto

the

vari

ous

stak

ehol

ders

inte

rest

s.

The

com

bina

tion

ofse

para

tion

ofco

ncer

nsan

dse

para

tion

ofab

stra

ctio

nle

vels

isa

sign

ific

ants

tep

tow

ard

supp

ortt

head

apta

tion

ofpr

oces

sre

pres

enta

tions

and

trac

ede

pend

enci

esto

vari

ous

stak

ehol

der

inte

rest

s.M

oreo

ver,

the

Rol

em

eta-

clas

s,a

spec

ializ

atio

nof

Trac

eRat

iona

le,c

anbe

anno

tate

dto

the

trac

elin

ksto

bette

rsu

ppor

tada

ptat

ion

and

reas

onin

gof

trac

ede

pend

enci

esan

dtr

acea

bilit

ypa

thw

ithre

spec

tto

part

icul

arst

akeh

olde

rs.

Supp

orti

nter

med

iate

mod

elin

gla

yers

[3]

supp

orts

trac

eabi

lity

betw

een

requ

irem

ent

and

mod

elel

emen

tsan

dbe

twee

nm

odel

elem

ents

and

code

but

does

notm

entio

nan

ysu

ppor

tfor

inte

rmed

iate

mod

elin

gla

yers

(i.e

.,m

odel

and

code

mer

ely

have

aneq

uiva

lent

abst

ract

ion)

.

[27]

focu

ses

ontr

acea

bilit

ybe

twee

nfo

urab

stra

ctio

nle

vels

ofU

P:re

quir

emen

t,an

alys

is,d

esig

n,an

dim

plem

enta

tion

mod

els.

[35]

use

mod

el-b

ased

cont

rolfl

owgr

aphs

and

test

gene

ratio

nhi

erar

chy

met

a-m

odel

asth

ein

term

edia

tela

yers

betw

een

UM

Lse

quen

cedi

agra

ms

and

test

ing

artif

acts

.

Not

supp

orte

dye

t.[5

7]ne

eds

furt

her

effo

rts

tosp

ecia

lize

the

trac

eabi

lity

mod

el.

Vie

w-b

ased

mod

elin

gfr

amew

ork

offe

rsth

ese

para

tion

ofvi

ews

into

diff

eren

tin

term

edia

tem

odel

ing

laye

rsat

diff

eren

tle

vels

ofab

stra

ctio

n.

Supp

ortf

orm

ulti

ple

gran

ular

itie

sN

otsu

ppor

ted

yet.

[27]

aim

sto

supp

ortt

hetr

acea

bilit

ybe

twee

nba

sic

UM

Lar

tifac

tsof

UP

abst

ract

ion

leve

ls.

[35]

mer

ely

conc

entr

ates

onfin

e-gr

aine

dtr

ace

depe

nden

cies

.

[37]

only

gene

rate

sre

latio

nsbe

twee

nm

odel

elem

ents

and

code

bloc

ks.

[57]

requ

ires

furt

her

effo

rts

tosp

ecia

lize

the

trac

eabi

lity

mod

el.

The

trac

eabi

lity

met

a-m

odel

isri

chan

dex

tens

ible

for

supp

ortin

gre

pres

enta

tion

ofm

any

leve

lsof

gran

ular

ityof

trac

ede

pend

enci

es(c

f.Se

ct.3

.2).

123

H. Tran et al.

Tabl

e2

cont

inue

d

TR

AC

ES

byA

lesk

yet

al.

UP

trac

eabi

lity

byM

äder

etal

.M

odel

-bas

edte

stin

gby

Nas

lavs

kyet

al.

M2T

byO

ldev

iket

al.

Gen

eric

MD

Dtr

acea

bilit

yby

Wal

derh

aug

etal

.

VbT

race

Ext

ensi

bili

tyop

tion

sN

otsu

ppor

ted

yet.

[27]

ism

erel

ybo

und

toU

P/U

ML

.N

otsu

ppor

ted

yet.

Not

supp

orte

dye

t.T

heex

tens

ibili

tyof

[57]

ispo

tent

ial,

how

ever

,re

quir

esad

ditio

nal

effo

rts.

VbT

race

offe

rsth

eex

tens

ibili

tyof

gran

ular

ityle

vels

and

inte

rmed

iate

mod

elin

gla

yers

byre

finin

gei

ther

Trac

eLin

k,A

rtif

actT

race

orE

lem

entT

race

,and

ofth

ese

man

tics

ofth

etr

ace

rela

tions

bysp

ecia

lizin

gTr

aceR

atio

nle

(cf.

Sect

.3.2

).M

oreo

ver,

VbT

race

isno

tbou

ndto

the

proc

ess

conc

erns

exem

plifi

edin

this

artic

lesu

chas

the

cont

rolfl

ow,p

roce

ssco

llabo

ratio

n,an

dda

taha

ndlin

g,bu

tis

exte

nsib

leto

othe

rco

ncer

nssu

chas

tran

sact

ions

,eve

ntha

ndlin

g,hu

man

inte

ract

ions

,etc

.[31

,54]

Tool

supp

ort

Apr

otot

ypic

alde

velo

pmen

ten

viro

nmen

twhi

chca

nbe

inte

grat

edw

ithE

clip

sean

dC

odeB

eam

erfo

rde

velo

pmen

tand

trac

eabi

lity.

Mod

els

are

stor

edin

eith

erX

ML

orX

MI

form

ats.

Not

supp

orte

dye

t.N

otsu

ppor

ted

yet.

Not

supp

orte

dye

t.[5

7]m

erel

yof

fers

age

neri

c,hi

ghle

vel

trac

eabi

lity

appr

oach

aim

ing

atsu

ppor

ting

shar

ing

and

inte

grat

ion

ofto

ols.

No

conc

rete

tool

supp

orts

are

men

tione

d.

Apr

otot

ypic

alE

clip

se-b

ased

inte

grat

eden

viro

nmen

tbas

edon

EM

FM

OF-

com

plia

nce

Eco

rean

dop

enA

rchi

tect

ureW

are

MD

Dfo

rpr

oces

s-dr

iven

SOA

deve

lopm

ent(

cf.

Sect

.4.1

).X

ML

Met

adat

aIn

terc

hang

e(X

MI)

stan

dard

[?]

isut

ilize

dfo

rm

odel

pers

iste

nce,

and

ther

eby,

bette

rsu

ppor

ttr

acea

bilit

ysh

arin

gan

din

tero

pera

bilit

yof

MO

F-co

mpl

iant

tool

s.

123


6 Conclusion

Traceability support in process-driven SOAs developmentsuffers from the challenging gap due to the fact that there isno explicit links between process design and implementationlanguages because of the differences of syntaxes and seman-tics and the difference of granularity and abstraction levels.In addition, the substantial complexity caused by various tan-gled process concerns and the lack of adequate tool supporthave multiplied the difficulty of bridging this gap. The view-based, model-driven traceability approach presented in thisarticle is our effort to overcome the issues mentioned aboveand support stakholders in (semi-)automatically elicitingand (semi-)formalizing trace dependencies between devel-opment artifacts in process-driven SOAs at different levelsof granularity and abstraction. A proof-of-concept Eclipse-based tool support has been developed and illustrated via theCRM Fulfillment process extracted from an industrial casestudy.

The view-based, model-driven traceability frameworkpresented so far lays a solid foundation for change impactanalysis, artifact understanding, change management andpropagation, and other activities. Our ongoing work is tocomplement this framework with a model repository thatalleviates collaborative model-driven development and trace-ability sharing with different stakeholders as well as toolintegrations.

This work was supported by the European Union FP7project COMPAS, grant no. 215175. We are grateful to anon-ymous reviewers for their constructive and truly helpful com-ments.

References

1. ActiveEndpoints (2008) ActiveBPEL Engine. http://www.activevos.com/community-open-source.php. Accessed 3 Febu-rary 2008

2. Aizenbud-Reshef, N., Nolan, B.T., Rubin, J., Shaham-Gafni, Y.:Model traceability. IBM Syst. J. Model-Driven Softw Dev 45(3),(2006). doi:10.1147/sj.453.0515

3. Aleksy, M., Hildenbrand, T., Obergfell, C., Schwind, M.: A prag-matic approach to traceability in model-driven development. In:PRIMIUM (2008)

4. Alexander, I.: Semiautomatic tracing of requirement versions touse cases—experience and challenges. In: TEFSE’03: 2nd Inter-national Workshop on Traceability in Emerging Forms of SoftwareEngineering, (2003)

5. Antoniol, G., Canfora, G., de Lucia, A., Casazza, G.: Informa-tion retrieval models for recovering traceability links between codeand documentation. In: ICSM ’00: Proceedings of the InternationalConference on Software Maintenance (ICSM’00), IEEE ComputerSociety, Washington, DC, USA, p. 40 (2000)

6. Antoniol, G., Canfora, G., Casazza, G., Lucia, A.D., Merlo, E.:Recovering traceability links between code and documentation.IEEE Trans Softw Eng 28(10), 970–983 (2002). doi:10.1109/TSE.2002.1041053

7. Bondé, L., Boulet, P., Dekeyser, J.L.: Traceability and Inter-operability at Different Levels of Abstraction in Model-DrivenEngineering, Springer, Netherlands, pp. 263–273. Applications ofspecification and design languages for SoCs (2006)

8. Constantopoulos, P., Jarke, M., Mylopoulos, J., Vassiliou, Y.: Thesoftware information base: a server for reuse. The VLDB J. 4(1),1–43 (1995). doi:10.1007/BF01232471

9. Eclipse (2006) Eclipse modeling framework. http://www.eclipse.org/emf. Accessed 3 January 2008

10. Egyed, A.: A scenario-driven approach to trace dependency analy-sis. IEEE. Trans. Softw. Eng. 29(2), 116–132 (2003). doi:10.1109/TSE.2003.1178051

11. Evenson, M., Schreder, B.: SemBiz deliverable: D4.1 use case def-inition and functional requirements analysis, (2007). http://sembiz.org/attach/D4.1.pdf

12. Frankel, D.: Model Driven Architecture: Applying MDA to Enter-prise Computing. Wiley, New York (2002)

13. Galvão, I., Goknil, A.: Survey of traceability approaches in model-driven engineering. In: EDOC, pp. 313–326 (2007)

14. Gotel, O., Finkelstein, A.: Contribution structures [requirementsartifacts]. In: Proceedings of 1995 IEEE International Sympo-sium on Requirements Engineering (RE’95), pp. 100–107, (1995).doi:10.1109/ISRE.1995.512550

15. Hayes, J.H., Dekhtyar, A., Osborne, J.: Improving requirementstracing via information retrieval. In: Requirements EngineeringConference. Proceedings 11th IEEE International, pp. 138–147(2003)

16. Hentrich, C., Zdun, U.: Patterns for process-Oriented integrationin service-oriented architectures. In: Proceedings of the 11th Euro-pean Conference on Pattern Languages of Programs (EuroPLoP2006), Irsee, Germany, pp. 1–45 (2006)

17. Holmes, T., Tran, H., Zdun, U., Dustdar, S. (2008) Modelinghuman aspects of business processes—a view-based, model-drivenapproach. In: Schieferdecker, I., Hartman, A., (eds) 4th Euro-pean Conference on Model Driven Architecture Foundations andApplications (ECMDA-FA) 2008. Springer, LNCS, vol. 5095,pp. 246–261

18. IBM (2006) Travel booking process. http://publib.boulder.ibm.com/bpcsamp/scenarios/travelBooking.html. Accessed 17 April2008)

19. Intalio, Inc (2006) Eclipse STP BPMN Modeler. http://www.eclipse.org/bpmn. Accessed 9 May 2008

20. Kindler, E.: On the semantics of EPCs: a framework for resolvingthe vicious circle. In: Business Process Management, pp. 82–97(2004)

21. von Knethen, A., Paech, B., Kiedaisch, F., Houdek, F.: System-atic requirements recycling through abstraction and traceability. In:Requirements Engineering, 2002. Proceedings. IEEE Joint Inter-national Conference on, pp. 273–281, (2002). doi:10.1109/ICRE.2002.1048538

22. Kozlenkov, A., Zisman, A.: Are their design specifications consis-tent with our requirements? In: RE ’02: Proceedings of the 10thAnniversary IEEE Joint International Conference on RequirementsEngineering, IEEE Computer Society, Washington, DC, USA,pp. 145–156 (2002)

23. Letelier, P.: A framework for requirements traceability in UML-based projects. In: Proceedings of the 1st International Workshopon Traceability in Emerging Forms of Software Engineering—17thIEEE International Conference on Automated Software Engineer-ing, pp. 32–41 (2002)

24. Lindvall, M., Sandahl, K.: Practical implications of traceability.Softw Pract Exp 26(10), 1161–1180 (1996). doi:10.1002/(SICI)1097-024X(199610)26:10<1161::AID-SPE58>3.3.CO;2-O

25. Lucia, A.D., Fasano, F., Oliveto, R., Tortora, G.: Recoveringtraceability links in software artifact management systems using

123

http://www.activevos.com/community-open-source.php

http://www.activevos.com/community-open-source.php

http://dx.doi.org/10.1147/sj.453.0515

http://dx.doi.org/10.1109/TSE.2002.1041053


http://dx.doi.org/10.1007/BF01232471

http://www.eclipse.org/emf

http://www.eclipse.org/emf



http://sembiz.org/attach/D4.1.pdf

http://sembiz.org/attach/D4.1.pdf

http://dx.doi.org/10.1109/ISRE.1995.512550

http://publib.boulder.ibm.com/bpcsamp/scenarios/travelBooking.html

http://publib.boulder.ibm.com/bpcsamp/scenarios/travelBooking.html

http://www.eclipse.org/bpmn

http://www.eclipse.org/bpmn

http://dx.doi.org/10.1109/ICRE.2002.1048538

http://dx.doi.org/10.1109/ICRE.2002.1048538

http://dx.doi.org/10.1002/(SICI)1097-024X(199610)26:10<1161::AID-SPE58>3.3.CO;2-O



H. Tran et al.

information retrieval methods. ACM Trans Softw Eng Methodol16(4), 13 (2007). doi:10.1145/1276933.1276934

26. Lucia, A.D., Oliveto, R., Tortora, G.: Adams re-trace: traceabilitylink recovery via latent semantic indexing. In: ICSE ’08: Proceed-ings of the 30th International Conference on Software Engineering,ACM, New York, NY, USA, pp. 839–842. doi:10.1145/1368088.1368216 (2008)

27. Mäder, P., Philippow, I., Riebisch, M.: A traceability link modelfor the unified process. In: SNPD (3), pp. 700–705 (2007)

28. Mader, P., Gotel, O., Philippow, I.: Rule-based maintenance of post-requirements traceability relations. In: International RequirementsEngineering, 2008. RE ’08. 16th IEEE, pp. 23–32. doi:10.1109/RE.2008.24 (2008)

29. Maletic, J.I., Munson, E.V., Marcus, A., Nguyen, T.N.: Using ahypertext model for traceability link conformance analysis. In:TEFSE’03: 2nd International Workshop on Traceability in Emerg-ing Forms of Software Engineering (2003)

30. Marcus, A., Maletic, J.I.: Recovering documentation-to-source-code traceability links using latent semantic indexing. In: ICSE’03: Proceedings of the 25th International Conference on SoftwareEngineering, pp. 125–135, IEEE Computer Society, Washington,DC, USA (2003)

31. Mayr, C., Zdun, U., Dustdar, S.: Model-driven integration and man-agement of data access objects in process-driven SOAs. In: Service-Wave, pp. 62–73 (2008)

32. Mendling, J., Hafner, M.: From inter-organizational workflows toprocess execution: generating BPEL from WS-CDL. In: OTMWorkshops, pp. 506–515, (2005). doi:10.1007/11575863_70.http://www.springerlink.com/content/dkmc5vy9fl4j7j4j/

33. Mendling, J., Ziemann, J.: Transformation of BPEL Processes toEPCs. In: Proceedings of the 4th GI Workshop on Event-DrivenProcess Chains (EPK 2005), vol. 167, pp. 41–53, (2005). http://wi.wu-wien.ac.at/home/mendling/publications/05-EPK.pdf

34. Mendling, J., Lassen, K.B., Zdun, U.: Transformation strategiesbetween block-Oriented and graph-oriented process modelling lan-guages. Technical Report JM-200510 -10, WU Vienna (2005)

35. Naslavsky, L., Ziv, H., Richardson, D.J.: Towards traceability ofmodel-based testing artifacts. In: A-MOST ’07: 3rd InternationalWorkshop on Advances in Model-based Testing, pp. 105–114,ACM, New York, NY, USA (2007). doi:10.1145/1291535.1291546

36. OASIS: Business process execution language (WSBPEL)2.0. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf (2007)

37. Oldevik, J., Neple, T.: Traceability in model to text transforma-tions. In: 2nd ECMDA Traceability Workshop (ECMDA-TW),pp. 17–26 (2006)

38. OMG (2003) Model-driven architecture (MDA) Guide V1.0.1.http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf. Accessed 2September 2007

39. OMG: second revised submission to the MOF Model to text trans-formation RFP. 2005, Object Management Group. http://www.omg.org/cgi-bin/apps/doc?ad/05-11-03.pdf (2005a)

40. OMG: unified modelling language (UML) 2.0. http://www.omg.org/spec/UML/2.0 (2005b)

41. OMG: object constraint language(OCL) 2.0. http://www.omg.org/spec/OCL/2.0 (2006)

42. OMG: business process modeling notation (BPMN) 1.1. http://www.omg.org/spec/BPMN/1.1 (2008)

43. openArchitectureWareorg (2002) openArchitectureWare—a modular MDA/MDD generator framework. http://www.openarchitectureware.org. Accessed 23 October 2007

44. Ouyang, C., Dumas, M., ter Hofstede A.H.M., van der AalstW.M.P.: From BPMN process models to BPEL web services. In:IEEE International Conference on Web Services, pp. 285–292(2006)

45. Pohl, K.: PRO-ART: enabling requirements pre-traceability. In:ICRE, pp. 76–85 (1996)

46. Ramesh, B., Dhar, V.: Supporting systems development by captur-ing deliberations during requirements engineering. IEEE. Trans.Softw. Eng. 18(6), 498–510 (1992). doi:10.1109/32.142872

47. Ramesh, B., Jarke, M.: Toward reference models for requirementstraceability. IEEE. Trans. Softw. Eng 27(1), 58–93 (2001). doi:10.1109/32.895989

48. Recker, J., Mendling, J.: On the translation between BPMN andBPEL: conceptual mismatch between process modeling languages.In: Eleventh International Workshop on Exploring Modeling Meth-ods in Systems Analysis and Design (EMMSAD’06), pp. 521–532(2006)

49. Spanoudakis, G., Zisman, A.: Software traceability: a roadmap,vol. 3, Handbook of Software Engineering and KnowledgeEngineering: Recent Advances edn, World Scientific Publish-ing, pp. 395–428. http://www.ecsi-association.org/ecsi/main.asp?l1=library&fn=def&id=514 (2005)

50. Spanoudakis, G., Zisman, A., Pérez-Miñana, E., Krause,P.: Rule-based generation of requirements traceabil-ity relations. J. Syst. Softw. 72(2), 105–127 (2004).doi:10.1016/S0164-1212(03)00242-5. http://www.sciencedirect.com/science/article/B6V0N-4B5BH76-1D/2/ee36ef777944b21af3c03a604ec521f7

51. Stahl, T., Völter, M.: Model-Driven Software Development: Tech-nology, Engineering, Management. Wiley, New York (2006)

52. Tran, H., Zdun, U., Dustdar, S.: View-based and Model-drivenapproach for reducing the development complexity in process-driven SOA. In: Intlernational Conference on Business Processand Services Computing (BPSC), GI, LNI, vol. 116, pp. 105–124(2007)

53. Tran, H., Zdun, U., Dustdar, S (2008) View-Based reverseengineering approach for enhancing model interoperabilityand reusability in process-driven SOAs. In: Mei H (ed.), 10thInternational Conference on Software Reuse, ICSR 2008,Springer, LNCS, vol. 5030, pp. 233–244. doi:10.1007/978-3-540-68073-4_23

54. Tran, H., Holmes, T., Zdun, U., Dustdar, S. (2009) Modeling pro-cess-driven SOAs—a view-based approach, handbook of researchon business process modeling edn, Information Science Ref-erence, chap 2. http://www.igi-global.com/reference/details.asp?ID=33287

55. W3C (1999) XML Path Language (XPath) 1.0. http://www.w3.org/TR/xpath. Accessed 8 July 2008

56. W3C (2001) Web Services Description Language 1.157. Walderhaug, S., Stav, E., Johansen, U., Olsen, G.K.: Traceabil-

ity model-driven software development, information science refer-ence, pp. 133–160. Designing software-intensive systems—meth-ods and principles (2008)

58. Ziemann, J., Mendling, J.: EPC-Based modelling of BPEL Pro-cesses: a pragmatic transformation approach. In: Proceedings ofthe 7th International Conference “modern information technol-ogy in the innovation processes of the industrial enterprises”(MITIP 2005), (2005). http://wi.wu-wien.ac.at/home/mendling/publications/05-MITIP.pdf

59. Zisman, A., Kozlenkov, A.: Managing inconsistencies in UMLspecifications. In: Proceedings of the ACIS Fourth InternationalConference on Software Engineering, Artificial Intelligence, Net-working and Parallel/Distributed Computing (SNPD’03), October16–18, 2003, Lübeck, Germany, ACIS, pp. 128–138 (2003)

60. Zisman, A., Spanoudakis, G., Pérez-Miñana, E., Krause, P.: Trac-ing software requirements artifacts. In: Proceedings of the Interna-tional Conference on Software Engineering Research and Practice,SERP ’03, June 23–26, 2003, Las Vegas, Nevada, USA, CSREAPress, pp. 448–455 (2003)

123

http://dx.doi.org/10.1145/1276933.1276934

http://dx.doi.org/10.1145/1368088.1368216

http://dx.doi.org/10.1145/1368088.1368216

http://dx.doi.org/10.1109/RE.2008.24

http://dx.doi.org/10.1109/RE.2008.24

http://dx.doi.org/10.1007/11575863_70

http://www.springerlink.com/content/dkmc5vy9fl4j7j4j/

http://wi.wu-wien.ac.at/home/mendling/publications/05-EPK.pdf

http://wi.wu-wien.ac.at/home/mendling/publications/05-EPK.pdf

http://dx.doi.org/10.1145/1291535.1291546

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf

http://www.omg.org/cgi-bin/apps/doc?ad/05-11-03.pdf

http://www.omg.org/cgi-bin/apps/doc?ad/05-11-03.pdf

http://www.omg.org/spec/UML/2.0

http://www.omg.org/spec/UML/2.0

http://www.omg.org/spec/OCL/2.0

http://www.omg.org/spec/OCL/2.0

http://www.omg.org/spec/BPMN/1.1

http://www.omg.org/spec/BPMN/1.1

http://www.openarchitectureware.org

http://www.openarchitectureware.org

http://dx.doi.org/10.1109/32.142872

http://dx.doi.org/10.1109/32.895989

http://dx.doi.org/10.1109/32.895989

http://www.ecsi-association.org/ecsi/main.asp?l1=library&fn=def&id=514

http://www.ecsi-association.org/ecsi/main.asp?l1=library&fn=def&id=514

http://dx.doi.org/10.1016/S0164-1212(03)00242-5

http://www.sciencedirect.com/science/article/B6V0N-4B5BH76-1D/2/ee36ef777944b21af3c03a604ec521f7



http://dx.doi.org/10.1007/978-3-540-68073-4_23

http://dx.doi.org/10.1007/978-3-540-68073-4_23

http://www.igi-global.com/reference/details.asp?ID=33287

http://www.igi-global.com/reference/details.asp?ID=33287

http://www.w3.org/TR/xpath

http://www.w3.org/TR/xpath

http://wi.wu-wien.ac.at/home/mendling/publications/05-MITIP.pdf

http://wi.wu-wien.ac.at/home/mendling/publications/05-MITIP.pdf


Author Biographies

Huy Tran is a PhD student atthe Distributed Systems Group,Institute of Information Systems,Vienna University of Technol-ogy, Austria. Huy received hisBachelor (2002) at Ho Chi MinhCity University of Technologyin Computer Science and Engi-neering. His research interestsinclude domain-specific model-ing, model-driven engineering,SOA and process-driven SOAs,and business process modeling.

Uwe Zdun is an assistantprofessor at the DistributedSystems Group, Institute ofInformation Systems, ViennaUniversity of Technology, Aus-tria. Prior to that, Uwe hasworked as an assistant professorin the Department of Informa-tion Systems at the Vienna Uni-versity of Economics and BA,Austria. His research interestsinclude software patterns, soft-ware architecture, SOA, distrib-uted systems, language engineer-ing, and object orientation. Hereceived his doctoral degree in

computer science from the University of Essen in 2002, and his habilita-tion degree (venia docendi) from Vienna University of Economics andBA in 2006. He is coauthor of the books Remoting Patterns (John Wiley& Sons, 2004) and Software-Architektur (Elsevier/Spektrum, 2005).

Schahram Dustdar is a FullProfessor for Internet Technol-ogies and director of the Dis-tributed Systems Group, Instituteof Information Systems, ViennaUniversity of Technology (TUWien). He is also Honorary Pro-fessor of Information Systemsat the Department of Comput-ing Science at the Universityof Groningen (RuG), The Neth-erlands. He received his M.Sc.(1990) and PhD. degrees (1992)in Business Informatics from theUniversity of Linz, Austria. InApril 2003 he received his habil-itation degree (venia docendi) inComputer science.

123

VbTrace: using view-based and model-driven development to ... · process concerns that multiplies...

Documents

Transcript of VbTrace: using view-based and model-driven development to ... · process concerns that multiplies...