Author Topic: class relation, diamond, but arrow.  (Read 2768 times)

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7752
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: class relation, diamond, but arrow.
« Reply #15 on: February 12, 2010, 04:51:33 pm »
Milan,

I still don't see why the code sample you gave should result in a composite association rather then a regular association.
One of the constraints of a composition is indeed that the parts are destroyed when the parent is destroyed.
In your example I don't see that happening (all the time).
All I see is that you the class NotBase has a reference to an instance of class Base. Now if at runtime the instance of NotBase would be the only one to hold a reference to that particular instance of Base then indeed the instance of Base would be destroyed when the instance of NotBase is destroyed.

But, that is not something we can detect from the code only. There could be other instances(of the same or of other classes) having a reference to the same instance of Base. In that case this instance of Base would not be destroyed when the instance of NotBase is destroyed.

Effectively, until you prove otherwise I don't think there is a way to distinguish regular associations from compositions based on the code.

Please prove my wrong by providing a code snippet that should result in a composition, and another code snipped that should result in a regular association.

Geert

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #16 on: February 13, 2010, 04:00:21 am »
Hi Günther ,

if you could bring some code for example it would be easier for me to understand your point. But without deeper thinking if for generic does not work(i need example from you to state this) than it can show simplier uml diagram if no generic code is there than the correct uml diagram.

br
Milan.

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #17 on: February 13, 2010, 04:16:14 am »
Hi Geert,

here is another example where from the code is clear that there is aggregation and not association but EA still gives only associations.

    class Base
    {
        private int i = 0;
    }

    class NotBase
    {
        class Tmp
        {
            private int z = 7;
        }
        public Tmp tTmp = new Tmp();
        public Base x = new Base();
    }


At least connection between NotBase and Tmp is aggregation do you agree ?

br,
Milan.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7752
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: class relation, diamond, but arrow.
« Reply #18 on: February 13, 2010, 04:22:52 am »
Milan,

I'm sorry but I don't agree.
The relation between NotBase and Tmp is on one hand that of a nested class (because tmp is defined within NotBase)
On the other hand there is a regular association because of the attribute tTmp of type Tmp.

Lets put it another way, what would be the rule to determine whether an attribute should be seen as an aggregate i.s.o. a regular association?

Geert

Geert

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #19 on: February 14, 2010, 08:36:04 am »
Hi Geert,

feel free to disagree that is why we are here.
Nested class is soemthing what should be at least in this simple example sinonim for aggregation.

So object of type Tmp can exist only if there is object of class NotBase. So this is aggregation, and even more it is composition. Do you agree ?

br,
Milan.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #20 on: February 14, 2010, 10:33:12 am »
Quote
Hi Geert,

feel free to disagree that is why we are here.
Nested class is something what should be at least in this simple example synonym for aggregation.

So object of type Tmp can exist only if there is object of class NotBase. So this is aggregation, and even more it is composition. Do you agree ?

br,
Milan.
We DO disagree...   :(

Nesting IS NOT aggregation - it is similar BUT NOT the same.

As  Geert  Geert amid I are trying to tell you  Aggregation tells  you NOTHING about how a thing is created ONLY about how it is destroyed.

When a class definition is Nested within another,  it just means you can't access the inner calls without going through the outer class.

The concept of aggregation is more complex that UML can model and certainly more complex than most languages can unambiguously indicate.  Search for meronymy...  "The relationship between the whole and the part".

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #21 on: February 14, 2010, 03:03:00 pm »
hmm in my simple example it was clear how inner class is created and destroied but still no expected UML diagram is got.
I am not talking about some general cases but about my small example.


>>When a class definition is Nested within another,  it just means you >>can't access the inner calls without going through the outer class.

it means also that inner object is created and destroid with parent class, which is enough for stating aggregation. Right ?

br,
Milan.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #22 on: February 14, 2010, 06:37:25 pm »
Quote
it means also that inner object is created and destroyed with parent class, which is enough for stating aggregation. Right ?.
No, it doesn't...

Nesting is about definition and access.

As Geert pointed out, HOW you access the inner class and particularly WHEN you destroy it establishes the nature of the relationship.

Unfortunately, the general case also applies in the the particular.

There is a REASON why UML says that aggregation (whether shared or composition) is an extension/specialization of the Association relationship.  If I create a nested definition and never instantiate the class, do I have a nested class (yes) do I have an aggregation (no)?

The point that Geert and I are still trying to make is that from the framework code only you CAN'T determine whether the Association (Attribute) is an aggregate or not (for reverse engineering).  You have to supply more information.

Anyway, I think we may have to agree to disagree.

HTH,
Paolo
« Last Edit: February 14, 2010, 06:39:34 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #23 on: February 14, 2010, 11:16:17 pm »
Hi Paolo,

OK, lets play now little more using yours rules :)
so is there any code example with all additional information needed which can in EA UML diagram after reverse engineering brings composition relation between 2 elements ?

If there is not such C++/C# example (I am not too good with other langueges) than ... maybe aggregation(whether shared or composition) does not exist at all :)

br,
Milan.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #24 on: February 15, 2010, 08:57:26 am »
It exists, but its just not trivial to determine from code alone.  It's a higher level concept than code.  If you guarantee that no reference counting can come into play then a member variable could be considered a composition.  C++ makes this easy because there is no reference counting.

For C#, if you made the members private in the last example, then you can tell that nothing else is going to take a reference to them and therefore they will be created and destroyed with the lifetime of the container.  That would then be composite.  But it's still non-trivial to determine that no other instance of that class is going to interfere with it.
Simon

support@sparxsystems.com

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #25 on: February 15, 2010, 01:16:05 pm »
Thanks Simon,

>>It exists, but its just not trivial to determine from code alone.  It's a higher level concept than code.

This seems to be little to strong said  :-? at the end of the day all we have is the code there is nothing else which can help us.
I do agree in the case of reference counting in C# it becomes more complicated but it is possible, Microsoft did it. Is it planned to integrate reference counting in EA and approximetlly when ?

In the worst case there could be implemented some switch/option in EA where can be switched off reference counting so it would works just like for C++, giving correct results in the simple cases. If more complecated cases are detected just association arrow can be drown with appropriate "unsupported" message.

br,
Milan.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #26 on: February 16, 2010, 09:16:49 am »
I'm not aware of any such plans, and to be honest I think it would be a waste of resources better spent in other areas.
Simon

support@sparxsystems.com

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7752
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: class relation, diamond, but arrow.
« Reply #27 on: February 16, 2010, 03:10:15 pm »
Simon,

I fully agree, I can't remember to have ever seen a private nested class in production code.

Geert

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #28 on: February 17, 2010, 09:42:05 am »
I'm not aware of any such plans, and to be honest I think it would be a waste of resources better spent in other areas.

Hmm UML tool company which want to invest time in selling something else :)
Could someone explain me what is the main feature of EA if not UML to code generation and otherwise ?

Br,
Milan.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6200
  • Karma: +47/-5
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #29 on: February 17, 2010, 12:38:56 pm »
Code Engineering is only a small part of modelling (just look at our release notes).  To properly determine if a link is composite or not would essentially require a fully functional compiler for each of the languages EA supports.
Simon

support@sparxsystems.com