quick Phase D questions

0 views
Skip to first unread message

MJ

unread,
Apr 1, 2005, 11:38:37 PM4/1/05
to JCVSR...@googlegroups.com
Hi David and group 11,

First of all, well done, your project is very professional.

Secondly, we have chosen your project for our phase D, and as we are
trying to extend it with the required metrics, the following question
comes to mind, and I think you would be able to save us time.

According to some of the new metrics we have to add, there are some
new "denominations" we have to report on. By that I mean, per FILE, per
CLASS, per INTERFACE ..etc, whereas your project currently only
displays per time and per developer.

So my question is how did you guys intend for us to extend this
capability, is it through SQL statements that provide new denominations
(which implies these SQL statements would get huge and complicated, and
we would then use them for cvs and java metrics alike), or is it by
imitating the style you used to extend your code with the 'per
developer' capability (which implies that we have to dive into your
actual implementation and code, and possibly change many classes here
and there).

Thanx alot for your time and reply,
Sincerely,
MJ

David James

unread,
Apr 2, 2005, 12:31:51 AM4/2/05
to JCVSR...@googlegroups.com
> First of all, well done, your project is very professional.
Thanks!!

> According to some of the new metrics we have to add, there are some
> new "denominations" we have to report on. By that I mean, per FILE, per
> CLASS, per INTERFACE ..etc, whereas your project currently only
> displays per time and per developer.
>
> So my question is how did you guys intend for us to extend this
> capability, is it through SQL statements that provide new denominations
> (which implies these SQL statements would get huge and complicated, and
> we would then use them for cvs and java metrics alike), or is it by
> imitating the style you used to extend your code with the 'per
> developer' capability (which implies that we have to dive into your
> actual implementation and code, and possibly change many classes here
> and there).

I'd recommend the second approach. The most flexible way to show
metrics per class, per file, per interface, etc. would be to implement
a class that could graph the 'relationship' between any two metrics.
To graph the number of imports per class, you'd want to graph the
relationship between the number of imports vs. the number of classes.

Now how would you graph the relationship between two metrics?
Currently, JCVSReport can show the relationship between two metrics by
graphing them side by side. We use this approach for a number of our
graphs (e.g. coupling, code complexity, test size). If you want to do
something more advanced, you'll need to write some Java code.

Cheers,

David
Reply all
Reply to author
Forward
0 new messages