UML Diagrams

Introduction:

Universal Modeling Language (UML) diagrams are used to represent the structure and processing of software systems. Their purpose is to abstract away all the details in source code, leaving only the essential structure and relationships.

Here are several different types of UML diagrams:

Packages:
Show packages¹ that make up a system and their calling relationships.
Activites:
Describe the sequencing of major processing activities.
Classes:
Show the classes in a subsystem and their relationships, e.g., inheritance, composition, aggregation, and using. The diagram may show class methods and data, but need not, if that isn't important for the discussion.
States:
State diagrams are used to show the sequencing of designated activities, emphasizing their transitions from one state to another.

There are other UML diagrams, e.g., sequence, use-case, ... but we will not use these in most of our discussions.

Example Package Diagram:

Client Package Diagram

Packages, in C#, are single source code files. Each package is named and we show calling relationships with directed arrows, pointing toward the callee package. Data can flow either way on a directed path, to the callee or to the caller, depending on the nature of the function called.

Package diagrams do not necessarily show every package in a system, although they often do; but they should show at least all of the most important packages. If a diagram gets too complex, it is common practice to factor into a set of diagrams, possibly showing links off diagram with labeled destinations, which on the receiving diagram point to a specific package.

When presenting a package diagram, the documentation should always discuss the responsibilities of each package, and, we often discuss the interactions between packages.

Example Activity Diagram:

Activity diagrams describe the sequencing of blocks of processing, called activites, and are represented by the text blocks in this diagram.

Client Activity Diagram

Each directed flow represents a transition from one activity to its successor. Activities start with outgoing flows from a start circle and end on exit circles with only incoming flows. We may also use labeled circles to avoid having too many, possibly crossing flows. Each flow is a transition from one activity to another.

The vertical bar shown in the middle of the diagram is a synchronizing bar. No flow leaves the bar until all its input flows arrive. So, for example, none of the activities flowing out of the synchronizing bar start until user input and a display activity has occurred. In this diagram, the bar represents the client form.

Flows leaving the synchronizing bar may be alternatives, so that only one is active at at time, or they may represent activities that can occur concurrently. This makes the activity diagram a good tool for visualizing how program defined threads operate.

Flows terminate on processing blocks or synchronizing bars, not on other flows. Activities that have no incoming flows are processing that results from inputs from users or other processes. In this diagram, the three activities at the bottom of this client diagram result from incoming messages from servers.

You use synchronizing bars when your program activities may have to wait for an input, as in a blocking queue or Windows form. In this diagram, all inputs to the display process are startup, messages from servers, or a user action on the form, which might be a change of view, using a tab control.

Example Class Diagram:

Class diagrams describe the logical structure of a program, describing the important classes and their relationships. There are four such relationships:

Inheritance:
Symbolically represented by a directed path with triangle incident on the base class connecting with one or more derived classes.
Composition:
A strong ownership relation between an owner class and owned value type, represented by a directed path with solid fill diamond incident on the composing class, connecting with a composed type. Since, in managed languages like C#, only value types, all primitives and structs, can be composed, we rarely show them on class diagrams². Composed types lie within the memory footprint of the composing class, and the composer does not call new to create an instance. That happens when the composing class is created.
Aggregation:
A weaker ownership relation, between an aggregator and aggregated type, is represented by a directed path with non-filled diamond, incident on the aggregating class, connecting with the aggregated class. In this case, the aggregated instance occupies a region of the managed heap outside the bounds of the aggregating class. The aggregated instance does not exist until some code in the aggregator creates it with a call to new.
Using:
Using relationships represent a non-owning relationship between the using class and the used class instance. The used resource is created by some other entity, not the using class, and is passed to the user via a function call.

Client Class Diagram

In this example, we've chosen to show only the class names, suppressing method and data information. Very often we chose this style, as those details are nicely represented by the code; and this simpler diagram conveys essentail information we usually need to understand how a system works.

The only inheritance relationship shown in this diagram is that between the IComm interface and the Receiver class that implements it. All the other solid lines represent aggregation relationships, and dotted lines capture using relationships.

As is the case for most managed languages, the value types are implementation details and not very conceptually important, so there are no composition relationships shown on this diagram³.

You will find these and other types of UML diagrams discussed here:

UML-Notation Presentation, pptx
UML - uml-diagrams.org
UML - Embarcadero.com

Remember that, in C#, a package is a single source code file, endowed with Prologue, Manual, and Maintenance comments, followed by class definitions, and finally a test stub enclosed by a compiler directive to include or not include compilation of its main function.
In native languages, like C++, one class instance can compose an instance of another class and most designs use those relationships frequently.
Note that many C# and Java developers use the term composition between instances of classes, but these relationships, as discussed above, are aggregations not compositions.

Introduction:

Packages:

Activites:

Classes:

States:

Example Package Diagram:

Example Activity Diagram:

Example Class Diagram:

Inheritance:

Composition:

Aggregation:

Using: