Hi Chong, I'm curious to see that high-level design view. A good starting point on what to modularize can be found at [#1], especially at the design tab [#2].
As for concrete classes, you can take a look at WikiEngine, which uses ClassUtil#getMappedObject to locate helper classes which can be understood as entry points for the different modules/subsystems. Also, WikiEngine/WikiContext probably need to be wrapped with an interface, as they're passed around mostly everywhere Regarding the nifty UML diagrams, provided that you have graphviz binaries ( www.graphviz.org) on your path, you can check out the maven branch [#3] and execute mvn javadoc:javadoc you'll get those diagrams embedded within the javadocs at app, package and class level. br, juan pablo [#1]: https://analysis.apache.org/dashboard/index/110730 [#2]: https://analysis.apache.org/plugins/resource/110730?page=org.sonar.plugins.design.ui.page.DesignPage [#3]: https://svn.apache.org/repos/asf/incubator/jspwiki/branches/MVN3_BRANCH On Tue, May 14, 2013 at 3:38 PM, Chun Yong Chong <cych...@siswa.um.edu.my>wrote: > Hi Glen! > > Thanks for the feedback. I fully understand your concern. I would not > attempt to change any component/structure of the source code but rather > provide a high-level design view of JSPWiki to fellow developers. This > high-level design view will solely depend on the structure of the source > code. For example, components/classes that behave similarity (method call, > shared variable, share data, etc.) will be clustered into the same package > diagram. Ultimately, I hope the resulting high-level design view can > improve the modularity of future release of JSPWiki > > > > On Tue, May 14, 2013 at 8:51 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > > > Hi Chun. Could be a good idea, much of our code may be rather old and > > could use a reexamination. I work still at a macro level with JSPWiki so > > can't answer yet which modules could use improvement--perhaps others can > > give you a suggestion. > > > > We're already modularizing as part of Maven, but the modularization you > > mention is of a much more granular (class-level) manner, so I don't think > > your work would effect that. Main concern I have is that many university > > types get bored after a few weeks and end up switching projects so I > > wouldn't want any massive changes to JSPWiki that are dependent on your > > presence and would leave JSPWiki in a heavily unfinished state if you > were > > to leave it. In other words, I'll let you paint a house if you paint > > room-by-room, so if you leave there can only be one unfinished room to > deal > > with; *not* by painting 10% of every room before finishing any, requiring > > *every* room to be repainted if you leave. > > > > Another concern is that sometimes the class design necessary for > beautiful > > UML diagrams and that for easy understanding and maintenance are not the > > same. > > > > Glen > > > > > > On 05/14/2013 04:13 AM, Chun Yong Chong wrote: > > > >> Dear devs, > >> > >> I understand that jspwiki is in incubator stage and requires > contributors > >> to improve the project. I am currently developing an algorithm to > reverse > >> engineer java source codes into clusters of cohesive classes to give a > >> better view of the software design. The output will be represented in > UML > >> class and package diagram. The output will assist developers when > >> modifying > >> or adding new modules into the system. Developers can easily identify > >> correlated software components when modifying a particular module. > >> Thus, I hope to receive some ideas from fellow developers as in which > >> module of the software requires re-modularization. Finally, I hope that > >> interested developers can assist me in verifying the quality of the > output > >> after re-modularization. > >> > >> Thanks and regards, > >> Chong > >> > >> > > >
