Menu
▾
▴
geotools-devel
|
From: Andrea A. <and...@al...> - 2006-06-03 21:41:12
|
Hi, I've just finished uploading a javadoc with embedded UML diagrams that I generated with my new toy, UmlDoc (still unpublished), an UML diagramming javadoc doclet that extends the standard doclet by adding class diagrams into the javadoc files. Basically, the tool reverse engineers context class diagrams for classes, and package diagrams for packages, using class informations such as fields and methods in order to compute relations and dependencies. At http://www.andrea-aime.name/static/gt2-api/index.html you can find an integrated javadoc for the gt/module projects, that I've generated with a slight modification of the gt2 main pom (so yes, it works with maven 2). Tell me what you think about it, and if you are interested in integrating the tool into the javadoc build for good. Beware, thought, that to make UmlDoc run you'll need Graphviz installed, and of course it'll take (way) more time to generated the javadoc. Just to give you a reference on my home PC (old Athlon XP 2600+) it takes between 10 and 15 minutes to generate the javadoc I published. Cheers Andrea Aime |
|
From: Bryce L N. <bno...@fs...> - 2006-06-05 18:19:35
|
I notice a lot of dashed lines. Is it drawing dependencies to everything in the import list? That may create a lot of visual noise. Perhaps there is a way to control how many dependencies are represented? Also, I don't notice "associations", which I think are being represented as dependencies instead. Is there a way to supply it with a UML diagram, or some sort of UML connectivity information (e.g., which dependencies are associations, which are attributes, and which are just dependencies?) The coverage implementation is building up full Ecore models for each of the packages. I think the diagrams could benefit If this information could somehow be imported into the tool. It does look nice, though! :) Bryce geo...@li... wrote on 06/03/2006 03:38:14 PM: > Hi, > I've just finished uploading a javadoc with embedded UML diagrams > that I generated with my new toy, UmlDoc (still unpublished), an UML > diagramming > javadoc doclet that extends the standard doclet by adding class diagrams > into > the javadoc files. > > Basically, the tool reverse engineers context class diagrams for classes, > and package diagrams for packages, using class informations such as fields > and methods in order to compute relations and dependencies. > > At http://www.andrea-aime.name/static/gt2-api/index.html > you can find an integrated javadoc for the gt/module projects, that I've > generated > with a slight modification of the gt2 main pom (so yes, it works with > maven 2). > Tell me what you think about it, and if you are interested in > integrating the tool into > the javadoc build for good. > Beware, thought, that to make UmlDoc run you'll need Graphviz installed, > and of > course it'll take (way) more time to generated the javadoc. Just to give > you a reference > on my home PC (old Athlon XP 2600+) it takes between 10 and 15 minutes > to generate > the javadoc I published. > > Cheers > Andrea Aime > > > > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
|
From: Gabriel <gr...@ax...> - 2006-06-05 19:21:21
|
On Monday 05 June 2006 20:13, Bryce L Nordgren wrote: > I notice a lot of dashed lines. Is it drawing dependencies to everything > in the import list? That may create a lot of visual noise. Perhaps there > is a way to control how many dependencies are represented? Also, I don't > notice "associations", which I think are being represented as dependencies > instead. > > Is there a way to supply it with a UML diagram, or some sort of UML > connectivity information (e.g., which dependencies are associations, which > are attributes, and which are just dependencies?) =20 well.. if we already were java5... in the mean time, while we don't have annotations, could the doclet inspect= =20 custom "@tasks" in the javadocs? 1.5c.- > The coverage=20 > implementation is building up full Ecore models for each of the packages. > I think the diagrams could benefit If this information could somehow be > imported into the tool. > > It does look nice, though! :) > > Bryce > > geo...@li... wrote on 06/03/2006 03:38:14 > > PM: > > Hi, > > I've just finished uploading a javadoc with embedded UML diagrams > > that I generated with my new toy, UmlDoc (still unpublished), an UML > > diagramming > > javadoc doclet that extends the standard doclet by adding class diagrams > > into > > the javadoc files. > > > > Basically, the tool reverse engineers context class diagrams for classe= s, > > and package diagrams for packages, using class informations such as > > fields > > > and methods in order to compute relations and dependencies. > > > > At http://www.andrea-aime.name/static/gt2-api/index.html > > you can find an integrated javadoc for the gt/module projects, that I've > > generated > > with a slight modification of the gt2 main pom (so yes, it works with > > maven 2). > > Tell me what you think about it, and if you are interested in > > integrating the tool into > > the javadoc build for good. > > Beware, thought, that to make UmlDoc run you'll need Graphviz installed, > > and of > > course it'll take (way) more time to generated the javadoc. Just to give > > you a reference > > on my home PC (old Athlon XP 2600+) it takes between 10 and 15 minutes > > to generate > > the javadoc I published. > > > > Cheers > > Andrea Aime > > > > > > > > _______________________________________________ > > Geotools-devel mailing list > > Geo...@li... > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel =2D-=20 Gabriel Rold=E1n (gr...@ax...) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 =46ax. +34 944 41 64 90 |
|
From: Andrea A. <and...@al...> - 2006-06-05 19:37:38
|
Bryce L Nordgren ha scritto: > I notice a lot of dashed lines. Is it drawing dependencies to everything > in the import list? No, just from whatever appears in method signatures. There's a flag that can enable the import list as well, but I left it disabled. > That may create a lot of visual noise. Perhaps there > is a way to control how many dependencies are represented? Nope, just the kind: from methods arguments, from imports as well, or nothing > Also, I don't > notice "associations", which I think are being represented as dependencies > instead. > They are there, you just looked at an unfortunate diagram. They are solid lines. It's also possible to have just relationships, but in my opinion that would spoil the diagrams too much. > Is there a way to supply it with a UML diagram, or some sort of UML > connectivity information (e.g., which dependencies are associations, which > are attributes, and which are just dependencies?) Yes, with javadoc comments, see http://www.spinellis.gr/sw/umlgraph/doc/cd-model.html (UmlDoc is an _unreleased_ extension to UmlGraph). > The coverage > implementation is building up full Ecore models for each of the packages. > I think the diagrams could benefit If this information could somehow be > imported into the tool. > That's not something I'm gonna do myself, but it's an open source project, you're welcomed to contribute :-) Cheers Andrea Aime |
|
From: Andrea A. <and...@al...> - 2006-06-05 20:03:10
|
Andrea Aime ha scritto: > Bryce L Nordgren ha scritto: > >> I notice a lot of dashed lines. Is it drawing dependencies to everything >> in the import list? >> > No, just from whatever appears in method signatures. There's a flag that > can enable the import list > as well, but I left it disabled. > >> That may create a lot of visual noise. Perhaps there >> is a way to control how many dependencies are represented? >> > Nope, just the kind: from methods arguments, from imports as well, or > nothing > > Two interesting suggestion that came up during the gt2 meeting to reduce visual clutter: - reverse engineer dependencies only from public/protected methods, avoid private ones - don't depict dependencies among classes in the same package, they are supposed to be related anyway. If I implemented those, would you be happy of generating gt2 javadoc this way, maybe just as an option for automated builds? (I really believe the diagrams would help newbies a lot, and also developers too, raise your hand if you think you know well the whole source code base :-) ) Cheers Andrea Aime |
|
From: Jody G. <jga...@re...> - 2006-06-05 20:09:34
|
Andrea Aime wrote: > Two interesting suggestion that came up during the gt2 meeting to reduce > visual clutter: > - reverse engineer dependencies only from public/protected methods, > avoid private ones > - don't depict dependencies among classes in the same package, they are > supposed to be related > anyway. > > If I implemented those, would you be happy of generating gt2 javadoc > this way, maybe just as > an option for automated builds? (I really believe the diagrams would > help newbies a lot, and also > developers too, raise your hand if you think you know well the whole > source code base :-) ) > +1 But you may also wish to ask on the users list :-) Or at least share your joy. Looking at the pictures for feature source, I really do not care to know about the implementations I am related to if they only depend on me by implementing an interface. Thinking of the implementation of repository shown there... does not show me anything that Repository did not show me. Jody |
|
From: Bryce L N. <bno...@fs...> - 2006-06-05 20:53:08
|
geo...@li... wrote on 06/05/2006 02:01:32 PM: > Andrea Aime ha scritto: > If I implemented those, would you be happy of generating gt2 javadoc > this way, maybe just as > an option for automated builds? (I really believe the diagrams would > help newbies a lot, and also > developers too, raise your hand if you think you know well the whole > source code base :-) ) I'd be glad to have it. How would it be set up? "mvn javadoc:umldoc"? We'd still want "mvn javadoc:javadoc" of course. :) Do you have to write a plugin for it? |
|
From: Andrea A. <and...@al...> - 2006-06-05 21:06:53
|
Bryce L Nordgren ha scritto: > geo...@li... wrote on 06/05/2006 02:01:32 > PM: > > >> Andrea Aime ha scritto: >> If I implemented those, would you be happy of generating gt2 javadoc >> this way, maybe just as >> an option for automated builds? (I really believe the diagrams would >> help newbies a lot, and also >> developers too, raise your hand if you think you know well the whole >> source code base :-) ) >> > > I'd be glad to have it. How would it be set up? "mvn javadoc:umldoc"? > We'd still want "mvn javadoc:javadoc" of course. :) Do you have to write a > plugin for it? No, that would replace mvn javadoc:javadoc, but I believe we can have both by using "profiles", or I could hack something, like an environment variable, to make it avoid generating the uml diagrams by default Cheers Andrea |
|
From: Martin D. <mar...@no...> - 2006-06-07 06:17:06
|
Andrea Aime a =E9crit : > Two interesting suggestion that came up during the gt2 meeting to reduc= e=20 > visual clutter: > - reverse engineer dependencies only from public/protected methods,=20 > avoid private ones I suggest to avoid static fields/methods too. Static fields are often enu= merations or pre-defined=20 instances of the same class. It would avoid recursive arrows from a box t= oward the same box just=20 because a predefined constant exists. Martin. |
|
From: Jody G. <jga...@re...> - 2006-06-07 08:10:07
|
Martin Desruisseaux wrote: > Andrea Aime a =E9crit : > =20 >> Two interesting suggestion that came up during the gt2 meeting to redu= ce=20 >> visual clutter: >> - reverse engineer dependencies only from public/protected methods,=20 >> avoid private ones >> =20 That said I love all the arrows, provides good motivation to clean up=20 more could to work against the interfaces :-) I really hope you see a better picture when you switch to the new=20 Feature Model (although initially it may be worse due to us running some older methods on Expression for backward=20 compatibility). Jody |
|
From: Andrea A. <and...@al...> - 2006-06-07 09:34:43
|
Martin Desruisseaux ha scritto: > Andrea Aime a écrit : >> Two interesting suggestion that came up during the gt2 meeting to >> reduce visual clutter: >> - reverse engineer dependencies only from public/protected methods, >> avoid private ones > > > I suggest to avoid static fields/methods too. Static fields are often > enumerations or pre-defined instances of the same class. It would avoid > recursive arrows from a box toward the same box just because a > predefined constant exists. Good catch, but I already avoided static fields in my generator. If you see one, it's a bug. Can you point me to a sample of an arrow generated because of a static field? Cheers Andrea |
|
From: Martin D. <mar...@no...> - 2006-06-07 22:20:42
|
Andrea Aime a =E9crit : >> I suggest to avoid static fields/methods too. Static fields are often=20 >> enumerations or pre-defined instances of the same class. It would=20 >> avoid recursive arrows from a box toward the same box just because a=20 >> predefined constant exists. >=20 > Good catch, but I already avoided static fields in my generator. > If you see one, it's a bug. Can you point me to a sample of an arrow > generated because of a static field? DefaultCoordinateSystemAxis there: http://www.andrea-aime.name/static/gt2-api/org/geotools/referencing/cs/pa= ckage-summary.html I assumed that the recursive arrow was caused by "public static final" fi= elds, but there is also a=20 "private transient" field that may be the cause. Martin. |
|
From: Andrea A. <and...@al...> - 2006-06-08 06:42:33
|
Martin Desruisseaux ha scritto: > Andrea Aime a écrit : >>> I suggest to avoid static fields/methods too. Static fields are often >>> enumerations or pre-defined instances of the same class. It would >>> avoid recursive arrows from a box toward the same box just because a >>> predefined constant exists. >> >> Good catch, but I already avoided static fields in my generator. >> If you see one, it's a bug. Can you point me to a sample of an arrow >> generated because of a static field? > > DefaultCoordinateSystemAxis there: > > http://www.andrea-aime.name/static/gt2-api/org/geotools/referencing/cs/package-summary.html > > > I assumed that the recursive arrow was caused by "public static final" > fields, but there is also a "private transient" field that may be the > cause. It definitely is. There is a solid arrow (directed association) for each field in the class, provided that the destination class is not hidden by a filter (for this diagrams the hide filter is java.*). Cheers Andrea |
|
From: Andrea A. <and...@al...> - 2006-06-05 19:47:49
|
Bryce L Nordgren ha scritto: > ... > > Is there a way to supply it with a UML diagram, or some sort of UML > connectivity information (e.g., which dependencies are associations, which > are attributes, and which are just dependencies?) Hum, forgot to answer that one. There are two kinds of associations: * the ones that are implemented by some strange data structures. These I cannot reverse engineer * the ones that are implemented as fields or a List<ClassXXX>. These I can reverse engineer, and I represent them as directed associations (since there's no way to tell for sure an association is bi-directional) * pure attributes in my opinion are just primitive ones. The others are associations. Everything that is used as an argument in methods is a dependency instead, and also everything that is imported but not used as a field. Cheers Andrea |
Thanks for helping keep SourceForge clean.
X