Two ideas related to ArgoUML

Following with my write-up of ideas to avoid neurological garbage collection before delving into ArgoUML for some time, follows a list of ideas related to ArgoUML, in which I won't elaborate as much as in the entry about medeia.

abstracter

The idea is to register in the background decisions that the ArgoUML modeler does, so that we may deduce from his actions a set of steps that might be used to solve similar problems. This is similar to a refactoring system that my colleague Rui Patrocínio explained to me. This system, takes a set of programmer actions and may apply them to a similar problem upon a programmer request.

This is called abstracter, because the goal would be to give such a tool the reverse engineering information from a software project and let it abstract away the details, creating easy to use diagrams and perspectives about the software. Kind-of something like pointing it to the OpenOffice.org source and letting it create some meaningful abstractions of it. The part where it is learning or being corrected by a developer is interesting, because it would allow experimentation with machine learning principles...

ArgoUML Lisp module

Implement a Lisp language module for ArgoUML. Probably this could have dialect specializations (Common Lisp, Scheme, Clojure, etc), but, have a reusable base. My idea is that this should be implemented in the specific languages and not in Java, in order to more easily receive contributions from developers that are primarily interested in the module.

Note: Rui Patrocínio referred a related project he was considering to do which is a static analyzer for Common Lisp so that it would be possible to support code browsing and refactoring.

The reverse engineering of Common Lisp, Scheme and Clojure should be based in the same communication protocol as the one used by SLIME, which allows things like running APROPOS.