Structured Types

[lwri...@frogooa.com]

I'm posting an email exchange between me Leon and Andrew Mangogna that
ended in the post to this group called, Composite Data Types (also
replicated here). I don't have anything further to say on the subject,
but the emails haven't been posted to date.

Lee wrote:
>> > > Hi Leon,
>> > >
>> > > I was looking at your * UML blog entries on Composite Data Types, and I
>> > > couldn't help thinking that what you were describing was construction of
>> > > a Class. Basically a grouping of core data types with operations, right?
>> > >
>> > > There was a discussion on the Yahoo! groups Executable UML list about
>> > > Composite Data Types that fell under two threads, "Attributes in xtUml"
>> > > and "Core Data Types?". I started the second with the proposal that
>> > > "Composite" should be a core data type with a limited set of valid
>> > > operations. The Mellor and Balcer book says that a Composite Data Type
>> > > should be treated as atomic. For example, Position can be a Composite
>> > > Data Type in the domain, but referencing Position.Longitude would be
>> > > illegal.
>> > >
>> > > I also found the following in support of my argument:
>> > > Further searching has this quote from Sally Shlaer off the SMUG
>> > > mailing list, "We need to add to the method explicit rules for how to
>> > > define and handle compound data types. I expect to do this in much
>> > > the same style as was done with the date data type in the paper. It
>> > > will be the responsibility of the architecture to implement whatever
>> > > operations that are needed by the client domains."
>> > >
>> > > BTW, you might also want to read the "Data Types in OOA" paper by Steve
>> > > and Sally, if you haven't recently. It helped solidify some of my
>> > > thinking in the aforementioned discussions.

Leon Starr wrote:
> > Lee -
> >
> > (feel free to chime in Andrew)
> >
> > Yeah, the debates and arguments have been going 'round and 'round for
> > quite some time.
> > I will take another look at that Data Types in OOA paper as it's been
> > awhile since the last read.
> >
> > Have you read C.J. Date's latest?
> >
> > http://www.amazon.com/Databases-Types-Relational-Model-3rd/dp/0321399420/sr
> >=8-4/qid=1159056734/ref=sr_1_4/104-5299456-2804752?ie=UTF8&s=books
> >
> > I know that much of Sally's thinking was derived from his earlier writings.
> >
> > I am fascinated by this latest book - recommended to me by Andrew. I
> > can't put the thing down! He talks in some detail about how type
> > theory, relational constructs and predicate logic fit together. I've
> > always known they were connected, as you say, a type definition is
> > really just a class model. Still don't know how to fold this into the
> > metamodel yet, but its got me rethinking everything.
> >
> > Following Date's logic as best I can, let's say that we have a data type
> > Point with x,y as real number components. So the coordinate (32, 15)
> > would constitute a single Point value. To get Point.x we would need to
> > define the x selector operation and bind it to the Point data type. If
> > we use . as an operator that calls this selector function then I suppose
> > we could, in fact, refer to Point.x, Point(x) or something like that.
> > The architecture would need to provide a mechanism for handling user
> > data types and data type operation definitions.
> >
> > Anyway - that's the current thinking.
> >

Andrew wrote:
> My current thinking on this follows that of Date. He distinguishes
> between "relational" types and "scalar" types. In this case "scalar" really
> means anything that is not "relational". Date insists that there be user
> definable data types along with the operations on those types.
>
> It really boils down to whether or not the type is encapsulated or not. If the
> type is encapsulated, then the details of its implementation are not apparent
> and the only access to it is via the operators defined for the type. This is
> still true even if one accesses some "component" part of the user defined
> type (e.g. pt.x where pt is a variable of type Point). Such types are very
> much different from relational types where there is no attempt at
> encapsulation and indeed none is desired. The fact that a given relation (or
> Class in the xtUML parlance) has specific attributes of specific types is
> fundamental to the abstraction that the relation represents as a statement of
> truth. Not the same can be said of Point, where the only concern is the
> operations available on Point types and the means by which those operations
> are implemented is of no concern to the relation that contains a Point as an
> attribute (and in the case of Point, two very different yet equivalent
> implementations exist -- cartesian and polar). This is also related to the
> notion that relational operations are polymorphic with respect to the
> specific structure of the relation, but the same cannot be said of operations
> on user defined data types (i.e. their operations apply to only that type).
> Suffice it to say that system defined types (i.e. "core" types) are just
> special cases of user defined types in that they are supplied as part of
> the "system" and it would be hard to make any progress if they were not
> there. It is also usually the case that system defined types have a
> particular implemenation advantage such that you do not want to be forced to
> define them up from "first principles".
>
> The more interesting question, I think, is when does one define a user type as
> opposed to "modelling" it in relational form. Alas, I think the answer is
> that it "depends upon your point of view" (as so much in the world does,
> Luke). If I'm modelling some 3d graphics domain, I'm probably going to want
> a "matrix" type as an encapsulated thing that I simply treat as an attribute
> and operate on. However, it is easy to envision a subject matter where
> exposing the matrix representation is an essential characteristic of the
> domain. In the real world, things conspire so that the choices are not so
> clear cut as in the case of a matrix (where there is real mathematical theory
> to guide the choices). The general guidelines I use are to define a user
> defined data type when my access to any "component" parts of the type is
> associated with algorithmic computation and place into relations those
> attributes where there is information-like reasoning going on. Not very
> precise, but it minimizes some of the coin flipping otherwise required.
>

Lee wrote:
After Leon's blog postings on composite data types, I sent him an
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.

[Leon Starr]

Sorry for the delay in responding. I've been trying to clear the desk
so that I can give this the thought it deserves. I think I want to
focus on getting the generalization population subsystem posted first,
and then come back to the data type issues. The data type model, as
it stands, is really intended to provoke this kind of discussion as it
apparently has. Good. Ultimately, I want to base what we do on 3rd
Manifesto, to the extent it makes sense in the world of articulate
analysis.

Anyway, nothing new at this point, but I will go back and reread the
relevant sections in Date and try to post on the topic soon and see
what you guys think. Meanwhile, I am certainly interested in any
other thoughts the group has the data type topic. We will eventually
get this sorted out properly.

- Leon

On Oct 29, 4:34 pm, "lwrie...@frogooa.com" <lwrie...@frogooa.com>
wrote:

> > >http://www.amazon.com/Databases-Types-Relational-Model-3rd/dp/0321399...