Some theory - Object

Ravi wrote:
> This question is related to OMT. Suppose we are given two classes:
> expression and functions, to be represented by a class diagram.
> Expressions are aggregation of functions (is-a-part-of relationship)
> while functions are themselves aggregate of expressions.
> But aggregation is not a symmetric relation. So how to reprsent thin
> in a class diagram.
>

This is OT for comp.lang.c++, the posting to comp.object is correct.

Followups set to comp.object

Draw it exactly as the description says...
If is a real problem, please provide more context for the system, because
the answer is always "depends".
BTW, who still uses/teaches OMT?

--
Gabriel Claramunt
http://gabrielsw.blogspot.com

"Ravi" <ra.ravi.rav{}> wrote in message
news:1179429796.613995.185020{}h2g2000hsg.googlegroups.com...
> This question is related to OMT. Suppose we are given two classes:
> expression and functions, to be represented by a class diagram.
> Expressions are aggregation of functions (is-a-part-of relationship)
> while functions are themselves aggregate of expressions.
> But aggregation is not a symmetric relation. So how to reprsent thin
> in a class diagram.
>

On 17 May 2007 12:23:16 -0700, Ravi wrote:

> This question is related to OMT. Suppose we are given two classes:
> expression and functions, to be represented by a class diagram.
> Expressions are aggregation of functions (is-a-part-of relationship)
> while functions are themselves aggregate of expressions.
> But aggregation is not a symmetric relation. So how to reprsent thin
> in a class diagram.

It is difficult to say, because there are three different things you might
have meant:

1. function call notation
2. function call expression
3. function body

Expression is an aggregation of itself, the terms of (literals and
identifiers) and operators/delimiters. This is a lexical model all parsers
are using. It refers to 1.

The semantic ****ysis has a different view, where 2 and 3 first appear.
Here an expression refers to a node of the parsing tree. Its children are
expressions of the arguments.

In all cases the definitions are sufficiently recursive. That means, yes,
you cannot represent *all* possible programs by *one* class diagram. But
you always can represent any concrete program by expanding all expressions
and naming the corresponding nodes.

In other words the language of class-diagrams lacks necessary power to
describe what you wanted.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On May 17, 9:26 pm, "Gabriel Claramunt" <gabc...{}internet.com.uy>
wrote:

> BTW, who still uses/teaches OMT?

I do, but not in public. :-)

Of course... but you always can say that you're doing UML with different
stereotypes!
:-D

--
Gabriel Claramunt
http://gabrielsw.blogspot.com
"Daniel T." <daniel_t{}earthlink.net> wrote in message
news:1179496518.213042.299780{}h2g2000hsg.googlegroups.com...
> On May 17, 9:26 pm, "Gabriel Claramunt" <gabc...{}internet.com.uy>
> wrote:
>
>> BTW, who still uses/teaches OMT?
>
> I do, but not in public. :-)
>