An MVC-based Analysis of Object-Oriented System Prototyping
for Banking Related GUI Applications– Correlationship between OO Metrics and Efforts for Requirement Change –Satoru Uehara, Osamu Mizuno, Yumi Itou and Tohru Kikuno
Department of Informatics and Mathematical Science,
Graduate School of Engineering Science, Osaka University, Japan
fs-uehara, o-mizuno, itou, kikunog@ics.es.osaka-u.ac.jp

Abstract
In this paper we analyze statistically the efforts for C++
program modification which is needed by a given requirementchange during the prototyping development of a certain GUI
application. In the analysis we consider both C++ program
P to be updated and the resultant C++ program P 0 , and discuss the correlation between the values M(P ) of the ObjectOriented metrics obtained from P and the efforts E(P 0 ) needed to produce P 0 . According to the definitions of M(P ) andE(P 0 ), we present two approaches in this paper.
In the first approach, we take M(P ) as the value obtained byapplying the metrics to the whole source code P and E(P 0 ) as
the lines of codes(LOC) that are actually modified or created,
respectively. However, the experimental result cannot show
strong correlation between M(P ) and E(P 0 ).
Based on the analysis results of the first approach, we propose the second approach to consider the object-oriented properties more directly. The analysis process consists of following
three steps: 1) take only the classes in P , classify them according to the MVC paradigm originally for Smalltalk theirfunctions, and then evaluate M(P ) for the classified classes,
2) in order to evaluate the efforts for code modification, defineE(P 0 ) as the heuristic value which is calculated empiricallyfrom the numbers of methods and members created or modified, and 3) analyze the relationship between the values ofM(P ) on the classified classes in P and the values of E(P 0 )on the source codes in P 0 . From the experimental result, we
can prove there exists a high correlation between them.

1 Introduction
In order to manage the software development, a large numberof methodologies and techniques have already been proposed.
For realizing high quality and productivity of the software,
the Object-Oriented(OO) paradigm has been attracted, and

it is widely utilized into practice. As a matter of fact, theobject-oriented paradigm has high capabilities to handle large
systems, change them, reuse the part of systems, and so on,which are important factor to assure the quality of the productand the productivity of the development team.
Until now, various approaches have been presented as guidelines and actually unique graphical notations for deriving
the object-oriented design, such as OMT[13] and Booch’s
method[2] have already been proposed. Additionally, a large
number of object-oriented programming languages such as Smalltalk, C++, Objective-C and Java have been introduced.
They of course implemented the object oriented properties
such as class, encapsulation, inheritance, polymorphism, andso on. Thus they can make it easy to utilize the object-oriented
paradigm into actual software development process. Recently, object-oriented approach is often used because it is very
compatible with operating systems which have event driven
architecture and Graphical User Interface(GUI), such as Windows.
On the other hand, in order to evaluate and support the
OO development, the object-oriented metrics have been introduced, since the traditional software metrics were not appropriate for applying the OO development. The OO metrics areevaluated and newly proposed in much research[5, 7, 9].
While applying the OO paradigm into practical use, theprototyping development is more applicable rather than traditional waterfall model. The prototyping development canreveal the customer’s requirement into the product, and it iscompatible to the OO paradigm.
In the prototyping development, the first product is developed(including design, coding and test) based on the initial
and thus incomplete requirement of the customer. Then the
product is delivered to the customer and checked by them. The
customer returns the changes in requirements to the developers. The developer performs the development to reflect therequirement. These process iterated until the customer satisfies the product or the deadline of delivery comes. Thus, it isimportant to estimate the efforts to update the product for the
prototyping development, when the changes in requirement
are returned from the customer. The adequate estimation will
make the prototyping development to be more productive one.

2 Motivation
2.1

Prototyping

Figure 1 shows an outline of typical prototyping process[6].
Therefore, we set the goal of our study as finding the prac- Generally speaking, the prototyping development proceeds
tical method to estimate accurately the efforts for updating consists of the rapid interactions between customers and dethe program. However, in order to establish the estimating velopers. One of specific characteristics of the prototyping is
methodology, we must analyze the relationship among the de- there are not complete specifications during the development.
velopers, the environments, the source codes, the metrics, and The developers design and implement the product based on
so on. In this paper, we perform the analysis of the first step the customers’ requirements, and deliver the prototype of program to the customers. The customers try to test the prototype,toward the final goal.
and return the changes of requirements to the developers. The
In this paper, we investigate the activities for updating the loop is iterated until the customers satisfy the program.
program due to changes of requirements. We consider the
program P before updating and the program P 0 after updating,
Initialand investigate the correlation between the values of metrics
Requirements
M(P ) which is measured from P , and the amounts of efforts
E(P 0 ) which is calculated from P 0 . Based on the definitions
DesignChange inof M(P ) and E(P 0 ), we present two approaches in this paper.
Requirement

Implementation

In the first approach, we take M(P ) as the value obtainedby applying the OO metrics to the whole source code P andE(P 0 ) as the lines of codes(LOC) that are actually modified or
created. However, the experimental result cannot show strong
correlation between M(P ) and E(P 0 ), since LOC does notconsider the object-oriented characteristics and the application
to the whole source code is too vague to conclude any specificproperties.
Based on the results of the first approach, we propose thesecond approach to consider the object-oriented properties
more directly. The key idea of second approach is as follows:
1) take the classes in P , classify them according to their functions using the MVC paradigm[4, 12], and then evaluate M(P )for the classified classes, 2) in order to evaluate the efforts forcode modification, define E(P 0 ) as the heuristic value whichis calculated empirically from the numbers of methods andmembers created or modified. We also consider the creationand modification of the classes separately.

Test

Program

Test

Final Program
CustomerDeveloper

Figure 1. General prototyping development process

During the prototyping development, the productivity ofdevelopment team is one of the most important factor, because
the product have to be delivered to the customers as soon as
possible. Thus, the estimation of the efforts on the prototyping
development is an essential problem from the management
point of view.
Generally speaking, it is very natual and easy to combine
theprototyping development and object-oriented developmenThen we measure the values of M(P ) for each classifiedt.
Becausethe object-oriented paradigm makes it easy to unclasses Model, View and Controller. Finally we propose thederstandthesystem structure and reuse the previous compoformulas which can reflect the difficulties for updating. From
nents
of
other
systems, and developers can deliver the productthe experimental result, we can prove there exists a high corrapidly
using
the
advantages of object-oriented development.
relation between them.
This paper is organized as follows: Section 2 shows the
motivation of our study. Section 3 explains the development
process and the OO metrics which are used in this study. Section 4 shows the first analysis based on the legacy metric, andthe result of it. Section 5 describes the key idea of this study
and Section 6 shows the second analysis. Finally, Section 7
summarizes the main results and the future research work.

2.2

Efforts Estimation

Numerous studies have been done with the estimation on thesoftware development process. Basili et al. have proposed
the framework to predict the fault-proneness of the classes
by using the object-oriented metrics[1, 3]. Since their aim isto estimate the quality, we cannot use their result directly toour objective. On the other hand, Kusumoto et al. developed
a simulator to estimate the efforts and faults of the software
project[8]. However, their simulator was targeted to the standard waterfall model, so it is hard to apply to the prototyping
development. Therefore we have to establish a new method toestimate the efforts for the object-oriented prototyping development.
Figure 2 shows a certain situation of the prototyping development. In this situation, we have a certain version of program
P and requirement change  from the customers, and we wantto estimate the efforts needed to update the program P into P 0
according to  .

Program P

Design &Implementation

Change inrequirements d

3 Process and Metrics
3.1

Software Development Process

Figure 3 shows the software development process actuallyadopted in the target project. The project is a development ofbanking related application. The platform of the program was
Windows 95/NT, and development environment was Microsoft
Visual C++. For the development, the OO development was
performed according to the OMT.
Then we adopted a typical prototyping development process. Three developers were engaged in the initial design, andtwo of them took part in the successive prototyping development. During the prototyping, since the customers’ requirement was changed twice, the development was iterated forthree times. Finally, three versions of program P1 , P2 and P3
were generated.

InitialRequirements

Test

Program P'

Test

Design &Implementation
P1

Developer

Test

First
Development

Design &Implementation

Changes in
Requirements

Figure 2. Estimation of the efforts

Test

P2

Test

SecondDevelopment

We can formulate this estimation as follows:E ort (P ! P ) = est(P; ; ")0

where " is the environment factor such as developers, tools,
and so on. In this study, we consider that both  and " areconstant for simplicity. One of the reasons is that less complex
method is required to use in the actual development field. Thenthe estimation formula is transformed as follows:E ort (P ! P ) = est(P )0

We use the object-oriented metrics measured on program P
to establish the function est(P ).

2.3 Objectives

Design &Implementation

Changes in
Requirements
Test

P3

Third
Development

Test

Final Program P3
CustomerDeveloper

Figure 3. Development process
A change in requirement shown in Fig.3 consists of small
requirement changes. For each small requirement change, theclasses in the program are modified and/or created. Furthermore each change can be identified by the comments on the
program.

As mentioned in the previous subsection, the final goal of ourstudy is the estimation of the efforts. In order to establish
3.2 Object-oriented metrics
the effort estimation method, the objective of this study is toanalyze the relationship between the metrics measured before In the object-oriented development, we can point out some
updating the program P and the efforts needed to update the factors which are related to the amount of efforts for updating
program P into P 0 . For convenience, we denote the metrics the program.
measured on the program P as M(P ), and the efforts needed Complexity of the class definition.
to update the program P into P 0 as E(P 0 ). According to the0
Generally, the more complex the class is, the more effort
definitions of M(P ) and E(P ), we present two approaches inis needed to modify it. There are various metrics tothis paper.

show the complexity of the class. Among them, wechoose the weighted methods per class WMC, the depthof inheritance DIT and the number of children NOC.

WMC = Interaction of the classes.
Interacting the other object by message passing is oneof important characteristics of the OO paradigm. However, if there are too many coupled classes in a class, it
is difficult to modify the class because there are many
classes which are affected by the modification. Thus wechoose the metric CBO. Similarly, we consider that theinteraction between the methods in the same class might
affect the efforts. Thus we choose the metric LCOM.

Table 1. Evaluation of metrics
WMC
14
11
9
21
15
5
13
6
22
11
6
21
7
3
2
5
5
5
5
7
5
5
10
9
9
8
8
15
18
17
21
15
17
11
10
17
18
10
16
17
6
39
17

DIT
1
1
1
1
1
1
1
1
1
1
1
1
3
4
5
6
6
6
4
5
6
6
4
4
4
4
4
4
5
4
4
4
5
6
6
4
4
6
4
4
4
3
4

NOC
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

CBO
5
2
5
4
5
3
6
3
3
6
3
3
9
2
1
2
2
2
5
4
2
2
7
8
11
8
7
15
11
14
20
12
11
9
8
20
15
8
15
13
28
19
12

LCOM
33
37
10
140
55
4
40
9
121
27
9
144
19
3
1
10
10
10
8
21
10
10
35
20
22
14
14
73
123
64
98
75
104
55
39
88
63
39
94
64
15
619
136

1) WMC (Weighted Methods per Class)
WMC is the total complexity of weighted methods perclass.
Consider a class C with n methods M1 ; 1 1 1 ; Mn that are
defined in the class. Let ci be the complexity of a Method
Mi :

i=1

ci

For simplicity, we assume that all the method complexities are unity (ci = 1). Thus WMC actually shows thenumber of methods n.
2) DIT (Depth of Inheritance Tree)
Depth of inheritance of the class is the DIT metric forthe class:In the following, we explain the definition of metrics to be
used. These metrics are originally defined in [5]:

Class
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
C15
C16
C17
C18
C19
C20
C21
C22
C23
C24
C25
C26
C27
C28
C29
C30
C31
C32
C33
C34
C35
C36
C37
C38
C39
C40
C41
C42
C43

n
X

DIT = the number of super-classes
3) NOC (Number Of Children)
NOC is a measure of how many subclasses are going toinherit the methods of the parent class:NOC=

the number of immediate subclasses
subordinated to a class in the class hierarchy

4) CBO (Coupling Between Object classes)
CBO for a class is a count of the number of other classes
to which it is coupled.
Consider a class which has m member variables
1 1 1 ; Am and n methods M1 ; 1 1 1 ; Mn . CBO can be
expressed as follows:

A1 ;CBO = jfOg [ fR1 g [ fR2 g [ 1 1 1 [ fRn gj
where fOg is a set of classes which is defined as a typeof member variables A1 ; 1 1 1 ; Am , and fRi g is a set ofclasses called by method Mi .
5) LCOM (Lack of COhesion in Methods)
LCOM is the cohesion between methods.
Consider a class C with n methods M1 ; 1 1 1 Mn . Let fIi g
be a set of instance variables used by method Mi . Let
P = f(Ii ; Ij )jIi \ Ij = g and Q = f(Ii ; Ij )jIi \ Ij 6=
g. Then LCOM can be expressed as follows:

LCOM =jP j 0 jQj if jP j > jQj
0otherwise

Then we apply the OO metrics to the program P . Table 1
shows the values of metrics for each class.

Development Process

First Analysis
M(P1)- WMC(Ci)- DIT(Ci)- NOC(Ci)- CBO(Ci)- LCOM(Ci)Program P1
700

De(U v e l
pd op
at m
in e ng) tChange inrequirements d

600
500
400
300

Program P3

200

Developer

R 2 = 0.0054

100

E(P3)

0
0

100

200

300

- LOC(Ci)Figure 4. Outline of first analysis

3.3 Other data
Table 2 shows the resultant data of the target project. At first,
the prototype program P1 had 43 classes and the size wasabout 6.3KLOC1 . After two successive requirement changes,
the number of classes increases to 58, and the size becomes
about 8.9KLOC.

Table 2. Characteristics of programs
Version # of classes
P1
43
P2
53
P3
58

LOC(Pi )
6295
7765
8925

modified and created LOC(Ci ) in the modified class Ci . Then,
we count LOC(Ci ) for each class Ci in the program P 0 :LOC(Ci )=lines of codes which are modified or createdin class Ci

Here, we use the notation M(Ci ) to represent the OO metrics
measured from the class Ci in the program P . Then we consider the correlation between M(Ci ) and E(Ci ). For example,
Fig. 4 shows the correlation between the metric LCOM(Ci )and LOC(Ci ).

4.2

Experimental Result

Table 3 shows the result of analysis. The correlation coefficients between the OO metrics(WMC, DIT, NOC, CBO andLCOM) and LOC(Ci ), respectively, are shown in it.

4 First Analysis
4.1 Outline
Figure 4 shows the outline of the first analysis. We analyze
the correlation between the OO metrics M(P ) and the efforts
E(P 0 ). In the analysis below, for simplicity, we compoundthe development process by combining the second and third
developments in Fig. 3 into one development.
Here, we introduce the notation E(Ci ) to represent the efforts needed to modify the class Ci in P 0 . In the first analysis,
we assume the efforts E(Ci ) as the lines of codes which are
1 Hereafter, the value of LOC implies the lines of code excluding thecomments.

Table 3. Correlation coefficients for LOC(Ci )Correlation
coefficient

WMC

DIT

NOC CBO LCOM

0.21

-0.02

0.05

0.12

0.07

As the result of analysis, we can say that there are not
any specific high correlations between the OO metrics M(Ci )and LOC(Ci ). Here, we discuss the reasons of the result.
First, it is not adequate to consider LOC as efforts needed
to modify the OO programs, because LOC cannot consider
the OO characteristics in the program. Second, it can be said
that the metrics obtained from the whole program were tooscattered to get any specific characteristics from them. In creating a member variable could be the most difficult work,order to solve the problems found in the first analysis, we have because if the type of new member variable is the other class,to introduce some new idea.
it is inevitable to refer the definition, structure and how to use.

5 Key Idea

5.2.2

Formulas for efforts (create)

In the case of creating a new class, we can measure the amountof creating efforts from the program P 0 , but we cannot comIn order to classify the classes, we use the MVC paradigm[4, pare it with any metrics on the program P because a new class12]. In the MVC paradigm, the user’s input, the modeling did not exist on P . However, it must not be ignored since theof the external world, and the visual feedback to the user are creation of the class is important factor of the OO developexplicitly separated as three types of functions: Model, View ment. Thus we try to introduce the substitute measure which
and Controller. The Model manages the behavior and data can be compared with created new class.
of the application domain, responds to requests for information about its state, and responds to instructions to change
state. The View manages the graphical and/or textual output
Program P
to the portion of the bitmapped display that is allocated to its
C1
C2
application. Finally, the Controller interprets the mouse and
C3
Design &keyboard inputs from the user, commanding the model and/or
Implementation
Change in
the view to change appropriately.
requirements d
Since it is said that the MVC paradigm is suitable to theProgram P'
development of the GUI application, we apply it to our proC2
C1
Test
gram and classify all the classes into three types. We expect
C3
C4
that the properties of the classes are emphasized to extract theDeveloper
correlations between the OO metrics M(Ci ) and the efforts
C and C are modified classes.
C is newly created class.
E(Ci ).

5.1 Classifications of classes[4,12]

2

3

4

5.2 Empirically calculated efforts
From the result of the first analysis, we have to investigate
the other efforts metric but LOC. Thus we introduce a new
metric to measure the amount of efforts needed to update theprograms. We consider two cases of updating the program:
modification of the existing classes and creation of the newclasses.
5.2.1 Formulas for efforts (modify)
In the case of modifying the existing class Ci , we calculate
the efforts of modification as follows:
E(Ci jmodify ) = w1 2 mbc + w2 2 mtm + w3 2 mtc
where mbc is the number of member variables which are newly
created on Ci , mtm is the number of methods which aremodified, mtc is the number of methods which are newly
created, and w1 , w2 and w3 are the weighting constants. In
this study, we determine these constants as (w1 ; w2 ; w3 ) =(5; 1; 2). The weighting is currently based on the experienceof developers. The developers in the target OO development
consider that modifying a method is an easy work because it
may not affect other parts of program. On the other hand,creating a method seems to be more difficult, since they haveto refer the class definition or the other class. Additionally,

Figure 5. Related modified classes
In Fig. 5, consider a certain requirement change  on the
program P . In order to reflect the requirement change into P ,we have to create a new class C4 and modify two classes C2and C3 at the same time. Here we define a set of C2 and C3 as
the related classes with C4 with respect to the change  , anddenote them as a set rel-C4 .
Then we define the M(rel-Ci ), which denotes the OO metrics measured from the related classes in P .
M(rel-Ci ) =X

Cj belong to rel-Ci

M(Cj )

Then we calculate the efforts of creating the class Ci as
follows:
E(Ci jcreate ) = w1 2 mbc + w3 2 mtc+w1 2 rel-mbc + w2 2 rel-mtm + w3 2 rel-mtc
where rel-mbc denotes the number of member variables which
are newly created in the related classes rel-Ci , rel-mtm denotes the number of methods which are modified in rel-Ci ,and rel-mtc denotes the number of methods which are createdin rel-Ci .

Development Process

Second Analysis
M(Contoroller)- WMC(Ci)- DIT(Ci)- NOC(Ci)- CBO(Ci)- LCOM(Ci)Program P1
Change inrequirements dDe(U v e l
pd op
at m
in e n
g) t

700
600
500

R 2 = 0.5693

400
300

Program P3
Developer

200

E(Controller)

100- E(Ci|modify)- E(Ci|create)

0
0

20

40

60

80

Figure 6. Outline of second analysis

6 Second Analysis

5.2.3 Validation of formulas

In order to verify the validity of the formulas above, we ana- Based on the key idea shown in Section 5, we perform thelyze the correlation between the difficulty of the classes and second analysis.
the value of the proposed metric by the Spearman’s rank correlation. Here we only show the validation of the formula for
6.1 Outline
efforts of modification.
Here, we explain the outline of the second analysis. In theanalysis, we introduce two key factors. At first, we classify all
the classes into three types: Model, View and Controller. In
Table 4. Heuristic ranking of difficulty
Table 1, the classes C1 to C13 are Model classes, C14 to C27 andClass Rank
Class Rank
C28 to C43 are classified as View and Controller, respectively.
C1
18
12.5
C32
C4
3
5.5
C33
Next, for each class, i.e. Controller, we investigate the correC5
7
C34
2
lation between the OO metrics M(Controller ) and the efforts
C7
10
C35
19
E(Controller ). Figure 6 shows an example of the analysis
C9
14
C36
12.5
C15
5.5
C37
15
for the Controller class, where we choose E(Ci jmodify ) for
C28
17
C39
9
X axis and LCOM(Ci ) for Y axis. The correlation coefficient
C29
20
C41
16
was
calculated as 0.75.
C30
4
C42
11
C31

8

C43

1

6.2
First, we interviewed the developers of target project, andasked them to rank all the classes in program P by the difficulty
to modify. Table 4 shows the ranking of difficulty for each
modified class. Table 5, to be given in subsection 6.2, shows
the caluculated efforts by the proposed weighting formula.
Then we perform the rank correlation analysis for the data in
Table 4 and Table 5. As the result of analysis, the Spearman’srank correlation coefficient was 0.86. Thus, we can say thatthe proposed weighting formulae have a certain degree ofvalidation.

Experimental Result

Now we show the experimental results for two cases: modification of classes and creation of classes.
First, Table 5 shows the values of mbc , mtm , mtc andcalculated efforts E(Ci jmodify ) for each modified class.
Table 6 shows correlation coefficients between OO metrics
M(Ci )(WMC, DIT, NOC, CBO and LCOM,) and the efforts
for modification E(Ci jmodify ). It is shown that the Controller
class has high correlation with WMC and LCOM(the valuesof coefficients are 0.64 and 0.75, respectively). Figure 7 showssome typical scattered graphs of Controller class.

mbc
1
0
3
0
1
0
1
0
0
0
0
3
0
0
0
0
0
0
12
6

mtm
1
0
6
0
1
0
2
1
1
1
0
4
4
1
2
0
1
1
0
14

mtc
3
6
15
1
2
1
1
0
2
2
1
5
0
2
1
3
1
0
4
6

E(Ci |modify)
12
12
51
2
10
2
9
1
5
5
2
29
4
5
4
6
3
1
68
56

LCOM(Ci)

Class
C1
C4
C5
C7
C9
C15
C28
C29
C30
C31
C32
C33
C34
C35
C36
C37
C39
C41
C42
C43

700
600
500
R2 = 0.5693

400
300
200
100
0
0

10

20

30

40

50

60

70

E(Ci|modify)

WMC(Ci)Table 5. Calculated efforts (Case of modification)

45
40
35
R2 = 0.4091

30
25
20
15
10

Table 6. Correlation coefficient for E(Ci jmodify )WMC DIT NOC CBO LCOM
Model
-0.14 ------0.04 -0.16
View---------------Controller 0.64 -0.36 ---0.00 0.75
All
0.53 -0.23 -0.15 0.00 0.64

Next, we investigate the case of class creation. Table 7
shows the values of rel-mbc , rel-mtm , rel-mtc and calculated
efforts E(Ci jcreate ) for each created class.
Table 8 shows the correlation coefficients between the efforts of class creation E(Ci jcreate ) and the OO metrics ofrelated modified classes M(rel-Ci ). It can be seen that relatively high correlations exist between them, especially for
View and Controller classes. Figure 8 shows some typicalscattered graphs for View class.

6.3 Discussions
From the result of the analyses, we can say that there are acertain extent of correlations between the OO metrics M(Ci )and the newly defined efforts of modification E(Ci ). Especially, in case of creating classes, we can see relatively highcorrelations between them. For the classification of the classes, it can be seen that the Controller class has high tendency tocorrelate with the OO metrics, especially WMC and LCOM.

7 Conclusion
In this paper, we investigated the relationship between the OO
metrics M(P ) and the efforts E(P 0 ) for updating the program

5
0
0

10

20

30

40

50

60

70

E(Ci|modify)

Figure 7. Scattered graph for the Controller(case of modification)in the prototyping development. For the analysis, we madetwo approaches, and we can show some successful results inthe second approach.
However, the result of the analysis might be a little bit
limited. Especially, we must investigate the generalizationof the weighting constant(currently determined heuristically)
and the OO metrics itselves.
Considering the problems above, we summarize our future
work as follows: We have to apply the analysis to other projects.
 The weighting formula shown in Section 5 have to beinvestigated its validity much more.

 For the choice of OO metrics, we have to examine theother metrics.

 Finally, we should establish the estimating method from
M(P ) to E(P 0 ).

References[1] V. R. Basili, L. C. Briand and W. L. Melo: “A Validation of Object-Oriented Design Metrics as Quality

4
1
1
1
4
0
0
6
1
3
6
6
4
1
1

13
4
3
4
3
1
0
7
4
6
7
7
3
3
0

8
8
7
8
8
0
2
5
5
2
5
5
8
7
5

mbc mtc
1
1
1
1
1
0
1
10
4
6
5
8
3
3
1

4
4
4
3
3
6
3
11
7
11
9
11
17
15
13

E(Ci |create)
52
38
35
36
50
13
15
119
53
77
90
109
88
67
46

LCOM(rel-Ci)

rel-mbc rel-mtm rel-mtc

1400

R2 = 0.8279

1200
1000
800
600
400
200
0
0

50

100

WMC(rel-Ci)

Table 7. Calculated efforts (Case of creation)
Class
C44
C45
C46
C47
C48
C49
C50
C51
C52
C53
C54
C55
C56
C57
C58

140

150

E(Ci|create)

R2 = 0.8847

120
100

Table 8. Correlation coefficient for E(Ci jcreate )WMC DIT NOC CBO LCOM
Model
-0.35 ------0.35 -0.35
View
0.94 0.91 -0.45 0.97 0.90
Controller 0.87 -0.87 -0.87 0.87 0.87
0.82 0.78 -0.37 0.90 0.78
All

Indicators,” IEEE Transactions of Software Engineering, Vol.22, No.10, pp.751–761, 1996.

80
60
40
20
0
0

20

40

60

80

100

120

140

E(Ci|create)

Figure 8. Scattered graph for the View (case ofcreation)[2] G. Booch: Object Oriented Analysis and Design With
Applications, The Benjamin/Cummings, 1994.
[3] L. C. Briand, J. Daly, V. Porter and J. Wüst: “Predicting
Fault-Prone Classes with Design Measures in ObjectOriented Systems,” Proc. 9th International Symposium on Software Reliability Engineering(ISSRE’98),
pp.334–343, 1998.
[4] S. Burbeck: “Applications Programming in Smalltalk80(TM): How to use Model-View-Controller (MVC),”
http://st-www.cs.uiuc.edu/users/smarch/stdocs/mvc.html, 1992.
[5] S. R. Chidamber and C. F. Kemerer: “A Metrics Suite for Object Oriented Design”, IEEE Transactions
on Software Engineering, Vol.20, No.6, pp.476–493,
1994.
[6] J. Martin: Rapid Application Development, Macmillan
Publishing Company, 1991
[7] E. M. Kim: “Program Complexity Metric and safety Verification Method for Object-oriented Software
Development,” PhD. Dissertation, Osaka University,
January, 1997.

[8] S. Kusumoto, O. Mizuno, Y. Hirayama, T. Kikuno,
Y. Takagi and K. Sakamoto: “A New Project Simulator Based on Generalized Stochastic Petri-Net,” Proc.
19th International Conference on Software Engineering(ICSE’97), pp.293–303, 1997.
[9] W. Li and S. Henry: “Object-oriented Metrics That
Predict Maintainability,” Journal of Systems and Software, Vol.23, pp.111–122, 1993.
[10] M. Lorenz and J. Kidd: Object Oriented Software Metrics, Prentice Hall, 1994.
[11] K. H. Möller and D. J. Paulish: Software Metrics,
Chapman & Hall, 1993.
[12] L. J. Pinson and W. S. Wiener: An Introduction to
Object-Oriented Programming and Smalltalk, Addison
Wesley, 1988.
[13] J. Rumbaugh: Object-Oriented Modeling and Design,
Prentice Hall, 1991.