Sparx Systems Forum

Discussion => Uml Process => Topic started by: aaaaaa on February 04, 2010, 05:48:36 pm

Title: class relation, diamond, but arrow.
Post by: aaaaaa 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;
};

Title: Re: class relation, diamond, but arrow.
Post by: Simon M on February 05, 2010, 08:52:32 am
Because EA reverse engineering does not distinguish between the kinds of association that are possible.
Title: Re: class relation, diamond, but arrow.
Post by: aaaaaa 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.

Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Reverse enginering does not work !
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Paolo F Cantoni 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
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens 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
Title: Re: class relation, diamond, but arrow.
Post by: Paolo F Cantoni 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
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Simon M 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.
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Makulik 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Makulik 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
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Paolo F Cantoni 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Paolo F Cantoni 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Simon M 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.
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Simon M 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.
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens 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
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken 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.
Title: Re: class relation, diamond, but arrow.
Post by: Simon M 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.
Title: Re: class relation, diamond, but arrow.
Post by: Makulik on February 18, 2010, 12:41:17 am
Quote
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.
I think that would lead a bit far to give an example here (just take a look at Wikipedia C++ CRTP (http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern)).
Let's put it simple: Yes, for languages (like C# or Java) that support the 'interface' keyword it would be easy to extract these on reverse engineering. For other languages (e.g. C++) and concepts that don't implement an interface by means of abstract classes or s.th. alike, this might become hard, if not impossible.

WBR
Günther
Title: Re: class relation, diamond, but arrow.
Post by: allnamesaretaken on February 18, 2010, 10:54:39 pm
Hallo Simon,

yes I agree that compiler supprot should be part of EA. I am bit supprized that it is not prioretized.

Considering Modeling (the main purpose of EA) is it possible that connecting UML icons without code support make lot of practical sence ?
I would be thankfull if you could send me any example of purpose/application of EA in some middle size(or bigger) project?
it seems I have problem of expecting that UML have to produce something and not just to be used as painting tool.

br,
Milan.
Title: Re: class relation, diamond, but arrow.
Post by: Geert Bellekens on February 18, 2010, 10:59:34 pm
Milan,

There's a whole world of modelling out there that doesn't use code generations (or reverse engineering).
I think that a large percentage of big software projects use UML for the analysis, but no code generation.

Geert