2 Jul
2007
2 Jul
'07
4:28 p.m.
On Mon, 2007-07-02 at 15:51 +0200, Tudor Girba wrote:
Excellent. I added it to the wiki.
I noticed you use Measurement.
We used to have Measurement as well, but this proved to induce a lot
of overhead because we ended up with tons of Measurement objects in
memory. As a consequence in our current FAMIX, we store measurements/
properties as attributes directly in the entity Class. For example,
for number of methods, we would have a FAMIX.Class.NOM attribute,
while you would have a Measurement object.
Would it be a problem for you if you would adapt your tools to not
have explicit entities for Measurements?
Let me first clarify this design decision:
- As we are working with tuples in Crocopath, changing the
representation as well as adding additional measurements in the future
(which is likely to happen) requires changing all our querying scripts
every time.
- Secondly, some measurements (Coupling & Cohesion) are calculated as a
post processing step. Being a seperate entity, it is easy to append them
to the fact base.
This means that it was pure convenience to implement it like that.
However, there is a difference in what constitutes our meta-model and
how we put in in a certain file format (read RSF, or, MSE). The
presented meta-model is extracted from our RSF representation. Producing
MSE with 'inline' measurements is not a problem for us. Therefore, if
you want to make it an attribute of the respective entities that's fine
for us.
Another option that you might consider is gathering measurements per
entity in a QuantitativeData entity - which would only double the amount
of objects in the system at most.
cheers,
Bart
Cheers,
Doru
On Jul 2, 2007, at 10:29 AM, Bart Van Rompaey wrote:
--
Bart Van Rompaey
Lab On Reengineering
Dept. of Mathematics and Computer Science
University of Antwerp
Office location: CMI - G.2.22
Office phone: +32 3 265 34 05
URL: http://www.win.ua.ac.be/~bvromp
On Sun, 2007-07-01 at 19:35 +0200, Tudor Girba
wrote:
--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/
"No matter how many recipes we'll know, we'll still value a chef."
Hi,
LOOSE Research Group will also participate in the definition of FAMIX
3.0.
Radu, could you give a short overview of MEMORIA? I would say a UML
diagram would do just fine.
The input for the discussion up to this point is given by:
- SCG FAMIX:
http://smallwiki.unibe.ch/moose/famixmetamodel/
- SEAL FAMIX:
http://seal.ifi.unizh.ch/wiki/swiki/show/FamixCore
The UA likes to contribute their meta-model as well:
http://www.win.ua.ac.be/~bdubois/images/metamodel.png
Its a RSF-alike model transformed from FAMIX CDIF.
cheers,
Bart
Cheers,
Doru
--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Bart Van Rompaey
Lab On Reengineering
Dept. of Mathematics and Computer Science
University of Antwerp
Office location: CMI - G.2.22
Office phone: +32 3 265 34 05
URL: http://www.win.ua.ac.be/~bvromp