6 Modelling and the UML
‘Essentially, all models are wrong, but some are useful.’
Models are forms of description often adopted in software development. They are abstractions used to represent and communicate what is important, devoid of unnecessary detail, and to help developers deal with the complexity of the problem being investigated or the solution being developed.
Modelling is used in other forms of design and engineering. For instance, architects develop different models of buildings – some addressing structures, others materials, others ergonomics, and so on. The same happens with modelling in software development: some models are used to capture properties of the problem domain, such as key elements of the business or how its processes work, while other models are used to consider different aspects of the software, such as how the code is divided up and organised, or how various elements of the software communicate and work together. Each model is an abstract representation of some view of the system, and such views may change as the development process unfolds.
Activity 11
Consider different types of model you have encountered in your own practice of software development. What was their purpose? How were they expressed?
In software development, we build models from different perspectives. In particular, we can distinguish between the following modelling types.
Domain modelling is concerned with understanding and modelling context information for a specific problem, independently of a decision to use a software system to deal with that problem. A domain model is a representation of the main concepts in the real-world problem context – for instance, a business under consideration. A domain model does not necessarily assume a software solution.
Specification modelling assumes that a software system will deal with the need in context. A specification model represents software elements used in the software solution to a problem, and is mainly concerned with the definition, at a high level of abstraction, of the services provided by the software.
Design modelling describes the software system itself, with the allocation of responsibilities to its various parts, and its behaviour and control flow.
Note: the distinction between ‘domain models’ and ‘design models’ was introduced by Cook and Daniels (1994). They called the domain model the ‘essential model’, and the design model the ‘implementation model’. ‘Business model’ is also often used in the literature with a meaning similar to domain model.
Domain modelling plays an important role in understanding the need in context, before suggesting any software solution. The important elements of the context, whether they are people, products, departments, sensors, alarms or operators, need to be identified. Only by understanding the need in context, and how, why and with what consequences that need changes, can a fit-for-purpose software solution be specified. However, modelling the domain may sometimes be unnecessary – for instance, when there is an accepted need for a well-defined software system to solve a well-understood problem. In such a case, modelling the domain would not bring much advantage.
Domain and specification modelling may produce very similar models, but the interpretations of the models are different; the former types of model are about real-world entities, the latter are about software representations of those entities.
Activity 12
How would you describe the relation between these three modelling perspectives and the traditional split between analysis and design in software development?
Discussion
You may consider domain modelling and specification modelling as analysis activities – that is, concerned with understanding what a problem is, and specifying what is required of the software system to be developed. As you might expect, design modelling corresponds to the design activity.
Models are usually constructed by following specific linguistic conventions, often referred to as techniques, and the models’ level of formality will depend on the formality of those conventions; for instance, models can be based on narrative, diagrams or even mathematics.
Well known modelling techniques in software development are defined under theUnified Modelling Language (UML). UML is one of the most popular and successful standards currently used by the software industry. UML is the result of the merging of several notations that appeared during the 1980s and early 1990s, augmented by new techniques and even a mechanism to extend the notation further. You will not learn UML in its entirety, but concentrate on a subset of the most commonly adopted techniques.
It is important to note that UML is a modelling language, not a development process – it gives you a set of techniques, but does not prescribe whether or how these techniques should be used during development. In fact, because UML is the result of an exercise in unification, it can be used flexibly within many different processes and practices, and the same technique can serve different purposes. Also, UML models can be constructed at different levels of precision. UML can be used equally effectively both as a sketching notation, for example to jot down ideas or communicate them among stakeholders, and for precise description of aspects of software systems, for example as semi-formal specification of system functions.
Brief UML history
In the early 1990s, various object-oriented methods appeared along with a proliferation of techniques and notations. By the mid-1990s two authors of well-known methods – James Rumbaugh, one of the authors of the Object-Modelling Technique (OMT), and Grady Booch, author of the Booch method (Rumbaugh et al., 1991; Booch, 1994) – joined forces in an attempt to unify their methods. They named their joint effort the Unified Method. Rumbaugh and Booch were soon joined by Ivar Jacobson and his colleagues, authors of Object-Oriented Software Engineering (OOSE), in the development of what became known as the Unified Modeling Language (UML); see Jacobson et al. (1992). As UML has evolved it has incorporated feedback from the object community, and has won the support of many people and organisations which considered the idea of a unified modelling language a valuable one. UML was then submitted for standardisation to the Object Management Group (OMG), a consortium of several large software companies that produces and maintains computer-industry specifications. UML was formally adopted in 1997. The UML specification is constantly updated. At the time of writing (2013), UML 2.5 is near completion; this is the basis of the notation we use in this course.