Understanding Association, Aggregation, Composition and Dependency relationship

A relationship defines the connection between objects. This explains how objects are connected to each other’s and how they will behave.

Association

It represents a relationship between two or more objects where all objects have their own lifecycle and there is no owner. The name of an association specifies the nature of relationship between objects. This is represented by a solid line.

Let’s take an example of relationship between Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers. But there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.

Aggregation

It is a specialized form of Association where all object have their own lifecycle but there is ownership. This represents “whole-part or a-part-of” relationship. This is represented by a hollow diamond followed by a line.

Let’s take an example of relationship between Department and Teacher. A Teacher may belongs to multiple departments. Hence Teacher is a part of multiple departments. But if we delete a Department, Teacher Object will not destroy.

Composition

It is a specialized form of Aggregation. It is a strong type of Aggregation. In this relationship child objects does not have their lifecycle without Parent object. If a parent object is deleted, all its child objects will also be deleted. This represents “death” relationship. This is represented by a solid diamond followed by a line.

Let’s take an example of relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room cannot belongs to two different house if we delete the house room will automatically delete.

Let’s take another example of relationship between Questions and options. Single questions can have multiple options and option cannot belong to multiple questions. If we delete questions options will be automatically deleted.

Dependency

It represents a relationship between two or more objects where an object is dependent on another object(s) for its specification or implementation. This is represented by a dashed arrow.

Let’s take an example of relationship between client and service. A client is dependent on the service for implementing its functionalities.

Let’s take another example of relationship between a client and a supplier. A client is dependent on the supplier for supplying products. If the supplier will not supply the products, client cannot use those products.

Actual References :

dotnettricks

 

 

UML diagrams for Payroll Processing System

Collected From sourcecodesolutions

AIM:

To model the “Payroll System” using the software Rational Rose with various UML (Unified Modeling Language) diagrams.

UML DIAGRAMS:

USE CASE DIAGRAM:

 

SEQUENCE DIAGRAM:

 

COLLABORATION DIAGRAM:

 

CLASS DIAGRAM:

 

ACTIVITY DIAGRAM:

 

COMPONENT DIAGRAM:

 

RESULT:

Thus the Payroll System application was successfully designed and the output was verified.

---

102

UML Class Diagram: Association, Aggregation and Composition

The UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways.

There are three primary inter-object relationships: association, aggregation, and composition. Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity.

Association

The most abstract way to describe static relationship between classes is using the ‘Association’ link, which simply states that there is some kind of a link or a dependency between two classes or more.

Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB instance, or returns instance of ClassB.

Strong Association

ClassA may also be linked to ClassB in order to show that it holds reference to ClassB instance.

Aggregation (Shared Association)

In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, taking special notice that ClassB can also be aggregated by other classes in the application (therefore aggregation is also known as shared association).

So basically, the aggregation link doesn’t state in any way that ClassA owns ClassB nor that there is a parent-child relationship (when parent deleted all its child’s are being deleted as a result) between the two. Actually, quite the opposite! The aggregation link usually used to stress the point that ClassA is not the exclusive container of ClassB, as in fact ClassB has another container.

Aggregation v.s. Association

The association link can replace the aggregation link in every situation, while aggregation cannot replace association in situations were there is only a ‘weak link’ between the classes, i.e. ClassA has method/s that contain parameter of ClassB but ClassA doesn’t hold reference to ClassB instance.

Martin Fowler suggest that the aggregation link should not be used at all because it has no added value and it disturb consistency, Quoting  Jim Rumbaugh “Think of it as a modeling placebo”.

Composition (Not-Shared Association)

In cases where in addition to the part-of relationship between ClassA and ClassB – there’s a strong life cycle dependency between the two, meaning that when ClassA is deleted then ClassB is also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link.

The composition link shows that a class (container, whole) has exclusive ownership over other class/s (parts), meaning that the container object and its parts constitute a parent-child/s relationship.

Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class,  thus changes in the composed class cannot be propagated to the rest of the system. Consequently, usage of composition limits complexity growth as the system grows.

——————————————————————————–

• Composition is an Association
• Aggregation is an Association
• Composition is a strong Association (If the life of contained object totally depends on the container object, it is called strong association)
• Aggregation is a weak Association (If the life of contained object doesn’t depends on the container object, it is called weak association)

Example:

class Contained {
    public void disp() {
        System.out.println("disp() of Contained A");
    }
}

public class Container {
    private Contained c;

    //Composition
    Container() {
        c = new Contained(); 
    }

    //Association 
    public Contained getC() {
        return c;
    }

    public void setC(Contained c) {
        this.c = c;
    }     

    public static void main(String[] args) {
        Container container = new Container();
        Contained contained = new Contained();
        container.setC(contained);
    } 
}

 

 

• Simple rules:

  1. A “owns” B = Composition : B has no meaning or purpose in the system without A
  2. A “uses” B = Aggregation : B exists independently (conceptually) from A

  Example 1:

  A Company is an aggregation of People. A Company is a composition of Accounts. When a Company ceases to do business its Accounts cease to exist but its People continue to exist.

  Example 2: (very simplified)

  A Text Editor owns a Buffer (composition). A Text Editor uses a File (aggregation). When the Text Editor is closed, the Buffer is destroyed but the File itself is not destroyed.

   

   

  

  

 

 

 

Unit of Work design pattern

Unit of Work design pattern does two important things: first it maintains in-memory updates and second it sends these in-memory updates as one transaction to the database.

So to achieve the above goals it goes through two steps:

• It maintains lists of business objects in-memory which have been changed (inserted, updated, or deleted) during a transaction.
• Once the transaction is completed, all these updates are sent as one big unit of work to be persisted physically in a database in one go.

What is “Work” and “Unit” in a software application?

A simple definition of Work means performing some task.  From a software application perspective Work is nothing but inserting, updating, and deleting data. For instance let’s say you have an application which maintains customer data into a database.

So when you add, update, or delete a customer record on the database it’s one unit. In simple words the equation is.

Collapse | Copy Code

1 customer CRUD = 1 unit of work

Where CRUD stands for create, read, update, and delete operation on a single customer record.

Logical transaction! = Physical CRUD

The equation which we discussed in the previous section changes a lot when it comes to real world scenarios. Now consider the below scenario where every customer can have multiple addresses. Then many rows will become 1 unit of work.

For example you can see in the below figure customer “Shiv” has two addresses, so for the below scenario the equation is:

Collapse | Copy Code

3 Customer CRUD = 1 Logical unit of work

So in simple words, transactions for all of the three records should succeed or all of them should fail. It should be ATOMIC. In other words it’s very much possible that many CRUD operations will be equal to 1 unit of work.

So this can be achieved by using simple transactions?

Many developers can conclude that the above requirement can be met by initiating all the CRUD operations in one transaction. Definitely under the cover it uses database transactions (i.e., TransactionScope object). But unit of work is much more than simple database transactions, it sends only changes and not all rows to the database.

Let me explain to you the same in more detail.

Let’s say your application retrieves three records from the database. But it modifies only two records as shown in the below image. So only modified records are sent to the database and not all records. This optimizes the physical database trips and thus increases performance.

In simple words the final equation of unit of work is:

Collapse | Copy Code

1 Unit of work = Modified records in a transaction

So how can we achieve this?

To achieve the same the first thing we need is an in-memory collection. In this collection, we will add all the business objects. Now as the transaction happens in the application they will be tracked in this in-memory collection.

Once the application has completed everything it will send these changed business objects to the database in “one transaction”. In other words either all of them will commit or all of them will fail.

Difference between Composition and Aggregation

Composition:

As we know, inheritance gives us an ‘is-a’ relationship. To make the understanding of composition easier, we can say that composition gives us a ‘part-of’ relationship. Composition is shown on a UML diagram as a filled diamond (see Figure 1).

If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?

public class Engine
{
. . .
}

public class Car

{

Engine e = new Engine();

…….

}

As you can see in the example code above, Car manages the lifetime of Engine.

Aggregation:

If inheritance gives us ‘is-a’ and composition gives us ‘part-of’, we could argue that aggregation gives us a ‘has-a’ relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example.

The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer ‘has-a’ Address. It wouldn’t make sense to say that an Address is ‘part-of’ the Customer, because it isn’t. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond (see Figure 2).

So how do we express the concept of aggregation in C#? Well, it’s a little different to composition. Consider the following code:
public class Address
{
. . .
}
public class Person
{
private Address address;
public Person(Address address)

{

this.address = address;

}

. . .

}

Person would then be used as follows:

Address address = new Address();
Person person = new Person(address);

or

Person person = new Person( new Address() );

As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.

More Details Here