Brain Dump

Class Diagram

Tags
modelling

Is a UML data-view diagram outlining the classes and inheritance model of a system. It relates strongly to the ERM except wheras ERM describes the abstract representation of the data model, the class diagram represents the static structure and behaviour of the proposed system.

Class diagrams are more likely to map to real world objects.

Class Overview

A class can be seen as a set containing all possible instances of a given type. Classes are drawn either simplistically as a rectangle containing the class name or in a detailed view with a rectangle divided into 3 rows each containing the:

  1. Name of the class.
  2. Fields/[see page 13, attributes].
  3. Methods/services.

Attributes refer to the data managed by the class which is added or removed on a need-to-know basis. These generally only specify basic types like string, integer, etc. If you need to specify a [see page 17, complex type] like another class you do so through an association. In some situations it may make sense to abbreviate a relationship with a standard type that is in actuality a class (example: Date). Methods/services are the business operations owned by the class written using the standard functional syntax.

You can attach types or default values to attributes or methods and can highlight them in different ways to indicate properties. For example a static method/field is shown by underlining it.

\begin{figure}
  \centering
  \begin{tikzpicture}
    \umlsimpleclass[x=0, y=0, width=5]{CurrentAccount};
    \umlclass[x=5, y=0]{CurrentAccount}{
      number : Integer \\
      balance : Real \\
      overdraftLimit : Real
    }{
      getBalance(): Real \\
      deposit(amount: Real) \\
      withdraw(amount: Real): Boolean
    };
    \umlnote[x=5, y=-3.5]{CurrentAccount}{Refuse to allow the balance to go below the overdraft limit.};
  \end{tikzpicture}
  \caption{\label{fig:class-eg} Example of a simple and detailed class view.}
\end{figure}

Inheritance

Allows a class to inherit fields and methods from a parent class to minimise code duplication. It's indicated using an arrow with a white arrow-head pointing towards the parent class. You can see an example of this in fig:class-inheritance.

\begin{figure}
  \centering
  \begin{tikzpicture}
    \umlclass{Account}{
      number: Integer \\
      balance: Real
    }{
      getBalance(): Real \\
      deposit(cash: Real) \\
      withdraw(cash: Real): Boolean
    };
    \umlclass[x=-3, y=-4]
      {CurrentAccount}
      {overdraftLimit: Real}
      {withdraw(cash: Real): Boolean};
    \umlclass[x=3, y=-4]
      {SavingsAccount}
      {\umlstatic{interestRate: Real = 0.03}}
      {withdraw(cash: Real): Boolean};
    \umlVHVinherit{CurrentAccount}{Account};
    \umlVHVinherit{SavingsAccount}{Account};
  \end{tikzpicture}
  \caption{\label{fig:class-inheritance}
    Example of two classes inheriting fields and methods from a parent class.}
\end{figure}

Association Class

Is a special class used when we wish to attach an attribute to an association.

\begin{figure}[ht]
  \centering
  \begin{tikzpicture}
    \umlclass{Degree}{
      name: String \\
      code: String \\
      department: String}{};
    \umlclass[x=9]{Module}{
      name: String \\
      code: String \\
      credits: Integer}{};

    \umlassoc[attr1=courses|1..*, attr2=units|1..*]{Degree}{Module};
  \end{tikzpicture}
  \caption{\label{fig:assoc-class-eg-1} Drawing of the situation outlined in the prior example.}
\end{figure}

For example consider a basic degree, module, class system where we wish to specify whether a module is core or optional for each degree. You can visualise this in fig:assoc-eg-1. We cannot assign it to the module class because the value varies according to a degree and it cannot belong to the degree class because it varies according to the module. It must be an attribute of the association itself. We can see the inclusion of an association class to this model in fig:assoc-eg-2.

\begin{figure}[ht]
  \centering
  \begin{tikzpicture}
    \umlclass{Degree}{
      name: String \\
      code: String \\
      department: String}{};
    \umlclass[x=9]{Module}{
      name: String \\
      code: String \\
      credits: Integer}{};

    \umlassoc[name=assoc, attr1=courses|1..*, attr2=units|1..*]{Degree}{Module};
    \umlassocclass[geometry=|-|,x=4.5, y=-3]
      {Approval}
      {assoc-1}
      {core: Boolean}
      {};
  \end{tikzpicture}
  \caption{\label{fig:assoc-class-eg-2}
    Variant of \autoref{fig:assoc-class-eg-1} with an association class adding a
property to the association.}
\end{figure}

Attribute Details

Class [see page 13, attributes] can be given types, access specifiers, or constraints (such as {const} or {not null}).

Method attributes can be given type parameters and tags such as in, out, inout to indicate whether the parameter is expected to be modified by the procedure and returned.

Access Specifiers

Class attributes or methods can be prefixed by symbols to indicate their [see page 10, visibility].

Table 1: Listing of the various access specifier symbols and their meaning.
SymbolVisibilityMeaning
+publicGlobally visible and may be used by any object.
-privateVisible within the class and only usable by instances of the class.
#protectedVisible by this class and its sub-classes and can be accessed by instances of them.
~packageVisible within the enclosing package and used only by instances of classes in this package.