architecture compliance checking at run-time

Information and Software Technology 51 (2009) 1586–1600

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

Architecture compliance checking at run-time q

Dharmalingam Ganesan a,*, Thorsten Keuler b, Yutaro Nishimura c

a Fraunhofer Center for Experimental Software Engineering (CESE), 5825 University Research Court Suite 1300, College Park, Maryland 20740-3823, USAb Fraunhofer Institute for Experimental Software Engineering (IESE), Fraunhofer-Platz 1, 67663 Kaiserslautern, Germanyc Ricoh Company, Ltd, 8-13-1 Ginza, 104-8222 Chuo-ku, Tokyo, Japan

a r t i c l e i n f o

Article history:Available online 5 July 2009

Keywords:Run-time monitoringArchitecture compliance checkingHierarchical Colored Petri nets

0950-5849/$ - see front matter � 2009 Elsevier B.V. Adoi:10.1016/j.infsof.2009.06.007

q A preliminary version of this paper was presenteConference on Quality Software (QSIC 2008) [7].

* Corresponding author. Tel.: +1 240 487 2915; faxE-mail addresses: [email protected] (D. G

se.fraunhofer.de (T. Keuler), [email protected] (

a b s t r a c t

In this paper, we report on our experiences with architecture compliance checking – the process ofchecking whether the planned or specified software architecture is obeyed by the running system – ofan OSGi-based, dynamically evolving application in the office domain. To that end, we first show howto dynamically instrument a running system in the context of OSGi in order to collect run-time traces.Second, we explain how to bridge the abstraction gap between run-time traces and software architec-tures, through the construction of hierarchical Colored Petri nets (CP-nets). In addition, we demonstratehow to design reusable hierarchical CP-nets. In an industry example, we were able to extract views thathelped us to identify a number of architecturally relevant issues (e.g., architectural style violations,behavior violations) that would not have been detected otherwise, and could have caused serious prob-lems like system malfunctioning or unauthorized access to sensitive data. Finally, we package valuableexperiences and lessons learned from this endeavor.

� 2009 Elsevier B.V. All rights reserved.

1. Introduction

The Japanese office equipment manufacturer Ricoh CompanyLtd. develops Multi-Function Peripherals (MFPs) that have severalfunctions, such as copy, scan, print, and facsimile. In the future,subsidiaries of Ricoh should be able to customize and extend thefunctionality by plugging in components, and thus enriching thefeature set provided by the MFP. Moreover, these MFPs are notgoing to be stand-alone devices: they will be more and more inte-grated into highly dynamic enterprise systems. All these businessrequirements drive Ricoh to invest into software architectures.

Fraunhofer supports Ricoh in exploring architectural challengesfor MFPs, which are long-lived products and have to undergo manyreleases for many customers with hard deadlines. Thus, in order toavoid architecture degeneration during evolution, Ricoh decided tointroduce a systematic architecture compliance checking ap-proach. Architecture compliance checking has been proven to bea usable and useful approach for avoiding architecture degenera-tion (e.g., see [6,12,16,23]).

Manually inspecting a running system for its architectural com-pliance is nearly an impossible task, for many practical reasons. Gi-ven the size and complexity of typical industrial systems, it is

ll rights reserved.

d at the Eighth International

: +1 240 487 2960.anesan), thorsten.keuler@ie-

Y. Nishimura).

almost impossible to inspect the control and dataflow of a runningsystem for architectural compliance. Furthermore, manual inspec-tion is not possible if the system changes in the field (e.g., on-the-fly component updates). Thus, a systematic, automated, built-inapproach is necessary for monitoring the running system for archi-tectural compliance.

Existing approaches address the problem by extracting theimplemented architecture using static code analysis and then com-paring it to the planned architecture. If relationships among codeelements are known before run-time, these methods work well.In general, this scenario is not necessarily true for systems thatare based on frameworks (e.g., OSGi [18]), or that adapt dynami-cally at run-time (e.g., on-the-fly component updates [20,30]). Inthe office domain, run-time adaptation is becoming more andmore important. For instance, software services might be down-loaded and installed on customer site or office devices are inte-grated at run-time with other devices in order to supportintelligent workflow management.

Run-time analysis approaches published in the literature usu-ally do architectural analysis in an offline mode, that is, after thesystem’s execution. For systems that never terminate, adapt orevolve dynamically [17], however, we need to be able to monitorthe running system in a non-intrusive manner, and perform archi-tectural compliance checking at run-time itself. This capabilitywould help in earlier detection of significant problems, such as ille-gal access to sensitive data and the system malfunctioning due toinappropriate usages of MFP components by the software exten-sions plugged-in by the subsidiaries of Ricoh. Thus, we believe it

http://dx.doi.org/10.1016/j.infsof.2009.06.007

mailto:[email protected]




http://www.sciencedirect.com/science/journal/09505849

http://www.elsevier.com/locate/infsof

Fig. 1. Sample Petri net. Fig. 2. Petri net after firing the transition T1 in Fig. 1.

D. Ganesan et al. / Information and Software Technology 51 (2009) 1586–1600 1587

is crucial to do appropriate system monitoring and architecturalcompliance checking in order to avoid such kind of problems. Tothat end, we evaluated a prototype version of the MFP using theDiscoTect method [27].

In this paper, we present our experiences and adaptations of theDiscoTect method, which supports architectural view extraction atrun-time. More specifically, we present an approach for collectingrun-time traces from systems based on the OSGi framework. Wethen demonstrate our approach for bridging the abstraction gapbetween run-time traces and software architectures for the goalof architectural compliance checking. We will show how to sys-tematically design hierarchical Colored Petri nets (defined in Sec-tion 2) for that goal.

Structure of the Paper: In Section 2, preliminary concepts and ouradaptations of the DiscoTect method are presented. In Section 3,the proposed approach is explained. In Section 4, the approach isapplied on Ricoh’s MFP prototype. In Section 5, experiences andlessons learned, effort data, limitations of the approach, and feed-back of developers and architects are presented. In Section 6, theexisting closely related research literature is discussed and com-pared. In Section 7, conclusions are drawn.

2. Preliminaries and Adaptations of DiscoTect

The concepts of hierarchical Colored Petri nets are the mainbuilding blocks of this article. Thus, we first give definitions andsome examples for comprehending the rest of the article. Second,we briefly introduce the DiscoTect method and our adaptationsin order to apply it in practice.

Petri net: A Petri net consists of places, transitions, and directedarcs [22]. Arcs run between places and transitions, never betweenplaces or between transitions. The places from which an arc runs toa transition are called the input places of the transition; the placesto which arcs run from a transition are called the output places ofthe transition. In Fig. 1, P1, P2, P3, and P4 are places, and T1 and T2are transitions. The dot within a place is called a token. P1, P3, and

Fig. 3. The DiscoTect archite

P4 have one token. Places may contain any non-negative numberof tokens. A distribution of tokens over the places of a net is calleda ‘‘marking”.

A transition of a Petri net may fire whenever there are tokens atall input places; when it fires, it consumes these tokens, and placestokens at all output places (see Fig. 2). In Fig. 1, T1 can fire, but T2cannot fire because P2 has no tokens. A firing is atomic and there-fore a single non-interruptible step. In general, the execution ofPetri nets is nondeterministic: when multiple transitions are en-abled at the same time, any one of them may fire.

Colored Petri net: In basic Petri nets, tokens do not have anystructure, that is, they do not hold data. In a Colored Petri net(CP-net), tokens are data holders according to certain data typeor schema definitions. Every place in a CP-net is assigned a datatype, and every token inside a place is an instance of the corre-sponding type. Every transition of a CP-net contains a precondition(e.g. a conditional expression) based on input places. If the precon-dition is true then the transition will fire, and tokens from the in-put places that satisfy the precondition will be consumed. For adetailed discussion of CP-nets, we refer the reader to [9,22,29].

Hierarchical Colored Petri net: The CP-net models of large realworld systems often contain a vast amount of places and transi-tions, making it very hard to analyze, visualize, maintain, and reuseparts of them in other contexts. Hierarchical CP-nets help us to bet-ter organize CP-nets. In a hierarchical CP-net, in addition to placesand transitions, we can use so-called sub-CP-nets. The input oroutput of a CP-net to sub-CP-nets is modeled by pins. Conceptually,pins can be considered as places, too. They help to connect differ-ent CP-nets in a hierarchical CP-net.

Since hierarchical CP-nets are basically CP-nets, hereafter weuse CP-nets and hierarchical CP-nets synonymously.

2.1. Adaptations of the DiscoTect method

The DiscoTect method: Fig. 3 shows the architecture of the Dis-coTect method. The focus of the DiscoTect method is to extract a

cture (figure from [27]).

Define Goal Define Mapping Define Probes ConstructCP-nets

Execute System Evaluate Extracted Views

Phase 1

Phase 2

Define Goal Define Mapping Define Probes ConstructCP-nets

Execute System Evaluate Extracted Views

Phase 1

Phase 2

Fig. 4. Steps of the approach.

1588 D. Ganesan et al. / Information and Software Technology 51 (2009) 1586–1600

Component–Connector view (C–C) [4] from a running system. APipe-and-Filter architectural style is an example of a C–C view,where Filters are Components and Pipes are Connectors. The es-sence behind the DiscoTect method is to define a mapping be-tween the planned architecture style (e.g., Pipe-and-Filter) andimplementation style (i.e., coding conventions). For example, amapping can be stated as follows: every instance of a class inher-ited from the ‘‘Filter” class is considered a ‘‘Filter” component. Byformalizing such mappings using CP-nets, the sequence of run-time events (e.g., call events, object creation events) is inter-preted in terms of architecturally significant events (e.g., creationof components, connectors). The mapping language, with thesemantics of CP-nets, used in DiscoTect is called DiscoSTEP inFig. 3.

Adaptations: We attempted to apply the DiscoTect method toMFP. However, due to the following issues that appeared duringour evaluation of the DiscoTect, we had to adapt various compo-nents (shown in Fig. 3) of the DiscoTect method in the followingways.

First, we had to enable run-time data collection in order to han-dle unknown components that will enter the system at run-time.Since the DiscoTect method does not provide any facilities to dothat, we developed a load–time weaving approach for run-timedata collection. This adaptation corresponds to ‘‘Probes” in Fig. 3.An approach for run-time data collection is presented in Section3.3.

Second, we had to decouple the DiscoTect method from itsmapping language called DiscoSTEP, used for specifying a map-ping between the planned architectural style and implementa-tion style. The DiscoSTEP specification is automaticallyconverted into to CP-nets in order to extract the run-time archi-tecture. In our evaluation, we found bugs in this automatic con-version step. Due to the prototypical state of the tool at the time,we decided not to use the DiscoSTEP language. Thus, we useexisting general-purpose CP-net languages. That is, we define amapping between the planned architectural style and its imple-mentation using CP-nets which are modeled using a commer-cial-off-the-shelf component called Exspect [29]. Through thisadaptation, we take advantage of easy-to-use and freely availabletools that support CP-net construction, execution, testing, anddebugging. To summarize, we used the Exspect functional pro-gramming language instead of the DiscoSTEP language for mod-eling the CP-nets.

Third, we had to extract sequence diagram in order to checkbehavioral compliance at run-time. This capability is not ad-dressed in the DiscoTect method. We adopted our approach suchthat we are not only able to check architecture-level structuralcompliance but also check for architecture-level behavior compli-ance such as the ordering of messages exchanged betweencomponents.

Fourth, we had to adapt the architecture visualization tool(called ‘‘Architecture Builder” in Fig. 3) to our context. For integ-rity reasons – since we already had a well-established tool forarchitecture visualization – we used the Fraunhofer SAVE (Soft-ware Architecture Visualization and Evaluation) tool [6], insteadof the ACMEStudio tool used by the DiscoTect method. Per se,the SAVE tool alone cannot automatically extract and visualizeC–C views (e.g. Pipes-and-Filters). This tool only considers low-level code relations, such as function/method calls, variable ac-cess, and include/import as connectors. Hence, the run-timeinteractions among components through connectors (e.g., pipes,RPC) are not shown. However, the SAVE tool supports the importfeature of external data that allow users to visualize any depen-dency model extracted from other tools and methods. We usedthat import capability to visualize the architecture extractedfrom our approach presented in this paper.

3. Approach

The problem that our approach addresses is to check whether arunning system is in compliance with the planned architecture. Tosolve this problem, we need to resolve a number of technical chal-lenges. In the subsequent sections, we first present these chal-lenges, and then we give a brief overview of the proposedapproach. Finally, we go into the technical details of the approach.

3.1. Challenges in architectural compliance checking

1. Monitoring the system, even in the field, to collect run-timeevents (e.g., call events) in a non-intrusive way. This should alsoinclude the capability to handle such systems where compo-nents can enter at run-time.

2. Bridging the abstraction gap between low-level run-time eventsand high-level architectural elements.

3. Handling of interleaved run-time events. While the system is run-ning, different events partially contribute to architectural ele-ments, and thus, the traces are interleaved with respect to thearchitecture.

4. Managing different interests. Not all run-time events are of rele-vance to all architectural views. For example, a thread startevent is of interest to a process or execution view, but not toa module view, where implementation relations are ofrelevance.

5. Storing the extracted architectural views in an appropriate formatfor further analysis and visualization by external tools.

3.2. Overview of the approach

In order to tackle the above challenges, the proposed approachis decomposed into two major phases (see Fig. 4). In the following,we explain how different steps address the challenges.

Phase 1 starts with the definition of goals. That is, at an architec-tural-level goals define the concerns that need to be monitored. Forinstance, a goal definition can be stated as ‘‘check whether the run-ning system follows the Pipe-and-Filter architectural style”. Sincethere is an abstraction gap between software architectures andthe system implementation, we define a mapping between themto tackle challenge 2. This mapping is used as input to define probes(i.e., monitoring code) and to construct CP-nets. Probes are used tocollect traces from the running system. The idea is to do selectiveinstrumentation of the target system in order to avoid unnecessaryrun-time traces. Our approach for defining probes is illustrated indetail in Section 3.3 in order to address the challenge 1.

We formalized the mapping definition using CP-nets, becausethey are proven to be a sound formalism for modeling concurrentsystems that expose challenges similar to challenge 3 (i.e., inter-leaving of events). As mentioned before, the DiscoTect method ex-ploits CP-nets for bridging the abstraction gap between run-time

Fig. 5. OSGi framework – Bundle concept.


events and architectures. CP-nets are constructed in order to ex-tract architectural views from run-time traces. In other words,CP-nets encode meta-models of the planned architectural views,and produce instances of the meta-models as output. In Section3.4, we present our meta-models to demonstrate how run-timetraces, software architectures, and CP-nets are put to worktogether.

In Phase 2, the system under analysis is executed, in a monitor-ing mode, using different use-cases or scenarios. This will generatethe run-time events as an input for the CP-nets that emit the actualarchitecture when the preplanned patterns are recognized. Afterthat, the extracted architecture is analyzed either at run-time oroffline.

3.3. Run-time trace collection with the OSGi framework

For trace collection, instrumentation has been used tradition-ally. However, the instrumentation of a system usually has to bedone before the system is compiled. Consequently, instrumenta-tion done before running the system is not capable of reflecting dy-namic system changes at run-time. Since MFPs are utilizing theOSGi framework, there are some other challenges to face due tothe fact that components may enter the system whose implemen-tation is not known a priori.

In order to address this issue, we followed an aspect-orientedapproach [14]. The motivation for applying aspect-oriented pro-gramming is mainly driven by the fact that the code for instrumen-tation and the implementation of unknown components isseparated per definition. Conceptually, aspects are considered aperfect fit since aspects modularize crosscutting concerns. Modu-larity is achieved by separating crosscutting code from the basecode using so-called pointcuts. Pointcuts are used for specifyingthe places in the base code where the crosscutting code (advice)should be placed. In our case, the advice was the instrumentationcode that we wanted to place at particular places in the base code.For this reason, we implemented an AspectJ weaver that realizesload–time weaving in the OSGi framework [13].

Load–time weaving in the context of OSGi, however, turned outto be an unexpected challenge. On the one hand, we had to over-come conceptual issues in the realm of selective instrumentation.On the other hand, we needed to realize our solution concepts witha given technology. The technological solutions turned out to be ona very detailed level of granularity since we needed to solve OSGiissues on the platform level. In the following we elaborate on theconcrete solutions that arose in the endeavor of run-time instru-mentation within the OSGi framework.

With OSGi applications or components (coming in the form ofbundles) can be remotely installed, started, stopped, updated anduninstalled without requiring a reboot (see Fig. 5). A service regis-try allows bundles to detect the addition of new services, or the re-moval of services, and adapt accordingly. With respect to aspect-orientation, a couple of approaches supporting load–time or run-time weaving already exist. When it comes to integrating aspect-oriented approaches with the OSGi platform, however, two issuesarise. The first issue concerns the adaptation of aspect weavingto the restricted class visibility among bundles within OSGi. Sinceeach OSGi bundle has its own class loader defined, there is no stan-dard way for accessing classes that are located in different bundles.However, this capability is essential in order to put the instrumen-tation code together with the bundle code. If a bundle wants to ac-cess services of another bundle, the bundle has to request theservice registry. However, the bundle to be accessed at run-timehas to be determined before compile-time. In that case, the OSGiregistry returns a reference to the bundle that provides the appro-priate service. After that, the requestor can submit a request to thebundle that was looked up in the registry. The bundle internal clas-

ses, however, are not visible to other bundles per se (e.g. if the re-quired bundle packages are not explicitly exported and importedrespectively). This raises problems when aspects have to be woveninto a new bundle entering the system at run-time.

Due to these restrictions imposed by the platform, the connec-tion between incoming bundles and the respective aspect bundlescan be established during load–time the earliest. That implies thatwe need to completely decouple aspect code from componentcode. Therefore, the second issue arising can be regarded as a con-sequence of the solution to the first issue. A mechanism needs tobe provided for separating the weaving information from compo-nents that can be utilized during class loading.

To support a clear separation of advice and its referred point-cuts, we partitioned the aspect into two parts. The first part isthe advice logic (containing the instrumentation logic) and the sec-ond part is the pointcut implementation (coming with each com-ponent individually). To that end, we created a bundle that is incharge of holding the advices (the so-called AspectProvider). Allother bundles that are determined for weaving bring their specificpointcut implementation. At that point we stress the fact that theadvice logic and the pointcut implementations are decoupledcompletely.

3.3.1. Class loadingAs stated earlier, the class visibility is restricted to the scope of

the respective bundle, and therefore, the separation of advice andpointcut causes some problems. For that reason we developed acustomized class loading concept for OSGi. Assuming the Aspect-Provider bundle running, we dynamically create a special class loa-der each time a new bundle is being started. This customized classloader (‘‘Intermediate class loader”) is initialized with a referenceto the class loader of the AspectProvider bundle, and at the sametime, as an extension of the newly entered bundle’s class loader(see Fig. 6). Using that construct, we exploit the java class loadingmechanism by overriding specific methods, so the Intermediateclass loader always finds the required classes.

The resulting class loading process is then working as follows:

(1) Apply the standard way the framework deal with class load-ing – loadClass().

(2) In case the class could not be found, the request is forwardedto the Intermediate class loader (ICL) – loadClass().

(3) ICL uses – findLoadedClass().

Fig. 6. Creating an ‘‘Intermediate class loader” as a connector to the aspect’s classes.


(4) Finally, ICL delegates to the class loader of the Aspect Pro-vider bundle – loadClass().

3.3.2. The weaving processTo successfully cope with load–time aspect weaving two impor-

tant challenges have to be solved:

1. Determination of the classes and the advices that need to bewoven.

2. Support of loading dynamically constructed classes.

Extension mechanisms can be used for elegant coping with bothof these challenges within the OSGi environment. The OSGi frame-work supports a mechanism to attach one bundle (called fragment)to another (called host). A fragment attached to the system bundleis called extension bundle. Extensions therefore can be used to in-sert additional functionality into the framework that is required forall running bundles. The Equinox implementation of OSGi providesa convenient way to implement and attach extension bundles. Atthat point, our concept exploits the same mechanisms as theyare used in the AOSGi project [1]: hookable adaptor. In particular,we use ClassLoadingHook as well as BundleWatcherHook for per-

aop.xml

ClassA

EDCL

ClassPath-Manager

Hook

ClassLoaderManager

Bundle1

org.weaver.hookex

findClass(ClassA)

processClass(ClassA)

resolveWeaver(Bundle1)

weave

mat

define(ClassA’)

ClassA’

ClassA’1

2

3

4

7

Fig. 7. Overview of the

forming our weaving strategy. ClassLoadingHook provides function-alities to manipulate class loading via the method processClass (seeStep 2 in Fig. 7). Hook objects are initialized by the adaptor duringthe launch of the framework.

The extensions-based aspect weaving approach comprises twophases: An initialization phase and a weaving phase.

3.3.3. Initialization phaseThe initialization phase is performed by an extension bundle

called org.weaver.hookextension. It contains a class called Hook thatimplements ClassLoadingHook and BundleWatcher. We manipulateclass loading by replacing the base class loader of all bundles bya class loader that is capable of resolving all classes within theAspectProvider bundle’s class space. To that end, Hook creates andsets an instance of ExtendedDefaultClassLoader (EDCL) as base classloader for all the bundles that are starting. EDCL enhances Default-ClassLoader and provides the class loading strategy described be-fore. That is, EDCL possesses an instance of an ICL that can beused to load classes that are placed in the AspectProvider bundle.So we are able to intercept class loading of all bundles in orderto launch class weaving before a class is defined by the EDCL.The EDCL performs standard class loading (Step 1 in Fig. 7) if theRun-timeWeaver bundle is not started. (Remark: In this case, theRun-timeWeaver bundle also contains the advice logic.)

3.3.4. Weaving phaseConsidering the Run-timeWeaver bundle running, the actual

weaving phase is initialized in case a particular application bundlethat has an aop.xml file (see Fig. 8) defined tries to load a class. Inthis example, we specify to advise all calls to the constructor of theclass CopyFilter. However, here we do not specify how the callsshould be advised. The advice logic is defined in the abstract aspect(see Fig. 9).

Please note that initially the extends-attribute of the aspect isempty. That is, the bundle coming with this description is notaware of the aspects that potentially use its pointcut definitions.By replacing the empty string with the name of the aspect that issupposed to be woven during load–time, we will be able to instan-tiate the abstract aspect as it is used by the aspect bundle. The

AJWeaver

ICL

Abstract-Aspect

RuntimeWeaver

OSGi-framework

tension

(ClassA)

ch(Aspects)

weave(ClassA)ClassA’

ClassA’

5 6

weaving process.

Fig. 8. Aspect definition with a concrete pointcut.

Fig. 9. Aspect definition using an abstract pointcut.

Fig. 10. Merged meta-model.

Table 1Sample data type definitions of architectural elements and run-time events andinheritance relation (�: high-level token, +: low-level token).

Data type Data type definition

Entity* archId:String, parentId:String, implId:StringRelation* source:Entity, target:EntityMessage* source:Entity, target:Entity, message:String,Init+ constructor:String,instance_id:String,args:List,Call+ Method:String, caller_obj:String,callee_obj:String, args:ListInherit+ derived_class:String, base_class:String


bundle holds a reference to the ICL that is provided by Hook toEDCL invoking it to resolve classes in Step 2 in Fig. 7. The ICLaccomplishes Steps 3 and 4 in the presented class loading schema.The decision whether to start weaving a particular class can bemade by looking at only those bundles that contain a ‘‘META-INF/aop.xml” representation of concrete aspects. This mechanismalso enables a dynamic match between concrete and abstractpointcuts (see Step 5 in Fig. 7). In the example given by Fig. 9,we refer to a Java method (generateEvent()) that prints log dataof a certain format: [name of the class, created object address].Note that the pointcut filterContructors() does not have an imple-mentation at that point.

The Run-timeWeaver is responsible for the actual weaving. Thebundle has a factory that is used by Hook to instantiate AJWeaverclasses for all bundles having aop.xml files defined. AJWeavermatches all concrete and abstract pointcuts using their namesand extends the concrete pointcut definitions of the respectivebundles at load–time. That is, the extends-attribute as shown inthe aop.xml in Fig. 8 would be changed to extends=”Probe_Aspect”.After this step, the aspect advices are eventually ‘‘connected” to theconcrete bundle pointcuts. Then, the AspectJ API can be used toperform the weaving (see Step 6 in Fig. 7). The woven class is thenpassed back to EDCL for defining the class in the bundle’s scope.

In the context of architecture compliance checking we wereable to successfully instrument incoming OSGi bundles by usingthis approach. The load–time weaving in the OSGi context enabledus to conduct selective instrumentation of bundles to keep the pro-filing as well as the instrumentation code within acceptable limits.

3.4. Modeling run-time traces and software architectures using CP-nets

This section elaborates on the role of CP-nets in the context ofencoding architectural abstractions. In other words, we describehow CP-nets connect the world of run-time traces with the worldof architectural abstractions. In the world of CP-nets, tokens areused to model control- and dataflow. Therefore, the inputs andoutputs of CP-nets are always tokens that are stored in places.

Every place in a CP-net has a data type. Hence, every token has adata type (see ‘‘CP-Net” in Fig. 10). We treat both the input (run-time traces) and output (architectural views) as tokens. Equiva-lently, we define data types for both of them. Therefore, data typesare viewed as the ‘‘interfaces” that connect the three differentworlds (see Fig. 10). An architectural view is defined as a set of

architectural elements that are arranged according to a topology.A topology defines the meta-model of a view. Table 1 containssome sample data types and definitions of architectural elementsand run-time events. Note that the inheritance relation is a static

Fig. 12. Approach in action.


relation. We extracted this relation at load time of classes, usingreflection mechanisms which offer methods for identifying theparent of a class. Here, the main message is that we model archi-tectural elements and run-time events as tokens with certain datatypes.

Thus, the purpose of CP-nets is to emit ‘‘high-level” tokens thatrepresent architectural elements by using ‘‘low-level” tokens thatrepresent run-time events. Our CP-nets extract a set of all architec-tural elements collected from the planned architectural views, andleave the task of visualizing the views to other external programs.

Table 2 presents how the elements of CP-nets are interpreted inthe context of architectural compliance checking. The execution ofCP-nets follows the path shown in Fig. 11. When a run-time eventoccurs (Step 1), a token is generated that is put into all appropriateplaces in the CP-net. Places are appropriate in case that they matchthe respective run-time event type. After that, the CP-net precon-ditions will be evaluated (Step 2) and transitions will be enabledaccording to the semantics of the CP-net (Step 3). Finally, the ex-tracted architectural element will be placed in the places thatmatch the architectural element type (Step 5). That is, all compo-nents and connectors will be placed in the respective places ofthe CP-net.

4. Architecture compliance checking in action

Fig. 12 shows an overview how the different parts are supposedto work together in practice.

The running system produces traces, and the traces are fed intoCP-nets that emit architectural elements when preplanned archi-tectural patterns are recognized. The architecture compliance

Table 2Interpretation of CP-net elements.

CP-netelement

Interpretation Comments

Place A place either refers to a type ofrun-time event or it a type of anarchitectural element

We model every run-time eventtype as a place in CP-nets. Forexample, a Call event type has aCP-net place in our CP-nets. Wealso store the extractedarchitectural elements in theplaces of the CP-nets

Token A token either refers to a singlerun-time event of a certain typeor an instance of an architecturalelement of certain type

For example, every call event is atoken in the place of type Call

Transition The precondition that formalizesthe mapping between thearchitectural elements and thecorresponding codingconventions or implementationstyle

The mapping specifies how tointerpret low-level events interms of architecture. Thisspecification is formalized usingpreconditions of transitions

Fig. 11. Execution view on CP-nets.

checker, which is also a collection of CP-nets, inspects the stateof CP-nets for architectural violations. Eventually, the architecturebuilder reads architecturally relevant tokens from CP-nets andvisualizes the extracted architecture. In a sense, the system is‘‘compiled” together with the CP-nets that are responsible forarchitecture extraction and compliance checking at run-time. JMS(Java Messaging Service) was used as an event bus to pass therun-time events collected by probes to CP-nets. The reasons forusing JMS were: (1) JMS supports both synchronous and asynchro-nous messaging services. Hence, a running program can put tracesto a queue and keep running. (2) The running program and the CP-nets can run anywhere. This set-up is interesting for embedded sys-tems like MFP because we can also do reverse engineering activi-ties on a computer and the actual system can run on the actualdevice. The CP-net feeder program reads the run-time data fromthe JMS bus and passes them to the CP-nets in the Exspect tool.

To apply our approach on the MFP example, we followed theprocess depicted in Fig. 4; now, we instantiate each of the steps.

4.1. Step 1 – Define goal

The goal is to check whether the MFP implementation is com-plaint to the planned Pipe-and-Filter (P–F) architectural style.There are many filters and pipes in the implementation, and oneof the goals is to extract actual dependencies among filters viapipes in order to check whether style properties or constraintsare obeyed by the implementation. In addition, the MFP design rulespecifies that every filter component should register to the con-nected filters for error handling reasons, before exchanging anydata between them. Traditionally, the P–F style does not allowsuch dependencies among filters, but the MFP needed them. Thus,the goal is also to extract a message sequence view to show thatfilters indeed register with connected filters before passing anydata.

4.2. Step 2 – Define mapping

Since there are many ways the P–F style could be implemented,the architects of MFP define a mapping. In the mapping, the imple-mentation style (also called coding conventions) of architecturalelements is specified. It states how filters, ports, and pipes are ex-pected to be implemented in the system. In the MFP case, the fol-lowing fragment of the implementation style is followed:

Filter: Every instance of a class that inherits from the root class‘‘Filter” is a filter.Pipe: Every instance of the class ‘‘Pipe” is a pipe.

Fig. 13. CP-net for pipe initialization.

Fig. 14. Hierarchical CP-nets for extraction of the P–F style.


Write port: A write port should only be created on a filter thefirst time it writes some data to a pipe instance. In addition,whenever the filter writes to a different ‘‘pipe” instance, a cor-responding write port should also be created on the filter.Read port: A read port should only be created on a filter the firsttime it reads some data to a pipe instance. The implementationof MFP follows the observer pattern to realize the P–F style.That is, pipes are observable and filters are observers. When afilter wants to read from a pipe, it first has to register to thepipe. The pipe then calls the registered filter whenever thereis some data in the pipe.Filter connection: If a filter writes to a pipe object and anotherfilter reads from the same pipe object, then we conclude thatthe filters are architecturally connected.

4.3. Step 3 – Define probes

We developed a collection of aspects to collect low-level eventsand used our load–time weaver to instrument the OSGi bundles ofMFP. It is important to note that we do not instrument the com-plete system. We used the mapping definition of the previous stepto instrument only those portions of the code which are relevantfor extracting architectural views. This particular step might beiterative if data analyses raise new questions.

4.4. Step 4 – Construct CP-nets

We will now show how CP-nets can be used to formalize themapping defined in Step 2 and in order to extract architecturalviews. We explain how to design CP-nets in such way that they be-come reusable across a set of systems that follow the same imple-mentation style for realizing the intended architectural views.

4.4.2. Defining token data typeBefore constructing CP-nets, we need to define data types for

architectural elements and low-level events.According to the goal definition, we need to extract the compo-

nent-connector view of the Pipe-and-Filter (P–F) architecture. Thearchitectural elements and data types relevant to these views arelisted in Table 3. Using the mapping specification, we identifiedthe list of low-level events, such as Init and Call (see Table 1), thatare relevant to extracting the architectural elements.

4.4.3. A sample CP-netHere, we introduce a simple CP-net that emits a pipe id when-

ever an instance of pipe is created. The intention is to give a feelingof CP-nets to those readers who are not familiar with this formalmethod.

Table 3Data type of P–F elements.

Architecturalelement

Datatype

Data type definition

Filter Entity archId – name of the filterparentId – not used hereimplId – instance id of the filter class

Read Port Entity archId – name of the portparentId – name of the filter that reads from theportimplId – instance id of the pipe used by the filter

Write Port Entity Similar to Read Port(i.e., Write instead of Read)Port Connector Relation source – Write port

target – Read portMessage Message source – Filter

target – Filtermessage – method name

In Fig. 13, the places init_event and pipe_id are of the type Initand String, respectively (see Table 1). The transition InitPipe waitsfor an init event and fires if appropriate preconditions are satisfied.Recall that the mapping specification states that every instance of aclass ‘‘Pipe” is a pipe.

We can formalize this specification in the Exspect functionallanguage as follows:

Precondition1: init_event@constructor = ‘Pipe’Action: pipe_id init_event@instance_idEvery time the InitPipe transition fires, a single token (a dot

within the circle) that satisfies the precondition from init_event isconsumed and a new token is produced in pipe_id.

4.4.4. Constructing a hierarchy of CP-netsA hierarchical CP-net is a CP-net that contains one or more CP-

nets. The main motivations for using hierarchical CP-nets for ourcontext are:

� Sub-CP-nets can be tested independently.� Sub-CP-nets are reusable for extracting architectural elements

that are also present in other systems that are implemented inthe same style.

� Sub-CP-nets are understandable by humans, as they are typi-cally small and conceptually isolated modules.

The core idea is that each sub-CP-net emits a part of the archi-tecture to be extracted; composition of these sub-CP-nets into asingle CP-net emits the complete architecture. A fragment of ahierarchical decomposition of CP-nets for the P–F style is shownin Fig. 14.

The root level CP-net is composed of sub-CP-nets, namely,‘‘Pipe-and-Filter” and ‘‘Filter to Filter Call”. The former CP-net emitsarchitecture models for the P–F style, while the latter emits any di-rect dependency from one filter to another filter using methodcalls. At the next level of decomposition, the ‘‘Pipe-and-Filter”sub-CP-net is composed of sub-CP-nets for filter creation, port cre-ation, initialization of pipes, and attachment of filters.

In this way, every CP-net is decomposed further until it is a sep-arate module on its own. To improve the reusability of CP-nets, wefollow a layered design of CP-nets. We hide implementation-spe-cific details at lower layers; thereby, we can reuse the top-levelstructure.

1 x@y refers to field y of data type x. x = y means ‘‘if x is equal to y”. x y means ‘‘y isassigned to place x.”


4.4.5. Execution of CP-netsHere, we show a brief collection from our library of CP-nets

based on the above decomposition. Each CP-net emits a certaintype of architectural elements of the P–F style; composition ofthese CP-nets into a single CP-net produces the whole P–F architec-ture style.

Common conventions of all CP-nets: The black boxes are also CP-nets. The circles with ‘‘i” (input pin) and ‘‘o” (output pin) in all theCP-nets denote the input/output from/to other CP-nets.

The data types for the places are shown in Table 4.The Exspect tool supports a simulation mode where the flow of

tokens among CP-nets can be visualized. In fact, the user can openeach CP-net in a separate window, and visualize follow of tokens atrun-time in each window. Here, we summarize the execution orsimulation of CP-nets for our CP-nets that recognize the Pipe-and-Filter architectural style.

Creating filters: The CP-net that creates filters (see Fig. 15) emitsfilter tokens in the output pin ‘‘filter_holder” by waiting for aninstantiation of classes that inherit from the base class ‘‘Filter”(as per the mapping definition).

Every token of the place ‘‘child_of_filter” denotes a class derivedfrom the base class ‘‘Filter”. The ‘‘CreateFilter” transition will fire ifthere is a token in the place ‘‘init_event” whose constructor or classname is the same as a token in the place ‘‘child_of_filter”. Note thatit also gives back the token to ‘‘child_of_filter” because many in-stances of the class derived from the base class ‘‘Filter” can be cre-ated during program execution. If the transition did not give backthe token, the ‘‘CreateFilter” would not be able to create more thanone filter.

The precondition and action for creating filters are:Precondition: init_event@constructor=child_of_filterAction: filter_holder init_event@constructor + init_event@

instance_idchild_of_filter init_event@constructorThe precondition checks whether the created instance of a class

is an instance of a child class of the ‘‘Filter” base class. If the pre-condition is true, then a filter component is created with nameas the name of the constructor with the unique object instance id.

The CP-net that emits all children of the base class (see Fig. 16)is composed with the filter creation transition ‘‘CreateFilter” usingthe output pin.

Table 4Data types for the places of CP-nets.

Place name(s)a Data type

filter*, write_port*, read_port*, *_filter Entityport_connection_holder RelationMessage_holder Messageinit_event Initcall_event Callinherit_event Inheritchild_of_filter, *pipe_id* String

ax* and *y refer to the places with a starting and ending name x and y, respectively.

Fig. 15. The CP-net for filter creation (Rule_CreateFilter).

We can formalize the CP-net for recognizing children of thebase class ‘‘Filter”:

Precondition: inherit_event@base_class=’Filter’Action: child_of_filter inherit_event@derived_classCreating ports: The CP-net for creating read ports (see Fig. 17)

waits for filter tokens (‘‘filter_holder” pin) and pipe tokens(‘‘pipe_id” pin) from other CP-nets. If the filters read data fromthe pipes, using an appropriate method call (placed in ‘‘call_-event”), then read ports are emitted in the place ‘‘read_-port_holder”. Note that this CP-net gives back the filter tokens(‘‘filter_holder” pin acts both as an input and output pin). Other-wise, the filter token would be lost, and we could not create morethan one read port in a filter. Similarly, the CP-net for write portcreates write ports on those filters that write to pipes.

Attaching filters: The CP-net for attaching filters (see Fig. 18)waits for read and write port tokens, and emits tokens that containa pair of attached write and read ports in the place ‘‘port_connec-tion_holder”. A write port is attached to a read port if a filter writesdata to a pipe object and another filter reads from the same pipeobject. The ‘‘message_holder” place contains the abstract logicalmessage ‘‘processData” when two filters are attached. The ‘‘mes-sage_holder” is used for drawing sequence diagrams to show theordering of data flow from one filter to another.

Putting the building blocks together: Once the building blocks areconstructed they have to be composed in order to emit architec-tural elements. To compose the building blocks, the Exspect toolprovides a GUI where the user has to connect the input/output pinsof sub-CP-nets to appropriate places in the above CP-nets in thedecomposition hierarchy.

The Composition of Sub-CP-nets follows a convention: If a tokenis needed as an input to more than one sub-CP-net, then tokenmultiplexing is performed.

For instance, both of the CP-nets that create read and writeports require pipe tokens as inputs (see Fig. 19). To pass the pipetokens to those CP-nets, we create a transition ‘‘Multiplex_pipe_id”that does nothing but just copying the pipe token into two places,

Fig. 16. The CP-net for Rule_GetFilterChildren.

Fig. 17. The CP-net for Rule_CreateReadPort.

Fig. 18. The CP-net for Rule_AttachFilter.

Fig. 19. The CP-net for P–F (Rule_CreatePipeAndFilter).


namely, ‘‘pipe_id_1” and ‘‘pipe_id_2”. All transitions with a namestarting with ‘‘Multiplex” are token multiplexers.

Creating a Message Sequence View from run-time traces involvesextracting components and messages exchanged among them. Forthe MFP case, every filter is treated as a component. Thus, we donot create separate CP-nets for the extraction of components; in-stead, we reuse the output filters of the ‘‘CreateFilter” CP-net,shown in Fig. 15. In case a filter makes a direct method call to an-other filter, the invoked method name is used as the messagename. This scenario is handled by the CP-net ‘‘Rule_Filter_2_Fil-ter_Call” (see Fig. 20). This CP-net monitors all calls and selectsthose calls whose source and target objects have already beenidentified as filters. Instead of a direct method call, if two filtersare attached through a pipe, we emit an abstract logical message‘‘processData” from the source filter to the target filter.

In Fig. 18, the CP-net ‘‘AttachFilters” emits such a token in theplace ‘‘message_holder”.

Storing the extracted views: We store the extracted views as acollection of architectural elements in the form of tokens. To thisend, the architectural elements of the views, namely the compo-nent-connector view and the message sequence views, are storedin the root level CP-net (see Fig. 21).

This CP-net is the result of composing the two sub-CP-nets dis-cussed before. The architectural elements, such as filters, readports, write ports, pipes, and messages are stored in the places ‘‘fil-ter_holder_copy”, ‘‘read_port_holder”, ”write_port_holder”,”port_connection_holder”, and ‘‘message_holder”, respectively.

To summarize, the whole process of developing CP-netsfollowed fundamental principals of software engineering [21], suchas abstraction, modularity, encapsulation, and composition. Thehierarchical decomposition of CP-nets into building blocks resultedin a modular design of CP-nets, where each module encapsulatesits design decision. For instance, the CP-net for creating a read port

Fig. 20. The CP-net for Rule_Filter_2_Filter_Call.

(see Fig. 17) on a filter does not know how the filter was created; itjust has filter tokens as an input to the transition.

4.5. Step 5 – Execute system (mfp)

As mentioned earlier, huge portions of the functionality of MFPsis based on the OSGi platform. The MFP filters are implemented asOSGi bundles. We start the so-called OSGi bundles and triggermany scenarios (e.g., scan, copy, resize papers, etc). The emittedtraces eventually reach our CP-nets, which extract architecturalelements and store them as tokens.

4.6. Step 6 – Evaluate extracted views

In this step, the goal is visualize and evaluate the architecturethat is stored as tokens in CP-nets places.

From the CP-nets places, an external program reads the tokensand prepares a visualization of architectural views. In our case, weautomatically converted the architecture stored as tokens into thedata format followed in our SAVE tool. Fig. 22 is visualized usingour SAVE tool, where boxes are filters and arrows are pipes. TheSAVE tool is not yet capable of visualizing ports. Thus, the readand write ports of filters are not shown in this figure.

Apart from visualizing the actual architecture at run-time, wealso evaluate whether the extracted architecture complies withthe intended architectural properties. That is, we check whetherthe architectural style constraints are not violated. In the MFPexample, we check the P–F style properties, such as:

Fig. 21. The root level CP-net.


(a) Every filter should have a read or write port.(b) Every write port should be connected to a read port.(c) A filter either reads or writes to a single pipe, but not both.(d) No two filters should make a direct method call.(e) Every filter is connected to at least one other filter through a

pipe.

Since the extracted architecture is stored as tokens in the CP-nets, we developed a library of reusable CP-nets to automaticallyverify such style-specific properties. Note that the CP-nets thatcheck for style constraints violations are reusable due to their inde-pendence from implementation details. Thus, the same CP-netscould be used to check architecture compliance across systemswith the same planned architectural style, independent of theway the style is implemented.

In the following, we summarize the major results of compliancechecking.

Unused filters are detected. Our analyses revealed that instancesof filters had been created that were never used during the systemexecution.

Unused pipes are detected. In our CP-nets, the place that holdspipe tokens should ideally be empty after the MFP execution, butthis was not always the case. Some pipes were created, and therewas no reading or writing to them. Discussions with the architectof the MFP exposed the reasons: Every filter is responsible for cre-ating its input pipes. Thus, input filters have input pipes, but noother filter writes to them. Hence, their input pipes were neverused.

Direct method calls from filters to filters are detected: However,this turned out not to be an architecture violation in the MFP case:At run-time, for error handling reasons, filters are allowed to makecertain direct calls to other filters. Even though filters can directlycommunicate in MFP, there are some protocols they must follow.For example, a filter is not allowed to send the ‘abort’ signal toother filters; users have to explicitly activate it from the GUI. Itwas expected that the design itself would enforce that rule, butwe identified a violation: A filter could send an ‘abort’ signal toother filters. Such violations can be detected at run-time, moreinterestingly even before the system crashes.

Application-specific P–F style constraints are validated: Theplanned architecture of the MFP defines three types of filters: in-put, process, and output. There are some protocols with respectto the data flow from one type of filter to another. For example, aprocess filter is not allowed to pass data to input filters. These con-straints were validated with the help of the CP-nets.

The extracted message sequence views capture behavioral as-pects of the software over time. In MFPs, every filter must directlyregister itself to its connected filters for error handling reasons be-fore passing any data (see Fig. 23). The underlying idea was to en-able an efficient backward propagation of failure events thatshould cause the stalling of the current data pipeline in order toavoid situations that are hard to recover from. Using the extracted

Fig. 22. A sample extracted C–C view.

message sequence view, we confirmed that the running systemdoes follow that design rule.

5. Discussion

This subsection presents: (a) experiences and lessons learned,(b) effort data, (c) benefits and limitations, and (d) feedback fromdevelopers or architects of MFP.

5.1. Experiences and lessons learned

In this section, we present the experiences that we madethroughout the application of our approach for architecture com-pliance checking at run-time. We align our experiences along thedifferent phases that the approach is comprised of.

Phase 1

Step 1: Define goalGoal definition is the most important step in the compliancechecking process. It is worthwhile to spend time on clar-ifying the goals of run-time monitoring, that is, what kindof architectural views are to be extracted for validation.The goals help (a) to define probes in a disciplined way(selective instrumentation) and, (b) to construct appropri-ate CP-nets for the views of interest.

Step 2: Define mappingHuman expert availability is important for constructing CP-nets and Probes. The approach is best applied in thosecontexts where there is an architect who can define amapping between architectural elements and traces. Ifno such architect is available, we think it is probably veryhard to do compliance checking.

Step 3: Define probesIt is important to separate the monitoring code and sourcecode. As we know, the source code of non-trivial systemsis already complex. Adding the monitoring code for qual-ity assurance purposes within the source code furtherincreases the complexity. Moreover, it will be very hardto (a) switch-on and switch-off the monitoring code and(b) to reuse the monitoring code in similar contexts. Thus,we recommend clearly separating the monitoring concernfrom the source code, using technologies such as AspectJ.Run-time trace collection requires significant effort. Giventhat our system is implemented in Java, we thought wecould quickly write some aspects to get traces. However,this was not as easy as it sounds, as all our componentsare OSGi bundles that have their own class loaders, whichmakes aspect weaving a challenging task. Moreover, weneeded methods in order to collect trace data while thesystem is running in a dynamic context: bundles comeand go. Fortunately, we could work out load–time weav-ing concepts to overcome this problem. Although theseare low-level technical issues related to data collection,

Fig. 23. A sample extracted message sequence view.

Table 5Effort data for architecture compliance checking.

Activity �Hours

Detailed study of the DiscoTect method and its prototype 60Learning about CP-nets and the Exspect tool 40Interview with a developer/architect 10Development of aspects for trace collection 50Construction of CP-nets for MFP 90

Table 6Size of the MFP prototype under study.

Property Value


we have to keep in mind that data collection is an impor-tant and critical task for run-time monitoring and archi-tecture compliance checking.AspectJ is non-intrusive: Although we have not quantifiedthe overhead due to monitoring, we did not observe anynotable difference in the response time before and afterthe instrumentation. Thus, we are of the view that AspectJis non-intrusive. However, it is also worth mentioningthat we have done selected instrumentation using thegoal definition, as explained earlier.Load–time weaving approach is necessary and useful forautomatic instrumentation of OSGi applications. In thiscase study, the user of the system is not at all aware thatthe running system is monitored. This was achieved usingour load–time weaving approach, which seamlesslyinjects monitoring code whenever a new OSGi bundleenters the system. The emitted run-time data is then usedto extract the actual architecture, which can be used byengineers as a starting point for their detailed diagnosisand debugging of errors, if any. Using our approach, wewere able to run the system, and simultaneously visualizeits actual architecture in more or less real-time. The archi-tectural views get updated if architecturally significantevents happen at run-time.

Step 4: Construct CP-netsConstructing CP-nets is an iterative process. Although itmight appear that our CP-nets are constructed in onestep, this is not true. Given that CP-nets are used to for-malize the implementation style based on the knowledgeshared by architects, it is hard to gather that knowledgevery precisely in the first step. In our case, we had threeiterations to precisely model the implementation style.Nevertheless, the benefits of constructing CP-nets wereworth the investment.Layered Design Improves the Reusability of CP-nets. Toimprove the reusability of CP-nets, we recommend a lay-ered design of CP-nets. That is, hide implementation-spe-cific details at the lower layers of CP-nets. In this way, thetop-level structure can be reused in other systems. Also,by following the modularity principle in the design ofCP-nets, we can reuse parts of the CP-nets to extractarchitectural elements that are implemented in the samestyle in other systems. On the other hand, the CP-nets thatcheck the completeness (e.g., architectural style viola-tions) of the extracted views can be reused as is, becausethey are free from any implementation style.Hierarchically decomposition of CP-nets controls design com-plexity. Like source code, CP-nets can also quickly becomecomplex as more and more places and transitions areintroduced. We believe by carefully decomposing thedesign of CP-nets into hierarchies we would be able tobetter understand and maintain them.CP-nets should betested. Problems like deadlock, livelock, starvation, etc.,occurred in our initial CP-nets. After some verificationeffort, we were able to fix these problems. If we thereare design errors in CP-nets, then the extracted softwarearchitecture may not be the actual architecture of therunning system. Thus, it is crucial to spent effort on test-ing and verification of CP-nets. We found that the actualeffort may depend on the modularity of CP-nets. In thefuture, we intend to apply automated model checking ofCP-nets using tools that looks for potential design errorsin the CP-nets.

Number of statements 22,651Number of classes 603Number of methods 3375

Phase 2Step 1. Execute the system.

The running system should cover a lot of code: The extractedarchitectural facts are as good as the code coverage. This is a gen-eral problem with dynamic or run-time analysis. In the MFP case,we executed many scenarios specified in the use cases. In addition,we used code coverage tools to measure coverage at class levels inorder to ensure that we covered all the classes related to the P–Fstyle.

5.1.3. General experiencesUniform coding convention helps architectural compliance check-

ing. As explained earlier, the proposed approach relies on codingconventions to develop probes and CP-nets. If architectural ele-ments are implemented with different coding conventions withinthe system, then both the probes (i.e., aspects) and also the precon-ditions of the CP-nets should be made aware of all coding conven-tions. Otherwise, the extracted architecture will not be a completeand correct representation of the running system. Multiple codingconventions increase the design complexity of probes and CP-nets,making architectural compliance checking more difficult.

Scalability of the approach. Although our study was done on aprototype of an MFP, we are optimistic about the scalability ofthe approach because of the modularity of CP-nets. Our CP-nets en-code meta-models of architectural views to be extracted. Forexample, our CP-nets for the P–F style can be used on systems withany number of filters and pipes, as long as the same implementa-tion style of the P–F is followed. Of course, with the assumptionthat a good tool like Exspect is used to model and run the CP-nets.

Applicability to other architectural styles. Although we demon-strated the approach on the pipe-filter architectural style, the ap-proach itself is not limited to this style. Recently, we applied theapproach on another system based on the JAVA’s Remote MethodInvocation (RMI) architectural style. While it was not possible toreuse any of the CP-nets developed for the pipe-filter style to thearchitecture and implementation based on RMI, experiences withour first endeavor helped us to come with a good design of hierar-chical CP-nets for RMI. In this case, it was more the reuse of pro-cesses than the reuse of product artifacts such as CP-nets orprobes. However, the CP-nets designed for RMI would be reusablefor all systems based on RMI.

5.2. Effort data

The approximate effort we spent on various steps of architec-tural compliance checking is given in Table 5. To relate the effortto the system under study, we list some size metrics in Table 6.In order to apply an existing method developed by other research-ers, we first needed to learn all details of the method. Some un-


planned effort was also spent on debugging the DiscoTect proto-type. As a consequence, we decided to adopt the method to ourown tool chain. Since we had no practical experience with CP-nets,we also spent effort on learning about CP-nets and related tools. Inorder to construct CP-nets, the implementation conventions haveto be collected. For that purpose, we interviewed a developer/architect. He explained the coding conventions/style correspond-ing to the architectural elements.

Note that the time spent on aspects development for the tracecollection does not include the development time of our general-purpose framework for load–time weaving into the OSGi platform[13]. It is not a trivial effort to break down CP-nets into a library ofreusable CP-nets. Thus, our major effort was spent on constructingCP-nets. Since the planned software architecture does not neces-sarily change frequently, this effort is spent only once per system.We anticipate that this effort will go down if we construct CP-netsfor other architectural styles, because of the potential to reuseknowledge and experience from this endeavor.

5.3. Benefits

By using the OSGi bundle technology, Ricoh subsidiaries pro-vide new components on demand to extend the MFP softwarefunctionality of their customers. Anticipating the way Ricoh’ssubsidiaries customize and use Ricoh components is difficult. Itmight happen that they violate the usage protocols of Ricoh’s com-ponents, which would pose the risk of system crashes or malfunc-tioning. To avoid such problems, the system needs to be monitoredat run-time for architecture compliance so that constructive steps(e.g., notify service engineers) can be taken if a violation occurs.Our experience with the approach indicates that CP-nets can alsobe deployed within MFPs in order to detect such kinds of problemseven in the field.

5.4. Limitations

Besides the listed benefits, we also identified a few limitations.Although a running system might comply with its architecture, itmight not obey timing properties. For example, there are require-ments like p pages should be copied in m minutes. There shouldbe some way (e.g., using timed CP-nets) to monitor and notify tim-ing violations of components or connectors. One limitation is re-lated to probes: currently the probes (for trace collection) andCP-nets are constructed manually, requiring significant time andeffort. While it might not be possible to completely eliminate thiseffort, some ways to automatically generate them from theplanned architectural style and the mapping definition wouldmake the method more appealing in practice. Finally, how to adaptthe running system in response to architectural violations is anopen issue.

5.5. Developer/architect feedback

When the approach was presented to Ricoh’s developers andarchitects, there were many questions at the beginning, in particu-lar referring to CP-nets. Also, many people were not that familiarwith aspect-oriented programming. Once the fundamentals ofCP-nets and aspects were clarified, they showed quite a lot of inter-est in the approach. During the execution of CP-nets in the Exspecttool, the visualization of the flow of tokens among places attractedtheir attention. Moreover, they liked the fact that the approachdoes not change the source code at all. They would prefer havingmore automation support during the design of CP-nets and probes.From the development team’s point of view, one problem inpractice is that maintaining the overall architecture is hard, as sys-tems are getting bigger and bigger with a lot of requirements and

variants offered. The approach presented in this paper takes a stepforward towards resolving this particular practical issue. We areexploring techniques that can construct CP-nets from the plannedbehavioral specifications formalized using sequence diagrams [19],which are relatively more familiar to developers.

6. Related work

The DiscoTect method was the basis of our work. The adapta-tions made were already discussed in the previous sections. Thissection places the DiscoTect method and our adaptations in thecontext of other research work. We avoided citing the relatedworks that were already mentioned in the DiscoTect article [27].

In our conference paper [7], we presented the experiences ofextracting architectures from run-time traces. In this paper, we ad-dressed the following, which were not covered in there:

1. We explained our approach for run-time trace collection on theOSGi framework.

2. We elaborated the experiences and lessons learned.3. We introduced the related work section to position this work in

the context of existing approaches.

Our work is related to (a) techniques that apply CP-nets forarchitecture modeling and evaluation, (b) aspect-oriented run-time monitoring, and (c) architecture extraction using run-timetraces.

6.1. Architecture modeling and evaluation using CP-nets

CP-nets have already been applied to modeling and evaluationof software architectures. The following three references are re-lated to evaluating software architectures before theimplementation.

Gomaa and Pettit [8] validate the dynamic behavior of concur-rent systems that are modeled in UML by automatically convertingUML models into CP-nets. Using the simulation capability of De-sign/CPN toolset, the authors check for concurrency issues, suchas deadlock, livelock, and timing constraints.

Xu and Kuusela [31] model an execution architecture based onPetri nets. A module view is converted into a Petri net, and, using asimulation of the net, the authors identify quality problems, suchas performance and throughput.

Fukuzawa and Saeki [5] apply CP-nets to evaluate quality attri-butes of software architectures. Quality models for reliability, secu-rity, and performance using probabilistic CP-nets with timedtransitions are developed. Using simulation of CP-nets, the authorsperform trade-off analysis among architectural alternatives.

The simulation results are as good as the actual implementationof the planned architecture. Our case study complements their ap-proach by reverse engineering the implemented architecturalviews, which could then be used as an input to build and refinethe simulation models for forward engineering purposes.

6.2. Aspect-oriented monitoring of running systems

In fact, monitoring the behavior of a running system is a con-cern similar to logging. One of the main issues in monitoring isoverhead in terms of memory and response time due to additionalmonitoring code. Aspect-oriented programming has shown to be apromising concept for separating concerns [14] in an efficient way.Furthermore, aspects are developed as separate modules andweaved into the functional code, thereby clearly separating thesystem monitoring code and real code, and can also be switchedoff in case monitoring is not necessary.


Richters and Gogolla proposed a method [25] for checkingwhether behavioral constraints, specified in the OCL language ofUML models, are followed by the implementation. Using the As-pectJ language, the authors validate the running system againstthe expected behavior. Their work focuses on method-level pre-conditions, post-conditions, and invariants checking, in contrastto our focus on software architecture-level conformance checking.

Kiviluoma et al. [11] proposed a run-time monitoring method tovalidate a running system against its expected behavior, which isspecified using UML profiles. From the profiles, the authors auto-matically derive and weave aspects into code to monitor expectedbehaviors. In our case, aspects are not automatically generated. Thepatterns of pointcuts and advice are programmed manually to col-lect run-time traces. Our primary focus was on preparing incomingcomponents for being instrumented before load–time, which wasnot addressed in [11].

Briand et al. [3] proposed a comprehensive methodology for re-verse engineering of sequence diagrams from distributed multi-threaded programs. The unique aspect of their work lies in thesound definitions of meta-models for run-time traces and se-quence diagrams, which are often missing or unclear in other re-ports. Their meta-models include control statements and loops,usually ignored by other tools. So far we have not focused on de-tailed code-level analysis, since we work at an architectural-levelcurrently. Hence, we do not yet collect information regarding con-trol statements and loops.

6.3. Architecture extraction using run-time traces

Riva and Rodriguez [26] combine static and dynamic analysisfor architecture reconstruction. If the system structure is fixedand there are no dynamic updates of software components, thentheir approach works well. They do not distinguish connectorsfrom components. Consequently, dependencies among compo-nents communicating only through connectors (e.g., pipe) cannotbe recovered.

The SAVE tool [6], developed at Fraunhofer, extract both thestructural and behavioral views from source code and run-timetraces, respectively. To build abstraction from low-level raw data,it makes use of the directory structure decomposition. Thus, theresulting views contain components (basically directories or files)and their interactions (e.g., function/method call, variable access).In [15], system of systems is analyzed by extracting the actual se-quence diagram by snooping the data passed in the network. Thatapproach is not applicable for systems whose components commu-nicate only through connectors like pipes.

The pattern-lint tool [24] uses a hybrid approach (i.e., both staticand dynamic analysis) to detect deviations between the plannedarchitecture and the actual architecture implemented in the code.Pattern-lint uses prolog rules to express the planned architecture.By using static analysis, source code relations are extracted andstored as prolog facts. After that, the extracted facts are verifiedusing the prolog rules. In addition to static analysis, the actual sys-tem is executed and a number of views based on the collected run-time data are visualized to mainly detect architectural violations.

The Rigi tool [28] is an environment for visualizing the structureof a system. In general, the Rigi tool can be used to visualize anyhierarchical directed graph. The user can build abstract views fromlow-level dependencies either through automated clustering ormanually through Rigi’s graph editing features, such as collapsing,hiding, etc. The tool has a simple import format allowing the userto import code-level relations, such as call, include, use, etc.Although Rigi has been mainly used for visualizing the staticstructure of a system, it can still be used to visualize dynamicstructure as long as the user obeys its import format. In fact, the

Dali tool [10] from the SEI uses Rigi to visualize the structure ofthe system after merging the static and dynamic relations into asingle database of relations.

Arias et al. [2] identify dependencies among execution entitiesusing dynamic analysis. In addition to program traces emitted bythe running system, they also monitor operating system activitiessuch inter-process communication, task execution, thread, etc.Their approach extracts dependencies among (a) software compo-nents, (b) tasks, and (c) software components and tasks. In our ap-proach, we have not yet focused on the OS-level behavior analysis,which could give a complementary view on the running system.

In all the above approaches, structural and behavioral viewswere extracted after execution of the system using the completetraces, unlike our approach which does architecture compliancechecking at run-time using on-line traces.

7. Conclusions

We presented a method for verifying a running system againstits planned architecture. This method is especially applicable forsystems whose components can enter and leave at run-time, andcommunicate using connectors like pipes. For such classes of sys-tems, statically analyzing the implemented architecture is not suf-ficient. Using dynamic analysis the actual architecture can beextracted at run-time, and can be evaluated for violations of the in-tended style constraints. We have disclosed a new method for sys-tematically instrumenting a running system using ideas fromaspect-oriented programming. Furthermore, we have shown howto bridge the abstraction gap between the collected run-timetraces and the planned software architecture using hierarchicalColored Petri nets (CP-nets).

We successfully applied architecture compliance checking toRicoh’s MFP prototype. To that end, we customized the DiscoTectmethod to our purposes: (a) by directly modeling the mapping be-tween architectural elements and run-time traces using hierarchi-cal CP-nets, which are defined using general-purpose functionalprogramming languages, (b) by developing a tool chain for practi-cally applying the method to overcome the technical barriers of theDiscoTect prototype. We have shown in detail how to systemati-cally design reusable CP-nets.

Our experiences with this approach indicate that there is defi-nitely an up-front investment to construct probes, design, develop,and test CP-nets. But, in our opinion it is worth applying this ap-proach because we can show that both the architecture and therunning system is consistent, otherwise software architecture isjust a hypothesis. For Ricoh’s MFP prototype, architectural viewsand a number of issues, such as unused filters, pipes, and designrule violations in component usages, have been extracted. More-over, the major benefit of the approach is that it can be used tocheck compliance between the running system and the plannedarchitecture at run-time. Ricoh considers this approach to be ofstrong practical relevance for quality assurance. Defining an appro-priate architecture and then checking its compliance at run-timeare emerging as a relevant quality assurance strategy.

Acknowledgements

We appreciated technical discussions of the DiscoTect methodwith Bradley Schmerl at CMU. Van der Aalst and the Exspect teamat Eindhoven University of Technology kindly answered our ques-tions related to the Exspect tool. We thank our colleagues SonnhildNamingha, Matthias Naab, and Jens Knodel for providing valuablecomments. Last, but not least, we thank the anonymous reviewersfor their insightful comments and constructive criticism.


References

[1] AOSGi. <http://www.eclipse.org/equinox/incubator/aspects/>.[2] T.B. Arias, P. Avgeriou, P. America, Analyzing the actual execution of a large

software-intensive system for determining dependencies, in: 15th WorkingConference on Reverse Engineering, 2008.

[3] L.C. Briand, Y. Labiche, J. Leduc, Towards the reverse engineering of UMLsequence diagrams for distributed, multithreaded Java software, IEEETransactions on Software Engineering 32 (9) (2006) 642–663.

[4] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J.Stafford, Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2003.

[5] K. Fukuzawa, M. Saeki, Evaluating software architectures by colored petri nets,in: International Conference on Software Engineering and KnowledgeEngineering, SEKE, 2002.

[6] D. Ganesan, J. Knodel, R. Kolb, U. Haury, G. Meier, Comparing costs and benefitsof different test strategies for a software product line: a study from Testo AG,in: Proceedings of Software Product Line Conference (SPLC), 2007.

[7] D. Ganesan, T. Keuler, Y. Nishimura, Architecture compliance checking atruntime: an industry experience report, in: Proceedings of the eighthInternational Conference on Quality Software, 2008.

[8] H. Gomaa, R. Pettit, Validation of dynamic behavior in UML using colored petrinets, in: Proceedings of the ACM Workshop on Dynamic Behavior in UMLModels: Semantic Questions, York, England, 2000.

[9] K. Jensen, Coloured Petri Nets, Basic Concepts, Analysis Methods and PracticalUse, Springer Verlag, 1993. ISBN: 3-540-60943-1.

[10] R. Kazman, S.J. Carrière, Playing detective: reconstructing softwarearchitecture from available evidence, Journal of Automated SoftwareEngineering 6 (2) (1999) 107–138.

[11] K. Kiviluoma, J. Koskinen, T. Mikkonen, Run-time monitoring of architecturallysignificant behaviors using behavioral profiles and aspects, in: Proceedings ofthe International Symposium on Soft Testing and Analysis, 2006.

[12] R.L. Krikhaar, Software Architecture Reconstruction, PhD Thesis, University ofAmsterdam, 1999.

[13] T. Keuler, Y.A. Kornev, Light-weight Load–Time Weaving Approach for OSGi,Workshop on Next Generation Aspect-oriented Middleware, AOSD, Brussels,2008.

[14] G. Kiczales, J. Lamping, A. Mendhekar, C. Maedar, C. Lopes, J.-F. Loingtier, J.Irwin, Aspect-Oriented Programming, ECOOP, 1997.

[15] M. Lindvall, C. Ackermann, W. Stratton, et al. Using sequence diagrams todetect communication problems between systems, in: IEEE AerospaceConference, 2008.

[16] G. Murphy, D. Notkin, K. Sullivan, Software reflexion models: bridging the gapbetween source and high-level models, in: Proceedings of the third ACMSIGSOFT Symposium on Foundation of Soft Eng, 1995.

[17] P. Oreizy, N. Medvidovic, R. Taylor, Architecture-based runtime softwareevolution, in: Proceedings of the 20th International Conference on SoftwareEngineering (ICSE-98), 1998.

[18] OSGi alliance. <http://www.osgi.org/>.[19] L. Padgham, J. Thangaraja, M. Winikoff, Adding debugging support to the

prometheus methodology, Engineering Applications of Artificial Intelligence18 (2) (2005), 173–190 (Special Issue on Agent-oriented SoftwareDevelopment).

[20] M. Shahabuddin, Component-based, run-time flight software modification, in:Aerospace Conference, 2008.

[21] D.L. Parnas, Designing software for ease of extension and contraction, IEEETransactions on Software Engineering 5 (2) (1979) 128–138.

[22] Petri net. <http://en.wikipedia.org/wiki/Petri_net>.[23] A. Postma, A method for module architecture verification and its application

on a large component-based system, Information and Software Technology 45(4) (2003) 171–194.

[24] T. Richner, S. Ducasse, Recovering high-level views of object-orientedapplications from static and dynamic information, in: Proceedings of theInternational Conference on Software Maintenance (ICSM), 1999.

[25] M. Richters, M. Gogolla, Aspect-oriented monitoring of UML and OCLconstraints, in: AOSD Modeling with UML Workshop, sixth InternationalConference on the Unified Modeling Language, 2003.

[26] C. Riva, J. Rodriguez, Combining static and dynamic views for architecturereconstruction, in: Proceedings of the European Conference on SoftwareMaintenance and Reengineering, 2002.

[27] B. Schmerl, J. Aldrich, D. Garlan, R. Kazman, Y. Hong, Discovering architecturesfrom running systems, IEEE Transactions on Software Engineering 32 (7) (2006).

[28] M.-A. Storey, K. Wong, H.A. Müller, Rigi – A visualization environment forreverse engineering (research demonstration summary), in: IEEE 19thInternational Conference on Software Engineering (ICSE-97), IEEE ComputerSociety Press, 1997, pp. 606–607.

[29] W.M.P. van der Aalst, ExSpect 6.4: An Executable Specification Tool forHierarchical Colored Petri Nets, Lecture Notes in Computer Science, vol. 1825,Springer-Verlag, Berlin, 2000, pp. 455–464.

[30] Frank van der Linden, Jürgen Müller, Creating architectures with buildingblocks, IEEE Software 12 (6) (1995) 51–60.

[31] J. Xu, J. Kuusela, Modeling execution architecture of software systems usingcolored petri nets, in: Proceedings of the International Workshop on SoftwarePerformance, 1998.

http://www.osgi.org/

architecture compliance checking at run-time

Documents