UML association understanding problem.

Question

I've been using UML for a while and I've read few articles, books, forums about it but I still don't REALLY understand when two classes should be connected with association line (a simple line or arrow (or are these not the same?)). I'll provide three examples - can you tell me which one will cause the two classes to be in this relationship?

1.

//a field of OtherClass
    public class MainClass
    {
        private OtherClass other;
    }

2.

//method argument
    public class MainClass
    {
        public void Action(OtherClass other)
        { }
    }

3.

//method return value
    public class MainClass
    {
        public OtherClass Action()
        { }
    }

4.

//used inside a method
    public class MainClass
    {
        private Something something;

        public void Action()
        {
            OtherClass other = something.GetOtherClass();
        }
    }

Answer 1

I typically use two different connectors in UML:

1. When a class is dependent on the implementation of another. This would imply that a class is creating or handling an instance of another. So the calling class is dependent on the implementation class. This would be evident in all of your examples.

2. When a class extends or implements another.

Answer 2

Edit: Rewrote answer following discussion in comments (thanks to Chimp for pointing out what I overlooked in Example 4)

Example 1: OtherClass is an attribute of MainClass, and thus is modelled as an association.

Examples 2 and 3: OtherClass is referenced within the class definition, although not stored within an attribute, hence is a dependency.

Example 4: The Something class is an attribute, and therefore an association, while the referenced OtherClass, which is not stored in an attribute, and so it is dependency.

Within UML, dependencies and associations are both types of Relationship and are not strictly related (except through a common supertype), although in my opinion an association implies a dependency.

Associations are indicated by a line between the 2 classes with multiplicities at each end. Navigability is indicated by arrows showing which class is aware of which (E.g. Class A ___> Class B means A is aware of B, but not the other way around) navigability in both directions is shown by arrows at both ends. Where there is no arrows it usually safer to make no assumptions about navigability unless stated elsewhere.

Dependencies are indicated by a dashed line with an arrow from the dependant class (client) to the class being depended on (supplier) (E.g. A ----> B means A is dependant on B). Dependencies show that a class is referenced at some point, and as such the client is dependent on operations provided by the supplier, but it doesn't indicate how it is referenced (unlike an association that suggests a reference stored in an attribute).

Answer 3

First of all an arrow represents navigability of the association. Single arrow means unidirectional relation, in this case only the source class knows about the target class. Arrow on both ends means bidirectional relation, where both classes know about each other. If no arrows are present the association can be either bidirectional by default or suppressed for the sake of readability. In practice you should draw arrows only when you want to emphasize the direction of the association.

When it comes to your second question, only the first case describes an (unidirectional) association between MainClass and OtherClass. Neither arguments nor return values imply association in the UML sense (although both imply dependency). In the last example there is an association between MainClass and Something class through the something attribute. As a rule of thumb you should look for associations in attributes.

Please note that there is a concept of dependency in UML and it is represented by a dashed line.

Pozdrowienia!

Answer 4

An association represents two or more related properties.

In example 1, MainClass has a property of type OtherClass. If OtherClass has an explicit property of type MainClass then there will be a bidirectional association between the class; if OtherClass has an implicit property of type MainClass (i.e. there is no attribute, but the relationship can be derived by working in the other direction) then there will be a unidirectional association from MainClass to OtherClass.

In examples 2, 3 and 4, MainClass does not have any properties of type OtherClass. It is dependent on the OtherClass though, so there would be a dependency relationship from MainClass to OtherClass. In code this is represented by a using or #include.