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
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
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.
Opportunities for and Costs of - Adaptation and
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.