I would start by making a copy of your model, applying David's suggestion,
and seeing what you think of the results. Whatever modifications you may
have to make could take considerably less of an effort than other possible
solutions (such as using the REI). Some of the apparent differences may
not cause substantive differences.
1) Columns that represent FKs will not appear; only the relationships will
show. But even in an object model, it is typical to use only the
association rather than having both an association and an attribute when
representing requirements. Some modelers add an attribute sometime during
design, but if you plan to use the tool to forward engineer, you will end
up with a duplication of the attribute.
2) In the data model, you can only represent the equivalent of a strong
aggregation (composition). This appears as a black diamond at the parent
table end of the relationship. The data model treats this as an
identifying relationship, and the object model will maintain the adornment
and create the association as an aggregate with containment by value. In
the data model, there is no equivalent to an aggregation with containment
by reference. This is treated like a normal 1:m relationship.
Where you might lose the adornment is if you have the same table ("class")
aggregated by two other tables. Rose will interpret this as the resolution
to a m:m relationship and create an association class instead of two
aggregate relationships.
3) Rose will not reverse engineer role names for the association ends. It
doesn't use either the names of the triggers (FK_) or the names of the FK
columns to create a role name.
4) All associations will be assumed to be navigable in both directions
since that concept is not used in the data model. (FKs do not represent
the same type of navigation. As a matter of fact, the object concept and
the relational concept are almost exact opposites. If you are dealing with
Order and OrderLine, you might say that an Order should know about the
Lines it contains but that a Line doesn't know about the Order it is part
of. In object, you would implement that as a collection of Lines in the
Order. In relational, you would implement that by having the primary key
of Order be a foreign key in OrderLine so that the appearance is that the
Line has knowledge of the Order but the Order doesn't have knowledge of the
line.)
In the past, I have done scripting that would accomplish what you want in
the following way:
Extract the class, attribute, operation, and association information
to Excel spreadsheets
Read the information from the spreadsheets into a new package or
model. First add the classes as new classes (Category.AddClass(), then add
the other items in any order desired (Class.AddOperation(),
Class.AddAttribute(), Category.AddAssociation()). You will need to deal
with classes by name, so if you have any duplicate names in other packages
in the model, you could have unpredictable results.
You probably don't need to deal with the operations since they would only
be triggers for the constraints and wouldn't reflect any true object
behavior.
So it comes down to the usual question of benefit vs effort.
*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
* Only plain-text messages are supported.
* HTML or Rich-Text messages may be rejected.
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
* http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
* To: [EMAIL PROTECTED]
* Subject: <BLANK>
* Body: unsubscribe rose_forum
*************************************************************************
