This chapter raises several of the main issues that affect systems engineering in today's world. Systems engineering is concerned with defining and implementing an approach to solving problems, while managing complexity and communicating effectively over the entire lifetime of a project. Some of the common themes behind many such failures and disasters are the three evils of systems engineering: complexity, communications and a lack of understanding. Project failures and disasters are commonplace in today's technology-driven society. The result of such failures and disasters can range from loss of money, to loss of life and damage to the environment.

This chapter discusses structural modelling. The class diagram forms the backbone of the Unified Modelling Language (UML). Each 'model' has two 'aspects', whereas six or seven 'diagrams' realise each 'aspect'. There are two types of 'aspect': 'structural' and 'behavioural'.

This chapter introduces each of the 13 UML diagrams in turn and provides examples of their use. Each diagram is discussed at a very high level, often missing out much of the diagram syntax, so that the modelling aspects of each diagram could be focused on, rather than being bogged down by all the syntax of each diagram. The following models serve as a recap for everything said in this chapter, which should be readable by anyone who has read (and understood) this book so far. Even with the limited amount of syntax that has been introduced, it is still possible to model many aspects of a system.

This chapter is concerned with modelling requirements. The diagram that is most frequently used for modelling requirements in the Unified Modelling Language (UML) is the use case diagram, although, technically speaking, any diagram may be used. In this chapter, we concentrate on modelling requirements using use case diagrams. Use case diagrams, it may be argued, are perhaps one of the simplest of all diagrams, at least on the surface. Requirements engineering is the discipline of engineering that is concerned with capturing, analysing and modelling requirements. We are looking purely at modelling requirements with some degree of analysis; how these requirements are arrived at in the first place is entirely up to the engineer.

This chapter discusses how an architecture may evolve over the course of a system development and to identify some possible elements at various points of the project. This simple example was then discussed in more detail in terms of which UML diagrams could be applied to what aspects of the architecture model. Standards for architectures are also considered and, throughout, the use of the UML is discussed to see how it may help us to define, understand and validate our systems.

This chapter discusses tools that may be used for UML modelling and, in some cases, for general systems engineering tasks. The main aim of this chapter is to provide information and guidelines that describe how to make an informed decision when choosing a tool. At the end of the day, if you are carrying out any form of UML modelling, you will need to consider obtaining some sort of tool for assistance. Tools range from the very basic, such as a simple PAPS (paper and pen system) tool, to a full-blown, interactive 'environment', but which sort of tool will be right for you? Tools can be expensive, very expensive! It is therefore absolutely essential to know your requirements when choosing a tool and to make sure that your requirements drive the choice of tool, rather than the other way around.