reverse engineering of object oriented code

8/13/2019 Reverse Engineering of Object Oriented Code

1/223


2/223


3/223


4/223


5/223


6/223


7/223


8/223


9/223


10/223


11/223


12/223


13/223


14/223


15/223


16/223


17/223


18/223


19/223


20/223


21/223


22/223


23/223


24/223


25/223


26/223


27/223


28/223


29/223


30/223


31/223


32/223


33/223


34/223


35/223


36/223


37/223


38/223


39/223


40/223


41/223


42/223


43/223


44/223


45/223


46/223


47/223


48/223


49/223


50/223


51/223


52/223


53/223

2.6 The eLibProgram 39


54/223

40 2 The Object Flow Graph

and the allocation s left hand side variable,Library.borrowDocument.loan


55/223

, y

(Fig. 2.8 center, edge labeled 60).

An example of a method call with a return value is provided by the first

abstract statement (after the declaration) of methodLibrary. addLoan (see

Fig. 2.7 top, line 42). The left hand side location(Library.addLoan.user)

is the target of an edge outgoing from Loan.getUser.return, the location

associated with the value returned by the method call (see Fig. 2.8 bottom,

edge labeled 42).

Container operations are also responsible for some edges in the OFG of

Fig. 2.8. For example, the body ofUser.addLoan contains just an insertion

statement (line 315). The containerUser.loans, into which aLoan object

is inserted, becomes the target of an edge starting at the inserted object

location, User .addLoan. loan(Fig. 2.8 center, edge labeled 44). This indicates

an object flow from the parameter loanof method addLoaninto the container

User .loans.

The OFG constructed for the code in Fig. 2.6 and 2.7 shows the data

flows through which objects are propagated from location to location. Thus,the parameter userof method borrowDocumentbecomes the current object

(this) inside numberOfLoans,while it is the parameter userinside method

authorizedLoan and it is the parameterusr inside the constructor of class

Loan, as depicted at the top of Fig 2.8. Similarly, the other parameter of

borrowDocument, doc,flows intoisAvailableandauthorizedLoanasthis,

and into the constructor of classLoanas the parameter doc. The object of class

Document returned by Loan.getDocument (bottom-right of Fig. 2.8) flows intothe local variabledocofLibrary. addLoan,and then becomes the current

object (this) insideDocument. addLoan.

2.7 Related Work

The OFG and the related flow propagation algorithms are based on research

conducted on pointer analysis [3, 21, 47, 49, 60, 68, 81, 86]. The aim of pointer

analysis is to obtain a static approximation of any points-to relationship that

may hold at run-time between pointers and program locations. Similarly, when

2.7 Related Work 41

be distinguished by statement or invocation context. Flow/context sensitive


56/223

g y

analyses are defined with reference to the control flow graph [2] of a program,

while flow/context insensitive algorithms define the analysis semantics at the

statement level.The algorithm most similar to ours is [3]. Originally described for the C

language, it has been recently extended to Java [49, 68]. Differently from the

approach followed in this book, no explicit data structure, such as the OFG,

is used in [3] as a support for the flow propagation: data flows are represented

as set-inclusion constraints.

The improvement of a control flow insensitive pointer analysis obtained

by introducing object sensitivity was proposed in [57], where the possibility

of parameterizing the degree of object sensitivity is also discussed.


57/223

This page intentionally left blank

3


58/223

Class Diagram

The class diagram is the most important and most widely used description of

an Object Oriented system. It shows the static structure of the core classes

that are used to build a system. The most relevant features (attributes and

methods) of each class are provided in the class diagram, together with the

optional indication of some of their properties (visibility, type, etc.) . Moreover,

the class diagram shows the relationships that hold among the classes in a

system. This gives a static view of the structural connections that have been

designed to allow communication and interaction among the classes. Thus, the

class diagram provides a very informative summary of many design decisions

about the system s organization.

Recovery of the class diagram from the source code is a difficult task. The

decision about what elements to show/hide profoundly affects the usabilityof the diagram. Moreover, interclass relationships carry semantic information

that cannot be inferred just from the analysis of the code, being strongly

dependent on the domain knowledge and on the design rationale.

A basic algorithm for the recovery of the class diagram can be obtained

by a purely syntactic analysis of the source code, provided that a precise defi-

nition of the interclass relationships is given. For example, an association can

be inferred when a class attribute stores a reference to another class. Oneproblem of the basic algorithm for the recovery of the class diagram is that

declared types are an approximation of the classes actually instantiated in a

program, due to inheritance and interfaces. An OFG based algorithm can be

d fi d t i th f th l di t t d f th d

44 3 Class Diagram

terfaces is discussed in Section 3.2, where an algorithm is provided to improveh l f l i l i Th bl l d h


59/223

the results of a purely syntactic analysis. The problems related to the usageof weakly typed containers and an OFG based algorithm to address them are

described in Section 3.3. Recovery of the class diagram is conducted on theeLibapplication in Section 3.4. Related works are discussed in the last sectionof this chapter.

3.1 Class Diagram Recovery

The elements displayed in a class diagram are the classes in the system underanalysis. Internal class features, such as attributes and methods, can be alsodisplayed. Properties of the displayed features, as, for example, the type ofattributes, the parameters of methods, their visibility and scope (object vs.class scope), can be indicated as well. This information can be directly ob-tained by analyzing the syntax of the source code. Available tools for Object

Oriented design typically offer a facility for the recovery of class diagramsfrom the code, which include this kind of syntactic information.

eLib example

3.1 Class Diagram Recovery 45

erations are in the bottom compartment. The first entry is the constructor,hil h h h d id h d f i li i f hi l


60/223

while the other methods provide the exported functionalities of this class.

Relationships among classes are used to indicate either the presence of ab-straction mechanisms or the possibility of accessing features of another class.Generalization and realization relationships are examples of abstraction mech-anisms commonly used in Object Oriented programming that can be shownin a class diagram. Aggregation, association and dependency relationships are

displayed in a class diagram to indicate that a class has access to resources(attributes or operations) from another class.Ageneralizationrelationship connects two classes when one inherits fea-

tures (attributes and methods) from the other. The subclass can add furtherfeatures and can redefine inherited methods (overriding). Arealizationrela-tionship connects a class to an interface if the class implements all methodsdeclared in the interface. Users of this class are ensured that the operations

in the realized interface are actually available.Generalization and realization relationships satisfy the substitutability

principle: in every place in the program where a location of the super-class/interface type is declared and used, an instance of any sublass/class

realizing the interface can actually occur.

Relationships of access kind hold between pairs of classes each time oneclass possesses a way to reference the other. Conceptually, access relationships

can be categorized by relative strength. A quite strong relationship is theaggregation. A class is related to another class by an aggregation relationship

if the latter is a part-of the former. This means that the existence of anobject of the first class requires that one or more objects of the other classdo also exist, in that they are an integral part of the first object. Participants

in aggregation relationships may have their own independent life, but it is

not possible to conceive the whole (first class) without adding also the parts

(second class). An even stronger relationships is thecomposition.It is a formof aggregation in which the parts and the whole have the same lifetime, inthat the parts, possibly created later, can not survive after the death of thewhole.

46 3 Class Diagram

the dependency) might affect the dependent class. The typical case is a classthat uses resources from another class (e g invoking one of its methods) Of


61/223

that uses resources from another class (e.g., invoking one of its methods). Ofcourse, aggregation and association are subsumed by dependency.

3.1.1 Recovery of the inter-class relationships

From the implementation point of view, there is no substantial differencebetween aggregation and association. Both relationships are typically imple-mented as a class att ribute referencing other objects. Attributes of container

type are used whenever the multiplicity of the target objects is greater thanone. In principle, there would be the possibility to approximately distinguishbetween composition and aggregation, by analyzing the life time of the ref-erenced objects. However, in practice implementations of the two relationvariants have a large overlap.

In the implementation, dependencies that are not associations or aggre-gations can be distinguished from the latter ones because they are accesses

to features of another class performed through program locations that, dif-ferently from class attributes, are less stable. For example, a local variableor a method parameter may be used to access an object of another class andinvoke one of its methods. In such cases, the reference to the accessed object isnot stable, being stored in a temporary variable. Nevertheless, any change inthe target class potentially affects the user class, thus there is a dependency.


62/223


63/223


64/223


65/223


66/223


67/223


68/223


69/223


70/223


71/223


72/223


73/223


74/223


75/223


76/223


77/223


78/223


79/223


80/223


81/223


82/223


83/223


84/223


85/223


86/223


87/223


88/223


89/223


90/223


91/223


92/223


93/223


94/223


95/223


96/223


97/223


98/223


99/223


100/223


101/223


102/223


103/223


104/223


105/223


106/223


107/223


108/223


109/223


110/223


111/223


112/223


113/223


114/223


115/223


116/223


117/223


118/223


119/223


120/223


121/223


122/223


123/223


124/223


125/223


126/223


127/223


128/223


129/223


130/223


131/223


132/223


133/223


134/223


135/223


136/223


137/223


138/223


139/223


140/223


141/223


142/223


143/223


144/223


145/223


146/223


147/223


148/223


149/223


150/223


151/223


152/223


153/223


154/223


155/223


156/223


157/223


158/223


159/223


160/223


161/223


162/223


163/223


164/223


165/223


166/223


167/223


168/223


169/223


170/223


171/223


172/223


173/223


174/223


175/223


176/223


177/223


178/223


179/223


180/223


181/223


182/223


183/223


184/223


185/223


186/223


187/223


188/223


189/223


190/223


191/223


192/223


193/223


194/223


195/223


196/223


197/223


198/223


199/223


200/223


201/223


202/223


203/223


204/223


205/223


206/223


207/223


208/223


209/223


210/223


211/223


212/223


213/223


214/223


215/223


216/223


217/223


218/223


219/223


220/223


221/223


222/223


223/223

reverse engineering of object oriented code

Documents