An aspect-oriented reference architecture for Software Engineering Environments

The Journal of Systems and Software 84 (2011) 1670–1684

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

An aspect-oriented reference architecture for Software Engineering Environments Elisa Y. Nakagawa ∗ , Fabiano C. Ferrari, Mariela M.F. Sasaki, José C. Maldonado Department of Computer Systems, University of São Paulo, São Carlos, SP, Brazil

a r t i c l e

i n f o

Article history: Received 8 September 2009 Received in revised form 19 April 2011 Accepted 20 April 2011 Available online 30 April 2011 Keywords: Software Engineering Environment Software architecture Reference architecture Aspect orientation Software testing

a b s t r a c t Reusable and evolvable Software Engineering Environments (SEEs) are essential to software production and have increasingly become a need. In another perspective, software architectures and reference architectures have played a significant role in determining the success of software systems. In this paper we present a reference architecture for SEEs, named RefASSET, which is based on concepts coming from the aspect-oriented approach. This architecture is specialized to the software testing domain and the development of tools for that domain is discussed. This and other case studies have pointed out that the use of aspects in RefASSET provides a better Separation of Concerns, resulting in reusable and evolvable SEEs. © 2011 Elsevier Inc. All rights reserved.

1. Introduction Software Engineering Environments (SEEs) have become an essential part of the software engineering practice, combining processes, techniques, methods and tools to support software engineers (Harrison et al., 2000). Different understandings can be found for SEE; in this work, we consider SEE as an integrated collection of tools that cover the entire software life cycle, or at least significant portions of it, as discussed by Harrison et al. (2000). A diversity of SEEs has emerged in the last decades. However, these SEEs have almost always been individually and independently implemented, relying on tailor-made architectures and internal structures and, sometimes, not considering integration, evolution and reuse features. Software architectures have received recognition as an important subfield of Software Engineering. According to Shaw and Clements (2006), software architectures will attain the status of all truly successful disciplines. Besides that, software architectures play a major role in determining system quality, since they form the backbone to any successful software-intensive system. Decisions made at the architectural level directly enable, facilitate, hamper or interfere with achieving business goals as well as meeting functional and quality requirements. In the literature, there are different definitions for software architecture (Bass et al., 2003; Garlan, 2000; Software Engineering Institute, 2011). In this work,

∗ Corresponding author. Tel.: +55 16 3373 9662; fax: +55 16 3373 9650. E-mail address: [email protected] (E.Y. Nakagawa). 0164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2011.04.052

we adopt software architecture as a structure (or a set of structures) of the system which comprises software elements, the externally visible properties of those elements, and the relationships among them (Bass et al., 2003). In this context, reference architectures have emerged as an element that aggregates knowledge of a specific domain by means of activities and their relationships. They promote reuse of design expertise by achieving solid, well-recognized understanding of a specific domain. Reference architectures for different types of systems can be found, such as embedded systems (Eklund et al., 2005) and web browsers (Grosskurth and Godfrey, 2005). Initiatives of reference architectures for Software Engineering area can also be found (ECMA and NIST, 1993; Eickelmann and Richardson, 1996). In this scenario, Separation of Concerns (SoC) is recognized as a major concept to build evolvable and reusable SEEs (Harrison et al., 2000; Herrmann and Mezini, 2000). In regard to that, Aspectoriented Programming (AOP) (Kiczales et al., 1997) consists in an approach that supports a better SoC and more adequately reflects the way developers think about the system. Essentially, AOP introduces a unit of modular implementation – the aspect – which has been typically used to encapsulate crosscutting concerns in software systems (i.e., concerns that are spread across or tangled with other concerns). Modularity, maintainability and facility to write software can be achieved with AOP (Laddad, 2003). Aspects have also been explored in the early life cycle phases, including architectural design (Navarro et al., 2007). According to Baniassad et al. (2006), aspects in early phases support easier identification and analysis of aspects during later phases and, as a consequence, a better SoC in the systems. Additionally, initiatives of reference

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

architectures that embody aspects in their structures can also be found (Greenwood et al., 2008). We have hypothesized that aspects inserted in reference architectures of SEEs could contribute to the development of reusable and evolvable SEEs and related tools. Thus, in this paper, we have four goals (i) to present a reference architecture for SEEs, named RefASSET (Reference Architecture for Software Engineering Tools), which encompasses knowledge and experiences of SEE development as well as aspects in the architectural level; (ii) to present a process to support the application of RefASSET in the development of software engineering tools; (iii) to present a specialization of RefASSET for the software testing domain and to discuss the development of tools for that domain; and (iv) to present a mechanism that makes possible to build tools that implement the aspects contained in the RefASSET. This will enable us to perform an evaluation of the utility of RefASSET. The results achieved in our work motivate the use of aspects in reference architectures for SEEs enabling the incremental development of independent and reusable software engineering tools, aiming at reusable and evolvable SEEs. This paper is organized as follows. In Section 2, we present the background on SEEs and summarize the related work. In Section 3, RefASSET is described. In Section 4, we present how to develop tools based on RefASSET. In Section 5, we discuss results, lessons learned and limitations of this work. Finally, in Section 6, we present our conclusions and future work.

2. Background and related work In the late 1980s, the emergence of the first SEEs, such as Arcadia (Taylor et al., 1988) and PCTE (Boudier et al., 1989), as well as the Wasserman’s work (1990) that discussed the dimensions of SEE integration, motivated and contributed to the establishment of a reference model for SEEs by ECMA and NIST (1993). This model served as a conceptual basis for describing and comparing SEEs. It defined a set of services to model the functional capabilities of a SEE framework. These services were grouped into object management, process management, user interface, communications and tools. Such model showed that services were provided within the integrated framework for data, control, interface, and processes integration. Thus, it is important to highlight that the need for integration and communication among tools as well as the need for software process management were important issues imposed by that model, since the beginning. During the 1990s, several SEEs were developed and, according to Harrison et al. (2000), they represented the most significant area of research over that decade. In particular, Process-centered Software Engineering Environments (PSEEs), i.e., sets of software engineering tools that support the modeling and execution the software processes, stood out. The explicit representation of software processes in PSEEs was the foundation on which modern integrated development environments have been developed. Important examples of PSEEs include EPOS (Conradi et al., 1991), SPADE (Bandinelli et al., 1996) and OIKOS (Ambriola et al., 1990). Considering the need of SoC in SEEs, Ossher and Tarr (2000a) discussed the first link between SEEs and aspects (from AOP). They presented a case study involving the development of a simple SEE using Hyper/J, a tool that supports multi-dimensional SoC, which they named hyperspaces approach (Ossher and Tarr, 2000b). In the same perspective, Herrmann (2002) presented an experience in applying multi-dimensional SoC in a SEE. Multi-dimensional SoC considers concerns from different dimensions, such as aspects (from AOP) (Kiczales et al., 1997), features (Turner et al., 1998), and roles (Andersen and Reenskaug, 1992), aiming at a full, complete SoC. It is worth highlighting that, before that, Garlan (1987)

1671

developed mechanisms for SEEs that had resemblance to what later became the hyperspaces approach. During 2000, in spite of SEE conference series being discontinued, academic and commercial tools and SEEs have been produced and more and more used; however, the focus was no longer specifically in tool integration. In 2004, the “Workshop on Directions in Software Engineering Environments” (Grundy et al., 2004) discussed and synthesized the state of the art related to tools and SEEs, assessing the progress of researches and identifying future research directions. Among the main topics identified, we can highlight the need of SEEs for collaborative software development and the use of open source development tools to improve tool integration, since earlier attempts for tool integration failed because commercial tool vendors were unwilling to invest in porting tools to a common platform, according to Wasserman (2004). In parallel to that, IBM created the Eclipse project.1 In particular, Eclipse is an Integrated Development Environment (IDE), i.e., an integrated programming environment that provides a Graphical User Interface (GUI) builder, a text or code editor, a compiler and/or interpreter, and a debugger. Eclipse does not address the dimensions of integration, such as, the process integration, as defined in ECMA TR/55; thus, in the essence, it is not considered a SEE. However, Eclipse is currently seen as a promising tool due to its plugin-based architecture that is based on the OSGi (formerly known as the Open Services Gateway initiative) standard (OSGi Alliance, 2011). This standard specifies a set of rules that allow developers to implement and easily integrate new applications to Eclipse using common services and infrastructure. This architecture has facilitated the Eclipse evolution, as observed through a diversity of applications that can be easily integrated into it (e.g., AJDT2 for aspect-oriented development and M2Eclipse3 provides integration of Apache Maven, a software project management tool, for Eclipse). In the context of IDE, we can find initiatives that use aspects (from AOP) in order to provide connection among plug-ins or modules. For instance, Eclipse plug-ins have used the aspect binding concept of the Aspect-oriented Programming language ObjectTeams/Java (Herrmann et al., 2007) (that is based on Object Teams concept (Herrmann, 2002)) in order to connect with other plug-ins. Essentially, we can find a diversity of SEEs presenting varied architectures, specific and non-standard internal structures, distinct data representations, different user interfaces and different integration mechanisms. Besides that, SEEs usually have particular manners to manage software processes when such functionality is present. In this context, we have also observed a lack of reference architectures of SEEs that encompass all software engineering activities that could be automated by SEEs. Moreover, there is a lack of pre-planned architectures that can influence the development and evolution of existing SEEs. Another subject closely related to this work is the use of AOP concepts at the architectural level. In particular, identifying the use of aspects during the early phases of the software life cycle – e.g., requirement specification and architecture design – has become a recurrent issue in the literature. In the last years, events such as the Aspect-Oriented Software Development (AOSD) Conference, the Early Aspects workshops series and the Workshop on Aspects in Architectural Description, have widely discussed the use of aspects in these early phases. Regarding the use of aspects in the architectural level, a diversity of recent works has mainly concentrated in two perspectives. The first comprises the identification of architectural aspects, i.e., identifying aspects when designing an

1 2 3

http://www.eclipse.org http://www.eclipse.org/ajdt/ http://maven.apache.org/eclipse-plugin.html

1672

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

architecture. For instance, coordination (a type of higher-order system interaction) (Cuesta et al., 2006) and security (Dai and Cooper, 2005) have been proposed as architectural aspects. Furthermore, we can find initiative that aims at establishing aspect-oriented software architectures (Navarro et al., 2007). The second perspective, on the other hand, focuses on modeling architectures that have aspects in their structure, extending, for instance, Architecture Description Language (ADL) (Lau et al., 2007; Pinto et al., 2007) and UML (Merson, 2005; Nakagawa and Maldonado, 2007; Rui et al., 2009). Despite all this available research, only few initiatives consider the use of aspects in reference architectures. In fact, a single proposition of a reference architecture for aspect-oriented middleware is available (Greenwood et al., 2008). In particular, the use of aspects in reference architectures of SEEs is still an open research area. 3. RefASSET: a reference architecture for SEEs RefASSET is an aspect-oriented reference architecture for SEEs. In order to establish this architecture, we have previously defined a set of main requirements considering the current status and limitations of SEEs (Nakagawa and Maldonado, 2008). In short, we stated that such reference architecture must support (i) the incremental development of interactive SEEs; (ii) the development of SEEs that automate different software processes; and (iii) the easy integration in SEEs, including the five types of integration initially established by Wasserman (1990): platform, presentation, data, control and process integration. Aiming at fulfilling such requirements, we defined RefASSET based on SoC, the ISO/IEC 12207 standard (Information Technology – Software Life Cycle Processes) (ISO, 1995), architectures of interactive systems and aspect-oriented concepts (Nakagawa, 2006). The principles of RefASSET are following described. 3.1. Principles of RefASSET The main principle of RefASSET is the SoC. SoC is the key principle in Software Engineering that promotes the clear identification of all elements that participate in a system, hiding complexity through abstraction and promoting modularity and reusability in software systems (Dijkstra, 1976). Concerns can range from highlevel notions like security and quality of service to low-level notions such as persistence, caching and buffering. They can be functional, like features or business rules, or non-functional, such as synchronization and transaction management. In our approach, we consider each software engineering activity as a concern. For instance, design, testing and configuration management are software engineering concerns. In order to identify all concerns in SEEs, we based ourselves on the international standard ISO/IEC 12207 that provides a comprehensive set of software life cycle processes, activities, and tasks for developing and maintaining software systems. This standard establishes and groups the activities (concerns) into three categories – primary, organizational, and supporting – depending on the role that the activity plays in the software development. Differently from previous work – such as the ECMA/NIST reference model and architectures of other tools and SEEs – RefASSET establishes a wide range of software engineering concerns that can be automated by SEEs. Thus, the primary concerns that are automated by SEEs resulting from RefASSET are requirement specification, analysis/design, coding, testing and maintenance. From an AOP/AOSD point of view, the primary activities can be seen as the core concerns implemented in a SEE. The organizational and supporting concerns, on the other hand, are spread across or tangled with other concerns (i.e., the core concerns), as illus-

trated in Fig. 1. For instance, documentation – a supporting concern – is performed from requirement specification to maintenance; furthermore, documentation is also performed in other software engineering activities. Concerns that present this characteristic are called crosscutting concerns by the AOSD community. Thus, we have adopted the term crosscutting concern to refer to the organizational and supporting concerns. We have also adopted the term architectural aspect as a unit that encapsulates a crosscutting concern at the architectural level. In other words, each architectural aspect encapsulates either an organizational or supporting concern. This has resulted in an aspect-oriented reference architecture, i.e., an architecture that contains architectural aspects embodied in its structure. This perspective suggests the building by developers of a unique tool for each architectural aspect; this tool must make available to users functionalities related to that architectural aspect. For example, considering again documentation, the idea is to design and implement a unique tool that makes available functionalities related to documentation management, such as creation, update, and storage of documents. Such tool can in turn be used in all other tools that automate primary concerns, differently from traditional tools that have their own modules to automate organizational and supporting concerns. RefASSET establishes seven tools that automate the software engineering supporting concerns: documentation, configuration management, quality assurance, verification, validation, joint review, and audit. Moreover, other four tools automating organizational concerns are established: management (e.g., project management, project planning, application of software metrics and estimates); infrastructure (e.g., infrastructure configuration, communication, distribution, and synchronization); improvement (e.g., collect of data on software processes, and effectiveness analysis); and training (e.g., help online, user manuals, and tutorials). In the context of the development of interactive systems, SoC facilitates not only the evolution of these systems but also the increase of the reuse of design and implementation. Indeed, the Model-View-Controller (MVC) architectural pattern and the threetier architecture (Eckerson, 1995) – presentation, application and persistence – have been consolidated as architectures that have provided a better SoC in interactive systems. Thus, RefASSET is based on the MVC and the three-tier architecture. 3.2. Architectural description of RefASSET The effective reuse of knowledge contained in reference architectures depends not only on raising the domain knowledge, but also on documenting and communicating efficiently this knowledge through an adequate architectural description. Therefore, in a previous work (Nakagawa and Maldonado, 2007), we have discussed and selected architectural views – module, runtime and deployment – and UML 2.0 to represent aspect-oriented reference architectures. Thus, we will use them to describe RefASSET. The module view shows the structure of the software in terms of code units. Packages and classes can be used to represent this view as well as containment, specialization/generalization, and dependency relationship. As illustrated in Fig. 2, RefASSET is composed by three tiers/layers. The Presentation layer refers to server side modules which are responsible for the user interface presented in client side. This layer is composed by (i) the Controller element, which processes events (typically user actions) and invokes the functionalities implemented by the Model element; and (ii) the View element, which contains the user interface. The Application layer contains the Model element, which aggregates the functionalities of software engineering tools, automating primary, organizational and supporting concerns. For instance, in testing tools, the Application layer includes functionalities related to test case management and execution, while modules related to the user interface (e.g.,

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

1673

Fig. 1. Relationship among primary, supporting and organizational concerns.

input forms for test cases) can be found at the Presentation layer. Furthermore, since SEEs usually manage and store amounts of data (or artifacts), such as diagrams, source code, and reports, the Persistence layer is the third one and corresponds to the set of data that is required to be stored by software engineering tools. A database (managed by a Database Management System (DBMS)) could be used, since it corresponds to a collection of data that is organized so that it can easily be accessed, managed, and updated. However, a repository (a central place in which an aggregation of data is kept and maintained in an organized way) or a file system (set of files and where they are placed logically for storage and retrieval) could be also adopted. In Section 3.3, we present more details about data integration using this set of data. Fig. 2 also presents four sets of tools, represented by the packages (i) primaryTools, which contains the core functionalities (i.e., the business logic) of tools that implement software engineering primary concerns; (ii) supportingTools, which aggregates tools that implement software engineering supporting concerns; (iii) organizationalTools, which contains tools that implement organizational concerns; and (iv) serviceTools, which is com-

posed by tools that automate services considered crosscutting concerns, such as persistence and access control. Notice that the serviceTools package is not directly related to software engineering knowledge, but considering the crosscutting nature of the services it provides, we inserted it into RefASSET aiming at improving the SoC. To avoid tangling in this view, we follow the same simple representation used in aspect-oriented modeling (Aldawud et al., 2003). Thus, there are dependency relationship among packages that contain tools which implement architectural aspects and other packages. Such dependencies are labeled with crosscuts in Fig. 2. For instance, documentationTool (within the supportingTools package) represents a tool that provides documentation for all other software engineering concerns. It crosscuts tools that implement primary and organizational concerns, such as testing and requirement management. The runtime view shows the structure of the system when it is executing by means of components, provided and required interfaces, packages, ports, and connectors. Interfaces of tools that encapsulate architectural aspects are obviously different from the

Fig. 2. Module view of RefASSET.

1674

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Fig. 3. Runtime view of RefASSET.

provided and required interfaces of modules composed only by objects.4 Thus, as illustrated in Fig. 3, we proposed a filled circle, labeled with the name of the interface, attached by a solid line to the tools that encapsulate architectural aspects in order to represent the interface of these tools. We named this type of interface as Interface Made by Aspects (IMA) (Nakagawa and Maldonado, 2007). We have also proposed a half-square,5 attached by a solid line to the

4 In UML 2.0, the interface realization dependency from a classifier (set of objects) to an interface is shown by representing the interface as a circle, labeled with the name of the interface, attached by a solid line to the classifier that realizes that interface. The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle attached to the classifier that requires such interface. 5 Filled circle and half-square are not elements of UML component diagram (version 2.x). We have inserted them in this diagram to represent components that encapsulate architectural aspects.

tool that is affected by tools that encapsulate architectural aspects. Differently from a provided interface, IMA represents a declaration of a set of coherent features and obligations, specifying a contract. In practice, it represents the characteristics that tools must present to use the tools that encapsulate architectural aspects. To make this view readable, only the connections between the documentation tool and other tools are presented in Fig. 3. The documentation tool has only IMAs and affects the behavior of other tools, thus providing them with functionalities related to documentation. The documentation tool itself is affected by the persistence tool (persistenceTool in Fig. 3), since documentation also requires data storage. The third view – the deployment view– describes the machines, software which is installed on that machines and network connections that are made available. Fig. 4 illustrates a deployment view of RefASSET that is generally similar to deployment view of tradi-

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

1675

Fig. 4. Deployment view of RefASSET.

tional web systems, if it is considered that the SEE will be available on web platform. RefASSET is therefore a reference architecture that organizes the structure of SEEs, presenting tools that compose these environments as well as relationship among them. In particular, RefASSET is composed by architectural aspects in order to encapsulate those software engineering activities considered crosscutting concerns. In this perspective, we also investigated and proposed mechanisms to implement these architectural aspects, which are presented in more details in Section 4.2.

3.3. Integration issues in RefASSET Tool integration is one of the hardest parts in building a SEE; thus, in RefASSET, we have also considered integration issues, in particular, the five types of integration proposed by Wasserman (1990). In order to conduct integration among tools, RefASSET has foresaw a tool, named managementTool (contained in Fig. 2), which supports the project management activity. This tool makes possible to support software processes and is responsible to define the workflow (sequence of connected steps/activities) in processes. Thus, according to a workflow, this tool coordinates the use of other tools, such as the requirement and programming tools. In this way, the process integration (one of the types of SEE integration that is concerned with the role of tools within a whole software process) is handled. Furthermore, the control integration (another type of SEE integration that is concerned with the interoperability of tools) is also considered in RefASSET. Considering that tools will be built or reorganized based on RefASSET, other two types of SEE integration – presentation integration and platform integration – may be achieved. Presentation integration is concerned with user interaction; RefASSET presents a layer (the presentation layer in Fig. 2) that encompasses only the elements related to the user interface (View and Control); thus, since this layer is independent from application layer and, therefore, it facilitates the development of an independent user interface, presentation integration among tools may be facilitated. Moreover, platform integration is concerned with common framework services used by tools. RefASSET is organized so that it promotes the development of software engineering tools available through web platform; thus, these tools use the web infrastructure, thereby promoting the platform integration. The last type of integration, the data integration, is concerned with the interchange of data between tools. In SEEs based on RefASSET, a database (or set of data that contains software artifacts) can be used as a common repository of data that tools would access to exchange data among them. However, in order to promote data integration, a common set of rules for encoding data or artifacts are so required. For this, in the implementation time, technologies, such as Document Type Definition (DTD) and XML Schema, could be adopted to establish these rules. Considering that RefASSET is a reference architecture and, therefore, it must not present

implementation technologies, RefASSET does not intend to establish these rules. Since tools (specially tools that support organizational and supporting software engineering activities) have crosscutting characteristic, we have also proposed the use of aspects (from AOP) as a data integration mechanism, as presented in more details in Section 4.2. Moreover, aspects contained in tools that support organizational and supporting software engineering activities affect other tools, promoting interoperability between them. Therefore, aspect should be further investigated as a mechanism that promotes also control integration. 4. Using RefASSET In order to enable the systematic development of tools and SEEs based on RefASSET, we defined a process named ProSA (Nakagawa, 2006). This process is not the main focus of this paper; however, for a better understanding of the work presented hereafter, it is briefly presented herein. ProSA is a reference architecture-centered development process split in two phases – ProSA-S and ProSAI – as illustrated in Fig. 5. ProSA-S (Architectural Specialization) comprises a set of steps to produce reference architectures specialized for a specific software engineering subdomain. For example, from RefASSET we can establish RefREQ, a reference architecture for requirement specification tools. Thus, knowledge contained in RefASSET (such as, the architectural pattern and style and relationship among tools) is inherited by RefREQ. Based on these specialized reference architectures, ProSA-I (Architectural Instantiation) defines steps for the establishment of architectural instances, from which we can develop the aimed tools. At the end, the idea is that each SEE could contain a tool dedicated to requirement engineering, as well as a testing tool, a configuration management tool and so on. Using ProSA, we intend to establish a family of reference architectures for the software engineering domain, as shown in Fig. 5. In this paper, we illustrate how ProSA was applied to obtain RefTEST (Reference Architecture for Software Testing Tools). We illustrate also how RefTEST was used as a basis to develop testing tools. Furthermore, we aim at showing how aspects inserted in RefASSET can facilitate the development of software engineering tools. Thus, in Section 4.2, we present the development of a tool to automate an architectural aspect of RefASSET: the software documentation. This can also show the possibility of developing a unique tool that aggregates functionalities that, in most situations, are scattered and tangled which other tools and that we have encompassed in RefASSET architectural aspects. 4.1. Using RefASSET in the software testing domain We have specialized RefASSET to the software testing domain, resulting in RefTEST, and have developed testing tools based on this architecture. For this, the following steps of ProSA-S and ProSA-I were applied:

1676

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Fig. 5. Outline structure of ProSA.

Step S-1: Domain investigation: This step refered to the investigation of the software testing knowledge in order to identify the core activities performed during the testing. Knowledge was elicited considering diverse sources (i) software testing processes (Sommerville, 2001; Vincenzi et al., 2005), from which the respective activities were investigated and identified as potential core activities; (ii) software architectures proposed in the testing literature (Eickelmann and Richardson, 1996), whose knowledge (structure, modules, and their relationships) were also considered; (iii) an ontology for software testing domain, called OntoTest (Barbosa et al., 2008), which served as a basis for identifying testing domain concepts and relationships; and (iv) characteristics and functionalities of well-known and widely used academic testing tools (e.g., MuJava (Ma et al., 2006) and Jazz (Misurda et al., 2005)) and commercial tools – the testing tools of Mercury Interactive Corporation6 and Rational.7 We have observed that the investigation of testing tools was the most important contribution for this step. Additionally, our experience in

6 These tools are now part of HP Software & Solutions (http://www.mercuryinteractive.com). 7 http://www-142.ibm.com/software/products/us/en/category/SW730

developing testing tools was also important (Maldonado et al., 2000). As a result, we identified 32 activities in software testing, presented in Table 1. The sources of information for each of them are also indicated in this table. For instance, the activity 20 (Generate test requirement) was identified through the investigation of software testing processes (P), testing tools (T) and testing ontology (O). It is noticed that these activities refer to the core activities of testing. Step S-2: Architectural analysis: Based on the identified activities, the core concepts of the testing domain were established. For this, each activity was related to a concept in the software testing domain. For instance, the activity 10 (Manually include test cases.) was related to the concept “Test Case”, the activity 20 (Generate test requirements.) was related to “Test Requirement”, and so on. The fourth column of Table 1 summarizes this analysis. We highlight that the four identified concepts are sufficient to represent the core elements of testing tools: Test Artifact, Test Case, Test Requirement, and Test Criterion. Fig. 6 presents the conceptual model for the core of testing tools. Complementing this model, definitions and related operations were established for each concept. Step S-3: Architectural design: Since RefTEST is a specialization of RefASSET, it inherits all RefASSET’s characteristics, such as

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

1677

Table 1 Activities in the testing conduction. #

Core activities

Source a

Related concept

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Load artifact to be tested Deal with artifact to be tested Execute artifact to be tested using test cases Report of execution of artifact to be tested View artifact to be tested Exclude artifact to be tested Include drivers and stubs View drivers and stubs Import test cases Manually include test cases Automatically include test cases Minimize test case set Able test case Disable test case Export test case Report of test case Exclude test case View test case Import test requirement Generate test requirements Select test requirements Set test requirement as non-executable Set test requirement as executable Execute test requirements using test cases Collect trace of execution of test requirements Report of test requirements View test requirements Exclude test requirements Establish testing adequate criterion Calculate test coverage Report of test summary Static analysis of the test execution

T A, P, T, O A, P, T P T T O O P, T P, T P, T T T T T T T T T P, T, O T P, T P, T P, T, O A P, T T T A, O A, P, T A, P A, T

Test Artifact Test Artifact Test Artifact Test Artifact Test Artifact Test Artifact Test Artifact Test Artifact Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Requirement Test Criterion Test Criterion Test Criterion Test Criterion

a

P = testing processes; A = architectures; T = testing tools; O = OntoTest.

the SoC and the architectures of interactive systems. In this step, an architectural description of RefTEST was built using architectural views. Fig. 7 presents the module view of RefTEST.8 It is observed that the general structure of RefTEST is similar to RefASSET; however, the testingToolCore package contains the core of testing tools, as identified through Steps S-1 and S-2 of ProSA. The other packages (supportingTools, organizationalTools and serviceTools) contain tools that implement architectural aspects, like in RefASSET. Thus, at the end of this step, reference architectures for specific software engineering subdomains are achieved. Steps I-1: Architectural instance establishment: This step consists in refining the reference architecture according to particularities of a testing tool that is intended to be developed. Such refinement yields an architectural instance which encompasses specificities of the testing tool. Therefore, the resulting architectural instance includes more details than its respective reference architecture. Using RefTEST, we have developed a tool that supports mutation testing of aspect-oriented Java programs (hereafter named Proteum/AJ (Ferrari et al., 2010)). In short, mutation testing is a fault-based testing criterion which relies on typical mistakes programmers make during the software development (DeMillo et al., 1978). It has been widely investigated and has been empirically shown to be one of the strongest testing criteria (Li et al., 2009). Fig. 8 shows the first refinement that was performed during this step. It consists of the one-to-one mapping between the core concepts of testing tools (Fig. 6) and the core concepts of the Proteum/AJ. Besides that, since RefTEST brings the knowledge about which operations must be available for each concept, the task of identifying operations is not necessary. Therefore, we can say

8

For the sake of space, we only present the module view herein.

Fig. 6. Core of testing tools.

that RefTEST reduces the task of requirement elicitation. However, efforts are necessary in order to identify how each testing tool will perform each operation. For instance, RefTEST defines that the module “Test Case” manages test cases (e.g., include, exclude and minimize test cases); however, the storage format of the test cases must be established, since this type of decision depends on the intended testing tool. Fig. 9 partially shows one of the refined models produced in this step. It includes details of how the Mutant concept supports one of the operations: the generation of mutants (or testing requirements9 ). The MutationEngine module includes the set of tasks required for generating mutants. It is responsible for invoking an external parser, receiving the parser output, activating the mutation operators and invoking the pretty-printer to build AspectJ code mutants. The MutantCompiler is responsible for managing

9 Testing requirement is a concept of the Software Testing domain and refers to an element that must be satisfied by the test being conducted.

1678

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Fig. 7. Module view of RefTEST.

Fig. 8. Mapping between the core concepts of RefTEST (left) and the AspectJ mutation tool (right).

and compiling the set of mutants created by the MutationEngine, using a JavaCompiler. Similar refinements were performed for other concepts and operations. As a result of this step, we obtained a set of models in UML representing the architectural instance of our tool, as well as detailed models of the concepts encompassed in this architecture. Step I-2: Tool development: Once the architectural instance is defined, the aimed tool can be implemented. We have implemented Proteum/AJ tool in Java language. The tool operations (e.g., mutant generation and test case execution) were available via scripts implemented within utility classes. Therefore, considering that RefTEST aims at realizing the MVC pattern, the implemented operations can be attached to different user interfaces (e.g., stand-alone and Web-based systems) requiring only minor customizations.

4.2. Automating architectural aspects Considering the relevance of software reuse in promoting significant improvements in the productivity and in the software quality, we have selected mechanisms that promote the reuse of tools and SEEs built according to RefASSET. We have used Aspect-Oriented Frameworks (AOF) that allow developers to reuse large structures in a particular domain and are specialized to specific applications, in the same perspective of Object-Oriented Frameworks (OOF) (Fayad and Johnson, 2000). We have used AOFs as a mechanism for developers build tools that make available for users function-

alities related to architectural aspects of the RefASSET. Thus, each architectural aspect can be implemented by an AOF that refers to a framework composed by classes and aspects which encapsulates only a single crosscutting concern and that must be coupled to a base code in order to work properly. A special characteristic of this type of framework is that the integration of this framework in other systems is made by aspects.

4.2.1. An aspect-oriented framework for software documentation To deal with software documentation as a crosscutting concern (i.e., an architectural aspect in RefASSET), we designed and implemented an AOF for documentation, named ADoc (Aspect-oriented tool for software Documentation). For this, three main steps were conducted (i) investigation of required documents; for instance, documentation standards and tools/modules for documentation, such as JavaDoc;10 (ii) establishment of requirements for the AOF, i.e., it was identified a set of common functionalities of documentation tools; and (iii) design of the AOF. An outline architecture of this AOF is presented in Fig. 10.11

10 http://www.oracle.com/technetwork/java/javase/documentation/ javadoc-137458.html 11 This framework is represented using UML-F (Fontoura et al., 2002), a UML profile to describe frameworks. We have also extended this profile in order to represent the aspects.

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Fig. 9. Part of refinement of the mutant concept.

Fig. 10. Outline architecture of ADoc.

1679

1680

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Fig. 11. Testing documentation tool.

ADoc is based on the three-tier architecture (presentation, application and persistence layers) aiming at contributing to the evolvability required in this framework. In short, the presentation layer implements the user interface that provides functionalities related to documentation to users. The application layer deals with the documents, generating and preparing them to be stored and presented to users. The persistence layer is responsible to store/retrieve the documents. Moreover, the integration layer was inserted in order to facilitate the integration of the AOF with other tools, as well as to encapsulate the integration mechanism in a separate layer. Thus, the AOF presents a 3 + 1-layer architecture: presentation, application, persistence and integration. In order to facilitate the comprehension of the AOF for documentation, we present the main concepts from AOSD herein. In short, a join point is a well-defined point in the execution of the program; pointcut is a means of referring to collections of join points; advice is method-like construction used to define additional behavior at join points; and aspect is a unit of modular crosscutting implementation composed of pointcuts, advices, and ordinary member declarations. Weaving refers to the coordination process that involves making that applicable advice run at the appropriate join points, i.e., it refers to combination of aspect and no-aspect codes. More detailed definitions of aspect, pointcut, join point, advice and weaving can be found elsewhere (Kiczales et al., 2001). It is worth to observe that since aspects have the ability to affect and crosscut a system, changing its behavior or obtaining data related to its execution, we have investigated the use of aspects as an integration/communication mechanism among software engineering tools. Thus, as shown in Fig. 10, integration layer is basically composed by (i) abstract aspect AbstractDocumentation, which declares the abstract pointcuts, implements the crosscutting behavior that captures data to compose the documentation, and; (ii) aspect ConcreteDocumentation, which extends AbstractDocumentation and for each abstract pointcut, the join points are established. In other words, the join points indicate the

points (inside of software engineering tools) that are affected by the AOF. As a result, ADoc intends to provide software documentation functionalities for different software engineering tools. In this paper, we illustrate the use of ADoc in the testing domain. Based on ADoc, we developed ATDoc (Aspect-oriented tool for Testing Documentation) that provides functionalities related to documentation to testing tools. 4.2.2. Using the AOF for software documentation in the testing domain ADoc was instantiated for the software testing domain, resulting in a tool – the ATDoc (presented in Fig. 11) – to document test suites. For this, we adopted the IEEE 829-1998 – Standard for Software Test Documentation (IEEE, 1998) that provides a complete set of documents for a test suite. Investigating the structure of these documents, we observed three sources of data for these documents (i) the testing tool itself (that implements the core functionalities of the testing tool); (ii) the testing planning/management tool; and (iii) the testers/documenters (who use the documentation tool to write down information about tests). In order to instantiate ADoc for the testing domain, two main tasks were conducted (i) concrete classes were created based on IEEE 829-1998 documents and as an extension of the class Document; and (ii) join points were established in the sources of data (testing tool and planning management tool); this is indicated with crosscuts stereotypes in Fig. 11. Thus, the aspects in the integration layer crosscut these sources, get data and provide these data to the application layer. In other words, the aspects are designed to get the “documentation objects”, i.e., the objects (instances of the types) that contain required data to the documentation. Thus, aspects intercept these objects and get them to ATDoc application layer. Application layer extracts then the required data from each object. Since XML (eXtensible Markup Language) aims at facilitating the sharing of data among different software systems as well as it has

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

1681

Fig. 12. User interface of ATDoc.

been widely used as a format for storing and processing documents, we adopted it to represent and store the testing documentation. For this, we defined a Document Type Definition (DTD), named Document Type Definition for Testing Documentation (DTDTD), for testing documentation based on the IEEE 829-1998 standard. DTDTD has 57 elements, one for each type of information that must be inserted in the documentation of a test suite. Based on this DTD, XML files store the testing documentation according to a common format. We highlight that a well-established and documented interface for ATDoc is essential in order to promote the reuse of this tool in other testing tools. Thus, we wrote down a document, named Document of Interface Description (DID), that establishes all types and data required in tools that intend to use ATDoc. For instance, DID establishes that a testing tool must have the type TestCase containing the attributes input and output. In other words, DID established which are the “documentation objects”. Regarding technologies to implement ATDoc, Java was used as the general-purpose language and AspectJ12 was used to implement aspects (i.e., the integration layer). Besides that, Struts,13 an open source framework for building Servlet/JSP-based web applications using the MVC pattern, was used in the presentation layer, together with HTML and Cascading Style Sheet (CSS). In order to automate the persistence layer, we used Document Object Mode (DOM) and XML. Fig. 12 presents screenshots of ATDoc. Fig. 12a shows the main window that presents the options to tester/documenter to access the tool (e.g., Produce documentation); window in Fig. 12b allows that testers/documenters choose the documents to be produced (e.g., Test Plan); and, window in Fig. 12c shows examples of information that testers can include in documentation (e.g., regarding Test Plan). While the AOF for software documentation was designed in order to be easily instantiated to any software engineering tool, ATDoc was built to provide documentation functionality to any

12 13

http://www.eclipse.org/aspectj/ http://struts.apache.org/

testing tool that complies with DID. Besides that, the insertion/removal of ATDoc in a testing tool does not alter the source code of this testing tool. 5. Benefits, learned lessons and limitations The establishment and use of RefASSET and RefTEST have provided us with feedback about how we can benefit from the domain knowledge and expertise that are embodied in reference architectures. In this section we discuss some issues related to it, which also includes lessons learned and limitations we have noticed. 5.1. Reusing knowledge Our experience has pointed out that the reuse of domain knowledge contained in reference architectures can increase the productivity in the development of new tools. For instance, we benefited from previous knowledge during the development of our AspectJ mutation tool. RefTEST provided us with guidance on how we could structure the tool. It also enabled us to define the set of modules, their operations and how the modules should work together (i.e., module interaction) in order to achieve the final, common objective. We believe that this level of reuse is expected in reference architectures. However, as stated before, instantiating RefTEST required some effort from the developers, since fine-grained details of the internal parts of each module must be made explicit. Furthermore, in order to adequately use RefTEST, knowledge of software testing, software architecture, UML and aspect-orientation are required. 5.2. Incremental development and reuse of modules Since RefASSET and RefTEST are based on aspects, they provide a better SoC, making possible the incremental development of software engineering tools. Specifically, each tool that supports organizational and supporting software engineering activity can be independently developed and integrated into a SEE afterwards. It is possible, since we have used aspects (from AOP) and DID that estab-

1682

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

lishes an interface between these tools and other tools. Besides that, each of these tools contains an integration layer composed by aspects, including an abstract aspect that is configured to integrate to other tools. More specifically, during the configuration, join points are established into abstract aspect and additional behavior are inserted by aspects into these other tools. In this way, we have explored aspects as integration mechanism, promoting integration among tools. Otherwise, integration among tools that support primary activities (requirement specification to maintenance) can also use aspects; however, it must be more investigated. As proposed, RefASSET makes possible to explore the of use different integration approaches; for instance, data integration using XML, control integration using message central server or even new technologies, such as aspect binding concept of the ObjectTeams/Java. Furthermore, each module of a tool can be independently developed and integrated into the tool. The SoC makes possible the reuse of design and source code of the tools developed based on RefASSET and RefTEST. For instance, the test case management module is usually required by any testing tool independently of the testing criterion implemented by this tool or the artifact under test. Thus, a test case management module was independently developed and can be reused in testing tools; however, pertinent adaptations because of different types of test cases (for instance, test case in text format or graphic format) should be taken into account. 5.3. Feasibility of AOFs When architectural aspects are considered in reference architectures of SEEs, they can yield better modularization of specific types of software engineering tools. For example, architectural aspects can encapsulate functionalities related to software documentation, configuration management, and project management, i.e., activities that have a crosscutting nature. Besides that, this makes possible to have a unique tool that encapsulates functionalities related to an architectural aspect. In the case presented in this paper, an AOF for documentation has been designed aiming at facilitating to make available documentation functionalities to other tools, such as coding, testing, and project management tools. In spite of the complexity of developing AOFs, designing and using an AOF have shown that (i) functionalities related to documentation are more easily integrated in software engineering tools, since code related to documentation is encapsulated into specific modules, i.e., code is not inserted directly into the software engineering tool’s code; and (ii) the maintenance of functionalities related to documentation is facilitated, again due to the enhanced modularization. It is worth highlighting that the aspects contained in AOFs seem to be a suitable mechanism to integrate a software engineering tool and a tool built from this AOF. These aspects are therefore responsible for connecting and making possible a synchronized operation of the involved tools. In the same direction of research that has shown advantages in the use of OOF, AOFs are evolvable by construction, allowing for software reuse. Thus, investigating and using AOFs seem to be adequate to support software engineering activities and relevant in the SEEs development.

ware engineering tools available in the web platform, specially to enable distributed access. We also believe that new technologies and concepts for the development of web systems (e.g., AJAX – Asynchronous Javascript And XML) can contribute to the development of tools, e.g., diagramming tools, which require more complex interaction than web forms as in traditional web systems. 5.5. Limitations There is a diversity of SEEs and tools available in varied platforms and architectures supporting different activities, processes, methods and techniques. We know that our approach does not cover all cases, but it is a direction in order to establish a reference architecture for software engineering domain. Furthermore, RefASSET and its specializations (e.g., RefTEST) are not tied to any implementation technology. In other words, even after the architecture instantiation, they are not intended to support automatic code generation, i.e., these architectures are artifacts in a higher level of abstraction. Regarding RefTEST, in spite of the achieved positive results, it must still be used in the development of diverse tools in order to reach a complete validation. Furthermore, through a qualitative evaluation of the tools developed from RefTEST, we believe that modules that compose these tools can easily be reused to build other tools. However, a quantitative study should be carried out. Also, through a qualitative evaluation of the AOFs that we have developed, we can point out that AOF is a suitable technology to implement architectural aspects. However, its implementation is not a trivial task. Besides that, the instantiation of an AOF for a specific tool requires some effort, mainly regarding internal configuration (e.g., implementation of new classes). In order to achieve an adequate and easier integration, the tools that intend to use these AOFs must conform to a specification; therefore, not every tool can use these frameworks. It is important to highlight that the perspective of aspects as an integration mechanism is new in SEE integration. Results of our experience have pointed out the viability of aspects. However, this is a research line that must be investigated regarding advantages and limitations of aspects if compared with other integration mechanisms proposed in the literature, such as those discussed in Wasserman (1990). At last, a complete validation of RefASSET is not presented herein, since it would require a significant effort to achieve a considerable set of software engineering tools composing an integrated SEE. Thus, for the present, we have developed some tools and frameworks for this SEE, aiming at preliminary validation of the idea proposed by RefASSET. 6. Conclusions The establishment of reference architectures can bring a significant contribution to areas in which software systems need to be designed and implemented. For the Software Engineering area, reference architectures are also currently a need. Regarding the goals presented in the introduction of this paper, following we show how we have achieved the four objectives:

5.4. Web-based development RefASSET and RefTEST also support the development of tools available in the web platform, following the trend of systems from several other domains. However, more research must be conducted in order to investigate the impact of adopting tool distribution issues. Furthermore, since a number of business reasons have caused software development to become increasingly distributed, resulting in a Globally Distributed Software Development (Ramasubbu and Balan, 2007), it is also relevant to make soft-

(i) to present a reference architecture for SEEs: we presented RefASSET, a reference architecture for SEEs that gathers knowledge of the software engineering domain and puts it together to ease the creation of tools and SEEs. Furthermore, RefASSET includes architectural aspects in its structure, representing modules that contain functionalities related to software engineering activities considered crosscutting concerns; (ii) to present a process to support the application of RefASSET: we presented ProSA, a reference architecture-centered devel-

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

opment process that systematizes the use of RefASSET, serving, therefore, as a guide to build software engineering tools; (iii) to present a specialization of RefASSET for the software testing domain: in order to illustrate the viability of RefASSET, we specialized this architecture for the software testing domain, using ProSA and resulting in RefTEST, a reference architecture for software testing tools. We have also been developing testing tools based on this architecture; and (iv) to present a mechanism to build tools that implement the aspects contained in the RefASSET: in order to show how the architectural aspects contained in RefASSET can be implemented by a tool, we presented an AOF for software documentation (i.e., an architectural aspect) and instantiated it to the testing domain. Similar development has been conducted in other two activities: configuration management and training/help. These experiences have motivated the use of AOFs as a mechanism to automate architectural aspects, aiming at contributing to reduce time, cost and efforts, as well as improving quality and productivity in tool development. Finally, regarding the hypothesis addressed in this paper, we have noted that aspects inserted in the RefASSET bring benefits. Aspects contribute to a better SoC, since they make possible to mainly modularize a set of functionalities that have crosscutting characteristic (i.e., software engineering activities that are crosscutting concerns and, therefore, encapsulated in architectural aspects). As a consequence, together with the use of AOFs, RefASSET can contribute to the development of reusable and evolvable tools and possibly a reusable and evolvable SEE. Motivated by the promising results of our approach, we intend to establish a set of reference architectures for the software engineering domain. This will aggregate domain knowledge into architectures, aiming at mainly reusing this knowledge to develop and restructure tools and SEEs. Besides that, consideration of other types of architecture, such as SOA (Service-Oriented Architecture), as basis of RefASSET shall also be investigated. Establishing strategies for integrating external tools in the environments developed based on RefASSET is another issue to be addressed. Acknowledgements This work is supported by the Brazilian funding agencies FAPESP, CNPq and CAPES, and by European Community (QualiPSo Research Project – Grant: IST-FP6-IP-034763). References Aldawud, O., Elrad, T., Bader, A., 2003. A UML profile for aspect oriented modeling. In: 3rd Int. Workshop on Aspect-oriented Modeling, Boston, USA, March 2003. Ambriola, V., Ciancarini, P., Montangero, C., 1990. Software process enactment in Oikos. SIGSOFT Software Engineering Notes 15 (6), 183–192. Andersen, E.P., Reenskaug, T., 1992. System design by composing structures of interacting objects. In: ECOOP’92. Springer-Verlag, Utrecht, The Netherlands, pp. 133–152. Bandinelli, S., Nitto, E.D., Fuggetta, A., 1996. Supporting cooperation in the SPADE-1 environment. IEEE Transactions on Software Engineering 22 (December (12)), 841–865. Baniassad, E., Clements, P.C., Araujo, J., Moreira, A., Rashid, A., Tekinerdogan, B., 2006. Discovering early aspects. IEEE Software 23 (1), 61–70. Barbosa, E.F., Nakagawa, E.Y., Maldonado, J.C., 2008. Ontology-based development of testing related tools. In: SEKE’08, San Francisco Bay, USA, July 2008, pp. 697–702. Bass, L., Clements, P., Kazman, R., 2003. Software Architecture in Practice. AddisonWesley. Boudier, G., Gallo, F., Minot, R., Thomas, I., 1989. An overview of PCTE and PCTE+. ACM SIGPLAN Notices 24 (February (2)), 248–257. Conradi, R., Osjord, E., Westby, P.H., Liu, C., 1991. Initial software process management in EPOS. Software Engineering Journal 6 (5), 275–285. Cuesta, C.E., Romayb, M.P., de la Fuente, P., Barrio-Solórzano, M., 2006. Coordination as an architectural aspect. Electronic Notes in Theoretical Computer Science 154 (May (1)), 25–41.

1683

Dai, L., Cooper, K., 2005. Modeling and analysis of non-functional requirements as aspects in a UML based architecture design. In: SNPD/SAWN‘05. IEEE Computer Society, Los Alamitos, CA, USA, pp. 178–183. DeMillo, R.A., Lipton, R.J., Sayward, F.G., 1978. Hints on test data selection: help for the practicing programmer. IEEE Computer 11 (4), 34–43. Dijkstra, E.W., 1976. A Discipline of Programming. Prentice Hall. Eckerson, W.W., 1995. Three tier client/server architecture: achieving scalability, performance, and efficiency in client server applications. Open Information Systems Journal 10 (January (1)). ECMA and NIST, 1993. Reference model for frameworks of software engineering environments, August 1993. Technical Report ECMA TR/55, 3rd ed., August 1993, NIST Special Publication 500-211. Eickelmann, N.S., Richardson, D.J., 1996. An evaluation of software test environment architectures. In: ICSE’96. IEEE Computer Society, Berlin, Germany, pp. 353–364. Eklund, U., Askerdal, Ö., Granholm, J., Alminger, A., Axelsson, J., 2005. Experience of introducing reference architectures in the development of automotive electronic systems. SIGSOFT Software Engineering Notes 30 (4), 1–6. Fayad, M.E., Johnson, R.E., 2000. Domain-Specific Application Frameworks: Frameworks Experience by Industry. John Wiley & Sons. Ferrari, F.C., Nakagawa, E.Y., Rashid, A., Maldonado, J.C., 2010. Automating the mutation testing of aspect-oriented Java programs. In: AST’2010 at ICSE’2010. ACM, Cape Town, South Africa, pp. 51–58. Fontoura, M., Pree, W., Rumpe, B., 2002. The UML profile for framework architecture. Object Technology Series. Addison-Wesley. Garlan, D., 1987. Views for tools in integrated environments, May 1987. PhD thesis, Carnegie Mellon University, Pittsburgh, PA, USA. Garlan, D., 2000. Software architecture: a roadmap. In: Conf. on The Future of Software Engineering at ICSE’00. ACM Press, Limerick, Ireland, pp. 91–101. Greenwood, P., Surajbali, B., Coulson, G., Rashid, A., Lagaisse, B., Truyen, E., Sanen, F., Joosen, W., 2003. Reference architecture for aspect-oriented middleware. Technical report, AOSD-Europe, February 2008. Deliverable D103. Grosskurth, A., Godfrey, M.W., 2005. A reference architecture for web browsers. In: ICSM’05. IEEE Computer Society, Budapest, Hungary, pp. 661–664. Grundy, J., Welland, R., Stoeckle, H., 2004. Report of the workshop on directions in software engineering environments (WoDiSEE). In: ICSE’04. IEEE Computer Society, Washington, DC, USA, pp. 768–769. Harrison, W., Ossher, H., Tarr, P., 2000. Software engineering tools and environments: a roadmap. In: ICSE’00. ACM Press, Limerick, Ireland, pp. 261–277. Herrmann, S., 2002. Object Teams: improving modularity for crosscutting collaborations. In: Int. Conf. NetObjectDays (NODe’2002), Erfurt, Germany, October, 2002, pp. 248–264, LNCS N. 2591. Herrmann, S., 2002. Views and concerns and interrelationships – lessons learned from developing the multi-view software engineering environment PIROL, September 2002. PhD thesis, Technical University Berlin, Berlin, Germany. Herrmann, S., Hundt, C., Mosconi, M., 2007. Object Teams/Java language definition – version 1.0. Technical Report 03, Technical University Berlin, Berlin, Germany. Herrmann, S., Mezini, M., 2000. PIROL: a case study for multidimensional separation of concerns in software engineering environments. In: OOPSLA’00. ACM Press, Minneapolis, MN, USA, pp. 188–207. IEEE 829-1998. IEEE standard for software test documentation, May 1998. ISO, 1995. ISO/IEC 12207. Information technology: software life-cycle processes. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G., 2001. An overview of AspectJ. In: ECOOP’01. Springer-Verlag, Budapest, Hungary, pp. 327–353. Kiczales, G., Irwin, J., Lamping, J., Loingtier, J., Lopes, C., Maeda, C., Menhdhekar, A., 1997. Aspect-oriented programming. In: ECOOP’97. Springer-Verlag, Jyväskylä, Finland, pp. 220–242. Laddad, R., 2003. Aspect-oriented programming will improve quality. IEEE Software 20 (November–December (6)), 90–91. Lau, Y., Zhao, W., Peng, X., Chen, Y., Jiang, Z., 2007. A unified formal model for supporting aspect-oriented dynamic software architecture. In: ICCIT’2007. IEEE Computer Society, Hydai Hotel Gyeongui, Korea, pp. 450–455. Li, N., Praphamontripong, U., Offutt, A.J., 2009. An experimental comparison of four unit test criteria: mutation, edge-pair, all-uses and prime path coverage. In: Mutation’2009 at ICST’2009. IEEE Computer Society, Denver, USA, pp. 220–229. Ma, Y.-S., Offutt, J., Kwon, Y.-R., 2006. MuJava: a mutation system for Java. In: ICSE’06. ACM Press, Shanghai, China, pp. 827–830. Maldonado, J.C., Delamaro, M.E., Fabbri, S.C.P.F., Simão, A.S., Sugeta, T., Vincenzi, A.M.R., Masiero, P.C., 2000. Proteum: a family of tools to support specification and program testing based on mutation. In: Mutation 2000 Symposium – Tool Session. Kluwer Academic Publishers, San Jose, CA, USA, October 2000, pp. 113–116. Merson, P., 2005. Representing aspects in the software architecture – practical considerations. In: Early Aspects Workshop, OOPSLA’05, San Diego, CA, USA, October 2005. Misurda, J., Clause, J., Reed, J.L., Childers, B.R., Soffa, M.L., 2005. Demand-driven structural testing with dynamic instrumentation. In: ICSE’05. ACM Sigsoft, St. Louis, MN, USA. Nakagawa, E.Y., 2006. A contribution to the architectural design of software engineering environments. PhD thesis, University of São Paulo, Sao Carlos, SP, Brazil, August 2006 (in Portuguese). Nakagawa, E.Y., Maldonado, J.C., 2007. Representing aspect-based architecture of software engineering environments. In: AArch’07 at AOSD’07, Vancouver, Canada, pp. 1–4.

1684

E.Y. Nakagawa et al. / The Journal of Systems and Software 84 (2011) 1670–1684

Nakagawa, E.Y., Maldonado, J.C., 2008. Architectural requirements as basis to quality of software engineering environments. IEEE Latin America Transactions 6 (July (3)), 260–266. Navarro, E., Letelier, P., Ramos, I., 2007. Requirements and scenarios: running aspectoriented software architectures. In: WICSA’07, January 2007. IEEE Computer Society, Mumbai, India, p. 23. OSGi Alliance, 2011. Osgi alliance specifications (On-line), World Wide Web. Available from: http://www.osgi.org/Specifications/ (accessed 19.04.2011). Ossher, H., Tarr, P., 2000a. Hyper/J: multi-dimensional separation of concerns for Java. In: ICSE’00. ACM Press, Limerick, Ireland, pp. 734–737. Ossher, H., Tarr, P., 2000b. Multi-dimensional separation of concerns and the Hyperspace approach. In: SACT’00. Kluwer, Enschede, The Netherlands, pp. 1–30. Pinto, M., Gamez, N., Fuentes, L., 2007. Towards the architectural definition of the health watcher system with AO-ADL. In: Early Aspects at ICSE’07. IEEE Computer Society, Washington, DC, USA, p. 5. Ramasubbu, N., Balan, R.K., 2007. Globally distributed software development project performance: an empirical analysis. In: ESEC-FSE’07. ACM, Dubrovnik, Croatia, pp. 125–134. Rui, W., Xiao-Guang, M., Zi-Ying, D., Yan-Ni, W., 2009. Extending UML for aspectoriented architecture modeling. In: WCSE’09. IEEE Computer Society, Qingdao, China, pp. 362–366. Shaw, M., Clements, P., 2006. The golden age of software architecture. IEEE Software 23 (March–April (2)), 31–39. Engineering Institute, 2011. Community software archiSoftware tecture definitions (On-line), World Wide Web. Available from: http://www.sei.cmu.edu/architecture/start/community.cfm (accessed 18.04.2011). Sommerville, I., 2001. Software engineering., 6th ed. Addison-Wesley. Taylor, R.N., Belz, F.C., Clarke, L.A., Osterweil, L., Selby, R.W., Wileden, J.C., Wolf, A.L., Young, M., 1988. Foundations for the Arcadia environment architecture. In: ACM SIGSOFT/SIGPLAN SDE’88. ACM Press, Boston, MA, USA, pp. 1–13. Turner, C.R., Wolf, A.L., Fuggetta, A., Lavazza, L., 1998. Feature engineering. In: IWSSD’98. IEEE Computer Society, Washington, DC, USA, p. p. 162. Vincenzi, A.M.R., Delamaro, M.E., Simão, A.S., Maldonado, J.C., 2005. Muta-pro: Towards the definition of a mutation testing process. In: LATW’05, March 2005, Salvador, Brazil. Wasserman, A.I., 1990. Tool integration in software engineering environments. In: Int. Workshop on Soft. Engineering Environments. Springer-Verlag, Chinon, France, pp. 137–149. Wasserman, A.I., 2004. The rise of open source development tools. In: WoDiSEE’04 at ICSE’04. ACM, Edinburgh, Scotland, UK, pp. 65–69.

Elisa Y. Nakagawa is a Professor Doctor in the Department of Computer Systems at University of São Paulo (USP), Brazil. Currently, she is conducting her Post-Doctoral in the Fraunhofer Institute for Experimental Software Engineering, Germany. She received her BS degree in Computer Science in 1995 from the University of São Paulo, her MS degree in 1998 and her PhD degree in 2006 in Computer Science and Computational Mathematics from the University of São Paulo. Her main research interests include software architecture, reference architecture, software engineering environment, software product line, and open source. A list of her main publications can be found on Lattes Platform (http://lattes.cnpq.br/ 7494142007764616). Mariela M.F. Sasaki is a software engineer in the Centre for Research and Development in Telecommunications Foundation (CPqD), in Brazil. Her main research interest is software testing. She received in 2009 her BS degree in Computer Engineering from the University of São Paulo (USP), Brazil. She is currently conducting her MS in the University of São Paulo. Main publications can be found on Lattes Platform (http://lattes.cnpq.br/6889951739468023). Fabiano Ferrari is an Assistant Professor in the Computing Department at Federal University of São Carlos (UFSCar), in Brazil. In 2005, he received a BS degree in Informatics from the University of São Paulo (USP), in Brazil. In 2010, he received a PhD degree in Computer Science and Computational Mathematics also from the University of São Paulo. His research interests include software testing, software metrics, object-oriented programming, aspect-oriented programming, software product lines and experimental software engineering. His main publications can be found on Lattes Platform (http://lattes.cnpq.br/ 3154345471250570). José Carlos Maldonado received his BS in Electrical Engineering/Electronics in 1978 from the University of São Paulo (USP), in Brazil, his MS in Telecommunications/Digital Systems in 1983 from the National Space Research Institute (INPE), in Brazil, his DS degree in Electrical Engineering/Automation and Control in 1991 from the University of Campinas (UNICAMP), Brazil, and his Post-Doctoral at Purdue University, in the USA, in 1995–1996. He worked at INPE from 1979 up to 1985 as a researcher. In 1985 he joined the University of São Paulo where he is currently Full Professor and Director. He is also the President of the Brazilian Computer Society (2007–2011). His main research interests are related to software engineering, software testing and validation, experimental software engineering, software quality, software engineering education and training, web systems, and reactive and embedded systems. A list of his main publications can be found on Lattes Platform (http://lattes.cnpq.br/8807333466702951).