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 Tue, 28 May 2013 12:37:23 GMT
Sorry for the confusion, I should have explained in detail in the first
place. Yes, a "cluster" is a "Java Package".  Also, "entities" are "Java
Classes". I should rephrase cluster as Java Package from now on.
The distance between the entities are calculated based on two aspect:
1. The dependency between java classes by referring to [#1]. If A is depend
on B, then a 1-1 relationship is established in between these two classes.
2. Inheritance of java classes. If A is the superclass of B or vice versa,
then A and B must be in the same package (or in another word, in the same
cluster).
Next, I try to calculate the similarity between classes using Sorensen-Dice
coefficient [#2] to find out the distance between A and B. If A=B, then the
similarity is equal to zero. Next, based on the result this coefficient, a
dendrogram is drawn. A dendrogram [#3] shows the correlation of data at
different hierarchy. Cutting/pruning the dendrogram at different level
generate different amount of java package with different amount of java
classes inside the package.
To answer your question regarding what is "entity distance", it is
basically the average distance between Java classes inside a package.
Ideally, if classes inside a package is cohesive, it should have low
distance score among the Java classes. I made a mistake by saying "low
cohesion" score. It should be "low distance" score. I am very sorry once
again. The same principle goes to distance between package/cluster. If the
package are well-defined, it should be far apart from each other.

Regards,
Chong

[#1] https://analysis.apache.org/**plugins/resource/110730?page=**
org.sonar.plugins.design.ui.**page.DesignPage<https://analysis.apache.org/plugins/resource/110730?page=org.sonar.plugins.design.ui.page.DesignPage>
[#2] http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient
[#3] https://en.wikipedia.org/wiki/Dendrogram


On Tue, May 28, 2013 at 8:09 PM, Glen Mazza <glen.mazza@gmail.com> wrote:

> "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
>> <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
>>> 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<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<https://analysis.apache.org/plugins/resource/110730?page=org.sonar.plugins.design.ui.page.DesignPage>
>>> [#2]:
>>> http://www.visual-paradigm.**com/ <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<https://analysis.apache.org/dashboard/index/110730>
>>>> [#2]:
>>>>
>>>> https://analysis.apache.org/**plugins/resource/110730?page=**
>>>> org.sonar.plugins.design.ui.**page.DesignPage<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://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<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