Discovering Architectures from Running Systems: Lessons Learned

Discovering Architectures fromRunning Systems

Bradley Schmerl, Jonathan Aldrich, David Garlan, Rick Kazman, and Hong Yan

Abstract—One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its

architectural design. In this paper, we describe a technique that uses runtime observations about an executing system to construct an

architectural view of the system. In this technique, we develop mappings that exploit regularities in system implementation and

architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations

and are formally defined using Colored Petri Nets. In this paper, we describe a system, called DiscoTect, that uses these mappings

and we introduce the DiscoSTEP mapping language and its formal definition. Two case studies showing the application of DiscoTect

suggest that the tool is practical to apply to legacy systems and can dynamically verify conformance to a preexisting architectural

specification.

Index Terms—Software architecture discovery, reverse engineering, architecture design tools and analyses.

Ç

1 INTRODUCTION

A well-defined software architecture is critical for thesuccess of complex software systems. An architectural

model consists of many views (e.g., [24]) of the system. Oneparticularly useful view is the component and connector(C&C) view, which provides a high-level view of a systemin terms of its principle runtime components (e.g., clients,servers, databases), their interactions (e.g., remote proce-dure call, event multicast, piped streams), and theirproperties (e.g., throughputs, latencies, reliabilities) [5],[31], [35]. As an abstract representation of a system, anarchitecture permits many forms of high-level inspectionand analysis, allowing the architect to determine if asystem’s design will satisfy its critical quality attributes.Consequently, over the past decade, considerable researchand development has gone into the development ofnotations, tools, and methods to support architecturaldesign [7], [8], [27].

However, a persistent problem is determining whether asystem as implemented has the architecture with which itwas designed. Without some form of conformance guaran-tee, the validity of any architectural analysis will be suspectat best and completely erroneous at worst.

Two tool-based techniques have been used to determineor enforce relationships between a system’s C&C softwarearchitecture and its implementation. The first is to ensureconsistency by construction. This can be done by embedding

architectural constructs in an implementation language(e.g., as described by Aldrich et al. [2]), where analysistools can check for conformance. Or, it can be done throughcode generation, using tools to create an implementationfrom a more abstract architectural definition [34], [37], [38].

Ensuring consistency by construction is effective whenit can be applied since tools can guarantee conformance;unfortunately, it has limited applicability. In particular, itcan usually be applied only in situations where engineersare required to use specific architecture-based develop-ment tools, languages, and implementation strategies. Forsystems that are composed of existing parts or thatrequire a style of architecture or implementation outsidethose supported by generation tools, this approach doesnot apply.

The second technique is to ensure conformance byextracting an architecture from a system’s code using staticcode analysis [17], [21], [28]. When an implementation issufficiently constrained so that modularization and codingpatterns can be identified with architectural elements, thistechnique can work well. Unfortunately, however, thetechnique is limited by an inherent mismatch betweenstatic, code-based structures (such as classes and packages)and the runtime structures that are the essence of mostarchitectural descriptions [8], [14]. In particular, the actualruntime structures may not even be known until theprogram executes: Clients and servers may come and godynamically, components (e.g., Dynamic Linked Libraries)not under direct control of the implementers may bedynamically loaded, and so forth. Indeed, determining theactual runtime architectural configuration of a system usingstatic analysis is, in general, undecidable.

A third, relatively unexplored, technique is to determinethe architecture of a system by examining its runtime behavior.The key idea here is that a system’s execution can bemonitored. Observations about its runtime behavior canthen, in principal, be used to infer its dynamic architecture.This approach has the advantages that it applies to any

454 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 7, JULY 2006

. B. Schmerl, J. Aldrich, D. Garlan, and H. Yan are with the School ofComputer Science, Carnegie Mellon University, 5000 Forbes Ave.,Pittsburgh, PA 15221.E-mail: {schmerl, aldrich, garlan, yh}@cs.cmu.edu.

. R. Kazman is with the University of Hawaii, 2404 Maile Way, Honolulu,HI, and the Software Engineering Institute, Carnegie Mellon University,5000 Forbes Ave., Pittsburgh, PA 15221. E-mail: [email protected].

Manuscript received 6 May 2005; revised 1 Mar. 2006; accepted 11 July 2006;published online 9 Aug. 2006.Recommended for acceptance by S. Uchitel, I.H. Kruger, M. Broy, andJ. Whittle.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TSE-0143-0505.

0098-5589/06/$20.00 � 2006 IEEE Published by the IEEE Computer Society

system that can be monitored, it gives an accurate image ofwhat is actually going on in the real system, it canaccommodate systems whose architecture changes dyna-mically, and it imposes no a priori restrictions on systemimplementation or architectural style.

However, there are a number of hard technical chal-lenges in making this technique work. The most seriousproblem is finding mechanisms to bridge the abstractiongap: In general, low-level system observations do not mapdirectly to architectural constructs. For example, thecreation of an architectural connector might involve manylow-level steps and those actions might be temporallyinterleaved with many other architecturally relevant ac-tions. Moreover, there is likely no single architecturalinterpretation that will apply to all systems: Differentsystems will use different runtime patterns to achieve thesame architectural effect and, conversely, there are manypossible architectural elements to which one might map thesame low-level events.

In this paper, we describe a technique to solve theproblem of dynamic architectural discovery for a large classof systems. Our key idea and contribution is to provide aframework that allows one to map implementation styles toarchitecture styles. This mapping is defined conceptually asa Colored Petri Net [19] that is used at runtime to track theprogress of the system and output architectural eventswhen predefined runtime patterns are recognized. Thus,the mapping provides a way to identify when a programperforms “architecturally significant” actions that producearchitectural structures. An important additional feature ofthe approach is the ability to reuse such mappings acrosssystems. In particular, we exploit regularity in implementa-tion and architectural styles so that a single mapping canserve as an architectural extractor for a large collection ofsimilar systems, thereby reducing the cost of writing eachabstraction mapping while still providing flexibility.

In the remainder of this paper, we describe this approachin detail and describe the tool called DiscoTect that we haveimplemented. Section 2 presents the DiscoTect approach,including an overview of the DiscoTect framework and theDiscoSTEP language used for specifying mappings. Wethen outline a formal semantics for DiscoSTEP that specifiesits meaning in terms of Colored Petri Nets. We illustrate thiswith a simple example. In Section 3, we describe theimplementation of DiscoTect. Sections 4 and 5 present casestudies that we use to evaluate the efficacy of DiscoTect. InSection 6, we position our work in the context of relatedresearch. Finally, in Section 7, we present our conclusionsand future work.

2 DISCOTECT

2.1 Technical Challenges

Any approach that supports dynamic discovery of archi-tectures must address three challenges:

1. monitoring: observing a system’s runtime behavior,2. mapping: interpreting that runtime behavior in

terms of architecturally meaningful events, and3. architecture building: representing the resulting

architecture.

In this paper, we are primarily concerned with the secondproblem of bridging the abstraction gap between systemobservations and architectural effects. There are a numberof issues that make this a hard problem. First, mappingsbetween low-level system observations and architecturalevents are not usually one-to-one. Many low-level eventsmay be completely irrelevant. More importantly, a givenabstract event, such as creating a new architecturalconnector, might involve many runtime events, such asobject creation and lookup, library calls to runtime infra-structure, initialization of data structures, and so forth.Conversely, a single implementation event might representa series of architectural events. For example, executing aprocedure call between two objects might signal thecreation of a new connector and its attachment to theruntime ports of the respective architectural components.This implies the need for a technique that can keep track ofintermediate information about mappings to an architectur-al model.

Second, architecturally relevant actions are typicallyinterleaved in an implementation. At any given moment,a system might be midway through creating severalcomponents and their connectors. This implies that anyattempt to recognize architectural events must be able tocope with concurrent intermediate states.

Third, there is no single gold standard for indicatingwhat implementation patterns represent specific architec-tural events. Different implementations may choose differ-ent techniques for creating the same abstract architecturalelement. Consider the number of ways that one mightimplement pipes, for example. Indeed, one might even findmultiple implementation approaches in the same system.Moreover, there is no single architectural style or patternthat can be used for all systems. For example, the use ofsockets might be used to represent many different types ofconnectors.

To handle this variability of implementation strategiesand possible architectural styles of interest, a language isrequired to define new mappings. Given a set of imple-mentation conventions (which we will refer to as animplementation style) and a vocabulary of architecturalelement types and operations (which we will refer to asan architectural style [12]), we require a description thatcaptures the way in which runtime events should beinterpreted as operations on elements of the architecturalstyle. Thus, each pair of implementation style and archi-tectural style has its own mapping. A significant conse-quence is that these mappings can be reused acrossprograms that are implemented in the same style.

In summary, taking these challenges into accountproduces the following requirements for an approach todynamically determine the architecture of a runningsystem:

1. It must handle M-N mappings between low-levelsystem events and constructs at the architecturallevel.

2. It must be able to keep track of concurrent andinterleaved sets of event traces that produce archi-tecturally significant events.

3. It needs to have flexibility in mapping implementa-tion style to architectural style.

SCHMERL ET AL.: DISCOVERING ARCHITECTURES FROM RUNNING SYSTEMS 455

2.2 The DiscoTect Approach

To address these concerns, we have adopted the approachillustrated in Fig. 1. Events captured from a running systemare first filtered to select the subset of system observationsthat must be considered. The resulting stream of events isthen fed to the DiscoTect Runtime Engine. The DiscoTectEngine takes in a specification of the mapping, written in alanguage called DiscoSTEP (Discovering Structure ThroughEvent Processing). The DiscoTect engine constructs aColored Petri Net from the mapping to recognize inter-leaved patterns of runtime events and, when appropriate, toproduce a set of architectural operations as outputs. Thoseoperations are fed to an Architecture Builder that incre-mentally creates an architectural model, which can then bedisplayed to a user or processed by architecture analysistools. We now elaborate on each of the three maincomponents in turn:

1. DiscoSTEP Mapping Specification. We have devel-oped a language, called DiscoSTEP, for specifyingmappings between low-level and architectureevents. The execution semantics of these mappingsis defined using Colored Petri Nets. We outline atranslation from DiscoSTEP mappings to ColoredPetri Nets in Section 2.4.

2. DiscoTect Runtime Engine. The runtime enginetakes, as inputs, events from the running programand a DiscoSTEP specification and then runs theDiscoSTEP specification to produce architectureevents. System runtime events are first interceptedand converted into XML (Extensible Markup Lan-guage) [45] streams by Probes. The resulting streamof events is then fed to the DiscoTect RuntimeEngine, which uses the DiscoSTEP specification torecognize interleaved patterns of runtime eventsand, when appropriate, outputs a set of architecturalevents.

3. Architecture Builder. The architecture builder takesarchitectural events and incrementally constructs anarchitectural description, which can then be dis-played to a user or processed by other architectureanalysis tools.

2.3 Informal Introduction to DiscoSTEP

To handle the variability of implementation strategies andarchitectural styles of interest, we provide a language to

define mappings. DiscoSTEP specifies how to map system-level events to architectural-level events. To discover thearchitecture of a system, a program written in the Disco-STEP language is compiled into byte code that can beinterpreted by the DiscoTect engine. The DiscoTect engineprocesses the runtime events produced by the system andgenerates architectural events on the fly. The architecturalevents can be further consumed by an architectural builderto construct the architecture. A DiscoSTEP specification hasthree main ingredients:

1. Events types. The kinds of events, and theirstructure, that are consumed and produced by theDisco-STEP program. These are defined by an XMLSchema.

2. Rules. Rules specify how to map a set of system-level events into architectural events and represent asingle “step” in processing an event stream.

3. Compositions. Compositions of rules specify howoutput events from rules are passed as input eventsto other rules. Complex patterns of event sequencesto be processed can be defined in this way.

In this section, we informally describe these three compo-nents. We then use a simple example to illustrate how theyform a language to instruct event handling.

2.3.1 Events

In DiscoTect, we can capture runtime events such as methodcalls, CPU utilization, network bandwidth consumption,memory usage, etc. To generate these events at runtime, weprobe, or instrument, the running system. To do this, wecan use resource monitoring tools or code instrumentationtools such as AspectJ [23] and AspectC++ [36] that allow usto inject code into the target system. These events are inputinto a DiscoSTEP specification. The specification producesarchitectural events, generated as a result of processing theruntime events, which in turn are used to produce thesoftware architecture.

Representation. We do not want the kinds of eventsconsumed or produced by DiscoTect to be hardwired. Wewant the flexibility of customizing events for particularimplementation and architectural styles. To do this, we useXML Schemas to specify the valid XML representations thatcan be used as events by DiscoSTEP and the events aretherefore represented in XML. This allows us to performstructural type checking of the use of events in theDiscoSTEP specification. Fig. 2 illustrates the schemadefinition of a call type event and Fig. 3 provides anexample of a valid XML event that conforms to this schema.In this paper, we use Acme representations for architec-tures. However, Acme is by no means the only architecturalrepresentation that could be supported by DiscoSTEPbecause we use an XML schema to define the output.

Input and Output. Our event processing engine takesruntime events as input and produces architectural eventsas output. For clarity, and for the purposes of checking thecorrectness of a DiscoSTEP specification, we partitionDiscoSTEP event types into inputs and outputs. For example,the call type event described above would be specified as aninput, whereas an event like “create_component” would bespecified as an output event.


Fig. 1. The DiscoTect architecture.

2.3.2 Rules and Compositions

Rules determine what events should be processed andgenerate new events that are either used to construct thearchitecture or are fed into other rules to allow recognitionof complex implementation patterns. Rules are composed ofinputs, outputs, triggers, and actions. Input and output blocksdeclare input events that a rule cares about and the outputevents that a rule can generate. Triggers are predicates overthe input events. Actions are assignments to the outputevents. When a trigger returns true upon the arrival of inputevents, the actions in the corresponding rule are activated toinstantiate the output events. Since events are representedin XML, we use a well-defined XML Query language calledXQuery [44] to describe triggers and actions. This allows usto specify a large range of predicates and manipulationsover XML, rather than inventing a new syntax.

A rule only represents a fragment of what is needed tocapture an architecture. Multiple rules can be assembledinto a composition to handle event sequences. In a composi-tion, rules are connected to each other by a set of input/output bindings. In the simplest case, a rule consumes anevent. However, in many cases, we want the rule to becontinually active; for example, a rule for recognizing a porton a component needs to fire multiple times so thatmultiple ports on the same component can be recognized.For this case, DiscoSTEP provides a bidirectional binding(denoted by <->). This means that a rule fires on an inputwithout consuming that input (the event is implicitlyreproduced as an output and fed back to the rule as input).Bidirectional bindings therefore are a convenient shorthandfor two directional bindings.

Section 3.4.4 provides examples of rules and composi-tions.

2.3.3 Informal Runtime Semantics

Informally, DiscoTect runs DiscoSTEP specifications in thefollowing sequence:

1. When an event is received by DiscoTect, associatethe event with any rule that accepts that type ofevent.

2. For any rule that has a value for each of its inputs,evaluate the trigger.

3. If a trigger matches for a set of input events, executethe action with that set of events.

4. For output events that are composed with otherrules, send the event as inputs to those rules. Foroutput events not composed with other rules, emitthem from DiscoTect as architectural events.

For each rule, an input event can be considered to be a set ofevents that match that type. Triggers match events to be

used in the rules. Formally, we model an event as coloredtokens (where the color is given by the type) and a rule as atransition. For each event, a token is generated and put in aplace before a transition. Rules consume tokens and putthem in places after transitions. We discuss this formaldefinition in Section 2.4.

2.3.4 An Example DiscoSTEP Specification

To illustrate the concept of events and the use of rules andcompositions, we now profile a simple program written inJava. In doing so, we illustrate how to specify events usingDiscoSTEP and how DiscoTect uses this specification togenerate an architectural description. The example is asimple system that implements a chat server.1 The chatserver creates a server socket and announces its intention toaccept connections. When a client connects to the waitingserver, a new thread (of type ClientThread) is started whichforwards all messages from that client to all connectedclients.

While this system is simple, it allows us to illustrate theconcepts of DiscoSTEP. In later sections, we provide morecomplex case studies. In the remainder of this section, weshow how we instrumented this system, describe its Disco-STEP specification, and discuss how DiscoTect processes thisspecification to produce an architectural description.

The architectural description for this system is based on aclient-server style. Informally, it is constructed as follows:When the server is created in the program, this maps to aserver type component in the architecture; ClientThreadsmap to client components and the socket connection mapsto an architectural connector between each client andserver.

Instrumentation. The act of instrumenting a system toproduce runtime events is not a novel aspect of DiscoTect.In fact, wherever possible, we use off-the-shelf technologiesfor our instrumentation. For Java-based systems, we haveused AspectJ to define instrumentation aspects that arewoven into the compiled bytecode of the programs. Theseaspects emit events when methods of interest enter or exitand when objects are constructed.

The aspects can reflectively retrieve information aboutthe runtime environment of, for example, a call, to ascertainthe calling object, the instance of the object that was called,the argument values and types that were passed to themethod, the method signature, etc. The aspects are writtento emit XML elements that conform to a schema expectedby DiscoTect. For example, to instrument the ChatServer,we wove in aspects to emit events when methods werecalled and when objects were constructed.

Runtime Events. Two types of runtime events werecollected from this running system: call events and initevents. A call event is reported when a method is invoked.


1. The example system, including Java code and DiscoSTEP specification,is presented in Appendix A, which can be found on the Computer SocietyDigital Library at http://computer.org/tse/archives.htm.

Fig. 2. Defining even schema for use in DiscoSTEP.

Fig. 3. An example “call” event.

Similarly, an object instantiation produces an init event.Take the following two events for example:

<init constructor_name=“ServerSocket” instance_id=“10”>

<call method_name=“ServerSocket.accept”

callee_id=“10” return_id=“11” />

An init event is generated when

ServerSocket ss = new ServerSocket(1111)

is executed; a call event is triggered by an execution of amethod call. For example, the call event above is emitted bythe following statement execution:

Socket socket = ss.accept()

Because multiple ClientThreads can run concurrently, someof the runtime events, such as InputStream.read andOutputStream.write, show up in random order and, hence,may be interleaved with each other.

A fuller trace of the events that we retrieved whenrunning the program is available in Fig. 10 of Appendix A,which can be found on the Computer Society DigitalLibrary at http://computer.org/tse/archives.htm. Theseevents can be fed into DiscoTect either in real-time oroffline, after the program has completed running.

DiscoSTEP Program. A DiscoSTEP program that spe-cifies how to handle the interleaved events between theclient and server was specified to capture how to mapsystem events into architectural events. The full specifica-tion is given in Fig. 11 of Appendix A, which can be foundon the Computer Society Digital Library at http://computer.org/tse/archives.htm; in this section, we discusssome of the rules and how these are combined with theevent trace to produce the architecture. DiscoTect takes theruntime events from the ChatServer to produce architectur-al events that construct a Client Server style representationof the system.

Fig. 4 shows a fragment of the DiscoSTEP program thatincludes two rules, and how they are composed. TheCreateServer rule constructs an architecture Server compo-nent. It takes the input event under inspection to be an initevent named $e. The output events include the string event$server_id and the create_component event $create_server.The condition for triggering this rule is that the constructor_name attribute of $e contains the string “ServerSocket.” Ifthe rule is triggered, the following action is taken:$server_id is assigned the id of the object constructed inthe init event and an architecture event that constructs aserver component named with the id of the newly createdinstances is assigned to $create_server.

The $server_id output from the CreateServer rule is fedto the ConnectClient rule, which has two inputs: $e and$server_id. Once these inputs are received by ConnectClient, the trigger will check to see if any events are calls toServerSocket.accept. If so, output events $client_id, $create_client, and $create_cs_connection are assigned appropri-ate values to construct both the client component and theconnector connecting it with the previously created servercomponent.

Instead of being specific to this particular ChatServerprogram, our client server event processing program is

generic enough to be applicable to any client serverapplications implemented with the same style (with, atthe most, some minor changes in the triggers).

Both the compositions and the rules are well encapsu-lated. Rules are self-contained specifications, communicat-ing with each other via inputs and outputs; compositionsfunction as glue that assembles the rules. We can reusecompositions by applying them to a different system andreuse rules by assembling them with a different composi-tion (and adding new rules if necessary).

2.3.5 Satisfying the Requirements

In this section, we revisit the requirements for DiscoSTEPthat we introduced in Section 2.1 and discuss how Disco-STEP meets these requirements.

. Allow M-N mappings between events. Since a Disco-STEP rule can have an arbitrary number of inputsand outputs, this requirement is simply met byDiscoSTEP.

. Keep track of information for use in subsequent stages.Input events and output events are data structuresthat can be passed from one rule to the next. Thesedata structures are used to store information that canbe passed between rules. Compositions define howthis data is passed between rules.

. Cope with concurrent states. The informal executionsemantics defined in Section 2.3.3 describe howinput events are propagated to each rule that canaccept an event of that type. In this way, these eventscan start multiple execution threads to cope withconcurrent states. A rule will wait until it gets a setof input events that match a trigger before firing. In


Fig. 4. The DiscoSTEP rule to create a Server component.

this way, interleaved threads of information can bemanaged.

. Be flexible with respect to mapping implementation style toarchitectural style. The fact that the types of eventsconsumed and produced by are specified in a Disco-STEP mapping means that multiple implementationstyles and architectural styles can be manipulated byDiscoTect. Furthermore, though not described indetail in this paper, the abstract syntax of DiscoSTEPspecifies that a composition itself may have input andoutput events, as well as subcompositions. In thisway, compositions can be combined hierarchically toform more complex mappings. So, for example, it ispossible to take a composition that identifies amapping between system file usage and a datarepository architectural style and combine that witha mapping that recognizes the construction of a pipe-filter architecture to define the mapping for a pipe-filter system that retrieves and stores data in files.

In sum, meeting these requirements means that a Disco-

STEP mapping captures the way in which runtime events

following an implementation style should be interpreted as

operations on elements of an architectural style.

2.4 Formal Definition of DiscoSTEP

To define the execution semantics of a DiscoSTEP program,

and to formally explain how the mappings are interpreted,

we use Colored Petri Nets (CP-nets) [19]. In [46], we

informally described the semantics of DiscoTect mappings

in terms of state machines. However, this semantics was

awkward because of the need to retain multiple active states

in the state machine to model the concurrency in the model.

We believe that Colored Petri Nets are a more appropriate

formalism for describing the semantics of DiscoSTEP

mappings because their tokens provide a rich way of

representing concurrent system states.The DiscoSTEP language is formally described and

modeled so that type checking and consistency checking

can be done at the language level. The more interesting

definition comes from how DiscoSTEP is formally modeled

using Colored Petri Nets. In this section, we summarize

how we translate a DiscoSTEP program into its equivalent

Colored Petri Net; Appendix B, which can be found on the

Computer Society Digital Library at http://computer.org/

tse/archives.htm, contains the full semantic definition of

DiscoSTEP. Informally, we translate the DiscoSTEP con-

structs into CP-net constructs in the following way:

. The types for the CP-net are formed out of the unionof event types used as input and output from all therules used in a DiscoSTEP composition.

. Each DiscoSTEP rule becomes a CP-net transition.

. Each group of connected input and output eventsbecomes a CP-net place.

. Each DiscoSTEP trigger becomes a guard in theCP-net.

. The color for a place is derived from the connectedinput and output event type used to construct thatplace, which are guaranteed to be equivalentbecause of the DiscoSTEP type semantics.

. Each DiscoSTEP action becomes an action in theCP-net.

. CP-net arcs and nodes are constructed from thecomposition of the places and rules.

The complication in the translation comes from forming the

places and dealing with the DiscoSTEP bidirectional

binding. These complications are a direct result of keeping

rules and composition separate.

2.4.1 Formally Modeling the Example

The ChatServer DiscoSTEP program uses the following

types: string, init, call, create_component, create_connector,

and update_component. By applying the translational

semantics, we obtain the color sets for the CP-net as:

� ¼ fstring; init; call; create component; create connector;

update componentg:

The transitions in the CP-net are created as:

T ¼ fCreateServer;ConnectClient;ClientIO;ClientRead;

ClientWrite;UpdateServerg:

By applying other translations, the inputs and outputs are

translated into CP-net places, arcs, and node functions, the

triggers and actions are translated into CP-net guards

defined from transitions into predicates, and arc expres-

sions are defined from arcs to XQuery expressions. Fig. 5

shows the resulting net. Note that the backward arcs from,

for example, the ClientRead transition to the $client_id place

are formed through the unification process in the transla-

tional semantics because the $client_id output of Connect-

Client is bound to the inputs of more than one rule (ClientIO,

ClientRead, and ClientWrite).This CP-net representation is then “executed” in our

toolset. When an event comes into the net, a token is created

for each place that is relevant for that event so that it can be

compared with the associated guards for interested transi-

tions. There is no priority on competing transitions—each

matching set of tokens is processed by the transition when

they match.

3 IMPLEMENTATION OF DISCOTECT

Recall from Section 2 that, to provide a framework for

discovering architectures, we need to solve three chal-

lenges. In this section, we discuss our response to each

challenge.Monitoring. We use existing probing technologies to

extract monitoring events. In the case studies in Sections 4

and 5, we used AspectJ to monitor object creation, method

invocation, etc. We provide a library that allows aspects to

produce system events formatted as XML strings which are

placed on a JMS event bus to be consumed by DiscoTect.Mapping. We have implemented the DiscoTect engine in

Java, which follows the implementation outlined in this

paper. The DiscoSTEP language is implemented using

JavaCC, a Java-based compiler generator, and uses the

Saxon XQuery processor to parse and execute the XQuery

triggers and rules in a DiscoSTEP specification.


Architecture Building. We represent architectures usingthe Acme architecture description language [13] (althoughwe are not restricted to this language; in principle, anyarchitecture description language could serve in thiscapacity). Operations on Acme architectures are definedin a library that provides operations that form buildingblocks of architectural actions. To connect to our existingarchitectural tools, DiscoTect produces architectural eventsformatted as XML strings that are forwarded by theAcmeStudio Remote Control plugin, communicating overJava RMI, to incrementally construct the architecture. Theanalysis capabilities of AcmeStudio [33] can then be used tocheck the architecture with respect to its style or to conductanalyses such as performance or schedulability.

4 AAMS CASE STUDY

In this section, we present a case study of an application ofDiscoTect that determines the runtime architecture ofAAMS, a simulation testbed for experimenting with mobilesystem architectural design decisions [22]. The testbedallows users to specify system resources, tasks, andscheduling strategies and simulates the running of themobile system. We chose AAMS because it represents afairly complex application (approximately 28KLOC), andthe runtime architectural view of the system is well-documented. This case study allows us to compare ourdiscovered architecture with the original documentation,illustrating the application of our tool to discover deviationsbetween the architecture discovered by DiscoTect and thedocumented AAMS architecture. Furthermore, this casestudy illustrates how we developed and refined the Disco-STEP specification to discover the final architecture.

Fig. 6 shows the runtime architecture of AAMS aspresented in [22]. The Simulation Controller forms asimulation from a description of resources and tasks, theirconfiguration, user activities and events, and informationthat it reads from a set of configuration and script files. TheSimulation Controller also takes commands from theSimulation GUI to control runtime parameters and feed-back. It then processes each simulation frame to generatethe actual running of the system. Each component in theapplication and resource layers simulates its own operation.

A set of services for File I/O, Error Reporting, and Loggingis available via publish/subscribe to any simulated object.

4.1 Design of the AAMS DiscoSTEP Program

In this section, we present the steps that we took to producethe DiscoSTEP program to discover the AAMS architecturemodel. Typically, writing these programs is an iterativeprocess, starting with a few generic rules to discovercomponents and connections and then refining these rulesto produce architectures corresponding to a particular style.For this case study, we used a specialization of a publish/subscribe style that distinguishes participating componentsas tasks, resources, etc. These component types are based onthe description of AAMS found in [22].

To develop the final DiscoSTEP program, we firstproduced rules that merely observed object creation andinteraction (through procedure calls). We then refined thisset of rules to identify objects with their architecturalcounterparts (e.g., Resource, Task, etc.).


Fig. 5. CP-net places, arcs, and node functions translated from inputs and outputs.

Fig. 6. Documented runtime view of AAMS.

Up to this point, we had not discovered anything about

the publish/subscribe part of the architecture itself. The

preliminary discovery results informed us that all the

resource and task components interact with an object of the

PubSub class using two procedure calls named publish and

subscribe. We conjectured that the system implements

publish/subscribe by creating a PubSub object and invoking

its two methods. This led us to design a specification for this

portion of the architecture. This specification creates an

EventBus connector when it notices the instantiation of a

PubSub object in the implementation. Once this has been

done, an EventTaker role is created when DiscoTect notices a

call to the publish method of the PubSub object and a Publish

port on the component corresponding to the call and

attaches them. Similarly, PubSub.subscribe leads to the

creation of an EventSender role on the EventBus providing

the method, the creation of a Subscribe port in the

component requesting the method, and the creation of the

attachment of port and role.

4.2 The Discovered Architecture

The final DiscoSTEP specification for AAMS consists of

10 rules. This specification took an expert about one week to

develop, which included interacting with the original

source code developer.Applying the above DiscoSTEP specification to a running

instance of AAMS yields the architectural model in Fig. 7.

(We have manually laid out this model to enable easier

comparison with the view in Fig. 6.) We uncovered four

types of discrepancies between the documented architec-

tural view and our discovered one.

1. Isolated, extraneous components/connectors. The resultshows two EventBus connectors, one of which isisolated from the rest of the system. This indicatesthat one instance is instantiated but never used.Code optimization should resolve this discrepancy.

2. Additional connections between components. Fig. 7 doesnot show any connections between the controllercomponent and simulation components such astasks and schedulers. Nor does it inform us thatsome of the support components (e.g., Logger andReporting) also subscribe to the event bus. Ignoringthose “backdoor” connections makes the architectur-al view less accurate; moreover, it might compro-mise architectural analysis where all meaningfulinteractions between components should be consid-ered. For example, in evaluating the performance ofa publish/subscribe infrastructure, the existence ofhidden communication channels could invalidatedeadlock or throughput analyses.

3. Misplaced connections between components. The dis-covered architecture shows a different File I/Oscheme: Instead of the GUI reading three files (cf.,Fig. 6), the controller reads two files. Thisdiscrepancy could cause errors during evolutionif the AAMS system was to work in a distributedenvironment. The evolution might require that thefile reading components run on the same computeras that containing the files. The documentedarchitecture would suggest that the SimulatorGUI is the component that should be associatedwith the files, when, in fact, according to theimplementation, this is incorrect.

4. Missing components/connectors. Two of the compo-nents —User and Envt (Environment)—recorded inthe document do not show up in the discoveredarchitecture.

To confirm that DiscoTect discovered the actual archi-tecture of the implementation and to understand thediscrepancies, we conferred with the AAMS developers.They agreed that DiscoTect produced a more complete andcorrect architectural description than their diagram and thatit had uncovered some errors in their coding. However, themissing User and Environment components are due to thefact that these represent user interaction and are not actualcomponents in the implementation.

5 EJB CASE STUDY

In this section, we present a second case study to determinethe runtime architecture of the Duke’s Bank Application—asimple EJB (Enterprise Java Beans) banking applicationcreated by Sun Microsystems as a demonstration of EJBfunctionality. Duke’s Bank allows bank customers to accesstheir account information and to transfer balances from oneaccount to another. It also provides an administrationinterface for managing customers and accounts. We use thiscase study to demonstrate how the architecture of an EJBapplication can be discovered using DiscoTect. We chosethis system because its architecture is well documented inSun Microsystems’ J2EE (Java2 Platform, Enterprise Edi-tion) tutorial [16], which enables us to compare the


Fig. 7. The discovered architecture of AAMS.

discovered architecture with the one presented in thedocumentation. For the case study, we used version 1.3 ofthe application provided by Sun and version 3.2.7 of theJBoss application server.

To instrument the system, we wrote an aspect thatinjected advice to object instantiations, method calls, andfield modifications. We compiled the Duke’s Bank applica-tion along with the aspect, using the AspectJ compiler, sothat system execution events were traced as the applicationran. In total, we developed 200 lines of AspectJ code toinstrument the application and the server.

Fig. 8 gives a view of how the components interact in theDuke’s Bank system as presented in [16]. The EJB applica-tion has three session beans: AccountControllerBean,CustomerControllerBean, and TxControllerBean (Tx standsfor a business transaction, such as transferring funds).These session beans provide a client’s view of theapplication’s business logic. For each business entityrepresented in the simplified banking model, the applica-tion has a matching entity bean: AccountBean, CustomerBean, and TxBean. The business methods of the AccountControllerBean session bean manage the account-customerrelationship and get the account information using theAccountBean and CustomerBean entity beans. TheCustomerControllerBean provides methods for creating,removing, and updating customers through CustomerBeanentity beans. The TxControllerBean session bean handlesbank transactions. It accesses AccountBean entity beans toverify the account type and to set the new balance andaccesses TxBean to keep records of the transactions.

5.1 Design of the EJB DiscoSTEP Program

We now present the steps taken to produce the DiscoSTEPspecification to discover the Duke’s Bank architecture. Weused a specialization of an EJB style that distinguishesparticipating components as entity beans, session beans,bean containers, database, etc. These component types arebased on the EJB specification found in [10].

As we did in the previous case study, we first producedprimitive rules that merely observed object interaction and

creation (through procedure calls and object instantiations).We then refined these rules to classify objects into their

architectural counterparts (e.g., Beans, Bean Containers,

Database, etc.) by checking the class constructor names. For

example, we created a SessionContainer object when its

constructor had the name of “SessionContainer.” The

relationships between the beans, the bean containers, andthe database were captured in the following way: Accord-

ing to the EJB specification, the beans are maintained by

their corresponding containers, so we connected the beans

with the containers controlling them by observing the

procedure calls made by the containers to manage the life

cycles of the beans. Knowing that database access wasimplemented using JDBC (Java Database Connectivity) [18],

we monitored the standard JDBC APIs to uncover the

connections between the beans and the database; the

interactions between the beans were also monitored and

represented as connectors linking them together.

5.2 The Discovered Architecture

The final DiscoSTEP specification code for Duke’s Bank

consists of eight rules. The process of developing the code

iteratively took a DiscoSTEP expert approximately three

days, which included understanding the working of theapplication and the server, developing the aspects, and

writing the DiscoSTEP specification.Applying the specification just described to a running

instance of Duke’s Bank yields the architectural model in

Fig. 9. We have manually organized the layout of this model

for better comprehensibility. We can make the following

observations based on this process:

1. Reflection of runtime instances. Besides showing thebean and the containers, the discovered result alsodetails each bean and container instance created atruntime. Tracing the individual bean and containerinstances is useful for performance analysis andfault diagnosis. In addition, the relatively complexm-to-n relationships between beans and bean con-tainers are revealed.


Fig. 8. Documented architectural view of the Duke’s Bank application.

2. Verification of Bean Interplay. The interactions be-tween the beans shown in Fig. 9 are consistentwith those described in the architecture shown inFig. 8: There are communication channels betweenAccountControllerBean and AccountBean, AccountControllerBean and CustomerBean, CustomerControllerBean and CustomerBean, TxControllerBean and TxBean, and TxControllerBean andAccountBean.

3. Discrepancies in Database Access. Fig. 8 does not showany connections between the session beans and thedatabase, which implies that all database access goesthrough the entity beans. This is consistent withSun’s EJB specification [18]. However, a “databasewrite” connector did appear in the discoveredarchitecture. Further (manual) source code analysisconfirmed that AccountControllerBean does directlywrite to the database, a violation of the architecture.As discussed in the previous section, identifyingcommunication “backdoor” connections like this isuseful for architectural analysis and to ensurearchitectural conformance.2

6 RELATED WORK

To analyze a running system, it is first necessary to getinformation from it. There are many technologies availablefor monitoring systems and we build on those. For example,Balzer and Goldman [4] and Wells and Pazandak [43]provide systems to instrument the source code to producetrace information and manipulate runtime artifacts to getthe information; aspect-oriented systems such as AspectJallow use to instrument binary code when the source is notavailable. We can use any of these approaches to getinformation out of the system.

Monitoring mechanisms do not by themselves solve thehard problem of mapping from code to more abstract

models; event correlation and abstraction is also needed.Work by Dias and Richardson [9] uses an XML-basedlanguage to describe runtime events and use patterns tomap these events into high-level events. However, analyz-ing these abstracted events to determine architecturalstructure is not addressed. In addition, a simple staticmapping from low-level system events to high-level eventshas limited expressiveness. For example, it cannot handlethe case where the event analyzer initially has an interest inone set of events, but then changes its interest after theinitial events have occurred. Also, it doesn’t provide a wayof specifying event correlations or mapping a series ofcorrelated low-level events to a single high-level event—acrucial capability needed when discovering the architectureof a system. Approaches to correlating events, for example,GEM [29] and SEL [50] and work by Kaiser et al. [20],provide sophisticated event correlation languages that candetect when certain combinations of events have occurredand, in some cases, what actions to perform based on thosecorrelations. Our approach is similar, but it makesarchitectural styles or patterns explicit; our mappings canbe used to map low-level events to high-level architecturalevents that are amenable to checking for consistency againstparticular architectural styles.

In prior work, we developed an infrastructure for doingcertain kinds of abstraction [15]. However, this approachwas limited to observing the properties of a system andreflecting them in a preconstructed architectural model.Here, we show how to create such a model.

A number of researchers have investigated the problemof presenting dynamic information to an observer. Forexample, some researchers present information aboutvariables, threads, activations, object interactions, and soforth [32], [40], [41], [49]. Ernst et al. show how todynamically detect program invariants by examiningvalues computed during a program execution and bylooking for patterns and relationships among them [11].This is somewhat different from detecting architecturalstructure.


2. Note that this error has been corrected in the most recent version of theDuke’s Bank J2EE application.

Fig. 9. Discovered architecture of Duke’s Bank.

Madhav [26] describes a system that allows Ada 95programs to be monitored dynamically to check confor-mance to a Rapide architectural specification [25]. Hisapproach requires the source code to be annotated so that itcan be transformed to produce events to construct thearchitecture. In contrast, our approach does not requireaccess to the source code and it does not rely on explicitarchitectural construction directives to be embedded in thecode as does the approach used by Aldrich et al. [2].

There has been research in using Colored Petri Nets todynamically determine software architectures from runningsystems using Colored Petri Nets. This work either focuseson a particular quality attribute (e.g., [1] for performanceanalysis), uses UML as the modeling language, which isvery close to the actual code [48], or checks that interactionson preknown connections are of the correct protocol [6]. Incontrast, our approach focuses on determining the compo-nent and connector architecture view of a running systemwhere the particular architecture components and connec-tions may not be known a priori and where the actualarchitectural view may be much more abstract than theprogramming language constructs used to implement thesystem. Moreover, our approach is agnostic about thespecific architectural styles that may be used and therepresentation language.

A large body of research has investigated specification ofthe dynamic behavior of software architectures. Of themany approaches, some use explicit state machines (e.g., asdescribed by Allen and Garlan [3] and Vieira et al. [39]).These approaches, however, do not link architecture to anexecuting system.

7 CONCLUSIONS AND FUTURE WORK

In this paper, we have described an approach to “discover-ing” the architecture of a running system that uses a set ofpattern recognizers that convert monitored system observa-tions into architecturally meaningful events. Our key ideaand contribution is to exploit implementation regularitiesand knowledge of the architectural style that is beingimplemented to create a mapping that can be applied to anysystem that conforms to the implementation conventions, toyield a view in that architectural style. The mapping itselfdefines a novel form of behavior specification (realized as aColored Petri Net) that relates low-level events to archi-tecturally significant actions. The power of Petri Nets isused to model the concurrent threads of event recognition,allowing us to disentangle the interleaved sequences of low-level events that contribute to higher-level architecturalbehavior.

There are a number of advantages of this approach. First,it can be applied to any system that can be monitored atruntime. In our case, we have demonstrated two casestudies written in Java, but we have recently successfullyexperimented with the use of AspectC to extract runtimeinformation from C and C++ programs. In general, anymonitoring environment that allows us to capture objectcreation, method invocation, and instance variable assign-ment will serve as a sufficient foundation for our runtimemonitoring. Second, by simply substituting one mappingdescription for another, it is possible to accommodate

different implementation conventions for the same archi-tectural style or, conversely, to accommodate differentarchitectural styles that employ the same implementationconventions. For example, although not described here, wehave been able to discover the Pipe/Filter architecture ofsystems implemented using different pipe conventions.

There are, however, several inherent weaknesses to theapproach. The first is that it only works if an implementa-tion obeys regular coding conventions. Completely ad hocbodies of code are unlikely to benefit from this technique.Second, it only works if one can identify a targetarchitectural style so that the mapping “knows” the outputvocabulary. Third, as with any analysis based on runtimeobservations, it suffers from the problem that you can onlyanalyze what is actually executed. Hence, questions like “isthere any execution that might violate a set of styleconstraints” cannot be directly answered using this method.Fourth, the DiscoSTEP mapping needs to be created via aniterate-and-test paradigm and, hence, the results are some-what dependent on the skill of the creator of the recognizer.Our techniques require some skill and judgment to beemployed effectively. Thus, our techniques are best viewedas one of several technologies that an architect must have inhis arsenal of architecture conformance checking tools. Forexample, we believe that DiscoTect can be effectivelycombined with static analysis tools such as Dali [21] orArmin [30] to provide complementary kinds of analysis,whereby runtime observations can be combined withstatically extracted facts. In this way, we should be able toachieve a more complete and accurate picture of the as-builtsystem. Finally, the level of effort required to write thespecification suggests that this approach is best appliedwhen there are many examples of a system using the samearchitectural styles and coding conventions. For example,the EJB Duke’s Bank case study requires understanding ofthe inner workings of a particular application server;however, we believe that applying the same specificationto another EJB system running on the same server willrequire only a small incremental effort.

These potential defects also point the way to futureresearch in this area. First is the area of system monitoring.As mentioned, we have experimented with a number ofexisting monitoring technologies for Java and C++. How-ever, monitoring technologies for other kinds of implemen-tations and system properties is a research area that shouldcontinue to provide increasing capabilities in the future thatwe can leverage.

Second is the area of codifying the ways in whicharchitectural styles are implemented. As technology ad-vances, implementation techniques will necessarily change,and it will be important to augment the set of mappings asthat happens. We envision a large library of recognizers forcommon architectural frameworks available as open sourcelibraries that would track the most common architecturalframeworks in practical use.

Third is the area of architectural coverage metrics,similar to coverage metrics for testing. It would be good,for example, to have some confidence that, in running asystem with various inputs, we have exercised a sufficiently


comprehensive part of the system to “know,” with somecertainty, what its architecture is.

Fourth, we would like to find a way to make thedefinition of implementation-architecture mappings moredeclarative. While the operational definition of statemachines as the carrier of those mappings is a good firststep, we can imagine more abstract forms of characteriza-tion that will be easier to create and analyze.

Fifth, while the approach we have outlined focusesprimarily on recognizing architectural structure, we believeit could be easily extended to architectural behavior. Forexample, we can imagine using the same runtime abstrac-tion techniques to check that the observed interactionbetween two components conforms to the protocol expectedover the corresponding architectural connector. Similarly,we might observe timing behavior, which could becompared with an architectural specification of expectedperformance.

Finally, we are still gaining experience with the use ofthese tools in practice. The process of developing theDiscoSTEP mapping is a long and iterative one thatcurrently requires intimate knowledge of the implementa-tion conventions. While we can never truly eliminate thisneed, we are investigating processes, conventions, and toolsthat could make this less time-consuming and error-prone.

ACKNOWLEDGMENTS

The research described in this paper was supported by theUS Defense Advanced Research Projects Agency, underGrants N66001-99-2-8918 and F30602- 00-2-0616, by aSoftware Engineering Institute (SEI) Internal R&D Grant,and by the US Army Research Office under GrantsDAAD19-02-1-0389 (“Perpetually Available and SecureInformation Systems”) and DAAD19-01-1-0485. The viewsand conclusions contained in this document are those of theauthors and should not be interpreted as representing theofficial policies, either expressed or implied, of any of thefunding agencies.

REFERENCES

[1] M. Ajmone Marsan, G. Balbo, G. Chiola, and G. Conte, “Modelingthe Software Architecture of a Prototype Parallel Machine,” Proc.SIGMETRICS Performance Evaluation Rev., vol. 15, no. 1, pp. 175-185, 1987.

[2] J. Aldrich, C. Chambers, and D. Notkin, “ArchJava: ConnectingSoftware Architecture to Implementation,” Proc. 24th Int’l Conf.Software Eng., 2002.

[3] R. Allen and D. Garlan, “Formalizing Architectural Connection,”Proc. Int’l Conf. Software Eng. (ICSE), 1994.

[4] R.M. Balzer and N.M Goldman, “Mediating Connectors,” Proc.19th IEEE Int’l Conf. Distributed Computing Systems WorkshopElectronic Commerce and Web-Based Applications, 1999.

[5] L. Bass, P. Clements, and R. Kazman, Software Architecture inPractice, second ed. Addison-Wesley, 2003.

[6] Q. Bai, M. Zhang, and K.T. Win, “A Colored Petri Net BasedApproach for Multi-Agent Interactions,” Proc. Second Int’l Conf.Autonomous Robots and Agents, Dec. 2004.

[7] P. Clements, R. Kazman, and M. Klein, Evaluating SoftwareArchitectures: Methods and Case Studies. Addison-Wesley, 2001.

[8] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R.Nord, and J. Stafford, Documenting Software Architectures: Viewsand Beyond. Addison Wesley, 2002.

[9] M. Dias and D. Richardson, “The Role of Event Description onArchitecting Dependable Systems (Extended Version fromWADS),” Lecture Notes in Computer Science—Book on ArchitectingDependable Systems, Spring-Verlag, 2003.

[10] Sun Microsystems, http://java.sun.com/products/ejb/docs.html,2006.

[11] M.D. Ernst, J. Cockrell, W.G. Griswold, and D. Notkin, “Dynami-cally Discovering Likely Program Invariants to Support ProgramEvolution,” IEEE Trans. Software Eng., vol. 27, no. 2, Feb. 2001.

[12] D. Garlan, R.J. Allen, and J. Ockerbloom, “Exploiting Style inArchitectural Design,” Proc. ACM SIGSOFT ’94 Symp. Foundationsof Software Eng., 1994.

[13] D. Garlan, R.T. Monroe, and D. Wile, “Acme: ArchitecturalDescription of Component-Based Systems,” Foundations of Compo-nent-Based Systems, G. Leavens and M. Sitaraman, eds., CambridgeUniv. Press, 2000.

[14] D. Garlan, A.J. Kompanek, and S.-W. Cheng, “Reconciling theNeeds of Architectural Description with Object Modeling Nota-tions,” Science of Computer Programming, vol. 44, no. 1, pp. 23-49,July 2002.

[15] D. Garlan, S.-W. Cheng, and B. Schmerl, “Increasing SystemDependability through Architecture-Based Self-Repair,” Architect-ing Dependable Systems, R. de Lemos, C. Gacek, and A. Roma-novsky, eds., Springer-Verlag, 2003.

[16] Sun Microsystems, http://java.sun.com/docs/books/j2eetutorial/index.html, 2006.

[17] D. Jackson and A. Waingold, “Lightweight Extraction of ObjectModels from Bytecode,” Proc. 1999 Int’l Conf. Software Eng., 1999.

[18] Sun Microsystems, http://java.sun.com/products/jdbc, 2006.[19] K. Jensen, “An Introduction to the Theoretical Aspects of

Coloured Petri Nets,” A Decade of Concurrency, J.W. de Bakker,W.-P. de Roever, and G. Rozenberg, eds., pp. 230-272, Springer-Verlag, 1994.

[20] G. Kaiser, J. Parekh, P. Gross, and G. Veletto, “KinestheticseXtreme: An External Infrastructure for Monitoring DistributedLegacy Systems,” Proc. Fifth Int’l Active Middleware Workshop, 2003.

[21] R. Kazman and S.J. Carriere, “Playing Detective: ReconstructingSoftware Architecture from Available Evidence,” J. AutomatedSoftware Eng., vol. 6, no. 2, 1999.

[22] R. Kazman, J. Asundi, J.S. Kim, and B. Sethananda, “A SimulationTestbed for Mobile Adaptive Architectures,” Computer Standardsand Interfaces, 2003.

[23] G. Kiczales, E. Hilsdale, J. Huginin, M. Kersten, J. Palm, and W.Griswold, “Getting Started with AspectJ,” Comm. ACM, vol. 4,no. 10, Oct. 2001.

[24] P. Kruchten, “The 4+1 View Model of Architecture,” IEEESoftware, vol. 12, no. 6, pp. 42-50, 1995.

[25] D.C. Luckham, “Rapide: A Language and Toolset for Simulationof Distributed Systems by Partial Orderings of Events,” Proc.DIMACS Partial Order Methods Workshop, 1996.

[26] N. Madhav, “Testing Ada 95 Programs for Conformance toRapide Architectures,” Proc. Reliable Software Technologies—AdaEurope ’96, 1996.

[27] N. Medvidovic and R.N. Taylor, “A Classification and Compar-ison Framework for Software Architecture Description Lan-guages,” IEEE Trans. Software Eng., vol. 26, no. 1, pp. 70-93, Jan.2000.

[28] G.C. Murphy, D. Notkin, and K.J. Sullivan, “Software ReflexionModels: Bridging the Gap between Source and High-LevelModels,” Proc. 1995 ACM SIGSOFT Symp. Foundations of SoftwareEng., 1995.

[29] M. Mansouri-Samani and M. Sloman, “GEM: A Generalized EventMonitoring Language for Distributed Systems,” IEE/IOP/BCSDistributed Systems Eng. J., vol. 4, no. 2, June 1997.

[30] L. O’Brien and C. Stoermer, “Architecture Reconstruction CaseStudy,” Software Eng. Inst. Technical Note CMU/SEI-2003-TN-008, 2003.

[31] D. Perry and A. Wolf, “Foundations for the Study of SoftwareArchitecture,” ACM SIGSOFT Software Eng. Notes, vol. 17, no. 4,1992.

[32] S. Reiss, “JIVE: Visualizing Java in Action (DemonstrationDescription),” Proc. 25th Int’l Conf. Software Eng., 2003.

[33] B. Schmerl and D. Garlan, “AcmeStudio: Supporting Style-Centered Architecture Development (Demonstration Descrip-tion),” Proc. 26th Int’l Conf. Software Eng., May 2004.

[34] M. Shaw, R. Deline, D. Klein, T.L. Ross, D.M. Young, and G.Zelesnik, “Abstractions for Software Architecture and Tools toSupport Them,” IEEE Trans. Software Eng., vol. 21, no. 4, Apr. 1995.

[35] M. Shaw and D. Garlan, Software Architecture: Perspectives on anEmerging Discipline. Prentice Hall, 1996.


[36] O. Spinczyk, A. Gal, and W. Schroder-Preikschat, “AspectC++: AnAspect-Oriented Extension to the C++ Programming Language,”Proc. 40th Int’l Conf. Tools Pacific: Objects for Internet, Mobile, andEmbedded Applications, vol. 10, 2002.

[37] R.N. Taylor, N. Medvidovic, K.M. Anderson, E.J. Whitehead, J.E.Robbins, K.A. Nies, P. Oriezy, and D. Dubrow, “A Component-and Message-Based Architectural Style for GUI Software,” IEEETrans. Software Eng., vol. 22, no. 6, June 1996.

[38] S. Vestel, “MetaH Programmer’s Manual, Version 1.09,” technicalreport, Honeywell Technology Center, 1996.

[39] M. Vieira, M. Dias, and D.J. Richardson, “Software ArchitectureBased on Statechart Semantics,” Proc. 10th Int’l Workshop Compo-nent Based Software Eng., 2001.

[40] R.J. Walker, G.C. Murphy, B. Freeman-Benson, D. Wright, D.Swanson, and J. Isaak, “Visualizing Dynamic Software SystemInformation through High-Level Models,” Proc. ACM SIGPLANInt’l Conf. Object-Oriented Programming, Systems, Languages, andApplications (OOPSLA), 1998.

[41] R.J. Walker, G.C. Murphy, J. Steinbok, and M.P. Robillard,“Efficient Mapping of Software System Traces to ArchitecturalViews,” Proc. CASCON, S.A. MacKay and J.H. Johnson, eds., 2000.

[42] W3C Consortium, “XQuery 1.0 and XPath 2.0 Formal Semantics,W3C Working Draft 4 April 2005,” http://www.w3.org/TR/2005/WD-xquery-semantics-20050404/, Apr. 2005.

[43] D. Wells and P. Pazandak, “Taming Cyber Incognito: SurveyingDynamic/Reconfigurable Software Landscapes,” Proc. First Work-ing Conf. Complex and Dynamic Systems Architectures, 2001.

[44] W3C, http://www.w3.org/TR/xquery/, 2006.[45] W3C, http://www.w3.org/XML/, 2006.[46] H. Yan, D. Garlan, B. Schmerl, J. Aldrich, and R. Kazman,

“DiscoTect: A System for Discovering Architectures from RunningSystems,” Proc. 26th Int’l Conf. Software Eng., May 2004.

[47] H. Yan, J. Aldrich, D. Garlan, R. Kazman, and B. Schmerl,“Discovering Architectures from Running Systems: LessonsLearned,” Technical Report CMU/SEI-2004-TR-016, Dec. 2004.

[48] J. Xu and J. Kuusela, “Modeling Execution Architecture ofSoftware System Using Colored Petri Nets,” Proc. First Int’lWorkshop Software and Performance (WOSP ’98), pp. 70-75, Oct.1998.

[49] A. Zeller, “Animating Data Structures in DDD,” Proc. SIGCSE/SIGCUE Program Visualization Workshop, 2000.

[50] D. Zhu and A.S. Sethi, “SEL, A New Event Pattern SpecificationLanguage for Event Correlation,” Proc. ICCCN-2001, 10th Int’lConf. Computer Comm. and Networks, Oct. 2001.

Bradley Schmerl received the PhD degree incomputer science from Flinders University inSouth Australia. He is a senior systems scientistat Carnegie Mellon University. His researchinterests include dynamic adaptation, softwarearchitectures, and software engineering environ-ments.

Jonathan Aldrich received the PhD degreefrom the University of Washington. He is anassistant professor of computer science atCarnegie Mellon University. His research inter-ests include applying language and programanalysis and verification techniques to softwareengineering problems.

David Garlan received the PhD degree incomputer science from Carnegie Mellon Uni-versity (CMU). He is a professor of computerscience at CMU. His research interests includesoftware architectures, formal methods, self-healing systems, and task-based computing.

Rick Kazman received the PhD degree incomputational linguistics from Carnegie MellonUniversity (CMU). He is a visiting scientist at theSoftware Engineering Institute and CMU and aprofessor of information technology manage-ment at the University of Hawaii. His researchinterests include software architecture, softwaredesign, analysis, and reverse engineering tools,open source software, and software engineeringeconomics.

Hong Yan is a doctoral candidate in computerscience at Carnegie Mellon University. Hisresearch interests include design and analysisof software systems and computer networks.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Discovering Architectures from Running Systems: Lessons Learned

Documents

Transcript of Discovering Architectures from Running Systems: Lessons Learned