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

aaaaaa

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
class relation, diamond, but arrow.
« on: February 04, 2010, 05:48:36 pm »
I have two class with his declaration in one .h header file. Then I make a new project in EA 7.5 with Class Model selected.  I launch the "code engineering" by right click on the Class Model icon, appointing the directory that contains the header.

What I expect is a diamond between the two class in class model view because I think it's relationship is Composition.

But actually I just got a arrow between the two class, why?

the contend of header is as following,
class X
{
};
class Z
{
    X x;
};


Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6193
  • Karma: +47/-5
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #1 on: February 05, 2010, 08:52:32 am »
Because EA reverse engineering does not distinguish between the kinds of association that are possible.
Simon

support@sparxsystems.com

aaaaaa

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #2 on: February 05, 2010, 12:13:12 pm »
In the User Guide, it says "An Aggregation connector is a type of association that shows that an element contains or is composed of other elements".  Isn't that class Z and X in that association?

Besides, there is no description for arrow in the Class Diagram Connectors legend.


allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #3 on: February 06, 2010, 12:45:13 pm »
There are so much stories and question about reverse engineering but spark EA administrator always have some short and "polite" explanation.
It judt does not work no metther what is written in the code ERA shows "implement" association type or sometimes something else but it is NOT CLEAR ! how it works ... actually i believe that reverse ingineering does not work at all in this moment. It is sorry that my company is paying so much for licencing... I would be glad if anyone would tell me that I am wrong and that I forgot to read some help file where everything is explained as muched as payed.
hope you will take serious this critik and make EA better.
gr
milan.

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Reverse enginering does not work !
« Reply #4 on: February 08, 2010, 10:00:31 pm »
Hi EA,

I tried by myself to reproduce behaviour reported by"aaaaaa" and in EA Version 7.5 I got the same and here is the C# code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{

    class Base
    {
        private int i = 0;
    }

    class NotBase
    {
        public Base x;
    }


    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}



Like reported, in the Class diagram of EA I got just "association" arrow but no diamonds.

Can we agree upon fact that that EA in this moment does not support any other connection type except "association" ? or I see things wrong ?

If only "association" connection type is supported than a lot of information from the code are not revealed in UML diagrams!

Br,
Milan.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #5 on: February 08, 2010, 10:38:49 pm »
Perhaps, †Milan, you could paste both what EA generated and what you expected - for the code snippet you posted above?

Sometimes, as we say, "a picture (or in this case two †;)) is worth a thousand words..."

Elsewhere, I have commented that - in general - many programming languages contain less metadata than UML. †It is often, not possible to distinguish at code level between an unaggregated and an aggregated association (without additional information).

I suspect, though, that the problem is not where you think it is; but, without the diagrams, I (and, I suspect, others) are loathe to comment.

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

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7731
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: class relation, diamond, but arrow.
« Reply #6 on: February 08, 2010, 10:54:01 pm »
Milan,

Could you now also post the code that you expect EA to reverse engineer into a regular association?
Because I really wouldn't know how to make the distinction between a composition and a regular association in C#. (in C(++) you could argue that the difference should be whether or not he variable is a pointer, but I don't think EA has that kind of refinement in its reverse engineering)

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #7 on: February 08, 2010, 11:29:58 pm »
Quote
Milan,

Could you now also post the code that you expect EA to reverse engineer into a regular association?
Because I really wouldn't know how to make the distinction between a composition and a regular association in C#. (in C(++) you could argue that the difference should be whether or not he variable is a pointer, but I don't think EA has that kind of refinement in its reverse engineering)

Geert
Geert,

I'd even argue that that's not enough...  

Composition by nesting is clear enough - as you suggest, but there are other forms of compositon...

What about shared aggregation?

Elsewhere, I've observed (with my former, and esteemed colleague Darren Sampson) that the ONLY thing you can say about a composition association is the the holonym (whole) can kill the meronym (part).

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

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7731
  • Karma: +165/-21
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: class relation, diamond, but arrow.
« Reply #8 on: February 09, 2010, 12:19:29 am »
Paolo,

My point exactly. I don't know of any rule that would allow any kind of reverse engineering process to decide whether an relation should result in an association, a shared aggregate or a composite aggregate based on the code. (except for mentioned difference between pointers and values in languages such as C)

Geert

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #9 on: February 09, 2010, 03:07:26 am »
Hi all,

nice that you all asked in the same direction...you are interesting about first picture(not possible to attach files to this forum but if you start your EA you can easily reproduce what I am talking here) and second about difference between association and composition aggregation(i observe officiel simple "Composition aggregation" meaning when mother is gone children are gone too).
Info about Aggregation in UML is much stronger as information about Association so I would expect composition(aggregation) instead of simple association, who would not ?
 
So Composition(aggregation) is Association but and in the other direction is not always true.

The example given is very simple and it does not brings UML diagram to the right configuration, what we should expect with more complicated code examples :-(

br,
Milan.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6193
  • Karma: +47/-5
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #10 on: February 09, 2010, 08:42:07 am »
Yes, EA only creates associations (no aggregations/compositions) when reverse engineering code.

I don't believe this is a major limitation.  As Paolo said, you can't necessarily distinguish between the different types.
Simon

support@sparxsystems.com

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #11 on: February 09, 2010, 09:45:15 pm »
the ONLY thing you can say about a composition association is the the holonym (whole) can kill the meronym (part).

As Paolo said at least some type of association (composition association) should be reckognized. Also interface could be easily reckognized...EA sometimes also mixed interfaces with generalization.
hmmm... pretty bad that EA offers not much more as simple association.

br,
Milan.

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #12 on: February 10, 2010, 02:15:10 am »
Quote
Also interface could be easily reckognized...
I'm just curious, how?? I'm pretty sure that even some of my developer collegues here won't be able to tell what really are the interfaces in my program code, despite I wouldn't document them. I'm sometimes using CRTP instead of (pure) virtual method definition to specify and realize interfaces. Believe me, it's hard to tell then. Keep in mind, there are other languages besides Java and C#.

Just my 0.02 EUR
GŁnther

allnamesaretaken

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #13 on: February 10, 2010, 03:01:37 am »
Hallo Herr GŁnther,

I did not thing a lot before saying that but what about checking if B is interface type or not ? this should be easy right ? specially with reflection in .net (lets think about C# bor begining)

interface B
{
}

class A:B
{
}


br,
Milan.
« Last Edit: February 10, 2010, 03:02:00 am by allnamesaretaken »

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: class relation, diamond, but arrow.
« Reply #14 on: February 10, 2010, 03:53:23 am »
Hello Mr. Milan,

Even for C#: Think about generics (not using a where clause for specification of the template parameter constraints). From the logical point of view, I may have a clearly defined interface for the classes that can be used as template parameters, but these interfaces will be hard to be extracted from code. That was my point!

WBR
GŁnther