With The aid of Andre, we finished creating the TypeDeclaration virtual
association in MooseChef (see also
http://moose-dev.97923.n3.nabble.com/Several-modifications-to-MooseChef-tp3…).
We also created a queryIncoming/OutgoingDependencies that will gather
all dependencies from a model:
allAssociations (real association from Famix) + TypeDeclarations
(virtual association that is "hidden" like the type of a variable).
The MooseChef documentation should be updated accordingly (see "<added>"
markers for additional stuff):
---
** Primitive queries return associations
Primitive queries return a set of dependencies related to the receiver.
Such dependencies are represented by instances of FAMIXAssociation:
invocations, accesses, inheritances, and references.
<added>
MooseChef also recognizes an association that does not exists as such in
Famix: TypeDeclaration.
It exists only for statically typed languages and relates a variable
(FAMIXStructuralEntity) to its type, or a method to its return type.
<added/>
receiver queryAllIncomingInvocations
querySureIncomingInvocations
queryIncomingAccesses
queryIncomingReferences
queryIncomingInheritances
<added>
queryIncomingTypeDeclarations
<added/>
receiver queryAllOutgoingInvocations
querySureOutgoingInvocations
queryOutgoingAccesses
queryOutgoingReferences
queryOutgoingInheritances
<added>
queryOutgoingTypeDeclarations
<added/>
[...]
Some composite queries are also defined on top
static associations = accesses + references + inheritances
sure associations = static + sure invocations
all associations = static + invocations
<added>
dependencies = all associations + typeDeclaration
<added/>
---
There are still some additional hidden dependencies in Famix as
discussed in
http://moose-dev.97923.n3.nabble.com/MooseChef-hidden-dependencies-tp354895…
tests are green (in my image)
nicolas
Hi,
Just to clarify the situation. We have two parsers that are mature enough for large cases studies. They are both closed source:
- VerveineJ: is closed source and it is likely to gain a license that will allow "friends" to use it for free, or something in this direction. At the moment, the sources and the build are available for anyone (although the license is not yet specified). It is mainly built by Nicolas Anquetil (and I helped a bit).
- inFamix: is free to use in any context, but you have to agree with their license usage (so, no real automated download). It is a subset from the inFusion commercial platform. It also supports C/C++. It is built by www.intooitus.com and I helped them a bit, too.
For what they cover, neither is quite complete in the little details, but they are almost there. VerveineJ is slightly better in the coverage of Annotations and a couple of more details (like References). They both export about the same metrics.
I would be interested in working with someone to build a little comparison infrastructure: we take some source code, and we generate a simple diff report on the build server.
It would be important for this community to get a robust solution for Java. I worked quite long on getting both of these mature enough and in evolving FAMIX to support the new language constructs in Java (e.g., Generics and Annotations), and I would still be interested in continuing this enhancement. inFamix also offers C/C++ support, and there one of the major headaches was given by the type alias possibilities, but that is solved now both in FAMIX and in the parser.
>From my experience, the most tedious work in this area is to go through each case study and deal with all the little details not just at the parser level, but also at the meta-model level. We are getting close to a solid solution for Java, but we need to push for the extra mile.
Talking about the meta-model we need to rethink completely the navigation API and be based solely on MooseChef (and possibly Lift). I would be interested in getting people to work with me on this, as well.
Cheers,
Doru
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Status: New
Owner: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal
New issue 808 by guillaum...(a)gmail.com: refresh a GLMRoassalPresentation
http://code.google.com/p/moose-technology/issues/detail?id=808
the update function on GLMRoassalPresentation don't call the painting
block. Consequently the visualization is not refreshed.
Hello,
I have implemented some Arki rules based on Smalllint. For now, there are
20 rules implemented. I also plan to implement more ones.
I am committing such rules into the project LintRules in the
packages OnSmalltalkModel-Report (Smalltalk-only rules),
OnMooseModel-Report (generic rules, ie, Smalltalk and Java)
and OnJavaModel-Report (Java-only rules, empty for now, but we can collect
some rule's idea from FindBugs for example).
Maybe I move them to the package OnMoose-Report, like that it can be
integrated to the moose-on-moose report, what do you think?
best regards,
--
Andre Hora
Hi,
Humane assessment is a method for making software engineering decisions. Assessing software systems to make decisions is a critical activity that needs to be approached explicitly during development. Humane assessment is made possible by the Moose analysis platform.
I am organizing a couple of courses in Bern that might be of interest to people on this list:
Humane Assessment Primer (August 17)
- This course is relevant for both managers and engineers. It covers assessment economics and the means to integrate humane assessment in the development process and in the organization
- http://www.humane-assessment.com/courses/humane-assessment-primer
Moose Apprentice (September 6-7)
- This course is relevant for engineers. This is an introductory hands-on course on using the Moose analysis platform for putting humane assessment into practice
- http://www.humane-assessment.com/courses/moose-apprentice
If you are interested in participating, please contact me directly.
Cheers,
Doru
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
Hi,
I see that there is a bit of an interest in the GTInspector, so here are some extra info about it. Beyond the things you can do out-of-the-box with it, the true power of the inspector comes from its extensibility. The idea is to offer each object an easy way to exhibit its own characteristics. This changes the way you can think of interacting with objects. Some more details here:
http://www.humane-assessment.com/blog/equal-browsing-opportunity-for-every-…
A new feature is the ability to edit code directly in the methods presentation. Combined with the possibility of executing a method in place and previewing the result, this opens the door for a prototype-like programming style.
The GTInspector is part of the Glamorous Toolkit. It is still in its infancy, but I think it shows that there is a great deal of possibilities to improve the IDE and to depart from the what we might think is a given. I am still looking for people interested in joining this effort (remember the idea of the ide taskforce). It would be great to get more people interested in improving this part of Pharo.
Cheers,
Doru
p.s. You can get the Glamorous Inspector in the following ways:
- download the Moose image:
http://www.moosetechnology.org/download/4.7
- download Pharo 1.4 (summer) with the Glamorous Inspector:
http://ci.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessf…
- load it in Pharo 1.4:
Gofer new
squeaksource: 'glamoroust';
package: 'ConfigurationOfGlamoroust';
load.
((Smalltalk at: #ConfigurationOfGlamoroust) project version: #development) load: 'GT-Inspector'
--
www.tudorgirba.com
"Live like you mean it."
Hi!
Just to keep you informed.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The field of software product lines is about managing variations in software configuration. The control software systems installed in a car typically reflect the different options one may want on a car. The space of configuration is often ridiculously large. The system of a BMW line has more different configurations than the amount of atoms the Universe is made of.
Software product lines are classically represented as a tree using a simple visual language. Whereas efficient at specification time, this language has several shortcomings, including poor ability to scale and ineffectiveness at understanding a large description.
An ECOSud project has been granted by both the Chilean and the French national research agencies. The project involves the University of Chile and the Polytech Engineering school in Sophia Antipolis.
The topic of the project is to explore new ways to understand and verify large software product lines specified using the Familiar language [*]. First, a parser has been written using PetitParser. Second, a metamodelisation of the product lines has been made with Moose. The parser creates from a Familiar program an instance of the meta-model we designed. Glamour then gives us a navigation browser for free. Roassal is then used to visually represent a model structure and the result of their associated metrics.
A software product line specification involves many dimensions, e.g., the definition of a feature, interaction between features, constraints between group of features. All those dimensions cannot be effectively simultaneously explored. Roassal supports a large range of interactive visualization mechanisms to make a product line exploration effective.
The ECOSud project has been initiated in June 2012. It enables the mobility of researchers and will span until the end of next year.
Stay tuned!
[*] Familiar: https://nyx.unice.fr/projects/familiar/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I'm trying to define this transmission:
browser transmit to: #one port: #selection; from: #two; transformed: [:x |
x-2 ].
The problem is that #one and #two are not defined in the same browser.
Specifically, #two is defined into a browser that is added to the browser
in which #one is defined usign something like:
a custom: MyBrowser browser.
How can I define the transmission? Thanks in advance,
Cheers,
Santiago
--
Santiago Vidal
Last week Willem and I presented a workshop Visualizing Legacy,
using MOOSE, at SPA2012 in London. In a 150 minutes workshop
we showed how to use glamour and mondrian to visualize the
github repository data from 4 ruby projects and the code used
for these analysis and the workshop itself.
The exercises work toward the creation of a glamour browser with a mondrian
pane showing custom visualizations not achievable by more static tools like Sonar.
The answering of specific questions that arise during the analysis of the data
show the strengths of the MOOSE toolchain.
We started by showing some of the work Diego and I have done for
the conversion of the data of a cobol ERP system to a modern ERP system.
By creating (at least) one browser/visualization a day, we were able to make
the subject matter expert, a very busy senior executive of the company,
steer the conversion process to her satisfaction. By treating her as the
bottleneck, and making it as easy as possible for her to see where we were,
and what we still had to do/understand, she could effectively prioritize and
decide.
Then we asked the participants what they expected/wanted from visualizing
their legacy code. The answers were a mix of things that tools like Sonar
can easily provide, with very specific questions that need a programmable tool
like MOOSE.
As we expected, it took most of the about 14 participants quite a lot of effort and
time to get to grips with the smalltalk environment to work in. So much so,
that some asked for a separate smalltalk workshop to do before this one,
or a larger timeslot for this workshop. The few participants experienced with
Smalltalk had been using VW/VA and also had some problems finding their
way around. In the end, the participants who managed to just follow the
exercises achieved the goals without too much interventions needed.
Inspired by ProfStef, we build a custom glamour browser for the workshop.
The code can be found in the SpaTutorial project on ss3. (The ConfigurationOf…
is no Metacello)
http://ss3.gemstone.com/ss/SpaTutorial
It is split in a generic part, allowing you to create tutorials, and a specific
part for this workshop. We might want to extend it so the exercises can be
done entirely in the custom browser. That might help the smalltalk newbies.
Now the participants needed two class browsers in addition to the tutorial,
one to edit the exercise code, and one to look at the domain model.
We believe the learning curve can be flattened by extending the SpaTutorial
browser so it can save code, and extracting some methods so the tutorial browser
only shows the bits participants have to work on right now,
gradually expanding the scope as it progresses.
It uses the data collected for the SPA2011 great egg-race.
http://chatley.com/posts/06-20-2011/spa-great-egg-race/
Git commit data was collected by Michael Feathers from four ruby projects,
a.o. active_merchant and diaspora. After my holidays I'll put the data in a zip in
https://github.com/StephanEggermont/repodepot-ruby
For the 150 minute timeslot we focused on glamour and mondrian,
although we also prepared an eyesee exercise. Next time we might switch
the exercises around - mondrian looks more glamourous than glamour ;).
A longer version may also be in the works if we can run it somewhere.
It was only after the mondrian exercise that participants could start playing
with the data on their own. Participants indicated they associatied mondrian
more with visualization than glamour.
Stephan Eggermont & Willem van den Ende