I want to emphasise that it is really important that both Business and IT development teams understand UML because it is a powerful communication, analysis and design tool. An understanding of UML and how it can be used is a starting point for significantly more successful IT projects.
Over the last 10 years or so UML has been an important and beneficial feature in all of the projects I have been involved in. I was first introduced to UML by a colleague (Tony Loton
I’ve used many other UML tools since then and I currently use Enterprise Architect – all the diagrams are created in Enterprise Architect 6.0, but newer versions are so much better. I’ve also been in the position to pass on that knowledge to many other colleagues – and now I am going to pass on as much as I can to you.
What Is UML?
The Unified Modelling Language (UML) is simply a notation. You use it to describe IT systems by creating a set of diagrams using standard symbols to represent its structure and behaviour.
But, as with any notation (like mathematical symbols), it offers so much more when you use it effectively. Just as a mathematician will learn a multitude of techniques and algorithms for manipulating mathematical models, with UML you can create a model of an existing or proposed system and use a range of simple techniques or comprehensive methodologies (such as Rational Unified Process) to arrive at a complete and detailed design for an IT system.
UML defines a set of pictorial symbols (rectangles, ovals, lines and other shapes) each representing a different piece of an IT system that are used to draw diagrams describing it.
There are several different types of diagram, each representing the system from a different point of view. Some describe the behaviour of the system – what it will do – while others describe the structure of the system – the parts that fit together and the relationships between them. In larger systems, each point of view can be divided into several diagrams showing smaller parts of it.
Underlying all of these diagrams – particularly when you create them with a UML modelling tool such as Enterprise Architect – is the model. Each diagram is a small window onto this model allowing you as a creator to grow and refine the model by focussing on just one small aspect of the model. As a viewer, it presents a clear and unambiguous view of a part of the model – which could be a model of a huge and complex system.
A Couple Of Examples
OK, so now I’ll cut the waffle and show you a couple of simple examples based on features that will be in the next releases of Kajabity Tools (SDI Form classes with File Open/Close and Printing).
First a simple Use Case diagram which describes at a high level what a system should do.
It looks a bit like something a 5 year-old might have done with a stick figure holding 4 balloons. Well, it’s not. This is one of the most important types of diagram (especially if you’re a Business Analyst like me).
The stick figure is called an “Actor” and in this case it represents a person who is going to use an application. The “balloons” are the Use Cases and each one represents a single process or function a user wishes to perform. The examples here are for Printing – e.g. Print Document.
The “string” from the actor “Application User” to three of the use cases indicates that the application user will “Use” each of the three use cases – in other words an Application user can Print a Document, Preview a Printed Document or Change Page Settings.
You will also guess that the fourth use case is “included” in the other three. What that means is that as a part of a process – for example, printing a document – we want to Correct the Printer Margins.
In the next posting I’ll go through Use Case diagrams in a lot more detail, how to create them, more features, the many different ways they can be used and providing more detail in a Use Case specification.
Next, a Class Diagram which describes the parts of a system at a lower level.
As I said, for some readers an introduction to Classes and Object Oriented design will be necessary – however, there are a number of details that most people will quickly be able to see represented in this diagram. This diagram describes “things” (classes), their properties (attributes), what they can do (methods) and the relationships between them.
We can see here that an SDIForm is a kind of Form (because of the type of line and arrow), it has a DocumentManager (called “manager”) and the DocumentManager has a Document (called, reasonably enough, “document”). Also, a TextDocument is a special kind of Document (one that holds Text) and there is a TextDocumentManager which can be used to manage it.
A lot of the details shown in the boxes and on the lines relates to concepts in Object Oriented Design so I will cover this as simply as possible in another posting fairly soon.
Summary
There is a lot to learn in UML, I won’t deny it, and it’s more than just a set of pictures. In any description of UML I am going to have to describe each of the types of diagram and what they represent and how they can be used to illustrate or drive analysis and design.
I will explain forward and reverse engineering and introduce you to a number of related concepts including Objects and OO Analysis and Design (essentially “things that do stuff”) , and Patterns (commonly used structures and algorithms).
All this will give me an excuse for lots of postings over the next few months.
Further Reading
You might find some of the following web sites and books useful: –
http://www.uml.org/ – the website dedicated to UML by the people that look after it, the Object Management Group (OMG).
http://en.wikipedia.org/wiki/Unified_Modeling_Language – a good summary of UML and it’s history.
http://www.sparxsystems.com.au/uml-tutorial.html – a tutorial on the latest version of UML by the people that brought you Enterprise Architect.