Composite Data Types
lwri...@frogooa.com
email. My view is that the attributes and operations specific to a
composite data type should not be exposed in the modeled domain. Leon
included Andrew Mangogna in our email discussion, and they both pointed
me toward, "Databases, Types, and the Relational Model: The Third
Manifesto" by C.J. Date and Hugh Darwen. Not having read that book, I
decided to defer further discussion until I had, and since this
discussion group got started, I decided it was a better venue than
email.
My previous view was based on the following statement in the Mellor and
Balcer Exectable UML book, "A type may be composite, but the
corresponding attribute must always be treated by the domain as a
single unit.", a similar statement made by Sally Shlaer in the SMUG
mailing list, and my own experience (which pales in comparison to
Leon's and Andrew's).
After reading the latest "Third Manifesto", my view is somewhat
strengthened by the following points:
1) The discussion seems to boil down to scalar vs. nonscalar type per
the Third Manifesto (loose) definition: "a type is scalar if it has no
user-visible components" In my opinion, an Executable UML model should
expose nonscalar composite data as a class.
2) On page 69 is a discussion of possreps (possible representations of
data) that suggests that the representations would vary based on the
(Executable UML) domain. This makes me think that possrep is something
that belongs in the Architecture domain (model compiler).
3) The "criterion for making something a type and not a relvar" in
Appendix B. (Basically a scalar vs. nonscalar discussion.) Especially
the statement that includes, "the lack of user-visible attribute names
that causes the difficulties."
4) Date and Darwen are discussing user defined data usage in terms of a
database, where the access to the data comes from what would be in
Executable UML terms many domains. This is more coherent with the model
compiler point of view, than the domain model.