History
I know what you think about this section, nonetheless, I consider important to keep the history alive. So... Do not worry, you can JUMP this section without any problem. Just coming back here when you have time, ok? (maybe on the bus) 😉 So... Here we go, this section explains Kuniri history and elucidates our motivations.
In September 2014, I had a healthy and fun discussion with my professor and co-works about the importance of having a class diagram of the project. At that time, I argued that class diagram is extremely useful to make easier to understand the project, the architectural possibilities, and it is programming activity too.Additionally, I defended, that is not necessary to spend a lot of time to create a perfect UML diagram, because I believe the traditional way to use it is really tedious. Usually, I just use some drafts of a sheet of paper without care to form, normally, I keep my attention on a class relationship and object behavior.Notwithstanding, my professor and colleagues told me that class diagram is a huge overhead under the project and not useful. We had a very good debate about it for hours, but in the end, we did not agree with each other.
Instead of keeping the discussion, I decided to find a way to proving my point, so I idealized a tool for make simple and fast the extraction of a class diagram from any kind of code. My goal was removing the tedious step of creating a class diagram manually, and made it flexible for any kind of language. With this idea in mind, In December 2014, I started Kuniri project focused on class diagram extraction.
I decided to use Ruby on Kuniri's project, because I did not know any script language, all my background came from C, C++, Assembly, and Java. Afterward, I realized that Ruby was a great choice because the way in which this language handle Regex and all the features provided by it.
After many lines of coding, I decided to show my work to my friends. When I explained my idea to my friend Gustavo Jaruga, he really liked it and shared with me thousands of nice ideas. After some weeks, me and him had many discussions about Kuniri's architecture, and he became a kuniri co-author. When we have seen our first results, we decided to share it with professor Paulo Meirelles, and he said to us: "How about trying to write a parser to be used in the analyso project? You already have it in your Kuniri project.". After his comment, we just considered it, and changed the focus of the project. We decided to create a generic parser, and make the UML extraction a different tool.
