Comparing CASE Tools
Programming by design
Jeffrey L. Armbruster
Jeffrey is team leader of the Windows Development Team at Aircraft Technical Publishers in Brisbane, California. He can be reached on CompuServe at 72711,3565.
Adopting an object-oriented design methodology can be the single most important step you take to improving your software-development process. An OOP methodology crystallizes (or exposes) a system's philosophy and psychology. Without a methodology, a system is shrouded in mystery.
What makes a good CASE tool? Detailed opinions appear in the accompanying text box entitled, "Expert Opinions." In general, most people agree that a tool should:
- Offer several methodologies and be able to switch between them on the fly.
- Check for logic errors.
- Animate the execution of the diagram.
- Be inexpensive.
- Be easy to use.
- Allow easy browsing through the class hierarchy.
- Allow you to brainstorm your diagrams in a nonlinear fashion.
- Allow you to enter code onto a diagram, then update the diagram.
- Separate object-model components into categories of responsibility.
- Provide version control for diagrams.
- Support work groups (multiple users).
- Reverse-engineer existing code.
- Have hooks into other API Frameworks (such as Microsoft's MFC, Borland's OWL, and Rogue Wave's DBtools.H++).
- Print large diagrams (that is, map large diagrams across 8.5x11-inch pages).
- Generate code.
The CASE tools I examine here--ProtoSoft's Paradigm Plus 2.0, Select Software Tools' Select OMT, and Object International's Together C++--let you place symbols to represent classes. Connector symbols representing inheritance, composite classes, or messages can then be inserted between the classes. The end result is a model of the behavior of components within your system. The diagramming symbols used by the tools represent the philosophy of a particular methodology for designing classes and defining their relationships within a program. Instead of viewing the system at the microscopic (that is, code) level, you see it at an eagle's height, using symbols. Since design is iterative, making changes to the system is painless, as the CASE tool reprints the system for you. Table 1 lists the features of each tool discussed in this article.
The PriceView Example
To examine the CASE tools, I've designed "PriceView," an application that collects pricing information in grocery stores. As a service to customers, the program provides them with a price audit.
PriceView (PV) consists of two components: one application that collects product prices in grocery stores and transmits the data to the corporate level, and another that generates reports from collected data stored in the corporate repository. In this article, I'll concentrate on the report generator.
Inputs to PV include customer name and address, store name and address, the stores to be price-audited, the type of audit ("Full-Store" or "Customer-Provided List"), items to audit, and audit data from the stores. For a Full-Store price audit, PV audits all of the items found in the store. For a Customer-Provided List, the list of items to be audited are transmitted via modem to the in-store auditor, unless another customer has requested a Full-Store audit.
PV has several outputs: a management report that includes the number of stores audited during a given week, the number of items audited, and the number of customers that ordered an audit for each store. This report tells management PV's gross sales and income for the week. The "Price-Audit Manager Report" is created to schedule workers to collect the data at the various stores. The "Customer Item-Price Report" lets customers see the price-audited items in spreadsheet form.
Object-oriented methodologies show class relationships in a system--an application's potential behavior--more than they show program work flow. For the event-driven behavior of modern GUIs, an OOP methodology detailing class relationships is more relevant than a work-flow or data-driven diagram.
I've set up the PV model as a hier-archy of classes, with the PriceViewCorp class as a starting point. PriceViewCorp has an aggregate relationship (Booch, Rumbaugh) with the classes Store, Report, and Customer. An aggregate relationship forms a "has_a" or "part_of" relationship. In this situation, PriceViewCorp is the parent, or owner, of the parts has_a Store, has_a Customer, and has_a Report. (I won't complicate this example with the additional detail of attributes and messages/functions for each class.) Store uses Report, AuditType, and AuditData to form an aggregate relationship. The AuditType class has two generalization/specialization (Coad/Yourdon) classes connected to it: FullStore and CustomerProvidedList. A generalization/specialization relationship indicates class inheritance. So the FullStore class is_a type of AuditType, and CustomerProvidedList class is_a type of AuditType. Finally, the abstract/generalized class Report has the Management, CustomerReport, and AuditManager classes making specialization connections to it. The class Customer has the AuditSubscription class as an aggregate relationship.
Paradigm Plus 2.0
Paradigm Plus 2.0 requires that you attach a dongle to a your machine to run the software. Paradigm Plus (PP) also requires 8 Mbytes of hard-disk space and the standard Windows 3.1 configurations. PP can be configured as a single- or multiuser tool. While installation is generally straightforward, network installation can cause headaches because the software acts as a network file server, database server, license server, and client workstation. However, the documentation is complete enough to walk you through the process. I opted for the single-user version and the installation was hassle free (except for crawling behind my floor-based tower to plug in the dongle).
PP comes with a user's guide/tutorial, a methods manual, and an installation manual. The methods manual helps you understand the diagramming symbols if you have not read a methodology text from one of the methodologists supported by the tool.
PP supports six methodologies: Rumbaugh et al., object modeling and design, Booch, fusion, Coad/Yourdon, and Shlaer/Mellor. The methods manual briefly illustrates the symbols used with each methodology, but it's enough to be familiar with one to start using the application.
In PP, you select one of the object-oriented methodologies, name your project, then place and position symbols on the screen to identify the classes and their relationships to PP; see Figure 1. You click on one of the symbols from the symbol toolbar to put Paradigm Plus into the drawing mode of that symbol. The cursor changes to help you see which symbol-mode you have activated. You then place the symbol on your diagram. You can name it by typing in the name or you can keep adding symbols to quickly brainstorm your idea into PP. I named my classes and tried to generate C++ code, but Paradigm Plus returned an error message until I added attributes and functions/messages to the classes.
At any point when building your model, PP will generate Ada, C++, Smalltalk, or SQL code from your diagram. Mastering a methodology and using its principles and symbols to write your programs will improve the quality of your code. You will reduce your errors and false starts and see the weaknesses and strengths of your program before you've written a single line of code. And because the CASE tool writes the code for you, you can easily rearrange the symbols to improve your design. It is the difference between standing on a street corner reading street signs or seeing all of the streets on a map. A methodology provides a detailed, disciplined map.
The question many programmers ask, however, is whether CASE tools improve or impede the development process. I believe they improve it. For instance, PP provides an alignment tool for tidying up your diagram by centering or justifying the symbols (a feature missing from the other CASE tools in this article).
Paradigm Plus also allows you to nest or level a diagram. This is an important feature when you're working with a lot of classes on a single screen. You can make an object explode or implode into a subdiagram, allowing you to zoom in to or out of your model's detail. This allows you to layer your model into Microsoft's MFC Document/View or Smalltalk's Model/View/Controller architecture, for example.
Additional Paradigm Plus features include reverse engineering of existing C/C++ code; availability for Windows, Windows NT, Sun, HP, AIX, and OS/2; a Basic-like scripting language to customize its behavior; multiuser support; the ability to generate SQL code for Versant, Objectivity/DB, ONTOS, ObjectStore, Oracle SQL, IBM's SOM, Raima Object Manager, and HP's Open ODB, and the ability to generate C, C++, Ada, and Smalltalk code.
In general, Paradigm Plus provides a robust set of tools. The Object Browser, for instance, lets you view and edit the relationships between all of the objects within your diagrams. You can view and edit your project using the matrix editor, a spreadsheet with the rows representing inherited classes, and columns repre-senting base classes. A class may be made into a generalization of another class by double-clicking on an intersecting cell. I prefer indicating the relationships in the diagram editor, but the matrix editor can also be used to double-check yourself. The table editor gives you another spreadsheet view of your project. The rows display the name of each class in your diagram, and the columns display metaclass information (additional data that Paradigm Plus allows you to collect for each class).
Select OMT
Select OMT uses the Rumbaugh et al. object methodology technique (thus the "OMT") exclusively. First, you create a project, which in turn creates a directory to store the project's associated files. You then open either an object-diagram, state-diagram, or general-graphics-diagram window. The general-graphics-diagram window allows you to create a (Demarco) data-flow, object-instance, or an event-flow diagram, but not to generate code. For the PriceView example, I used the object-diagram window to construct the classes in Figure 2. This was easy: You click on the object-diagram window, and a pop-up menu prompts you to select Class, Ternary Association, Free Format Text, or Free Format Box. If you select Class, Select OMT prompts you for the class name, then paints a Rumbaugh class symbol on the screen. Some CASE tools force you to fill out all of the class information (attributes, services, operations, and the like) before allowing you to add another class--a real annoyance. Select OMT allows you to brainstorm your entire model, prompting you only for the barest essentials, permitting you to rapidly see your model before worrying about the details. When you're ready to add the details, click on the class and OMT pops up the class-editor dialog box. This is where you can add/delete class attributes and operations, get a preview of the code that Select OMT will generate for your class, and enter comments and descriptions that will be included in your code.
At some point, your diagram will become too large to fit on one screen. You can either zoom out or use the Dictionary Item Selector to browse through all of the classes in your model and view their context. From here, you can edit the item and check its usage within your model. If your model is huge, the dictionary lets you create a type filter so that the dictionary displays only those items that meet your specified type. Select OMT has the standard paint features for moving groups of classes and tidying up your diagram. At any point, you can generate or simply preview your code. The code can be generated to a file or copied to the clipboard and imported into your favorite Windows-hosted editor.
Select OMT can also print a tiled diagram (mosaic printing), allowing you to see the full scale of your project by tiling the printed sheets on the wall or the floor. Select OMT's printing feature is the best in the group. In the multiuser environment, you can lock out prying eyes by requiring a password. Select OMT also allows you to view more than one diagram at a time. It is not as feature rich as Paradigm Plus, but you can get a lot out of this tool for a lot less money.
One peculiarity was the difference in the code Select OMT and Paradigm Plus generated. If a class had an association/aggregation relationship with another class, Paradigm Plus would generate a bidirectional pointer connection. That is, class A would contain a private pointer to class B, and class B would contain a private pointer to class A. Rumbaugh specifies this bidirectional connection in his text. However, Select OMT simply adds a comment in both classes denoting that they are part of an association/aggregation relationship.
Together C++
Together C++ uses the Coad/Yourdon object methodology, which is so clean and simple that you may be able to use Together C++ without reading a book that explains the methodology. (Coad/ Yourdon symbols are subject, abstract class, object class, generalization-connector, specialization-connector, message line, and a subset of the standard flowchart symbols.)
Together C++ opens with four windows. You diagram your model in the object-model window; see Figure 3. The other three windows contain the classes in your diagram, subjects, and graphical views of your project. The exciting feature is that if you type in the code in the editor window, the diagram window will be updated and vice versa. Your code and diagram always reflect each other. You create a Class-Object either by clicking on the right mouse button and selecting class or subject from a pop-up menu or by clicking on the Class-Object icon in the floating toolbar. Together C++ will prompt you for the name of the Class-Object and generate the .hpp and .cpp files. Together C++ arranges the symbols within the object-model window; you can override this feature by switching to manual or semi-automatic. In semi-automatic mode, you arrange the symbols and Together C++ arranges the relationship connections. In manual mode, you handle arranging the symbols and the placement of their connections. Manual mode also allows you to show the class multiplicities (one-to-many or one-to-one relationships between Whole/Part classes) for every class on the diagram. The other products hide the multiplicities in the code comments.
At any time, you can add comments to your code and Together C++ will record them automatically. (Comments aren't so easy to add with the other tools.) If you add attributes, services, or comments to your code using an external editor, Together C++ will parse your code and update the graphics symbols of the diagram model. If you want to use Together C++ with an existing project, Together C++ will parse your code and build the diagram model for you. The reengineered diagram will need to be rearranged (it will be all jumbled up across the screen), but it will accurately reflect the model buried in your code. In fact, of the three tools discussed here, Together C++ has the fastest, most-accurate parser/reengineering tool.
Together C++ also contains a version-control system so that a team of developers can use Together C++ for the same project. The team members share a revision control system (RCS) directory on the network, and Together C++ contains a menu for locking and unlocking the project's new and updated code and diagram files. It also keeps a history of the changes. When the diagram begins to look like a spider's web of connections, you can selectively hide symbols within the diagram, making it easier to read and update. You can easily bring all of the hidden symbols back with a single menu command. Together C++ contains many browser windows that allow you to see all of the files connected to the project, including the .cpp and .hpp files and all of the classes, attributes, services, and types of connections to other classes through generalization or specialization.
Like the other CASE tools examined here, you can control the default options used by the program, such as setting attribute types from ints to chars for the generated code, building comment templates, changing colors, and so on.
Conclusion
None of the CASE tools I've examined here is perfect. It would be great to take the best features from each and build a single toolset. Yet, any one of these tools will go a long way toward making you a better designer, developer, and programmer. Paradigm Plus is the most comprehensive. It doesn't lock you in to a single methodology, and it allows you to layer your diagram, with each layer revealing greater detail. However, Together C++ contains the best parser--if you enter code in one window, Together C++ updates your entire diagram. It is also the best at parsing code for an existing project. But it is weak at layering--you have to hide each class and its subject one at a time. This is not as clean and quick as Paradigm Plus. On the other hand, Paradigm Plus's steep price tag may be a sticking point for many developers. Finally, Select OMT is the best at printing your diagram, the easiest to get up to speed with, and the least expensive.
For More Information
Paradigm Plus 2.0
ProtoSoft Inc.
17629 El Camino Real, Ste. #202
Houston, TX 77058
713-480-3233
Select OMT
Select Software Tools Inc.
1526 Brookhollow, Ste. #84
Santa Ana, CA 92705
800-577-6633
Together C++
Object International Inc.
8140 N. MoPac 4-200
Austin, TX 78759
512-795-0202
Expert Opinions
When it comes to CASE tools, everyone has an opinion. Here's what some leading methodologists and programmers have to say about computer-aided software engineering:
Ed Yourdon. The best CASE tools allow the analyst to model requirements or software architecture in diagrams (and then have the tool generate the code). Some essential elements are:
- Flexibility of diagramming, so the CASE user can see whatever he wants, in whatever form he wants to see it.
- Good error checking to enforce the OOA/OOD methodology.
- A low price, so that you can experiment with the methodology without feeling you've made a "religious" commitment to it.
Larry Constantine. An excellent CASE tool is more than a diagramming tool. It must actually support the work of real developers working within particular methodologies. The CASE vendor needs a deep understanding of the techniques and modeling processes that can only be gained from actually using the supported methodologies. The tool's user-interface design should reflect careful attention to detail. Common tasks should be simple to perform and reflect how developers think about software problems. In the hands of skilled software developers, a CASE tool should fade into the background, becoming an extension of the developer's thought processes.
An outstanding CASE tool permits the analyst/developer to move seamlessly back and forth between different models and between different views of the same underlying model. A user should be able to develop a data-flow model in one notation and instantly switch to another; to move through interconnected models--class hierarchy, object communication, functional decomposition of methods, and code--as smoothly as navigating through hypertext. The best CASE tools support the iterative, nonlinear thinking and exploratory processes of real system development and evolution (as opposed to the linear and limited life-cycle models enshrined in textbooks and methodology courses).
Peter Coad. An excellent CASE tool should have the object model in one window and C++ in the other. You can edit in either window, and the two update themselves continuously.
I build object models by identifying purposes, finding objects, establishing responsibilities, and establishing dynamics with scenarios. Therefore view management and filtering are necessary for viewing specific object-model components (problem domain, human interaction, data management, task management, system interaction), subjects (groupings of objects that are meaningful to look at together), and each scenario, with its objects and its scenario-specific responsibilities.
Grady Booch. The ideal CASE tool should aid in the creation and visualization of architectures (instead of just producing pretty pictures). It should be tied to back-end tools, for both forward and reverse engineering, and it must manage the tedium of crafting complex systems by having enough semantic knowledge to check for consistency and correctness of the system being architected.
"Must-have" features include deep semantic knowledge of the notation; coupling to other tools via APIs, mechanisms such as OLE, scripts, or programmatic means; multiuser support; and the ability to scale up to complex things.
James Rumbaugh. Transparency is a key element of an excellent CASE tool. The mechanics of using the tool should fade into the background--manipulating the notation directly should be as easy as using a piece of paper. Many Macintosh, UNIX, and Windows programs embody this quality, including programs for desktop publishing, financial management, spreadsheets, drawing tools, some methodology tools, and so on. The lack of transparency has been a drawback of many CASE tools in the past.
Must-have features include a good balance between simplicity and power. This is easy to state, fairly easy to recognize, but much harder to achieve. When a tool tries to do everything, even simple tasks become difficult because the user has to make so many choices. A good tool makes common things easy to do at the expense of more unusual things. A good tool doesn't try to automate everything (as some AI tools tried to do); instead, it should automate the simple things and provide a straightforward way of accomplishing the difficult things, perhaps by some textual escape hatch. A good tool has well-chosen defaults so that the user can get started without making choices and can later tailor the results by selecting options. For example, a C++ code generator should come with some well-chosen defaults that work most of the time but can be overridden.
Stanley Lippman. I appreciate your including me in a somewhat-august group. However, I have never used a CASE tool, nor have any of my colleagues here. In fact, I personally don't know of anyone writing code who uses a CASE tool--although I know many excellent designers and programmers. Looking at internal job postings and talking with people leads me to believe that CASE tools tend to be mandated by management, in many cases due to a sense of unease about controlling a software project new to OOP. Methodologies and CASE tools seem to be most fervently espoused by those the least technically astute. This is a developer's point of view, of course; one who has never worked in a large project (100+ developers) or contracted to supply a system to a client--the domains where CASE tools may prove useful.
Stephen J. Mellor and Rod Montrose. Essential elements of an excellent CASE tool include: group support (analysis is a group activity); configuration control, at least to the diagram level; enforcement of a particular method (this is in contrast to the popular CASE drawing tools that only provide notation support); flexible reporting and printing; support for large diagrams (software engineering is the only engineering discipline that insists on keeping everything to a 8.5x11-inch sheet of paper); ability to view multiple diagrams on the same screen of the current project and other past projects; and database integrity. This last includes self-checking/repair, administration utilities, and security levels. The only way to evaluate a CASE tool's effectiveness is to use it on a moderately sized project with three to four engineers. With this type of testing, initial impressions such as user interface will be far less important than method support. Remember, the CASE tool can only support what the method supports, and the benefits to a project come from the practice of a method, not just its automation.
We approach must-have features from the Shlaer/Mellor angle. Its three main characteristics are: partitioning of a problem into domains; rigorous analysis of each domain and execution of each domain's models; and translation of the analysis of each domain into an implementation. In a CASE tool, this would result in: support for domain charts, subsystem models (subsystem-relationship model, subsystem-communications model, and subsystem-access model), and bridge descriptions; and support for the analysis diagrams for each domain, including the object-information model, object-state model, process model, object and attribute (textual) descriptions, object-communications model, object-access model, and thread-of-control chart. Ideally, CASE tools would have a detailed checker that could critique the analysis models and support for simulation and execution of each domain's analysis models. Many defects traditionally discovered using debuggers would be uncovered using an analysis simulator, and a translation engine would accept an architecture and the analysis models to produce 60 to 80 percent of the final system code.
--J.L.A.
Table 1: CASE-tool comparison.
Select OMT Paradigm Plus Together C++
Methodologies supported Rumbaugh Rumbaugh Coad/Yourdon
Coad/Yourdon
Booch
Shlaer/Mellor
Fusion
Animate diagram execution No No No
Cost Under $1000 Under $4000 Under $1000
Class-hierarchy browsing Yes Yes Yes
Brainstorm diagrams Yes Yes Yes
nonlinearly
Dynamic updates between No Not easily Yes
code and diagram
Separate object-model Yes Yes Yes
components into cate-
gories of responsibility
Diagram version control Yes No Yes
Support work groups Yes Yes Yes
Reverse-engineer existing Yes Yes Yes
code
Hook into other API No No Yes*
frameworks (MFC, OWL,
Rogue Wave's DBtools.H++)
Print large diagrams Yes No No
Generate 3GL code Yes Yes Yes
Hierarchical layering No Yes No
or nesting of diagrams
*<I>requires adjusting the diagram after it parses the MFC or OWL code</I>
Figure 1 Creating classes and their relationships using Paradigm Plus.
Figure 2 Constructing classes using the object-diagram window in Select OMT.
Figure 3 Object-model view in Together C++.
Copyright © 1995, Dr. Dobb's Journal
