当前位置:首页 >> >>

Maintenance and Testing of Object-Oriented Programs Using A Unified Class Dictionary Graph

Maintenance and Testing of Object-Oriented Programs Using A Uni ed Class Dictionary Graph Representation
L. M. Keszenheimer Northeastern University, College of Computer Science Cullinane Hall, 360 Huntington Avenue, Boston MA, USA 02115 seiter@ccs.neu.edu August 17, 1994

The evolution of class structures often has signi cant impact on the maintenace and testing of existing application code. There exist many representations for procedural programs to aid in software testing and maintenance. This paper introduces a model for describing object-oriented programs called a Behavior-Extended Class Dictionary Graph (BCDG ). A BCDG can represent many di erent views of a program to facilitate testing and maintenance. These views include object-oriented extension to the traditional Call Graph, Interprocedural Flow Graph, BLAH BLAH BLAH. A set of transformations on a BCDG are presented. The impact of the transformations on testing and maintenance detailed. Keywords: Class Evolution, Object-Oriented Software Engineering, Software Testing, Software Maintenance.

1 Introduction
The evolution of application domains is a di cult force to manage during software development. Adapting class structures to re ect new application requirements often has a signi cant impact on the maintenance and testing of existing software. It is desirable to automate certain aspects of class optimization, such as the abstraction of common features for reuse through inheritance or delegation, to reduce maintenance and testing costs. It is necessary to de ne a coherent model for the representation of object-oriented programs from which to study the impact of evolution on testing and maintenance. While class transformations have been studied and described ( 17], 5] , 6], 1], 2], 13]), the literature has focused on the evolution of the structural aspects of classes and the corresponding impact on stored objects. The term class evolution has primarily been associated with the evolution of the structural characteristics of classes, their attributes and relations. Recent research has begun to detail the impact class evolution has on existing behavior de nitions. The e ect of class evolution is analyzed in 11], 10], where the impact of modi cations to the class structure on the maintenance of C++ programs is compared to the maintenance of abstract behavior speci cations called propagation patterns 12]. Hursch and Bergstein analyze the maintenance of C++ and CLOS programs due to speci c structural class transformations 4], demonstrating the relative ease of maintaining untyped languages compared to strongly typed ones. Bergstein has also de ned language preserving class transformations 3], demonstrating techniques for maintaining programs given structural transformations to the classes. Thieme and Siebes present an approach to schema integration, based on both structural and behavioral aspects 16]. These approaches primarily have analyzed the impact that structural changes in the attributes and associations of a class have on existing behavioral implementations of a class. This paper extends earlier work 11], 10] on class transformation by examining the evolution of the behavioral apsects of classes. In section 2, a class model called a Behavior-Extended Class Dictionary Graph (BCDG) is introduced upon which transformation primitives will be based. The class model graphically depicts both class 1

structure and behavior. The BCDG representation can be used to represent many views of the system which facilitate testing and maintenance, including object-oriented extensions of traditional Call Graphs, Interprocedural Flow Graphs, BLAHBLAHBLAH. In section 3, a set of primitives are given which de ne Behavior Preserving Class Transformations. These primitives are important in supporting the automation of class optimization to maximize reuse through redundancy reduction. The nal section concludes with a discussion on uses of the BCDG in automation of testing and maintenance techniques.

2 Class Model Notation
The examples presented in this paper are based upon an extended version of the Demeter data model 14]. In the traditional Demeter data model, class structure can be represented by a Class Dictionary Graph 14]. The vertices in the graph represent classes, while the edges in the graph represent class relations.

2.1 Class Dictionary Graph Model
De nition 1: A Class Dictionary Graph ? is a directed graph, ? = (V; ; E ) where
is a nite set of edge labels, describing the names of relations. E = EC EA EC is a relation on V V describing the labeled construction edges: (v ?! w) 2 EC i there is a construction edge with label l from v to w. Class v then has a part, or relation, named l to class w . A construction edge is represented by a labeled single-edge arrow. EA is a relation on V V describing the alternation edges: (v=)w) 2 EA i there is an alternation edge from v to w. Class v then has an alternative, or specialization w . The properties of v are inherited by w . An alternation edge is represented by an unlabeled double-edge arrow. V =VC VA VC is a nite set of construction vertices which describe the instantiable classes. These are represented as rectangles. V C = fvjv 2 V; 8w 2 V : (v =) w) 62 EAg. The construction vertices have no outgoing alternation edges. This follows from the basic rule of inheritance from abstract superclasses. 9]. VA is a nite set of alternation vertices which describe the abstract classes. These are represented as hexagons. V A = fvjv 2 V; 9w 2 V : (v =) w) 2 EAg. The alternation vertices have at least one outgoing alternation edge.

De nition 2:


If a vertex w is alternation-reachable from a vertex v, then w is a derived class of v, inheriting the properties of v. A vertex w is alternation-reachable 14] from a vertex v(v =) w) via a path of length 0, if v=w via a path of length n+1, if 9u 2 V such that (v =) w) 2 EA and u =) w via a path of length n.

De nition 3:


For a given vertex v, the direct and inherited construction edges of v describe it's parts. Parts(v) = f(l; w)j9v0 : v0 =) vand(v0; w; l) 2 EC; w 2 (V A V C )g


A class dictionary graph is considered legal if two conditions hold, it must follow the cycle-free alternation axiom, and the unique-labels axiom.
The cycle-free alternation axiom 14] states there must be no cyclic alternation (inheritance) paths. f(v; w)jv;w 2 (V A V C ); v 6= w; and v =) w =) vg = ;.

De nition 4:

De nition 5:


Figure 1 contains an example class dictionary graph which details the organization of several classes. A Main object contains a part called expr which is an instance of the Expression class. An Expression is either Compound or a Number . A Compound object has three parts, an op , expr1 and expr2 . An Operator is either an AddSymbol or a MulSymbol class instance.
Main expr

The unique labels axiom 14] states that a class can not have two parts, either direct or inherited, with the same label. 8u; v; v0; w; w0 2 (V A V C ); l 2 such that(v =) u); (v0 =) u) and (v; w) 6= (v0; w0) : f(v ?! w); (v0 ?! w0)g 6 EC . 2



Compound expr1 op expr2




Figure 1: Class Dictionary Graph de ning binary expressions.

V = fMain, Expression, Number, Compound, Operator, AddSymbol, MulSymbolg VC = fMain, Number, Compound, AddSymbol, MulSymbolg VA = fExpression, Operatorg EC = f(Main, Expression, expr), (Compound, Operator, op)

(Compound, Expression, expr1), (Compound, Expression, expr2)g EA = f(Expression, Number), (Expression, Compound), (Operator, AddSymbol), (Operator, MulSymbol)g = fexpr, expr1, expr2, opg

2.2 Extended Class Dictionary Graph Model
A Class Dictionary Graph can describe the structural relations between classes. Behavior is typically de ned for a class in a textual manner, either by writing C++ member functions or by describing behavior using Propagation Patterns 12]. Both techniques rely on textual description of class behavior. The Class Dictionary Graph model must be extended to include description of class behavior. This extended model will be referred to as a Behavior-Extended Class Dictionary Graph (BCDG). The information initially provided in a BCDG can be augmented with additional representations that are useful for testing and maintenance. These representations are object-oriented extensions to the traditional Call Graph 15], Interprocedural Flow Graph 8], 7], and System Dependence Graph 7].

De nition 6: A Behavior-Extended Class Dictionary Graph ? is a directed graph, ? = (V; ;E ) where

VA, VC are de ned as for Class Dictionary Graphs. V B is a nite set of method vertices which de ne class behavior. V E = V EA V EM . This set describes the expressions contained in methods. V EA is a nite set of assignment expression vertices. V EM is a nite set of message expression vertices. V V is a nite set of variable usage vertices. V EE is a nite set of variable entry/exit vertices, which are used for representation of interprocedural data ow. These are automatically generated from the initial class structure and behavior, based on formal parameters and return types of methods. V M is a nite set of method name vertices. EA is a relation on ((V A (V A V C )) (V B V B ) (V EE V EE )) describing the structural and behavioral alternation edges. The alternation edges in V A (V A V C ) describe the structural alternation relation as in the class dictionary graph representation. The edges in V B V B describe the behavioral alternation relation, namely the dynamic binding between a virtual method of a superclass and the implemented method in the subclass. The edges in V EE V EE describe the dynamic binding of variable entry/exit nodes used during interprocedural data ow analysis, these are automatically generated from existing information in the graph. These edges show the dynamic binding of formal parameter entry/exit nodes in a base class's method to those in the derived class's method. EC is a relation on (V A V C ) (V A V C V B ) describing the labeled construction edges in the graph. A construction edge describes both the structural and behavioral parts of a class. EL is a relation on V B (V A V C ) which describes variables declared local to methods. EPF is a relation on V B (V A V C ) Integer which describes the ordered formal parameters to methods. EPA is a relation on V EM (V V V EM ) Integer which describes the ordered actual parameters to method calls. ER is a relation on V B (V A V C ) which describes method return type. EF is a relation on (V B V E ) (V E ) which describes the ordered ow of expression evaluation. ED is a relation on V E (V V V EM ) which describes the destination of an assignment or message expression. ES is a relation on V EA (V V V EM ) which describes the source of an assignment expression. EM is a relation on V EM V M which describes which method is being invoked. ECM is a relation on V B V B which describes the call graph among class methods. These edges are generated automatically from the initial class structure and behavior, as are additional edges in V B V B 2 EA which describe the dynamic binding of methods based on the inheritance structure.


ECB is a relation on ((V V

V EM ) V EE ) (V EE (V V V EM )) which describes the call/return binding edges that are automatically generated from the initial class graph to describe the binding of actual arguments to formal parameters. ERB is a relation on (V EE V V ) (V V V EE ) which describe reaching edges that bind entry/exit nodes to their uses for interprocedural data ow analysis. These are also automatically generated from the initial class structure and behavior.

Figure 2 contains a BCDG de ning the class structure and behavior for simple binary expression evaluation. The C + + code which corresponds to the behavior de ned by the BCDG is shown in the upper right corner of Figure 2. The graph contains the initial representation of the program structure, it will subsequently be augmented with information necessary to depict the Call Graph, Interprocedural Flow Graph, and other testing and maintenance representations. A BCDG de nes a simple object-oriented programming language to represent class structure and methods. Assignment and message passing are included in the language. All methods are virtual, with dynamic binding of messages to methods. Parameters are passed by reference. There exist two special variables, this and return . The variable this references the class instance of the method call, the variable return references the class instance that the method evaluates to. There exist several prede ned methods for the Number class, namely add and mult and print . A system models behavior of existing objects, object creation and deletion are not modeled. Additionally, condition ow of control is not modelled, since there will not exist a di erence in testing mechanisms between procedural and object-oriented programs based on conditional ow.


De nition 7:

Given a BCDGAn ?, an expression w 2 V E is ow-reachable from a vertex v 2 V B; (v ; w) via a path of length 1, if 9(v0; w0) 2 EF; v0 = v; w0 = w via a path of length n+1, if 9u 2 V E such that (u; w) 2 EF and v ; u via a path of length n.

De nition 8:


Given a BCDG ?, for each v 2 V A V C; m 2 V B; e 2 V E let

Parts(v) = f(l; w)j9v0 : v0 =) v and (v0; w;l) 2 EC; w 2 (V A V C )g Methods(v) = f(l; w)j9v0 : v0 =) v and (v0; w;l) 2 EC; w 2 V B g Formals(m) = f(l; w; i)j9(m0; w; l; i) 2 EPF; m = m0g Locals(m) = f(l; w)j9(m0; w;l) 2 EL; m = m0g Type(m) = v iff 9(m0; v) 2 ER; m = m0 Class(m) = v iff 9(v; m0; l) 2 EC; m = m0 Expressions(m) = f(w)j(m ; w);w 2 V E g Method(e) = m iffe 2 Expressions(m)

A BCDG is legal if several conditions hold.


De nition 9:

The unique labels axiom is modi ed to include behavior. 8u; v; v0; w; w0 2 (V A V C ); l 2 such that(v =) u); (v0 =) u) and (v; w) 6= (v0; w0) : f(v ?! w); (v0 ?! w0)g 6 EC . A vertex can not have two parts, either direct or inherited, with the same label. f(u; v; l) 2 EC ELj(l 2 (this return))g = ;. f(u; v; l; i) 2 EPF j(l 2 (this return))g = ;. A vertex can not have a part with the label this or return . A method can not have a local variable or formal parameter with the label this or return . 6 9(u; v; l) 2 EC; (u; v0; l) 2 EC : v; v0 2 V B; v 6= v0.

Main eval expr

Main::eval Expression::eval



void Main::eval() {expr?>eval()?>print();} //pure virtual Number* Expression::eval() Number* Number::eval() {return this;} Number* Compound::eval() {return op?>apply(expr1?>eval(),expr2?>eval());} //pure virtual Number* Operator::apply(Number*, Number*) Number* Addsymbol::apply(Number* n1, Number* n2) {return n1?>add(n2);} Number* MulSymbol::apply(Number*n1, Number*n2) {return n1?>mult(n2);}







Compound expr2



op eval apply Operator expr1 eval






Operator::apply Number::eval



F F n12 n2
AddSymbol MulSymbol



Number Number



return apply apply op








AddSumbol::apply MulSumbol::apply


expr2 apply E6




F F 1 n1 2 n2


F F 1 n1 2 n2












return E9






n2 n1


n1 add

n2 mult


Construction Vertex

Expr Id Assignment Expression Vertex


Construction Edge Alternation Edge


Destination Edge Source Edge Message Edge Control Flow Edge Reaching Edge Call/Return Edge


Alternation Vertex

MethodName Method Vertex Expr Id Message Expression Vertex


Local Variable Edge Return Variable Edge

ord ord


label Formal Parameter Edge Actual Parameter Edge


Message Vertex


Variable Vertex


Entry/Exit Vertex Shading Implies Duplicated Graph Object To Facilitate Viewing

Figure 2: Behavior-Extended Class Dictionary Graph describing class structure and behavior for evaluating binary expressions.

A vertex can not have two outgoing construction edges with the same label to di erent method vertices. This implies a class can't have two methods with the same name de ned for it. This does not exclude inheriting a method with the same name as a directly de ned method. 6 9(l; w) 2 Locals(m) such that9(l0; w0) 2 Parts(v); v = Class(m); l = l0; w = w0. 6 9(l; w); (l0; w0) 2 Locals(m) such thatl = l0 6 9(l; w) 2 Locals(m) such that9(l0; w0; i) 2 Formals(m); l = l0. 6 9(l; w; i) 2 Formals(m) such that9(l0; w0) 2 Parts(v); v = Class(m); l = l0; w = w0. 6 9(l; w; i); (l0; w0; j ) 2 Formals(m) such that(l = l0) For a given method, local variables and formal parameter variables must be uniquely named, and can not have the same name as any of the parts of the class the method is attached to.

De nition 10:


TODO:FINISH FORMALIZING THESE: 4. Valid Message Expression: 1 destination edge, 1 message edge, 0+ actual edge. The actual edges are uniquely ordered, starting with 1. Type(destination) has a method with correct name(method), type(method), numformals(method). For each actual, type(actual) <= type(formal). 5. For each method (M) of class C: There exists 0-1 outgoing ow edge. M has 0-1 outgoing return edge. For each variable vertex V in owpath of M, V in PartLabels(C) u FormalLabels(M) u LocalLabels(M) u this u return. 6. For each expression vertex, there exists 0-1 outgoing ow edge.
Main::eval Call Edge Dynamic Binding Edge

Each assignment expression vertex must have exactly one outgoing source edge and one outgoing assignment edge. TODO: TYPE(SOURCE) = TYPE(DESTINATION). 2

8v 2 V EA; 9(v; w) 2 ES; (v; u) 2 ED. 8(v; w) ES; 6 9(v0; w0) 2 ES such that(v 6= v0) 8(v; w) ED; 6 9(v0; w0) 2 ED such that(v 6= v0)

The Valid Assignment Expression axiom states:










Figure 3: Call Graph for Binary Expression BCDG

2.3 Call Graph Representation
The information initially contained in a BCDG can be used to generate a Call Graph . In a call graph, the vertices represent class methods, while the edges represent calls between class methods. A call graph represents the

behavioral structure of a program that can be used for program understanding during maintenance and testing. A call graph is produced on top of the existing BCDG structure. Figure 3 contains the BCDG augmented with call graph information edges. This representation shows both the calls between methods, as well as the alternation relation between a given method de ned for a superclass and the method de ned in the subclass, which calls may be dynamically bound to. While the call graph is useful for determining basic method dependencies, it is insu cient for determining information about data ow between methods. It can not indicate whether the value of parameters remain constant during method calls, or if they could be modi ed. It does not show the ow of return values out of methods. It is necessary to incorporate this ow-sensitive information into the graph. This information can be used for code optimization and parellelization.

2.4 Interprocedural Flow Graph Representation
To represent the ow of objects into and out of methods, it is necessary to develop an object-oriented extension to the traditional interprocedural ow graph 8], 7]. Figure 4 contains the interprocedural ow graph, which depicts the ow of objects across method boundaries. These edges are generated from the existing information in the BCDG . A traditional interprocedural ow graph shows several kinds of edges, binding edges which relate actual and formal parameters, and reaching edges that depict the ow of data between procedure control points (entry, exit, call, return). An interprocedural reaching edge connects call and return nodes to show information about the de nitions and uses of parameters that can reach across procedure boundaries 8]. The interprocedural ow graph representation and its' construction algorithm are not su cient for representation of object-oriented programs. There are several additions which must be made. First, for each method m, entry/exit nodes are added for the variables this and return . Next, alternation edges are added to represent the dynamic binding between entry/exit nodes in the superclass's method and each subclass's method. Also, in addition to the traditional process of adding call/return edges between an actual parameter variable and the formal parameter entry/exit node, an edge is added between actual parameters that are method call expressions and the formal parameter entry/exit node. Call/Return edges are added between the destination object of a method call expression and the entry/exit node the for variable this . Call/Return edges are added between a method call expression and the entry/exit node of the return variable.

3 Behavior Preserving Class Transformations 4 Language Preserving Class Transformations 5 Conclusion

Thanks blah blah blah

1] S. Abiteboul and R. Hull. Restructuring hierarchical database objects. Theoretical Computer Science, 62, 1988. 2] Paul Bergstein. Object-preserving class transformations. In Object-Oriented Programming Systems, Languages and Applications Conference, in Special Issue of SIGPLAN Notices, pages 299{313, Phoenix, Arizona, 1991. ACM Press. SIGPLAN Notices, Vol. 26, 11 (November).

Expression::eval entry

Compound::eval entry this 1 expr1 2 expr2 e7 e6

Operator::apply entry this entry n1 entry n2

AddSymbol::apply entry this entry n1 entry n2 n1 e9

Number::add entry

entry x

e6 exit 1 return 2 E7 e7 E6 n1 exit n2

e9 exit n1 n2

n2 e8 exit return exit this exit

e5 op exit 1 2 return exit return this e4 exit return this exit this exit exit exit return this

x exit return exit

Legend Dynamic Binding Edge Call/Return Binding Edge Reaching Edge Interprocedural Reaching Edge Call/Return Variable Node Entry/Exit Node Call/Return Expression Node

Figure 4: Interprocedural Flow Graph for Binary Expression BCDG

3] Paul L. Bergstein. Managing the evolution of object-oriented systems. Technical report, Northeastern University, 1994. Ph.D. thesis. 4] Paul L. Bergstein and Walter L. Hursch. Maintaining behavioral consistency during schema evolution. pages 176{193, Kanazawa, Japan, November 1993. JSSST. 5] Eduardo Casais. Managing class evolution in object-oriented systems. In Dennis Tsichritzis, editor, Object Management, pages 133{195. Centre Universitaire D'Informatique, Geneve, 1990. 6] Eduardo Casais. An incremental class reorganization approach. In European Conference on Object-Oriented Programming. Springer Verlag, 1992. 7] J. Ferrante, K. Ottenstein, and J.D. Warren. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems, 9(3):319{331, July 1987. 8] Mary Jean Harrold and Brian Malloy. A uni ed interprocedural program representation for a maintenance environment. IEEE Transactions on Software Engineering, 19(6):584{593, June 1993. 9] Walter L. Hursch. Should Superclasses be Abstract? In European Conference on Object-Oriented Programming, Bologna, Italy, July 1994. Springer Verlag, Lecture Notes in Computer Science. To appear. 10] Linda Keszenheimer. Specifying and adapting object behavior during system evolution. In Proceedings of the 8th International Conference on Software Maintenance, pages 254{261. IEEE Computer Society, 1993. 11] Linda Keszenheimer. Utilizing behavioral abstractions to facilitate maintenance during class evolution. In Proceedings of the 6th Conference on Advanced Information Systems Engineering, Utrecht, Netherlands, 1994. Springer Verlag, Lecture Notes in Computer Science. 12] Karl Lieberherr, Cun Xiao, and Ignacio Silva-Lepe. Propagation patterns: Graph-based speci cations of cooperative behavior. Technical Report NU-CCS-91-14, Northeastern University, September 1991. 13] Karl J. Lieberherr, Walter L. Hursch, and Cun Xiao. Object-extending class transformations. Technical Report NU-CCS-91-8, Northeastern University, July 1991. 14] Karl J. Lieberherr and Cun Xiao. Object-oriented software evolution. IEEE Software, pages 313{343, April 1993. 15] B.G. Ryder. Constructing the call graph of a program. IEEE Transactions on Software Engineering, (3):216{ 225, May 1979. 16] Christiaan Thieme and Arno Siebes. Schema integration in object-oriented databases. Proceedings of the Conference on Advanced Information Systems Engineering, 1993. 17] Markus Tresch. A framework for schema evolution by meta object manipulation. In Proceedings of the 3rd International Workshop on Foundations of Models and Languages for Data and Objects, Aigen, Austria, September 1991.

Maintenance and Testing of Object-Oriented Programs Using A ....pdf
Maintenance and Testing of Object-Oriented Programs Using A Unified Class Dictionary Graph_专业资料。The evolution of class structures often has significant ...
Object-Oriented Software Engineering-Ch11E2_图文.ppt
Object-Oriented Software Engineering Practical Software Development using UML and...? Maintenance is simply a type of on-going development. ? Lethbridge/Lagan...
Object-oriented Design_图文.ppt
using selfcontained objects and object classes(自...(语言) Object-Oriented Software Engineering(方法) ...? ? Easier maintenance. Objects may be understood...
software using object oriented paradigm is gaining ... of lines changed per class during maintenance. ...tested on several C sharp programs and and ...
Object-Oriented Analysis and Design_图文.pdf
CS 292 Software Development and Professional ...object classes CS 292 Object Oriented Design 4 ...Easier maintenance. Objects may be understood as ...
Perspective inObject-Oriented Programming_图文.ppt
Perspective inObject-Oriented Programming_医学_高等...of a PatternTM ?Rigidity in pattern maintenance ...pattern Limitations on Use in Software TM Pattern...
Object-Oriented Design.pdf
Object-Oriented Design_专业资料。Make some guesses...Heap Memory used by an executing program is ... saves time for development and maintenance ...
Smalltalk class - day 1 - UIUC Smalltalk Archive_图文.ppt
Programs organized by classes, inheritance hierarchies and subsystems Object-...maintenance - fixing/extending your model Object-oriented programming and ...
Testing Object-Oriented Programs Making it Simple.pdf
Testing Object-Oriented Programs Making it Simple_...class accessed using a multiple assignment notation... and reduces the cost of software maintenance. ...
The problematics of testing object-oriented software.pdf
c testing for object-oriented software: “Both testing and maintenance are simpli?ed by an objectoriented approach, but the traditional methods used in ...
incremental testing of a....pdf
Incremental testing of adaptive software_专业资料。Class evolution can have significant impact on the maintenance and testing of an object-oriented application....
Maintenance of Object-Oriented C++ Software A Protocol Study_....pdf
one program required the construction of an additional class, another ...maintenance using this method also naturally studies object-oriented programming...
...for Concurrent Object-Oriented Software Maintenance.pdf
object-oriented program, and can be used as an...program slicing, debugging, testing, maintenance, ...dicult than understanding sequential object-...
Metrics-based evaluation of object-oriented software ....pdf
KEY WORDS: software measurement, object-oriented ...use of class libraries (/Lee et al 94/), ... the basis model in the maintenance phase is ...
Context-driven Testing of Object-oriented Systems.pdf
Context-driven Testing of Object-oriented Systems_..., program integration, and software maintenance. ...using a subsumption hierarchy, a qualitative ...
A. Risk-based Object Oriented Testing.pdf
A. Risk-based Object Oriented Testing_专业资料。...software will be used as well as a thorough ...design and therefore maintenance is more difficult....
Using object-oriented metrics for automatic design flaws in ....pdf
object-oriented software metrics for the automatic ...maintenance effort, class hierarchy layout and ...A Unified Framework for Cohesion Measurement in ...
its metadata are duplicated in several LOs, maintenance and updates are ...ned by a hierarchy of classes using ObjectOriented Programming (OOP) ...
Chapter 1 - Introduction to the Object-Oriented Approach_图文....ppt
Speed the program development process, improve maintenance and enhances ...objectOriented Approach 3.Introducing C# The class Keyword Is used to ...
programs that have been developed using a ...One of the most prominent maintenance objectives ...classes in object-oriented systems and change ...

All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。