Many significant computer systems will consist of a variety of software components located on a number of machines communicating via a variety of hardware and software mechanisms. A deployment model records how various components are to be mapped onto different machines and how they will communicate. This can be represented using a deployment diagram.
Activity 17 Modelling languages
Suppose you and a colleague used UML on a particular development project. What would be the consequences of introducing symbols or notations that were not defined in UML?
Such an extension would incur costs as well as offering potential benefits. The costs include the need to communicate the syntax and semantics of your new symbols or notation to other developers. The benefits include the ability to express concepts specific to your project that could be more meaningful in your context.
In the past, there have been many attempts to standardise modelling notations and languages. How might the choice of modelling language affect the maintenance of a software system?
Every time a new standard notation or language is defined, it allows new software systems to be built using that standard. It can only help with existing software retrospectively. For example, a developer might use the new standard to express a proposed change to the software.
There is no guarantee that an existing software system used any modelling language at all, let alone any agreed standard for one. Even if a standard was used, new staff arriving on the team for the purpose of maintenance might not know about it. Each variety of standard would affect the organisation of a component library. For example, if components using a particular standard were to be put in a library, the descriptions would be likely to require some maintenance as that standard changes over time.