interactive automatic (rules) automatic (patterns) interactive REP ENVIRONMENT KERNEL

Transcription

1 AN APPROACH TO SOFTWARE CHANGE MANAGEMENT SUPPORT Jun Han Peninsula School of Computing and Information Technology Monash University, McMahons Road, Frankston, Vic 3199, Australia phone: , fax: , [email protected] A paper appeared in Proceedings of 15th IASTED International Conference on Applied Informatics (IASTED-AI'97), Innsbruck, Austria, February 1997, pages IASTED ACTA PRESS.

2 AN APPROACH TO SOFTWARE CHANGE MANAGEMENT SUPPORT JUN HAN Peninsula School of Computing and Information Technology Monash University, McMahons Road, Frankston, Vic 3199, Australia phone: , fax: , [email protected] ABSTRACT The process of software change is complex, and needs to be managed and assisted by automated tools. In this paper, we present an approachtosupporting software change management in software engineering environments. The major issues addressed include system representation, impact analysis and change propagation. In this approach, the change management activities are carried out on the original representation of software artifacts in the environment, rather than on a separate system model extracted. This enables assisted change propagation. We use both dependences and properties of software artifacts for impact analysis. Both impact analysis and change propagation areacombination of guided user intervention and automatic processing based on codied change patterns and propagation rules. Keywords: Software change management, tool support, impact analysis, change propagation. 1. INTRODUCTION The development and maintenance of a software system involves a large number of software artifacts, capturing the system's requirements, designs, implementations, testing suites, maintenance records, and so on. For various reasons such as error correction and changed system requirements, changes to these artifacts are often required during the system's initial development and consequentmaintenance. Since the software artifacts are logically related to each other, an initially proposed change may lead to a large number of modications to various artifacts. As such, the processofsoftware change needs to be managed and, if possible, assisted by automated tools. Over the years, we have seeneorts addressing issues related to software change management. They include process models for change management such as Prism [1], frameworks for comparing impact analysis methods [2], specic techniques for change impact analysis and change propagation such as program slicing [3] and program dependence graphs [4, 5, 6], and specic support systems for change management [7, 8, 9, 10]. In this paper, we address the tool support issues for software change management in the context of a software engineering environment [11, 12, 13]. In our approach, the kernel of the software engineering environment serves as a generic tool for change management. The policies and methods for change management in a particular application context can be codied to augment the environment kernel, so that the resulting environment provides the specic change management (as well as other) support as required. As such, this approach recognises the varied needs of different application contexts, which may be due to the nature of the particular system developed, the development methods and languages used, and so on. In the following discussions, we rst introduce a framework for software change management support in our approach, and then present strategies for the major change management issues addressed, including system representation, impact analysis, and change propagation. 2. A FRAMEWORK FOR CHANGE MANAGEMENT SUPPORT As mentioned above, dierent application contexts may require dierent development methods and languages, and may have dierent project management processes. In these varied contexts, the requirements for change management policies and methods as well as tool support change accordingly. For example, a specic tool supporting change impact analysis for programs written in COBOL may not be used in the context of C programs. To meet these varied needs in a more eective manner, we introduce a general framework for change management. This framework is based on a software engineering environment [11, 12, 13] so that the environment features such 1

3 CP IA REP artifacts interactive interactive dependences automatic (rules) automatic (patterns) properties ENVIRONMENT KERNEL FIGURE 1. A CONCEPTUAL ARCHITECTURE OF A CHANGE MANAGEMENT SYSTEM as those for software representation and presentation can be used for change management, provides general mechanisms for software change management such as impact analysis and change propagation models, and allows codication of context-specic change management requirements such as those specic to the development methods and system architectures, to provide the specic change management support as required. Within this framework, our approach provides support for the following three major aspects of software change management: system representation, impact analysis, and change propagation. A high-level conceptual architecture for change management support in our approach is shown in Figure 1. The system representation (REP) requirement is largely met by the environment kernel's existing capability for representing software artifacts, with only minimal extensions. Based on the underlying system representation, impact analysis (IA) employs artifact dependences, artifact properties and change patterns to identify consequent modications. Change propagation (CP) is essentially based on the impact analysis facilities and results with further enhancement in terms of making changes, including change propagation rules. The details of these major major components for change management are explained below. 3. SYSTEM REPRESENTATION Fundamental to any software change management system is the representation of software artifacts and their dependences. All issues of change management will be based on this underlying system representation. In the context of a proposed change, the software artifacts are objects of modication, and their dependences are among the means to realise the impact and propagation of modications. In addition, we also make use of the consistency properties of software artifacts and dependences for change management. While not usually addressed in the literature as such, the use of consistency properties provides additional exibility and expressiveness in specifying and managing change activities. In particular, they can be used to determine the impact of introducing or deleting a software artifact in the context of a proposed change (in the sense of maintaining their consistency). As in most software tools, we use syntax trees to represent software artifacts and use an augmented EBNF notation to dene their syntactic structures [12]. For example, a design document developed in the Booch method [14] may include a class diagram, state transition diagrams, and some other diagrams. A class diagram may include classes and other entities. DesignDoc = ClassDiagSpec f STD g... ClassDiagSpec = f Class g... An implementation document in C++ may include C++ classes, type declarations, and so on. ImpDoc = f ImpClass g f TypeDec g... The relationships (or dependences) between software artifacts or their components can be captured and represented in the environment as structural relations [12]. A structural relation connects one artifact (or component) to another artifact (or component). The relations are dened in terms of the connected artifacts (or components). For example, a Booch design class may have its own state transition diagram, there are relationships between the declaration and use of C++ types, and there are also relationships between the corresponding design and implementation classes. hasstd = <Class, STD> typetouse = <TypeDec, ImpClass...> hasimp = <Class, ImpClass> Additional structural properties or constraints may apply to software artifacts and their relationships as to their consistency [15]. For example, we may state that for a development to be complete, there must be an implementation class for each design class. propdilink = total(hasimp Class) Note that the above system representation for change management are in fact readily available as developed and maintained in the software engineering environment. Therefore, there is no extracted system model required. Impact analysis and change propagation can be performed on the actual software artifacts. The only additional issue to be considered is to nominate the artifact granularitylevel and restrict the relationships and properties for impact analysis and change propagation (since the actual representation in the environmentmayhave a ner granularity and may have relationships and properties for other purposes).

4 4. IMPACT ANALYSIS An essential part of software change management is to predict the system-wide impact of a change request before actually carrying out all the required modications to the system { impact analysis, sothat appropriate decisions related to the change request can be made, such as planning, scheduling and resourcing. From an initial set of modications derived from the change request, change impact analysis identies all the estimated consequent modications across the entire system, based on the dependence relationships and the consistency properties. Because of the varied situations captured by the dependences and consistency properties, the set of estimated consequent modications may contain those that are actually not required [2]. To make the estimated change set closer to the actual change set, our approach facilitates (1) automatic determination through codied change patterns (for well-dened cases) and (2) interactive determination by the user (for the rest). The object of a modication is a software artifact (or component), or a dependence. The types of possible modications for an object are update, introduction and deletion. Therefore, a modication is characterised by a pair: (obj m type), where obj is the object of modication and m type is the type of modication. For an initiating modication (obj I m type I ), the potential objects of immediate impact are the objects that are involved with obj I in dependences, properties, derived dependences, or derived properties. The cases based on derived dependences or properties capture the situations where a potential consequent impact can not be directly captured by a dened dependence or property. In general, these situations can be captured by a change pattern. Change patterns can be used (1) to characterise derived dependences and properties, and (2) to resolve whether a potential consequent modication is an actual one. Achange pattern takes the following format: fmod I 1 mod I 2 :::g!fmod C 1 mod C 2 :::g : exp B which states that the initiating modications mod Ij (j =1 2 :::) will together result in modications mod Ck (k =1 2 :::) if and only if the Boolean expression exp B is true. In general, the Boolean expression states the relationship among or properties about, the objects involved. For a potential consequent modication (identi- ed based on either dependences, properties, or derived dependences and properties), in general, the environment will rst try to nd a matching change pattern. If found, the pattern is applied and the potential consequent modication is resolved. Otherwise, the scenario is presented to the user for resolution. Upon completion of impact analysis, we are left with a set of identied actual modications (required) together with the impact relationships between them. If an update is required for a design class in the above example, the support environment will identify its state transition diagram as a potentially impacted object according to the hasstd dependence between them. When presented to the user, it can be conrmed or eliminated. When a new design class needs to be introduced, the environment will identify the need to introduce a corresponding implementation class as a potential impact for user resolution, which is based on the dened property propdilink. To identify the impact that an update on a design class's state transition diagram will cause an update on its implementation class, we may introduce the following change pattern: f(a : STD update)g!f(b : ImpClass update)g : (c b) 2 hasimp ^ (c a) 2 hasstd With this change pattern, the environment will automatically conrm the impact. 5. CHANGE PROPAGATION We refer to the process of actually carrying out the initial and consequent modications as change propagation. In terms of management, making the initial modications is straightforward. The challenges come from making the consequent modications to re-establish system consistency. The basic tool support would involve advising the user the artifacts to be modied and the types and order of the modications. This can be based on the impact analysis result. The simplest way to carry out the modications is to follow the impact relationships between the identied modications. For example, we may rst update a state transition diagram and then update the related implementation classes in the scenario captured by the change pattern given above. In certain well-dened cases, the change process can be further assisted by codifying rules for change propagation in the environment and letting the environment carry out some of the consequent modications automatically upon the completion of their initiating modications. These rules are similar to change patterns, but with an additional action component for making the consequent modications. For example, we may realise the eect of introducing an implementation class caused by introducing its corresponding design class in two steps: (1) introduce automatically askeleton for the implementation class as well as the hasimp dependence between the classes, and (2) let the user ll in the class details in an update. The rst

5 step can be codied in the following rule: f(a : Class introduction)g! fmod :(b : ImpClass introduction) (r : hasimp introduction)g : < a r b > by begin b = introimpclass() introrel(a b hasimp) intromod(b "update" mod) end where introimpclass is a function for introducing a skeleton implementation class, introrel is a primitive function for introducing a relationship, and intromod is a function for introducing a new modication, (b update), which is related to the initiating modication mod. In general, therefore, change propagation is realised through a combination of rule-based automatic change propagation and tool-guided user intervention. 6. CONCLUSIONS In this paper we have introduced an approach to providing software change management support in software engineering environments. In clear contrast to existing approaches, our approach directly uses the environment representation of software artifacts and their dependences, so that no extracted system representation is required and automated change propagation becomes possible. In addition to dependences, we have also used properties about software artifacts and dependences for impact analysis, to achieve greater exibility and expressiveness. Both the impact analysis and change propagation employ a combination of automatic process (based on change patterns and propagation rules) and guided user intervention. We are currently planning to implement the approach in our software engineering environment, so that it can be easily tailored for various application contexts. REFERENCES [1] N.H. Madhavji. The Prism model of changes. In Proc. of 13th Intl. Conf. on Software Engineering, Austin, USA, 1991, 166{177. [2] R.S. Arnald and S.A. Bohner. Impact analysis { towards a framework for comparison. In Proc. of 1993 Intl. Conf. on Software Maintenance, Montreal, Canada, 1993, 292{301. [3] M. Weiser. Program slicing. IEEE Trans. on Software Engineering, SE-10(4), 1984, 352{357. [4] A. Podgurski and L.A. Clarke. A formal model of program dependences and its implication for software testing, debugging, and maintenance. IEEE Trans. on Software Engineering, SE-16(9), 1990, 965{979. [5] J.P. Loyall and S.A. Mathisen. Using dependence analysis to support the software maintenance process. In Proc. of 1993 Intl. Conf. on Software Maintenance, Montreal, Canada, 1993, 282{291. [6] R. Al-Zoubi and Prakash. A. Program view generation and change analysis using attributed dependence graphs. Software Maintenance: Research and Practice, 7, 1995, 239{261. [7] G. Kaiser, P. Feiler, and S. Popovic. Intelligent assistance for software development and maintenance. IEEE Software, 5(3), 1988, 40{49. [8] G. Avellis. CASE support for software evolution: A dependency approach to control the change process. In Proc. of Fifth Intl. Workshop on Computer-Aided Software Engineering, Montreal, Canada, 1992, 62{73. [9] K. Gondow, T. Imaizumi, Y. Shinoda, and T. Katayama. Change management and consistency maintenance in software development environments using object oriented attribute grammars. In Proc. of First JSSST Intl. Sym. on Object Technologies for Advanced Software, Kanazawa, Japan, 1993, 75{94. [10] S. Barros, Th. Bodhuin, et al. Supporting impact analysis: A semi-automated technique and associated tool. In Proc. of 1995 Intl. Conf. on Software Maintenance, Nice, France, 1995, 42{51. [11] J. Welsh and J. Han. Software documents: Concepts and tools. Software Concepts and Tools, 15(1), 1994, 12{25. [12] J. Han. Software documents, their relationships and properties. In Proc. of 1st Asia-Pacic Software Engineering Conf., Tokyo, Japan, 1994, 102{111. [13] J. Han. A document-based approach to software engineering environments. In Proc. of 5th Intl. CASE Sym., Changsha, China, 1995, 128{133. [14] G Booch. Object-Oriented Design with Applications. (Benjamin/Cummings, second edition, 1994). [15] J. Han. Specifying the structural properties of software documents. Journal of Computing and Information, 1, 1995, 1333{1351.