Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: error (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CANtV4OFAjO8eKOPJtJ3SATFEFQbAzNngB+wZSPc=CiMtkCXUxA@mail.gmail.com>
References: 
 <CANtV4OFTjuifaTfU8JWTs3Ama4+F0_fE-5x2Tnr-xaGgDjVZgA@mail.gmail.com>
	<51923357.2030407@gmail.com>
	<CANtV4OHXBLM2pjZtRA5tAoRaPLpm6eKKBhed3S85n2_YF_0vtw@mail.gmail.com>
	<CAMufup716rhrksYkJKGj+EWAVY1nY_3h6QOg6dMeBkUL9AfArA@mail.gmail.com>
	<CANtV4OFAjO8eKOPJtJ3SATFEFQbAzNngB+wZSPc=CiMtkCXUxA@mail.gmail.com>
Date: Tue, 28 May 2013 14:41:47 +0800
Message-ID: 
 <CANtV4OFzv1JKkxy9hu0jxwfJ20eFx4HKOuQrDK=myfh+J3y0MQ@mail.gmail.com>
Subject: Re: Offer to re-modularize jspwiki source code
From: Chun Yong Chong <cychong@siswa.um.edu.my>
To: jspwiki-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7bd6a8ce2b820d04ddc18fb3

--047d7bd6a8ce2b820d04ddc18fb3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Developers,

Additional points to add. The breakdown of cohesion and coupling score for
all three solutions are as below:
JSPWiki1.jpg - Average Cohesion =3D 24 Average Coupling =3D 11.0
JSPWiki2.jpg - Average Cohesion =3D 23 Average Coupling =3D 1.5
JSPWiki3.jpg - Average Cohesion =3D 19 Average Coupling =3D 1.2
Note that lower cohesion score implies that the distance between entities
inside the cluster is lower, which leads to more cohesive cluster. Higher
coupling score implies that the clusters are well separated in their own
domain.
As mentioned in my previous message, I feel that JSPWiki3.jpg is a better
design view although it score badly in term of coupling score. This might
be due to the way how software components in JSPWIKI are
interacting/depending on each others. I found that several classes are
acting like utility classes where a lot of function call are being made to
the same classes.
Hope to get some feedback from you guys.


Regards,
Chong


On Mon, May 27, 2013 at 11:26 PM, Chun Yong Chong
<cychong@siswa.um.edu.my>wrote:

> 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 component=
s
> in JSPWiki. Basically my algorithm uses agglomerative clustering to form =
a
> dendrogram that depicts the hierarchy of relationships between each entit=
y
> (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 o=
f
> 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 t=
o
> 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=3Dorg.sonar.plug=
ins.design.ui.page.DesignPage
> [#2]:
> http://www.visual-paradigm.com/
>
>
> On Wed, May 15, 2013 at 6:32 AM, Juan Pablo Santos Rodr=EDguez <
> 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 understo=
od
>> 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 th=
e
>> 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=3Dorg.sonar.plu=
gins.design.ui.page.DesignPage
>> [#3<https://analysis.apache.org/plugins/resource/110730?page=3Dorg.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.m=
y
>> >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 rathe=
r
>> > provide a high-level design view of JSPWiki to fellow developers. This
>> > high-level design view will solely depend on the structure of the sour=
ce
>> > 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 a=
nd
>> > > 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 yo=
u
>> > were
>> > > to leave it.  In other words, I'll let you paint a house if you pain=
t
>> > > 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 giv=
e
>> 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 identi=
fy
>> > >> correlated software components when modifying a particular module.
>> > >> Thus, I hope to receive some ideas from fellow developers as in whi=
ch
>> > >> 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
>> > >>
>> > >>
>> > >
>> >
>>
>
>

--047d7bd6a8ce2b820d04ddc18fb3--