incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun Yong Chong <cych...@siswa.um.edu.my>
Subject Re: Offer to re-modularize jspwiki source code
Date Mon, 27 May 2013 15:26:12 GMT
Dear dev,

I had managed to use the information from [#1] (as pointed out by Juan) and
run through my algorithm to identify the similarity between components in
JSPWiki. Basically my algorithm uses agglomerative clustering to form a
dendrogram that depicts the hierarchy of relationships between each entity
(each java classes represent one entity). I then tried to cut the
dendrogram at some certain threshold to form meaningful representation of
the systems in the form of clusters. Entities that are related to each
others are clustered together. To decide whether the entities should be
cluster together, I measure the cohesion and coupling of each entities
based on the data mined from [#1].
All in all, I managed to come out with 3 possible solutions in the form of
class/package diagram drawn in Visual Paradigm [#2]. The files are
accessible from this link:

https://www.dropbox.com/sh/bw2h0hn3wmiuwot/vyCAWueafI

The three sample solutions (JSPWIKI1.jpg, JSPWIKI2.jpg, JSPWIKI3.jpg) yield
22, 32, and 63 clusters respectively. Out of all the possible way to cut
the dendrogram, these 3 sample solutions achieve the best balance in term
of cluster cohesion and coupling. These solutions exhibit different
behaviour in term of cohesion and coupling strength:

Solution 1 (22 clusters) - Highest coupling but lowest cohesion. Clusters
are well-seperated from each others which leads to high coupling strength.
However, the entities inside the same cluster is weakly bond together and
resulting in clusters with a lot of entities (Package 22).
Solution 2 (32 clusters) - Average coupling and low cohesion.
Solution 3 (63 clusters) - Low coupling but highest cohesion. A lot of
small clusters are formed. However, the entities inside the same cluster
exhibit very high cohesion strength.

In my opinion, solution 3 looks more convincing but it contains a lot of
clusters with small amount of entities (2-3). I am wondering if this
intended? Furthermore, I found that a lot of classes in JSPWiki are
dependant on class wiki.tags. Class wiki.tags. behave similar like an
utility class. It could probably get wrapped by an interface class for
better performance.
I hope to receive some feedbacks from fellow developers regarding the
accuracy/usefulness of this proposed result.

Regards,
Chong

[#1]:
https://analysis.apache.org/plugins/resource/110730?page=org.sonar.plugins.design.ui.page.DesignPage
[#2]:
http://www.visual-paradigm.com/


On Wed, May 15, 2013 at 6:32 AM, Juan Pablo Santos Rodríguez <
juanpablo.santos@gmail.com> wrote:

> 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 <cychong@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.mazza@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
> > >>
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message