Software Engineering Journey: From Design to Skeleton Code

I have been delivering lectures on software engineering (SE) for quite some time now. A lot of emphasis in SE is laid on activities such as requirements gathering, specification development, design, testing. There are other ideas such as adoption of appropriate process models and agile practices that are considered important. We hear about the waterfall, V, sawtooth and spiral models. Then we learn about extreme programming and confuse them with computer programming and process models. Considerable emphasis is also laid on development of software. But the erstwhile mentioned peripheral activities are talked about so much that development issues receive little attention. Even when we were students, we began to realize that design and specifications are the most important parts of any SE process. So much so that we began to believe that the enterprise of SE has got nothing much to do with software development. This flawed awareness is somewhat also always a source of great happiness especially for students who are shy of software development.

So as I taught I also reflected on how big of a deal software development is.

My thought process triggered by the use of a UML to code generation tool called easyUML. This is a plugin for the Netbeans IDE. It allows users to draw a UML class diagram. Once the diagram is drawn, skeleton code of that can be generated with a few clicks through the IDE.

I tried the tool and appreciated how easy it had made the life. Code of the whole project emerging automatically through the design can sound miraculous after all. What you get is skeleton code of all the classes and interfaces. Fields and methods with empty bodies are declared in them according to the design.

Then I reflected on what the easyUML does on the backend to generate such an elegant looking skeleton code. easyUML leverages from tools that are used to develop compilers. Parsers and interpreters are common nowadays. So if you provide such tools with an abstract representation of your software, they simply create the skeleton code for you. To this end, easyUML is not as miraculous as it might seem after its first use. A little contemplation reveals that its capability is not a big deal given the current state of the contemporary technologies. It is nonetheless a great tool.

It will begin to appear a lot less miraculous if we understand what it really does in essence. It takes as an input a UML diagram and generates code for it. The diagram has blocks and edges in it. Blocks represent classes and edges represent relationships between them. Blocks also contain fields and method signatures. If we were to develop code through such a diagram in Java, essentially we would be developing a source file for a Java class for each of the block. We would use the information provided by each of the edges to develop composition and inheritance relationships between Java source files. Translating a design diagram to code is as simple as that. Once we understand this, we realize that easyUML is not miraculous at all. Reiterated, it is still a very handy tool.

So once I realized this with much clarity, I though what remains of the code then? Well, the only thing we are left with is to write code for the methods. Once we have implemented all the methods correctly, we are done and dusted with the nuisance of development.

But how easy or difficult it is to implement methods? This is something we should figure out.

Photo by Seth W.