UML – General

See below for a self-explanatory and quick crash course in GoF UML.  The UML diagrams used in this tutorial use notation which is similar to GoF notation with one major exception. In GoF UML, an aggregator class which holds a reference to several of the aggregatee class at once (usually through a datastructure such as a hashtable etc) would normally indicate the multiplicity with a filled-black-circle at the end of the association.  I have never been able to locate that black dot in Visio, so you will not see it in my diagrams.  However, in my diagrams, multiplicity is—usually—indicated by an asterisk “*” near the end of the association.

In the crash course below the notation being demonstrated is centered around the association between two classes.  So pay attention to the two classes that are connected, since the name of the class explains how it participates in the association with the class it is connected to.

Samples of UML associations

 

Most folks will already be familiar with the notation for Interface Implementation and Abstract Class inheritance and super-class inheritance.

A solid line pointing to a class usually indicates the Class holds a reference to the “Pointed-to” class. The GoF refer to this as an acquaintanceship relationship.

A solid line with an unfilled diamond at its base and terminating on the associated class with an arrow head indicates that the Aggregator class holds a reference to one or more instances of the aggregated class.  In the case of multiple aggregatees (usually contained in some sort of data structure such as a hashtable or arraylist), the GOF would normally indicate this with an arrow terminating on a filled dot.  However, I am unaware of black dots in Visio, so I have indicated multiplicity with an asterisk near the aggregatee class.

A Dashed line indicates that the class on the left (usually referred to as a factory class) is responsible for instantiating the class on the right, the product class.

 

Additionally, I must highlight the fact that in the GoF UML diagrams, the point on the Class diagram where the arrow originates is very important.  Do not just look at it as coming from the class, but from the actual member in the class.  So when you read the GoF book, remembering this will help you to get the most information from the diagram.

UML – Sample Code

This shows the structure diagram for the specific scenario that will be illustrated in the code sample.

Participants – Sample Code

Concept is similar to the GoF treatment of participants, but in this instance the equivalent of the GoF-Collaborations is incorporated into Participants section.

Sample Code (Highlights)

Code highlights are the critical structure and other aspects of the code that show the operation or structure of the pattern “in-lined” with the pattern discussion.  Code snippets are usually in Courier New Font.

Also included with each pattern is a downloadable zip file that contains a VB.NET solution.  In one or two cases there will be an included MS-Access database that is used with the solution.

Most of the sample applications are console applications and a few of them actually allow you to interact with them.  In most of the cases the classes are separated into namespaces and assemblies and you need to pay attention to how they are separated.  The assembly usually helps with accessibility issues, where only the classes in that namespace can directly refer to each other and they are hidden from other classes or clients.  In many cases the namespace also represents the Containable-Object-Group, the set of classes which would be reused together.

The namespaces I find useful when working with intellisense because it helps narrow down the classes you might want to work with.  In the picture below I am selecting from a set of classes that represent rhythms you can select when creating a song.  I am only interested in the rhythm classes, but without namespaces.  When I type the key-word New, intellisense brings up a little less than a million classes to select from.  But having factored the Rhyhm-classes into the Rhythm namespace, when I type “New Rhythms” it brings up a nice tight list as shown below.

Using Namespaces

Opportunities for and Costs of - Adaptation and Extension

These are ways in which the pattern allows for extension, usually by the addition of new classes or modification of existing classes so as to introduce new behaviors or new states.  It will normally include a short discussion on the actions which need to be taken to register the new classes in the existing structure so that they can be recognized by the system or developer and become usable.  You could liken this to the concept of a device driver that makes a peripheral accessible to a PC.