Re: Relation or attribute and why

"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:TqAdg.40506$mh.23663_at_tornado.ohiordc.rr.com...

> "Me too!" Although I must admit, when describing systems at the
> conceptual level, we're seldom talking about data. One glaring
> counterexample is the Snodgrass and Jensen (I think, or was it
> Christiansen? ) description of the "Bitemporal Conceptual Data
> Model." It just goes to show...

I agree with the above, but I think it's a sad state of affairs. A great many of today's systems fail because of sloppy analysis. Thinking about the data during the analysis phase somtimes forces the analysis to be "hard" rather than "soft". Analysis that is too soft is often dismissed as mere guidelines during design. The result is usually a good design that solves the wrong problem.

>
> > A conceptual model and a conceptual data model
> > may or may not be the same thing.
>
> ...that, "It all depends." And I have the uneasy feeling that
> somewhere along the line, we should shake off this cloak of
> relativism and settle upon language that gets us somewhere.
> Far too much time is spent explaining, "What I meant was..."
>

I was leaving the question open with regard to the discussion in c.d.t. awaiting responses from other people. The two terms are quite clear in my own mind.

Some of the time spent in c.d.t on the "what I meant was" issue is due to people who insist on a perverse reading of other people's comments, and on a disrespectful attitude towards other people's thinking. There is a lot of that going on in c.d.t. right now. Sharp incisive analysis of other people's comments is a good thing. Blunt insulting of other people is not.

> > As far as level of detail goes, a model that fits on a napkin is good
for a
> > casual conversation in a bar or restaurant. That could be the beginning
of
> > a formal project, but it's hardly the end of conceptual modeling. The
thing
> > that attracted me to OOA by Coad and Yourden is that they don't split
the
> > conceptual model into a data model and a process model.
>
> Translating a concept into a design into an implementation has
> been a particularly sticky problem. "Data flows" are useful
> in some contexts but "control flows" seem more useful in others.
> The difference seems to be that imperative code, while obviously
> "process" in the first instance, is more easily treated like "data"
> in the second.
>

I was impressed with the book on design by Rumbaugh, et al (sorry I don't remeber the title).

They had three views of a (proposed) system, one of which was an object model, one of which was a control model, and on of which was a functional model. Each view emphasized certain aspects, while glossing over others. I never had a chance to apply this, so I can't verify that it works under realistic situations, but it sure looked good on paper.

> I was particularly impressed with a technique used by an aircraft
> manufacturer in which the two were pulled together. They had a
> set of boxes and blobs and lines and connectors and arrows, etc.,
> that captured it all. Loaded with jargon, of course -- but it
> worked.
Received on Fri May 26 2006 - 13:38:32 CEST