"Note that lower cohesion score implies that the distance between entities inside the cluster is lower,
which leads to more cohesive cluster." -- What's a cluster? (Do you mean "Java package"?)
Could you define "entity distance" for us? Also, a *lower* cohesion score means the clusters are
*more* cohesive?
Glen
On 05/28/2013 02:41 AM, Chun Yong Chong wrote:
Dear Developers,
Additional points to add. The breakdown of cohesion and coupling score for
all three solutions are as below:
JSPWiki1.jpg - Average Cohesion = 24 Average Coupling = 11.0
JSPWiki2.jpg - Average Cohesion = 23 Average Coupling = 1.5
JSPWiki3.jpg - Average Cohesion = 19 Average Coupling = 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
<cych...@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 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.san...@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://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
