Reverse Engineering - "new" Relation not

[eppinkf]

When doing Reverse Engineering of the following two simple classes:

class Program
{
   static void Main(string[] args)
   {
SecondClass sc = new SecondClass();
sc.DoIt();
   }
}

class SecondClass
{
   public void DoIt()
   {}
}

in the generated diagram, there is no relationship between the "Program"-Class and "SecondClass" although "Program" is using "SecondClass". For my software engineering purposes it would be helpful to see this connection/relation in the corresponding UML diagram.

From my mediocre understanding of UML this could be an "Association" relationship, but I assume that "Association" relationships are only created in a generated diagram when one class is an instance variable in another class.
Is this assumption true?

Is there a way to make the specified relationship visible in a reverse engineered diagram?

Thanks

[Paolo F Cantoni]

EA will not create this relationship for you.

You will need to add it manually.

We agree that it is a form of Association.

We manually create them and stereotype them «local» - with the following meaning:
Implies «instantiate» and there shall be NO member variable.  Therefore no target role.

HTH,
Paolo

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

[eppinkf]

Thanks for the quick and informative reply

[«Midnight»]

This sounds like something that a small automation project could set up or enforce, once you assigned the stereotype. Perhaps it could also present a list of likely candidates and set the stereotype for the ones selected.

This might be packaged as part of a suite of functions for setting, tidying, and validating various corporate standards for your models. It could be done as an add-in or an external automation project.

Just 'adding in' [sorry, couldn't resist that] another .02 CAD...

[sargasso]

I see no structural association in the OP´s code.  A dependency perhaps, but the instantiated structure of ¨Program¨  will not contain an instantiation of ¨SecondClass¨.  Nothing in Program other than the Main method will have visibility of ¨sc¨.

The behaviour of Program will certainly depend on the availability of an implementation of ¨SecöndClass¨ (that exhibits a public behaviour of ¨DoIt¨).  

Consider

Code: [Select]

class Program {
   static void Main(string[] args)
   {
    object a = new object();
    object b = new object();
    ...
    object zz = new object();
   }
}
Would this imply 26² associations?

bruce

[Zidane]

In version 7.1 of EA I can't find that stereotype <<local>> for associations anymore. What kind of relationship should be / do you use for 2 classes where one uses the other.

What I know from UML it should be an association and not a dependency. If yes, I have to tell EA not to create a member variable.

Thanks in advance.
Didi

[Torsten Binias]

Hi,

it must be modeled as a dependency, because you don't need that member variable. The stereotype of the dependency should be <<use>>, because your class Program does not only create an instance of SecondClass but also invokes an operation on it (see class Usage in der UML superstructure).

If Program just instantiates SecondClass I recommend the stereotypes <<instantiate>> or <<create>> whatever you like best.

Best regards,
Torsten

[Eve]

In version 7.1 of EA I can't find that stereotype <<local>> for associations anymore. What kind of relationship should be / do you use for 2 classes where one uses the other.

What I know from UML it should be an association and not a dependency. If yes, I have to tell EA not to create a member variable.

The use of an association with the «local» stereotype was not recommended by Sparx Systems and at least to my knowledge the «local» stereotype was never part of the standard installation of EA.

An association doesn't need to have a member variable, or even have either end accessible from the other end.  Having said that, I would still find it most intuitive to model as a dependency.