Jon Holt
IEE, London, 2001
Jon Holt
IEE, London, 2001
ISBN 0852961057 (boards)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Other Reviews
This is an introductory text, which as the preface states: 'is not intended to be a definitive systems engineering book' but 'tries to tackle some of the main issues' of how the UML can be applied to Systems Engineering (SE), understood broadly as defined by Stevens et al.
Engineers are often sceptical of new techniques, especially if they involve conceptual models rather than analytic ones. They are especially doubtful of all that comes from the world of software, where a 'system' is all too often the same thing as an program, or perhaps a suite of programs. To many specialist engineers, the very existence of a discipline of SE is poorly understood. Holt wisely reiterates the basic case for deliberately managing complexity in engineering projects using SE in his introductory chapter. It certainly isn't self-evident that a technique that is useful for software is going to be applicable to railways, for instance. So Holt has set himself a considerable mountain to climb.
To start at the beginning, UML, the Unified Modeling Language comes from the world of Object-Oriented Software. The UML represents an attempt by a range of commercial interests (led by Rational Software Corp.) to define a standard set of ways of representing logical structures (with static models such as class diagrams) and functional behaviour (with dynamic or behavioural models, such as state charts and activity diagrams -- aka flow charts). It also represents the visible face of Object Orientation; the means of expression of the Rational Unified Process; and an attempt to sweep away despised practices such as Structured Analysis/Design with its old-fashioned Dataflow Diagrams and other obsolete notations such as, ahem, state and flow charts.
So it is on this controversial foundation that Holt sets out to teach the rudiments of UML. He has a strong background in university teaching and industrial training, and he has the gift of making what are sometimes quite fiddly diagram and model constructs seem intelligible. His examples are of two kinds: the homely doghouse (due to Booch, actually), game of chess, or classification of creepy-crawlies; and the process-mad EIA 632, ISO 15504 and their acronym-rich associates. There is a useful discussion of how the different UML diagrams overlap in meaning and how interaction diagrams represent scenarios which are instances of use cases.
Modelling is to some extent held up as a panacea:
The book retains quite a strong software focus. Some types of UML diagram are certainly shown to be widely applicable -- notably, activity, state and use case diagrams, and arguably class (part-whole) hierarchies as well, at least when used at high level. Others such as collaboration diagrams seem more at home in the world of software.
If you have never heard of the UML (where have you been for the last decade?) and want to gain a general understanding of what its nine types of diagram and two types of model are for, then this may be the book for you. You will then be able to approach books such as Fowler's UML Distilled, or for that matter Rumbaugh, Jacobson, and Booch's UML Reference Manual, with something more like confidence.
If you are new to SE and want a general overview of what it is and how to practise it, see Stevens's book first, then (when you are ready to start making UML models) move on to Holt. If you are interested in the SE process, and want to learn how to describe it more accurately, you will at once find the conceptual tools illustrated here very helpful.
© Ian Alexander 2002
You may also like:
However, many projects do succeed. One reason is that they avoid, or minimise,
the aforementioned problems due to effective modelling. (page 33)
