Using UML: software engineering with objects and components

Welcome to the book's home page! If you're reading this in a frame and would rather read it in the whole window, click here.

Please let me know if you have any suggestions about what should be here (or better still, contributions). Click here or here for information from Addison-Wesley (now part of Pearson Education) on the book.

Material at this site is variously copyrighted: ©Addison Wesley Longman Limited 1999 ©Perdita Stevens 1999-2006 ©Rob Pooley 1999. Copying details


Full bibliographic information and ordering links

Title: Using UML: Software Engineering with Objects and Components
Authors: Perdita Stevens with Rob Pooley
Publisher: Addison-Wesley (Object Technology Series)
ISBN: 0-201-64860-1
Pages: 280
Price: around 27.95 in the UK (variable, shop around!)
BibTeX entry
(Those are the details of the current, updated, edition, which uses UML1.3. Not sure why anyone would still want Details of the first edition but here they are anyway.)

To order from:

General web resources

About UML

Programming language tutorials

Links to collections of links

Resources by chapter

Part I: Conceptual background

Chapter 1: Software engineering with components

This chapter is a whistle-stop motivation for and introduction to the kind of software engineering this book is about. We consider what a high-quality software system is, and the extent to which we have high-quality systems today. We discuss the need fo modularity, and cover the characteristics of good modules. We consider how to go beyond engineering good modules in isolation towards engineering systems based on good reusable architectures with endemic component reuse. Finally, we mention process.

Chapter 2: Object concepts

This chapter is a whistle-stop motivation for and introduction to object orientation. We consider what an object is and how messages are sent between objects. We show that the objects in a system can usefully be divided into classes, rather than being considered individually, and we begin to consider the connection between objects and components. We discuss how a class can be defined using another class's definition by inheritance. Finally we discuss the other feature of inheritance in object oriented languages, its ability to provide polymorphism and dynamic binding.

Chapter 3: Introductory case study

(including panels Design by Contract I and Persistence)

This chapter describes a simple case study. It introduces the main features of UML in a necessarily sketchy way; Part II of the book covers each diagram type in detail, but since the diagrams are designed to be used together in an iterative development it is important to have an overview of what UML is before going into details.

Chapter 4: The development process

We discuss development methods in general, and the need for modelling languages. We briefly discuss the history of UML, and the question of what development methodologies can be used with UML. Finally we discuss the role of design, models and diagrams. A system has a design. There can be several models of a design, focusing on different aspects, which must all be consistent. A model can be represented by some diagrams, which must all be consistent.

Part II: The Unified Modelling Language

Chapter 5: Essentials of class models

(including panel Design by Contract 2: substitutivity)

This chapter introduces class diagrams, which represent the static structure of the system to be built. We discuss how classes and their associations can be identified, and the concept of multiplicity of an association. We show how a class's attributes and operations are shown. Next we cover generalisation, which can be implemented for example by inheritance. Finally we discuss the role of the class model through the development, and illustrate the use of CRC cards for validating a class model.

Chapter 6: More on class models

(including panels OCL, the Object Constraint Language and Stereotypes)

This chapter considers some advanced features of UML class models. We describe some ways of giving extra information about the assocation between classes, considering aggregation and composition, roles, navigability, qualified associations, derived associations and association classes. We also covered constraints, which are a general feature of UML that can be used for a wide variety of purposes; here we discussed their use for giving class invariants and for recording the relationships between various associations. Next we consider interfaces, which, again, can be applied more generally. We mention abstract classes, and so-called parameterised classes, which are not really classes at all, but rather are functions which take one or more classes as arguments and return classes as the result. Finally we consider dependency and visibility.

Chapter 7: Essentials of use case models

(including panel Use case driven development?)

This chapter introduces simple use case models and shows how they are used to specify the behaviour of a system in a design-independent way. We discuss how to identify actors, use cases and the communication relationships between them, and how to use the use case model in the context of a development project.

Chapter 8: More on use case models

In this chapter we show how the uses relation can record what functionality is common to several use cases, and how the extends relation can record what happens in unusual cases. We discuss generalisation between actors, and the relationship between actors and classes.

Chapter 9: Essentials of interaction diagrams

(including panel Where should messages go? Law of Demeter)

We discuss how to use interaction diagrams -- collaboration and sequence diagrams -- to describe how objects interact to achieve some piece of behaviour. Collaboration diagrams are better at showing the links between the objects; sequence diagrams are better for seeing the sequence of messages that passes. Interaction diagrams can be used to show how a system realises a use case, or for various other purposes including showing how a class realises an operation or how a complex component is to be used.

Chapter 10: More on interaction diagrams

This chapter covers two more advanced aspects of UML interaction diagrams. First we discuss generic interaction diagrams, which allow us to show more than one scenario on a diagram, by permitting the expression of conditional and iterative message passing. Then we very briefly introduce some features suitable for modelling concurrent systems.

Chapter 11: Essentials of state and activity diagrams

(including panel Designing classes with state diagrams)

We describe how to use state diagrams to model the way that significant changes in an object's attributes affect the way it reacts to events, such as messages. We emphasise that, although if an object has such complex behaviour it can be useful to show it in a state diagram, it is better to avoid designing classes with complex state-based behaviour where possible. We also discuss activity diagrams, which model the dependencies between activities, such as the operations involved in the realisation of a use case, or the use cases of a system.

Chapter 12: More on state and activity diagrams

In this chapter we consider some further features of UML state and activity diagrams. We consider events and actions more general than the message-passing examples in Chapter 11, and go on to consider state diagrams with compound states, with or without concurrency.

Chapter 13: Implementation diagrams

(including panels Summary: classifiers and instances and The deployment model in the project)

We consider the two kinds of UML implementation diagrams, component diagrams and deployment diagrams, and how to use them. Component diagrams express the structure of the implemented system, helping to keep track of dependencies to ease maintenance, and to record the reuse of components. Deployment diagrams show how the system is deployed on a particular hardware configuration.

Chapter 14: Packages, subsystems, models

In this chapter we discuss UML's mechanisms for structuring the development of systems. The most general mechanism is the package, which can contain any sensible collection of model elements. There are two specialised kinds of package. A subsystem has a specification part and a realisation part, and can be instantiable; a subsystem typically describes a component. UML's notion of model formalises the informal idea of model we've been using all along: a model includes the model elements which make up a particular view of a system at a certain level of abstraction. A model is represented by one or more diagrams.

Part III: Case studies

Chapter 15: CS4 Administration

Chapter 16: Board games

Chapter 17: Discrete event simulation

Part IV: Towards practice

Chapter 18: Reuse: components, patterns

(including panel What is a component really? Controversial!)

We discuss reuse, covering what can be reused and the practical problems in getting a reuse programme established. As a special case, we consider patterns, which can be seen as the reuse of expertise. Many of the difficulties in achieving a high level of reuse, especially by building components in-house, stem from the need for reused artefacts to have high quality and for the organisation to support the work needed to build and to use them.

Chapter 19: Product quality: verification, validation, testing

This chapter considers product-focused techniques for improving quality, after briefly reviewing what quality of software is. It classifies product quality improvement activities into verification (checking whether we're building the product right) and validation (checking whether we're building the right product). It considers techniques for verification ranging from informal human checks, perhaps aided by a list of things to check, through to formal proof. An important part of validation is usability analysis, which requires the involvement of users. Testing is useful both for verification and for validation; we discuss the special needs of object oriented systems. Formal technical reviews, too, are useful in both areas. However, we suggest that focusing on the product may not be sufficient: in the next chapter we consider process-focussed approaches to ensuring high quality.

Chapter 20: Process quality: management, teams, QA

(including panel Quality assurance: the case against)

In this final chapter we consider the contribution made to the quality of systems by the organisations which build them and the quality assurance processes of these organisations. We discuss management, leadership, teams, organisations and quality assurance.

Copies of diagrams

Here are
all figures in PDF form (with captions, including figure numbers). These are from the most recent edition of the book. Here you can find diagrams from the first edition.

Notes on recent changes to UML and hence Using UML

The original edition of the book was based on the UML 1.1 standard. The Object Management Group's UML Revision Task Force was charged with updating the language to deal with bugs and suggestions, and versions 1.3 and 1.4 of UML were released. The first three printings of the Updated Edition of the book were based on UML1.3; later printings are based on UML1.4 (which differs from UML1.3 only in very small ways, see below).

The main changes between UML1.1 and UML1.3/4 are to the relations between use cases (Chapter 8). This is not surprising: as we discussed in the original Chapter 8, the original scheme (uses and extends relations between use cases) proved confusing, particularly because these relations were counterintuitively described as generalisation relationships. These relationships have been replaced by a "genuine" generalisation relationship, plus two stereotyped dependencies corresponding to the old stereotyped generalisations.

Warning: Booch, Jacobson and Rumbaugh's UML User Guide, published in autumn 1998, claimed to be up to date with respect to UML 1.3, but this is naturally not true, since UML1.3 was not finalised until June 1999! What happened was that the numbering of the releases was changed at the last minute; the Amigos expected that 1.3 would be released in autumn 1998 and that what we now know as 1.3 would be called 1.4.

The next version of UML will be UML2.0, which is scheduled to be finalised in 2002. The current plan is to produce a Second Edition of Using UML describing UML2.0. My best guess is that UML2.0 will not involve large changes to UML as presented in Using UML, although it will involve significant extensions (some of which may be discussed in the Second Edition) and rearchitecting of the language definition.

Errata and changes to Using UML

How can I tell which printing/edition I have?

Pointers to a few of the courses that use this book

Note that the inclusion of a link here does not imply that the authors of the courses have granted permission for others to reuse their material. Ideas are free, though!
(NB I've given up attempting to be exhaustive - but if you have a particularly interesting link that you think should be here, please let me know.)

For lecturers and other instructors

In addition to the material on this page, there is a password-protected web site
available only to instructors. This is now run by Pearson Education, not by me. Please follow the instructions on the site to get access.

About the authors

The book was originally co-authored, but I (Perdita) am now solely responsible for updating it. My day job is as a reader in software engineering in the School of Informatics here at Edinburgh. Edinburgh offers a range of undergraduate degree courses (BSc, BEng) and postgraduate degree courses (MSc, MRes, PhD) .