The excellent idea of writing a lightweight book on the Unified Modeling Language (UML) wasn't ours, we admit. This idea originated from Milan's customers. Having taught more than a hundred courses and seminars on omponent approaches to software development and on UML over the past few years, he was repeatedly asked for 'UML made easy' for people who specify, buy, or manage complex software systems, yet don't program them. This demand seems logical given the way UML is being used in projects and read of in the success stories - as well as the increasing specification work load in any knowledge industry (see Introduction). However, as we moved on into this book project, both of us became increasingly enthusiastic about the idea, as did Cambridge University Press (CUP). Luckily, a majority of our readers are quite familiar with CUP from their own (variety of) fields; so this book is likely to be seen as accessible in most senses of the word.
Any system specification can state requirements on functionality, usability, reliability, performance, and supportability, as well as legal and technical constraints where relevant. In UML projects, we start from a view of the business - its processes and activities - and move into functionality, incrementing all the remaining, nonfunctional, bullet lists as we go. These are then resolved later, during construction, rather than during specification. As stressed in the chapter on components as well as implied throughout the book, wherever we're on the scale between 'buy' and 'build,' the specification work and business analysis just don't simply disappear. Even with an off-theshelf system, we still specify our requirements, and we still need to understand the essence of all those UML diagrams.
To keep this book lightweight, we stay reasonably lightweight on the art of balancing the content of internal/technical UML views. This kind of balance is key down the road, that is, later on in a software development project.