What is the type of the relationship in the class diagram if the object is initiated or referenced in a method?

Question

I am doing a reverse engineering to one system and creating a class diagram.

The code is similar to this example:

class B
{
}

class C
{
}    

class A
{
    C GetC()
    {
       return new C();
    }

    void Foo()
    {
       B b = new B;
       C c = GetC(); // this function returns a reference to an object of type C
    }
}

I want to know if I have this code what is the relation between the class A and B, A and C?

Answer 1

Assuming it's UML class diagram then you have a dependency. From Wikipedia (emphasis is mine):

Dependency is a weaker form of bond which indicates that one class depends on another because it uses it at some point in time. One class depends on another if the independent class is a parameter variable or local variable of a method of the dependent class. This is different from an association, where an attribute of the dependent class is an instance of the independent class.Sometimes the relationship between two classes is very weak. They are not implemented with member variables at all. Rather they might be implemented as member function arguments.

For example:

In your case class A uses class B and class C. It's a dependency and it's not composition because of highlighted text: b and c are (at least in that example) local variables then association between A and them is merely their usage (not even a weak aggregation).

OK, to be honest - I hope UML purists won't blame me too much - I would say use instead of composition because (guessing from code fictionally example) b is a tool to complete Foo() task. If it was used (even if local variable) to make (from an external point of view) A a container for B then I'd say composition. For example in this case:

class RocketLauncher {
    public void Launch(World world, Location target) {
        AutonomousObject rocket = world.Rocket.Factory.Build(_structure);
        rocket.MoveTo(world, target);
    }

    private static LauncherStructure _structure;
}

Even if strictly speaking Rocket is used by RocketLauncher I'd tend to define both (LauncherStructure and Rocket) as composition. From an outside point of view a RocketLauncher is composed by (is made of, has) a structure and a rocket (even if current implementation delegates creation to last moment). Point (IMO) is what you want to represent with this diagram. If you're describing implementation then point of view doesn't matter: dependency is dependency and composition is composition.

If you're describing higher level architecture you would keep implementation details out of the diagram and try to describe class interface (of course when implementation greatly differs from abstract architecture there may be smell of something wrong - in implementation or in architecture - and reasons - if any - must be documented).