What is the Unified Modeling Language?
 |
When discussing UML, we need to establish one important point right up front.
In theory you can apply aspects of the notation according to the steps prescribed by any process that you care to choose - traditional waterfall, extreme programming, RAD - but there are processes that have been developed specifically to complement the UML notation. You'll read more about the complementary process(es) later in this chapter.
Why use UML?Hidden inside that specific question there's a more generic question, which is "Why use a formal analysis and design notation, UML or otherwise?" Let's start to answer that question by drawing an analogy. Suppose you wanted to make a bridge across a small stream. You could just place a plank of wood across from one side to the other, and you could do so on your own. Even if it failed to hold your weight, the only downside would be wet feet. Now suppose you wanted to make a bridge across a narrow river. You'd need to do some forward planning to estimate what materials you'd need - wood, brick, or metal - and how much of each. You'd need some help, and your helpers would want to know what kind of bridge you're building. Finally, suppose you wanted to build a bridge across a very wide river. You'd need to do the same kind of forward planning as well a communicating your ideas to a much bigger team. This would be a commercial proposition with payback from fare-paying passengers, so you'd need to liaise with the relevant authorities and comply with health-and-safety requirements. You'd also be required to leave behind sufficient documentation to allow future generations to maintain the structure long into the future. In a software context, this means that formal design becomes increasingly important as a function of the size and complexity of the project; in particular, as a function of the number of people involved. Based on that analogy, and wider project experience, we could conclude that a formal design notation is important in:
Of course, we've probably all encountered projects in which little or no formal design has been done up-front (corresponding with the first three bullet points in that list); in fact more projects than we care to mention! Even in those situations, UML notation has been found to be invaluable in documenting the end result (the last bullet point in that list). Though not recommended, if that's the extent of your commitment to UML you'll be most interested in the Reverse Engineering discussion in Chapter 5. Now that we've answered the generic question, let's return to the specific question of why use UML? Well it's become something of an industry standard, which means that there's a good chance of finding other people who understand it. That's very important in terms of the communication and documentation bullet points in our list. Also if you or anyone else in the team does not understand it, there's a good chance of finding relevant training courses, or books like this one. That's very pragmatic reasoning and perhaps more convincing than a more academic (or even commercial) argument such as:
A Brief History of UMLTaking the phrase Unified Modeling Language as our starting point, we've discussed in the previous section the "language" (namely, notation) aspect. In the next section, we'll investigate the "modeling" aspect, which leaves us here with the word "unified". What, or who, preceded the UML and how did it all become unified? This will become clear as we step through a brief history of UML. In the beginning although there was a plethora of object-oriented "methods", there were three principal methods:
These three methods have many ideas in common, yet different notation for expressing those ideas. Some of you may remember that in an OMT class diagram the classes were represented as rectangular boxes whereas in the Booch method they were represented as stylized cloud shapes. Also, each method placed emphasis on different aspects of object-oriented software development. For example Jacobson introduced the idea of use cases, not addressed by the other methods.
The unification of these three methods combined the best bits of each method with a common notation (UML) for the common concepts - the end result being an industry-standard notation for analysis and design. If you speak with anyone who claims to be doing object modeling, chances are they'll be using UML. So how did this unification play out in time? The key dates are:
If we've given the impression that the Unified Modeling Language is the exclusive work of only three contributors, the three amigos, then let's set the record straight. Some of the concepts are based in the early work of other individuals - for example, David Harel's work on Statechart diagrams - and some further enhancements have come from other member organizations of the OMG; for example, the Object Constraint Language (OCL) devised by IBM.
More information on OCL can be found at http://www-3.ibm.com/software/ad/library/standards/ocl.html. At the time of writing, the UML specification is at version 1.4 and in mid-2001 the OMG members started work on a major upgrade to UML 2.0. Modeling tools - including Visio for Enterprise Architects - will always be one or two steps behind in their support for the specification, but that's not usually a big problem because the core concepts discussed in the next section are now quite mature and stable. At the time of writing, the version of Visio for Enterprise Architects used in the construction of this chapter provides support for UML at least up to version 1.2 - this can be determined from the About error checking in the UML model section of the Microsoft Visio Help:
| ||||||||||||||||||||||||||||||||||
EAN: N/A
Pages: 85