Can UML aggregation be both ways?

Question

I am implementing an application with an MVC pattern in Python with the following class definitions:

class Controller(object):
    def __init__(self, model, view):
        self.model = model
        self.view = view

        self.view.register(self)

class Model(object):
    def __init__(self):
        pass

class View(object):
    def __init__(self):
        self.controller = None

    def register(self, controller):
        self.controller = controller

Classes are instantiated by

model = Model()
view = View()
Controller(model, view)

Controller has access to View, but View also has access to the Controller (since Controller passes itself to View). What is the appropriate way to represent such structure in UML? My guess would be

but am not sure the aggregation in both ways exists.

Answer 1

You are using a shared composition (hollow diamond). To cite p. 110 of the specs

Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

So its general use is not recommended unless you have your own definition of its semantic.

If you meant to use a composite aggregation, this is simply forbidden to be on both sides. That would mean that the life time of each connected element depends on the other's lifetime.

To cite p. 110 below:

Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an object in one part of the graph will also result in the deletion of all objects of the subgraph below that object.

Bi-directional is not acyclic.

Answer 2

(UML 2.5 section 9.5.3)

[composite] Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects

So having a bi-directional composition makes no sense, as you cannot have bi-directional responsibility for existence -- once one side destroys the other, the other cannot destroy the first.

Furthermore using aggregation in you MVC example is also incorrect, as the controller is NOT responsible for the lifecycle of the model; in fact a model can be used from many different controllers.

So just use regular associations, with unidirectional and bidirectional navigability.