A Comparison and Evaluation of Architecture Recovery in Data-Intensive Systems using Focus

Transcription

1 A Comparison and Evaluation of Architecture Recovery in Data-Intensive Systems using Focus Chris Mattmann and Paul Ramirez Computer Science Department University of Southern California Los Angeles, CA USA ABSTRACT Architecture recovery is an emerging practice in which the architecture of a software system is extracted from relevant available information including source code, documentation and observations of system s runtime behavior. Typically architecture recovery has been performed on statically linked software systems which have well-defined architectural configurations (arrangements of software components and software connectors). Recently, dynamically linked software applications which rely on middleware implementation facilities have become critical to facilitate source code reuse, dynamic binding and system heterogeneity. Data-Intensive software systems rely heavily on middleware implementation facilities for the aforementioned properties. These systems are becoming an important research area as data-volumes approach the near petabyte scale and little or no reuse of architecture, design or code exists at this point in time. Our study centers on the architectural recovery of two such data-intensive software systems, OODT and the Globus Toolkit using the Focus architecture recovery approach. We present our recovered architectures, provide insight with regards to architecture recovery of middleware systems and finally we conclude by evaluating the architecture recovery method itself. Further, our work can be used to drive architecture recovery in the data-intensive system domain. 1 INTRODUCTION Large-scale software development typically commences with requirements gathering, follows with architecture construction, then high-level design, then implementation and concludes with software maintenance or evolution. As a software system evolves so does its implementation, and ideally its architecture as well. In practice; however, the evolution of the architecture is not synchronized with the evolution of the implementation, phenomena described by Perry and Wolf as architectural erosion [1]. Although there are many accepted reasons for this (e.g. lack of manpower, lack of understanding of the system s as-documented architecture, changing of the guard, etc.), as software engineers we are still left with the problem of ensuring that a software system s architecture is kept up to date with its implementation; otherwise, its utility significantly decreases [2, 3]. In software architecture research, this process of mapping a system s implementation to its architecture is known as software architecture recovery. Middleware technologies have emerged as copper bullets [4] promising to attack some of the pitfalls of large-scale software development such as the architectural erosion phenomena described above. The main focus of middleware is to shift software architecture-based development from the current process of static design synchronized with static implementation (where the system s as documented architecture must be synchronized with the implementation to reflect and model its current state), to dynamic design synchronized with static implementation 1

2 (where the system s as documented architecture may evolve despite its given static implementation). One new class of software systems that rely extensively on middleware as implementation-level substrates are data-intensive systems. Data-intensive systems are large-scale distributed software systems which integrate information from heterogeneous data sources [5]. As data volumes approach near petabyte scale, as software implementation languages and middleware substrates change every few years, and as data models which describe data are poorly documented at best; sound architecture-based design of data-intensive systems has the potential to influence the processing, access, and distribution of unimaginable sizes of data to a worldwide community for years to come. Unfortunately, our recent study of architecture in data-intensive systems [5] paints a grim picture of architecture-based principled construction of data-intensive systems. In fact, the need for architecture-based, principled construction of data-intensive systems arises out of a need to migrate legacy data systems, which do not interoperate and cannot be reused (two clear benefits of architecture-based software development [1, 6, 7]), into data systems which address these limitations. The focus of this paper is on two such large-scale, data intensive software systems, which use middleware implementation substrates: the OODT (Object Oriented Data Technology) Middleware [8] and the Globus Toolkit [9]. In both cases, each respective middleware system is depicted in the literature [5, 8-12] as simple box and arrow designs. Our experience tells us that these systems are likely more complex than their rudimentary box and arrow designs [13]; thus, we have sought out to investigate our intuition using the Focus architecture recovery approach [3, 14], a lightweight, incremental approach to architectural recovery and architecture evolution. For our purposes, we were interested in Focus s ability to perform architecture recovery, although evolution of data-intensive systems is also an open area of research [5]. We also used this work to evaluate the Focus method as an architecture recovery approach. In the literature [3, 14], Focus claims to recover not only a system s processing components, but also its data components, which is of great interest, because we believed, and in the case of OODT knew, that these systems rely heavily on data components at the architectural level. The rest of this paper is organized as follows. Section 2 presents our work recovering the architectures of the OODT Middleware, the Globus Toolkit, and the Metadata Catalog Service (a static software component built on top of the Globus Toolkit). Section 3 discusses the differences that arose recovering the architectures of middleware-based systems, as opposed to static software systems (as was the case with the previous case studies that involved Focus). In Section 4, we critically evaluate Focus, both quantitatively and qualitatively, with regards to its ability to recover the architectures of data-intensive systems, as well as compare it to other architectural extraction approaches using an evaluation method that we found in the literature. Section 5 surveys related work. Section 6 rounds out the paper. 2 RECOVERED ARCHITECTURES The Focus approach was performed on Java implementations of the OODT Middleware, the Globus Toolkit and the Grid Metadata Catalog Service (MCS) using the Java reverse-engineering capabilities of Rational Rose [15]. In this section, we highlight the relevant steps of architectural recoveries by pointing to the rules of Focus that were applied iteratively to arrive at our results. 2.1 Recovering the architecture of the OODT Middleware The OODT Middleware [10, 16] is a middleware infrastructure developed at the Jet Propulsion Laboratory geared towards supporting scientific, data-intensive systems. The key distinction between OODT and other types of middleware infrastructures is the first-class status that OODT 2

3 gives to its data components. Throughout software architecture research, data components are identified as first-class citizens [1, 7] ; although curiously it is rare that data components are actually the emphasis of software system development. This is evidenced by the neglect of most software architecture recovery techniques to explicitly recover data components in any form [3]. Subsequently, the idealized architectural model of the OODT middleware entails 8 explicit components, and one connector. Of the 8 components, there exist 3 server components, 3 client components, one connector, and 2 data components, all of which are shown in the UML 1 class diagram below. Figure 1. The OODT idealized model. Since Focus claims to support recovery of data components explicitly, our assumption was that our architectural recovery of OODT would include both the 6 processing components and the 2 data components. Our recovery of OODT consisted of 3 iterations of the base set of Focus rules, along with domain-specific rules that we exploited to aid in our recovery process. Our first iteration, shown below consisted of Focus rules 1 (Figure 2b), 2 (Figure 2c), 5 (Figure 2d), 6 (Figure 2e), and 7 (Figure 2f) (grouping based upon diagram position and aggregation, identification of domain classes, grouping based upon domain classes and grouping based upon path dependency with domain classes respectively). The second step of our recovery is presented in Figure 3 below, and is highlighted by the application of Focus rules 6 and 7 (a second application of these rules), and also the application of a new rule that we used to group classes together. The rule is based on the fact that after applying Focus rule 7 in the second iteration, we were stuck and could not apply any further Focus rules to refine the architecture. Under normal circumstances, this would indicate the recovery process has completed; however, our domain-specific knowledge of OODT told us otherwise. 1 We use UML to visually represent software architectures throughout this paper on the basis of its widespread acceptance and understanding in the software engineering community 3

4 a b d c e f Figure 2. First iteration of Focus applied to OODT a b Figure 3. Second iteration of Focus applied to OODT c One item of interest that we could exploit from the existing diagram above was the fact that many of the classes above did not share relationships Focus could recognize yet they did share other types of relationships. For example, in Figure 3b above, 14 classes contained the term Exception (this was determined by examining the name of the class, which would contain the string Exception ). In this manner, we felt (and later verified) that these classes all related to different type of Exceptions, which are well known OO constructs for structured error recovery in OO languages (such as C++ and Java). Because of this relationship, these classes could be grouped together into a higher-level Exception component, a data component and an architecturally relevant facet. Exception data components are typically handled by some sort of Exception 4

5 processing component, so it is also possible to add an Exception processing component to handle the exception data. In essence, our new rule 2 can be summarized as: Rule A: Group related classes which share the string Exception in their class name into an Exception data component and if desired also an Exception processing component. a b Figure 4. Third iteration of Focus applied to OODT Next, we removed 15 classes from Figure 4a which contained the word test 3, leaving us with about 20 classes with no existing relationships in the diagram. At this point, we realized an architecturally relevant facet that was not included in the Focus approach. In OOPLs (Object- Oriented Programming Languages), Interfaces are used to relate classes together that share the same method. Interfaces can be considered abstract components which expose a particular set of methods. In this manner, one way to relate classes would be to examine if they implement the same interface. If they do, then the classes could be grouped into a higher level component which exposes the particular public methods of the particular interface. To this end we feel that we have arrived at a general rule to complement the other rules in Focus s rule base. We summarize our rule below: Rule B: Group related classes which share the same Interface into a higher level component with the same name as the interface, and the same public methods. We do not believe that this rule is particularly limiting in the sense that OO languages typically provide some support for interfaces (in C++, virtual functions within abstract classes can be 2 We acknowledge that Exception classes may also be related through generalization (to a higher level Exception class, such as java.lang.exception in java); however, we note that by default, reverse engineering tools like Rose do not show these types of relationships when automatically generating class diagrams 3 We could have chosen to not include these classes initially using the OTS tool s reverse engineering capabilities, but we chose to just include all the classes and perform the filtering of irrelevant classes as we came to them 5

6 considered interfaces, in Java, there is explicit support). In Figure 4b, we were able to use this information to recover the Product Server component, the Profile Server component, and the Query Server component. Each component was recovered by examining the interface relationships to the classes which implemented each specific interface. At this point, we had finished recovering both the data and processing components of the OODT middleware. We arrived at this conclusion by comparing the recovered classes present in Figure 4b to the OODT idealized model. Since the set of recovered components present in Figure 4b was a super-set of the components in the OODT idealized model, we knew that we were finished. An independent step in the Focus approach during recovery of processing and data components involves modeling the relevant use-cases that the software system should support. The use-cases allow one to observe the run-time needs of the software system, and what high-level functionalities it should support. Use-cases can be acquired from either observing the system at run-time or extracted from relevant documentation. Below, we present the use-cases that we extracted from relevant literature [10-12] which point to capabilities that a data-intensive middleware system should support. Figure 5. Data-Intensive Use-Cases. Once both data and processing components are recovered, the next step in architectural recovery using Focus is modeling the recovered processing and data components ability to support the 6

7 relevant use-cases for such a software system. With respect to OODT, Figures 6 and 7 present the recovered OODT components interactions using UML sequence diagrams. Figure 6. OODT components supporting query and retrieve data from distributed data sources a b Figure 7. OODT Components supporting query and retrieve data (a), and query and retrieve metadata (b). 7

8 The components present in Figure 4b, the use-cases presented in Figure 5, and the sequence diagrams presented in Figures 6 and 7 marked the end of the Focus recovery for OODT. 2.2 Recovering the architecture of the Globus Toolkit Figure 8. Globus Toolkit (GT3 Core) Idealized Model The Globus Toolkit [9, 11, 17-19] is a middleware-based software system enabling the creation of virtual organizations. Virtual Organizations are possibly distributed, heterogeneous organizational entities sharing data, metadata, computing power, authorization and authentication information. Recently, a set of data-intensive service components, built on top of the Globus Toolkit, has emerged and been coined the Data Grid [12, 18]. The Grid paradigm that Globus enables has been evaluated successfully across many different existing projects as shown in the literature [9, 12, 17, 20-22] and among the recent midst of interest and projects that are using Grid software, our first goal was to investigate and examine the architecture of the most prevalent implementation of the Grid paradigm, the Globus Toolkit. Our second goal was to compare and contrast the recovered Grid architecture from Globus against that of the recovered architecture of OODT. Initially our assumption was that the Data Grid concept that builds on Globus services would reify itself in the recovered architecture of Globus, and therefore we felt 8

9 that both the recovered data and processing components of Globus would have much similarty to those of OODT. And, since both middlewares run on top of an underlying middleware implementation substrate (in OODT s case, this is the pluggable messaging layer connector, in Globus, this is the web-services framework), we felt that the connector relationships would also be similar. To begin our architectural recovery of Globus, we found the idealized model of gt3_core, Globus Toolkit s underlying implementation infrastructure. The GT3 core idealized model is depicted in Figure 8. From the idealized model, we could expect to recover 8 processing components. Surprisingly; however, there were not any data components in the GT3 core idealized model. The recovery of Globus Toolkit s architecture consisted of 3 Focus iterations, once again consisting of applying iteratively the existing rules within the Focus rule-based, as well as exploiting some domain-specific information to aid in our recovery. We also used Globus as a case-study to evaluate the previous new Focus rules we introduced (recall Section 2.2), Rule A and Rule B. Figure 9a represents the initial class diagram extracted from the gt3_core jar file. Figures 9b, 9c, 9d and 9e correspond to Focus rules 1, 2, 6 and 7 respectively. a d b c Figure 9. First iteration of Focus applied to Globus e 9

10 a c b Figure 10. Second Iteration of Focus applied to Globus d a b Figure 11. Third and final iteration of Focus applied to Globus Figures 10 a-d correspond to the second iteration of Focus applied to the Globus middleware. Figure 10a marks the beginning of the second iteration of Focus applied to Globus. In Figure 10b, we apply Rule A and group together classes which are related by Exception data. Of interest in Figure 10c was that we were once again stuck and unable to group any further components from the class diagram of the Globus toolkit. One thing we noticed which was exploitable, 10

11 (which also could be noticed in the initial recovery of OODT) was grouping classes based upon similar class names. Although this tactic is entirely subjective, we believe that it is not entirely without utility and can help in cases where there are no relevant rules left to apply. Figures 11a and 11b mark the end of applying Focus to the Globus toolkit. In Figure 11a, we have applied another domain specific tactic that we believe can be further generalized into a Focus rule. We noticed in Figure 11a that there were several disjoint classes that all shared the same java package name, but no other relationships in the diagram. Since the Globus idealized architectural model had only 8 processing components we felt that there still existed several classes which could be grouped into higher level components. Put more generally, we feel that one important artifact that code developers leave behind as evidence of their envisioned architectural model of the software system is the hierarchical nature of the system s code. In this case, we have grouped together classes which share the same package. This relationship can be exploited if the package name denotes a higher level component that was present in the idealized architectural model (in our case, OGSI services was one particular package that was identified as an actual component). This particular rule may be generalizable as Object Oriented Programming Languages (OOPLs) typically have some notion of class packages, in particular Java. The fact that n classes belong to a particular package may be exploitable and therefore we present it as our fourth possible rule. Rule C: Group related classes which share the same package into a higher level component indicative of that package, if the package is referenced in the idealized architectural model as a first class component. In Figure 11b, we have exploited this rule to arrive at Figure 11b, our final step in recovering the Globus toolkit s processing and data components. In parallel, we modeled Globus Toolkit s system-level behavior using UML sequence diagrams. We discovered one particular use-case of Globus from the reference model white paper [11] included with the Globus distribution: discover and request a capability from a dynamic Globus Service. Our modeling of this use-case is depicted below and highlighted as part of Focus s usecase modeling activity. Figure 12. Discovering a Globus service and its capabilities. 11

12 Surprisingly enough; however, it seems that gt3_core does not in fact explicitly support dataintensive systems. We believed in fact, that several Globus extension services, such the Metadata Catalog Service [12], the Replica Location Service [21] and other Data Grid like services (such as GridFTP [19], etc.) are explicitly how Globus supports data-intensive system issues. By its very nature; however, gt3_core provides a middleware framework for constructing and deploying Grid-based services. The data-intensive nature of these services appeared to be an extension of the underlying core. In Section 2.3 below, we present the results of recovering the Metadata Catalog Service to investigate this notion. 2.3 Recovering the architecture of the Globus Metadata Catalog Service (MCS) Figure 13. The idealized model of the Metadata Catalog Service. The Metadata Catalog Service (MCS) [12] is a software component built using the Globus toolkit whose main goal is to provide search and retrieval of metadata describing resources within a Globus connected system. Metadata is in the form of several metadata types including User Metadata, Virtual Organization Metadata, Domain-specific Metadata, Domain-Independent Metadata and Physical Metadata. In [12], one particular use-case showing how a User could discover files within a Grid system using the Metadata Catalog Service and the Globus Replica Location Service (to find replicas of file within the context of the Globus connected system) was of much interest. This use-case explicitly satisfied the Retrieve Product Metadata use case of data-intensive systems shown in Figure 5. Figure 13 depicts the idealized model of the Metadata Catalog Service that was found in [12]. The sequence of interactions between the MCS Client and MCS Server components are relatively simple: 1. MCS Client requests metadata from the MCS Server 2. MCS Server returns metadata to the MCS Client We downloaded both the binary and source distributions of the Metadata Catalog Service from [23]. Our recovery of the MCS architecture involved two iterations of the Focus rule-base, along with application of our domain specific rules so far. Figure 14a is the initial class diagram generated from Rational Rose. Figures 14b, 14c, 14d, 14e and 14g correspond to Focus rules 12

13 a d b c e f Figure 14. First iteration of Focus applied to the MCS g 1, 2, 6, 7 and Rule C respectively. In Figure 14f, we removed classes that were deemed as test classes (recall Section 2.1) and thus considered not architecturally relevant. a c b Figure 15. Second iteration of Focus applied to MCS d 13

14 Figures 15a-d highlight the second and final iteration of Focus applied to the MCS. In Figure 15a, we depict the start of the 2nd Focus iteration. Figure 15b shows our application of Focus rule 6 (group based upon identified domain classes) to the diagram from 15a. Figure 15c uses Rule C to group based upon package name (shown circled in red). Figure 15d marks the end of our recovery of the architecture of the Metadata Catalog Service. Of interest is the fact that the idealized model of the MCS contained 4 processing components and no data components at all; however, from Figure 15d, we have recovered 10 processing components and 2 data components. The processing components recovered included the actual SOAP-based implementation of the Metadata Catalog Service (as well as its associated client component), along with a Metadata Catalog Service Client which was not SOAP-based. Figure 16 shows how the components that we recovered could explicitly support the Retrieve Product Metadata use-case mentioned above. Figure 16. Retrieve Product Metadata using recovered MCS components In Section 4, we evaluate our architecture recovery using Focus on the above three case studies and attempt to provide insight with respect to the ability of Focus to recover data-intensive software systems. One notion that we can point to directly is that there are many differences recovering the architectures of middlewares (e.g. OODT and the Globus Toolkit) as opposed to the architectures of static software systems (e.g. the MCS). In Section 3 below, we discuss these differences. 3 RECOVERING MIDDLEWARE VERSUS STATIC SOFTWARE SYSTEMS In this section, we detail the differences that we believe exist between recovering middlewarearchitectures and static software systems architecture. We begin by presenting a view of the overall process in each, and then treat our experience during our respective case studies and conclude by providing insight with regards to how each separate process can be used in architecture recovery. 3.1 Recovering Middleware Software Architectures The process of recovering a middleware system s architecture commences with an architecture recovery process which generates a Recovered Architectural Model, referred to from here on as RAM. 14

15 Figure 17. Recovering the architecture of middleware-based systems In the case of a middleware system, the RAM contains software components and connectors, yet no software configurations. For this reason, we refer to the RAM as an incomplete. The incomplete RAM contains no configurations due to the fact that middleware systems are inherently used to construct static software systems; thus rather than having its own configuration which reifies itself during the architecture recovery process, the configuration of the middleware is usually identified by the architectures of the systems that it is used to construct. This relationship has been shown in existing software architecture research. In particular, Dashofy et al. [24] have shown that software middlewares typically correspond to implementation-level remnants of software architectural connectors. The middlewares are treated as black-box like entities which handle connector-like functionalities such as message marshalling, data type conversion, delivery guarantees and other such features. Ivkovic et al. [25] also validate this intuition in their case study of recovering the architecture of the Nautilus window file manager, which uses CORBA as its communication middleware. CORBA is treated as an implementationlevel connector between Nautilus File View components. Once the incomplete middleware RAM has been recovered, the architect can use its respective components and connectors to construct one or more architectures which take advantage of their respective functionalities. 3.2 Recovering Static Software System Architectures Recovering the architecture of a static software system commences with an architecture recovery 15

16 Figure 18. Recovering static software systems architecture process, generating a Recovered Architectural Model a.k.a. RAM, which contains software components, connectors and a configuration. The RAM is then used as a baseline for the software architect to evolve and analyze the architecture of the software system as necessary. This is the most typical form of software architecture recovery. Because the RAM contains software components, connectors and configurations, it is referred to as a complete RAM. In the case studies we conducted, the Metadata Catalog Service grid component followed this particular process for its recovered architecture, although interestingly enough the configuration was not explicitly recovered from the Focus architecture recovery step. The configuration itself was formulated using a combination of the idealized architectural model and the recovered software components fro the architecture recovery step. 16

17 4 CRITICAL EVALUATION OF FOCUS Our evaluation of Focus is both quantitative and qualitative due to the two overarching goals for our project. Our first goal was to perform architecture recovery on data-intensive middlewarebased systems and then compare and contrast the similarities and differences of the recovered architectures. To this end, in section 4.1 we evaluate Focus quantitatively to assess its viability in effectively recovering the architectures of data-intensive software systems. Our second goal for the project was to asses Focus s effectiveness as an architectural recovery approach vis-à-vis the utility of its architectural recovery rules. We further sought to evaluate the rules themselves, determine their applicability in the case studies we performed, and also suggest improvements and additions to the rule-base where we felt it was needed. In Section 4.2, we present our recommendations and a qualitative evaluation of Focus according to the case studies performed. 4.1 Quantitative Evaluation Our quantitative evaluation criteria are based upon Number of Components Recovered versus Number of Components in Idealized Model. We also evaluate Focus s recovery of OODT, Globus Toolkit s and the Grid Metadata Catalog Service s (MCS v. 2.0) Processing Components versus Data Components. Focus does not explicitly recover software connectors, so we do present them here with our evaluation. Finally, the recovered architectures are each evaluated for their respective ability to support the standard use-cases for a data-intensive system presented in Section 2. properties middleware NUMBER OF COMPONENTS RECOVERED NUMBER COMPONENTS IDEALIZED MODEL PROCESSING COMPONENTS DATA COMPONENTS DATA- INTENSIVE SUPPORT (NATIVE) OODT Globus Toolkit (GT3 Core) Metadata Catalog Service (MCS v 2.0) Table 1. Evaluation of Focus approach in data-intensive systems A point of interest in our evaluation is the fact that we were performing architectural recovery on middleware in the first two case studies, rather than static software systems with well-defined configurations, as was the case with the Metadata Catalog Service case study. We also note that of the data components recovered above, all of Globus Toolkit s 15 data components were not present in the idealized model. Of the 3 recovered OODT components, 2 of them (the profile and the query object) were actually present in the idealized model. In the Metadata Catalog study, the 2 recovered data components were also not present in the idealized architecture. So in all three cases Focus was 100% effective in recovering known data components and also Focus recovered architecturally relevant data components which were not present at the idealized model level. This may be due to the fact that certain data components (such as exception data and so on) are not disseminated in idealized architectural models and just assumed to be there once the idealized model is refined into an implementation. We also note that the Metadata Catalog Service is an implementation of a Grid Service, and therefore runs on top of the Globus Toolkit we recovered in the second case study. The Metadata Catalog Service explicitly supports the Query and Retrieve Product Metadata data-intensive system use-case, so we mark its NATIVE DATA- INTENSIVE SYSTEM SUPPORT as + in the table above. 17

18 4.2 Qualitative Evaluation In this section we evaluate Focus qualitatively, based upon the only guidelines we could discover in the literature [26-28]. We conclude by evaluating the rule base of Focus against our case studies. Armstrong et al. [28] base their evaluation on three criteria, Extraction, Classification and Visualization. Extraction Refers to the recovery approach s ability to extract out a low-level model of the software system from its available source code. Classification Refers to the recovery approach s ability to group related constructs from the extracted model into higher level concepts or intermediate components. Visualization Refers to the recovery approach s ability to visualize manipulate and present the recovered architecture to the user of the approach. Their evaluation is based on a survey of five different architectural recovery techniques, SNIFF+, Rigi, PBS, CIA and Dali. Although Armstrong et al. also decompose each of the three criteria into sub-criteria, we do not present that level of comparison in our table below, due to the fact that some of the decomposed criteria involve domain-specific measurements of the architecture recovery tool support, which Focus does not explicitly provide (due to its lightweight approach). implies that the recovery method supports the property, implies the negation. Desired Property Recovery Method EXTRACTION Focus SNIFF+ Rigi PBS CIA Dali CLASSIFICATION VISUALIZATION Table 2. How Focus stacks up other architectural extractors using Armstrong s criteria. Medonça et al. [26, 27] state that the two most important requirements for an effective architectural recovery framework are a richer source code representation and an effective set of architectural analysis tools. Focus is not a strong candidate for a richer source representation because of its reliance on OTS tool support for the architectural model extraction. In order to provide a richer source representation the recovery process would mandate a different style of source code representation as input. In the case of Focus, if the OTS tool support could take a richer source code representation, then Focus could be performed on the generated intermediate model. With regards to architectural analysis tools, Focus relies heavily on the architect performing the reverse engineering process to analyze the respective intermediate architectures generated from iterative applications of the process. Focus also relies on the notion of architectural style [1, 7] to drive architecture analysis, which complicates the tool development process because analysis of styles tends to require domain-specific knowledge and intuition. We conclude our evaluation of focus by presenting our experience with the rule base of Focus on the 3 case studies we performed. We identify potential causes for phenomena encountered during the approach. We also identify rules which we did not use during the reverse-architecting process. Note that Focus implicitly supports extraction through its use of OTS tool support. 18

19 Focus Rule Description Problems Conditions RULE 1 RULE 2 RULE 3 RULE 4 RULE 5 RULE 6 RULE 7 RULE 8 RULE 9 RULE 10 Group based on isolated classes Group based on generalization Group based on aggregation Group based on composition Group based on two-way association Identify Domain classes Group classes with a single originating domain class association into domain class Group classes along a domain class circular dependency path Group classes along a path with a start node and end node that reference a domain class Group classes along paths with the same end node, and whose start node references the same domain class None Experienced None Experienced Not present in any of the case studies Not present in any of the case studies None Experienced Lots of room for error i.e. identifying the correct amount of ingoing/outgoing relationships (not always 4). Determined that rule could be applied iteratively. Potential for domain-class to be associated with one or more additional domain classes. OODT Globus MCS N/A N/A N/A N/A N/A N/A N/A N/A N/A Random number of incoming and outgoing relationships Random number of incoming and outgoing relationships Random number of incoming and outgoing relationships N/A N/A Not present in any of the case studies Not present in any of the case studies Not present in any of the case studies Table 3. Problems encountered using the Focus approach 5 RELATED WORK Ding et al. [14] present the Focus architectural recovery approach. Focus is deemed lightweight because of its reliance on OTS tool support for visual editing and clustering classes and generating class diagrams. Focus is suitable for (1) recovering the architecture of a software system from a class diagram and (2) evolving the architecture as needed. Although Focus has the potential to be a general approach, the case studies conducted to date involve only two classes of software systems GUI based (Mozilla, DrawCli, Wordpad and a Petri-Net Simulator) and webserver based (Jigsaw). Our current case studies show Focus s potential in recovering middleware-based systems and data-intensive software systems as does the related work involving dynamically linked applications below. I. Ivkovic et al. [25] conduct a case-study of recovering the architecture of dynamically-linked applications, e.g. applications that involve the use of middleware. They present an apply an architecture recovery method for dynamically linked systems, Dynamo-1, that combines the filtering and clustering approach of PBS (Portable Bookshelf) [29] and the use-case modeling aspect of Focus. Dynamo-1 is applied to Nautilus, a graphically-rich Windows-explorer like 19

20 interface for GNOME, the GNU Desktop environment. Nautilus uses CORBA for distributed communication between window-manager objects. This work is most-related to ours; although the application in this case-study is more GUI-intensive (hence the choice of C2 [30] as the idealized architectural model s style) than Data-Intensive. Also, our work applies Focus as-is, rather than combining it with additional clustering techniques. 6 CONCLUSIONS This paper motivated, presented, and validated the architectural recovery of two data-intensive middleware systems using the Focus architectural recovery approach. The middleware systems, the OODT middleware and the Globus Toolkit, were hypothesized to be similar because of their respective success as data-intensive middleware solutions, and were later shown to both have similar properties and stark differences. We followed with a discussion of the differences between recovering static software systems versus those of dynamic software systems (e.g. those based on middleware implementation substrates). The Focus recovery approach was evaluated both quantitatively and qualitatively and its limitations were discussed. The paper rounded out by surveying related work in the area. REFERENCES [1] D. E. Perry and A. L. Wolf, "Foundations for the Study of Software Architecture," ACM SIGSOFT Software Engineering Notes (SEN), vol. 17, [2] R. Kazman and S. J. Carriere, "Playing Detective: Reconstructing Software Architecture from Available Evidence," Automated Software Engineering, vol. 6, pp , [3] N. Medvidovic and V. Jakobac, "Using Software Evolution to Focus Architectural Recovery," Automated Software Engineering, vol. To appear, [4] F. P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer, [5] C. Mattmann, D. Crichton, J. S. Hughes, S. Kelly, and P. Ramirez, "Software Architecture for Large-scale, Distributed, Data-Intensive Systems," presented at 4th IEEE/IFIP Working Conference on Software Architecture (WICSA-4), Oslo, Norway, [6] N. Medvidovic and R. N. Taylor, "Separating fact from ficiton in software architecture," presented at 3rd International Workshop on software architecture (ISAW-3), Orlando, Florida, [7] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline: Prentice Hall, [8] S. Kelly, "Object-Oriented Data Technology (OODT)," vol. 2004, [9] Globus, "The Globus Alliance," vol. 2004, [10] D. J. Crichton, J. S. Hughes, and S. Kelly, "A Science Data System Architecture for Information Retrieval," in Clustering and Information Retrieval, W. Wu, H. Xiong, and S. Shekhar, Eds.: Kluwer Academic Publishers, 2003, pp [11] T. Sandholm and J. Gawor, "Globus Toolkit 3 Core - A Grid Service Container Framework," Argonne National Laboratory [12] G. Singh, S. Bharathi, A. Chrevenak, E. Deelman, C. Kesselman, M. Manohar, S. Patil, and L. Pearlman, "A Metadata Catalog Service for Data-Intensive Applications," presented at IEEE International Conference on Supercomputing, [13] M. Shaw and P. Clements, "A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems," presented at 21st IEEE International Computer Software and Applications Conference (COMPSAC), [14] L. Ding and N. Medvidovic, "Focus: A lightweight, incremental approach to software architecture recovery and evolution," presented at 2001 Working IEEE/IFIP Conference on Software Architectures (WICSA 2001), Amsterdam, Netherlands, [15] IBM, "Rational software from IBM,"

21 [16] D. Crichton, S. Hughes, S. Kelly, and P. Ramirez, "A Component Framework Supporting Peer Services for Space Data Management," presented at IEEE Aerospace Conference, Big Sky, Montana, [17] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, "Grid Services for Distributed System Integration," IEEE Computer, pp , [18] A. L. Chervenak, I. Foster, C. Kesselman, C. Salisbury, and S. Tuecke, "The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Datasets," Journal of Network and Computer Applications, pp. 1-12, [19] C. Kesselman, I. Foster, and S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations," International Journal of Supercomputing Applications, pp. 1-25, [20] E. Deelman, R. Plante, C. Kesselman, G. Singh, M. Su, G. Greene, R. Hanisch, N. Gaffney, A. Volpicelli, J. Annis, V. Sekhri, T. Budavari, M. Nieto-Santisteban, W. O'Mullane, D. Bohlender, T. McGlynn, A. Rots, and O. Pevunova, "Grid-Based Galaxy Morphology Analysis for the National Virtual Observatory," presented at IEEE Conference on Supercomputing, Phoenix, AZ, [21] A. Chervenak, E. Deelman, I. Foster, L. Guy, W. Hoschek, A. Iamnitchi, C. Kesselman, P. Kunszt, M. Ripeanu, B. Schwartzkopf, H. Stockinger, K. Stockinger, and B. Tierney, "Giggle: A Framework for Constructing Scalable Replica Location Services," presented at IEEE Supercomputing Conference, Baltimore, MD, [22] J. Blythe, E. Deelman, Y. Gil, and C. Kesselman, "Transparent Grid Computing: A Knowledge- Based Approach," presented at Innovative Applications of Artificial Intelligence (IAAI), [23] Globus, "Grid Metadata Catalog Service," [24] E. M. Dashofy, N. Medvidovic, and R. N. Taylor, "Using Off the Shelf Middlewares to Implement Connectors in Distributed Software Architectures," presented at International Conference on Software Engineering (ICSE), Los Angeles, CA, [25] I. Ivkovic and M. W. Godfrey, "Architecture Recovery of Dynamically Linked Applications: A Case Study," presented at 10th IEEE International Workshop on Program Comprehension, Paris, France, [26] N. C. Mendonca and J. Kramer, "Requirements for an effective architecture recovery framework," presented at 2nd ACM SIGSOFT International Software Architecture Workshop (ISAW-2), San Fransisco, CA, [27] N. C. Mendonca, "Architecture Recovery for Distributed Systems," Stuttgart [28] M. N. Armstrong and C. Trideau, "Evaluating Architectural Extractors," presented at IEEE Working Conference on Reverse Engineering (WCRE), Honolulu, Hawaii, [29] I. T. Bowman, R. C. Holt, and N. V. Brewster, "Linux as a Case Study: Its Extracted Software Architecture," presented at International Conference on Software Engineering (ICSE), Los Angeles, CA, [30] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. W. Jr., J. Robbins, K. A. Nies, P. Oreizy, and D. L. Dubrow, "A Component-and-Message-Based Architectural Style for GUI Software," IEEE Transactions on Software Engineering, vol. 22, pp ,