Overview of Commonly Used UML Symbols

This article explains some of the commonly used UML symbols that we need to understand to design for working on the class level design patterns. Besides association, aggregation and composition there are other UML designs and OOP concepts that we need to be familiar with. Since I myself sometimes become confused about the symbols I thought to come up with this article to have a nice handy reference.

In the following table I have mentioned some of the commonly used symbols that explains their use with examples:



1. Inheritance

Inheritance is one of the key concepts of the OOP in which we can inherit the public properties and methods of the base class into the derived class. In the code snippet below I have mentioned an inheritance example where the Employee (A as per our UML notation above) class is being derived from by the Manager (B) class.

public class Employee {
    //Class Implementation
}

public class Manager: Employee {
    //Class Implementation
}

2. Realization

This is the concept using which a derived class implements the virtual functions of the base class, usually an interface or an abstract class. All the methods or properties that are abstract in the base class are implemented in the derived class that is usually non-abstract.

public interface IEmployee {
    void GetAccess();
    //other abstract implementation
}

public class Manager: IEmployee {
    //Class Implementation
    #region IEmployee Members

    public void GetAccess() {
        //implementation of the method
    }

    #endregion
}

3. Association

This is the kind of the design in which two classes taking part in the design are associated with each other in one or another way. Both of these classes can exist independently and their lifetime is not dependent on another object.

As an example take the case of the following code snippet that has two classes that are using each other's functionality.

public class Manager {
    public void AssignProject(SoftwareEngineer engineer) {
        engineer.Project = "Designing Project";
    }

    public void LeaveAppliedBy(SoftwareEngineer engineer) {
        //Track the leaves applied by all the employees
    }
}

public class SoftwareEngineer {
    public string Project {
        get;
        set;
    }

    public void AskForLeave(Manager manager) {
        manager.LeaveAppliedBy(this);
    }
}

And in the main class we can use the two classes as shown.

static void Main(string[] args) {
    Manager manager = new Manager();
    SoftwareEngineer se = new SoftwareEngineer();

    manager.AssignProject(se); //manager assigns a project to the software //engineer
    se.AskForLeave(manager); //SE asks for leaves from manager
}

As we can see from the preceding example, the two classes are using each other's functionality but that is not the only case. These two classes that can exist independently and work accordingly for themselves as per their functionality.

4. Association (one way)

The preceding scenario is not the only case of association. The other scenario is the one-way scenario in which only one of the classes participating in the design knows about the other, but the reverse is not true. In the code snippet shown below, the HR class can call and access the Employee's methods.

public class HR {
    private IList < Employee > listOfEmployees = new List < Employee > ();
    public void AddEmployeeToOrg(Employee emp) {
        if (emp != null) {
            emp.AddEmployeeToPayroll();
            listOfEmployees.Add(emp);
        }
    }
}

public class Employee {
    public string Name {
        get;
        set;
    }
    public void AddEmployeeToPayroll() {
        //some formalities which employee need to do to be part of the organization
    }
}

5. Aggregation

This is an OOP concept in which the container class (A) maintains a has-a relationship with the containee class (B) in the UML diagram shown above, but the containee class can also be sustained even without the container class. In this case I want to take an example of the two classes, Employee and Address.

public class Employee {
    public string Name {
        get;
        set;
    }
    public Address Address {
        get;
        set;
    }

    public Employee(string name, Address add) {
        this.Name = name;
        this.Address = add;
    }
}

public class Address {
    public string HouseNumber {
        get;
        set;
    }
    public string Street {
        get;
        set;
    }
}


static void Main(string[] args) {
    Address add = new Address() {
        HouseNumber = "204", Street = "Main Street"
    };
    Employee emp = new Employee("Vikram", add);
}

As we can see from the preceding code snippet Address and Employee are two different enititioes and Employee has an Address and the Address can exist even without an Employee. Some Students can also have a has-an address also.

6. Composition

Composition is a specialized form of aggregation and it can be sometimes called a “Death” relationship. Since the entities taking part in this relationship cannot exist independently, carrying forward the same analogy I used in my previous examples, I want to cite one more example. Here in this example my Organization (A) entity contains a CEO and the Ilist<Employee> entities and both of these enities cannot exist independently without an organization class. And once the organization class is destroyed both of these classes are also destroyed.

public class CEO {
    //CEO implementation
}

public class Organization {
    public List < Employee > Employees {
        get;
        set;
    }
    public CEO CEO {
        get;
        set;
    }

    public void AddEmployee(Employee emp) {
        if (emp != null) Employees.Add(emp);
    }

}