Board index » delphi » OOdesign and modelmaker

OOdesign and modelmaker


2004-08-27 11:48:54 PM
delphi87
Hi,
I am having doubts with my UML.
When I use modelmaker if I have something like
TCustomer = class
property address:TAddress (...);
end;
The relationship Customer-Address is shown as an agregation. But when
I drawed that relationship on paper I used a simple asociation.
I thought that aggregations meant something else when you have a whole
and its corresponfing cards ( a deck of cards and a card for eg). For me the
difference between an aggregation and associaton is just conceptual but not
of implementation.
In Borland Toghether I work it in that way.
But now I am full of doubts.
Some other people even told me that asociatons implies a collection class
that it is not shown in the model.
Who can shed some light in the subject?
Esteban Calabria
 
 

Re:OOdesign and modelmaker

Quote
Some other people even told me that asociatons implies a collection
class
that it is not shown in the model.
That's wrong. You could have a 1..1 association.
Quote
Who can shed some light in the subject?
Aggregate means that a "Parent" object references a "Child" object, but the
"Child" object may also be referenced by other intstances.
Composite usually means the same as above, but the child is an integral part
of the parent and shouldn't really be shared with other instances (like a
purchase order line).
Although that is what I have read, that is not how I personally use them :-)
--
Pete
====
Audio compression components, DIB graphics controls, FastStrings
www.droopyeyes.com
Read or write articles on just about anything
www.HowToDoThings.com
 

Re:OOdesign and modelmaker

Peter Morris writes:
Quote
>Some other people even told me that asociatons implies a
>collection class that it is not shown in the model.

That's wrong. You could have a 1..1 association.


>Who can shed some light in the subject?

Aggregate means that a "Parent" object references a "Child" object,
but the "Child" object may also be referenced by other intstances.

Composite usually means the same as above, but the child is an
integral part of the parent and shouldn't really be shared with other
instances (like a purchase order line).

Although that is what I have read, that is not how I personally use
them :-)
We've read slightly different things. :)
According to what I have read, aggregation is an enumerated type with
three values (hanging on an associationEnd).
1) None.
This means there's no aggregation, it is a "plain" association.
2) Shared.
There seems to be no consensus as to what this means, so in practice it
means nothing.
(except that you cannot have aggregation<>none on more than one end of
the association)
(People have been playing with letting 'Shared' be some kind of
reference-counted ownership)
3) Composite.
This is a strong "part/composed-of" relation. If the owner dies, the
part dies with it. And a "part" cannot be owned by more than one owner
at a time (at runtime, but statically I believe the type of the part can
be in a composite relation to multiple potential owner types)
Cheers,
Jarle
 

Re:OOdesign and modelmaker

Quote
1) None.
This means there's no aggregation, it is a "plain" association.
I agree.
Quote

2) Shared.
There seems to be no consensus as to what this means, so in practice it
means nothing.
(except that you cannot have aggregation<>none on more than one end of
the association)
I personally use this to specify that you cannot delete the parent if it has
children.
Quote
3) Composite.
This is a strong "part/composed-of" relation. If the owner dies, the
part dies with it. And a "part" cannot be owned by more than one owner
at a time (at runtime, but statically I believe the type of the part can
be in a composite relation to multiple potential owner types)
Although I disagree with it, I have read that the composite children should
never be referenced directly, but only their owning class (as if they were
internal to the parent). However, I think this is {*word*99} :-)
--
Pete
====
Audio compression components, DIB graphics controls, FastStrings
www.droopyeyes.com
Read or write articles on just about anything
www.HowToDoThings.com
 

Re:OOdesign and modelmaker

Peter Morris writes:
Quote
>3) Composite.
>This is a strong "part/composed-of" relation. If the owner dies, the
>part dies with it. And a "part" cannot be owned by more than one
>owner at a time (at runtime, but statically I believe the type of
>the part can be in a composite relation to multiple potential owner
>types)

Although I disagree with it, I have read that the composite children
should never be referenced directly, but only their owning class (as
if they were internal to the parent). However, I think this is {*word*99}
:-)
Well, like the saying goes:
"If you believe everything you read, better not read."
One problem with UML is that a lot of writings about it seems to be
rather formal, but usually is full of inconsistencies.
For a "fun" (or something) article related to this:
www.dbdebunk.com/page/page/622916.htm
Cheers,
Jarle
 

Re:OOdesign and modelmaker

Jarle stabell writes:
Quote
One problem with UML is that a lot of writings about it seems to be
rather formal, but usually is full of inconsistencies.
For a "fun" (or something) article related to this:
www.dbdebunk.com/page/page/622916.htm
Very entertaining, indeed. So, it isn't only me feeling that quite a lot of
the so called "high-level" theory on OO is of very little use when trying to
figure out a fruitful strategy on OO applications.
;-)
--
Regards,
Bjørge Sæther
XXXX@XXXXX.COM
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
 

Re:OOdesign and modelmaker

Bjørge Sæther writes:
Quote
Jarle stabell writes:
>One problem with UML is that a lot of writings about it seems to be
>rather formal, but usually is full of inconsistencies.
>For a "fun" (or something) article related to this:
>www.dbdebunk.com/page/page/622916.htm

Very entertaining, indeed. So, it isn't only me feeling that quite a
lot of the so called "high-level" theory on OO is of very little use
when trying to figure out a fruitful strategy on OO applications.
;-)
Take Chris Date with a *huge* grain of salt. He does have legitimate issues
regarding the lack of consistency with which many discuss
objects/classes/types, etc, however he seems of have become absolutely
obsessed with this and tries to use it to indict the entirety of
OOA/OOD/OOP. He is extremely pedantic; make so much as a typo in an article
and he'll use that as evidence that OO is itself fatally flawed.
And in many cases he sets up strawmen just so he can knock them down, the
following is a typical example:
"Note:As an aside, let me reiterate that one of the other things an object
is said to be is "a concrete manifestation of an abstraction." Strange!--I
would have thought it was exactly the other way around. That is, I would
have thought an object, whatever else it might be, was surely an abstraction
of something concrete (or something more concrete, at any rate). For
example, the customer named Edward is surely something fairly concrete,
while the object that corresponds to that customer in some information
system is an abstraction of that concrete thing. Oh well, perhaps it is all
in the mind..."
This is a deliberately invalid mixing two different contexts - both are
absolutely correct in their separate contexts. A *class* is indeed "an
abstraction of something concrete ", such as a person. An object with the
value of 'Edward' is indeed a concrete instance of that class. that is where
that context ends. The other context is that the object with a value of
'Edward' is also an *abstraction* of what in the physical world would be a
*particular* real person (as the class would be an abstraction of a
*non-particular* real person). There is no inconsistency here and nothing
circular or invalid in anyway. Such strawmen indict Chris Date, not OO, his
hostility to OO has become well-known and quite tiresome.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
SpaceShipOne; GovernmentZero
 

Re:OOdesign and modelmaker

Quote
an object
is said to be is "a concrete manifestation of an abstraction."
If that is the correct description, then I assume that "an abstraction" is
referring to a class. I'd say that it is incorrect because classes can
be either concrete or abstract, so to call a class "an abstract" is just
wrong.
I'd say that "an object is an instanciation of a class".
Quote
Such strawmen indict Chris Date, not OO, his
hostility to OO has become well-known and quite tiresome.
Well, if people want to write code like
10 SIN
20 GOTO HELL
Then leave them to it. Some people like attaching electrodes to their
{*word*196}s, although I don't do it myself who am I to tell them that they are
wrong? :-)
--
Pete
====
Audio compression components, DIB graphics controls, FastStrings
www.droopyeyes.com
Read or write articles on just about anything
www.HowToDoThings.com
 

Re:OOdesign and modelmaker

Wayne Niddery [TeamB] writes:
Quote
Bjørge Sæther writes:
>Jarle stabell writes:
>>One problem with UML is that a lot of writings about it seems to be
>>rather formal, but usually is full of inconsistencies.
>>For a "fun" (or something) article related to this:
>>www.dbdebunk.com/page/page/622916.htm
>
>Very entertaining, indeed. So, it isn't only me feeling that quite a
>lot of the so called "high-level" theory on OO is of very little use
>when trying to figure out a fruitful strategy on OO applications.
>;-)

Take Chris Date with a *huge* grain of salt. He does have legitimate
issues regarding the lack of consistency with which many discuss
objects/classes/types, etc, however he seems of have become absolutely
obsessed with this and tries to use it to indict the entirety of
OOA/OOD/OOP. He is extremely pedantic; make so much as a typo in an
article and he'll use that as evidence that OO is itself fatally
flawed.
I don't know this guy and I am certainly not going to be one of his diciples
;-)
His articles kind of illustrated something I have been experiencing, though -
that some OO theory leave people like me wondering if it is really necessary
to explain seemingly simple things in models being relatively
incomprehensible...as if there were huge amounts of aspects of OO that I
have never thought of. I just can not get it, as I have been reading quite a
lot, studied quite a lot of examples and written a few OPFs.
The downside with OOP is IMHO that it easily results in complex models. The
principial models are usually clean, but the final, working, real world ones
are usually a bit more complex. I remember getting hot on patterns a few
years ago, but for the reasons mentioned I have not been following this path.
Introducing a new term is ok if it solves a task, but if it doesn't, it may
work as a smoke carpet. If we would all know what a 'Visitor' is and agree
upon it is role, it may possibly be very fruitful. When it comes to real
world applications, we would give our 'visitors' different roles. This is
perhaps what I got from reading the articles - a somewhat better
understanding of why I have never been fascinated by high-level OO theory
and modelling. Well, I know what I have been thinking; it is about failing to
address the most precious needs of software design.
--
Regards,
Bjørge Sæther
XXXX@XXXXX.COM
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
 

Re:OOdesign and modelmaker

Peter Morris writes:
Quote
>an object
>is said to be is "a concrete manifestation of an abstraction."

If that is the correct description, then I assume that "an
abstraction" is referring to a class. I'd say that it is
incorrect because classes can be either concrete or abstract, so to
call a class "an abstract" is just wrong.
Are you thinking of "abstract class" - one not intended to be instantiated,
versus ones that are? that is not what is meant by "abstraction" here. All
classes are abstractions representing the essential attributes of some
entity, that is the context of which Date is quoting and commenting. So a
manifestation (instance) of an abstraction (class) is an object with actual
values for the abstracted attributes. The description he is quoting is
correct, but he then applies a different context to it and claims it is
contradictory.
Quote
I'd say that "an object is an instanciation of a class".
Correct.
Quote
Then leave them to it. Some people like attaching electrodes to their
{*word*196}s, although I don't do it myself who am I to tell them that
they are wrong? :-)
As long as you only do it to yourself, I won't tell you you're wrong either,
but when you deliberately spread FUD with the intention of convincing people
they are doing the right thing by electrocuting themselves then I *will*
tell you (and them) that you are wrong.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"Some see private enterprise as a predatory target to be shot, others
as a cow to be milked, but few are those who see it as a sturdy horse
pulling the wagon." - Winston Churchill
 

Re:OOdesign and modelmaker

Bjørge Sæther writes:
Quote

I don't know this guy and I am certainly not going to be one of his
diciples ;-)
He is very knowledgeable and properly respected in relational database
theory. But he seems to explicitly not *want* to get OO and uses some
legitimate terminology issues as a justification for it.
Quote
His articles kind of illustrated something I have been experiencing,
though - that some OO theory leave people like me wondering if it is
really necessary to explain seemingly simple things in models being
relatively incomprehensible...as if there were huge amounts of
aspects of OO that I have never thought of. I just can not get it, as
I've been reading quite a lot, studied quite a lot of examples and
written a few OPFs.
I'm not sure I get what you mean here. There are indeed some people that are
able to take simple ideas and twist them into pretzels, if that is what you
mean, but that does not invalidate the original concept.
Quote
The downside with OOP is IMHO that it easily results in complex
models. The principial models are usually clean, but the final,
working, real world ones are usually a bit more complex.
Hmmm. With any given tool and practitioner you are going to see the whole
range of good and bad work. But given something at least reasonably well
designed then I would say no matter how complex it is in OOP, it would be that
much worse without OOP. I'd agree that the *worst* examples of OO can
indeed be even worse than bad procedural "spaghetti" code though.
Quote
I remember
getting hot on patterns a few years ago, but for the reasons
mentioned I have not been following this path. Introducing a new term
is ok if it solves a task, but if it doesn't, it may work as a smoke
carpet. If we would all know what a 'Visitor' is and agree upon it's
role, it may possibly be very fruitful. When it comes to real world
applications, we would give our 'visitors' different roles. This is
perhaps what I got from reading the articles - a somewhat better
understanding of why I have never been fascinated by high-level OO
theory and modelling. Well, I know what I have been thinking; it's
about failing to address the most precious needs of software design.
Attempts at identifiying and abstracting patterns is generally a good thing,
but like many things I think many have tried to put too much emphasis on it.
In my experience most people do agree on what the various patterns
represent, but may disagree on the best implementation. Even something has
simple as an Observer pattern can have a far bit of variation in
implementation. Identifying the patterns, for me, is more of an aid to
thinking out designs than implementing them, however tools, more and more,
are able to help with the latter as well.
The same is true of UML, its main value to me is to help me work out my
classes and class relationships, not necessarily implement them. On occasion
UML is good for helping a client picture something I am trying to describe or
work out with them, but not often in my experience - most just assume you're
trying to impress them with silly pictures instead of writing up something
they can understand (and unfortunately some of that is from experience from
other "consultants"). I find UML uses cases essentially useless, but I
definitely *write* uses cases.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The only reason some people get lost in thought is because it's
unfamiliar territory." - Paul Fix
 

Re:OOdesign and modelmaker

Wayne Niddery [TeamB] writes:
Quote
Bjørge Sæther writes:
>
>I don't know this guy and I am certainly not going to be one of his
>diciples ;-)

He is very knowledgeable and properly respected in relational database
theory. But he seems to explicitly not *want* to get OO and uses some
legitimate terminology issues as a justification for it.
By the "Foundation for Object/Relational Databases" book, he (and
Darwen) seem to know OO very well from a theoretical standpoint.
Perhaps he is unhappy of being "ignored" by the (UML) OO community,
considering that they have done a lot of work which may be useful to the
OO community? (Pure speculation on my part, it seems they have done some
great work)
Quote
>His articles kind of illustrated something I have been experiencing,
>though - that some OO theory leave people like me wondering if it is
>really necessary to explain seemingly simple things in models being
>relatively incomprehensible...as if there were huge amounts of
>aspects of OO that I have never thought of. I just can not get it, as
>I've been reading quite a lot, studied quite a lot of examples and
>written a few OPFs.

I'm not sure I get what you mean here. There are indeed some people
that are able to take simple ideas and twist them into pretzels.
Somehow, patent applications comes into mind. :)
Quote
>The downside with OOP is IMHO that it easily results in complex
>models. The principial models are usually clean, but the final,
>working, real world ones are usually a bit more complex.

Hmmm. With any given tool and practitioner you are going to see the
whole range of good and bad work. But given something at least
reasonably well designed then I would say no matter how complex it is in
OOP, it would be that much worse without OOP. I'd agree that the
*worst* examples of OO can indeed be even worse than bad procedural
"spaghetti" code though.
With OOP you can utilize inheritance and polymorphism to truly embrace
and extend the nature of spaghetti code. :-)
Quote

>I remember
>getting hot on patterns a few years ago, but for the reasons
>mentioned I have not been following this path. Introducing a new term
>is ok if it solves a task, but if it doesn't, it may work as a smoke
>carpet. If we would all know what a 'Visitor' is and agree upon it's
>role, it may possibly be very fruitful. When it comes to real world
>applications, we would give our 'visitors' different roles. This is
>perhaps what I got from reading the articles - a somewhat better
>understanding of why I have never been fascinated by high-level OO
>theory and modelling. Well, I know what I have been thinking; it's
>about failing to address the most precious needs of software design.

Attempts at identifiying and abstracting patterns is generally a good
thing, but like many things I think many have tried to put too much
emphasis on it.
One problem seems to be that some people tend to use "too many"
patterns, putting in a lot of flexibility (and getting unecessary
complexity) into their implementations, without really needing this
flexibility.
Quote
The same is true of UML, its main value to me is to help me work out
my classes and class relationships, not necessarily implement them.
On occasion UML is good for helping a client picture something I'm
trying to describe or work out with them, but not often in my
experience - most just assume you're trying to impress them with
silly pictures instead of writing up something they can understand
Am I the only one who finds that UML class diagrams have the cardinality
constraints and the role names on the least useful ("wrong") end of the
associations, making the diagrams slower to read/comprehend than most
other similar notations ever invented for the same purpose?
Cheers,
Jarle
 

Re:OOdesign and modelmaker

Jarle stabell writes:
Quote

By the "Foundation for Object/Relational Databases" book, he (and
Darwen) seem to know OO very well from a theoretical standpoint.
If he actually does understand it properly then he is going out of his way
to pretend otherwise, else he would not present such strawman arguments
(this is a repeated pattern with him in everything I have read by him on this
topic).
Quote
One problem seems to be that some people tend to use "too many"
patterns, putting in a lot of flexibility (and getting unecessary
complexity) into their implementations, without really needing this
flexibility.
That's not really an issue of patterns, that is a more general problem of
over-engineering and, what seems to be common in this regard is, the idea of
designing for reuse. This got turned into a mantra for many and every class
had to be designed to be used beyond the current project. The majority of
classes *do not ever* get reused past the current project, and ones that are
legitimate candidates for cross-project re-use should still be *primarily*
designed for the current project and refactored later once use of that class
has become more clear through concrete use.
Quote
Am I the only one who finds that UML class diagrams have the
cardinality constraints and the role names on the least useful
("wrong") end of the associations, making the diagrams slower to
read/comprehend than most other similar notations ever invented for
the same purpose?
Seems right to me, the cardinality should be beside the class it applies to,
from the POV of the other class, same as E-R diagrams.
[A] 1 --------- 0..* [B]
A can see 0..* B's, B can only see 1 A.
Where I sometimes get confused is aggregation - it seems to me the diamond
should be beside the aggregated class, not the aggregator. I also tend to
think top-down for ancestor to descendant, so it bugged me at first that the
inheritance symbol points to the ancestor instead of to the descendant.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The legitimate powers of government extend to such acts only as are
injurious to others. But it does me no injury for my neighbor to say
there are twenty gods, or no God. It neither picks my pocket nor breaks
my leg." - Thomas Jefferson
 

Re:OOdesign and modelmaker

Wayne Niddery [TeamB] writes:
Quote
Jarle stabell writes:
>
>By the "Foundation for Object/Relational Databases" book, he (and
>Darwen) seem to know OO very well from a theoretical standpoint.

If he actually does understand it properly then he is going out of
his way to pretend otherwise, else he would not present such strawman
arguments (this is a repeated pattern with him in everything I've
read by him on this topic).
I agree he seems more than "slightly" pedantic when it comes to OO!
(When I read the OCL book I didn't even notice many of the
inconsistencies Date found in it)
Quote
>One problem seems to be that some people tend to use "too many"
>patterns, putting in a lot of flexibility (and getting unecessary
>complexity) into their implementations, without really needing this
>flexibility.

That's not really an issue of patterns, that is a more general problem
of over-engineering and, what seems to be common in this regard is,
the idea of designing for reuse. This got turned into a mantra for
many and every class had to be designed to be used beyond the current
project. The majority of classes *do not ever* get reused past the
current project, and ones that are legitimate candidates for
cross-project re-use should still be *primarily* designed for the
current project and refactored later once use of that class has
become more clear through concrete use.
Agree completely. But it seems patterns gave people many ideas of how to
make something more reusable/general, which they previously wouldn't
even have considered.
(I do held the GOF book as essential reading though)
I sometimes find it hard to know what abstraction level to use,
sometimes making it more abstract doesn't buy you anything, and burns
more development time and makes the code/design harder to understand for
others, but at other times making something more abstract may (often
unexpectedly) open the door for much cleaner solutions (both algorithms
and designs).
(But abstraction level and reuse are not the same)
Quote
>Am I the only one who finds that UML class diagrams have the
>cardinality constraints and the role names on the least useful
>("wrong") end of the associations, making the diagrams slower to
>read/comprehend than most other similar notations ever invented for
>the same purpose?

Seems right to me, the cardinality should be beside the class it
applies to, from the POV of the other class, same as E-R diagrams.

[A] 1 --------- 0..* [B]

A can see 0..* B's, B can only see 1 A.
But to see that A can see 0..* B's, you have to look at both [A] and
[B], which IMO is suboptimal.
If you include the role names, and only focusing on A (and adding
another type [C]), you might see something like:
----- 0..1 a [A] a 1 -------------
which doesn't tell you much about A's place in the scheme of things.
But if cardinality and role names had been swithed to the other ends,
you would see:
----- 1 c [A] b 0..* -------------
immediately telling you that A has one c, and 0..* b's. Today you have
to "hunt" through the diagram to find this information.
Quote
Where I sometimes get confused is aggregation - it seems to me the
diamond should be beside the aggregated class, not the aggregator.
It seems you're not alone there, here's a footnote from "Model Driven
Architecture", by David S. Frankel:
"There is a possibility that, in UML 2.0, the aggregation property will
be specified on the other end of the association, that is, on the part
rather than the whole"
Cheers,
Jarle
 

Re:OOdesign and modelmaker

Jarle stabell writes:
Quote

But if cardinality and role names had been swithed to the other ends,
you would see:

----- 1 c [A] b 0..* -------------

immediately telling you that A has one c, and 0..* b's. Today you have
to "hunt" through the diagram to find this information.
Actually I do see your point. While I have no problem with the current
standard, I do like the idea of, as I leave [A], knowing the cardinality of
the thing at the other end before getting there. The problem is the current
standard is *strongly* entrenched since it was just inherited from E-R, so
reversing this would be terribly confusing at this point. Whereas ...
Quote
"There is a possibility that, in UML 2.0, the aggregation property
will be specified on the other end of the association, that is, on
the part rather than the whole"
... UML is still young enough to consider such changes, and I am *very* glad
to find I am not alone on this one.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The only reason some people get lost in thought is because it's
unfamiliar territory." - Paul Fix