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 <cych...@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.ma...@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 >>> <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 >
