The model-driven approach is becoming widely used for software development. In model-driven software development, either application modeling or data modeling generally serves as the starting point. Application modeling and data modeling, however, are very similar to one another. Application modeling captures key business information as classes and associations in the form of class models in Unified Modeling Language (UML). Class models can then be used as the basis for deriving the logical data models for data modeling. Data modeling, on the other hand, captures business entities, their relationships, and constraints in logical data models (LDMs), which can then be used for deriving the class models for application modeling.

A well-formed LDM can provide a single-truth representation of the key business information in an enterprise. It can encompass and outlive many applications and physical data sources. The precise, accurate and complete semantics in the LDM provide a perfect foundation for class models when an organization takes on an application modeling task.

Whether starting from application modeling or data modeling, when these different forms of modeling are combined are combined in a holistic fashion, the power of model-driven software development is revealed because we have:

• achieved model interoperability across the enterprise and across the layers of the enterprise architecture,
• created reusable information models that are useful for multiple applications,
• decoupled data semantics and physical implementation, and
• allowed separation of concerns between the application modeler and the data modeler.

IBM is the leader in providing application modeling tooling and has recently added data modeling tooling. The users can model applications in Rational Software Architecture (RSA) and model data in Rational Data Architect (RDA). IBM recognizes the importance of integrating application modeling and data modeling in model-driven software development, and has developed the UML-to-LDM transformation and the LDM-to-UML transformation to link these tools together. The UML-to-LDM transformation is an optional feature of RSA V7, and the LDM-to-UML transformation is an optional feature of RDA V7. The on-line documentation in each product details the step-by-step procedure for installing and using each respective transformation and also includes object mappings information.

This article first provides a quick overview of RSA and RDA, and then outlines the high-level steps in three RSA-RDA integration scenarios. For the UML-to-LDM (top-down) scenario and the LDM-to-UML (bottom up) scenario, it further provides recommendations on when organizations should consider using each. This article continues by discussing application modeling in RSA, data modeling in RDA, and transformations from UML-to-LDM (top down) and from LDM-to-UML (bottom up). It also discusses the UML Logical Data Model Profile, which enables data modeling in RSA and enhances UML-to-LDM and LDM-to-UML transformations.

Please note that while the UML-to-LDM transformation and the LDM-to-UML transformation are at the core of RSA and RDA integration, there are other important aspects of RSA and RDA integration worth mentioning:

• common install and shell sharing for ease of deployment and usage
• common model repository using Clearcase
• common model-driven development toolkit (EMF model, transformation framework, extensibility, and so on)

Discussions of these topics are beyond the scope of this article.

Rational Software Architect

Rational Software Architect (RSA) is an application modeling tool that enables an organization to model, analyze, design, and generate applications. It leverages model-driven development with UML for creating well-architected applications and services. RSA:

• Extends the Eclipse open and extensible software development environment.
• Exploits the latest in modeling language technology, enabling flexible modeling across a variety of different domains including UML 2, UML-like notation for Java and more.
• Enables flexible model management for parallel development and architectural re-factoring; for example, you can split, combine, compare and merge models and model fragments.
• Eases the transition between the architecture and code with model-to-model and model-to-code transformations, including reverse transformations.
• Eases the design-to-code experience for Java™/J2EE™, Web Services, SOA and C/C++ applications.
• Includes all of the features of IBM Rational Application Developer for an integrated design and development experience.

Classes in RSA can be anything that is created, assembled, inspected, tested, modified, or worked upon in applications. Figure 1 below shows a few sample classes, and their associations, – Invoice, InvoiceItem, ProductInvoice and ServiceInvoice from a sample RSA project called Invoice. Note that there are three different types of associations shown: composition (invoice – item), aggregation (main – associate) and simple association (product - service). These associations are discussed later in this article.

Rational Data Architect

Rational Data Architect (RDA) is an enterprise data modeling and integration design tool. It simplifies data modeling and integration design, enabling architects to discover, model, visualize and relate diverse and distributed data assets. Using RDA one can:

• Create logical and physical data models.
• Compare and synchronize the structures and elements of two data models.
• Analyze data models for correctness and conformance to enterprise standards.
• Discover, explore and visualize the structure of data sources.
• Use mapping to discover potential relationships and identify relationships between disparate data sources.

Figure 2 below shows a sample LDM from the sample RDA project called Invoice. Note that there are three types of relationships: identifying (item – invoice), non-identifying (associate - main) and many-to-many (service - product). Note also that key inheritance occurs for generalizations and key migration occurs for identifying and non-identifying relationships. This is discussed later in this article.

Logical Data Models were frequently overlooked in the software development life cycle, but have become increasingly important for many reasons. LDM provides a view of the data entities in a business or an enterprise without exposing implementation details; it separates data semantics from implementation and is especially useful when dealing with today’s increasingly complex and heterogeneous IT environments. Other logical or physical models, such as service models, message models, class models and data warehousing models, can all be traced to a common LDM. With state-of-art, model-driven development tooling such as Rational Data Architect and Rational Software Architect, the user can even generate downstream models and physical implementations based on LDM. It is not an exaggeration to say LDM is the information hub of an organization. LDM allows an enterprise view of data, which in turn helps to reduce data redundancy, improve data quality, and speed up integration.

Back to top

Integration Scenarios

There are three primary scenarios for the integration of application modeling and data modeling: top-down, bottom-up and meet-in-the-middle. The following sections desscribe each of the scenarios in more detail. The assumption is that two main IT roles are involved – The Application Modeler performs application modeling, and the Data Modeler carries out data modeling.

Top-down: Application Modeling to Data Modeling

In the top-down scenario, class modeling elements (classes, properties and associations) in RSA are transformed into LDM modeling elements (entities, attributes and relationships) for use in RDA.

The steps in this scenario are:

1. The Application Modeler models applications in RSA. Business or application data is captured as class models.
2. The Application Modeler transforms part, or the whole, of a class model into a LDM using the UML-to-LDM transformation.
3. The Data Modeler accesses and imports the LDM in RDA
4. The Data Modeler transforms the LDM into a Physical Data Model (PDM) and further generates database schema using RDA.

The following diagram shows the interaction between the Application Modeler and the Data Modeler in the top-down scenario:

We recommend organizations consider using the top-down scenario when a combination of the following conditions is true:

• Application modeling is driving the project initiative.
• Applications cut across business units or silos.
• Applications are object centric and have limited requirements for data management other than persistence.
• LDM is not available.
• Physical database schema does not exist.

However, people sometimes adopt the top-down scenario for the wrong reasons. The following (in quotes) are some poor reasons for deciding to adopt the top-down scenario; they are followed with an counterargument against adopting the top-down scenario:

• “We have never done LDM before.” There is always a first time. If your organization has cut corners on LDM in the past, the sooner LDM efforts start, the better off the organization will be in the long term.
• “We don’t have LDM skills.” A good data modeler is worthy of investment so you should hire someone or develop people internally with LDM skills.
• “We only need to persist data for use by this application.” Most enterprise applications will need to share persistent data with other enterprise applications. A LDM will reduce Total Cost of Ownership.

Finally, the cons of using the top-down approach need to be addressed:

• Data models may become tightly-coupled with particular applications.
• Class models may not be readily reusable in LDM due to de-normalization and object-centric modeling in application modeling.

Bottom-up: Data Modeling to Application Modeling

In the bottom-up scenario, LDM modeling elements (entities, attributes and relationships) are transformed into class modeling elements (classes, properties and associations) for use in RSA. From an enterprise perspective, in the long run, it is preferable to use the bottom-up than the top-down approach because of the limitations of the top-down approach and the many benefits coming with LDM, as mentioned in the previous sections. In addition, the bottom-up approach allows the separation of concerns – the Data Modeler concentrates on developing an enterprise-wide vocabulary and data models; the Application Modeler focuses on application modeling.

The steps in this scenario are:

1. The Data Modeler models data in a LDM in RDA. In those cases where there’s an existing database schema but no physical or logical model, the Data Modeler derives a PDM from the existing schema, and transforms the PDM into a LDM.
2. The Data Modeler transforms part, or the whole, of a LDM into a class model using the LDM-to-UML transformation.
3. The Application Modeler accesses and imports the class model in RSA,.

The following diagram shows the interaction between the Application Modeler and the Data Modeler in a bottom-up scenario:

We recommend that organizations consider using the bottom-up scenario when a combination of the following conditions is true:

• A LDM on that domain is already available.
• There are several existing data sources (relational databases or other).
• The organization wants to de-couple data from applications and manage data from the enterprise-level.
• The organization wants to create reusable information across the enterprise.
• Multiple initiatives are involved; for example, business application rewrite along with a requirement to tie into a data warehouse.
• Applications are complex and frequently in flux.
• Applications are data-centric.
• The project needs to consider, at least in part, existing data models. This can happen if you have legacy applications, third-party applications, or standards-based interfaces to satisfy.

Finally, the bottom-up approach also comes with a price:

• Some semantics may be lost during the transformation from a LDM to a class model because LDMs hold richer data semantics (as in, primary keys) than class models.
• Because LDMs tend to be more complete than class models, if LDMs are pushed into class models without appropriate communication, the details might overwhelm Application Modelers. If the Application Modeler doesn’t understand LDMs, they may end up re-inventing the wheel and define entities or attributes that are already in LDMs. Thus, proper education and communication between the Data Modeler and the Application Modeler is essential. Ideally Application Modelers should be educated on how to understand and leverage logical data models.

Meet-in-the-middle

The previous sections descirbe both the top-down and bottom-up scenarios, which primarily focus on new development. However, change is the only constant in software development. Application modeling and data modeling should rarely be a one-time shot. To avoid obsolescence, application modeling and data modeling need to be iterative and deliver business value quickly. Thus, the tooling of application modeling and data modeling should support model update capability. For example, changes in class model can be updated and reflected in LDM either through automated (for simple changes) or manual (where complex heuristics are required) methods for model convergence, and vice versa from LDM to class model.

In reality, it is not an easy task to manage the synchronization and change management of class models and LDMs as they reside in different tools and are often performed by two distinct roles – the Application Modeler and the Data Modeler. Nevertheless, careful planning, excellent communication and disciplined change management can effectively utilize the tooling features and achieve end-to-end data governance.

There are two use cases in the meet-in-the-middle scenario, depending on if you want to update your class models or LDMs:

1. Once class models are transformed into LDMs and used in RDA, the Application Modelers make some changes in the class models such as adding new properties. We want to update the LDMs in RDA to reflect the updated class models. This use case is an extension of the top-down scenario, with the added complexity of synchronizing existing LDMs in RDA with the new or modified information.

The steps in the first use case are:

1. The Data Modeler uses LDM version 1 in RDA, which was previously transformed from class model version 1 in RSA.
2. The Application Modeler modifies class model version 1 in RSA, then transforms the updated class model (version 2) as LDM version 1+.
3. The Data Modeler accesses and imports LDM version 1+ in RDA.
4. The Data Modeler compares and merges LDM version 1+ and version 1 into LDM version 2 in RDA.

The following diagram shows the interaction between the Application Modeler and the Data Modeler in the first use case:

1. Once the LDMs are transformed into class models and used in RSA, the Data Modelers make some modifications to the LDMs, such as adding new columns. You should update the class models in RSA to reflect the updated LDMs. This use case is very similar to the bottom-up scenario, with the added complexity of synchronizing existing class models in RSA with the new or modified information.

The steps in the second use case are:

1. The Application Modeler uses class model version 1 in RSA, which was previously transformed from LDM version 1 in RDA.
2. The Data Modeler modifies LDM version 1 in RDA, then transforms the updated LDM (version 2) as class model version 1+.
3. The Application Modeler accesses and imports class model version 1+ in RSA.
4. The Application Modeler compares and merges class model version 1+ and version 1 into class model version 2 in RSA.

The following diagram shows the interaction between the Application Modeler and Data Modeler in the second use case:

Back to top

Model Transformations

Model transformations are at the core of integrating application modeling with data modeling. In the top-down scenario discussed above, class models are transformed to logical data models using the UML-to-LDM transformation; in the bottom-up scenario, logical data models are transformed to class models using the LDM-to-UML transformation.

UML Class Model

A class model defines:

• Model and packages: these serve as the structural components and namespaces for other model elements. A package can contain packages, diagrams, classes, associations, association classes, and data types.
• Classes: they represent concepts within the system being modeled. Instances of the same class share common characteristics. A class has:
  • Properties: descriptions of the characteristics of a class. A property has, among other things, a type that defines the type of value it can have.
  • Generalizations: a class may have generalizations, as in, taxonomic relationships, between it and more general classes. The class is fully consistent with the more general class and contains additional properties.
• Associations: these represent semantic relationships between two classes that involve connections among their instances. In addition to the simple form of association, there are two additional forms:
  • Aggregation: a form of association that specifies a whole-part relationship between an aggregate (a whole) and a constituent part.
  • Composition: a form of aggregation with strong ownership of parts by the composite (whole) and coincident lifetime of parts with the composite. A part may belong to only one composite at a time.
• Association classes: an association class is an association that is also a class. An association class connects two classes and has properties.
• Data types: a data type is a descriptor of a set of values. Data types include:
  • Predefined primitive types: Boolean, Number, String, UnlimitedNatural
  • User defined data types: primitive types or enumerations

Please refer back to Figure 1 for the sample class model.

RDA Logical Data Model

A logical data model defines:

• Packages: these serve as the structural components for other model elements. A package can contain packages, diagrams, entities, and domains.
• Entities: they represent concepts, events, persons, places, or thing about which information is kept. Instances of the same entity share common characteristics. Entities may be either independent or dependent. An entity whose instances cannot be uniquely identified without determining its relationship to another entity or entities is a dependent entity; otherwise, it is an independent entity. An entity has:
  • Attributes: descriptions of the characteristics of an entity. An attribute has, among other things, a type that defines the type of value it can have.
  • Primary key: an attribute or attributes that uniquely identify an instance of an entity
  • Generalization: an entity may have generalizations, i.e., taxonomic relationships, between it and more general entities. The entity is fully consistent with the more general entity and contains additional attributes.
• Relationships: these represent connections, links, or associations between two entities. There are three kinds of relationships:
  • Identifying relationship: a relationship whereby an instance of the child entity is identified through its association with a parent entity. The primary key attributes of the parent entity become primary key attributes of the child.
  • Non-identifying relationship: a relationship whereby an instance of the child entity is not identified through its association with a parent entity. The primary key attributes of the parent entity become non-key attributes of the child.
  • Many-to-many relationship: an association between two entities in which each instance of the first entity is associated with zero, one, or many instances of the second entity and each instance of the second entity is associated with zero, one, or many instances of the first entity.
• Data types: a data type is a descriptor of a set of values. Data types include:
  • Predefined data types: BINARY, BLOB, BOOLEAN, CHAR, CLOB, DATALINK, DATE, DECIMAL, DOUBLE, FLOAT, INTEGER, INTERVAL, LONG, ROWID, SHORT, TIME, TIMESTAMP, VARBINARY, VARCHAR, XML
  • User defined data types: atomic domains

Please refer back to Figure 2 for the sample logical data model.

Top-Down: Class Model to Logical Data Model

From the above discussions it can be seen that the UML class model and the RDA logical data model match each other very well in modeling constructs and semantics. As a result, transforming a class model to a logical data model generally is straightforward and incurs no information loss.

Table 1 shows the mapping from a class model (source) to a logical data model (target). In the table it is worth noting:

• A class does not have primary key; it has an implicit OID (object identifier). This is transformed to a surrogate key.
• A simple association is transformed to a non-identifying relationship if either association end has a multiplicity of 0.1 or 1; otherwise it is transformed to a many-to-many relationship.
• A property may have class reference as type, which has identical semantics as an aggregation. A class reference is therefore transformed to a non-identifying relationship.
• Association class is a concept which does not exist in the logical data model. It is transformed to an entity and two relationships to preserve the semantics of association class.

Figure 7 shows the target logical data model generated by the UML-to-LDM transformation using the sample class model in Figure 1. In comparing the source and target models, please note:

• A surrogate key (as in, Invoice ID for Invoice) has been generated for each entity.
• Key inheritance (as in, Invoice ID from Invoice to ProductInvoice) takes place for generalization.
• Key migration (as in, Invoice Id to invoiceInvoice Id from Invoice to InvoiceItem) takes place for composition.
• Key migration (as in, Invoice Id to mainInvoiceID from Invoice to Invoice) takes place for aggregation.
• For key migration, by default, the child foreign key attribute name is generated by prefixing the parent role name to the parent primary key attribute name.

The UML Logical Data Model Profile

Not all classes defined during application modeling necessarily relate to data modeling or have persistent data; similarly, not all primitive types or enumerations necessarily corresponding to data types required for data modeling or persistent data. The UML Logical Data Model Profile can be used to:

• Allow user control over what classes, primitive types, or enumerations to transform to a logical data model.
• Specify concepts important to logical data modeling but missing in UML including:

• • Primary key attribute(s)
  • User defined data types: more information than what can be specified with primitive types or enumerations
  • Referential integrity: as in, parent delete rule

In essence, the UML Logical Data Model Profile enables a user to perform logical data modeling using UML in RSA.

Table 2 shows the stereotypes and attributes provided by the Logical Data Model Profile. Please note:

• Enumeration or primitive types may be stereotyped as Domain. If so, additional information (as in, the base type) can be specified.
• Classes may be stereotyped as Entity. By default, they are persistent and do not use surrogate key.
• Properties are always stereotyped as Attribute. By default, they are not required.
• Properties may be stereotyped as PrimaryKey.
• Associations and association classes are always stereotyped as Relationship. If so, foreign key attribute names (in the form of primary key attribute name, foreign key attribute name pairs) and parent delete rule (NONE / RESTRICT / CASCADE / SET NULL / SET DEFAUL) can be specified. In the future, child delete rule can also be specified.

Table 3 shows the mapping from a class model (source) to a logical data model (target) when the Logical Data Model Profile is applied to the class model. It is worth noting:

• Only classes stereotyped as Entity are transformed to entities. By default, they are persistent and do not use surrogate key.
• Properties stereotyped as PrimaryKey are transformed to primary key attributes, in which case the generated attributes are required.
• For associations and association classes, if foreign key attribute names and parent delete rule are specified, they are used for the generated relationship. In the future, child delete rule, if specified, will also be used.
• Only primitive types / enumerations stereotyped as Domain are transformed to atomic domains.

Figure 8 shows the sample class model wit the Logical Data Model Profile applied. Please note:

• All primitive types have been stereotyped as Domain.
• All classes have been stereotyped as Entity.
• The ID attributes of Invoice and InvoiceItem have been stereotyped as PrimaryKey.

Figure 9 shows the target logical data model generated by the UML-to-LDM transformation. The source of the sample class model used in this transformation is from Figure 8. In comparing the source and target models, please note:

• No surrogate key has been generated. Instead, primary key attributes (the ID of Invoice and ID of InvoiceItem) have been generated.
• Key inheritance (the ID from Invoice to ProductInvoice) takes place for generalization.
• Key migration (the Invoice Id to ivoiceID from Invoice to InvoiceItem) takes place for composition.
• Key migration (the ID to mainID from Invoice to Invoice) takes place for aggregation.
• For key migration, by default, the child foreign key attribute name is generated by prefixing the parent role name to the parent primary key attribute name.

Bottom-Up: Logical Data Model to Class Model

Similar to the top-down transformation, transforming a logical data model to a class model generally is straightforward and incurs no information loss. Table 4 shows the mapping from a logical data model (source) to a class model (target).

Figure 10 shows the target class model generated by the LDM-to-UML transformation. The source of the sample logical data model used in this transformation is from Figure 2. In comparing the source and target models, please note:

• Primary key information (the ID of Invoice) is lost in the class model since UML class model does not support the concept of primary key.
• Foreign key attributes (the invoiceID of InvoiceItem) are not transformed to the class model since they are generated by key migration in the logical data model and are not inherent to the model.

In order to preserve logical data modeling concepts and information in the target class model, the Logical Data Model Profile can be applied to the target class model during the LDM-to-UML transformation. Table 5 shows the mapping from a logical data model (source) to a class model (target) with the Logical Data Model Profile applied. Please note:

• Entities are transformed to classes stereotyped as Entity.
• Primary key attributes are transformed to properties stereotyped as PrimaryKey.
• Atomic domains are transformed to primitive types and enumerations stereotyped as Domain.

Figure 11 shows the target class model generated by the LDM-to-UML transformation, with the Logical Data Model Profile applied to the target class model. The source of the sample logical data model used in this transformation is from Figure 2. In comparing the source and target models, please note:

• Primary key information (the ID of Invoice) is preserved in the class model.
• Foreign key attributes (the invoiceID of InvoiceItem) are not transformed to the class model since they are generated by key migration in the logical data model and are not inherent to the model.

Back to top

Conclusion

This article provides a high-level overview of RSA and RDA and their integration. You viewed three integration scenarios and learned adoption criteria for the top-down scenario and the bottom-up scenario, respectively. In order to create well-formed application models and data models, it is not enough just to know how to use the tooling. It is equally important to know the reasons for adopting a certain scenario, to define a robust and repeatable change management process, and to create a strategy that leverages the synergy between application modeling and data modeling. Successful integration of application modeling and data modeling may require organizational and cultural changes as well. Hopefully, this article will help you jump-start your integrated application modeling and data modeling efforts.

The article also provides a detailed discussion of the UML-to-LDM and the LDM-to-UML transformations as well as the UML Logical Data Model Profile. In general it is beneficial to apply the Logical Data Model to the class model whether the class model serves as a source or is generated as a target. In the formal case, it allows a user to control what classes, primitive types, or enumerations to transform to a logical data model, and to specify concepts and information important to logical data modeling but missing in UML. In the latter case, it makes the transformation reversible since major logical data modeling concepts and information are preserved in the generated class model.

As Figure 12 illustrates, logical data modeling is the lynch pin of data modeling integration. You saw in this paper how application modeling in RSA can be integrated with logical data modeling in RDA. Integration between logical data modeling and relational data modeling is a standard feature of RDA. Integration between business modeling in WBM and logical data modeling in RDA, as well as integration between logical data modeling and XML data modeling in RDA, are already in the works and will be discussed in a forth-coming developerWorks article.

Back to top

Acknowledgement

Thanks to Der Ping Chou, Davor Gornik, Gary Robinson, and Hong-Lee Yu for reviewing and commenting on this article. Thanks to Andreas Drasdos (GAD) for valuable feedback on the UML-to-LDM transformation and the UML Logical Data Model Profile.

Back to top

Resources

Learn

• Learn more about Rational Software Architect and Rational Data Architect.

• Visit the developerWorks resource page for Information Management and Rational application development to read articles and tutorials and connect to other resources to expand your RSA and RDA skills.
• Browse the technology bookstore for books on these and other technical topics.

Get products and technologies

• Download a free trial version of Rational Software Architect.
• Download a free trial version of Rational Data Architect.
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Integration Scenarios
• Model Transformations
• Conclusion
• Acknowledgement
• Resources
• About the author
• Comments

Next steps from IBM

• Try: InfoSphere Data Architect
• Demo: Integrated Data Studio in a real-world scenario
• Webcast: Five things you can do today to cut costs using agile development
• Briefing: Jazz and Rational Team Concert
• Buy: InfoSphere Data Architect

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers