Abstraction experiment - Grouping elements and connections

We conducted some experiment to de-clutter the diagrams and especially the overview diagram showing all the sub-diagrams on one view.
Here is the original (obfuscated) diagram.

After several trials, we chose the following rules

• Component objects are represented with “C” whereas interfaces with “I” (this is not ‘pretty’ but it helps us differentiate them while we are still playing around with ideas)
• We only show connections within a package. No more crossing lines from inside a package to another.
• Interfaces which are not connected to anything are listed in the upper part of their ‘home’ components
• Interfaces having other connections than the one linking them to their ‘home component’ are detached from the component (The “I” component objects). We still show to which component they belong to by drawing a line ‘home component’-> interface
• All connections crossing from a package to another package are listed under the corresponding connected components or interfaces. With the form <PackageName>.<ComponentOrInterface>().

  Zoom on one sub diagram :
Original

Modified

Discussion

As we can see, grouping elements in that way lightened the diagram while preserving the original information.
As package (sub-diagram) inter-connections are presented inside each sub-diagram, one idea could be that the solution generate first an overview of how the packages are connected.
Example

and then generate one picture/page per sub-diagram. In our opinion this splitting from overview to more detailed view would follow the pedagogic way of explaining the system to someone new to it.

We are awaiting feedback on this idea(s) and we are now exploring an additional way of  abstracting the diagram by grouping elements by names.
We also asked our supervisor, as only they, are experts in the system,  if he had tips on generic rules which could dictate which components are important to show and which can be remove without altering the message they want to present with the diagrams. Awaiting for answer.

Grouping ports by their names and connections

We also worked on grouping ports by their names in our obfuscated system overview diagram. The system overview diagram without grouping ports is shown in Figure-1 and 2.

Figure-1 System overview

 Figure-2 System overview (zoomed)

We grouped all ports and wrote them into one config file. Since all the port names are not the real ones, the group names and each group classification are also done for experimenting. Grouped representation of system overview is shown in Figure 3 and 4.

 

Figure- 3 System overview with grouped ports

 Figure - 4 System overview with grouped ports (zoomed)

When we analyzed grouped diagram, there are still a lot of lines which reduces the readability. However comparing with the original diagram, grouping ports method widely minimizes the line traffic in the diagram. Now we are considering omission of some ports according to their importance level if it is possible. With the help of this method, omission of unimportant ports can also improve the readability of the diagram pretty much.

2015/06/01 - 2015/06/18

Status report

What we did

• Class diagram abstractions level : We constructed several abstraction level experiments based on grouping connections and related elements together. (See post)
• Final report draft writing : We worked a lot on our final report draft and sent a version to our Chalmers supervisor and examiner (2015/06/15). We didn't get feedback yet as of 2015/06/22.
• Neato and PlantUML : We began exploring PlantUML source code and studied the possibilities of switching PlantUML layout algorithm to Neato. In summary, switching the layout algorithm is easier said than done. The source code is quite complex. We mailed the PlantUML developers to get some tips and input on how it would be possible and even though they are really interested by this functionality (which was also on their to-do list), they warned us on the complexity to do it in the amount on time we have left. Therefore we decided to leave it on the side for now and focus on abstraction to collect feedback before everyone leaves on vacation. We will pick it back up later on.
• Getting feedback : We presented our latest results (2015/06/12) to our Ericsson supervisor to get his and his team feedback. Awaiting for answer.

What we will do - week 2015/06/22 - 2015/06/26

• Getting feedback: It is critical that we get feedback before our supervisor and his team go on vacation so that we can develop the solution while they are away. We are awaiting for feedback on our abstraction propositions and on the rules making elements "relevant"/"not so relevant" to show on the diagrams.
• Abstraction - statistical analysis: Our abstraction experiments so far focus on grouping and presenting element differently while preserving the original information. Another track we are exploring without knowledge of the system is to get statistics on components' names, number of interfaces and connections to see if it correlate to what our supervisor identifies as "important"/"not so important" component. This is based on Truong Ho Quang's work.
• Continue on the final report writing

Meeting Notes - 2015-05-29

We met both our supervisors with some expert people both from Chalmers and Volvo-Cars.

• We presented our thesis work (research, problems, ideas,..) to the new visitors.
• Patrizio (docent in SW Enginering) introduced himself and his works about software models (dependencies).
• We discussed about the concept "readability" and agreed that it depends on the targeted audience. In our case the audience is 'developers of the DURA team' meaning that they have a certain understanding about technique and diagrams and they will validate our research's outcomes. It is important to show our test results to them to understand what is more readable in their case.
• Truong (Phd candidate) presented his work : A tool generating UML class diagrams with different abstraction levels. His tool uses machine learning to define the 'importance' of each components. Depending on the abstraction parameter, items with less importance disappear.
• We decided to study Truong's solution and see if his concepts can be adapted to our case. We will try to define the importance of every component in our models and see if it produces acceptable results. The difficulty is that given the limited number of models we have (7), it will be hard to use his machine learning algorithm.
• We decided to meet in two weeks to present our progress before everyone goes on summer vacations.
• We should also think about some research questions.

Graph Generation with KIELER

KIELER (Kiel Integrated Environment for Layout Eclipse RichClient)

KIELER is an open source research project for graphical model based design of complex systems. Within the project developers present some standalone applications as well as KIELER features for Eclipse environment. We tried one of its standalone application Web Service Tool with command-line which offers different layout algorithms, visualization options and file formats. Even from their web page, it is possible to try out this application online.

What interests us much is, they introduce a big list of different layout algorithms for supported graph formats, like dot, json, gml, svg, etc. They divide the layout algorithms into four main groups:

• KLay Force is an implementation of force-directed layout algorithm, where nodes tend to be closer when they are connected and far apart otherwise.
• KLay Layered is developed for diagrams which have hierarchical relations.
• KLay Planar contains planarization based algorithms which is currently in progress.
• KLay Tree is for tree layout algorithms.

We tried out its online tool with  one of our example diagram and  got some outputs which seem to be more readable then the original one.

 

Figure-1 Original Diagram  (obfuscated)

 

Figure-2 Mixed model  algorithm applied to the original diagram

Figure-3 Sugiyama algorithm applied to the original diagram

 
Link to the home page : https://www.informatik.uni-kiel.de/rtsys/kieler/