IPM: AN INCREMENTAL PROCESS MODEL FOR DISTRIBUTED COMPONENT-BASED SOFTWARE DEVELOPMENT Eduardo Santana de Almeida 2, Calebe de Paula Bianchini 1 1
Anhembi Morumbi University (UAM), Computing Department, Rua Quatá, 203, Zip. Code 04.546-041, São Paulo, SP, Brazil Email:
[email protected]
Antonio Francisco do Prado, Luis Carlos Trevelin 2
Federal University of São Carlos, Computing Department, Rod. Washington Luiz, km 235, P.O box 676, Zip.Code 13565905, São Carlos/SP, Brasil Email: ealmeida, prado, trevelin {@dc.ufscar.br}
Keywords:
Incremental Process Model, Reuse, Components, Distribution, and MVCase Tool
Abstract:
In spite of recent and constant researches in the Component-Based Development (CBD) area, there is still lack of patterns, process model and methodologies that effectively support as much the development “for reuse” as “with reuse”. Considering the accelerated growth of the Internet over the last decade, where distribution has become an essential non-functional requirement of most applications, the problem becomes bigger. This paper proposes a novel Incremental Process Model (IPM) that integrates the concepts of Component-Based Software Engineering (CBSE), frameworks, patterns, and distribution. This process model is divided into two stages: the development “for reuse”, and the development “with reuse”. A CASE tool is the main mechanism to apply this process model, supporting inclusively, the code generation of components and applications. A distributed components environment is proposed for accomplishing the results of this process model. Through a case study it is shown how the process model works on a given problem domain.
1
INTRODUCTION
One of the most compelling reasons for adopting component-based approaches to software development, with or without objects, is the premise of reuse. The idea is to build software from existing components primarily by assembling and replacing interoperable parts. These components range from user-interfaces control such as listboxes and HTML browsers, to components for database persistence or distribution. The implications for reduced development time and improved product quality make this approach very attractive [1]. Reuse is a variety of techniques aimed at getting the most from design and implementation work. The objective is not to reinvent the same ideas every time when designing a new product but rather to
capitalize on that work and deploy it immediately in new contexts. In that way, more products can be delivered in shorter times, maintenance costs are reduced because an improvement to one piece of design work will enhance all the projects in which it is used, and quality should improve because reused components have been well tested [1, 2]. In order to make reuse effective, it must be considered in all phases of the software development process [1, 2, 3, 4]. Therefore, the ComponentBased Development (CBD) 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 a component-oriented language. Besides, the CBD must use interrelations among components already in existence, which have been previously tested, aiming to reduce the complexity and the software development costs.
Components are already a reality at the implementation level [4], and now the concept must be founded at the earlier phases of the development lifecycle. Doing so, CBD principles and concepts should be consistently applied through the whole development process, and consistently followed from one phase to the other. Current CBD methods and approaches, those discussed in [1, 5, 6], do not include the full support for the concept of a component. It results in the fact that components are handled mainly at the implementation and deployment phase, instead of being the focal point through the complete system lifecycle. The methods are significantly influenced by their Object-Oriented origins, while trying to introduce the CBD concepts mainly through the use of standard Unified Modeling Language (UML) [7] concepts and notation [8, 9]. In this context, motivated by ideas of reuse, component-based development and distribution this work proposes and evaluates an Incremental Process Model (IPM) to support the Distributed ComponentBased Software Development (DCBD). The paper is organized as follows. Section 2 presents the main mechanisms integrated into the IPM. Section 3 describes this process model, followed by a case study showing its uses. Section 4 discusses relation aspects of tests approaches. An evaluation in which the IPM was applied is described and analyzed in Section 5. Related approaches are considered in Section 6, and, finally, Section 7 presents some concluding remarks and directions for future work.
2.1 Catalysis Method Catalysis [1] method is divided into three levels: Problem Domain Definition, where emphasis is on the problem understanding, specifying “what” the system must do to solve the problem; Components Specification, where the system’s 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 objective of the precision principle is to detect errors and inconsistency in modeling. The “plug-in” components principle supports components reuse to construct other systems [1]. The integration of Catalysis in the first stage of the proposed process model was done through corresponding the definition of each step of the components development, to each of those levels as showed in Table1. Catalysis Method
First Stage of IPM
Problem Domain Definition Components Specification Components Inner Project
Define Problem Specify Components Project Components Implement Components Table 1: Catalysis versus First stage of IPM.
2.2 Middleware 2
MECHANISMS OF THE IPM
After researching different methods, techniques and tools available in the literature [1, 5, 6, 10, 11, 12, 13], it was decided to use Catalysis [1] as the method component development; Middleware [14] as an additional layer between the client and server; framework [15] and Patterns [16] to facilitate the distribution of components, and the uses of database. These mechanisms were integrated by a process model, which guides the software engineer in process software development. To automate the development tasks, the MVCASE tool [17, 18] has been implemented in IPM design where the components constructions and reuses are based.
Middleware differs from usual two layer client/server applications where the client identifies and synchronizes directly with the required server. The concept of middleware assumes the role of an additional layer between the client and the server in the applications multilayers and the applications with distributed objects. Middleware is connectivity software that consists of a set of enabling services that allow multiple processes, running on one or more machines, to interact across a network [14]. The Object Request Broker, or simply, ORB, is among the types of middleware [14] we emphasize in this work. ORB is a technology that manages the communication and the exchange of data between objects. In other words, the ORB provides interoperability in object distributed systems, allowing the construction of applications by grouping objects that communicate between
themselves through it, hiding details of programming languages, operating systems, hardware and localization of objects. Thus, the IPM uses middleware like an intermediary layer, to allow the distribution of the components through the net and to offer to an infrastructure for your localization and communication.
2.3 Framework and Patterns To construct software components that are more reliable, easier to maintain and use, the IPM uses a pattern [16] based framework. Framework can be considered as a reusable design for a system, or subsystem, which describes how the system is decomposed into a set of interacting objects or components [15]. The use of patterns in complex software systems allows already existing and previously tested solutions to be reused, making systems easier to develop and maintain. Thus, to decrease the time and reduce the components development costs of a problem domain, a basic component framework (Persistence) was developed in the database access area. The component framework reuse gives a guide to accomplishing the data persistence in database systems.
2.4 MVCASE Tool CASE tools have been used, with success, in the project and re-project of systems to be reconstructed. Among various CASE tools, MVCASE [17, 18] stands out. It supports system specification using UML notation and has been extended to implement the IPM discussed here. MVCASE supports code generation from the system specifications. The way the IPM leads with the distribution and reuse of components is to manage the components deployment in a set of repositories for further reuse. MVCASE implements a three-tier architecture [26] to construct and place the components. The three tiers allow the software engineer to separate the client applications from the remote client (thin client) interface, business rules, and from the database services or, to store in another way. The components of these tiers can be distributed in different platforms, supporting client-server applications, which can be executed by the Internet. The proposed IPM uses the MVCASE to build and reuse the components of a problem domain, using a middleware. Once specified the components
of a domain can generate the code of those components in an object-oriented language, specifically Java [19], making it available in a component repository for future reuses.
3 IPM: AN INCREMENTAL PROCESS MODEL FOR DISTRIBUTED COMPONENTBASED SOFTWARE DEVELOPMENT Integration of Catalysis CBD method, the principles of middleware, components framework (persistence) and the Distributed Adapters Pattern (DAP) [20], into the MVCASE Tool, define an Incremental Process Model that supports the Distributed Component-Based Software Development (DCBD). The IPM was divided in two stages, as shown in Figure 1, using SADT [21] notation. In the first stage, the process model starts from the requirements of a problem domain and produces implemented components in an object-oriented language (development “for reuse”). Once implemented, these components are stored into a repository. In next stage, using a Trading [22] mechanism offered by MVCASE, the software engineer consults the available components of a given problem domain in the repository. After identifying the necessary components, the applications that reuse them are developed (development “with reuse”). As shown in Figure 1, the main mechanisms of the IPM are the MVCASE tool and the software engineer. The IPM is guided by framework persistence, the Catalysis method, DAP, Middleware and component repository.
Figure 1: IPM for DCBD.
Following is a detailed presentation of each IPM stage presented.
orders of a certain client, and of employees responsible for each task.
3.1 Development of Distributed Components
3.1.1 Define Problem
In this stage, which corresponds to a pattern [23], components of a problem domain are built in four steps: Define Problem, Specify Components, Design Components and Implement Components, according to Figure 2. The first three steps correspond to the three levels of Catalysis, as shown in the right part of Figure. 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 framework Persistence, the DAP, the middleware and the Java language.
In the first step, emphasis is placed on understanding the problem and specifying “what” the components must do to solve the problem. Initially, the requirements of the domain are identified, using techniques as storyboards or mindmaps [1], aiming to represent the different situations and problem domain sceneries. Next, the identified requirements are specified in Collaboration Models [1, 7], representing the action collections and the participant objects. Finally, the collaboration models are refined in Use Cases Model [1, 7]. The first step summarized in Figure 3, 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, aim’s to reduce the complexity and improve the problem domain understanding.
Figure 2: Distributed Components Development Steps.
The detailed presentation of each step of the stage Development of Distributed Components is presented next. To make the understanding of inputs, outputs and controls of each step easier, the Service Order problem domain of a computer company is used as example. The Service Order (SO) domain applications are divided into 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, the manager, service
Figure 3: First Step: Define Problem.
3.1.2 Specify Components This step supports the second level of Catalysis, where the system’s external behavior is described in a non-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’s 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) [1] to detail the objects behavior, with no ambiguity.
oriented paradigm. The framework for Service Order can be reused in several of the application’s domains. Figure 6 shows the Framework Application of Service Order domain. In this framework, the types with placeholders are substituted by respective types.
Figure 4: Model of Types from Specify Components step.
Once identified and specified, the types are put together in Model Frameworks. Model Frameworks are designed at a higher level of abstraction establishing a generic scheme that can be imported, at the design level, with substitutions and extensions in order to generate specific applications [1]. Figure 5 shows this model. The fact that the Model Framework is small, thus narrowly focused, increases its reuse potential in a well-defined application domain, the Service Order domain in this case. In addition, conceived as a Model Framework, it is a reusable asset at the design level, thus it is intended to be customizable to more specific applications down to the code component level [1]. As a design represents much of the major decisions that go into finished code, it can specify frameworks at a design level and offer a process to refine these frameworks down to the level of a set of interoperable code components.
Figure 6: Service Order Framework Application.
Still in this step, the Use Case Models from the last step are refined through Interaction Models represented by sequence diagrams [7] to detail the utility scenarios of components in different applications of the problem domain. In summary, 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; 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 Design Components
Figure 5: Service Order Model Framework.
The types with names written between brackets are defined as placeholders [1]. These types can be substituted in the specific application. The concept is similar to the extensibility of classes of the object-
In this step, the software engineer does the components inner project, according to the third level of Catalysis and specifies other non-functional requirements standing out: distributed architecture, fault tolerance, caching, and persistence. As a first step, the Model of Types are refined to Classes Models [7], where the classes are modeled with their relationships, taking into consideration the components definitions and their interfaces. Figure 7 shows a portion of the Classes Model of Service Order domain. The previous Interactions Models, represented by sequence diagrams, are refined to
show design details of method behavior in each class.
Figure 7: Classes Model obtained from Model of Types.
Starting from Classes Model, use the Distributed Adapters Pattern (DAP) [20] to design from Components Model [7], where the organizations and dependencies between components are shown. The next section presents the overview of this pattern.
becomes independent with respect to the distribution layer, so that changes in the latter do not impact on the former [20]. There are two kinds of adapters: source adapters and target adapters. Roughly, the latter wraps server business objects in the places where they are located, and the former represents those objects in remote locations. In a typical interaction, a user interface object (a GUI, for instance) in one machine would request the services of a source adapter located in the same machine. The source adapter would then request the services of a corresponding target adapter residing in a remote machine. Finally, the target adapter would request the services of a Facade object co-located with the target adapter. Figure 8 illustrates this example [20].
Figure 8: DAP Interaction Model.
3.1.3.1 Distributed Adapters Pattern (DAP) 3.1.3.2 Applying DAP The Distributed Adapters Pattern (DAP) was developed with the purpose of refining the distribution layer of distributed architectures. It is a combination of the Facade, the Adapter, and the Factory design patterns [16]. Indeed, well-known patterns for structuring distributed systems already exist. The Broker [24] and the Trader [24] patterns are two examples. These are architectural patterns [24] and focus mostly on providing fundamental distribution issues, such as marshalling and message protocols. Therefore, they are mostly tailored to the implementation of distributed platforms, such as CORBA [22] for instance. DAP uses these fundamental patterns and provides a higher level of abstraction due to the distribution Application Programming Interface (API) transparency to both clients and servers [20]. DAP introduces a pair of object adapters [24] to achieve better decoupling of components in distributed architectures. The adapters basically encapsulate the API that is necessary for allowing distributed or remote access of business objects. In this way, the business layer of an application
Figure 9 shows the design Components Model after the application of DAP. The components Source and Target abstract the business rules of the problem domain. The TargetInterface interface abstracts the Target component behavior in distributed scenery. At this interface, the components Source and Target do not have communication code either. These three elements compose a distributed independent layer. The main components 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 another machine, isolating the Target component from distributed code. SourceAdapter and TargetAdapter, usually, are located in different machines, and do not directly interact. TargetAdapter implements RemoteInterface used to connect with SourceAdapter.
Figure 9: Design Component Model after apply DAP.
Once designed components, specify other nonfunctional requirements. 3.1.3.3 Other non-functional requirements The adapters presented deal with basic distribution details and hide these details from the business and the user interface code. The adapters may also handle additional non-functional behavior, which also should not affect the business and the user interface code. In this step, we illustrate how the adapters may perform some of this additional behavior, which might be useful for implementing distributed applications. i. Fault Tolerance. The source adapters presented previously have no fault tolerant behavior. If there is a communication error or if the server is unavailable, they simply raise a communication exception. Nevertheless, source adapters can also implement fault tolerant behavior. If a source adapter receives a remote exception when interacting with the target adapter, it may implement the policy of trying to contact the target adapter again a certain number of times, or trying to contact another target adapter, representing a spare service. This policy, being implemented by the source adapter, is hidden from its client, a GUI for instance. ii. Caching. Some operations may return a considerable amount of data, of which only part is useful at any moment. Sending everything to the client at once is not desirable since it may have a negative impact on network performance. One solution is to send a cache with part of the required data and to transfer more data every time a fault happens. A source adapter can implement this caching behavior. When a querying operation returns many entries, part of them are used to initialize a source adapter. The client of this adapter (a GUI, for instance) retrieves the entries from this adapter.
When a fault happens in the source adapter, it contacts the target adapter to retrieve more entries. This caching behavior is implemented in the source adapter and is transparent to the GUI. iii. Data Persistence. To facilitate database access the software engineer can be reuse components of Persistence framework [25]. Figure 10 shows these components. 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), 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 10: Framework Persistence.
In summary, the main artifacts and the sequence of the Design Components activities, include: a) Refining Model of Types into Classes Models; b) Refining the Interactions Models; and c) Creating the Components Models. 3.1.4 Implement Components In this step, the software engineer defines the distribution technology and so uses a code generator, from MVCASE, to optimize implementation tasks from designed components. In this situation, CORBA was chosen as illustration means, but other technologies such as RMI [19], JAMP [28] and JINI [19] can be used. Thus, for each component, it has the stubs and skeletons and its interfaces that make its services available. Those components are customized by
software engineer and next stored in a component repository to be used on applications development in the future. Figure 11 shows, the process of code generation of design component by MVCASE.
Figure 11: Generate code in MVCase tool.
3.2.1 Specify Application This step starts with the problem understanding and identifying the application requirements. Before the requirements specification starts at MVCASE, the software engineer, using its Trading mechanism imports the components of the related problem domain, in this case SO, that are available in the repository and will be used in the application. Next, the requirements are specified in Use Cases and Sequence Diagrams. Continuing the modeling process, the software engineer specifies the application component model. In this case, the component ServletAddCustomer was built in away that reuses services from the SO domain components. Figure 13 shows the three components (shaded), reused in the Add Customer application.
Once the components of the problem domain are constructed, the software engineer goes to the second stage on IPM, where applications that reuse those components may be developed.
3.2 Development of Distributed Application Figure 12 shows the steps for application development. It starts with the application requirements and proceeds with the normal life cycle development, which includes: Specify Application (SA), Design Application (DA) and Implement Application (IA). The constructed components of the problem domain are available to reuse in the component repository. As in components development, MVCASE is the main mechanism to guide the software engineer during the application development.
Figure 12: Development of Distributed Applications.
For a better comprehension of these steps, an application example is developed that registers, via web, a customer from the Service Order (SO) domain and which components were built in the previous stage.
Figure 13: Reused components in the Add Customer application.
3.2.2 Design Application The specifications from last step are refined by the software engineer to obtain the application project. In this step, the non-functional requirements related to distributed architecture and data persistence are specified. Figure 14 shows the components diagram of the application project, where the components DriversUtil, ConnectionPool, FacadePersistent and TableManager, from persistence framework, were added to deal with the database access.
3.2.3 Implement Application At last, based on the application project, the software engineer uses the MVCASE code generator and produces customized adaptations. Figure 16 shows part of the generated code to Add Customer application.
Figure 14: Project of the distributed application.
Once the projected application is achieved the software engineer prepares the environment for execution. 3.2.2.1 Prepare Environment To distribute an application, at least one platform needs to be chosen. For this platform there must be some configuration information, such as the location of a server, port numbers and others. Figure 15 shows how the distributed application is structured, through an Object Web [26] extension model, using a middleware, e.g. CORBA, to accommodate the components repositories. In the first layer, the client executes the application. Through the HTTP (HyperText Transfer Protocol) communication, the requests are sent and received from Servlets, available in the Web Server. In the second layer, the web server communicates to the Component Server, which makes available the problem domain components that are stored in a repository. This communication is done via ORB. 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 16: Implementation of the Add Customer application.
4
TESTS WITH THE IPM
The IPM test is done at three levels, individual components, consistency within a domain, and application development reusing components. i. Within a domain, each component is tested individually by building a simple test application around the component that allows the component’s funcionality to be exercised. ii. Then, tests to verify the internal consistency between components of a domain are accomplished. iii. The last form of testing is at the level of applications. Applications are submitted to a long series of tests before taken into production. The Service Order domain, constructed using IPM, was tested using these three levels presented. The tests had helped to correct imperfections in the different phases of the process model, driving improvements in each step and refining the mechanisms integration.
Figure 15: Extended Distributed Model Object Web.
5
IPM EVALUATION
In order to determine whether the IPM meets its proposed goals, the Service Order domain was developed and analyzed. This section describes the evaluation, discussing its soundness and usefulness.
5.1 Methodology The approach for evaluation was developed using the components and applications for Service Order domain by applying IPM. The technologies used by IPM were: a) Java as implementation language; b) HTML and Servlets, for user interfaces across the Web; c) MySQL for persistent storage; d) CORBA as the distribution technology. The study’s subject was two undergraduate students (S1 and S2) with one year’s experience in cited technologies. Initially, based on problem domain requirements, S1 and S2 executed an initial analysis of the domain in order to realize their understanding. In sequence, already with the IPM in hand, their execution began step by step. In the step to define problem, the requirements of the domain were identified utilizing the techniques of mind-maps. The collaboration model had been specified as a requirement of the domain, and later, the use cases model. Firstly, a global use case model was defined and, in sequence, this model was fragmented into packages, with their respective models (ex: package customer, task). From the specifications refinement of the previous step, S1 and S2 passed to the subsequent step. In this step, the model of types was developed, the model framework, the framework application and the interaction models for each use case. After the conclusion of components specification, S1 and S2 started their project. The model of types from the previous step was, initially, refined in the classes model. The same refinement procedure adopted for the use cases model was adopted. In sequence, the DAP was applied for each business class identified. Additionally, other nonfunctional requirements had been projected, as caching and data persistence. After, the interactions models of the previous step were refined, adding the classes with the DAP structure and the framework persistence structure. At last, S1 and S2 created the domain components model.
Once the components were projected, S1 and S2 completed their implementation and later, the tests. Table 2 summarizes the artifacts available on the first stage of IPM. Table 2: Artifacts Available. Step Artifact Define Problem Define Problem Define Problem Specify Components Specify Components Specify Components Specify Components Specify Components Design Components Design Components Design Components Implement Components Implement Components
Mind-Map Collaboration Model Use Cases Model Model of Types Data Dictionary Model Framework Framework Application Interactions Model Classes Model Interactions Model Components Model Interfaces Components
Qt. 1 1 1 1 1 1 1 18 5 18 5 16 24
After the conclusion of the first stage, S1 and S2 began the subsequent phases, completing the steps defined in section 3.2. The construction of the domain and their applications [27] results in a total of 24 components, 18 applications and 3812 lines of code developed, as measured by the Unix wc (word count) program, not counting the blank lines, commentaries and Java libraries used. Total construction time was 60 hours and 13 minutes.
5.2 Discussion With this evaluation, we conclude that utilization the process model proposed, where desires guide the software engineer in the development of the components and applications of a domain, results at the end of the process in a much better quality software compared with an ad-hoc approach. Using the IPM achieves the following benefits: i. Modularity: the IPM allows systematic separation of the aspects of distribution and persistence in database, avoiding an interlacement of codes with different purposes; ii. Reuse: through the artifact input availability, the IPM allows the reuse from models (Model Framework) to codes, optimizing and improving the development tasks; iii. Partial automation: with the MVCASE tool support, a great part of the activities proposed in the IPM can be executed automatically; iv. Define changes in the communication code of the components, a minimized form, with the utilization of the DAP pattern. Even with the advantages listed above, the following disadvantages can be observed:
i. Incremental class number [20]: in order to use the DAP pattern, it is necessary to use a pair of adapters, as well as initialization and nomination components. These structures though can be generated through partial automation using the MVCASE; ii. Commercial off-the shelf (COTS): the way the IPM was initially projected does not consider the possibility of using components acquired somewhere else.
6
RELATED WORKS
There are similar works in literature. In this section, we’ll present part of them, emphasizing their differences and similarities in the proposal approach. i. In [28], the authors describe an object-oriented distributed systems development strategy, divided into three steps: Distributed System Specification, where the system is modeled using UML notation, Object Distribution, where is defined the architecture of the system distributed based in the services and frameworks available in platform JAMP (Java Architecture for Media Processing) and Distributed System Implementation where is realized their implementation, based on specifications of the previous steps. This approach differs from the approach proposal for utilizing frameworks available in platform JAMP, where all strategy is supported. Furthermore, it works with objects, not components, decreasing the reuse in the applications development. ii. In [29], is presented a strategy for distributed component-based systems development, which uses Aspect-Oriented Programming (AOP) to describe and implement the dependencies between components. The authors use the process modeling of the component-based system proposed in [10]. This process was extended using AOP in interfaces and components specification and components implementation levels. Compared to the proposal of [29], the IPM defines an incremental approach for distributed component-based software development, starting at level conception domain, identifying their elements and relationships, until their current materialization on software components. On the other hand, IPM allows no just code reuses, as in, models of high abstraction level (Model Frameworks). Furthermore, the IPM defines, systematically, the applications development reusing the development components.
iii. The Rational Rose [12] and Objecteering/UML [13] are CASE tools that offer a great range of resources in order to support the whole distributed component-based software development process. These tools support the system specification using UML notation and generate code from these specifications. Compared to the MVCASE tool, this differs from the other tools for having a component repository integrated, allowing the storage and search for components for a later use in the application development. Another resource available in the tool is a visual editor like the ones found in other environments, as in JBuilder, allowing a quick application development. Last, for being an academic tool, the MVCASE is totally free.
7 CONCLUSION AND FUTURE WORKS The main contribution of this work is to propose an Incremental Process Model (IPM) for Distributed Component-Based Software Development, that integrates several mechanisms, guiding the software engineer as much in the development as in the reuse of components of a problem domain. The integration of mechanisms in the MVCASE tool makes possible the development of components and applications in a distributed platform. Although these mechanisms exist in the literature, still it exists 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. Additionally, an evaluation was accomplished that has shown the process model’s usefulness. By following the IPM, the software engineer will not, to the end of process, tangle code of different layers, such as user interface, distribution and persistence. 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. In future work, two directions are being researched for integration in the IPM: the utilization of Aspect-Oriented Programming (AOP) [30] to treat distribution and database persistence, as well as, the insertion of other functions, like concurrency control and security. A second direction comes from the COTS use, as was mentioned in section 5. Lastly, we intend to gather experience with other users of the IPM, and perform further experiments to
verify if the model can be successfully applied to larger domains. There is a necessity to investigate the distributed components performance, and finally, to explore their utilization on a larger scale.
[14] Eckerson, W., et al., 1995. Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client/Server Applications. Open Information Systems. [15] Johnson, R., 1996. How To Develop Frameworks. In ECOOP’1996, 10th European Conference on Object-Oriented Programming, Tutorial Notes. [16] Gamma, E., et al., 1995. Elements of Design Patterns: Elements of
ACKNOWLEDGEMENTS
Reusable Object Oriented Software, Addison-Wesley.
The authors would like to thank the anonymous referees for their reviews and suggestions during this work. This work is supported by Fundação de Amparo à Pesquisa do Estado da Bahia (Fapesb)Brazil.
[17] 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. [18] 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
REFERENCES
SBES’2002, 16th Brazilian Symposium on Software Engineering, Tools Session.
[1] D’Souza, D., F., Wills, A., C., 1999. Objects, Components, and Frameworks with UML, The Catalysis Approach, Addison-Wesley. USA.
[19] Horstmann, C., S., Cornell, G., 2002. Core Java 2: Volume II, Advanced Features, Prentice Hall. [20] Alves, V., Borba, P., 2001. Distributed Adapters Pattern (DAP): A
[2] Jacobson, I., Griss, M., Jonsson, P., 1997. Software Reuse:
Design Pattern for Object-Oriented Distributed Applications. In
Architecture, Process and Organization for Business Sucess, Addison-
SugarLoafPlop’2001, The First Latin American Conference on
Wesley. Longman.
Pattern Languages of Programming.
[3] Heineman, G., T., Councill, W., T., 2001. Component-Based Software Engineering, Putting the Pieces Together, Addison-Wesley. USA. [4] Szyperski, C., 1998. Component Software: Beyond Object-Oriented
[5] Jacobson, I., et al., 2001. The Unified Software Development Process. Addison-Wesley. USA, 4nd edition.
methodology for delivering next generation applications, The Active Archive Solutions Company. Avaliable in 10/06/2002, URL:
Group.
Avaliable
in
10/04/2001,
URL:
http://
www.omg.org.
DDCP:
A
Develop
Distributed
Component
Pattern.
In
SugarLoafPlop’2002, The Second Latin American Conference on Pattern Languages of Programming. [24] Buschmann, F., et al, 1996. Pattern Oriented Software Architecture: A
http://www. princetonsoftech.com. [7] Rumbaugh, J., et al., 1998. The Unified Modeling Language Reference
System of Patterns. John Wiley & Sons. [25] Yoder, J., Johnson, R., E., Wilson, Q., D., 1998. Connecting Business
Manual, Addison-Wesley. USA. [8] Stojanovic, Z., Dahanayake, A., Sol., H, 2001. A Methodology Framework for Component-Based System Development Support. In
Objects to Relational Databases. In PLoP’1998, Pattern Language of Progamming. [26] Orfali., R., Harkey, D, 1998. Client/Server Programming with Java
EMMSAD’2001, Sixth CAiSE/IFIP8.1. [9] Boertin, N., Steen, M., Jonkers., H, 2001. Evaluation of ComponentMethods.
[22] The Common Object Request Broker Architecture, 1996. Object
[23] Almeida, E., S., Bianchini, C., P., Prado, A., F., Trevelin, L., C., 2002.
[6] Perspective, 2000. Select Perspective: Princeton Softech’s practical
Development
Ideas, 1997. IEEE Transaction on Software Engineering.
Management
Programming, Addison-Wesley. USA.
Based
[21] Ross., D., T. Structured Analysis (SA): A language for communicating
In
EMMSAD’2001,
Sixth
CAiSE/IFIP8.1. [10] Cheesman, J., Daniels, J., 2000. UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley. USA, 1nd edition. [11] Atkinson, C., et al, 2000. Component-Based Software Engineering: The KobrA Approach. In ICSE’2000, 22th International Conference on Software Engineering, 3rd Workshop on Component-Based Software Engineering. ACM Press. [12] Rational Rose Tool, 2001. Rational the software development company. Avaliable in 10/07/2001, URL: http://www.rational.com. [13] Objecteering/UML Tool, 2002. Objecteering Software. Avaliable in 10/07/2002, URL: http:// www.objecteering.com.
and CORBA. John Wiley & Sons, Second Edition. [27] Almeida., E., S., 2002. Service Order Domain Construction Report (in portuguese). Federal University of São Carlos. [28] Guimarães, M., P., Prado, A., F., Trevelin, L., C., 1999. Development of Object Oriented Distributed Systems (DOODS) using Frameworks of the JAMP plataform. In First Workshop on Web Engineering, in conjunction with the 19th International Conference in Software Engineering (ICSE). [29] Clement, P., J., Sánchez, F., Pérez, M., A., 2002. Modeling with UML Component-based and Aspect Oriented Programming Systems. In WCOP’2002,
The
7th
Workshop
for
Component-Oriented
Programming. In conjunction with the 16th European Conference on Object-Oriented Programming (ECOOP). [30] Kiczales, G., et al, 1997. Aspect-Oriented Programming (AOP). In ECOOP’1997. LNCS Springer-Verlag.
