Inheritance Strategy incorrect behavior

I am having difficulty getting desired results synchronizing a class heirarchy model to an Entity Relationship model. The biggest problem I have is associated with the inheritance of attribution from parent class to subclass.

Example; I have an abstract class GeographicPoint with attributes A, B, and C with Subclasses Building and Marker. The Building subclass has attributes D and E and the Marker subclass has attributes F and G. What I would expect to see generated in the ER model is two tables Building (with attributes A, B, C, D and E) and Marker (with attributes A, B, C, F, G). Only the leaf nodes (Building and Marker) are stereotyped as ORM Persistable.

Looking at the inheritance strategies, Table per Subclass should generate the results I am looking for, however only the attributes specific to the subclasses appear in the generated entities.

What is the trick to get the inherited attributes to generate correctly into the ER model.

Thanks

Kern Blackburn
Autodesk, Inc.

Hi Kern Blackburn,

Thank you for your post. We are sorry that we do not support what you expect to see (to show two tables Building with attributes A, B, C, D, E and Marker with attributes A, B, C, F, G).

If you set “Table per subclass” in inheritance strategy for each subclass, you will have a table of super class in database. However, no matter it has a table or not, there will be no difference when using the class model.

Would you mind telling me why you do not want to save the GeographicPoint as a table?

Best regards,
Lilian Wong

There are a lot of good reasons for not wanting to implement GeographicPoint as a table. Briefly, I am working on an Automated Mapping application that does spatial analysis and network topology. The physical design your tool supports presents makes doing some of that processing awkward.

Every other modeling tool I’ve used alows me to generate entities as I need to, even Visio. Can you briefly tell me why yours doesn’t?

Hi Kern Blackburn,

Thank you for replying. We are sorry that it’s the current limitation so that we do not support generating entities as you expect. However, it’s a great suggestion and we are investigating the possibility to support this in our tool. If there are any news about this issue, I’ll notify you immediately.

If you need any help, please do not hesitate to contact me.

Best regards,
Lilian Wong

One of the biggest disappointments I have encountered with using Visual Paradigm is its inheritance strategy options. Traditionally, tools support three types, generate parent only, generate parent and children and generate children only. VP only supports the first two options. While this may be a workable scenario for the design of transient objects, it has the impact of adding significant amounts of mundane labor to a model design in order to get desired results for a database design. In short, there are many factors a DBA takes into account when designing tables, including a familiarity with the data and the size of the tables, the selectivity of indexes, potential replication strategies, and application query performance. These factors are independent of theoretical modeling considerations and the inability to provide the necessary flexibility in VP is a major shortcoming of the product.
I will provide an example from a recent model. Below is the conceptual design.

http://www.kernblackburn.us/images/cdm_ex.jpg

There are several levels of abstract class. I prefer to model ‘common’ attributes and behavior at higher levels in order to keep the noise down in the model. However, the intention is to propagate these attributes to the leaf node and generate those as persistent tables. The entity/relationship model I expect to be able to generate from this design is included below.

http://www.kernblackburn.us/images/pdm_ex.jpg

There is absolutely no way to generate this design from VP without manually pushing all the attributes down the inheritance chain. The result is an awkward, clumsy, ugly conceptual design that takes more work to complete.

Hi Kern,

Thanks for your reply and the details. We’re sorry for the inconvenience caused in our current version.

We already have plan on supporting this feature, it will be supported in VP-UML 6.3 (VP Suite 3.3), which will be release on about June. I’ll keep you informed for any news about this feature.

If there are any inquiries, please do not hesitate to ask.

Best regards,
Lilian Wong