Very apt, Betty,
I have thought for a long time that a conceptual model - which may very
well be in the form of an object-oriented model - should not commit one
to a design or implementation model that is necessarily object-oriented.
For example, one could have that object conceptual model but implement
software in procedural C code.
This is because the high-level model should promote understanding of the
job, while the design and implementation models have other goals.
The same can be true of the data implementation model (which might be in
XML, JSON, or ...), which need not be isomorphic to the conceptual data
model, as long as there is a reasonable mapping between them.
TomP
On 6/26/2016 10:05 PM, Betty Harvey wrote:
> Steve:
>
> As usual I agree with you and I do on this point as well!
>
> However, I am not sure what prompted Roger's question but it may be from
> some of the same frustration that I have experienced with large projects
> that use UML for the conceptual model. UML is great for conceptualizing
> and visualizing data models. The problem arises when the conceptual
> model derives the physical (XML) model. Large projects are sold on the
> concept that one UML software tool can be used for both the conceptual
> and physical model. The XML data model is produced directly from the
> UML model within the UML software. The result, unfortunately, is a
> complicated data model that lacks the natural inheritance of an XML data
> model.
>
> Personally I believe deriving the XML data model directly from the UML
> model without human intervention is a dead-wrong approach and I have the
> scars to prove it!
>
> I would love to see a 'standard' graphical representation of an XML
> model. When talking to UML folks about the capability of graphical
> representation of XML schemas/DTD's available in XML tools it is
> disregarded because XML doesn't have a standard graphical representation
> of the data model. Each XML tool has derived their own graphical
> representation of the data model.
>
> Betty
