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
| 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!) |
To order from:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.