Tuesday, December 5, 2006

Object Oriented CASE Tools: Lost Opportunities and Future Directions

Those of you that have been around long enough might remember the glory period of the traditional CASE tools and structured programming. These were the days where a lot of people were experimenting with CASE tools and even went so far that they started to predict work estimations using function point analysis. The main drive was that companies wanted to get their IT projects under control again. In the late 80s, the traditional CASE tools were victorious in a lot of large companies because of this reason. These tools had a decennium to learn from their mistakes and from the mistakes of others.

In the early nineties, with the rise of Object Orientation, the traditional CASE tools were perceived as a failure by many people. The root cause of this bad perception was that the tools a) failed to embrace OO, and b) were used in combination with traditional software development processes. This caused traditional CASE tools to be strongly associated with the waterfall methodology, at a time when iterative development and rapid application development were increasingly gaining momentum. With the rise of the OO CASE tools (Popkin Architect, Rational Rose, Cool:Jexx, etc.) in the mid-nineties, everything was reinvented.

As with most software products, the CASE tool market is highly feature-driven. However, CASE tools have been around for more than 20 years, and one might expect also some mature features. The irony of it all is—as I will illustrate further in this article—that a lot of features with high user value can be implemented; it's not that there are rational reasons to not do it.

This article outlines some important aspects that today's "best of breed" OO CASE tools could learn from the traditional CASE tools. A generally applicable rule—which we forget frequently in the software industry—is that we should not neglect the experiences in a very similar domain just because we have labeled it "old-fashioned."
An Object Oriented CASE History

For the purposes of this discussion, I will identify three "generations" of OO CASE tools:

First Generation OO CASE Tools: Diagramming Tools


Diagramming tools only allow the modeling of ideas—things like concepts, analysis artifacts, etc. There's no link to code. Everything is maintained manually.

The first OO CASE tools still had the "diagramming dialect" battle to fight, which made comparing the tools quite difficult because people were more comparing the diagramming dialects than the tool's features themselves. (You may remember the "OO notation wars" before Rumbaugh, Booch, and Jacobson got together on UML and ended the controversy.) After the introduction of UML in the late nineties this was resolved.

Second Generation OO CASE Tools: Code Visualization Tools

A "code visualization" tool is a form of diagramming tools that knows how to "harvest" code and map it onto a model of classes and diagrams (this process is also known as "reverse engineering").

These tools also allow you to start from a model and to transform that into code. However, in these tools this implies that you are modeling at the lowest level—the level where you have a one-to-one mapping with code.

Typically this is not that productive, as you need quite some training and patience before you are able to get the result that you want in one go. An agile way to approach this is using the tool that suits the purpose: If you want to get an interface down on paper and you know the programming language, then just type it using a code editor. If you want a visual representation of it to be able to highlight the relationship with other classes (e.g. which classes implement this interface), then use the reverse engineering feature.

To recall an anecdote, many years ago in the Microsoft COM era I wanted to model an interface that could be generated in IDL (Interface Definition Language). It took me quite some iterations before I could get it right. Effectively, this was a waste of time because I was IDL literate: I really knew what I wanted it to look like and how to write it.

Third Generation OO CASE Tools: Computer Aided Software Modeling Tools

CASM tools assist the user in his/her choices regarding software architecture, data modeling, business modeling, etc. These tools don't solve all the problems, but rather help in coming to a solution. For example, the tool could provide a computer-aided review of your design; or it could include a data normalization/demoralization tool; or it could suggest or highlight potential "deviations," such as the use of a functional database key (e.g. customer number) instead of a technical one. These are the tools of the future. In the rest of the article, I'll outline what features you should expect of such a tool.

Lost Opportunities and Future Directions

In the remainder of the article I will explore a variety of features shared or not shared by traditional/structured CASE tools and today's "third generation" OO CASE tools, including discussion of opportunities for today's OO CASE tools to incorporate some of these features.

Before beginning this discussion, I'd like to make the distinction between a CASE tool as "tool" and as a "framework." The viewpoint of a "tool" encompasses everything I can do without any custom development. The functionality is directly accessible using the user-interface of the CASE tool. The viewpoint of a "framework" encompasses everything that can be done with the tool using custom development (that is, by using the CASE tool's API).

As a brief illustration of the difference, consider a standard feature of a CASE tool user interface: finding all artifacts with a certain name. This is a common feature. In contrast, extracting the dependencies between all classes to a spreadsheet is typically not a feature of a CASE tool. To do this, custom development—using a scripting language or a regular software development language—is required using the tool's API. I'll discuss the "framework" viewpoint in a future article, because the concerns are different.

The table below summarizes the list of features we will explore, including an indication of whether and how the features are implemented by the traditional/structured CASE generation of and the more contemporary Object Oriented generation of CASE tools.