Many modern applications are being developed based on object-oriented principles such as classes, methods, and inheritance. One of the advantages of object orientation is how well it lends itself to a notational representation of these principles. Object modeling CASE tools provide support for object-oriented modeling notations and methodologies, and they also generate parts of object-oriented applications. New versions of object-oriented CASE tools are beginning to address new languages such as Java. Many of these object modeling CASE tools also support relational databases by performing logical and in some cases physical database modeling and design, including schema generation and reverse engineering of RDBMS tables and other elements.
CASE tools offer many benefits for developers building large-scale systems. As spiraling user requirements continue to drive system complexity to new levels, the CASE tools enable us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify. The larger a project, the more important it is to use CASE technology. As developers interact with portions of a system designed by their colleagues, they must quickly seek a subset of classes and methods and assimilate an understanding of how to interface with them. In a similar sense, management must be able, in a timely fashion and from a high level, to look at a representation of a design and understand what's going on. For these reasons, CASE tools coupled with methodologies give us a way of representing systems too complex to comprehend in their underlying source code or schema-based form.
To provide this level of abstraction, object modeling CASE tools must deal with the mix of popular object-oriented methodologies, including Object Modeling Technique (OMT), Booch, Jacobson Use Cases, the Unified Modeling Language (UML), and Fusion. Notational support is only one way to categorize CASE tools. Other distinguishing features include support for multiple programming languages, the use of files or repository databases to store model information, and integration with version-control software.
Object-oriented CASE tools create diagrams that represent an object model using the notational elements of specific methodologies. These notations depict classes (including attributes, methods, and events), various object relationships (such as inheritance, aggregation, and friendship), and cardinality. In addition, most if not all of the tools available offer the ability to generate skeletal application code from models. This skeletal code typically includes class definitions and function prototypes. Developers then add meaningful underlying application logic using C++, Java, or Smalltalk, to name just a few supported languages.
Developers and designers often have needs that clearly extend beyond the boundaries of any given tool. For example, designers often need CASE tools to address logical data modeling, object modeling, and in some cases, even business processes re-engineering, all within an integrated framework. Popkin Software & Systems Inc.'s System Architect product is an example of a CASE tool that performs several kinds of modeling ranging from business process modeling to data modeling, object modeling, and structured techniques.
Although many vendors of OO CASE tools are aggressively expanding their roles to address database design, these tools are often unable to model some of the core functionality of object-oriented design, which can leave designers and developers bewildered. For example, the inability to display methods or attributes of a nested class, creation of scoped enums or typedefs, and integration with shrink-wrapped libraries are often weak spots in even the best of the CASE tools.
Meanwhile, the ability to use fewer tools to model a system that spans object-oriented design as well as relational database design is becoming more of a reality. Tools such as Platinum Technology Inc.'s Paradigm Plus (see the May 1997 issue of DBMS for a full review) and Cayenne Software Inc.'s ObjectTeam are threatening the sacred ground of logical and physical data modeling now held by Logic Works Inc.'s ERwin and Powersoft Inc.'s PowerDesigner (formerly S-Designor). To developers, this is a very positive sign. The ability to do more work with fewer tools means better integration and less complexity, which can yield higher productivity.
Many tools, such as Platinum's Paradigm Plus or Rational Software Corp.'s Rose, already have implemented, or are in the process of implementing, scripting that makes the tools more configurable and adaptable. But most project managers have not factored time and expertise into their project plans for script writing for CASE tools. Conversely, scripting creates an opportunity for third-party vendors to produce value-added packages that address areas of common interest to particular niches.
Depending on the application, active content can involve much more than simply layering a user interface on top of a database. For instance, a simple application can use an ActiveX control to obtain user input, query a database, and display the results. (See Figure 1, page 96.) This process represents a simple yet common application that can stress the design capabilities of many CASE tools. Say the ActiveX control is written in Visual Basic and is embedded in a Web page using VBScript. The control communicates through a CORBA interface to a C++ application server, which modifies the query based on some information contained on the server and then forwards the query to a relational database.
Looking at an application composed of such disparate elements, you can begin to appreciate the challenge facing CASE tool vendors who wish to provide an integrated design environment. Applications such as the scaled-down sample in Figure 1 span platforms and languages. From a CASE tool standpoint, the ability to present a single high-level view, perhaps similar to the view illustrated in Figure 1, would signify the type of integration that will be required in many future projects.
Again, referring to Figure 1, perhaps this application fulfills a requirement that was described as part of a business process. Popkin's System Architect CASE tool enables business processes to be represented graphically. A portion of a business process that might be solvable through a system implementation could then be represented in a Use Case diagram to capture an overview of the behavioral requirements.
Continuing with this example, I do not know of any notation that can represent all of the elements of this application. The Unified Modeling Language (UML) has a good chance of addressing this in the future because it is based on a extensible metamodel. The UML metamodel is a model that describes models. A glimpse at this model reveals object-oriented elements such as classes, attributes, and methods, all of which are represented by metaclasses, along with their interrelationships. Additional metaclasses could be added to the model to describe entity-relationship models, as well as extensions for dealing with interfaces such as those found in CORBA's Interface Definition Language (IDL).
Rational developed the UML methodology through the collaboration of James Rumbaugh, Grady Booch, and Ivar Jacobson. The UML has been submitted to the Object Management Group (OMG; www.omg.org) for standardization. Besides consolidating the total number of methodologies (by combining Booch and OMT), the UML core supports what information is captured and how it is interrelated, it defines standard notations for representing the information from a graphical perspective, and it supports the use of an interchange format.
The CASE Data Interchange Format (CDIF; see www.cdif.org) is an important adjunct to the UML. Although the UML specifies the type and interrelationship of information to be stored in a repository, it does not specify how that information should be stored. This is left to various vendors. The CDIF allows an ASCII representation of a design repository in a static form. This file can be used to transfer design data from one CASE tool to another, it can be used by report generators, and so forth. However, Microsoft Corp.'s recently released Repository may become a common clearinghouse for design and development information submitted by various CASE and development tools. Many vendors have announced support for the Microsoft Repository, and the next year or two will see if this potential is fulfilled.
When we talk about "code," we are actually referring to headers and prototypes in the case of C++ or Java, and to schema information in the case of relational databases. These form the basis for classes, methods, and attributes in object-oriented applications, as well as tables and columns and relationships in relational DBMSs.
Having a CASE tool generate application and database code helps ensure that the model and its underlying implementation are synchronized. This synchronization makes a modeling tool more useful to developers. Without an integrated mechanism for keeping the implementation and model synchronized, a disconnect usually occurs between design and implementation. That is to say, invariably better solutions become evident in the process of implementation. If these solutions, which often result in modifications to the design, are not properly fed back into the model, the model will quickly become out of date. The model's intrinsic value will be diminished to the point where it will not be trusted and hence not used.
Several methods of code generation are available and can be loosely described as push, pull, and push-pull (or round-trip engineering). All three of these code-generation methods have both pros and cons, and all three apply to both object-oriented modeling and data modeling (schema generation and reverse engineering). Using the push method, a CASE tool is used to modify or create a method, attribute, or class, and then code is regenerated. This affects the productivity of the classic edit cycle and has a profound impact on developers. Generated code must then be compiled, tested, debugged, edited again, and so on. Placing a CASE tool into this mix requires a sensitivity to these productivity issues. Rational Rose 4.0 has made some significant strides. Detailed editing in the CASE tool is now just as efficient as is editing .cpp and .h files directly.
Additional complexity sets in, however, in the boundary between the CASE tool and the development environment. To support generation of header files and method prototypes, there must be a way to ensure that the tool doesn't overwrite method bodies (and other code or comments) entered by the developer. The safest and most frequent way of doing this is to embed information about the model into the generated code.
Embedded information in code files often leads to complaints by developers when they first begin using CASE tools. These complaints are understandable, because readability of the source code is significantly reduced by the CASE tool's information placed into comment blocks.
Two things happen to nullify this complaint. First, developers get used to seeing the extra comments and begin to mentally filter them out. This might seem a bit odd to point out, but developers do in fact learn to selectively attenuate the noise level introduced by the tool into the code. The second thing that tends to offset the "code pollution problem" comes about through the use of sophisticated integrated development environments such as Microsoft's Visual C++. These IDEs offer class and method browsers that make navigation to specific declarations and definitions very easy, so developers can bypass the noise level in the native code files.
CASE tool vendors are very aware of the problems of intrusive markers in source code. As a result, many recent product releases include more sophisticated marker systems that are less objectionable to the developer. Cayenne's ObjectTeam, for instance, is specifically embedding this information into a repository and results in minimal intrusion into source code. Cayenne's tool can also generate code for different languages including C++, Java, Smalltalk, Fortý, Ada, PowerBuilder, and Delphi.
The ability to represent IDL (Interface Definition Languages for CORBA and Microsoft's DCOM), including support for features such as inheritance, is another challenge for today's object modeling tools. IDL is the backbone for describing distributed systems consisting of heterogeneous operating systems and languages for implementing objects.
Because models are subject to frequent change during analysis and design, many CASE tool vendors integrate version control and configuration management. This integration often occurs through menu options that invoke an external version-control program for check-in, check-out, and related functions. Rational's Rose supports the use of scripts, which are invoked from menu choices for such typical version-control functions as "Get Latest," "Check Out," "Check In," "Check In Without Changes," and so forth. These scripts are tied to command-line interfaces supported by external configuration and version-control tools.
CASE tools must work well in a multiuser environment because large projects are modeled and built by teams of developers. CASE tools that store models in operating system files (instead of using a repository database) must be able to define units of a model that can be worked on concurrently by several designers and analysts. These units must also be placed under version control. The granularity of a model's units is important because parts of a model are often intertwined. When one developer checks out a portion of the model, that portion should be sufficiently fine-grained so that other developers can check out other model elements and work on them independently. Any portion of the model that is common to more than one unit being checked out or frequently updated can easily become a bottleneck in the modeling process.
The version-control features integrated with CASE tools apply only to model files, not to the source code, which is generated by the CASE tool. Developers could apply version control to both model and source code files by writing more advanced scripts if a CASE tools has a scripting language. However, version control of source code files usually occurs outside the boundaries of the CASE tool. Often it is managed within an Integrated Development Environment (IDE).
On the language front, object modeling CASE tools must improve their support for mixed-language development that involves Java, C++, Visual Basic, and so forth. Bringing together components that are implemented in different languages and interconnected using CORBA or DCOM is a real challenge.
CASE tools that now store model information in files will probably move toward using repositories that are accessible to multiple tools. This will make it easier for developers to exchange current information between tools that perform specific kinds of modeling. However, the ability to reduce the number of CASE tools needed to model an application and its persistent database schema is another trend.
So much is left to be done -- as technology continues to evolve toward Web-based applications, distributed applications, and ever-more heterogeneous environments -- that CASE tools vendors are likely to be playing catch-up for some time to come.
What did you think of this article? Send a letter to the editor.