Hi Laurent,
Thomas mentioned on the list that there's a module generator and I agree
with you that it might be good to use it to create the code generation
framework. I don't know what state it's in, but I'm definitely willing to
try it out.
One of the things that's interesting about the idea of a module-generator is
that it could be generalized to generate any type of project. I could
imagine people generating Java web projects, RoR/Grails/Lift projects using
such a module. Perhaps with the appropriate profile support.
Usually open source projects that make a lot of use of Maven, end up
creating their own "archetypes". These are project templates that can be
used to kickstart a development effort by generatng either a project
skeleton or a plugin skeleton. It would be nice if we had something like
this since it would make module development easier, faster and more
standardized. And if there was a way to invoke it from the argouml module
generator that would be great. It would allow developers to specify
requirements/propose a design, post it to the wiki, and then after getting
feedback from the group, get started on the coding and testing with a
minimal amount of fuss.
My goal of generating other project artifacts like services files, web.xml
files, and Maven POM files is to make it easier and faster for developers to
use ArgoUML to accelerate their own projects. But I don't see any reason
why we shouldn't be able to use the same tools to accelerate ArgoUML
development.
To generate a Maven POM from a deployment diagram, you need a Maven profile
that includes stereotypes for basic project elements like dependencies,
project information, etc. You should be able to generate a pom file with
ArgoPrint. Although you might need to add some methods to DiagramUtil to
handle extracting profile and stereotype information from the project.
As for next steps for code generation, I'd propose the following:
1. I'll post the model for Code Generation to the wiki and send out the
link to the group. I haven't used the wiki so I don't know if it can handle
straight HTML, or if things have to be in wiki markup. I'll see if I can
generate something useful in ArgoPrint that can be posted to the wiki.
Anyone who's interested can comment on it for a week. Ideally, we should
get feedback from everyone who currently supports a language. That should
also give us time to look at Thomas' argouml module generator and see if we
can use it to create a code generation module.
2. Create a code gen module. We'll need help from Linus in setting up a
new project in svn or perhaps making it another directory within argouml.
3. Implementing code gen. There are 3 parts to this, the UI, the code
generation framework, and the templates. I would start with the code
generation framework, and create unit tests that allow template writers to
quickly create and test templates. In addition to the menu items and dialogs
for code generation, it would be good for the Source tab to use the code
generation framework. Even without a GUI, you should be able to generate
code.
In order to be able to test this properly, we'll need some real world UML
models. At the moment, reveng for java isn't fully functional, so we can't
reverse engineer some real world projects. It would be nice to be able to
reveng the ArgoUML project, and to be able to describe its use cases, and
the software development processes that it supports. Perhaps have a
deployment diagram that shows each of the main modules. The models that are
used to test ArgoUML are pretty minimal and don't really reflect real-world
modeling scenarios. It would be good to get a model for a web app that
includes stereotypes for things like Controllers and Services.
To get started though, we will need a class diagram that demonstrates
each of the features (classes, interfaces, methods, attributes, generics --
at least what's currently supported, enums, varargs, inner classes, and
code-level documentation for all of it). We could probably do most of this
using the code gen UML model itself. In the US it's called "eating your own
dog food", not sure if they have a similar expression in French. ;-)
That should be enough to get people started on the code gen project.
Bob outlined the issues that were needed for a stable release in a separate
email thread last month.
http://argouml.markmail.org/search/?q=issues+for+stable+release#query:issues%20for%20stable%20release+page:1+mid:ltzlyvweq3nqkxl5+state:results
Beyond a stable release, I think many people on the project have wanted a
1.0 release for some time now. As I see it, the main things that are
missing from a 1.0 release are (in no particular order):
- Reveng for Java
- Support for generics
- Support for inner classes
- Support varargs
- Support enums
- Java language support in diagrams (see previous bullet items)
- Templated Code generation
- Doc generation/ArgoPrint
- Support diagram-level descriptions
http://argouml.tigris.org/issues/show_bug.cgi?id=6360
- Support company name/address in project properties
http://argouml.tigris.org/issues/show_bug.cgi?id=6296
- Support re-ordering of diagrams:
http://argouml.tigris.org/issues/show_bug.cgi?id=6336
- Support for template repositories:
http://argouml.tigris.org/issues/show_bug.cgi?id=6346
- Sequence diagram issues (I think there are numerous issues that
Penyaskito filed on this -- these are just the ones I noticed recently)
- self-referencing calls are difficult to create
- sequence notation
http://argouml.tigris.org/issues/show_bug.cgi?id=6212
- Fit and finish issues
- Use case generation not consistent:
http://argouml.tigris.org/issues/show_bug.cgi?id=6327
- Underscores in menu items:
http://argouml.tigris.org/issues/show_bug.cgi?id=6322
- Error messages in property panels
- Icon updates/Icon Loader framework;
http://argouml.tigris.org/issues/show_bug.cgi?id=5427 ,
http://argouml.tigris.org/issues/show_bug.cgi?id=6200
- Use Autocomplete fields on namespace combos:
http://argouml.tigris.org/issues/show_bug.cgi?id=6334
- Clean up Documentation panel. Author field WAYYY too wide, and
documentation field WAYYY too small. There are also unused fields on this
panel that take up room. HTML support would also be nice --
plenty of open
source widgets for that.
- Make Explorer filterable:
http://argouml.tigris.org/issues/show_bug.cgi?id=6335
- Documentation - there are a lot of missing items
- Profiles
- Java web app profile
- Spring bean profile
- Spring web profile
- Maven profile
- Requirements profile
- Use case profile
- Test case profile
- Support for shared profile repositories
- UML2 support: I'm not sure where UML2 fits in with the priorities. I
know Bob is working full throttle on it, so hopefully we'll see it feature
complete in the near future.
Most of the items on the list (except perhaps for UML2 support) are small
enough in scope that they could be knocked out without too much work.
I should emphasize that my list is my opinion and not necessarily what
anyone else on the project sees as a priority. These are just the things
that give me pause whenever I find myself demonstrating ArgoUML. And
contrary to what one might infer from the task list, I REALLY DO like
ArgoUML. :-)
Sorry for rambling on a bit here.
Mark
On Sat, Sep 3, 2011 at 4:23 AM, Laurent BRAUD <[email protected]> wrote:
> Hi,
> At this time, I just use ArgoUML to edit UseCase / Classe / State Diagram.
> But I would like to become "UML power users" with ArgoUML.
>
> By reading Mark, we need (re)write module in order to be able to work
> (generate/reveng/ and instant Reveng...) with Java 5 (or > ).
> And, the best way will be to have a first generic module for all generation
> (Java, C++, SQL, Groovy, ...).
>
> "If I create a deployment diagram, I should be able to generate
> META-INF/services files, web.xml files (for web apps), Maven POM files"
> => Thomas has started to develop an intersting module
> "argouml-modulegenerator" in order to develop Argo's module.
> I don't know if Thomas want to spend more time alone in this project before
> shared it.
>
> If not, Mark, as you have write a lot of Enhancement, I suggest we start
> (after stable release) to go in your way :
>
> 1) Mavenize Argorpint / argouml-modulegenerator
> I don't know how to use Maven, but I understand you know, and you want it
> quickly.
>
> Is there a doc where it's explain how to generated "maven files" from
> "deployement diagram" ?
> If not, can you provide this diagram (add an "Argo project" in the
> Argoprint java project) and what you want to be generated
> With this, I think we can be able to do somethink in modulegenerator.
>
> And do some "basic" for modulegenerator (a menu item for generate
> ".launch",...)
>
>
> 2) Next step
> Reveng ArgoPrint ?
> Use ArgoUML to generate ArgoPrint ?
> Other ?
> => I think we have to choose a goal which is intersting the most of them
> when we start ?
>
>
> I have write this for ArgoPrint, but I think we need others projects:
> -> Some other new module (Thomas write feature about using modulegenerator
> to generate itself)
> -> One more "common" project, that can be use in documentation (Exemple in
> books : PetShop, Library, ..). And the idea was to be able
> to generate more than one language.
>
> With the common project, we can "generalized" what is done in ArgoUML
> module. For instance, generate ".POM" isn't a "ArgoUML module".
> Moreover, this project can help user to use Argo, and then to be involved.
>
>
> For me, we need to have always 2 versions : One with MDR, one with UML2
> It's more time, but I think it the best way to progress with "UML2", at
> least for test.
>
> If we successfull, then we can think to extend it to other module and
> ArgoUML.
>
> With "argouml-modulegenerator", we have the ".zargo" in the Java Project. I
> want to do this for ArgoPrint
> -> Where is the best place to put it ? Java Project root ? Java project
> subdirectory ? Other site ?
> -> I don't think ".zargo" was the best. Can we save file in a directory
> without zip them.
> Then, we will have exemple of argo's files in SVN. May be we can progress
> with issue for sharing Argo project.
>
>
> Of course, our first priority is to close all P2 in order to have a stable
> release.
> I have a look at them at start of alpha, but seems difficult for me.
> And some of them seems to be frozen. Are they real P2 or a just a wish ?
> Mark : If we start rewrite the Java module in some next mounth, do we need
> to fix 6239 as P2.
>
> And I don't forget that some other issue must be solve.
>
> Best reagards.
>
> Laurent.
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2834814
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
> To be allowed to post to the list contact the mailing list moderator,
> email: [[email protected]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2834862
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
