Hi,
not really, mainly because the projects we have are not all at that
level of abstraction: analyzing a big class to cut it into pieces is not
the same thing as understanding a big system as a whole.
But we are indeed interested in what your students may have to propose :-)
nicolas
On 16/02/2017 12:08, Abdelghani Alidra wrote:
Hi Nicolas,
On 15 Feb 2017, at 12:00,
moose-dev-request(a)list.inf.unibe.ch
<mailto:moose-dev-request@list.inf.unibe.ch> wrote:
Message: 1
Date: Tue, 14 Feb 2017 12:10:54 +0100
From: Nicolas Anquetil <nicolas.anquetil(a)inria.fr
<mailto:nicolas.anquetil@inria.fr>>
To: Moose-related development <moose-dev(a)list.inf.unibe.ch
<mailto:moose-dev@list.inf.unibe.ch>>
Subject: [Moose-dev] Re: software reingineering guidelines
Message-ID: <f856fa35-917e-0a5a-a84c-41d89ebe83ac(a)inria.fr
<mailto:f856fa35-917e-0a5a-a84c-41d89ebe83ac@inria.fr>>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Abdou,
not that I know of.
Moose provides the tools, the engineers must provide the "intelligence",
the processus to extract needed informatino.
We currently have a project with Master students along these lines, but
they did not deliver it yet, so no experience result yet neither.
I was thinking that people from Synectic (for instance) could have
some valuable experience in this field (where to start from, a list of
what to look for, how to look for it, the different reports, …)
We recommended using Roassal (and explained how to use it) to try to get
an understanding of the “architecture”
Yes, and use the queries to gets different
metrics about the projects.
maybe detect some (anti) patterns...
Actually, asking them to explain HOW they got their results (As well as
WHAT results they got) could be interesting
Definitely, this is part of the objectives too :)
Maybe we could produce a sorte of practical guide to code analysis
with Moose.
nicolas