the development of applications that reuse those components. In the first stage, the domain .... engineer separate the client applications from the business rules, and from the .... adapters, basically, encapsulate the API needed to remote access.
Distributed Component-Based Software Development Strategy Integrated by MVCase Tool Eduardo S. Almeida1, Calebe de P. Bianchini, Antonio F. Prado, Luis C. Trevelin Computing Departament – Federal University of São Carlos Rod. Washington Luiz, km 235 – São Carlos/SP - Brasil P.O box 676 – Zip.Code 13565-905 Phone/Fax: + 55-16-260-8232
{ealmeida, calebe, prado, trevelin}@dc.ufscar.br ABSTRACT This paper presents a Strategy that integrates different technologies to supports Distributed Component-Based Software Development. The involved technologies are: the Catalysis method, the CORBA pattern to support components distributeds distribute the components, frameworks of components and a CASE tool. The strategy drives the software engineer in two stages: in the development of problem domain components, and in the development of applications that reuse those components. In the first stage, the domain components are developed in four steps: Define Problem, Specify Components, Project Components and Implement Components. Catalysis is used as a Component-Based Development (CBD) method to define, specify and design the distributed components, through CORBA architecture. Frameworks of components are developed to accomplish the communication between applications, guide the distribution of the developed problem domain components and facilitate the database access. In the second stage, applications can be developed reusing the components built in the first stage, via three steps: Specify Application, Project Application and Implement Application. A CASE tool is the main mechanism to apply this strategy, supporting the code generation of developed components and the application that reuse them. An distributed objects environment is proposed for accomplishing the results of this strategy. A case study is presented to show the application of these technologies integrated by the proposed strategy.
Categories and Subject Descriptors D.3.3 [Programming Languages]: Language Constructs and Features – abstract data types, polymorphism, control structures.
General Terms Design, Standardization, Languages.
Keywords Distributed CBD, Components, Catalysis, CORBA, Frameworks, Patterns and the MVCase Tool.
1. INTRODUCTION In the software development, the reuse is characterized by the uses of software products, in a different situation for which these products were built [11]. The CBD cares about the creation of components that can be reused in other applications. As a solution for this problem, researches [1, 2, 3, 4, 7, 11, 21] show, as a fundamental step, the systematization of the process of analysis and creation of components to a certain application domain. In order to make the reuse effective, it must be considered in all phases of the software development process. Therefore, the Component-Based Development must offer methods, techniques and tools that support from the components identification and specification, in a problem domain level, to their project and implementation in an executable language. Besides, the CBD must use interrelations among components already existent, which have been previously tested, aiming to reduce the complexity and the software development costs [21]. In spite of the recent and constants researches in the CBD area, there is still lack of methods, techniques and tools that effectively support as much the development as the components reuse in certain applications domain. Although different technologies exists to supports the CBD, many difficulties are faced when trying to integrate those technologies to cover al the CBD process, from the constructions of the components to its utilization in the applications. If considering the distributed components, as they happen in the Internet, with client-server platform, the problem becomes bigger. Different methods, techniques and tools have been proposed to support the CBD, standing out the CASE tools [10], [12], [19]. However, mainly of these methods, techniques and tools support partially the CBD, mostly in the case of distributed applications. Motivated by these ideas, this paper presents an integration of different technologies to support the Distributed ComponentBased Development (DCBD), through a strategy that, divided in two stages: Develop Components of a application domain and Develop Applications that reuse the components of that domain.
1
This work is supported by Fundação de Amparo à Pesquisa do Estado da Bahia (Fapesb).
This paper is organized as follow: section 2 presents the main technologies integrated to the DCBD; section 3 describes the Strategy that integrates the technologies to support the DCBD, followed by a study case showing its uses; section 4 discuss relation aspects to the strategy tests; finally, section 5 shows some conclusions of this research.
2. TECHNOLOGIES TO THE DCBD After the study of different technologies available in the literature [7, 11, 18, 21], it was decided to use Catalysis [8, 11] as the method component development; CORBA [5, 9, 17] as the pattern to distribute and adapt components; frameworks [13] to facilitate both the communication with the applications as the distribution of the components, and the uses of databases. These technologies were integrated by a strategy, which guides the software engineer in all process development software. To automate the development tasks, the MVCase tool [1, 2] is used in which the components constructions and reuses are based.
2.1 Catalysis Method Catalysis [8, 11] method are divided in three levels: Problem Domain Definition, where it is put emphasis in the problem understanding, specifying “what” the system must do to solve the problem; Components Specification, where the system behavior is described in a non ambiguous way; and the Components Inner Project, where it is defined “how” the specified requirements will be implemented. Catalysis is based on the principles of abstraction, precision and “plug-in” components. The abstraction principle guides the developer in search of essential aspects of the system, sparing details that are not relevant for the context of the system. The precision principle has as objective to detect errors and inconsistency in modeling. The “plug-in” components principle supports components reuse to construct other systems. The integration of Catalysis in the first stage of the proposed strategy was done through its correspondence the definitions of steps to the components development, in to each of those levels, as Table 1 shows.
Table 1. Catalysis versus First stage of DCBD Strategy. Catalysis Method Problem Domain Definition Components Specification Components Inner Project
First Stage of DCBD Strategy Define Problem Specify Components Project Components Implement Components
2.2 Common Object Request Broker Architecture (CORBA) In the CBD it is necessary establish a formal relation among the components and the application that uses them, through welldefined interfaces. In DCBD, distribution and recall management is a crucial aspect the must be considered. To meet to these requirements, the distributed CBD strategy is based on the CORBA [5, 9, 17] architecture, which is a pattern established by Object Management Group (OMG) to support distributed objects. CORBA presents well-defined interfaces and independent of
applications, through the Interface Definition Language (IDL) [5, 9, 17], that fits perfectly in the CBD context. Other aspects that motivated the use of CORBA were: the programming language independence, due to the possibility of mapping from IDL to several languages; the portability among computational environments; the possibility of object adaptation and services of Safety, Nomination and Notification, offered by the specification.
2.3 Frameworks To construct software components safer, more reliable, easier to maintain and use, the CBD can use frameworks techniques based on Patterns [13]. Framework is a set of related classes that make reuse of a project for specific software classes [13]. The pattern use in complex software systems allows that previously tested solutions be reused, making system more comprehensible, flexible, easy to develop and maintain. The objective of the use of software patterns is the spread of the software developing solutions already existent. The use of patterns in the frameworks construction, aims to turn them still more flexible, and, mainly, facilitate the components reuse in the application development. Thus, to decrease the time and reduce the components development costs of a Problem Domain, frameworks of basic components in the areas of communication (Communication) and distribution (Broker) [6, 13] of components and database access (Persistence) [13, 23] were developed. Through the reuses of these frameworks components, it has a safer guide to accomplish the communication with the applications, distribute the components of a problem domain and integrate them to the database systems.
2.4 MVCase Tool CASE tools have been used, with success, in the project or reproject of systems to be reconstructed. Among various CASE tools, stands out MVCase2 [1, 2], which supports system specification using UML techniques [15] and has been extended to implements this DCBD strategy discussed here. MVCase can generate code from the system specifications. Other MVCase resource is the possibility to build software components, based on the Enterprise Java Beans (EJB) [14] technology. The way this strategy leeds with the distribution and reuse of components is to manage the components deployment in a set of repositories. MVCase implements a three-tier architecture to construct and place the components. The three tiers allow that the software engineer separate the client applications from the business rules, and from the database storing services or another way of storing. The components of these tiers can be distributed in different platforms, supporting client-server applications, which can be executed by the Internet. The same way to Java/EJB, the proposed DCBD strategy uses the MVCase to build and reuse the components of a domain problem, according to CORBA pattern. Thus, the components of a domain are specified with IDL interfaces, and reuses components of the 2
MVCase tool is a project under development at DC/UFSCar by a research Software Engineering group support by CNPq/SPBrazil.
basic frameworks available in the MVCase. Once specified, it can generate code of those components, in an object-oriented language, as Java [10], making it available in a component repository, to future reuses.
3. DISTRIBUTED COMPONENT-BASED SOFTWARE DEVELOPMENT STRATEGY Integration the Catalysis CBD method, the CORBA architecture to specification and component distribution, and the frameworks of components, into the MVCase tool, defined a strategy that supports the Distributed Component-Based Software Development. The strategy was divided in two stages, as shown in Figure 1, using SADT [20] notation. In the first stage, the strategy starts from the requirements of a Problem Domain and produces the implemented components, in an component-oriented language. Once implemented, these components are stored into a repository. In the next stage, using a Trading [16] mechanism offered by MVCase, the software engineer consults the available components of a problem domain in the repository. After identified the necessary components, the applications that reuses them are developed. As shown in Figure 1, the main mechanisms of the strategy are: the MVCase tool and the software engineer. The strategy is guided by frameworks Broker, Communication and Persistence; by the Catalysis method; by CORBA architecture; and by component repository.
Figure 2 – Distributed Components Development Steps. The detailed presentation of each step of the stage Develop Distributed Components is presented next. To make easier the understanding of inputs, outputs and controls of each step, the Service Order Problem Domain of an electronic equipment repair garage is used. The Service Order (SO) domain applications are divided in three big modules: the first one, Customers, is responsible for registering and notifying customers of a certain service order; the second one, Employees, is responsible for registering employees and controlling service order tasks; the third one, Reports, is responsible for emitting reports, related to accomplished and pending tasks consultation, to the manager, service orders of a certain customer, and of employees responsible for each task.
3.1.1 Define Problem
Figure 1 – DCBD Strategy. A detailed presentation of each strategy stage is presented next.
3.1 Develop Distributed Components In this stage, the components of a problem domain are built, in four steps: Define Problem, Specify Components, Project Components and Implement Components, according to Figure 2. The first three steps correspond to the three stages of Catalysis, as shown in the right part of Figure 2. In the last step, the physical implementation of the components is done. The main execution mechanisms of this stage are the MVCase and the software engineer, and the controls are the Catalysis method, the frameworks Broker, Communication and Persistence, the CORBA pattern and the Java language.
In the first step, is put emphasis in the problem understanding, specifying “what” the components must do to solve the problem. Initially, the requirements of the domain are identified, using techniques as storyboards or mind-maps [18], aiming to represent the different situations and domain problem sceneries. Next, the identified requirements are specified in Collaboration Models [15], representing the action collections and the participant objects. Finally, the collaboration models are refined in Use Cases Model [15]. The Figure 3 summarizes the first step, where a mind-map, defined in the Service Order domain requirements identification, is specified in a Collaboration Models, and, later, refined and partitioned in a Use Cases Model, aiming to reduce the complexity and improve the problem domain understanding.
Figure 5 – Second Step: Specify Components. Figure 3 - First Step: Define Problem.
3.1.2 Specify Components This step supports the second level of Catalysis, where the system external behavior is described in a no ambiguous way. In the CASE tool, the software engineer refines the previous steps specifications, aiming to obtain the components specifications. This step begins with the refining of the models problem domain. The Model of Types is specified, according Figure 4, showing attributes and object type operations, without worrying about implementation. Still in this step, the data dictionary can be used to specify each found type, and the Object Constraint Language (OCL) [11] to detail the objects behavior, with no ambiguity.
In resume, the activities from this step, accomplished by the software engineer, in the MVCase tool, include the specifications of: a) Model of Types; b) Model Framework; c) Framework Application, based on the Model Framework; and d) Interactions Models, represented by sequence diagrams, based on Use Cases Model. These models are used in the next step, to obtain the components inner project.
3.1.3 Project Components In this step, the software engineer does the components inner project, according to the third level of Catalysis. Now, the implementation details become important, standing out: safety, persistence, distributed architecture and the implementation language.
Figure 4 – Model of Types from Specify Components step. According to Figure 5, the Model of Types is organized in the Model Framework [11], with their attributs and relationships. The framework is reused throuth the Framework Application [11], representing the dependances of the frameworks types, with the extended types in the application. The Use Cases Models, from last step, are refined to Interaction Models represented by sequence diagrams [15] to detail the utility scenaries of components in different applications of the problem domain.
As a fist step, the Model of Types are refined to Classes Models of components [15], where the classes are modeled with their relationships, taking in consideration the components definitions and their interfaces. Figure 6 shows portion of the Classes Model of SO domain and the IDL specifications interface. The Interactions Models, represented by sequence diagrams techniques are refined to show design details of method behavior in each class.
[6], co-located with the TargetAdapter. Figure 8 [2] shows this interaction.
Figure 8 – DAP Interaction Model.
Figure 6 – Class Model obtained from Model of Types. Starting from Classes Model, the Components Model may be design [15], where the organizations and dependencies between components are showed. The Components Model may reuse components from other existents frameworks. Figure 7 shows the Components Model obtained from Classes Model on Figure 6, reusing the components of frameworks Broker, Communication and Persistence, organized in the packages Broker, Communication and Persistence respectively.
Figure 9 shows the framework Broker structure. The components Source and Target abstract the business rules of the problem domain. The TargetInterface interface abstracts the Target component behavior in distributed scenery. As this interface, the components, Source and Target do not have communication code either. These three elements compose a distributed independent layer. The main components of framework Broker are SourceAdapter and TargetAdapter. They are connected to a specific API of distribution and encapsulate the communication details. SourceAdapter is an adapter that isolates the Source component from distributed code. It is located in the same machine that Source and works as a proxy to TargetAdapter. TargetAdapter is located in other machine, isolating the Target component from distributed code. SourceAdapter and TargetAdapter, usually, are located in different machine, and do not directly interact. TargetAdapter implements RemoteInterface used to connect with SourceAdapter. The Initializer component is located in the same computer as Target and TargetAdapter components, and it is responsible for the creation of Target and TargetAdapter components [6] as can be seen in the Figure 9.
Figure 7 – Components Model. The components on the framework Broker use the Distributed Adapters Pattern (DAP) [6] to implements remote communication between two components. The technique adopted by DAP to offer this functionality is to insert a pair of adapter components, seeking a better component unjoining in a distributed architecture. The adapters, basically, encapsulate the API needed to remote access Target components. This way, Sources components of an application in relation to the distributed aspects, and any change on this aspects does not cause impact on it autonomous. In the pattern, there are two types of adapters: SourceAdapter and TargetAdapter. On a typical interaction, a component that implements the user interface in a machine requests SourceAdapter services located in the same machine. The SourceAdapter, then, requests the services of its corresponding TargetAdapter, located in a remote machine. Finally, the TargetAdapter requests the services from the component Facade
Figure 9 – Framework Broker structure. The components of framework Communication are a set of Servlets [14] responsible to receive requests from clients, accomplish the communication with the applications and return those requests. The uses of Design Patterns from Gamma Catalog [9], Facade and Singleton among other, the Persistent Object and ObjectPool [13, 23], on components constructions, may increase their reusability. Figure 10 shows components of framework Persistence. The ConnectionPool component, through its IConnectionPool interface, does the management and connection with the database used in the application. The DriversUtil component, based on
eXtensible Markup Language (XML) [22], has information from supported database drivers, available through its interface IDriversUtil. The TableManager component manages the mapping of an object into database tables, making their methods available by the ITableManager interface. The persistent component of the FacadePersistent structure, through its IPersistentObject interface, makes the values which must be added to the database available, passing parameters to the TableManager component.
Figure 12 – Fourth step: Implement Components.
Once constructed the components of the problem domain, the software engineer goes to second stage on DCBD strategy, where applications that reuses those components may be developed.
3.2 Develop Distributed Applications Figure 10 – Framework Persistence. Figure 11 summarizes the main artifacts and the sequence of the Project Components activities, which include: a)
Refining Model of Types into Classes Models;
b)
Refining the Interactions Models; and
c)
Creating the Components Models reusing existents components.
Figure 13 shows the steps for application development. It starts with the application requirements and proceeds with the normal life cycle development, which includes: Specify Application, Project Application and Implement Application. According to Figure 13, the constructed components of the domain problem are available to reuse in the component repository. The same way in components development, the CORBA pattern guides the distribution of the applications objects. In the case, Java is used as target implementation language. MVCase is the main mechanism to aims the software engineer during the development.
Figure 11 – Third step: Project Components.
3.1.4 Implement Components In this step, the software engineer uses a code generator, from MVCase to implements the designed components. For the components being distributed, the code is generated using CORBA pattern. For each component, it has the stubs and skeletons and its interfaces that makes its services available. Next, those components are stored in a component repository to be used on applications development in the future. Figure 12 shows, in the left, the process of code generation of design component, and, at the right, the IDL and Java codes generated by MVCase.
Figure 13 - Development of Distributed Applications. For a better comprehension of these DCBD stages, it is developed application that registers, via web, an service order, from the Service Order (SO) domain, which components were built in the previous stage.
3.2.1 Specify Application This step starts with the problem understanding, identifying the application requirements. Before starts the requirements specification, at MVCase, the software engineer using its Trading mechanism imports the components of the related domain problem, in this case SO, that are available in the repository, that will be used in the application. Next, the requirements are
specified in Use Cases and Sequence Diagrams. Figure 14 shows the Use Case AddServiceOrder and its Sequence Diagram.
Figure 16 – Project of the Distributed Application. Figure 14 – Use Case and Sequence Diagram. Continuing the modeling, the software engineer specifies the application classes model. In this case, the class AddServiceOrder was built in away that reuses services from the SO domain components. Figure 15 shows the four components (hachured), reused in the Add Service Order application.
Figure 17 shows how the distributed application is structured, through Object Web [14] extension model, using CORBA. In the first layer, it has the client, which executes the application. Through the HyperText Transfer Protocol (HTTP) communication, the requests are sent and received from Servlets that belong to framework Communication, available in the Web Server. In the second layer, the web server communicates to the Application Server, which makes available the domain problem applications. This communication is done via Object Request Broker (ORB) [5, 9]. The Application Server, via ORB, communicates to the Component Server requesting the components referring to the problem domain that are stored in the repository. In the third layer the database and its server are located. Communication between the Component Server and the Database Server, via JDBC (Java Database Connectivity) allows the access to the database services
Figure 15. Reused components in the Add Service Order application.
3.2.2 Project Application The specifications from last step are refined by the software engineer to get the application project. In this step, it is specified the non-functional requirements, related with: application security, distributed architecture, implementation language, and others. Figure 16 shows the components diagram of the application project, where the components DriversUtil, ConnectionPool, FacadePersistent and TableManager were added to deal with the database access, the components ServiceOrderSourceAdapter, ServiceOrderTarget, Initializer and ServiceOrderTargetAdapter to deal with the object distribution and the component ServletAddServiceOrder to deal clients requests and to send and receive, respectively, the parameters and informations the component AddServiceOrder.
Figure 17 – Extended Distributed Model Object Web.
3.2.3 Implement Application At last, based on the application project, the software engineer uses the MVCase code generator to do its implementation. Figure 18 shows part of the generated code to Add Service Order application.
5. CONCLUSION This paper presented a Strategy of Distributed Component-Based Software Development (DCBD), that integrate current technologies to support as much the development as the reuse of components of a problem domain. The integration of technologies like Catalysis, CORBA, and Java in MVCase tool, makes possible the development of components and applications in a distributed platform. Although these technologies exist in the market, the software industry still is devoid of methods and tools that integrate them and assist the software engineer in the distributed component-based software development, automatizing part of its tasks. Figure 18 – Implementation of the Add Service Order Service application.
4. TESTS WITH DCBD The strategy of the DCBD, integrating the presented technologies, was tested in the construction of the components and applications of the domain the SO. Even though informal, the tests had helped to correct imperfections in the different phases of the development processes, being improved each step of the strategy and refining the integrated technologies. When using the DCBD strategy the software engineer will be able to still detect imperfections in the modeling process, that is being refined and improved with the practical the development in other problem domain. In the domain and applications development, errors may occurs as in the components as in the applications that reuse them. Errors of the application are treated returning to the steps of the development of the application. Errors of reused components are corrected returning to the development steps of the components of the problem domain. Figure 19 shows the environment of execution of the application, that register an service order, being executed in a distributed architecture.
The developed components can be distributed and be reused, reducing the code redundancies and facilitating the application development. The maintenance of the applications will be easier and reliable, a time that the reused components previously had been tested. Besides, the components also offer more safety, because they are accessed by its interfaces, making available only what is concerned to the applications. Another contribution of this work is in the extension of the model of distribution Object Web, approaching the use of the components server with its repositories, allowing a bigger reuse for the applications, not treated in the original model. Other advantages offered for the strategy come from the use of frameworks, patterns and of the MVCase tool acting as element integrator, assisting in the modeling and implementation of the components and the applications of the problem domain.
6. ACKNOWLEDGMENTS This work is supported by Fundação de Amparo a Pesquisa do Estado da Bahia (Fapesb).
7. REFERENCES [1] Almeida, E., S., Bianchini, C., P., Prado, A., F., Trevelin, L., C., 2002. MVCase: An Integrating Technologies Tool for Distributed Component-Based Software Development. In APNOMS’2002, The Asia-Pacific Network Operations and Management Symposium,Poster Session. Proceedings of IEEE.
[2] Almeida, E., S., Lucrédio, D., Bianchini, C., P., Prado, A., F., Trevelin, L., C., 2002. MVCase Tool: An Integrating Technologies Tool for Distributed Component Development (in portuguese). In SBES’2002, 16th Brazilian Symposium on Software Engineering, Tools Session.
[3] Almeida, E., S., Bianchini, C., P., Prado, A., F., Trevelin, L., C., 2002. DDCP: A Develop Distributed Component Pattern. In SugarLoafPlop’2002, The Second Latin American Conference on Pattern Languages of Programming.
[4] Almeida, E., S., Bianchini, C., P., Prado, A., F., Trevelin, L.,
Figure 19 – Test Service Order Application.
C., 2002. Distributed Component-Based Software Development Strategy. In PhDOOS’2002, The 12th Workshop for PhD Students on Object-Oriented Systems, in Conjuction with 16th European Conference on ObjectOriented Programming (ECOOP).
[5] Ben-Natan, R. CORBA A Guide to the Common Object Request Broker Architecture. Mc-Graw-Hill, 1995.
[6] Borba., P., and Alves, V. Distributed Adapters Pattern: A Design Pattern for Object-Oriented Distributed Applications, The First Latin American Conference on Pattern Languages of Programming. Rio de Janeiro. Brazil 2001.
[7] Heineman, G., T., Councill, W., T., 2001. Component-Based Software Engineering, Putting the Pieces Together, AddisonWesley. USA.
[8] Catalysis. Catalysis Enterprise Components with UML. Avaliable: site Catalysis Enterprise Components with UML. URL: http://www.catalysis.org. Consulted in 10/08/2001.
[9] Corba. The Common Object Request Broker: Architecture and Specification. Avaliable: site OMG (1996). URL: http://www.omg.org. Consulted in 10/04/2001.
[10] Cool:Gen. Cool:Gen Tool. Avaliable: site Computer Associates. URL: http://cai.com/acq/sterling. Consulted in 10/07/2001.
[11] D’Souza., D., and Wills, A. Objects, Components and Frameworks with UML – The Catalysis Approach. USA:Addison Wesley, 1998.
[12] Erwin. Erwin Tool. Avaliable: site Computer Associates. URL: http://www.cai.com. Consulted in 10/07/2001.
[13] Gamma., E., and et al. Design Patterns. Elements of Reusable Object-Oriented Software. Ed. Addison-Wesley. USA.1995.
[14] Horstmann., S., C. Core Java2 Volume2-Advanced Features. Sun Microsystems Hal 1999.
[15] Rumbaugh, J., et al., 1998. The Unified Modeling Language Reference Manual, Addison-Wesley. USA.
[16] Omg. Trading object services specification. Technical Report, Object Management Group. Avaliable: site OMG. URL: http://www.omg.org, May 2000.
[17] Orfali., R., and Harkey, D. Client/Server Programming with Java and CORBA. John Wiley & Sons, Second Edition, 1998.
[18] Pressman., R., S. Software Engineering: A Practitioner's Approach. 5th Edition 2001.
[19] Rose. Rational Rose Tool. Avaliable: site Rational the software development company. URL: http://www.rational.com. Consulted in 10/07/2001.
[20] Ross., D., T. Structured Analysis (SA): A language for communicating Ideas, IEEE Transaction on Software Engineering, January 1977.
[21] Szyperski, C., 1998. Component Software: Beyond ObjectOriented Programming, Addison-Wesley. USA.
[22] Xml. Extensible Markup Language (XML) 1.0 Second Edition. Avaliable: site W3C - World Wide Web Consortium. URL: http://www.w3.org/TR/2000/REC-xml2000-10-06. Consulted in 10/07/2001.
[23] Yoder., J., W., and Johnson., R., E., and Wilson., Q., D. Connecting Business Objects to Relational Databases. In: Conference on the Pattern Languages of Programs, 5, Monticello-IL, EUA. Proceedings. 1998.
