An Evolution Process for Application Frameworks

Transcription

1 An Evolution Process for Application Frameworks Maria Istela Cagnin 1, José Carlos Maldonado 1, Paulo C. Masiero 1, Rosana T. V. Braga 1, Rosângela Dellosso Penteado 2 1 Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo USP São Carlos-SP, Brazil, CEP Departamento de Computação, Universidade Federal de São Carlos UFSCar São Carlos-SP, Brazil, CEP [istela, jcmaldon, masiero, rtvb]@icmc.usp.br, rosangel@dc.ufscar.br Abstract Application frameworks, as occurs with any software, evolve as they are used. The initial versions often do not satisfy all the domain requirements for which the framework has been built, thus, soon after the framework is released for use, the evolution process starts. As it is a generic architecture of a domain, framework maintenance activities differ from maintenance activities of conventional applications. An evolution process for application frameworks, comprising eight steps, is proposed. This process is based on the evolution of a framework for the information systems domain. 1. Introduction A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize for specific computing solutions. With frameworks, software developers do not have to start from scratch each time they write an application [16]. The framework architecture consists of fixed parts (frozen spots) and variables parts (hot spots) [5]. The fixed structure defines the system overall architecture its basic components and their interrelationships and is primarily used without modification in all framework instantiations. The variable structure contains the components that can be adapted and extended by the domain application engineer to satisfy the needs of a particular system (business rules, functional requirements inherent to the organization, internal policies, etc). Instantiation of new applications in the domain is done by component selection (black box) or by class specialization of the variable structure (white box). As frameworks technology consolidates and applications are instantiated based on them, the need for a comprehensive and formally organized process for framework maintenance and evolution grows. The authors of this paper could not find in the literature a proposal for such type of process. The process proposed in this paper was motivated by two reengineering case studies, using the PARFAIT agile reengineering process [7], which uses the GREN framework [1] as the basis for legacy systems reengineering. GREN is the acronym for Gestão de Recursos de Negócios (in portuguese), which means Business Resource Management, and support purchase, sale and rental of business resources. It was developed based on the GRN pattern language that records knowledge about that domain [2]. During the usage of the PARFAIT process, it was noticed that the legacy system had several functionalities not implemented in GREN. The process here presented is generic and can be the basis for the evolution of other framework types, as for instance, those based on components and on aspects [10]. This paper is organized in the following way. In Section 2, works related to the context of this paper are discussed. In Section 3, the proposed process for framework evolution is presented, Financial support from FAPESP #00/

2 giving a detailed description of each step. In Section 4 evolution examples of the GREN framework, using the process proposed, are shown. In Section 5, concluding remarks and future work are presented. 2. Related Work The Evolving Frameworks pattern language [15] documents how frameworks are built with a white box structure and evolve until they become black box, but it does not comprise maintenance and configuration management activities. Based on experiences of industrial framework evolution, Mattsson and Bosch propose a classification of frameworks evolution [11], motivated by the addition or modification of requirements in a product family [17]. Four types of maintenance have been identified: internal reorganization, changing functionality, extending functionality, and reducing functionality. Other classifications for software maintenance can be easily adapted to the framework context. Chapin et al. [8] proposes a classification based not on people s intention, but on objective evidence of maintainer s activities, i.e., it is determined based on the activities performed and on the produced artifacts, together with a comparison done before and after the software documentation. They propose twelve types of maintenance, grouped in four clusters, supported by criteria to guide the maintainer to decide which is the correct type of maintenance. Each cluster has a default type, with different impact degrees on the software itself and on the business processes. The default type is chosen when the other types in the cluster do not fit the maintenance activity conducted. From these twelve maintenance types, five are considered by Chapin et al. as software evolution types: performance, adaptive, reductive, corrective, and. In the context of frameworks, we can consider these five types and add the preventive type, as it contributes to better software, so it can also be considered as software evolution. Following, these six maintenance types are described: Corrective: modifies the software to fix functionality defects or make it more correct. Preventive: modifies the source code to avoid or reduce future maintenance activity. It does not alter either the software functionality or the existing technology. Adaptive: modifies the source code to accommodate changes in its external environment (CPU, OS, etc) or resources used, without altering its functionality. Reductive: modifies the software to restrict or reduce functionalities. Enhancive: modifies the software to replace, add to, or extend functionalities. Performance: modifies the source code to alter software performance characteristics or properties. 3. A Process for Frameworks Evolution Management The steps of the proposed process for framework evolution are illustrated in Figure 4. These steps are applied in an incremental and iterative way. In order to successfully apply this process, the domain engineer needs to have previous knowledge of the framework functionalities and architecture. The process emphasizes mainly the maintenance, as it has significant differences from the evolution process of other software types. It should be noticed that steps 2 and 3 are

3 conducted by the application engineer, while steps 1, 4, 5, 6, 7, and 8 are conducted by the domain engineer. For each requirement or set of requirements (functional or non functional) not satisfied by the framework: Step 1) Analyze if the requirement (or set of requirements) can be considered generic to the framework domain (usage of requirements history). In case it cannot be considered generic: Step 2) Design, implement and test functionalities in the application to satisfy the requirement (or set of requirements). Step 3) Log the requirement (or set of requirements) in the requirements history. In case it can be considered generic: Step 4) Design, implement and test functionalities in the framework to satisfy the requirement (or set of requirements). Step 5) Update the framework documentation. Step 6) Validate the framework Step 7) Update tools associated to the framework (for example, instantiation tool). Step 8) Handle Configuration Control Management. Figure 4 Framework Evolution Process Step 1) Analyze if the requirement can be considered generic to the framework domain (usage of requirements history) The first and most important decision of the domain engineer, when facing a maintenance request, is to decide whether or not the functionality (or a set of requirements that may occur more than once in the same application) requested is: a) considered generic to the framework domain and could be used in other applications, then should be incorporated to the framework, or b) is not considered generic to the framework domain and thus, should not be implemented because of this, or c) is considered generic to the framework domain but should not be implemented due to lack of technical and/or economical feasibility. In cases b) and c), the functionality or set of requirements must be stored (Step 3) for a possible change of decision in the future, thus being a candidate to be implemented in the framework. Other factors that should be considered to make this decision are out of the scope of this paper. The criteria to decide the generality of certain functionalities are the same used for making that decision during the framework development [1, 3, 14, 15]. When in doubt, the domain engineer may consult the log of functionalities (stored in the requirements history - Table 1), which have been identified but that were not implemented in the first version of the framework or were implemented in maintenances done in applications instantiated from it to verify if it has occurred at least two more times (according to Roberts and Johnson [15]). If this is true, it is a strong indication that the requirement is generic to the domain and should be satisfied and withdrawn from the requirements history. If the requirement is considered as belonging to the domain, and if it is decided to implement it, then steps 4-8 should be taken, otherwise, steps 2-3 are chosen Steps to follow when the requirement (s) cannot be considered generic Step 2) Design, implement and test functionalities in the application to satisfy the requirement (or set of requirements) Once decided that the requirement will not be implemented in the framework, it is implemented directly in the application that has been instantiated from the framework. To implement the

4 modification, it is necessary to study the application classes and methods, as well as the framework superclasses from which they inherit from, in order to avoid that modifications done in the application damage the expected framework behaviour (design level). The implementation must be done with special attention to the flexibility of the modifications, because otherwise if a decision is made later extend the domain, the code of the modified application will probably be used as a basis for the framework generalization and implementation. After implementing the requirement directly in the application, it should be tested, initially with unit test of the affected modules, and then by integration, regression and system tests, verifying specially if no functionalities have been damaged with the implementation of the new one. ID. Requirements Requirements type 01 Books may have several Functional authors. 02 Book belongs to a certain Functional area (Mathematic, Biologic and Human sciences). 03 Electronic appliance has Functional an owner. 04 Need for printing mailing list labels. 05 A damage file is created to store information about damages reported due to the hole and includes citizen name and address. 06 It is necessary to autenticate the system users, to log the accesses made, and to block the accesses to certain user operations, according to its role. 07 It is necessary to solve the performance problem that occurs when large volume of data is loaded into graphical user interfaces. Functional Functional Table 1 Requirements History Design Solution Implemented in the application Implements the book authors as a multivalued attribute of the Book class. Implements the book area as an enumerated type. Implements an electronic appliance owner in the Appliance class as a reference to class Owner through an enumerated type. Implements the mailing list labels creating the Label class with two preestablished label sizes. Creates a Damage class from the syntactic application of the TRADE THE RESOURCE GRN pattern, in order to control the damage occurred. Functional A Security sub-system was implemented, using aspect-oriented programming, to implement these functionalities. Nonfunctional Profilers were used to determine the system bottleneck. Then, process forks were used so that the loading of registers into memory is done in background, with a lower priority. Application Library Library Repair Shop Repair Shop Potholes Repair (development) Maintenance Type - Sale System performance Step 3) Log the requirement (or set of requirements) in the requirements history Once functionalities have been implemented in the specific application to satisfy certain requirements, the application engineer has to inform the solution adopted. This should be performed by logging, in the requirements history, the description and the type of each requirement (functional or non-functional), the solution adopted, and the maintenance type conducted Steps to follow when the requirement (s) can be considered generic Step 4) Design, implement and test functionalities in the framework to satisfy the requirement (or set of requirements).

5 Requirements that appear two or more times in the Requirements History should be analyzed for generality, as discussed in step 1, and those that are considered generic to the domain, have to be implemented first in the framework, before the new application is instantiated from it. The first activity is to decide how the requirement can be satisfied by the framework (design level). The design class diagram is updated, observing which classes, relationships, methods and attributes have to be added and/or modified in the component affected, to allow the implementation of the designed functionalities. For this, it is necessary to study in advance or to have deep knowledge about the framework architecture and classes hierarchy. The functionalities that have already been implemented in applications instantiated from the framework should serve as basis for the study and, if possible, they may be generalized from the implementations done and from the domain knowledge. When it is decided to implement a typical functionality of the domain, but which had not been implemented yet, for reasons of scope of the first effort, a process for domain analysis similar to that used to generate the framework should be used [1, 3, 14, 15]. Next, the functionalities are coded in the framework, so a deeper study of its class hierarchy may be necessary. In this process, it is important to distinguish which classes will belong to the fixed framework structure and which will be made more flexible (applying for example, metapatterns [13] and design patterns [9]), to consequently be part of the framework variable structure. The domain engineer should test the implemented functionalities, choosing some test criterion as, for instance, equivalence class partitioning and boundary value analysis functional criteria [12]. Then, it can be checked if the functionalities implementation satisfies the desired requirement. Afterwards, integration and regression tests are conducted to verify if the implemented functionality satisfies the intended requirement and whether or not existing functionalities have been damaged by the implementation of the new functionalities. If the functionalities had already been implemented during maintenances in instantiated applications, the tests previously created can be reused after being properly adapted to the new needs. Step 5) Update the framework documentation All the modules of the framework documentation that depend on the changes done during the implementation of the functionalities to satisfy a new requirement have to be updated (class diagrams, class hierarchy, cookbook, etc). Step 6) Validate the framework In this step, system more robust validation is conducted to verify if the implemented functionality satisfies the intended requirement and if no existing functionalities have been damaged by the implementation of the new functionalities. Then, all framework parts that reflect the modifications done have to be properly validated through several instantiations that include the new functionalities, following the process considered in the updated cookbook. That activity has to be conducted with the cooperation of both a domain engineer and an application engineer to certificate that requirements have been considered. It is stressed that the system validation is important for correcting and tunning the documentation resulting from the previous step. Step 7) Update tools associated to the Framework If the framework has associated tools, they have to be properly updated to reflect the changes done in the framework. This requires considering the same issues needed to make any type of maintenance, as already mentioned in step 4, e.g. understanding the tool architecture, its class hierarchy, source-code, etc. In the specific case of updating the framework instantiation tool, the cookbook, updated in step 5, can serve as a guide to know the changes that need to be done.

6 Step 8) Handle Configuration Control Management This activity is essentially similar to the configuration control management for other software types, but can become more complex due to the existence of several versions and support tools for the framework. Applications that were generated based on a previous version of the framework could be created again, now based on its new version (this is quite often not practical) or could continue working in the framework version in which they were created. In this case, a rigorous framework version control is required, to manage the available framework versions and their corresponding derivated applications. In the case of applications that went through changes directly in the source code, other precautions should be taken as new changes are incorporated, because the code that was manually included in the application can conflict with them. So, if you use the tool to generate the application again, you will probably loose the manual changes done. Besides, special attention should be paid to the effect that modifications can cause in the database architecture, the need to migrate ancient data, and also undo possible changes that had been done directly in the application code. 4. Evolution Examples based on the GREN Framework This section presents the evolutions of the GREN framework using the proposed process for framework evolution. Step 1) Analyze if the requirement can be considered generic to the framework domain Table 1 presents a list of requirements for several applications in the business resource management domain that were not satisfied by GREN and, therefore, were logged according to step 4. This history was built after using GREN in the development of one system (i.e. Pothole Repair) and in the reengineering of three different systems: Library, Repair Shop, and Sale System. In fact, some of them could be manually implemented with some effort, but there were no facilities available to ease their implementation. Requirements such as #1 could be implemented using string attributes, but this would cause problems in the future. According to the analysis conducted, it has been noticed that the requirements recorded in the history are used twice or more in the business resource management domain, so they are functionalities inherent to that domain and their absence could limit too much the framework usage (with exception of requirement 5). Consequently, they are candidates to be implemented in the framework and, after that, should be removed from the history. The security requirement (# 6) was already known since the GREN implementation as a desirable requirement for the domain, but has not been implemented. This requirement has been added to the history in GREN version 1, to be implemented in the future, as it is a requirement that should be present in practically all the domain applications. The same occurs with performance requirements, as exemplified by requirement 7. In real systems, it would not be admissible to wait for minutes before being able to include a new product, for example. This was the case in the Sale System being reengineered using GREN. The legacy system contained more than forty thousand products, and the reengineered system time to retrieve them from the database was almost three minutes. By fixing the problem in the framework itself, other systems instantiated from it can take advantage of the evolution and will not suffer the same problem. In summary, requirement 5 was not considered generic, so steps 2-3 are applied to it, while the remaining requirements were considered generic, so steps 4-8 are applied to each of them.

7 Step 2) Design, implement and test functionalities in the application to satisfy the requirement As mentioned before, requirement 5 has been implemented directly in the application of the pothole repair system. Tests were conducted during and after this implementation, in order to verify if no functionalities have been damaged with the implementation of the new requirements. Step 3) Log the requirement in the requirements history Table 1 suggests a possible template to be used to log the requirements to be implemented in the future. Step 4) Design, implement and test functionalities in the framework to satisfy the requirement The first three maintenances of GREN, motivated by requirements 1 to 3, were. Both the fixed and the variable structure of the framework have been altered, as new concrete and abstract classes have been added to ease the inclusion of attributes with special types (i.e. enumerated and multivalued types) in the application classes. Requirement 4, which led to the fourth maintenance of GREN, included a new type of system output mailing list, which implied changes in its fixed and variable structures. For requirement 6, more complex modifications in the fixed structure of GREN were required, as seventeen classes were created to implement the whole access control system, as well as some simple modifications in the variable structure. The implementation of requirement 7 required some study about profilers and processes, but no modifications in the GREN framework were necessary: only a few methods were changed to solve the performance problem. Functional, integration, and regression tests were performed during and after the several GREN evolutions. Step 5) Update the framework documentation The maintenances, as expected, resulted in changes in the external documentation. Procedures were created in the cookbook to describe how to add, to the concrete classes of the instantiated applications, new attributes of types enumerated and multivalued. The possibility to choose another special type of report has been documented in one of the patterns of the GRN pattern language, and the possibility to decide if an instantiation does or does not adopt the security requirement has been documented in the cookbook. Step 6) Validate the framework The GREN framework was validated in each of its evolutions. Applications that were instantiated before using GREN, but with uncovered requirements, were created again with the evolved version, to check if the evolution was well succeeded and existing funcionalities were not damaged. Step 7) Update tools associated to the Framework All the maintenances done in GREN have been incorporated to its Visual Builder. For requirement 7, no modifications were needed in the Visual Builder. Step 8) Handle Configuration Control Management A special tool, called GREN-WizardVersionControl [6], was built to help detecting changes in the source code for each new version of the applications instantiated by the GREN Visual Builder [4]. This tool stores the code inserted manually by the application engineer in the applications instantiated and, when the Visual Builder is invoked again with the same application, it does the matching with the code supplied by the visual builder, detecting code inclusions, modifications, and exclusions. Code inclusions and exclusions are handled by the tool itself when instantiating the application new version. However, code modifications have to be handled by the application

8 engineer at run time, when he chooses the better implementation (i.e., GREN Original Method or GREN Modified Method) for the current version. 5. Conclusion Although the proposed process has some steps that are similar to any other software maintenance process, it has several peculiarities inherent to the framework variability control. Several types of maintenance should be supported: corrective, adaptive, preventive,, and performance. Reductive evolution may also follow steps 4 to 8 but changing properly implement by cut in step 4. The experience with the evolution of a framework for the information systems domain, during about three years, is still not enough to validate and guarantee the generality and comprehensiveness of the proposed process. The process is being continuously improved as new versions and new functionalities continue to be implemented from new uses. References 1. Braga, R.T.V. A Process for Construction and Instantiation of Frameworks based on a Domain-Specific Patterns Language. Sc.D. Thesis Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos-SP, Brazil, 224 p., (in portuguese). 2. Braga, R.T.V.; Germano, F. S. R.; Masiero, P. C. A Pattern Language for Business Resource Management. In: Annual Conference on Pattern Languages of Programs, PLOP'99, 6, Monticello, Illinois, EUA, Proceedings, v.7, p. 1-33, August, Braga, R.T.V.; Masiero, P.C. A Process for Framework Construction Based on a Pattern Language. In: 26 th Annual International Computer Software and Applications Conference (COMPSAC 2002), IEEE, Oxford, England, p , August, Braga, R.T.V; Masiero, P.C. Building a Wizard for Framework Instantiation Based on a Pattern Language. In: 9 th International Conference on Object-Oriented Information Systems (OOIS 03), Geneva, Switzerland. Lecture Notes on Computer Science, LNCS 2817, Springer, p , September, Buschmann, F. et al. Pattern-oriented software architecture: A System of Patterns, Wiley, Cagnin, M.I.; Maldonado, J.C.; Germano, F.S.; Penteado, R.; Braga, R.T.V. GREN-WizardVersionControl: A Support Tool to the Applications Version Control Created from GREN Framework. In: Tool Session'2004, Brazilian Software Engineering Symposium, 2004 (portuguese, to be published). 7. Cagnin, M.I.; Maldonado, J.C.; Penteado, R.; Germano, F. PARFAIT: Towards a Framework-based Agile Reengineering Process. In: Agile Development Conference, Salt Lake City, Utha, EUA, 25-29, p , June, Chapin, N.; Hale, J. E.; Khan, K. M.; Ramil, J.; Tan, W. Types of software evolution and software maintenance. Journal of Software Maintenance and Evolution: Research and Practice, v. 13, p. 3-30, Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns Elements of Reusable of Object-Oriented Software. Addison-Wesley, 2ª edition, Kiczales, G., et al. Aspect-Oriented Programmming. In: Proceedings of the European Conference on Object- Oriented Programming (ECOOP). Springer-Verlag, Finland, June Mattsson, M.; Bosch, J. Frameworks as Components: a Classification of Framework Evolution. In: Proceedings of Nordic Workshop on Programming Environment Research, Ronneby, Sweden, p , August, Myers, G.J. The Art of Software Testing. Wiley, Pree, W. Design patterns for object-oriented software development. Addison-Wesley, Pree, W. Hot-spot-driven development in M. Fayad, R. Johnson, D. Schmidt. Building Application Frameworks: Object-Oriented Foundations of Framework Design, John Willey and Sons, p , Roberts, D.; Johnson, R. Evolving frameworks: A pattern language for developing object oriented frameworks. In: Martin, R.C., Riehle, D., Buschmann, F. Pattern Languages of Program Design 3, Addison- Wesley, p , Taligent Inc. Building Object-Oriented Frameworks, URL: postscript/ buildingoo.pdf. Accessed: March, Weiss, D. M; Lai, C. R. R. Software product-line engineering. Addison-Wesley, 1999.