Bidirectional and Directed Associations

Associations allow classes to interact.  By interact, we mean calling an operation or accessing data.  In code, pointers or references implement associations in object oriented languages.    Functional languages, such as C, use pointers or references when passing data, but only require #include for accessing operations.

Technically, the previous paragraph isn’t right, is it?  Associations don’t allow classes to interact, they allow objects to interact.  UML Links instantiate associations.  That is, an association defines a generic pointer whereas a link defines a pointer to a specific object.  For simplicity sake, though, we’ll continue to discuss this subject in terms of classes and associations.

In the previous diagram, the line between Sensor and GenericDetector represents a bidirectional association.  That means that Sensor “knows” about (has a pointer to) GenericDetector and GenericDetector knows about Sensor.  Sensor refers to GenericDetector with the name itsDetector.  Similarly, GenericDetector refers to Sensor as itsSensor.  So, an object of type GenericDetector could call the Sense operation of an object of type Sensor.  In C++, the code would look like this:

     itsSensor->Sense();

Most of the time, however, only one of the two classes involved in the interaction needs a pointer to the other.  In fact, requiring bidirectional associations is generally considered bad design because it makes the software harder to reuse and to extend.  Instead, use directed associations, as shown in the attached figure.  Here, Sensor can call Reset() or ToggleValue(), but GenericDetector cannot call Sense.

Structure -- Class Diagrams

The interesting thing about structural diagrams is that they look very similar for both UML and SysML, but their interpretations are different.  Let’s start with UML Class diagrams because they are more basic and easier to understand.

Class diagrams, such as the one here, show classes and relationships among classes.  In UML, classes are entities that contain functionality (operations), data (attributes) and relations.  They are not necessarily language (code) classes.  When working in a structured language like C, I use UML to help define and allocate functions to files and variables to structures.

Associations are general relationships between classes.  They come is several flavors that we'll discuss here, but it helps to understand the basics before we get into the subtleties of the metamodel.  The easiest way to understand a relation is to understand how it gets implemented in code.  For simplicity sake, I am going to use C++ terminology and syntax.  The design principles apply to object oriented languages like Java, AND to functional languages like C.

In UML, classes have two primary types of relations:  a class can have an association to another class and a class may be generalized from another class.  Associations are how classes know about each other.  In C++, an association gets implemented as a pointer or reference.  Generalizations show an inheritance.  A class that generalizes another (the child) has all of the attributes and operations of its parent.

More on each of these relationships in the next few articles.

The figure shows these two relations.