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
VbTrace: Using view-based and model-driven development
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
V3 technology-specific
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
V2 technology-specific
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
VbTrace: Using view-based and model-driven development
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
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
VbTrace: Using view-based and model-driven development
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