Software exploration tool Moose2Model for developers (ABAP, SAP, Java, Smalltalk, …) – Roadmap
The new software exploration tool Moose2Model is currently under development in Pharo Smalltalk and based on the Moose Analysis platform. See also the blog Legacy Code – Storing the mental model in diagrams.
An extractor (SAP2Moose) is available to extract model data to file. Moose can then be used to analyse. Extractors to Moose are also available for other languages, there is therefore no restriction to ABAP or SAP.
The SAP2Moose extractor is not restricted to ABAP Objects. It extracts also functions, reports, tables, WebDynpro ABAP and to some extend SAP BW coding. This fits to a typical customer IT, where a lot of different logic and data bearing entities are used.
This allowed me to draw fascinating diagrams of SAP applications and explore features that I would not have seen otherwise. My impression is, that this is a good way to explore new coding and get an overview over the structure. The most valuable advantage compared to the UML class diagram is that relations between methods and attributes are shown. This is more detailed than an UML class diagram. This helps to understand legacy application where normally too much details are missed if dependencies are restricted to classes.
But my current job is not to analyse applications on a high level. My duty is to analyze details of complex applications and add changes to them. And to have in mind all side effects that could cause errors. And to be able to really use this tool, I needed a way to make diagrams that fit to the way I (and many other developers) work. But for everyday work I missed features:
- It was easy to drag elements of a diagram in Moose, but there was no simple way to keep such customization when the diagram is opened the next time.
- Diagrams where often very big, and it was difficult to show only the elements of interest
- I needed a way to comment elements
- To help during development I needed a tool that provided many small features that where adapted to the workflow of a developer.
Moose was originally developed in other languages and was ported 2008 to Pharo Smalltalk, because this is an environment that allows for easy adapting and developing of applications. Pharo runs in a virtual machine and is written in Smalltalk itself. All coding can be changed and analyzed, it is therefore easy to adapt Moose if needed. This can be done in the virtual machine without need for compiling or in most cases even restarting an application. This gives a developer who works full time in SAP projects a chance to develop a software exploration tool that provides the features needed.
The new application is named Moose2Model. It is currently hosted on github as Moose2Model, the internal name space is RWDiagram. It is not restricted to SAP ABAP or to the mse files that are provided by SAP2Moose. Smalltalk coding can be analyzed also, I do this to while developing the tool. Java, C and many other languages (as soon as an extractor is available) should work also (But is not tested currently).
It works fine for me and I use it for existing and new applications. It generates customized diagrams like this: 
.
I checked the available literature on Software Exploration Tools to get a hint on how to improve it. See for instance Margaret-Anne Storey “Designing a Software Exploration Tool Using a Cognitive Framework” (DOI: 10.1007/978-1-4615-0457-3_5) and Seonah Lee and Sungwon Kang “What situational information would help developers when using a graphical code recommender?” (DOI: 10.1016/j.jss.2016.02.050) pdf
The challenge is to develop an application that fits to the needs of developers and has a chance to be adopted for everyday work. It should be as easy as possible to implement and use. So that the benefits outweigh the additional complexity of the tool.
I plan to do the needed changes to the current Software Evaluation Tool to achieve this.
Already done (This will be updated and grows with time):
- Simplify installation, a preconfigured virtual machine can now be downloaded on SAP2Moose.org.
- Jump directly into the code in Eclipse using ADT links (Windows only) – Available with SAP2Moose v0.5.1 and Moose2Model v0.2.0
- Provide a graphical user interface to simplify the usage (Moose2Model v1.0.0)
- Improve the diagrams, provide an option to show whether all or only some of the connected elements are displayed (Moose2Model v1.0.0)
- No need to use Moose or the Pharo Playground. This simplifies using and learning the tool.
Planned are (This will be updated and shrinks with time):
- Allow text input for diagram elements that are not extracted (Comparable to the plantUML class diagram)
- Provide a history
- Provide a preview feature to show what is around the currently displayed elements (This is now not so much needed anymore as diagrams can now be much easier changed
- Allow searching in layouts
- Provide a redo button
Please give me feedback, either by comments to this blog or by opening issues in github. What do you need?
I will update this blog during implementation.
Hi Rainer!
It looks wonderful and pretty interesting, even only from a visual impact: i'm fashinated by these diagrams, recalling a bit The Matrix.
This is a project i admit i do not know if it could be useful in day by day development but surely it could impress during a presentation and could be used to identify critical objects (from what i'm understanding ) in a complex architecture.
i'll keep an eye on it!
Wonderful work!
Hi Simone!
thank you very much for the feedback!
Each tool adds complexity to the work, so I try currently to make the tool less complex. I think we have always to find out whether a tool helps us, or just makes our work more complicated. I do not believe that there will be a general answer to this.
Best regards,
Rainer
Hi Rainer,
I've tried to check some packages of our system (ca. 4000 classes), but unfortunately I'm not able to get the graph running... In some cases, I'm also getting an unexpected message.
Do you have any idea? Thank you.
Kind regards,
Stefan
Hi Stefan,
if you have 4000 classes and run the diagram without limiting the amount of elements to be displayed, there will be a very big amount of elements to be displayed. This can work, but I would not be surprised if it fails.
A solution is to limit the amount of elements before displaying the diagram. For this search for the relevant methods in the Moose panel. You can use the statement 'MYMETHOD' = each name (case sensitive) or '*mypattern*' asUppercase match: each name (A pattern search, not case sensitive) to find your elements faster.
Then click on the folder evaluator and send a statement like
RWDiagram suppressOthersUsedByLayers: 1 usingLayers: 1 to: self.
This should lead to a much smaller diagram.
The runtime is probably still high, I wait currently 2 minutes for an mse file with 2700 classes , 14500 accesses and 8200 methods before a small diagram is displayed. I plan to improve this.
I will be happy if you open an issue for this in github to document and track the solution (https://github.com/Moose2Model/Moose2Model/issues). It is OK if you do not do this, in that case I can do it 🙂
In case it does not help, what is written in the unexpected message?
Kind regards,
Rainer
Hi Stefan,
I opened and solved issue https://github.com/Moose2Model/Moose2Model/issues/21 . You can download now a new image v.0.2.2. Here a Pop Up will be displayed that warns if a diagram is generated for all elements. And I explain now better how to circumvent this problem.
Kind regards,
Rainer
PS: A message is send with Ctrl-D "Do It", I hope that my explanation is clear enough.
PPS: I have still no solution for the performance problem with big models.
Hi Rainer,
You are really fast 🙂 Thanks for that. I've tried to apply the filter to the methods and/or classes, but I don't know how to start the "RW dependency graph". On the filtered objects I didn't see any options.
One thing I was not aware in the first place (but after watching at the example graphs more in detail): Every method and attribute would be considered as one dependency, right? Is it somehow possible to "aggregate" them? So, in the first place I'm not interested in which method/attribute is used by which method, but I would like to investigate the dependencies between classes/interfaces - like the big ball of mud...
Thank you.
Kind regards,
Stefan
Hi Stefan,
displaying dependencies of “packages” and “classes” is not yet possible
I thought of this already… The best for me would be, if you open an issue for this in the github repository (I try to motivate people to open issues on Github, I learned this from Lars Hvam, who started abapGit. It is very easy and transparent
. And it saves time for the main developers of the project, you should not forget it is done on top of the other duties.). I plan a lot of improvements in the next 12 month, and this requirement is surely on my lists of things that should be done.
You can:
Kind regards,
Rainer
Hi Stefan,
this is now possible with release v0.4.0. By setting the scope to package or class only packages or classes are displayed together with their dependencies.
I made some tests and find it very helpful.
Kind regards,
Rainer
Hi Rainer,
You are really fast 🙂 Thanks a lot. I will try it later.
Kind regards,
Stefan
Hi Rainer,
I've created this issue: https://github.com/Moose2Model/Moose2Model/issues/22
In the matter of contributing, I'm still struggling with myself to do so 🙂
But, let's discuss it on the issue in GitHub.
Kind regards,
Stefan
Hi Stefan,
thanks for the issue, I added already a comment to it.
I understand your hesitation to contribute, most Open Source projects I see have only a very few number of active maintainers that make the majority of coding (often just one). Correcting a simple bug is simple, but to add a complete function into a complex application written in language someone is not trained in (Smalltalk) is very time consuming. I spent a few months just to learn Smalltalk.
Contributions can also be made to the documentation and by adding issues. I do my best to write a good documentation, but I am sure you had problems that are due to documentation errors I made? Contribute to documentation is simple. Fork the repository, make the changes and make a pull request.
Lars Hvam made it once to SAP2Moose and it is really fast, faster than if he would have sent me an Email describing the bug.
I will do my best to find a solution for this issue
Kind regards,
Rainer
See above comment, solved with release v0.4.0.