Integrating Rational Software Architect with InfoSphere Data Architect

Making your application model and data model work together

Model-driven software development generally starts with either application modeling or data modeling. Application modeling and data modeling, however, are closely related to, and complement, one another. IBM has recognized the importance of integrating application modeling with data modeling in model-driven software development, and has developed the Unified Modeling Language (UML)-to-logical data model (LDM) and the LDM-to-UML transformations. These transformations integrate application modeling using Rational Software Architect (RSA) and data modeling using InfoSphere Data Architect (IDA). This article provides a quick overview of RSA and IDA, outlines the high-level steps in three RSA-IDA integration scenarios, and discusses the UML-to-LDM and the LDM-to-UML transformations and the UML logical data model profile. [2009 Apr 17: Added note about InfoSphere Data Architect changing product name to InfoSphere Data Architect. --Ed.] [2011 Mar 10: Author reviewed and updated content and changed references from Rational Data Architect to InfoSphere Data Architect. --Ed.]

Daniel T. Chang (dtchang@us.ibm.com), Senior Software Engineer, Information Management, Data Tools, IBM

Daniel T. Chang is a senior software engineer at IBM Silicon Valley Lab. He has been with the RDA Core team since 2006.



10 March 2011 (First published 09 August 2007)

Also available in Chinese Russian Vietnamese Spanish

Introduction

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 in a holistic fashion, the power of model-driven software development is revealed because you have accomplished all of the following:

  • 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
  • Allowed separation of concerns between the application modeler and the data modeler

Product name change

On December 16th, 2008, IBM announced that as of Version 7.5.1, Rational Data Architect is renamed to InfoSphere Data Architect to feature its role in InfoSphere Foundation Tools.

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 InfoSphere Data Architect (IDA). IBM recognizes the importance of integrating application modeling and data modeling in model-driven software development. IBM 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, and the LDM-to-UML transformation is an optional feature of IDA. The online 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 provides a quick overview of RSA and IDA and then outlines the high-level steps in three RSA-IDA integration scenarios. For the UML-to-LDM (top-down) scenario and the LDM-to-UML (bottom up) scenario, the article further provides recommendations on when organizations should consider using each. This article continues by discussing application modeling in RSA, data modeling in IDA, and transformations from UML-to-LDM (top down) and from LDM-to-UML (bottom up). This article also discusses the UML logical data model Profile, which enables data modeling in RSA and enhances UML-to-LDM and LDM-to-UML transformations.

Note that while the UML-to-LDM transformation and the LDM-to-UML transformation are at the core of RSA and IDA integration, there are other important aspects of RSA and IDA integration worth mentioning, including the following:

  • 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.

Note also that the RSA and IDA integration discussed in this article applies in total to the Rational Software Modeler (RSM) and IDA integration.

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 does the following:

  • 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 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.

Figure 1. Sample class model in RSA Invoice project
Invoice, InvoiceItem, ProductInvoice, and ServiceInvoice showing associations such as Description and EndDate

InfoSphere Data Architect

InfoSphere Data Architect (IDA) 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. You can do the following using IDA:

  • Create logical and physical data models
  • Extend logical and physical data models with dimensional notations
  • 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
  • Integrate and interchange logical and physical data models with other modeling (application, data, and dimensional) tools and repositories

Figure 2 shows a sample LDM from the sample IDA 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.

Figure 2. Sample logical data model in IDA Invoice project
Same as Figure 1, except associations are reversed (associate and main, and so on)

Logical data models were frequently overlooked in the software development life cycle, but they 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-the-art, model-driven development tooling such as InfoSphere Data Architect and Rational Software Architect, you 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 integration.


Exploring 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 describe 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 IDA. Following are the high-level steps in this scenario:

  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 IDA.
  4. The data modeler transforms the LDM into a physical data model (PDM) and further generates a database schema using IDA.

Figure 3 shows the interaction between the application modeler and the data modeler in the top-down scenario:

Figure 3. Top-down integration scenario: Application modeling to data modeling
Work flow from Model data as class to Generate Schema, as described above

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.

People sometimes adopt the top-down scenario for the wrong reasons. The following are some poor reasons for deciding to adopt the top-down scenario followed with counterarguments 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 need to share persistent data with other enterprise applications. An LDM can reduce total cost of ownership.

Finally, consider the disadvantages of using the top-down approach, including the following:

  • Data models can become tightly-coupled with particular applications.
  • Class models can be not 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 while the application modeler focuses on application modeling.

The steps in this scenario are as follows:

  1. The data modeler models data in an LDM in IDA. 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.
  2. The data modeler transforms the PDM into an LDM.
  3. The data modeler transforms part, or the whole, of an LDM into a class model using the LDM-to-UML transformation.
  4. The application modeler accesses and imports the class model in RSA.

Figure 4 shows the interaction between the application modeler and the data modeler in a bottom-up scenario.

Figure 4. Bottom-up integration scenario: data modeling to application modeling
Work flow from Model Data or Reverse Engineer PDM to Access Class Model, as described above

Consider using the bottom-up scenario when a combination of the following conditions is true:

  • An 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, such as 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.

The bottom-up approach comes with the following disadvantages:

  • Some semantics can be lost during the transformation from an 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, the application modelers might end up re-inventing the wheel and defining 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 approach

The previous sections describe 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, because 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.

This section describes two use cases in the meet-in-the-middle scenario, depending on whether you want to update your class models or LDMs.

In the first use case, once class models are transformed into LDMs and used in IDA, the application modelers make some changes in the class models such as adding new properties. The LDMs are updated in IDA 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 IDA with the new or modified information.

The steps in the first use case are as follows:

  1. The data modeler uses LDM version 1 in IDA, 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 IDA.
  4. The data modeler compares and merges LDM version 1+ and version 1 into LDM version 2 in IDA.

Figure 5 shows the interaction between the application modeler and the data modeler in the first use case.

Figure 5. Meet-in-the-middle scenario: application modeling to data modeling
Work flow from Modify Class Model or Use LDM to Compare and Merge, as described above

In the second use case, 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. The class models in RSA are updated to reflect the updated LDMs. This use case is an extension of 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 as follows:

  1. The application modeler uses class model version 1 in RSA, which was previously transformed from LDM version 1 in IDA.
  2. The data modeler modifies LDM version 1 in IDA, 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.

Figure 6 shows the interaction between the application modeler and data modeler in the second use case.

Figure 6. Meet-in-the-middle scenario: data modeling to application modeling
Work flow from Use Class Model or Modify LDM to Compare and Merge, as described above

Understanding 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 the following:

Model and packages
The structural components and namespaces for other model elements. A package can contain packages, diagrams, classes, associations, association classes, and data types.
Classes
Concepts within the system being modeled. Instances of the same class share common characteristics. A class has the following subclasses:
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
Taxonomic relationships between a class and more general classes. The class is fully consistent with the more general class and contains additional properties.
Associations
Semantic relationships between two classes that involve connections among their instances. In addition to the simple form of association, there are two additional forms as follows:
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 can belong to only one composite at a time.
Association class
An association that is also a class. An association class connects two classes and has properties.
Data types
A descriptor of a set of values. Data types include the following:
Predefined primitive types
Boolean, Number, String, UnlimitedNatural
User defined data types
Primitive types or enumerations

Refer back to Figure 1 for the sample class model.

IDA logical data model

A logical data model defines the following:

Packages
The structural components for other model elements. A package can contain packages, diagrams, entities, and domains.
Entities
Concepts, events, persons, places, or things about which information is kept. Instances of the same entity share common characteristics. Entities can 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 the following:
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
Taxonomic relationships between the entity and more general entities. The entity is fully consistent with the more general entity and contains additional attributes.
Relationships
Connections, links, or associations between two entities. Following are three kinds of relationships:
Identifying relationship
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
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 descriptor of a set of values. Data types include the following:
Predefined data types
BINARY, BLOB, BOOLEAN, CHAR, CLOB, CURRENCY, DATALINK, DATE, DECIMAL, DOUBLE, FLOAT, INTEGER, INTERVAL, LONG, NUMERIC, ROWID, SHORT, TIME, TIMESTAMP, VARBINARY, VARCHAR, XML
User defined data types
Atomic domains

Refer back to Figure 2 for the sample logical data model.

Top-down: Class model to logical data model

The UML class model and the IDA 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, note the following:

  • A class does not have a primary key; it has an implicit OID (object identifier). This is transformed to a surrogate key by default.
  • 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 can have class reference as a type, which has identical semantics to an aggregation. A class reference is therefore transformed to a non-identifying relationship.
  • Association class is a concept that does not exist in the logical data model. It is transformed into an entity and two relationships to preserve the semantics of association class.
Table 1. UML-to-LDM mapping
UML (source)LDM (target)
Model/packagePackage
ClassEntity
PropertyAttribute
n/a (OID)Surrogate key
GeneralizationGeneralization
CompositionIdentifying relationship
AggregationNon-identifying relationship
(Simple) associationNon-identifying relationship or many-to-many relationship
Class referenceNon-identifying relationship
Association classOne entity and two relationships
Predefined UML primitive typePredefined data type
Primitive typeAtomic domain
EnumerationAtomic domain

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, note the following:

  • A surrogate key, such as Invoice ID for Invoice, has been generated for each entity.
  • Key inheritance, such as Invoice ID from Invoice to ProductInvoice, takes place for generalization.
  • Key migration, such as Invoice ID to invoiceInvoice ID from Invoice to InvoiceItem, takes place for composition.
  • Key migration, such as 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.
Figure 7. Logical data model generated by the UML-to-LDM transformation
Logical data model similar to Figure 2 with the changes described above

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 correspond to data types required for data modeling or persistent data. The UML logical data model profile can be used to do the following:

  • Provide 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 the following:
    • Primary key attributes
    • User defined data types: more information than what can be specified with primitive types or enumerations
    • Referential integrity, such as 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 that the logical data model profile provides. Note the following about the table:

  • Enumeration or primitive types can be stereotyped as Domain. If so, additional information, such as the base type, can be specified.
  • Classes can be stereotyped as Entity. By default, entities are persistent and do not use surrogate key.
  • Properties are always stereotyped as Attribute. By default, attributes are not required.
  • Properties can be stereotyped as PrimaryKey.
  • Associations and association classes are always stereotyped as Relationship. 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 DEFAULT) can be specified. Similarly, child delete rule can also be specified. In addition, a transform-as option (SEPARATE_TABLE / MERGE) can be specified.
  • Generalizations are always stereotyped as Generalization. Both transform-as option (SEPARATE_TABLE / ROLL_UP / ROLL_DOWN) and defining attribute can be specified.
Table 2. The UML logical data model profile
StereotypeExtensionsAttributes
DomainEnumeration
PrimitiveType
BaseType
Length
Precision
Scale
Required
DefaultValue
EntityClassPersistent
UseSurrogateKey
AttributePropertyRequired
PrimaryKeyProperty
RelationshipAssociation
AssociationClass
ForeignKeyAttributeNames
ParentDeleteRule

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. Note the following about the table:

  • Only classes stereotyped as Entity are transformed to entities. By default, entities 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.
  • Only primitive types and enumerations stereotyped as Domain are transformed to atomic domains.
Table 3. UML-to-LDM mapping with the logical data model profile
UML (source)LDM (target)
Model/packagePackage
Class (<<Entity>> only)Entity
Property (<<PrimaryKey>>)Attribute (primary key)
n/a (OID)Surrogate key
GeneralizationGeneralization
CompositionIdentifying relationship
AggregationNon-identifying relationship
(Simple) associationNon-identifying relationship or many-to-many relationship
Class referenceNon-identifying relationship
Association classOne entity and two relationships
Predefined UML primitive typePredefined data type
Primitive type (<<Domain>> only)Atomic domain
Enumeration (<<Domain>> only)Atomic domain

Figure 8 shows the sample class model with the logical data model profile applied. Note the following about the table:

  • 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 8. Sample class model with the logical data model profile
Logical data model similar to Figure 1 with the changes described above

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, note the following:

  • No surrogate key has been generated. Instead, primary key attributes (the ID of Invoice and the ID of InvoiceItem) have been generated.
  • Key inheritance (the ID from Invoice to ProductInvoice) takes place for generalization.
  • Key migration (the Invoice ID to InvoiceID 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.
Figure 9. Logical data model generated by the UML-to-LDM transformation with the logical data model profile
Logical data model similar to Figure 8 with the changes described above

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).

Table 4. LDM-to-UML mapping
LDM (source)UML (target)
PackageModel/package
EntityClass
Attribute Property
GeneralizationGeneralization
Identifying relationshipComposition
Non-identifying relationshipAggregation
Many-to-many relationship(Simple) association
Predefined data typePredefined UML primitive type
Atomic domainPrimitive type or Enumeration

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 in Figure 2. In comparing the source and target models, note the following:

  • Primary key information, such as the ID of Invoice, is lost in the class model, because the UML class model does not support the concept of primary key.
  • Foreign key attributes, such as the invoiceID of InvoiceItem, are not transformed to the class model, because they are generated by key migration in the logical data model and are not inherent to the model.
Figure 10. Class model generated by the LDM-to-UML transformation
Logical data model similar to Figure 1 with the changes described above

In order to preserve logical data modeling concepts and information in the target class model, the logical data model profile is applied by default 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. Note the following about the table:

  • 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.
Table 5. LDM-to-UML mapping with the logical data model profile
LDM (source)UML (target)
PackageModel/package
EntityClass (<<Entity>>)
Attribute (primary key)Property (<<PrimaryKey>>)
GeneralizationGeneralization
Identifying relationshipComposition
Non-identifying relationshipAggregation
Many-to-many relationship(Simple) association
Predefined data typePredefined UML primitive type
Atomic domainPrimitive type (<<Domain>>) or Enumeration (<<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 in Figure 2. In comparing the source and target models, note the following:

  • Primary key information, such as the ID of Invoice, is preserved in the class model.
  • Foreign key attributes, such as the invoiceID of InvoiceItem, are not transformed to the class model, because they are generated by key migration in the logical data model and are not inherent to the model.
Figure 11. UML model generated by the LDM-to-UML transformation with the logical data model profile
Logical data model similar to Figure 2 with the changes described above

Conclusion

This article provides a high-level overview of RSA and IDA and their integration. The article contains three integration scenarios and describes 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 might require organizational and cultural changes as well. This article jump-starts 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 which classes, primitive types, and 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, because major logical data modeling concepts and information are preserved in the generated class model.

Logical data modeling is the lynch pin of data modeling integration, as shown in Figure 12. This article shows how application modeling in RSA can be integrated with logical data modeling in IDA. Integration between logical data modeling and relational data modeling is a standard feature of IDA. Integration between business modeling in WebSphere Business Modeler (WBM) and logical data modeling in IDA, as well as integration between logical data modeling and XML data modeling in IDA, are discussed in "Integrate WebSphere Business Modeler and Rational Data Architect" (developerWorks Nov 2007).

Figure 12. Logical data modeling as the lynch pin for data modeling integration
Logical data modeling as the Lynch Pin for data modeling Integration

Acknowledgments

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.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, Rational
ArticleID=246518
ArticleTitle=Integrating Rational Software Architect with InfoSphere Data Architect
publish-date=03102011