Use <<entity>> stereotype for data modeling?

[dana n]

A colleague claims that, since UML already defines an <<entity>> stereotype, we should start with that for data(base) modeling rather than use EA's UML Profile for Data Modeling. He's seeming to dislike that EA's profile does not begin with <<entity>>.

Some questions:

* Is it somehow illegitimate to create / use a UML Profile for Data Modeling that doesn't start with the pre-defined <<entity>> stereotype? Presuming here that the EA profile starts with class and then stereotypes it as <<table>>. What are the pros and cons of this approach?

* If we want to do conceptual data modeling > logical data modeling > physical modeling, should we in fact start with the <<entity>> stereotype and build our own profile and transforms? Is this reinventing the wheel, or does it buy us something worth having?

* Looking for a good definition of "Domain Model". My colleage says we really ought to begin with a "Domain Model" first, then transform into logical and then physical models.

Don't know if this should actually be a new post in its own right; but I think it should due to the "why are people seeming to ignore the pre-existing <<entity>> stereotype in UML"?

I guess I'm further confused by the fact that stereotypes, I thought, were for the purpose of extending UML--with me strictly interpreting it as non-canonical, extra UML 2.1 extensibility; e.g. customizability by any old person. Does OMG use stereotypes to get from one release of UML to later releases?

Thanks very much.

Dana

[Geert Bellekens]

Hmm, I see, a classical mistake.
In fact if you have a look in the current UML specification (2.2) then you will not find that <<entity>> stereotype anymore (except for components, but that is not related to this issue)
The <<entity>> stereotype you are talking about was included in a previous UML specification (1.4 I think) as part of an example of a profile. This example was a profile that used the ECB (Entity Control Boundary) paradigm.
Now because this stereotype was in the UML specification a lot of people (and toolbuilders) mistakingly thought this was a standard UML stereotype. Well, it isn't.
So unless you want to use the ECB paradigm I suggest you use the stereotypes that seem appropriate for your domain and forget about this "standard" <<entity>> stereotype.

Geert

[dana n]

Hmm, I see, a classical mistake.
In fact if you have a look in the current UML specification (2.2) then you will not find that <<entity>> stereotype anymore (except for components, but that is not related to this issue)
The <<entity>> stereotype you are talking about was included in a previous UML specification (1.4 I think) as part of an example of a profile. This example was a profile that used the ECB (Entity Control Boundary) paradigm.
Now because this stereotype was in the UML specification a lot of people (and toolbuilders) mistakingly thought this was a standard UML stereotype. Well, it isn't.
So unless you want to use the ECB paradigm I suggest you use the stereotypes that seem appropriate for your domain and forget about this "standard" <<entity>> stereotype.
Geert

Thanks Geert. I forwarded this info to my colleague. After reading it and seeing that <<entity>> is still in UML 2.2, but under Component as you stated, he seems to want to continue down that path. I didn't fully understand his explanation. But he looked it up in the UML 2.2 superstructure document > annex c Standard Stereotypes, where this definition is given:

"«entity» Components:: BasicComponents Component: A persistent information component representing a business
concept."

He argues that a "persistent information component representing a business concept" can be an entity as thought of in a Domain Model / ER Diagram; that you could go to a table from that as a starting point.

Is there anything wrong with that logic? Anyone else out there ever done this or thought of doing this?

I "argue" that the predominant way of doing things seems to be to use the Class Diagram as a starting point for data modeling. But maybe that's not a sufficient reason?

My main question to my colleage, and to you all, is this:

If we start from <<entity>> in our data modeling, what "bad things" might result, e.g.:

-- Would we be reinventing the wheel?
-- Would we be missing out on lots of good work already done?
-- Will we be prevented from doing anything we'd like to do?
-- Will it take huge amounts of staff hours to build transforms to interoperate with others?

I'm trying to peform "due dilligence" so we don't go down the wrong, possibly very esoteric, path.

Sorry I can't come up with any better questions. I'm very new to UML. And please don't shoot the messenger. :-)

Dana

[Geert Bellekens]

Dana,

First of all, do not use components to represent classes just because there is a familiar stereotype defined in UML.
Use components for what they are designed: to represent a container for your elements. You could use these <<entity>> components to represent your different databases for example, but not to represent to actual entities/business objects/concepts/whatever...
I don't know much about industry standards in this area, but I'm sure they all use classes and not components.

I'm not saying you shouldn't use entity as a steretoype for your (conceptual) datamodelling, I'm just saying that there is no reason (UML standard) to use entity in favour of another stereotype that might describe the (meta) concept you are modelling better. Maybe you don't even need a stereotype and you can just use classes without stereotype.
Just think about what you are modelling, what do you call these things? Entities? Business Objects? Information Objects,...
Then make sure you have a solid definition for this concept and try to find out if you really need a stereotype to distinguish these classes from other classes in your model. If this concept is the only concept represented by classes then why should you need a stereotype?
Even if there are different concepts represented by the same UML Class meta object, then there are still other ways to distinguish them, they could reside in another package ("Business Information Model" package vs "System Information Model" package for example) or you could use some sort of naming convention to distinguish them.

If you do want to use a stereotype then make sure it describes your (meta) concept in the best way possible.
It could be worth scouting the internet for existing profiles/modelling methods that you can use as a starting point. Just don't expect to find one that you can use out of the box without tuning it to your specific needs.

Hope this helps

Geert