This in-depth, pragmatic tutorial to UML 2, is adapted from the UML appendix of my book Object-Oriented Analysis and Design, John Deacon, 2005, Addison-Wesley, ISBN 0-321-26317-0. The material of the book, including this appendix is based on a course I give. Like the book, the aim of this UML tutorial is to be useful to typical developers using typical, object-oriented languages and frameworks.
If your interest is UML 1.5 (or UML 1.4) this UML reference should still be useful. The guide notes the major changes that took place. The biggest changes were to activity diagrams.
The book was written with the FrameMaker® publishing software, and, while the automatic generation of HTML is very nice, it didn't really do the illustrations justice. The footnotes from the book don't really work in HTML so they've been turned into end notes in the UML guide.
The generation process also produces a stylesheet that is somewhat idiosyncratic. I've checked in three of the commonest browsers and things are pretty acceptable in each, but, for example, only IE shows bullets correctly. The illustrations appear in pop-ups, so if you've turned off all pop-ups, you might not see the illustrations.
While you are welcome to reference, bookmark or link to this page, I request that you do not mirror it. Work is in progress to update this for the changes that took place between UML revision ptc/03-08-02 and ptc-04-10-02. The official home of this tutorial is http://www.johndeacon.net/UML/UML_Appendix/Generated/UML_Appendix.asp
This UML reference is divided among three pages. Here are some links to the tutorial sections within those three pages.
The main chapters of the book kept best-practice and pragmatic analysis and design as the primary focus. UML was introduced and used but it was treated as secondary. Here, UML takes center stage and gets a pretty complete coverage. Although much of what is in here has already been said, the UML in here is much more concentrated; unlike the book, there is (almost) no preaching here. Nonetheless, we still want to make sensible and insightful use of the UML, so this tutorial does offer opinions as to the best way to use the UML.
Back in the mid-1990s, we began to hear that Grady Booch was trying to unify some of the software development methods that were being proffered by different methodologists at the time. There were a terrifyingly large number of methods and notations floated around that time. Booch's wasn't the only attempt at a fusion or unification, but coming from the author of one of the two most popular methods of the time - the OMT of Rumbaugh et al. being the other - his effort seemed one of the more promising.
Eventually the unification began and in 1995 the world became aware of the Unified Modeling Language, or UML. Actually it was somewhat misleadingly called the Unified Method back then; it wasn't a method, it was a notation and the name was later changed to better reflect its character. The UML still focuses on modeling and notation; hence the need for books like this one - books that try to suggest a methodical way to do the modeling and populate the diagrams.
The original contributors were Grady Booch and James Rumbaugh. "Class" diagrams and statecharts began to stabilize.1 Later, Ivar Jacobson joined in the effort and use cases and interaction diagrams were added.
The time was right and something was ripe. Since the late 1980s a desire for standards and interoperability had been growing in the industry. As articles and presentations began to appear using the UML, people's interests were roused. Customers began to ask for UML support from the CASE tools. The takeup of the UML began to snowball.
In 1997 The Object Management Group, or OMG (http://www.omg.org) took over stewardship of the UML from Rational Software Corporation, where the three authors were all working at that time, and where the UML had originally been developed. The OMG's main prior claim to fame had been the CORBA distributed object standard.
Under the OMG, the UML underwent steady "tinkering" until version 1.4.1. (There was a version 1.5 but that didn't change any diagrams.) It was clear however, that a major reworking would eventually be necessary to improve the usability, focus and consistency. In parallel with the modifications for 1.4 and 1.5, work began on UML 2.0, which arrived as a Final Adopted Specification in 2003 and was due to replace UML 1.5 in 2004.
This appendix will describe UML 2.0, and will mention what UML 1.x had if there is a major difference. If you see "ptc/03-08-02", that is referring to the exact version of the UML superstructure specification that was used for this book. It refers to a particular file from the OMG's FTP server. Work is underway to update this to the latest revision - ptc-04-10-02.
The focus of the main chapters of the accompanying book was method . Not all of the UML diagrams were found to be useful at all times; and not all of the elements of the diagrams were found to be useful for the typical project. So in the main body of the book, the UML coverage took second place to the the interests of method. In this appendix, method suffers in the interest of UML coverage.
This appendix is a ready reference. It was written to complement the book's coverage of analysis and design best practices. It will be somewhat dangerous when taken out of the context of the book. Anyone who tries to start drawing diagrams, with no regard as to their appropriateness and appropriate contents, will waste a lot of time for very little result.
Even so, this appendix isn't a full treatment of the UML. For a complete reference, I'm afraid you'll just have to read the standard. (Although having read this appendix, you should be in a much better position to understand the official UML specification!) The target readership consists of the typical developers of typical object-oriented systems using typical object-oriented languages, and of the typical users of typical CASE tools.
We developers create specific models: your models, my models. The superstructure of the UML, which is our primary interest, offers standard modeling materials that enable anyone who understands the superstructure, to create models that other people who understand the superstructure will stand a good chance of interpreting properly. It is the superstructure that this appendix is mostly about.
The infrastructure doesn't focus on the UML itself; instead it describes the way in which the UML is described, and the way that description is structured into layers and packages. For example, the most basic elements of activity diagrams - those that approximate simple flowcharts - are in one layer, while the elements that extend activity diagrams to approximate Petri nets are in another, "higher" layer. This layering helps organize the UML, and it helps incremental learning as well.
Imagine you were going to develop a CASE tool, and that your CASE tool was going to store the information gleaned from its diagrams in a nice sensible schema (logical database structure). What kinds of elements (what tables?) would the database need? That's what the infrastructure tries to tell you, the tool builder, as formally as possible.
So if the UML allows us developers to produce models, and the UML's structure is itself modeled - in a metamodel - does it stop there? No. We acknowledge that there are modeling needs other than those of object or component developers. The infrastructure tries to ensure that the way the UML is described - the metamodel - is itself compatible with other modeling language descriptions. The OMG has another metamodel called the Meta-Object Facility (MOF). Part of the reason for reorganizing the UML is so that there is an alignment of UML and MOF. They have decided to do this by making the MOF the metamodel of the UML. Developers using the UML would perceive this top model as a "meta-metamodel".
By way of comparison with cultures other than software development, if you are familiar with XML, you will know that there is an infrastructure to markup languages. I might decide to describe some data using the rules of the film critic markup language. If such a markup language were to be created, the creators might decide to make their markup language XML compliant. XML, and the SGML that it is based upon, and the compliance of the film critic markup language would form the infrastructure of the film critic markup language's superstructure.
The languages in which languages are expressed are often called metalanguages. The infrastructure of the UML has metamodels of metamodels. A common and helpful picture is the "M n " picture of the layering. Look at Modeling layers (metamodels and meta-metamodels).
Pick the most concrete instance you find useful and declare that to be in the M 0 layer. This would be, for example a run time instance of the concrete class RecordedFingerprintSet : the instance representing the recorded set of fingerprints for John Deacon, for example. (To keep life simple, we will picture a programming language like C ++ where there is no significant run time presence of the class itself, only the object instances.)
Above that (and ignoring the source code files) we find our design model, expressed in UML. We see, for example, in that particular UML model a box representing the RecordedFingerprintSet class. This box exists in the M 1 modeling layer.
The RecordedFingerprintSet class box is just one of many concrete class boxes representing concrete classes. The implementation class (concrete class) box is one of the kinds of symbols defined by the UML superstructure. That there is a representation for implementation class (and others for interfaces, etc.) is defined in the M 2 modeling layer. This layer is what we are thinking about when we learn to use the UML, and the truly motivated might go so far as to look at the formal model, in the infrastructure, where the symbols we are leaning to use are defined.
The kind of reader who is interested in the infrastructure is almost certainly the kind of reader who should be working from, and be happy working from, the standard itself, which can be downloaded from the OMG's web site (see the beginning of this appendix), so we will say little more about the infrastructure.
The Object Constraint Language, or OCL, is somewhat different. It is a textual, formal, expression language2 for rigorously writing constraints using identifiers and values. Constraints can appear in diagrams, often involving brackets: square for guards and curly for general constraints. Constraints can also express preconditions , postconditions and invariants .
Preconditions, postconditions and invariants are particular easy and powerful ways of improving specifications. Preconditions are statements that must turn out to be true before particular things can take place. Postconditions are statements that must turn out to be true after particular things have taken place. Invariants are things that must always hold true when the system is at a stable point, i.e. the elements of the invariant are not actually undergoing change.
There are various levels of power that expression languages can make available. Most programming languages, for example, only make a simple, "boolean" kind of logic available within expressions. Higher-order logics can talk about subsets in expressions. Higher-order logics, for example, can make statements like, "For all thefts valued at over $1000 ( 1 1150), form P60 must be filled in", or "For all category 3 holding facilities and above, there must exist a padded cell." Languages without higher-order logic cannot make such statements, and must instead use processing loops of some kind.
The OCL has forAll and exists operators,3 but they can only be applied to identifiable existing collections. So it has a kind of higher-order logic.
There are two kinds of diagrams: structure diagrams which represent the way things are, and behavior diagrams which represent the way things happen. I will list the diagrams that have different sets of symbols; i.e. having learned the contents of one of these, you would have more content to learn for another.
Even in this appendix where I was going to try to be less method-fussy, I feel compelled to put laughing quotes around class. We use "class" diagrams for much more than just classes, in the regular sense of the word. In this book, we have typically been producing analysis diagrams with entities, early design diagrams with object types and class diagrams with classes, abstract classes and interfaces.
Interestingly, in the draft of UML 2.0 that I'm working from (ptc/03-08-02), use case diagrams are not mentioned in the behavior diagrams list, although they do appear at the end of the behavior section. If such things were important, which they aren't really, you could argue that because use case diagrams only show the existence of the use cases and the relationships between the use cases, they are structure diagrams. The behavior that a use case tells us about, is not graphically present in the use case diagram , it is "behind the scenes", in the model repository in character format (e.g. text), or it is expressed in a diagram other than a use case diagram - an action diagram, for example.
There are other kinds of diagram. They use the same symbols as those we have already listed, but they have specialized purposes. UML diagrams shows all thirteen kinds of diagram.
If a diagram requires a border or a title, Diagram frame shows how this is done. The border plus title is known as a frame . Some behavioral diagram elements appear on diagram borders - ports or entry/exit points, for example.
Currently I write about, and deliver training courses on, analysis and design, and in object technology, mainly to financial and physics organizations, including over ten years' work at CERN, the high-energy physics institute and the creator of the web, as well as companies such as banks and telecommunication providers.
I guess it's just the whims of business as to why I've ended up with such an apparently polar client base. However, after finishing a science degree I did work for a year or so in accountancy before moving on to software development, and eventually returning to science via teaching software engineering and OOA / OOD to high-energy physics establishments like CERN, Rutherford-Appleton and DESY.
In the 1980s, I spent a couple of years at a London polytechnic teaching analysis and design, programming and artificial intelligence.
The software development I have done ranges over application areas from TV to double-entry bookkeeping, over jobs from programming to project management, and over architectural levels from boot code to frameworks.
(And - odd coincidence department should you know your rock bands - I was involved in the music industry for a brief while and do play bass:-)
Update: I was diagnosed with throat cancer in 2010. I made it (as of writing this it's 2013), but I had to give up the lecturing. I retired early and took up an old hobby - locks and safes - to augment the pension and the royalites.