Key words and phrases: software maintenance, ob ject oriented programming, change analysis, impact identication, regression teating, environment, tool.
Change Impact Identification in Object Oriented Software Maintenance D. Kung, J. Gao, P. Hsia, F. Wen
Y. Toyoshima, and C. Chen
The Univ. of Texas at Arlington P. 0. Box 19015
F'ujitsu Netwmk Tr;Lnsmission Systems, Inc. 3099 North First Street San Jose, CA 95134-2022
Arlington, TX 76019-0015
i
Abstract
by another class. Thus, there are data dependencies, control dependencies, and state behavior dependencies between the two claseee. Moreover, since the inheritance and aggregation relations are transitive r e lations, the above dependencia also are transitive dependencies. Polymorphism and dynamic binding imply that objecte may take more than one form, and the form which an object assumes is unknown until run time. Thin makea the identification of the affected components much more diflicult.
In the object-oriented (00) paradigm, new features (such aa encapsulation, aggregation, inheritance, polymorphism and dynamic binding) introduce new probl e m in soflwan testin and maintenance. One of them ir the d s c u l t y ofidentifying the afected componenk (such as classes) when changes are made in object-oriented class libraries or programs. This paper dircusser the types of code changes in an objectoriented class librury, and rovides an automated solution to identify diffennt Einds of code changes and t h e i r impact. In addition, an 00 soflwan maintenance environment that implements the research result is described. Our ezperience with the environment prototype shows promising results. Key words and phrases: software maintenance, ob ject oriented programming, change analysis, impact identication, regression teating, environment, tool
The maintenance complications introduced by the 00 features can be summarized aa follows: 1) althou h it ia relatively easy to understand m a t of the lata structures and member functions of the object classea, understanding of the combined effect or combined functionality of the member functions ia extremely difficult; 2) the complex relationships between the object classes make it diflicult to anticipate and identify the ripple effect' [SI of changes; 3) the data dependencies, control dependencies, and state behavior dependencies make it difficult to prepare test casea and generate test data to "adequately" retest2 the affected components; 4) the com lex relations ale0 make it difficult to define a cost-efPective test strategy to retest the affected components. This paper discusses types of changea that can be made to an 00 library. It also describes a method for identifying the affected claeaes due to structure chan ea to an object clase library. The method is base% on a reverse en eering approach designed to extract the classea a n g h e i r interrelationships. Thia information ia represented in a multigraph, which ia used to automatically identify the changes and the effects of those changes. The method haa been implemented in the integrated testing and maintenance environment. The arfitecture and functionality of the relevant part will be presented.
1 Introduction One important activity of software maintenance is regreasion testing, which ensures that the modified software still satisfies ita intended requirements. To save effort, regreasion teatin should retest only those parb that are affected by t i e modifications. In traditional functionsriented programming, only control dependencies exist between the modules; hence, it is relatively easy to identify the affected modules. In the objectoriented 00) paradigm, a number of new featurea ia supporte , such as encapsulation, information hiding, inheritance, aggregation, polymorphism, and dynamic binding. These new features introduce new problems in the maintenance phase, including difficulty of identifying the affected components when changes are made.
6
Encapsulation and information hiding imply the socalled "delocalized plan" [19],in which several member functions from possibly several object classea are invoked to achieve an intended functionality. This phenomenon means that chan ea to a member function of a claw may affect many cfassea. Inheritance and aggregation imply structure and state dependent behavior reuse, i.e., the data members, function members, and state dependent behavior of a class are re-used
0-8186-6330-8/94 $04.00 0 1994 IEEE
'The ripple deet r e f a to the phenomenon that &" made to one part of a roftram ryrtem ripple throughout the ayatem. We use this t u m l o d y to mean d a t i n g the software with a certain deof confidence. We choose not to give a formal definition of adequacy in this paper.
202
The organhation of this paper is aa follows: In WOtion 2, a brief review of related work on maintenance of conventional mhware am well aa 00 software ia given. In section 3, we diecuee types of changes and change identification. A formal model is presented to facditate change identification and impact identification, which im described in section 4. In section 5, we de!scribe a support s stem for 00 teating and maintenance. ~n section we report our experience on 00 sofkware maintenance and in section 7, we present the conclusions and future work.
data
i,
2
method atNCtUra change#
Related Work
method component
Hartmann and Robson examined several regression testing strategies, including methods for capturing the program portion which may be affected by maintenance modifications to a conventional program [8]. A eimilar study waa conducted by Leung and White [14] using a formally defined cost model. Laski and Szermer deacribed an algorithm for identifying the affected parb in conventional program maintenance [ll]. The algorithm ia based on differentials between the control flow graphs for the original program and the modified ro am. In [13],impact of data and function changes a%&eseed using a dynamic approach.
change d8ta .ccy rope/mode/uma dd/deletedata
8
D 10 change a control MqU11 dd/d&te/cbange local data
ia clsu component changes
change a mequarial Kgament
19 change a d&d/red&ed method method 14 dd/d&ta a d&ed/red&ed 15 dd/delete/chuya a deAned datum
16 dd/delete a virtual abrtrrt method mode/rcope 1z change an sttribute IC-
18 dd/deleta a r u p e d r u
clsu relatiomhip
E
changes
19 dd/delete a
ao
dd/delete an object pointer
11 dd/delete an .(lgragrkd object
-az
Some conventional program maintenance system have been reported in the literature. The VIFOR iaual Interactive FORtran [17] were developed for ORTRAN programs the asterscope [20] for Interlisp, and the CIA (C Information Abstractors) [3 for C. These system provide editing, browsing, an database supports to a maintainer. In particular, the VIFOR system also provides graphical display and transformations between the textual representation and the graphical representation. ua Wilde and Huitt [23 analyzed problems of dynamic binding, object ependencies, dispersed p r e g a m structure, control of pol morphism, high level understanding and detailed c o l understanding. The authora then provided a general list of recommend+ tions, including the use of de endency analysis [22] and clustering methods [4] [15[ for possible tool s u p port.
r
1
3
changes
d
dd/delete an object meuaga 1s change a dur; (d&ed attributsr) dd/delete a relntioo between cl15 dde/delete a d u and itm relatiom 26 dd/delete an independent dsu
Figure 1: Different Types Of Code Changes
d
and stored the information in a database. A maintainer could query the data base to obtain the desired knowledge to maintain a C++ program. Lejter, Meyers, and Reise diecussed the " l t y of maintaining an 00 software system due to the pres ence of inheritance and dynamic binding 121. The authors then described the XREF/XREF B prote type system that provided text editing and relational data base querying support to facilitate 00 software maintenance. A similar system was described in [16].
6
Crocker and Mayrhauser addressed problems relating to clam hierarch changes, clam signature changes, and polymorphismf5]. The authors then proposed a list of tools to help solve some of the problems. The tools provide information collection, storage, analysis, inference, and display Capabilities.
Our system is similar in many aspects to the above systems. It uses rogram analyzem to collect information and stores t i e information in a data base. It p r e videa both graphical and textual display and brows ing, whereas most of the existing s s t e m provide only textual display and browsing (wit$ VIFOR aa an exception). It ia capable of automatically identifying the changes to an 00 program and deriving the affected parts from the changes. Another difference ia that our system ia integrated with testing capabilities to facilitate regression test case and teat data reuse and generation, result analysis, and report generation.
An early system for maintainin C++ programs waa reported by Samethinger in
[18f The system utilized the inheritance relation and containment relations (e.g., a clam is contained in a file, or a method belongs to a clam, etc.) to provide text-based brows ing facilities to an 00 software maintainer. The C++ Information Abstractors [7Jused p r e g a m analyzere to extract cross-reference information
203
nu:..-
Change Identification
3
One of the major Mcultiea in software maintenance ia to identify chan es and their impact aut+ matically oinee it b very firscult to keep track of the changed when a mftware system ia modified exten. capability becomea sively by reverd p c n ~ ~Thin even more crucial when the modifications are performed by one oup of PUSOM and regreasion test ing b performeflby another group of persona. In thie oection, we lirst d i s c u s the different typea of code changa. We then deacribe how to identify the various typea of code changea.
3.1
m-w
"ypea Of Code Changes 1 provida a classification of code changes in
an %?ana
library. Theee change typea are explained
m follows:
Data change: Any datum (i.e., a lobal variable, a local variable, or a class data member! can be changed by updating ita definition, declaration, access scope, accem mode and initialization. In addition, addmg new data and/or deleting existing data are ale0 considered an data changed.
Figure 2: A BBD for a member function in the I n k Views Library 3.2 Method Change Identification A directed di am,called block-branch dia am (BBD) ia used t o y d t a t e a the understanding o$the member functions and their interfacea and relationahips to the global data, clam data, and other member functions. Figure 2 shown a BBD for a member function of the Interviews library. The various componenta of a BBD ia explained ( ~ 8follows:
Method change: A member function can be changed in various ways. Here we classify them into thra typm: component changes, interfoce changes, and contwl rrtructun changes. Component changes include: 1) adding, deleting, or changmg a predicate, 2) adding, deleting a local data variable, and 3) changing a sequential segment. Structure &an e~ include: 1) adding, deleting, or modifying a bran& or a loop structure, and 2) adding, or deleting a sequential eegment. The interface of a member function consists of ita signature, accea scope and mode, ita interactions with other member functions (for example, a function d). Any change on the interface ia called an interface change of a member function.
0
The large window displays the BBD body, denoted B; it encapnulatea the program graph for the member function'. The upper left window displays the global and class data that are used by the member function; this ia denoted by Du;
0
C h i change: Direct modifications of a clasa can
be clsesified into t h r a t pea: component changes, in-
terface changw and n i t i o n changes. Any change
on a d&ed/redefined member function or a defined data attribute ia known aa a component change. A &an e ia said to be an interface change if it adds, or defetm a defined/red&ed attribute, or chan ea ita mode or scope. A change is said to be a refation change if it adds, or deleter an inheritance, aggregation or seeociation relationship between the c l w and
0
-
0
another clans.
The upper right window displays the input/output parameters, denoted P,of the member function; The bottom left window dieplays the global and dass data that are defined (i.e., U dated) by thin member function; this ia denoted gy Dd; The bottom right window displays functions that are called by thin member function; thin ia d o noted by Fe;
Formally, the block branch diagram for a member function f ia a quintuple
Class library change: Theae include: 1) changing the defined members of a c l w , 2) adding, or deleting a clssr and ita relationships with other classes. 3) adding, or deleting a relationship between two existing daeeea3,4) adding, or deleting an independent clw.
BBD: = (Out Ddr P,Fe, B ) where the components are M defined above. When no confusion can a r k , we will omit the subscript f 'The progun gr8ph EIP be d, unong othen, to genemake brui. path t a t CUQ and t a t d ~ t a(21. However, it L beyond the wope ofthi. papa? to explorsthbkrue.
204
3.4 Clase Change Identiflcation A claas ie a pair C = ( D ~ . j , F h j ) where , D~l.3is a aet of dehed/redefined data attributes, F~l.3ie a set of dehed/red&ed member functions. Let C‘ = (ode!, F i e f ) be a modified version of a el880 c. Then class code change is identified as follows:
h m BED!. A BBD body is formally defined by a directed graph E = (V, E), where V denotes the set of program graph vertiw and E c V x V the directed edga reprssenting the control flowe. For more details the reader is referred to [kung93b]. Let B E D = (Du,Dd,P,Fe,B), and BBD‘ =
- o d e / # 8, then any d E (D&j is a deleted data attribute. if Ddej
-
if o d e ! Ddej # 01 then is an added data attribute. 0
0
if V - V’# 0 then any v E ( V - V‘) is a deleted block node.
0
0
ifV’- V # 0 then any v E (V‘- V) is an added block node.
0
if E-E'# 0 then any e E (E - E ’ )
0
is a deleted
control edge.
0
0
if E ‘ - E # 0 then any e E (E‘-E) is an added control edge.
if Du -nu # 0, then mme data usea are removed.
0
if Du Du # 8, then some data usea are added.
0
if DJ Dd # 0, then some data definitions are removed.
0
0
-
if any d E Dd.3 n D&j ie changed, then a residual data attribute is changed.
-
- FA!) b
-
- Fhj)is
F& # 8, then any f in (Fdef a deleted member function. if Fd.3
if Fie, Fdef # 0, then any f i n (Fief an added member function.
if any f E Fief n F&j is changed, then a residual defined/redehed member function is changed.
v
-
- Dd # 0, then some data definitions are
if added.
if Fe - F: # 0, then some function calls are removed’.
0
-Dbj)
3.5 Class Library Change Identiflcation A class library L is a collection of ORDe. An ORD b an edge labeled directed graph ORD = (V,L,E), where V is the set of nodes representing the ob’ect classea, L = { I , A g , A 8 } is the set of edge lakela (for inheritance, aggregation, and association), and E = EI EAQUEASis the eet of edges. For a detailed de nition and how to reverse code to yield an ORD, the reader is referred to [9 . Ae mentioned earlier, Figure 3 shows the ecreen um of an ORD for part of the InterViews library. In tfe figure, the inheritance and aggre ation relationshi are shown uk ing Rumbau h et 3 ’ s notation, w& association is shown using !hrected arcs. The figure says that World is associated with OptionDeec, and hence dependent on OptionDeac. MonoScene is a part of Sensor, and hence Sensor is dependent on MonoScene. The figure also shows that World is a derived class of Scene, and hence, it is dependent on Scene.
A member function interface change is identified a~ followe: 0
d E (Ode!
- Q~l.3)
if Fe -F: # 0, then some function calla are added.
3.3 Data Change Identiflcation Data change identification is em since the needed information is captured by the BiD’a (and the internal representation) for the member functions6. In particular, information about each data item’s access seope, type, access mode, update set i.e., functions that d e h e the data item and use set \i.e., functions that uee the data item). o identify data change, this information is compared with the information for the al eoftware. If any of the above information is O erent, X the corresponding type of change is identified.
d
Modifications to a library can be classified into
three basic casea, i.e., addm an ORD, deleting an
8.
ORD, and changing an ORD In the first two cases, there is no impact to the other ORD’s, therefore, we will consider only the last case. An ORD can be changed in several wa s: changing the defined members of a clw, addingfdeletin a relation between two existing classes, and adding/$eleting a claas and ita relations. Chanke identification for a eingle class has been discussed m the previous subsection. Here, we focus on structure change of a clam library.
P
Let ORD = (V, L, E) and 0R.D‘ = (V’, L‘, E’) be the ORD’s for two versions of the same software. A structure change in an ORD is
8Sip&umchmget treated U d e l e t i n g a d then adding a tupctioa
not belong to any dau am treated U member Eunctionr d a dummy ryrttam dau in our approach.
‘Note an i.olsted dsu im an ORD.
205
F’igure 3: An ORD for a part of the Interviews Library 0
0
if V’- V # 9 then any w E ( V -V) ia an added dam node. if V - V‘ # 9 then any w E (V V#)ia a deleted node.
-
(c) u t a 4
0
if@ -E # 0 then any e E (6-E) is an added new edge.
0
if E- E‘
# 0 then any e E (E- k)io a deleted
49. 0
if auy v in vn V’h changed, then a residual class m changed.
To facilitate understanding, Figure 4 shows the difh t typa of structure changea for an oRD8.Figu r a 4(a and b) show the two casea in which a new chum no e IO ded inta the ori al O W by inserting a new relation with an reaidufiser. Two casea of a dam deletion are given in Figunr 4(c) and d Notice that if a clam node ir removed from an &I&, then dl relation edga between the dam node and other dama muat be deletd. In Figure 4 e), an existing dation edge ir rsmovcd from two redi ual classes. In Figure 4(f), a new relation edge between two reaidual dsera w added.
6
4
(e)
Delete a dupedent du
Change Impact Identification
After change identification, it io very important to detect the ripple decta of the changea because these changa may affect the ooftware in Merent aspects, including fuuctions, rtructurer, behavior, and performance. Clearly understanding theae ef€ecta not only reducer the c#t of roftwam maintenance but also eavu the repdon tert dort. For example, if we a h h d a p e d d JnsL &a in a cl.w libruy im conridered an ORD. Thw,adding (or dellating) m independent Jnda dudb (or deletas) .pORD.
I
206
Figure 4: Different Structural Changea In An ORD
(c) If the edge b an seeociation edge, then at least one method of dam A must be changed, and hence, A b dfected in thin neenee.
can find all the affected components in the given software, the testers need only to retest these components
instead of all of the components in the software. Thus, it b very important to identify and encloee all the affected componenta after changing a software.
2. Adding a new dependent dam. Clase A b not affected and hence doea not need to be reteated.
Change impact identification includea data chan4e impact identification, method change impact identification, clm change impact identification, and cllibrary change (i.e., dsse relation change) impact identification. Existing rerults, e.g., [13], can be used to identiiy data and method change impacts. A clase firewall concept b introduced in [lo] to encloee all possible af€ected daeeer after moms changes are made in a class. In thin paper, we focus on &an ea of daesee and their nlationrhrp. An automated so ution b given to identify the change impact due to changer of c l w and their relatiomhipa.
3. Deleting a "superclaee" . Thia changea claaa A by removing clam B from clase A's euperclaee or component claaa liet: (a) If the ed e b an inheritance edge, then it reducer tfe inherited members. Thb only af€ecta daw A'r test c a m which related to those removed members. (b) If the edge b an inheritance or aggregation edge, then it reducea the rtatea and tranaitions of claas A (see Figure 4.lb). According to Weyuko's antidecompoeition axiom, we should retest the state behaviors of the modified class A. (c) If the edge ia an seeociation edge, then at least one method of class A muat be changed, and hence, A ie affected in this 8enee.
P
Clasr Library Change Impact Identi-
4.1
flcation The major task of clam librar change impact identification U to find all the A c t e d claaser due to changer of interdam relationships. We use a clase fire wall concept introduced in [lo] to encloee all affected claeeer. The computation of a class firewall b based on the O W for the class library.
4. Deleting a dependent clam. Clam A b not affected.
h rho- in Figure 4, there are six types of structure changes in an ORD. Taking into consideration the dif€erenca in treatin the inheritance, aggregation snd moociation relationskps, the impact on a residual d m b identified as follows:
5. Deleting a relationship between existing classea. This is similar to (c) above. 6. Adding a relationship between exiating claeeee. This ie similar to (a) above.
1. Adding a new %uperclass":
We have diecussed the Merent t es of structure changea of an 00 library. We havexown how nome of the changes affect a residual d m A even though its defined attributer were not changed at all. Thua, dase A should be retested. A reeidual claas like dam A is called an addition affecfcd clam if it b directly affected by any edge addition or dam addition) in an ORD (casea (a) and (I) abovf. Similarly, a reaidual class b called a deletron affected clasr if it is directly affected by any edge deletion (or daas deletion) in an ORD (casea (c) and (e) above).
(a) If the new edge ia an inheritance edge, then it expands A's members. According
to Weyuko'e antidecomposition axiomg, we should r e k t these new inherited members in the context of clam A [24]. In addition, integration testing of dssr A's new inherited membem and its other membem b needed to make sure that they work well together. (b) If the edge b an inheritance or aggregation edge, then it expanda A'r state space in terms of state behavior (see Figure 4.la). That b, ita states and tranaitiona are extended by ita inherited membus from claas B. According to Weyukoe's anticomposition axiomi0, we should retest the state behaviors of class A.
4.2 Class Firewall Generation The basic idea of computing a e l m firewall b described in [lo]. A class firewall b a eet of affected classee when some changea are made in a claas library or an objecboriented program. A binary relation R, derived from an O R D r (V,L,E), b introduced to compute the dasa firewall.
@Themexists. p m g u n P aad component Q luch that T ia dsqrvte for P. T' t t h e ret of vectors of v d u a that vuiabla CUI yully on aptrurco to Q for 1 0 1 ~t. of TIand T' ia not
R = ( < C j , C i > ICi,CjEVAEE)}
for Q. [211 lobartt propun P urd Ql d t a t mt T,much that T
where R is the dependence relation which defines the dependence between clasees, according to the inheritance, aggregation, and association relatione.
i. doquato for P, .Pdthe mt ofvectomofvduen that v u i a b h 0.p ammm on to Q for inpub in T im adequate for Q, but T im pot d e q u t a for P;Q.[P;Q ia the compositionof P and
Q*PI]
207
c
c
m GUI
\
Add Q to P
p*
P
= P'
T t not adequate for Sl+S1
nourcm coda
-TfOrSl+S2
jner/old &on)
&tract graphic model
dlulgeinfonMtion and ripple dst.
T' for S 1
\
Delete Q 6nm P
= P'
Figure 6: The Architecture Of OOTME
P' T m not d e q r u t e for S1 0
The cl- fiewall for addition affected computed M followe:
clansea in
CCFW = {Cj\(W)(3k)((< Cj,C,k > E E' E ) A < C,Cj > E R'*} Figure 5: Changes in Object State Space
where R' in the dependence relation for the modified ORD.
In, lo]! we have proved that for an ORD, if the mo cation a daw library changes a dam C without altering the structure of the ORD,then a class fire wall for C, denoted CCFW(C), can be computed aa followe:
0
d$
CCFW(C)= {CjI < C,Cj > E
The clam fiewall for deletion affected clames ie computed M followe:
CCFW = {Cjl((X)(3L)(( E E E')A < C,Cj >E R")
-
e}
where R' ia the transitive closure of R. That is, if C CilCj >E R and < .cj,ck>E Re, then < Ci,Cr,>E R'. The transitive closure of R can be computed by the famous Warehall algorithm [l]. Let L be I ) claae libr and L' ita modified version. h a m e that ORD = L, E) is an ORD in L and that ORD' = (V', L', E') ita modified version. We define a binary relation & M
(";$:
R = R n (V x V )n (vlx V ) where x in the Cartesian product operation. In other mrC, R, ie the relation which definea the d e pendencia between the residual classes. The class fire rpalb are generated aa follows: e
-
The cl- firewall for a changed clasa C is computed M followe:
Support System
5
The objective of a software maintenance ayetem is to help a software maintainer in: underatanding a given software, identifyin code changes, eupporb ing software updates and enfancement, and detecting change effecta. Therefore, any mftware maintenance system hae to fulfill four unportaut requiremenb. 1) it has to be able to provide the v8riow information about the software, including ita structures, aud the interfaces and relationahips between Merent compe nents at the different levels; 2) it has to provide an acient and user-friendly interface to pr-t the varioua information about software and eupport maintenance activities; and 3) it Ean to be able to identify code changes between Merent software vemiona and their effects. Figure 5 depicts the architecture of an 00 testing and maintenance environment we are currently developing. The components of the environment are described as followe: 0
208
G UI:The GUI in conetructed baaed on Motif and X window software; therefore it ie wer-friendly.
II \
t
daeeee). In addition, it aleo identifiee 26 changed residual clsrula, 16 d b t e d d w , and 4 unaffected daeeee. The detailed wulte u e dnn in k b l a 1 - 3.
Experience Ai& to undenknd an 00 eoftware eyetem, antie ipate apd i d e n w the +te of change! +d facilitate re -on tatmg M dau.ble u p a b d ~ t ~ ofaan 00 6
t
I
14
I
1
A w a r e maintaanca environment. our experience indicatu that it ie extremely time c“iq and La dioue to t a t and maintain an 00 eoftware eyetern. Thia problem becoma even more .cute when d e mentation ie either miming or inulequsts. Coneider, ibr exam le, the Intervim library originally develo ed by &anford U n i d t y . An euly d o n of the li!rary conaieted of 146 fila, more than 140 d m , more than 400 ralationrhi and more than 1,000 member funct~oru. We a h ta t it WM di5cult to obtain a high level of underetandk of the dames. member fun&one, and their relatbkhip. Our b&
Fiyrs 7: Change impact identification 0
Pancr. There am three differeat parsere: the
ORD pamcr, the BBD pareer, and the OSD pareer. The uru can we them to extract information from a d- library. 0
0
0
Dirphycr: There are three Diepla era: the
ORD
Dieplayer, the BBD Dieplayer, anlthe OSD Dik player. The user can use them to dieplay the O m ,B B b , and OSDa, respectively. Change identifier. The change identifier can be d to to find the code chan a between two diff a t V ~ O Mof the name dam library. It can a h be wed to automatically identify the impact d a planned code change to help a maintainer to determine whether the change ehall be carried aut. Finwall generotor: The firewall generator can be all the in a daer library when it pomible affected cl-
d to identify a claer firewall to endm modified. 0
Reg”iom i d took The regmaion test tool condste of a tat rtrakgy generator and a teet caae generator. The t a t etrate generator produma a metdective t u t order each daae m the library [lo]. Thie tat order w i l l be med M a retest aquenca in clam unit tating sad re-integration The tat generator ie used to generate new t a t cams.
-
taw.
We have applied thio tool to many applications, indudiag the Interview8 library. Figure 7 ehowe an exun le lietin of the firewall information for a subset d &e Inter&ewr library. We have ab0 compared the trro OM 3.0 and 3.1) of the Interview8 library wing the 00 ME. It hta all of the difTerencea b o tween there two vUS~OM, including 68 added daeses 76 deleted dsssss, and 46 residual daeees (reused
I,
209
be inatantiated by another clam which can then UIC the capabilitia of the former. To ensue quality of our producte, we often had b retat the entire libuy when major changa wen nude. Softwareengineers in the industry consider the ryb tem useful for tating, maintenance,and rangineuing. The application of the to the Interviewe library, an elevator library, and a PBX pro(psm ehowe that it tadlitatq undentandiug, tat orduing [9][lO erahon for which automatic mpport e t a z a E i n the L t m ) , and d o r t atimation (in terms of extended cydomatic complexity and COCOMO model).
4
The application of the automatic change and change effect identification capabiilitiee to the InterViews library haa produced p’Omi”LLg multe. Bowever, our aprriaacs ie too llmited to draw any cond u s i o ~W . e anticipate that thae upabilitia will be particularly wdul m the maintenauce phaae. Without tool mpport, 000 haa to &ament each change and identify ite impact according to o n d B knowledge of the syskm. Thie ie both time c o b and inaccurate. The tool will reduca c a b eignificantly and improve productivit). in documentation and r e g ” testing by automatically identityiry the chan a and their impact, thue eliminating many errore. Akhough the system ie etill in ite prototyping atage, eeverd companies have a y e d inter+ .in experimenting with the system an we are portrry it to more comp.aicm.
7 Conclusion and Future Work We have d a d b e d the varioue a of code changa
P
of an 00 system and a formd mo el for capturing and inferencing on the changu to identify affected compe nenta. T h e model a d the inference capabilities have
maintenance of object oriented syetemr," to appear in Journal of Object Oriented Programming, 1994.
been implemented in a tool prototype. Experience with an earlier version of the tool shows prormsing r s d t r . An reported elsewhere [10][9], the changed and affected claeser, can be tested m a cost-effective order to avoid d v e construction of test stubs.
(111 J. Laski and W.Szermer, 'Identification of P r e gram Modifications and ita Applications in Software
Maintenance," Proc. IEEE Conference on Software Maintenance, pp. 282 290,1992.
-
Identification of changea and their impact ia only one as ect of ooftware maintenance. We are currently arbm%ng the capabilitiea to include various metria, such tu complexity, object-orientedneoe, and effort, to facilitate the maintenance work. The system ia bein expanded with these new featurea and integrated w i d a tart environment to provide reteating support.
8
[12] M. Lejter, S. Meyere, and S.P.R.eiss, "Support for maintaining object-oriented programs, A IEEE Transactions on Software Engineering 18:1045 - 52 Dec 1992. [13] H. K. N. Leung and L. White, "A study of integration testing and software regremion at the integration level," Proc. IEEE Conf. on Software Maintenance, pp. 290 301,1990.
Acknowledgment
The materid presented in thia paper ia baaed on work rupported by the Texas Advanced Technology Program (Grant No. 003856097), Fujiteu Neb work lkanunieSion Systems, Inc:, Hewlett-Packard Company, and the Software Enweering Center for Teleeommunicationr at UTA.
9
E]
H. K. N. Leung and L. White, "A Cost Model to mpare Regression Test Strategiea," Proc. Conf. Software Maintenance, pp. 201 - 208,1991.
References
[l] A. V. Aho, J. E. hopcroft and J. D. Ullman, Data Structures and Algorithms, AddisomWesley Publication Company, 1983.
a
251nventional S. Liu and N. Wilde, ''Identifring Objeeta in Procedural Language: An Example of
Data Design Recover$' , Proceedings of IEEE Conference on Software Mamtenance, pp. 266 - 271,1990.
4
[16 P. D. O'Bria, D. D. Halbart, and M. F. Kilian, he Trellis programming environment," in Proc. 1987 Conf. ObjecbOriented ProPfamminl: System. Languages and Applications (00PSLA'87)1, p'p. 91 102, Oct. 1987.
Beher, "Software Testing Techniques," 2nd ed.!!%k Hoetrand Reinhold, 1990. [3] Y.-F.Chen, M. Y. Nishimoto, and C. V. Ramamoorthy, "The C information abstract system," IEEE lkw. Software Eng., Vol. 16, pp. 325 - 334, Mar. 1990.
~ , P. Linos, "VI171 V Ra lich, N. D a m a ~ k i n and FOL: a - too for software maintenance: Software:
i
Practice & Experience Vol. 20 pp. 67 - 77, Jan 1990.
[4] S. C. Choi and W.Scacchi, "Extracting and restructuring the deaign of large systems," IEEE SoftWW, Vol. 17, NO. 1, pp. 66 - 71, Jan. 1990.
[l8] J. Sametinser, "A tool for the maintenance of C++ programs, Proc. IEEE Conf. on Software Maintenance, pp. 54 59, 1990.
-
[5] R. T. Crocker and A. v. Mayrhauaer, 'Maintenance Support Neede for Object - Oriented Software," Proc. of COMPSAC'93, pp. 63 - 69, 1993.
I191 E. Soloway et al, "Desi documentation to compensate for delocalized CACM Vol. 31, NO. 11, pp. 1259 1267, NOV. 1988.
9
-
T. Gane and C. Sarson, "Structured System An ysia," McDonnell Douglas, 1982.
[20]W. Teitelman and L. Masinter, T h e Interlisp
[71 1. E. Gram and Y.-F. Chen, "The C++ information abstractor," in UNSENIX C++ Conference. h c . , pp. 265
-
pro ramming environment," IEEE Computer, Vol.
14,fVo. 4, pp. 25
- 277,1990.
- 34, Apr.
1981.
[21] E. J., Weyuker, "The evaluation of pro ambased software teat data adequacy criteria," CfCM, Vol. 31, NO. 6, pp. 668 - 675, 1988.
[8] J. Hartmann and D. J. Robson, "Revdidation During the Software Maintenance Phase," Proc. IEEE Conference on Software Maintenance, pp. 70 - 80, 1989.
[22] N. Wilde, R. Huitt and S. Huitt, "Dependency Analysis Tools: Reusable Components for Software Maintenance", Proc. IEEE Conference on Software Maintenance, pp. 126 - 131, October 1989.
[9] D. Kung, J. Gao, P. Hsia, J. Lin and Y. Toyoehima, "Design Recovery for Software Testing of ObjectOriented Programs," Proc. of the Working Conference on Reverse Engineering, pp. 202 - 211, IEEE Computer Society Prese, 1993.
[23] N. Wilde and R. Huitt, "Maintenance support for object-oriented programs," IEEE Trans. on Software Eng., Vol. 18, No. 12, pp. 1038 - 1044, Dec. 1992.
[lo] D. Kung, J. Gao, P. Hsia, Y.Toyoehima, and C. Chen, "Firewall, regression testing, and eoftware
210
[24] Dewayne E. Perry and Gail E. Kaiser, "Adequate Testing and Objectoriented Programming," January/February JOOP, 1990, class name
clacrs name
class name
clasa name
clasa name
ActiveHandler BoxImpl DialogKitImpl FieldEditorImpl G LContext LayoutLayer M FKit Info MonoKitImpl 0L-Anchor 0L-CheckMark OLSrame OLSushpin OLSpecr 0brerver
Adjustable CoordinateSpace Drag Fields tringEditor Input Handler MFDidogKithpl MFKit MenuItem MonoKit Info OL-Button OL-Dragbox OL-Gauge OL-Pushpinhok OLStepper WidgetKi t h p l
AUocationInfo DebugClyph DragZone FileBrowscrImpl Input Handlerlmpl MFKitFonground Menuhpl MonoKit MenuItem OL-Calk OL-Elevator OL-Indicator OL-Scrollbar OL-Tick Widgcl Kil Overlay
AUocationTable Dialog DragZoneSink FileC h o o u r h p l Layout Kit MFKitFrame MonoKitForegound OLKitImpl OL-Channel OL-ElevatorClyph OLMenuMark OLSetting OL-ToLimit
AUocationTableImpl DialogHandler FieldBut ton FontBoundingBox Layout Ki t Imp1 MFKitImpl MonoKit Frame OLAbbrevMenuBut ton 0 L-CheckBox OL-FieldEditor OLMover OL-Slider 0baervable
Table 1: New added clarrer in InterViewa3.1 c l m name
clasa name
clms name
clam name
clma name
ApplicationW indow Center HMargin LMargin OptionDeac PageMo Possi bleHi tTarget RMargin Resourcehpl SessionRep StyleAttribute
BMargin
BoxAllocation Fixedspan Hit Target Listener PSFont Pattern PrinterInfo Regexp Sensor SimpleCompotsitor StyleWildcard TIFFRarter Tile Transient Window ValueString
BoxComponent HCent er Hit Target Lirt ManagedWindow PSFont h p 1 PointerHandler Printerbp ReqErr Seaaion Stencil St yleWi l d c u d h f o TIFFFbrterhpl TileRevencd VCenter Window
BreakSet HGlue IconWindow Margin
superpose
Target TranaformSetta VMargin X YMarker
DeckInfo HRule LRBox Overlay Patch Printer Raster
Rule Shadow StyleRep TBBox TeXCompdtor Tranaforma VRule
Table 2: Deleted cl-r
Page
Popupwindow Property Data Resource SesaionIOHandler Style StyleWildcardMatchQuality TMargin TopLevelWindow VClue World
from InterViews3.0
clacrs name
class name
class name
class name
class name
(W g g n g a t e (C)Box (C)Composition (C)Font (C)HitImpl (C)TBCompoaition (A)Cwr (A)LRMarker (A)Strut (U)Requiremcnt
(C)Allocation (C)Break (C)Deck (C)FontFamily (C)Im4?e ( A)AggregateMo (A)Discretionary (A)Label (A)VStrut
(C)Background (C)Brush (C)Display (C)Glwh (C)LRComposition (A)Align (A)Glue (A)Layout (U)Allotment
(C)Bitmap (C)Canvar (C)Event ( C )Handler (C)MonoGlyph (A)Character ( A)G roup (A)ShapeOf (U)ArrayCompoaitor
(C)Border (C)Color (C)Extension (C)Hit (C)Requirition ( A)CompoaitionComponent (A)HStrut (A)SP(U )Compoaitor
Table 3: Reused clmaes in InterView3.1
211
+
