Ten Reasons Why CASE Tool Programming is Harder Than, say, Game Programming
Ten Reasons Why CASE Tool Programming is Harder Than, say, Game Programming
Join the DZone community and get the full member experience.Join For Free
Java-based (JDBC) data connectivity to SaaS, NoSQL, and Big Data. Download Now.
Looking at the graphical output of a CASE tool like AgileJ StructureViews, the 2d picture it creates, while informational, is somewhat tame compared with the rich graphical 3d worlds created by computer games. Simple lines, text and a few icons appear dry and lifeless compared with the varied textures and landscapes of a game – not to mention the effects and behaviors like liquids or explosions which are routine for games and motion graphics software. Ideally, we would like software structure visualization to be as vivid as playing a game or watching a movie, but CASE tool development is weighed down by a number of additional concerns which leave reduced development resources to devote to the graphical layer. This article lists those additional other concerns.
- Platforms. Many games run on a single platform and this frees the programmer up from having to continually consider platform portability issues. If the product works in development then it will probably work the same way in deployment. Java does help us a lot with developing for the three main platforms, MS Windows, Mac OS X and Linux, but there is still a lot of effort required to test across supported platforms. It is surprising how the quality of graphical content in Java varies between these platforms. The speed and clarity of graphical content rendering are impacted by the operating system and the hardware and what looks fine and renders quickly on one platform often lacks resolution and speed on another.
- Java versions. Thankfully, the Java language is settling and maturing well now. But changes between Java versions (Java 1.4 to Java 1.5 comes immediately to mind) introduced a great many new constructs which had to be supported. In particular the introduction of parameterized types had an impact on how class diagrams are displayed. Not only do the parameterized types have to be displayed in methods and fields, they have an impact on containment relationships too. It makes sense, for example, to show a relationship between two classes using the contained type rather than the container.
Hence supporting a shifting programming language demands model changes in the CASE tool.
- Eclipse versions. Eclipse takes care to avoid having new versions break old plugins. There is a rule in the use of Eclipse packages that if the package name excludes the word ‘internal’ then it is part of the platform API and will remain stable from release to release. However, if a package does contain the word ‘internal’ then it is fair-game for change between Eclipse versions. Even so, the scope remains that subtle differences in the implementation of the API can have unexpected effects across versions. Furthermore Eclipse, being an SWT application and therefore using native graphics where possible, varies in its behavior across platforms. In particular we have found, and had to create workarounds for, the different ways native image components operate and the image size constraints they impose.
- Undo and redo. Support for undo and redo adds whole layers of complexity on its own. The real world doesn’t support undo and redo (although we sometimes wish it did), games don’t generally have to worry about undo and redo either. However, that policy is not acceptable for a CASE tool. We expect Ctrl+Z to take us back to the previous state. While that sounds simple enough, anyone who has implemented undo/redo buffering will tell you that it is complex. Firstly, the application must constantly keep a record of actions taken and buffer them ready to be undone. Secondly, it is not sufficient to just restore a previous model state – the user must be shown that state restore happening otherwise, without feedback, the user will doubt that the undo action has had any effect. Hence along with recording each action, the display parameters must also be recorded so the action can be ‘played back’. Thirdly, the undo and redo buffers can lose integrity if a further action is executed after restoring a previous state. Fourthly, actions happen in clusters. For example, selecting then repositioning multiple classes, while it may be implemented as many separate actions, must be undone or redone in a single step.
- The file system. Games rarely involve the file system, well more specifically, games rarely involve user interaction with the files system. Apart from the usual backslash vs forwards slash issues. It’s even harder when you consider that the Eclipse IDE contains a workspace with many projects. Each project has source folders and buildpath entries. This really goes for the clipboard and drag and drop support too. These are not features which the finished product can boast about and most users don’t even notice they are there. But if they were missing it would seem strange.
- The combinations of possibilities in the Java model. Inner classes, templatized types, sourcecode/bytecode, code which doesn’t compile and refactoring tools all make it complex to model object oriented Java software under construction. To be fair, the Eclipse Java model mostly performs exceedingly well building inheritance trees, presenting code completion options and indexing the model according to multiple facets – but there are some Java model issues such as dependencies for which we have to create additional Java modeling code. This additional modeling code takes time and the development of a lot of test cases. The point is that the Java model is made of up of multiple 2d graphs like the dependency graph, the inheritance graph, the packages/bundles graph, call graph and composition graph. Hence the Java model far exceeds the familiar 3d world most games have to model.
- Integrating with the ide. Early CASE tools were programming language independent and were stand alone applications. This made things simple as the application could be built from the ground up without worrying about interaction and integration with other software development tools. But the main limitation of the stand alone approach was that effort was required by the user to keep the CASE model in line with the implementation in a real programming language like Java or C++ happening in a separate IDE. Fortunately, IDEs like Eclipse offer excellent facilities for third-party tool vendors to create plugins which integrate with the programming environment they contain. This affords an excellent opportunity to tap into high-quality models in the IDE, but the downside is that it takes time to understand the APIs offered by the IDE. Most games are written for a platform, such as Android rather than for a framework. Yes, you can write mods for Minecraft, but the mods are more like tweaks to an existing game as opposed to whole games being written by plugging into a generalized gaming framework.
- Text/fonts. Games rarely need to render large volumes of detailed text. Whereas CASE tools are required to present large amounts of detailed text. Badly scaled, fuzzy text is not acceptable. The entire diagram zooming mechanism in AgileJ is therefore built around letting the underlying platform graphics layers render text at fixed point sizes. The layout of the class diagram is built up backwards from the size occupied by each piece of text. Text rendering is a heavily time consuming aspect to CASE tool development.
- Printing. Exporting.Â Games don’t generally ever print anything or export graphical content ready to be opened by another application. However, printing and exporting are significant functions for CASE tools. People like to print class diagrams for reference, or export the content so that it can be embedded in other documents. Unspectacular as this is, printing is complex because of the page breaks, labelling each page and giving a preview of how pages will be printed.
- FIltering. Finally, there is a need within CASE tools for filtering down the volume of information which they present. This is akin to switching on or off a number of options within an online map application – things like terrane, roads, traffic information, place names, boundaries. In a CASE tool such as AgileJ StructureViews, the filtering controls the content which is displayed and sifts through rules configured for each Java element to determine what to display and how to display it. This filtering layer lies between the Java model and the presentation layer. The tools which allow the user to specify the filtering, and the filtering mechanism itself are important for the usefulness of the product as they simplify the graphical content and reduce the detail which is presented – not something you ever want a computer game to do.
Working on a modestly graphical application like a CASE tool is probably not a fair comparison with the intense graphical content of a game. Games are built first and foremost around how they look and behave – and this puts games programmers in the enviable position of creating smooth, detailed worlds. In the future, code visualization will head nearer to a comparably well rendered, interactive world in which software under construction will be navigated more like a 3d world than the primitive 2d world it currently occupies. CASE tool development has a lot of catching up to do.
Published at DZone with permission of Paul Wells , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.