incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun Yong <cych...@siswa.um.edu.my>
Subject Re: Offer to re-modularize jspwiki source code
Date Sun, 02 Jun 2013 00:27:56 GMT
Dear developers

I had exclude all the UML association, dependency and generalization notation in the diagram
that I had provided. This is because I found that if I were to include those notation, the
diagram would look very messy and very hard to comprehend. For the grouping of classes into
package, I had ensure that classes with inheritance relationship all always grouped into the
same package to avoid breaking the hierarchy. 
I hope to receive some comments from the developers regarding the accuracy of the package
diagram as well as its usefulness in term of software maintenance (i.e. from a scale from
1 to 5, 5 being very good). 
I strongly appreciate any kind of comments from the developers. 

Thanks and regards
Chong

On 28 May, 2013, at 8:37 PM, Chun Yong Chong <cychong@siswa.um.edu.my> wrote:

> 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
> [#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
>>>> 
>>>> 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://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, 7-Bit, 0 bytes)
View raw message