> MBLM's approach to development > UML Basics
Understanding UML - The readers digest version
I've been developing software since 1992 and have worked with Object Oriented Analysis & Design methodologies since 1994.
I've put together this summary as a basic easy introduction into what the Unified Modelling Language (UML) is all about.
UML most simply put is a syntax for drawing diagrams describing relationships and dynamics of software systems.
There are several types of diagrams in UML:-
- Use Case Diagrams
- Class Diagrams
- Interaction Diagrams
- Package and Collaboration diagrams
- State Diagrams
- Activity Diagrams
- Component and Deployment diagrams
It's important to remember UML is a flexible communication tool, its not necessary to use or understand UML in its entirety to communicate a system's design.
It is quite normal when expressing a systems design using UML, that only a fraction of UML's syntax would be used in its description.
For instance you might only use a state diagram if state transitions in your system are particularly complex or make up a large part of its function.
UML is not about documenting parts of your system that are already well defined or obvious, for instance it would be a waste of time using it to illustrate relationships between classes in the .NET Framework.
UML is best used as a part of exchanging and communicating ideas on ways to model a complex system (which could be modelled in numerous ways).
Out of the set of UML diagrams, Class and Interaction diagrams are the most
commonly used.
Class Diagrams
Class diagrams describe relationships between classes, offering a high level overview of a system's architecture.
Very often class diagrams are the first step from business requirements into a possible architecture for a system.
Class diagrams are very simple and easy to make.
Out of all the types of diagrams in UML class diagrams are the most important to understand.
Out of all the types of UML diagrams class diagrams when architecting a system class diagrams offer the most value for the time spent creating them.
Within an hour or two you can quite easily define the structure of a system that may take many months to implement.
Quite often for small projects that require a little forethought I will create one or two class diagrams and from there go straight into coding.
This illustrates how flexible and value UML can be.
Most UML Case Tool programs offer functionality to allow developers to generate code from class diagrams, and reverse engineer existing code into class diagrams representing the relationships between classes in that code.
Here's a short list of some of the relationships you'll encounter on a typical class diagram
Associations
An association represents a relationship between instances of classes.
They can have an arrow on one, both or neither ends of the connecting line.
In this example class A has an association with class B but not the other way around.
I.e. within A, we might be creating an instance of B or be getting passed B as an argument; B however has no knowledge of A.
Without the arrow it would be bidirectional and both A and B would know about each other.
Associations are important as they give you an idea of how objects in your system are coupled together.
Loosely coupled systems in software development are often far more robust to change and easier to develop.
High amounts of coupling in a system are often associated with increased complexity, and an increase in the likelihood that the introduction of new features will trigger a major refactoring of the code for the system.
Dependency
A dependency is a special type of association indicating that a change in B's interface is likely to mean changes in A are required.
One of the aims of OO Development is to keep dependencies to a minimum so that the effects of changes are minimised.
Composition
Composition is a special type of association indicating B is a part of A. e.g. A could be a car and B it's wheels.
Typically composition is implemented as a data member, and the implementation of A's Dispose would call B's Dispose.
Generalization (Inheritance)
Generalization indicates that Class A is a specialization of B.
Typically generalization in a UML diagram would be implemented as an inheritance relationship.
Realization
Realization is similar to generalization; it indicates A realizes an interface specified by B.
Typically Realization is implemented as inheritance of an interface in C#.
Strictly speaking when implementing realization, B need not be an interface and it need not be inherited by A, it's permissible for A to generalize B just by implementing a common interface.
Interaction Diagrams
Interaction diagrams are probably going to be quite intuitive for those familiar with procedural programming as they highlight the procedural interactions between classes.
An Interaction diagram is used to illustrate how a particular use case is handled by the systems architecture.
A typical use case for example might be a customer placing an order for a product, or viewing a list of their orders, or cancelling an order.
Patterns
Patterns are standard object oriented solutions to problems that are commonly found in many software applications.
Singleton and Factory are all pretty common and widely known patterns. Patterns are typically illustrated using UML class diagrams.
The Design Patterns book by the "gang of four" is one of the earliest and most recognised books on design patterns.
UML Tools
There are plenty of tools out there that will help you manage your UML diagrams.
These tools will help you manage your UML diagrams.
Many allow you to generate C#/VB.NET code from your UML diagrams and also the ability reverse engineer your existing .NET source code into UML.
Many of these tools integrate into the Visual Studio.NET IDE.