Bridging Two Worlds

Rational Rose 2001 eases efforts to model relational data for OO applications

By Terry Moriarty      

Since the advent of object-oriented (OO) approaches, people have been wondering whether object class models and data modeling can coexist on the same project. Because most persistent storage is in relational databases, some level of integration must exist within an application. But how much and when data analysis should occur within the project lifecycle has been a constant issue for applications being built using OO technology. Rational Software Corp., perhaps the leading provider of OO modeling tools, has provided its answer to these questions by incorporating support for data modeling into its flagship product Rational Rose 2001 Enterprise Edition, which I review here, as well as the Professional Data Modeler Edition.

Rational provides a number of tool suites to meet specific development needs. For this review, I used the AnalystStudio suite, which focuses on analysis and design for the analyst and database designer. It is intended to encompass the entire application development lifecycle, with RequisitePro positioned as its requirements product and Rational Rose as its application modeling and design product. Other products in the suite include Clearquest, Rational's defect tracking and change management product, and a variety of products that support the testing phase of the project lifecycle. Finally, DataModeler supports the integration between object class models and database design. Supporting the entire lifecycle is the Rational Unified Process (RUP), a complete project development and management product, and Rational SoDA, which generates a project's supporting deliverables.

Rational Rose 2001 serves as the bridge between the requirements and implementation phases by providing the environment for analyzing requirements, converting them into a technology-independent design, and ultimately depicting the architecture and design of the software and database aspects of the application to be built. In some cases, Rational Rose can generate the initial code for the application, in terms of object classes, including the attributes, method stubs, and message formats.

Object Class Diagram and Data Model Integration

Consider the following scenario, which is so typical to many organizations. Your persistent data storage environment uses relational technology, or data stored such that it resembles relational tables. You have no intention of moving to OO databases. However, all new development is being done using OO analysis and design approaches and programming technologies. How do you incorporate your relational data into your OO development process?

Rational Rose addresses this issue through its DataModeler facility, which orchestrates the coordination between object class and data model diagrams. DataModeler is more than just a data model diagramming tool. It provides a full range of features that support both the forward and reverse engineering of models across the relational and object data management paradigms.

The first step is to reverse engineer the relational database design into the Rational Rose environment, either by directly connecting to the DBMS's catalog or by parsing a text file containing the database's data definition language (DDL). Rational Rose can reverse engineer from IBM DB2, Oracle, Microsoft SQL Server, and Sybase Adaptive Server DBMSs.

The tool illustrates relational components through a Unified Modeling Language (UML) object class model in which it depicts every table as an object class box, with the columns listed as attributes. (See Figure 1). It represents the primary keys, foreign keys, indexes, triggers, and constraints as operations on the table object class. It derives relationships between tables, represented as associations, based on foreign key relationships. If the foreign key is part of the primary key of the second table, then the tool establishes an identifying association and an aggregation association. Otherwise, it uses a simple association. All associations are navigable in both directions. Each stored procedure is represented by its own container class. Database views are not reverse-engineered into Rational Rose.

Next, the data model, which is really a model of the physical database design, is transformed into an object class model. Every table and column is transformed into an object class and attribute respectively. Rational Rose automatically maintains the mapping between the data model component and its object class model counterpart. You are free to change the properties of the object classes and attributes, such as assigning names that conform to OO naming standards. You can move attributes from one object class to another. Likewise, you can make similar types of changes to the data model. Rational Rose maintains the mapping between the models, ensuring that traceability continues to exist between the database and object perspectives.

However, you can view these mappings only through the data model. I would prefer to see the mapping from the object class perspective, as well. Rational Rose does not transform the operations assigned to the data model tables into the object class model. While this omission may be appropriate for the key and index specification, I think there is value in bringing triggers and constraints forward into the object class model.

At this point, you have an object class model that is tightly coupled with your database design. You must decide whether this model is the one against which you will write your OO programs. This model probably doesn't fully exploit all the capabilities of your OO programming language. However, whenever the object class and data model diverge, you will probably need to create code to handle the transformations between the two perspectives.

As your project progresses, you will probably encounter new object classes that need to be persisted within the database. Rational Rose supports the forward engineering of the object class model into the data model. As with the reverse engineering process, Rational Rose maintains the mapping between the object classes and attributes and their database counterparts. The transformation creates a table for each object class and a column for each attribute. Rational Rose provides the most robust approach for transforming association into relationships that I have encountered to date. It converts aggregations, compositions, and inheritance hierarchies into nonidentifying, dependent tables. It turns association classes into tables that resolve the association between the two tables. It does not transform derived attributes into columns.

When the modifications to your database design are complete, Rational Rose provides a "Compare and Synchronize" function to coordinate forward engineering of the changes to the database. First, it generates a visual display of the difference between the database or DDL script and model. From that point, you can choose to import to the model, export to the database, ignore each difference on its own, or do the same to all. You then update the model or database as needed. Rational Rose subsequently alters or drops and recreates the tables, as needed, to effect the desired database changes.

Methodology Enforcement

Rational Rose primarily supports the UML modeling technique, although it also supports Booch and OMT notation. This UML centrism is unsurprising; Rational was one of the primary companies involved in developing the UML approach. Rational Rose provides all the primary UML analysis and design diagram types, including Use Case, Object Class, Sequence, Collaboration, Activity, and State Chart diagrams. As I discussed previously, Rational Rose has also incorporated support for relational database design.

Stereotypes, an important UML concept, provide the basis for extending UML to support various technologies or analysis and design methodologies. You create stereotypes from the basic UML building blocks. For example, the relational database constructs of table, column, and relationships can be represented as stereotypes of the UML object class, attribute, and association metaobject types.

Rational Rose's support for stereotypes is very robust. A stereotype consists of several parts: the UML metaobject type that is being typed, its name, and a large and small icon. You can create new stereotypes through Rational Rose's extensibility function. Diagrams can either display the standard UML symbol for the metaobject type, its stereotype's icon, or the UML symbol with the small version of the icon included in the upper right hand corner. For example, Rational Rose has provided custom stereotypes for business-oriented concepts, such as business object, business actor, business worker, and business user case. When the diagram includes the stereotype's icon, it's much easier to understand what level of the business is being modeled: the requirements or technical perspective.

The object class diagram supports the most important UML constructs, including association classes, navigation for associations, aggregation and containment associations, inheritance hierarchies, and qualified, derived, and static attributes. Tenary associations and multivalued attributes are not supported.

An interaction diagram illustrates the expected behavior of a use case. Rational Rose allows two different views of an interaction. The sequence diagram, which provides the logic flow of a scenario, is ordered by time. The collaboration diagram, which provides the alternate view, lets you explore the impact of change by showing how objects interact with one another. A collaboration diagram also shows data flow. As soon as one diagram has been created, Rational Rose can generate the alternate interaction diagram.

Interaction diagrams can use objects, object classes, or both. Rational Rose uses messages to make requests from one object (class) to another to perform some function. Before generating code, messages must be mapped to an operation of the receiving class.

Behavior can also be specified through state chart and activity diagrams, another set of companion diagrams. A state chart shows the valid state of an object and the events that cause the transition from one state to another. The activity diagram illustrates the conditions that cause the transition between states.

Rational Rose supports two system design level diagrams. The implementation model illustrates the technical architecture of the system by depicting its configuration in terms of executable code modules. This diagram can also be used to map its components back to the design model objects that it supports (such as tasks and modules). The deployment diagram describes how the system is configured across hardware platforms.

The "package" feature is one UML feature that I really like. It lets you group model objects together in many different ways. For example, I created a package for each major phase in the project lifecycle: business, analysis, design, and implementation. A package can contain other packages. So within each of my lifecycle phase packages, I created packages for each of the diagram types (object class and use cases). Rational Rose comes with its own set of default packages for the UML system views: Use Case, Logical, Component, and Implementation. I would have liked to delete these packages or at least renamed them, because they don't correspond to my high-level view of a business system, but Rational Rose wouldn't allow it. It's the only area of inflexibility that I really encountered within the tool. It's one I can work around.

Each model object is defined through its specification. The information you can specify depends on the metaobject type and, in some cases, the stereotype. Usually you can see which diagram the model object appears on and which associations it participates in. Clicking on a diagram's name opens that diagram. Likewise, clicking on an association's name opens the specification for that association. Documents, specified as local files or Web URLs, can also be attached to model objects. As with diagrams and associations, clicking on the file name will open up the document.

The check model feature iterates through the entire model to determine whether it conforms properly to UML. The program writes any discrepancies to the session log, which records all actions taken and warnings or errors detected. The log starts when a model initially opens and can be viewed at any time.

Conformance to the modeling methodology that the product supports is an important evaluation criteria. But it is insufficient when making the decision about which OO analysis and design tool to select for your organization. Ease of use, reporting, and its ability to integrate into your enterprise's information management environment are also things you should carefully assess. In the next issue for the second half of this review, I will hold Rational Rose 2001 up against these additional evaluation criteria.

Terry Moriarty (terry@inastrol.com), president of Inastrol, a Southern California-based information management consultancy, specializes in customer relationship information and metadata management. She also writes the Metaprise column in Intelligent Enterprise.