Re: discuss Digest, Vol 47, Issue 14

Hi !!

I am doing research paper on "Clustering Algorithm in Aspect Mining", can
some body can help me.

regards

S Kotrappa


On 8/31/07, [email protected] <[email protected]> wrote:
>
> Send discuss mailing list submissions to
>        [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://aosd.net/mailman/listinfo/discuss_aosd.net
> or, via email, send a message with subject or body 'help' to
>        [email protected]
>
> You can reach the person managing the list at
>        [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of discuss digest..."
>
>
> Today's Topics:
>
>   1. Re: Metrics for Aspect-orientd Modelling (Andrew Carton)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 31 Aug 2007 01:20:48 +0100
> From: Andrew Carton <[email protected]>
> Subject: Re: [aosd-discuss] Metrics for Aspect-orientd Modelling
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
>
> I've changed my mind on this. I think the solution lies more in the
> model-driven domain than the aspect-oriented domain.
>
> Comparing AO + OO is like comparing apples and oranges ;) In fact,
> not even, -  its like comparing a granny smith apple with a valencia
> orange. There are too many variations of source-code / modelling
> languages to compare against and it is difficult to define a metric
> for a new variation.
>
> There is no common representation for two grammars (source-code
> languages) to compare. At the moment, it is semi-formal. In model-
> driven development, we have a meta-metamodel for the formal
> definition of metamodels. Since there is a common foundation, there
> is at least some grounds for a set of metrics to be derived for
> comparing two meta-models and then models. So now we can compare our
> apples and oranges maybe in terms of "properties of a fruit" ? You
> could have a meta-rule saying "Variety A of Fruit B has more sugar
> than Variety C of Fruit D, therefore it is sweeter". You could also
> define formally what sugar means or what sweet means. I think this is
> where the state-of-the-art in metrics is going anyway from what i've
> read?
>
> I found the below paper interesting. It talks about evaluating
> maintainability from a domain-specific point-of-view. They argue that
> maintainability metrics based on source code are not applicable to
> models. They then apply the Goal-Question-Metric approach to define
> their own evaluation / metric system. I found this really interesting
> because rather than retro-fitting the existing metrics and trying to
> derive something from these (like i previously was doing), you define
> your own evaluation scheme and this is more suitable for what you
> want to evaluate. Does anyone have an opinion on this?
>
> Evaluation of Maintainability of Model-driven Persistency Techniques,
> Thomas Goldschmidt, Jochen Winzen, Ralf Reussner
> http://www.sciences.univ-nantes.fr/MoDSE2007/p14.pdf
>
> Regards,
> andrew.
>
>
> D? hAoine, 24 L?nasa 2007 10:31, scr?obh Andrew Carton,
>
> > I am in a similar situation and need to compare an AO vs. an OO
> > model. From my brief introduction to this topic, I think this is an
> > interesting and very challenging exercise for a number of reasons.
> >
> > First, I believe the level of abstraction is important. If modelling
> > at a high level of abstraction, the models are not going to be
> > computationally complete, so the comparison is only valid if they are
> > only equally as detailed as each other. Generally, the metrics out
> > there give guidelines on what the numbers mean - are these numbers
> > still applicable when working at a different level of abstraction
> > than code? I think not!
> >
> > Second, I think the next challenge is deciding how to map these
> > metrics from code to metamodel artefacts. If using the UML, I think
> > an activity diagram is very good for something like mccabes
> > cyclomatic complexity because it is similar to a control-flow graph.
> > Other metrics aren't so easy, like lines of code, Halstead complexity
> > metrics or those that depend on counting code level artefacts need to
> > be redefined and reinterpreted, for that specific metamodel.
> >
> > Third, add AO and its slew of metrics into the mix further
> > exacerbates these problems. The new metrics need to mapped to your
> > chosen AOM and how that is represented (metamodel or Profile right?).
> > Most automated metric tools out there run over aspectj. You also have
> > to assume there is a correlation between these metrics and your AOM
> > (maybe your AOM supports different types/levels symmetry?), and then
> > from these to the OO metrics.
> >
> > In the end, I think you just have to state the assumptions, be
> > consistent in applying the metrics and derive an argument from the
> > observation of the results? Easiest approach if using a low-level
> > abstraction is just to transform to code and use the tools to do the
> > dirty work. I think metrics are pretty silly anyways...
> >
> > This works on an OO UML model and may be useful to be adapted.
> > http://www.eclipse.org/m2m/atl/usecases/ModelsMeasurement/
> >
> > There is also a workshop for MoDELS "Model Size Metrics" that has
> > some interesting stuff!
> >
> > Regards,
> > andrew.
> >
> >
> >
> > D?ardaoin, 23 L?nasa 2007 13:57, scr?obh Jaroslav Svacina,
> >
> >> Hello,
> >> Are you aware of any metrics for aspect-oriented modelling. My
> >> purpose
> >> is to compare one design of an application using object-oriented
> >> models
> >> with another design of that application with aspect-oriented
> >> models. I
> >> would be grateful if you could point me to works in that area.
> >>
> >> Best regards,
> >>    Jaroslav Svacina
> >>
> >> --
> >> Dipl.-Inf. Jaroslav Svacina
> >> Tel.: +49 (0)30 6392 1908
> >> E-Mail: [email protected]
> >>
> >> Fraunhofer-Institut fuer Rechnerarchitektur und Softwaretechnik,
> >> FIRST
> >> Kekulestra?e 7
> >> D - 12489 Berlin
> >> Germany
> >> http://www.first.fraunhofer.de
> >>
> >>
> >> _______________________________________________
> >> discuss mailing list    -    [email protected]
> >>
> >> To unsubscribe and change options, go to:
> >> http://aosd.net/mailman/listinfo/discuss_aosd.net
> >>
> >> Check out the AOSD.net Wiki: http://aosd.net/wiki
> >
> >
> > _______________________________________________
> > discuss mailing list    -    [email protected]
> >
> > To unsubscribe and change options, go to:
> > http://aosd.net/mailman/listinfo/discuss_aosd.net
> >
> > Check out the AOSD.net Wiki: http://aosd.net/wiki
>
>
>
>
> ------------------------------
>
> __________________________________________________
> AOSD Discuss mailing list    -    [email protected]
> To unsubscribe go to http://aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>
>
>
> End of discuss Digest, Vol 47, Issue 14
> ***************************************
>



-- 
Prof S Kotrappa
Assistant Prof,
Department of CSE/MCA
KLES's College of Engg., & Technology
Belgaum-India.

_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki