Thoughts on Class to ERD 1

[jfrost10]

Hey guys,

I had a discussion with a friend of mine today regarding how, although we both believe the theory of it, there isn't any documented methodology for taking classes in a state diagram and turning them into the basis for an ERD or schema. Right now, we just basically hand the state diagram off to the db personnel to develop the schema with. This works well, but if your main db analyst isn't versed in UML, issues could occur.

Just curious what your thoughts or experiences are in regards to the state to ERD diagrams are.

And if you're of the thought that this SHOULDN'T happen, or the database should come first, please don't bother posting: I'm looking for thoughts from like minded people, not an argument.

Thanks,

Jack

 

[DonQuichote]

I don't know what ERD means. Could you please explain it or give a link to an explanation?

Thanks

 

[jfrost10]

ERD = Entity Relationship Diagram

Its typically the key diagram used to map out data entity relationships, and used mainly in development of a database (from my understanding).

Jack

 

[GARooke]

I assume you mean "Classes in a Class Diagram", not State Diagram.

Select Enterprise and Rational Rose both provide automatic conversions between the two. They use fairly standard rules. There is some hand crafting during the conversion if your classes are not 'well normalised', but any thing you sort out is remembered and used every time you reconvert.

The biggest impact is with inheritance. You are given three choices:
Place base class attributes in every derived class
Make 1:1 mappings between the base class and each derived class
Place the union of all attributes for all the derived classes in the base class (non-normalised solution)

Link classes are retained as linking entities.
Aggregation becomes an identifying relationship.
Associations are non-identifying.
Prime DataTypes map to Domains
Class DataTypes are not mapped
Qualifiers are mapped as Keys, Alternate keys or inversion entries.

Then there are less strucural things all of which are remembered on subsequent runs.
Decisions on which classes to include.
Attribute names can be changed so that datanames meet different naming standards
Key and unique fields needed to be flagged
All Tables can be given a unique serial ID number for database requirements.
The output from Select consists of:
ERD Diagrams drawn by Select
CREATE and other SQL statements to allow the database to be created or maintained.
ERWIN import files that allow the output to be further manipulated in that tool.

When reverse engineering, new tables create new classes, which in Select are easily found, because right clicking on a class allows you to import into the diagram all other classes associateds with that class.
Sorry! I shouldn't have mentioned this last capability. You said you wouldn't talk to me if I did. There are times:-((

Gil

 

[jfrost10]

LOL

thanks for your thoughts Gil. I didn't mean that last line of my original post to be taken as sternly as it might have sounded. I just know how passionate us OO people can get about our methodologies.


jack

 

[jfrost10]

Hey Gil,

Just to clarify the wording I meant of "State Diagram" (went back to the book for it):

In the Iconix methodology (which we're using), the first step is to go through the requirements and create a very high level class diagram, but without the attributes or cardinalities. Just a general idea of what main objects will be required, and how they relate simply to each other
i.e. ClassOrder contains ClassProduct, but no other detail is recorded.

Over teh development process, that model gets added to, changed, and has detail added.

So really, it does mean "classes in a class diagram" (in the ICONIX vocabulary anyway), just a VERY early class diagram.

Just wanted to clear that up.


jack