When analyzing the structure of JSPWiki, I found that there are a lot of package that contains small amount of classes (Around 2 to 3 classes in a package). I hope to get some insight from the developers if this decision is intended? Overall the system is very cohesive and compose with a lot of strongly related classes. However, problem might occur if we were to remove/add new modules into the system because a lot of software components might be affected. I might be able to perform a traceability study on JSPWiki to identify the severity of adding or removing a particular component from JSPWiki.
Regards, Chong On Sun, Jun 2, 2013 at 8:27 AM, Chun Yong <cych...@siswa.um.edu.my> wrote: > 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<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<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.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<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 < >>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>> >> >
