XML files for easier customization. With this common J2EE configuration, the client needs an. Internet browser, and the server needs to run an. Application ...
USING AND SPECIALIZING JAFAR, A PATTERN-BASED J2EE FRAMEWORK: AN AUCTION CASE STUDY Nicolas Guelfi, Benoît Ries Luxembourg University of Applied Sciences Software Engineering Competence Center 6, Rue Coudenhove-Kalergi L-1359 Luxembourg-Kirchberg, Luxembourg
ABSTRACT1 Sun’s J2EE environment is becoming one of the major technologies for the development of web applications. The reuse of stable and integrated components is a wellknown means to achieve an effective development. Frameworks have this objective but few frameworks are available for the J2EE platform, and moreover, they are rarely integrated in a global methodological approach supported by a tool. Furthermore, the available literature mainly provides a general conceptual presentation of frameworks. The objectives of this paper is to present, from a pragmatic perspective, the use of the J2EE framework called JAFAR devoted to the development of web applications. As JAFAR has been developed from a software engineering point of view, we also show how its use can be supported by CASE tools that support design modeling and allows pattern-based development. For this purpose we used the Rational XDE environment.
KEY WORDS Software Architecture, Software Development, J2EE, Design Pattern, Object-Oriented Frameworks, CASE tool.
1. INTRODUCTION JAFAR is a framework implemented for a specific product line. The term framework can be defined in many ways, and we use the following one: “a reusable, semicomplete infrastructure that can be specialized to produce custom applications. Frameworks are designed to be reusable and specialized in the context of a product line.” [1] JAFAR was implemented in the context of the FIDJI project [2], which aims at defining a methodology for the development of reliable Java based distributed applications. The FIDJI project has selected a targeted product line: web-based e-commerce applications. A way 1
This work is supported by the Luxembourg Ministry of Higher Education and Research under the Title I project n°MEN/IST/01/001.
of enhancing the reliability of an application is to reuse some robust components. Thus, FIDJI has proposed to provide a development methodology that promotes the integration of components and frameworks. JAFAR first implementation focuses on web-based applications and uses some aspects of the Java 2 Enterprise Edition [3] Platform: the Enterprise Java Beans, Servlets, and Java Server Pages. The JAFAR framework is supported by a CASE tool, which is Rational XDE [4]. It has been used to create the UML models of the framework and for its implementation. The framework relies on Rational XDE’s pattern engine to define transformation mechanisms, and wizards that assist the user of the framework in building his application. The framework could be used with a different CASE tool that would support the creation of models, the transformation mechanisms (pattern engine), and the creation/use of wizards. This paper presents the process of developing an application with the JAFAR framework from the project creation to its deployment. It will present what JAFAR consists of and how to apply its components through a concrete example: the PearlCircle Online Auction (PCOA) case study. PCOA was provided by the Rational Architecture & Framework group [5] and is the first experimentation of JAFAR. There is a growing interest in J2EE Frameworks in the industry and products like Kona [6] and rM Framework [7] start to be released; but there are only a few results provided by the academic world. In Section 2, we recall the notions of architectural framework, product line, and the main features of an architectural framework for a web application. We discuss about the objectives and the development of the JAFAR framework in the Section 3. In Section 4, we present an overview of the process of using and specializing the JAFAR framework. Finally Section 5 shows the process more thoroughly, following the Pearl Circle Online Auction case study.
2. ARCHITECTURAL FRAMEWORK FOR J2EE APPLICATIONS As already presented in the introduction a classical framework is a reusable infrastructure that can be specialized to produce custom applications. We focus on architectural frameworks because they emphasize the resulting application architecture. In our opinion, an architectural framework is composed of implementation code, transformation mechanisms and documentation including the explanation of the use and the specialization of the framework. There are many advantages in implementing an application with an architectural framework. It is used to provide a basic structure for the development of an application. The framework has an existing structure that the architect can reuse, and the framework guides the developer to create the application by specializing the framework. An architectural framework is often limited to one product line, and though shall not be adapted to domains that fundamentally differ to the one it has been built for. Modular services can be added in case of product line modifications. “A product line is a group of products sharing a common, managed set of features that satisfy the specific needs of a selected market.” [8]. We chose to study the web application product line. The applications of this product line have many recurrent services, for instance the management of user accounts. A framework can then provide a common basic structure for web applications. The structure of a web-based application is constrained by some technological choices. Let us restrict them to Java technologies as we essentially focus our study on J2EE. The layered structure promoted by J2EE is made of a presentation layer and a business layer. J2EE provides Java Server Pages and Servlets for the presentation layer and Enterprise Java Beans for the business layer. We consider that a workflow layer should be part of the structure of a J2EE application. This layer takes care of the requests coming from the presentation layer and dispatches them to the business layer. Its purpose is to centralize the use-case control logic on a distinct layer. To implement the workflow layer, standard technologies can be used like simple Java Classes optionally coupled with XML files for easier customization. With this common J2EE configuration, the client needs an Internet browser, and the server needs to run an Application Server (Web container, EJB container)
account. All these different features can be grouped in user management common services. Another concept is the item, lots of web sites especially the e-business web sites deal with items (books, cds…). There are some features that are usually associated with items; there is the possibility to browse the available items, in some cases to buy the item, and some other cases to add new items. Web sites also provide functionalities involving the sending of emails to the users (weekly newsletter, account creation confirmation…). The main service offered by an architectural framework for web applications can be the user management (authentication, restricted access to specific services). Its architecture should be composed of recurrent architectural fragments of web applications that are the navigation through web pages and the dispatching to the appropriate code logic, the storage of the user data to a persistent media, and batch processing at regular intervals. These are the features on which the JAFAR Architectural framework focuses for its first version and which are presented in the following.
3. THE JAFAR FRAMEWORK JAFAR stands for J2EE Architectural Framework. It offers the features of a web application framework as described in Section 2. It manages users (creation /modification of a user account), the dispatching of the requests from the web clients to the business logic, and the storage of information to the database with the help of EJB entity beans.
3.1 FRAMEWORK SERVICES The JAFAR Framework provides: - Software components that can be used to build a web application. Some of these components form a complete architecture into which the framework user only has to plug his own modules while others simply offer useful services that simplify the implementation of a web application. - Transformations, defined using Rational XDE’s pattern engine, which create software components based on their specification in a design model. - Wizards, defined using Rational XDE’s pattern engine, which simplify various tasks for the framework user by generating some of the model elements and implementation components. - Four documents covering the framework. Software Components
Web applications offer many kinds of services depending on their target domain (business, portals…). Despite the diversity of web applications domains, we can still extract some recurrent services. The concept of user is important. Features associated to users are among others: the possibility to access specific services only if the user is authenticated, the creation, and the modification of a user
The JAFAR framework offers a presentation tier architecture in which the framework user can plug his web pages and the control logic that they require. It is based on Sun’s Service to Worker pattern [9]. For each use case the framework user provides a dispatcher that
implements the use case’s workflow and a number of JSP pages that take care of the presentation.
implementation of a dispatcher based on information provided by the user.
The web pages are included in a template that is defined in the framework. This template includes a header with a menu that the application user can use to access the application’s functionality. This mechanism is based on Sun’s Composite View pattern [9].
Documents The framework comes with four documents: - Using and Specializing a Pattern Based J2EE Framework: The PCOA case study [10]. Explains how the framework should be used to build an application by studying a concrete case study. - User Guide of a Pattern Based J2EE Framework [11]. Presents the main components of the framework and explains how they should be used to build an application. - Detailed Design of a Pattern Based J2EE Framework [12]. Presents the main components of the framework and their interrelationships to developers who want to modify the framework to adapt it to their needs. - Meta Development with Rational XDE using its extensibility mechanism [13]. Presents the JAFAR framework’s use of XDE’s meta-development features to developers who want to use them to modify the framework.
The JAFAR framework provides a form validation mechanism. Forms that are submitted to the application are validated by verifying whether their fields match given patterns. A configuration file provides the information about the forms that is necessary for the validation. The framework takes care of the user management. It allows application users that connect to the web site to create a new account; it handles the user login/logout, and allows the application users to manage their account information. When a user creates a new account, the account must be activated before he can sign in with it. To activate his account, the user has to enter a secret number that is sent to him via e-mail. This ensures that the users provide valid e-mail addresses. The framework provides a number of utility services that simplify the implementation of some common tasks. The framework offers a messaging service that offers a simple way of sending e-mails to the application’s users. Finally, it provides a batch job service that allows the framework user to specify tasks that will be executed asynchronously. The batch job service supports three types of scheduling: immediate, deferred, and periodic execution. Pattern-Based Transformations The framework provides transformation mechanisms that create implementation components based on their specification in a design model. These transformation mechanisms have been defined using Rational XDE’s pattern engine. The framework provides two such transformation mechanisms: one that creates a session bean based on a component interface specification and one that creates an entity bean based on an entity class. In both cases additional classes are generated to implement common J2EE design patterns [9]. For the session beans the framework generates a business delegate and a service locator class. For the entity beans the framework generates an implementation of the Value Object pattern. Wizards The framework provides wizards that guide the user in his work. Some of these wizards create a basic structure consisting of empty diagrams and packages that help the framework user getting started with new aspects of the application. There is one wizard that creates a partial
3.2 INPUTS AND TOOLS The JAFAR framework is based on Rational’s PearlCircle Online Auction framework. PCOA is a reference application Rational has developed to illustrate how Rational tools can be used when building an application. When Rational developed this application they separated the generic, reusable parts from the application itself. The generic parts are inside the framework over which the PearlCircle Online Auction is built on. We have extracted the framework from the PCOA application and based the development of JAFAR on it. The JAFAR framework implements many of Sun’s J2EE patterns that are discussed in [9]. The JAFAR framework’s presentation tier architecture is based on the Service to Worker pattern. Its form validation mechanism is based on the Validating Filter pattern. Additionally, when using the framework to build an application, the framework provides tools that generate implementation components that implement different J2EE patterns. Entity beans created with the framework use the Value Object pattern to provide access to their data and the session beans created by the framework implement the Service Locator and the Business Delegate patterns. Rational XDE’s pattern mechanism is used by the framework to assist the user in some of the tasks related to building his application. The framework uses the pattern mechanism to define transformations that create implementation components from their specification in a design model. Additionally, the framework uses the pattern mechanism to provide wizards that create empty models and packages when the user starts working on a new business package or a new use case.
THE
more details about the design of the JAFAR framework look in [12].
The JAFAR Framework is used in two different ways. Some parts are ready to use without any modification, and can be called in the new application; some other parts have to be specialized (i.e. instantiated). It’s also known as the Hollywood principle: Don’t call us. We’ll call you.
The implementation of an application with the framework is done by using and specializing the framework. The JAFAR Framework has been implemented using the design and development tool: Rational XDE [4]. The specific functionalities that we took advantage in this tool are the following: 1. Modeling: The UML models of the framework for all its development phases. At least we recommend the models promoted by the 4+1 view model of architecture [15]. 2. Pattern engine: The application of a pattern based transformation through the use of an easy-to-use wizard. 3. Round Trip Engineering (RTE): The synchronization of the design and the implementation of the application inside the same tool.
4. USING AND SPECIALIZING JAFAR FRAMEWORK
Using the framework is the process of calling classes that are already fully implemented in the framework. Before using some of these classes, some configuration needs to be done. The configuration is set with the help of XML files that contain all the information associated with the application using the framework. Specializing the framework is the process of extending classes that are present in the framework. This process of framework specialization is also called framework instantiation [14]. These framework classes have a default behavior and some methods must be overridden to fit the needs of the application. Some parts of the process of specializing are guided with pattern-based transformations. These transformations can be created with Rational XDE’s pattern mechanism. Their objective is to create a basic implementation that is specific to the application. The developers will then complete the basic implementation created.
The process that can be used to develop the PCOA application on the JAFAR Framework is composed of five steps: project creation, design application elements, applying pattern based transformations, application implementation, application deployment. This process is given in a chronological order and is detailed below.
5.1 PROJECT CREATION
5. VALIDATION OF THE JAFAR FRAMEWORK THROUGH AN AUCTION CASE STUDY
The first step of the process is to create a new project as well as six models inspired by the 4+1 view approach. For three of them, wizards of the JAFAR Framework are used to create their basic structure.
The auction case study chosen for this article is the PCOA web application. PCOA is a web application. The main service it offers to its members is the handling of auctions. For instance, the members can add their items to the system. PCOA also offers the possibility to browse the existing items of the other members and to bid on any item whose the auction period is not finished yet.
A project following the 4+1 view of architecture in the Rational XDE tool is composed of six models: the UseCase Model [16], the User Experience Model [17], the Design Model, the Implementation Model (Java + Web) and the Deployment Model [16]. The process of specializing the framework, as used with the PCOA case study, only uses three models: the design model, the java implementation model and the web implementation model.
Final Application PCOA Application
Auction Management Service
JAFAR Framework Framework Core User Management Service
Request Validator
…
Email Sender
…
Fig 5.1 Final Application Structure
In this section we will present how we can develop the PCOA web application as an auction management service that uses the JAFAR Framework. Thus as shown in Figure 5.1 the final application will be composed of the auction management service plus the different services provided by the framework. Note that the framework services are not exhaustive in the following schema. For
The design model is “an object model describing the realization of use cases; serves as an abstraction of the implementation model and its source code. A design model contains architecture definitions and the design details of the architecture. Class declarations are filled out with methods and attributes.” [18] “The implementation model is the collection of implementation files, organized in implementation subsystems and implementation directories that are required to implement the running system. These include both operational files, such as executables, and files from which these operational files are derived, such as source code files, and visual models.” [16]
To create a new project with the corresponding models, the JAFAR framework provides: six model templates, and three wizards. First, the model templates are used to create the models before using the wizards. Second, the wizards are used to create a basic package structure in the models. This structure is required to apply the patternbased transformations, available in the framework and that are used in the third step, section 5.3. The general process of creating a project is: create an empty java project in XDE, add the six models to the project, use the three wizards, set up the project properties. The configuration of the project is important to start the implementation. The project must know that it uses the JAFAR Framework project, in order to reference and use the framework libraries in its code. Thus, for the PCOA project we used the three templates: Design Model, Java Implementation Model and Web Implementation Mode, to create the three corresponding models in XDE. Then we applied the wizard for the Design Model, with as an input the name auction. Finally, we created a package called auction in both Java and Web Implementation Model.
5.2 DESIGN ELEMENTS The second step concerns the design model. In this model, two design elements are important for our process: the key abstractions and the components interfaces. These two elements will then be taken as input for the patterns of the step 3. A key abstraction is an element part of the application domain, in other words a business object. To create a key abstraction and use it in the project: first, make a list of all the entities that the system will handle; then, specify the entities in the project; and finally, apply the code transformations (see next section). PCOA deals with auctions and its key abstractions are: Auction, Bid, Auctioned Item, Category, and Pending Payment. An UML Class with stereotype represents a key abstraction in the design model. This class is only composed of attributes, which represent the attributes of the entity. For example, the Category entity has three string attributes: uid, name and description. The key abstractions are used during the implementation to build an EJB Entity Bean. An enterprise component is a component that groups a set of services dealing with the same key abstractions (e.g. Auction Manager). To create the specification of an enterprise component and use it in the project: first, make a list of all the business methods that the system will need; then, create the enterprise component and specify
its interface in the project; and finally, apply the code transformations to the interface. In the Auction application, an enterprise component handling the auction is required: AuctionManager. In the design model, the AuctionManager is represented as a UML Subsystem with an stereotype. In this subsystem, an UML Interface represents the interface of the enterprise component. Among other methods, the interface of the AuctionManager enterprise component has the methods: SearchOpenAuctions, getHighestBid. The interface is used during the implementation to build an EJB Session Bean.
5.3 APPLYING PATTERN TRANSFORMATIONS
BASED
The objective of the third step is to apply pattern-based transformations in order to take information from the design model to create implementation fragments. Rational XDE uses wizards to apply these transformations. A pattern-based transformation is a design to code transformation with the resulting code structure involving design patterns. In this paper, a pattern-based transformation will often be referred to as a pattern. The objective of applying these patterns is to take information from the design model to create a quasicomplete implementation in the implementation model. At this step the implementation is operational and could be used as a prototype of the application. The patterns available in the JAFAR framework need to be applied to a specific package structure. This structure is built during the project creation. The JAFAR framework provides three patterns: Entity Bean, Session Bean, and Dispatcher. The JAFAR Framework offers a pattern that gets the key abstraction specified in the Design Model and creates an EJB Entity Bean following the attributes of the key abstraction. The transformation creates with the entity bean, the corresponding Object Value [9] class that contains all the attributes of the bean. It offers a pattern that gets the enterprise component interface specified in the Design Model and creates an EJB Session Bean following the methods of the interface of the enterprise component. The transformation creates with the session bean, the corresponding Locator and Delegate [9] classes.
public class CreateAuctionDispatcher extends DefaultDispatcher { private static String sCreatePage =
"/WEB-INF/myproject/auction/CreateAuction_Create.jsp";
private static String sCongratulationPage =
"/WEB-INF/myproject/auction/CreateAuction_Congratulation.jsp";
private static String sCreateTitle =
"Create";
private static String sCongratulationTitle = "Congratulation"; public boolean handle(javax.servlet.http.HttpServletRequest httpRequest,javax.servlet.http.HttpServletResponse httpResponse) throws DispatcherException { try { RequestDispatcher rd = null; if (super.handle(httpRequest, httpResponse)) { String stateId = (String) httpRequest.getAttribute("StateId"); if (stateId == null || stateId.equals("")) { // this is the default state or the first state
Code created by the pattern based transformation
rd = processCreate(httpRequest, httpResponse); } else if (stateId.equals("Create")) { rd = processCreate(httpRequest, httpResponse); } else if (stateId.equals("Congratulation")) {
Implemented by the developer
rd = processCongratulation(httpRequest, httpResponse); } } if (rd != null) { rd.forward(httpRequest, httpResponse); } } catch (Exception e) { e.printStackTrace(); throw new DispatcherException(e.toString()); } return true; } protected RequestDispatcher processCreate(javax.servlet.http.HttpServletRequest httpRequest, javax.servlet.http.HttpServletResponse httpResponse) { javax.servlet.RequestDispatcher rd = null; rd = configureTemplate(httpRequest, sCreateTitle, sCreatePage); return rd; } protected RequestDispatcher processCongratulation(javax.servlet.http.HttpServletRequest httpRequest, javax.servlet.http.HttpServletResponse httpResponse) { javax.servlet.RequestDispatcher rd = null; AuctionItemValues aiv = new AuctionItemValues(); aiv.name = (String) httpRequest.getAttribute("AuctionName"); aiv.price = (String) httpRequest.getAttribute("Price");
try { AuctionManagerDelegate amd = new AuctionManagerDelegate(); amd.createAuction(aiv); } catch (DelegateException e) { e.printStackTrace(); } rd = configureTemplate(httpRequest, sCongratulationTitle, sCongratulationPage); return rd; }
Fig 5.2: The Create Auction Dispatcher
A Dispatcher is part of the Sun J2EE Pattern called Service to Worker. It is responsible for view management and navigation, managing the next view to present to the user. The Sun J2EE Pattern has been customized for the JAFAR framework context. There is one dispatcher for each use-case of the application.
that XDE deployed in the specific deployment tool of the application server. See the JAFAR Framework User’s Guide [11], which contains a detailed explanation of the deployment process.
In the context of the PCOA case study, all the different pattern-based transformations have been used. The sample implementation of the Figure 5.2 is the result of the Dispatcher transformation.
At the end of this process, a new application has been implemented. This application is in two elements, the first one is the unchanged code of the JAFAR Framework and the second one is the specialization of the JAFAR Framework to the requirements of the Pearl Circle Online Auction.
The Dispatcher transformation was applied with the following inputs: 1. the name of the use-case handled that is CreateAuction 2. the two states of the use-case Create Auction that are the display of the form to enter the auction information and the confirmation of the creation, respectively called Create and Congratulations.
5.4 APPLICATION IMPLEMENTATION The transformation patterns create a basic implementation of the application specific code. The next step is to complete the code fragments provided by the pattern. We differentiate two parts in the implementation: 1. The code created by the pattern engine, which includes customized code templates, method signatures and attributes. This customization is realized with the input classes from the Design Model for the Entity Bean and the Session Bean transformations and with inputs entered by the user for the Dispatcher transformation. 2. The code that the developer has to complete. Let us take for example the Dispatcher transformation in the context of the PCOA case study, see Figure 5.2. The code that the developer completes consists in: the location of the JSP pages and their titles, the default state of the dispatcher, and the code logic to retrieve data from the business layer through the Delegate classes.
5.5 APPLICATION DEPLOYMENT Last step is to deploy the new application. When the implementation is finished, the application has to be deployed. The final application is composed of the JAFAR Framework and the PCOA, thus the framework has to be deployed together with the application. When modeling his application in XDE the developer can provide deployment information associated with the application's EJBs. XDE uses this information to create deployment descriptors for the targeted application server and completes the missing information if necessary with default values. This allows XDE to be used to deploy applications. The last step is to customize the application
5.6 RESULTING APPLICATION
In case of an addition of an auction service to the product line, PCOA could be moved to the framework. PCOA would then extend the range of basic services that JAFAR provides.
6. CONCLUSION In this paper we have presented the use of the first version of our J2EE framework (JAFAR) for web application development. We have also shown how its use can be supported by CASE tools that support design modeling and allows pattern-based development. The JAFAR framework has been developed entirely using the Rational XDE environment and this CASE tool must be used to develop JAFAR based applications. Concerning the design of JAFAR [12], the next step for the framework evolution is the addition of a service managing e-business specific features like, among others, transactions management. Concerning the development methodology, complementary work for JAFAR is currently available in order to integrate it in a complete and rigorous approach to architecture engineering [19]. It will replace the 4+1 approach used in this paper.
7. ACKNOWLEDGEMENT We would like to thank Wojtek Kozaczynski and Jim Thario who gave us a lot of inputs on all the subjects covered by this paper. We also would like to thank the FIDJI team members who were of great help for this work.
REFERENCES [1] G. Butler, Object Oriented Frameworks, 15th European Conference on Object-Oriented Programming, Budapest, Hungary, 2001 [2] N. Guelfi, D. Hammouche, P. Sterges, and O. Biberstein, Activities Report, Applied Computer Science Department technical report n° TR-DIA-02-01,
Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2001 [3] B. Shannon, Java 2 Platform Enterprise Edition Specification Version 1.3, Sun Microsystems, http://java.sun.com/j2ee/download.html, 2001 [4] Rational Software Corporation, Rational XDE product, http://www.rational.com/products/xde, 2002. [5] W. Kozaczynski, PearlCircle Online Auction Reference Application Software Architecture Document v0.3, http://www.jroundup.com/pearlcircle, 2002 [6] Applied Knowledge Incorporated, Kona, http://www.aki.com/kona, 2002 [7] realMethods Incorporated, rM Framework, http://www.realmethods.com, 2002 [8], P. Clements and L. Northrop, Software Product Lines: Practices and Patterns (Reading, MA: AddisonWesley Pub Co, 2001). [9] D. Alur, J. Crupi, and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies (Upper Saddle River, NJ: Prentice Hall PTR, 2001). [10] B. Ries and P. Sterges, Using and Specializing a Pattern Based J2EE Framework: The PCOA case study, Applied Computer Science Department technical report n° TR-DIA-02-03, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [11] P. Sterges and B. Ries, User Guide of a Pattern Based J2EE Framework, Applied Computer Science Department technical report n° TR-DIA-02-02, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [12] B. Ries and P. Sterges, Detailed Design of a Pattern Based J2EE Framework, Applied Computer Science Department technical report n° TR-DIA-02-04, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [13] B. Ries, Meta Development with Rational XDE using its extensibility mechanism, Applied Computer Science Department technical report n° TR-DIA-02-05, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [14] J. Van Gurp and J. Bosch, Design, implementation and evolution of object oriented frameworks: concepts and guidelines, Software: Practice and Experience, 31(3), 2001, 277-300. [15] P. Kruchten, Architectural Blueprints - The "4+1" View Model of Software Architecture, IEEE Software, 12(6), 1995, 42-50. [16] Rational Software Corporation, RUP Java Developers' Process Configuration, 2002. [17] J. Nielsen, R. Molich, C. Snyder, and S. Farrell, ECommerce User Experience (Fremont, CA: Nielsen Norman Group, 2001). [18] Rational Software Corporation, Rational XDE [4] Glossary, 2002. [19] G. Perrouin and N. Guelfi, Rigourous Engineering of Software Architectures: Integrating ADLs, UML and Development Methodologies, Applied Computer Science Department technical report n° TR-DIA-02-08,
Luxembourg University of Applied Luxembourg-Kirchberg, Luxembourg, 2002.
Sciences,
