Home » Eclipse Projects » DTP » Data Modeling Notations
| Data Modeling Notations [message #123] |
Sun, 03 April 2005 21:36  |
Eclipse User |
|
|
|
Originally posted by: eclipse.ambysoft.com
One of the data modeling notations which I would like to propose we
support is UML. I've posted the start of a profile at
http://www.agiledata.org/essays/umlDataModelingProfile.html which for
the most part focuses on physical data modeling. This profile is not
complete, although I would argue that it's the most sophisticated one
currently available today. I'm always open to suggestions for
improvements to it, and fully expect that as work progresses that
we'll need to expand on what is currently there.
We should also support other notations, such as Barker and Information
Engineering (to name two), although I suspect that UML will be the
easiest to support seeing as Eclipse currently supports UML class
modeling.
- Scott
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #129 is a reply to message #123] |
Mon, 04 April 2005 23:17  |
| Eclipse User |
|
|
|
Originally posted by: mail.martynroberts.com
I think we should focus on UML to begin with so, as you say, we can take
advantage of existing developments. UML also strikes me as the most
extensible notation, something we will need for vendor neutrality while
at the same time being able to support proprietary features.
Scott Ambler wrote:
> One of the data modeling notations which I would like to propose we
> support is UML. I've posted the start of a profile at
> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
> the most part focuses on physical data modeling. This profile is not
> complete, although I would argue that it's the most sophisticated one
> currently available today. I'm always open to suggestions for
> improvements to it, and fully expect that as work progresses that
> we'll need to expand on what is currently there.
>
> We should also support other notations, such as Barker and Information
> Engineering (to name two), although I suspect that UML will be the
> easiest to support seeing as Eclipse currently supports UML class
> modeling.
>
> - Scott
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #131 is a reply to message #129] |
Tue, 05 April 2005 18:21 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.ambysoft.com
Exactly.
It also has the benefit that many Eclipse users are likely to be
familiar with it.
- Scott
On Tue, 05 Apr 2005 00:17:17 +0100, Martyn Roberts
<mail@martynroberts.com> wrote:
>I think we should focus on UML to begin with so, as you say, we can take
>advantage of existing developments. UML also strikes me as the most
>extensible notation, something we will need for vendor neutrality while
>at the same time being able to support proprietary features.
>
>Scott Ambler wrote:
>> One of the data modeling notations which I would like to propose we
>> support is UML. I've posted the start of a profile at
>> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
>> the most part focuses on physical data modeling. This profile is not
>> complete, although I would argue that it's the most sophisticated one
>> currently available today. I'm always open to suggestions for
>> improvements to it, and fully expect that as work progresses that
>> we'll need to expand on what is currently there.
>>
>> We should also support other notations, such as Barker and Information
>> Engineering (to name two), although I suspect that UML will be the
>> easiest to support seeing as Eclipse currently supports UML class
>> modeling.
>>
>> - Scott
>> Scott W. Ambler
>> www.ambysoft.com/scottAmbler.html
>> Visit www.agiledata.org for my data writings.
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #134 is a reply to message #123] |
Tue, 05 April 2005 19:27 |
 Pete Rivett
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
You should be aware of the GMF project proposal which aims to directly
support development of such modeling tools based on EMF (as UML is) but
with more freedom of notation.
You should also consider whether to use UML as the underyling metamodel: I'd
suggest not - it is probably more appropriate to use a (EMF) metamodel more
focused on the subject matter (data modeling) which will make it a lot
easier to manipulate, interchange, and render the same model using different
notations. With a UML Profile, if you have a Stereotype such as <<Table>>
which you can attach to UML Class shapes, then in an actual model you send
up with both a Class object and a Table object.
One existing metamodel to consider is the Relational part of the Common
Warehouse Metamodel from OMG: this has the advantage of inheriting from a
UML-like core.
BTW Now that UML2 Finalization is out of the way, watch out for a more
data-oriented initiative/RFP from OMG which is likely to encompass metamodel
and profile aspects.
Cheers,
Pete
"Scott Ambler" <eclipse@ambysoft.com> wrote in message
news:n6o051doeo49m7vde00lshmcfhgl2qcclb@4ax.com...
> One of the data modeling notations which I would like to propose we
> support is UML. I've posted the start of a profile at
> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
> the most part focuses on physical data modeling. This profile is not
> complete, although I would argue that it's the most sophisticated one
> currently available today. I'm always open to suggestions for
> improvements to it, and fully expect that as work progresses that
> we'll need to expand on what is currently there.
>
> We should also support other notations, such as Barker and Information
> Engineering (to name two), although I suspect that UML will be the
> easiest to support seeing as Eclipse currently supports UML class
> modeling.
>
> - Scott
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #136 is a reply to message #131] |
Wed, 06 April 2005 08:26 |
| Eclipse User |
|
|
|
Originally posted by: user.server.net
In general, it would be very helpful to have an integrated modeling tool
supporting such powerful/comprehensive modeling frameworks as the
proposed one. I might be missing out something in the overall DTP (and
expecting something from the modeling subproject, the overall project
will asure in different ways), but for smaller projects it might be
helpful to also have very simple ways of modelling/documentation like
the good old ER at your disposition (which surely can be part of a UML
model).
Baseline: The idea of an overall framework sounds very good to me; yet
please don't make it to rigid, so it can be stipped down for small projects.
Best regards,
Kai
---
kai <dot> sautter <at> coreva <dot> com
Scott Ambler wrote:
> Exactly.
>
> It also has the benefit that many Eclipse users are likely to be
> familiar with it.
>
> - Scott
>
> On Tue, 05 Apr 2005 00:17:17 +0100, Martyn Roberts
> <mail@martynroberts.com> wrote:
>
>
>>I think we should focus on UML to begin with so, as you say, we can take
>>advantage of existing developments. UML also strikes me as the most
>>extensible notation, something we will need for vendor neutrality while
>>at the same time being able to support proprietary features.
>>
>>Scott Ambler wrote:
>>
>>>One of the data modeling notations which I would like to propose we
>>>support is UML. I've posted the start of a profile at
>>>http://www.agiledata.org/essays/umlDataModelingProfile.html which for
>>>the most part focuses on physical data modeling. This profile is not
>>>complete, although I would argue that it's the most sophisticated one
>>>currently available today. I'm always open to suggestions for
>>>improvements to it, and fully expect that as work progresses that
>>>we'll need to expand on what is currently there.
>>>
>>>We should also support other notations, such as Barker and Information
>>>Engineering (to name two), although I suspect that UML will be the
>>>easiest to support seeing as Eclipse currently supports UML class
>>>modeling.
>>>
>>>- Scott
>>>Scott W. Ambler
>>>www.ambysoft.com/scottAmbler.html
>>>Visit www.agiledata.org for my data writings.
>
>
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #138 is a reply to message #136] |
Thu, 07 April 2005 12:53 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.ambysoft.com
On Wed, 06 Apr 2005 10:26:23 +0200, Kai Sautter <user@server.net>
wrote:
>In general, it would be very helpful to have an integrated modeling tool
>supporting such powerful/comprehensive modeling frameworks as the
>proposed one. I might be missing out something in the overall DTP (and
>expecting something from the modeling subproject, the overall project
>will asure in different ways), but for smaller projects it might be
>helpful to also have very simple ways of modelling/documentation like
>the good old ER at your disposition (which surely can be part of a UML
>model).
Definitely. If you look at the profile it basically shows how to do
ER modeling with the UML. My point is that far more developers will
know UML than they will common ER notations, so we should start with
UML. However, some people definitely like ER notations so why can't
we support both views and simply toggle back and forth between them.
- Scott
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #141 is a reply to message #134] |
Thu, 07 April 2005 13:08 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.ambysoft.com
On Tue, 5 Apr 2005 20:27:16 +0100, "Pete Rivett"
<pete.rivett@adaptive.com> wrote:
>You should be aware of the GMF project proposal which aims to directly
>support development of such modeling tools based on EMF (as UML is) but
>with more freedom of notation.
Yes, I'm definitely aware of this effort and would want to work
closely with this team. No need to reinvent the wheel, IMHO.
>
>You should also consider whether to use UML as the underyling metamodel: I'd
>suggest not - it is probably more appropriate to use a (EMF) metamodel more
>focused on the subject matter (data modeling) which will make it a lot
>easier to manipulate, interchange, and render the same model using different
>notations.
We need to distinguish between the underlying metamodel and the
notation. My real issue is with the notation -- the vast majority
(e.g. 99.9%) of developers could care less about the metamodel when it
comes to modeling, at best they'll learn the notation and hopefully
how to use it.
Tool builders worry about the metamodel, and for then it's critical to
the success.
So, let's remember to distinguish between the two.
> With a UML Profile, if you have a Stereotype such as <<Table>>
>which you can attach to UML Class shapes, then in an actual model you send
>up with both a Class object and a Table object.
Yes. In the profile I talk about a large number of potential
stereotypes, including <<Table>>, as well as provide advice for when
to visually display them and when not to. Although the stereotype is
important to have in the model itself, it actually proves to be
"visual noise" on the diagrams. If you know that you're modeling a
relational db, then by default you can assume that the boxes are
tables unless otherwise noted. You wouldn't show the stereotype
"Business Class" on your business classes, would you? Same thing with
tables.
>
>One existing metamodel to consider is the Relational part of the Common
>Warehouse Metamodel from OMG: this has the advantage of inheriting from a
>UML-like core.
Exactly. I've suggested exactly this in the past too. Unfortunately
the CWM is effectively dead in the water, nobody within the data
community seems to take it seriously, nor should they, but the reality
is that there is some pretty good thinking there that we could harvest
for our data modeling efforts. I've already done some of that in the
existing profile.
>
>BTW Now that UML2 Finalization is out of the way, watch out for a more
>data-oriented initiative/RFP from OMG which is likely to encompass metamodel
>and profile aspects.
Too little, too late, IMHO. I was suggesting this back in 1997 when
the initial version of the UML first came out.
However, it's nice that they're finally thinking about doing the work
that has obviously needed to be done for quite some time, but
considering their past track record I wouldn't want to wait around for
these folks. If they're able to produce anything of relevance then we
should use it, otherwise they can catch up to what we're doing.
A lot of the work is already done at
http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
sure what the OMG has to offer other than bureacracy. You might find
my article at
http://www.sdmagazine.com/documents/s=9604/sdm0504i/sdm0504i .htm to be
entertaining.
When you stop and think about it, if we can develop software in an
open source manner then why can't we develop UML profiles in an open
source manner? It makes you question the relevance of the OMG, at
least when it comes to the UML.
- Scott
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #186 is a reply to message #141] |
Sun, 24 April 2005 16:38 |
Pete Rivett
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
> Exactly. I've suggested exactly this in the past too. Unfortunately
> the CWM is effectively dead in the water, nobody within the data
> community seems to take it seriously, nor should they,
Scott,
Perhaps 'dead in the water' was another of your April Fools (like your
SDMagazine article), since I suspect the vast majority of the 'data
community' are using a tool that can exchange via CWM either directly or
indirectly.
Vendors supporting CWM include (in no particular order):
IBM
Oracle
SAS
Cognos
Informatica
Metamatrix
Hyperion
Allen Systems Group
Data Advantage Group
Embarcadero
Adaptive
And bridges are available (e.g. from MetaIntegration) that support:
Business Objects
ERwin
Most databases (reverse engineering a model from schema)
Most UML Tools
CWM is an interchange standard so is primarily of interest to vendors and
integrators: data modeling users should just look for the 'tick on the box'
when selecting a tool if they want to ensure interoperability. Frequent
interoperability showcases have shown that it really works without the
difficulties that people ave had with UML XMI.
> Too little, too late, IMHO. I was suggesting this back in 1997 when
> the initial version of the UML first came out.
With respect to 'too little' what else would you like to see?
> A lot of the work is already done at
> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
> sure what the OMG has to offer other than bureacracy.
What you have there is a good input (are you happy, from copyright
perspective, for this to be taken as input to a standard?), as are the
efforts of a number of vendors who have had their own bash at this. What OMG
as to offer is a 'seal of approval' from a large community of vendors -
which is what matters for real interoperability between real tools you can
buy off the shelf. Yes there is an element of bureaucracy but what would you
expect when getting a large number of vendors with competing vested
interests to agree to something they will implement ?
Pete
"Scott Ambler" <eclipse@ambysoft.com> wrote in message
news:baba51tkr4mmi78jv65uvpcfepnml6n7ol@4ax.com...
> On Tue, 5 Apr 2005 20:27:16 +0100, "Pete Rivett"
> <pete.rivett@adaptive.com> wrote:
>
>>You should be aware of the GMF project proposal which aims to directly
>>support development of such modeling tools based on EMF (as UML is) but
>>with more freedom of notation.
>
> Yes, I'm definitely aware of this effort and would want to work
> closely with this team. No need to reinvent the wheel, IMHO.
>
>>
>>You should also consider whether to use UML as the underyling metamodel:
>>I'd
>>suggest not - it is probably more appropriate to use a (EMF) metamodel
>>more
>>focused on the subject matter (data modeling) which will make it a lot
>>easier to manipulate, interchange, and render the same model using
>>different
>>notations.
>
> We need to distinguish between the underlying metamodel and the
> notation. My real issue is with the notation -- the vast majority
> (e.g. 99.9%) of developers could care less about the metamodel when it
> comes to modeling, at best they'll learn the notation and hopefully
> how to use it.
>
> Tool builders worry about the metamodel, and for then it's critical to
> the success.
>
> So, let's remember to distinguish between the two.
>
>> With a UML Profile, if you have a Stereotype such as <<Table>>
>>which you can attach to UML Class shapes, then in an actual model you send
>>up with both a Class object and a Table object.
>
> Yes. In the profile I talk about a large number of potential
> stereotypes, including <<Table>>, as well as provide advice for when
> to visually display them and when not to. Although the stereotype is
> important to have in the model itself, it actually proves to be
> "visual noise" on the diagrams. If you know that you're modeling a
> relational db, then by default you can assume that the boxes are
> tables unless otherwise noted. You wouldn't show the stereotype
> "Business Class" on your business classes, would you? Same thing with
> tables.
>
>>
>>One existing metamodel to consider is the Relational part of the Common
>>Warehouse Metamodel from OMG: this has the advantage of inheriting from a
>>UML-like core.
>
> Exactly. I've suggested exactly this in the past too. Unfortunately
> the CWM is effectively dead in the water, nobody within the data
> community seems to take it seriously, nor should they, but the reality
> is that there is some pretty good thinking there that we could harvest
> for our data modeling efforts. I've already done some of that in the
> existing profile.
>
>>
>>BTW Now that UML2 Finalization is out of the way, watch out for a more
>>data-oriented initiative/RFP from OMG which is likely to encompass
>>metamodel
>>and profile aspects.
>
> Too little, too late, IMHO. I was suggesting this back in 1997 when
> the initial version of the UML first came out.
>
> However, it's nice that they're finally thinking about doing the work
> that has obviously needed to be done for quite some time, but
> considering their past track record I wouldn't want to wait around for
> these folks. If they're able to produce anything of relevance then we
> should use it, otherwise they can catch up to what we're doing.
>
> A lot of the work is already done at
> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
> sure what the OMG has to offer other than bureacracy. You might find
> my article at
> http://www.sdmagazine.com/documents/s=9604/sdm0504i/sdm0504i .htm to be
> entertaining.
>
> When you stop and think about it, if we can develop software in an
> open source manner then why can't we develop UML profiles in an open
> source manner? It makes you question the relevance of the OMG, at
> least when it comes to the UML.
>
> - Scott
>
>
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #195 is a reply to message #186] |
Sun, 24 April 2005 22:32 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.ambysoft.com
On Sun, 24 Apr 2005 17:38:03 +0100, "Pete Rivett"
<pete.rivett@adaptive.com> wrote:
>> Exactly. I've suggested exactly this in the past too. Unfortunately
>> the CWM is effectively dead in the water, nobody within the data
>> community seems to take it seriously, nor should they,
>
>Scott,
>Perhaps 'dead in the water' was another of your April Fools (like your
>SDMagazine article), since I suspect the vast majority of the 'data
>community' are using a tool that can exchange via CWM either directly or
>indirectly.
>
>Vendors supporting CWM include (in no particular order):
Having talked with many people in the data community about this, I
have yet to meet anyone that considers CWM to be something worth
considering. The vendors can claim they support it, but is it being
used in practice for anything of significance? The people who should
be taking CWM seriously, the data folks, don't seem to be doing so.
<snip>
>
>> Too little, too late, IMHO. I was suggesting this back in 1997 when
>> the initial version of the UML first came out.
>
>With respect to 'too little' what else would you like to see?
http://www.agilemodeling.com/essays/realisticUML.htm
>
>> A lot of the work is already done at
>> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
>> sure what the OMG has to offer other than bureacracy.
>
>What you have there is a good input (are you happy, from copyright
>perspective, for this to be taken as input to a standard?), as are the
>efforts of a number of vendors who have had their own bash at this.
I'm happy to have that work used as the base for a standard, and have
indicated so several times.
The problem with vendors approaches, and I've actually worked with one
of the vendors who has also published their thoughts about how to data
model with UML, is that they never seem to cover the full spectrum of
data modeling. The vendors always seem to want to focus on just what
their tools can handle.
> What OMG
>as to offer is a 'seal of approval' from a large community of vendors -
But does the seal of approval mean anything. The OMG put their seal
on a variety of CORBA ORBs, yet they always seemed to be very
difficult to get working together. I've lost track of the number of
tools which support XMI, yet have yet to see a combination of tools
which don't have information loss between them when you start doing
round-trip work.
>which is what matters for real interoperability between real tools you can
>buy off the shelf.
The OMG wouldn't know what real interoperability was if it hit them in
the side of the head. I'll let the OMG's interoperability track
record stand on it's own. CORBA interoperability is little more than
a bad joke. Same thing with XMI interoperability.
> Yes there is an element of bureaucracy but what would you
>expect when getting a large number of vendors with competing vested
>interests to agree to something they will implement ?
Then perhaps we should try a better way. When it comes to UML data
modeling the OMG has clearly failed. Let's try an open source
approach and see how that works.
- Scott
<snip>
|
|
|
| Re: Data Modeling Notations [message #564516 is a reply to message #123] |
Mon, 04 April 2005 23:17 |
| Eclipse User |
|
|
|
Originally posted by: mail.martynroberts.com
I think we should focus on UML to begin with so, as you say, we can take
advantage of existing developments. UML also strikes me as the most
extensible notation, something we will need for vendor neutrality while
at the same time being able to support proprietary features.
Scott Ambler wrote:
> One of the data modeling notations which I would like to propose we
> support is UML. I've posted the start of a profile at
> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
> the most part focuses on physical data modeling. This profile is not
> complete, although I would argue that it's the most sophisticated one
> currently available today. I'm always open to suggestions for
> improvements to it, and fully expect that as work progresses that
> we'll need to expand on what is currently there.
>
> We should also support other notations, such as Barker and Information
> Engineering (to name two), although I suspect that UML will be the
> easiest to support seeing as Eclipse currently supports UML class
> modeling.
>
> - Scott
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #564546 is a reply to message #129] |
Tue, 05 April 2005 18:21 |
Scott Ambler
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
Exactly.
It also has the benefit that many Eclipse users are likely to be
familiar with it.
- Scott
On Tue, 05 Apr 2005 00:17:17 +0100, Martyn Roberts
<mail@martynroberts.com> wrote:
>I think we should focus on UML to begin with so, as you say, we can take
>advantage of existing developments. UML also strikes me as the most
>extensible notation, something we will need for vendor neutrality while
>at the same time being able to support proprietary features.
>
>Scott Ambler wrote:
>> One of the data modeling notations which I would like to propose we
>> support is UML. I've posted the start of a profile at
>> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
>> the most part focuses on physical data modeling. This profile is not
>> complete, although I would argue that it's the most sophisticated one
>> currently available today. I'm always open to suggestions for
>> improvements to it, and fully expect that as work progresses that
>> we'll need to expand on what is currently there.
>>
>> We should also support other notations, such as Barker and Information
>> Engineering (to name two), although I suspect that UML will be the
>> easiest to support seeing as Eclipse currently supports UML class
>> modeling.
>>
>> - Scott
>> Scott W. Ambler
>> www.ambysoft.com/scottAmbler.html
>> Visit www.agiledata.org for my data writings.
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #564606 is a reply to message #123] |
Tue, 05 April 2005 19:27 |
Pete Rivett
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
You should be aware of the GMF project proposal which aims to directly
support development of such modeling tools based on EMF (as UML is) but
with more freedom of notation.
You should also consider whether to use UML as the underyling metamodel: I'd
suggest not - it is probably more appropriate to use a (EMF) metamodel more
focused on the subject matter (data modeling) which will make it a lot
easier to manipulate, interchange, and render the same model using different
notations. With a UML Profile, if you have a Stereotype such as <<Table>>
which you can attach to UML Class shapes, then in an actual model you send
up with both a Class object and a Table object.
One existing metamodel to consider is the Relational part of the Common
Warehouse Metamodel from OMG: this has the advantage of inheriting from a
UML-like core.
BTW Now that UML2 Finalization is out of the way, watch out for a more
data-oriented initiative/RFP from OMG which is likely to encompass metamodel
and profile aspects.
Cheers,
Pete
"Scott Ambler" <eclipse@ambysoft.com> wrote in message
news:n6o051doeo49m7vde00lshmcfhgl2qcclb@4ax.com...
> One of the data modeling notations which I would like to propose we
> support is UML. I've posted the start of a profile at
> http://www.agiledata.org/essays/umlDataModelingProfile.html which for
> the most part focuses on physical data modeling. This profile is not
> complete, although I would argue that it's the most sophisticated one
> currently available today. I'm always open to suggestions for
> improvements to it, and fully expect that as work progresses that
> we'll need to expand on what is currently there.
>
> We should also support other notations, such as Barker and Information
> Engineering (to name two), although I suspect that UML will be the
> easiest to support seeing as Eclipse currently supports UML class
> modeling.
>
> - Scott
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #564631 is a reply to message #131] |
Wed, 06 April 2005 08:26 |
Kai Sautter
Messages: 1
Registered: July 2009 |
Junior Member |
|
|
In general, it would be very helpful to have an integrated modeling tool
supporting such powerful/comprehensive modeling frameworks as the
proposed one. I might be missing out something in the overall DTP (and
expecting something from the modeling subproject, the overall project
will asure in different ways), but for smaller projects it might be
helpful to also have very simple ways of modelling/documentation like
the good old ER at your disposition (which surely can be part of a UML
model).
Baseline: The idea of an overall framework sounds very good to me; yet
please don't make it to rigid, so it can be stipped down for small projects.
Best regards,
Kai
---
kai <dot> sautter <at> coreva <dot> com
Scott Ambler wrote:
> Exactly.
>
> It also has the benefit that many Eclipse users are likely to be
> familiar with it.
>
> - Scott
>
> On Tue, 05 Apr 2005 00:17:17 +0100, Martyn Roberts
> <mail@martynroberts.com> wrote:
>
>
>>I think we should focus on UML to begin with so, as you say, we can take
>>advantage of existing developments. UML also strikes me as the most
>>extensible notation, something we will need for vendor neutrality while
>>at the same time being able to support proprietary features.
>>
>>Scott Ambler wrote:
>>
>>>One of the data modeling notations which I would like to propose we
>>>support is UML. I've posted the start of a profile at
>>>http://www.agiledata.org/essays/umlDataModelingProfile.html which for
>>>the most part focuses on physical data modeling. This profile is not
>>>complete, although I would argue that it's the most sophisticated one
>>>currently available today. I'm always open to suggestions for
>>>improvements to it, and fully expect that as work progresses that
>>>we'll need to expand on what is currently there.
>>>
>>>We should also support other notations, such as Barker and Information
>>>Engineering (to name two), although I suspect that UML will be the
>>>easiest to support seeing as Eclipse currently supports UML class
>>>modeling.
>>>
>>>- Scott
>>>Scott W. Ambler
>>>www.ambysoft.com/scottAmbler.html
>>>Visit www.agiledata.org for my data writings.
>
>
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
| |
| Re: Data Modeling Notations [message #564686 is a reply to message #134] |
Thu, 07 April 2005 13:08 |
Scott Ambler
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
On Tue, 5 Apr 2005 20:27:16 +0100, "Pete Rivett"
<pete.rivett@adaptive.com> wrote:
>You should be aware of the GMF project proposal which aims to directly
>support development of such modeling tools based on EMF (as UML is) but
>with more freedom of notation.
Yes, I'm definitely aware of this effort and would want to work
closely with this team. No need to reinvent the wheel, IMHO.
>
>You should also consider whether to use UML as the underyling metamodel: I'd
>suggest not - it is probably more appropriate to use a (EMF) metamodel more
>focused on the subject matter (data modeling) which will make it a lot
>easier to manipulate, interchange, and render the same model using different
>notations.
We need to distinguish between the underlying metamodel and the
notation. My real issue is with the notation -- the vast majority
(e.g. 99.9%) of developers could care less about the metamodel when it
comes to modeling, at best they'll learn the notation and hopefully
how to use it.
Tool builders worry about the metamodel, and for then it's critical to
the success.
So, let's remember to distinguish between the two.
> With a UML Profile, if you have a Stereotype such as <<Table>>
>which you can attach to UML Class shapes, then in an actual model you send
>up with both a Class object and a Table object.
Yes. In the profile I talk about a large number of potential
stereotypes, including <<Table>>, as well as provide advice for when
to visually display them and when not to. Although the stereotype is
important to have in the model itself, it actually proves to be
"visual noise" on the diagrams. If you know that you're modeling a
relational db, then by default you can assume that the boxes are
tables unless otherwise noted. You wouldn't show the stereotype
"Business Class" on your business classes, would you? Same thing with
tables.
>
>One existing metamodel to consider is the Relational part of the Common
>Warehouse Metamodel from OMG: this has the advantage of inheriting from a
>UML-like core.
Exactly. I've suggested exactly this in the past too. Unfortunately
the CWM is effectively dead in the water, nobody within the data
community seems to take it seriously, nor should they, but the reality
is that there is some pretty good thinking there that we could harvest
for our data modeling efforts. I've already done some of that in the
existing profile.
>
>BTW Now that UML2 Finalization is out of the way, watch out for a more
>data-oriented initiative/RFP from OMG which is likely to encompass metamodel
>and profile aspects.
Too little, too late, IMHO. I was suggesting this back in 1997 when
the initial version of the UML first came out.
However, it's nice that they're finally thinking about doing the work
that has obviously needed to be done for quite some time, but
considering their past track record I wouldn't want to wait around for
these folks. If they're able to produce anything of relevance then we
should use it, otherwise they can catch up to what we're doing.
A lot of the work is already done at
http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
sure what the OMG has to offer other than bureacracy. You might find
my article at
http://www.sdmagazine.com/documents/s=9604/sdm0504i/sdm0504i .htm to be
entertaining.
When you stop and think about it, if we can develop software in an
open source manner then why can't we develop UML profiles in an open
source manner? It makes you question the relevance of the OMG, at
least when it comes to the UML.
- Scott
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #564817 is a reply to message #141] |
Sun, 24 April 2005 16:38 |
Pete Rivett
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
> Exactly. I've suggested exactly this in the past too. Unfortunately
> the CWM is effectively dead in the water, nobody within the data
> community seems to take it seriously, nor should they,
Scott,
Perhaps 'dead in the water' was another of your April Fools (like your
SDMagazine article), since I suspect the vast majority of the 'data
community' are using a tool that can exchange via CWM either directly or
indirectly.
Vendors supporting CWM include (in no particular order):
IBM
Oracle
SAS
Cognos
Informatica
Metamatrix
Hyperion
Allen Systems Group
Data Advantage Group
Embarcadero
Adaptive
And bridges are available (e.g. from MetaIntegration) that support:
Business Objects
ERwin
Most databases (reverse engineering a model from schema)
Most UML Tools
CWM is an interchange standard so is primarily of interest to vendors and
integrators: data modeling users should just look for the 'tick on the box'
when selecting a tool if they want to ensure interoperability. Frequent
interoperability showcases have shown that it really works without the
difficulties that people ave had with UML XMI.
> Too little, too late, IMHO. I was suggesting this back in 1997 when
> the initial version of the UML first came out.
With respect to 'too little' what else would you like to see?
> A lot of the work is already done at
> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
> sure what the OMG has to offer other than bureacracy.
What you have there is a good input (are you happy, from copyright
perspective, for this to be taken as input to a standard?), as are the
efforts of a number of vendors who have had their own bash at this. What OMG
as to offer is a 'seal of approval' from a large community of vendors -
which is what matters for real interoperability between real tools you can
buy off the shelf. Yes there is an element of bureaucracy but what would you
expect when getting a large number of vendors with competing vested
interests to agree to something they will implement ?
Pete
"Scott Ambler" <eclipse@ambysoft.com> wrote in message
news:baba51tkr4mmi78jv65uvpcfepnml6n7ol@4ax.com...
> On Tue, 5 Apr 2005 20:27:16 +0100, "Pete Rivett"
> <pete.rivett@adaptive.com> wrote:
>
>>You should be aware of the GMF project proposal which aims to directly
>>support development of such modeling tools based on EMF (as UML is) but
>>with more freedom of notation.
>
> Yes, I'm definitely aware of this effort and would want to work
> closely with this team. No need to reinvent the wheel, IMHO.
>
>>
>>You should also consider whether to use UML as the underyling metamodel:
>>I'd
>>suggest not - it is probably more appropriate to use a (EMF) metamodel
>>more
>>focused on the subject matter (data modeling) which will make it a lot
>>easier to manipulate, interchange, and render the same model using
>>different
>>notations.
>
> We need to distinguish between the underlying metamodel and the
> notation. My real issue is with the notation -- the vast majority
> (e.g. 99.9%) of developers could care less about the metamodel when it
> comes to modeling, at best they'll learn the notation and hopefully
> how to use it.
>
> Tool builders worry about the metamodel, and for then it's critical to
> the success.
>
> So, let's remember to distinguish between the two.
>
>> With a UML Profile, if you have a Stereotype such as <<Table>>
>>which you can attach to UML Class shapes, then in an actual model you send
>>up with both a Class object and a Table object.
>
> Yes. In the profile I talk about a large number of potential
> stereotypes, including <<Table>>, as well as provide advice for when
> to visually display them and when not to. Although the stereotype is
> important to have in the model itself, it actually proves to be
> "visual noise" on the diagrams. If you know that you're modeling a
> relational db, then by default you can assume that the boxes are
> tables unless otherwise noted. You wouldn't show the stereotype
> "Business Class" on your business classes, would you? Same thing with
> tables.
>
>>
>>One existing metamodel to consider is the Relational part of the Common
>>Warehouse Metamodel from OMG: this has the advantage of inheriting from a
>>UML-like core.
>
> Exactly. I've suggested exactly this in the past too. Unfortunately
> the CWM is effectively dead in the water, nobody within the data
> community seems to take it seriously, nor should they, but the reality
> is that there is some pretty good thinking there that we could harvest
> for our data modeling efforts. I've already done some of that in the
> existing profile.
>
>>
>>BTW Now that UML2 Finalization is out of the way, watch out for a more
>>data-oriented initiative/RFP from OMG which is likely to encompass
>>metamodel
>>and profile aspects.
>
> Too little, too late, IMHO. I was suggesting this back in 1997 when
> the initial version of the UML first came out.
>
> However, it's nice that they're finally thinking about doing the work
> that has obviously needed to be done for quite some time, but
> considering their past track record I wouldn't want to wait around for
> these folks. If they're able to produce anything of relevance then we
> should use it, otherwise they can catch up to what we're doing.
>
> A lot of the work is already done at
> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
> sure what the OMG has to offer other than bureacracy. You might find
> my article at
> http://www.sdmagazine.com/documents/s=9604/sdm0504i/sdm0504i .htm to be
> entertaining.
>
> When you stop and think about it, if we can develop software in an
> open source manner then why can't we develop UML profiles in an open
> source manner? It makes you question the relevance of the OMG, at
> least when it comes to the UML.
>
> - Scott
>
>
> Scott W. Ambler
> www.ambysoft.com/scottAmbler.html
> Visit www.agiledata.org for my data writings.
|
|
|
| Re: Data Modeling Notations [message #564866 is a reply to message #186] |
Sun, 24 April 2005 22:32 |
eclipse
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
On Sun, 24 Apr 2005 17:38:03 +0100, "Pete Rivett"
<pete.rivett@adaptive.com> wrote:
>> Exactly. I've suggested exactly this in the past too. Unfortunately
>> the CWM is effectively dead in the water, nobody within the data
>> community seems to take it seriously, nor should they,
>
>Scott,
>Perhaps 'dead in the water' was another of your April Fools (like your
>SDMagazine article), since I suspect the vast majority of the 'data
>community' are using a tool that can exchange via CWM either directly or
>indirectly.
>
>Vendors supporting CWM include (in no particular order):
Having talked with many people in the data community about this, I
have yet to meet anyone that considers CWM to be something worth
considering. The vendors can claim they support it, but is it being
used in practice for anything of significance? The people who should
be taking CWM seriously, the data folks, don't seem to be doing so.
<snip>
>
>> Too little, too late, IMHO. I was suggesting this back in 1997 when
>> the initial version of the UML first came out.
>
>With respect to 'too little' what else would you like to see?
http://www.agilemodeling.com/essays/realisticUML.htm
>
>> A lot of the work is already done at
>> http://www.agiledata.org/essays/umlDataModelingProfile.html , I'm not
>> sure what the OMG has to offer other than bureacracy.
>
>What you have there is a good input (are you happy, from copyright
>perspective, for this to be taken as input to a standard?), as are the
>efforts of a number of vendors who have had their own bash at this.
I'm happy to have that work used as the base for a standard, and have
indicated so several times.
The problem with vendors approaches, and I've actually worked with one
of the vendors who has also published their thoughts about how to data
model with UML, is that they never seem to cover the full spectrum of
data modeling. The vendors always seem to want to focus on just what
their tools can handle.
> What OMG
>as to offer is a 'seal of approval' from a large community of vendors -
But does the seal of approval mean anything. The OMG put their seal
on a variety of CORBA ORBs, yet they always seemed to be very
difficult to get working together. I've lost track of the number of
tools which support XMI, yet have yet to see a combination of tools
which don't have information loss between them when you start doing
round-trip work.
>which is what matters for real interoperability between real tools you can
>buy off the shelf.
The OMG wouldn't know what real interoperability was if it hit them in
the side of the head. I'll let the OMG's interoperability track
record stand on it's own. CORBA interoperability is little more than
a bad joke. Same thing with XMI interoperability.
> Yes there is an element of bureaucracy but what would you
>expect when getting a large number of vendors with competing vested
>interests to agree to something they will implement ?
Then perhaps we should try a better way. When it comes to UML data
modeling the OMG has clearly failed. Let's try an open source
approach and see how that works.
- Scott
<snip>
|
|
| |
Goto Forum:
Current Time: Fri Aug 16 16:27:49 GMT 2024
Powered by FUDForum. Page generated in 0.08108 seconds |
] 
Search
Help
Register
Login
Home
