3 Modelling languages
3.1 Making consistent models
It would be preferable to have a consistent way of representing the different models that one might want to construct. The notion of a modelling language allows the developer to make useful connections between different models. For the most part, models are represented diagrammatically. There are two aspects of a diagram-based modelling language that you should be aware of:
a set of rules that defines what symbols can be used on a particular type of diagram and what can be constructed with these symbols – its syntax;
one that determines what the diagrams and symbols mean – its semantics.
It is important to recognise that you construct models to express your understanding of a particular situation in the expectation that the model will help you pass on that understanding to others. On any given project there are decisions to be made about every model. You should favour a modelling language that is:
sufficiently expressive, so that you can be confident that your particular ‘take’ on a situation can be represented;
easy enough to use, but in such a way that its notation allows you to express what you want to say (there will necessarily be some limitations on this because models are a simplification of reality);
unambiguous, so that the number of possible interpretations of your model are minimised (ideally, that number should be one);
supported by suitable tools, so that you can apply your modelling skills and not be constrained by your drawing skills;
widely used, so that you can move to other problem situations without having to learn a new modelling language every time. If you leave one project team and join another that uses the same modelling language, you need only learn about the new problem situation. This advantage is amplified if you have also moved to a different company at the same time! Naturally, the team that you join will expect you to be more productive than if you had to learn a whole new modelling language.
Using an accepted language increases the chance that a component developed for one product, such as a software application or some electrical device, can become a component in another product. For example, suppose you were trying to decide which electric motor to include in a new vacuum cleaner. Clearly, you would begin by reading all the descriptions. The chances of choosing an appropriate electric motor are increased if you can understand the descriptions of its specification to be confident that it will meet your requirements.
For example, the development of software applications according to object-oriented principles is commonplace. The Unified Modelling Language (UML) has emerged to become an industry standard. Its success is partially due to its separation from any particular method for developing software. UML is available for anyone to include in his or her own method. Although a detailed history and description of UML is beyond the scope of this course, it is useful to know that it was derived from three of the most popular methods that were used in early projects that adopted object-oriented principles in software development. UML is intended to be a general purpose language for software development – it is not meant to be a complete language for modelling all aspects of all systems.
The UML is only one of many modelling languages that have been developed and which are in common use. They provide different viewpoints on the decomposition of problems. As a requirements analyst, you would need to explore other modelling notations, languages and techniques. For example, different types of model you might find useful are:
a model to identify the key stakeholders and their relationships to one another;
a model that shows how the intended product fits into its working environment (known as a context model);
a model which shows the parts of the product that come about because of a particular requirement (that is, one that shows the relationships between an agreed set of requirements and the eventual product, and enables you to trace the links between the requirements and the product – such a model is an essential component of working on projects).