as been advocated (e.g., by UML proponents, see Chap. 1.2.2) that UML (a common-value language) should also be used for modeling systems in domains other than software. The fact that this is theoretically possible does not, however, imply that it is realistic and meaningful. Let's take a look at the implications of such an approach. Figure 1.1 shows the general paradigm for all modeling lan- guages. has attribute user-defined relation relevant Entity Entity has_attribute relevant Fig. 1.1 The model for all modeling languages The model describes the language as defining entities that may have any kind of user-defined relations, some of which may be attributes to entities (attributes are things that have a value range and no other relation to entities in the actual model). Some languages allow relations to have attributes as well. Common-value lan- guages normally define only two symbols, one for relations and attributes and one for entities. Some languages (e.g., the language component in AMLs for modeling resources) do not even use any symbol for entities, i.e., entities are just text strings. Since a common-value language cannot define symbols for entities and relations of added-value systems, most common-value languages realize that they must define a relation that tells which kind of entity is meant. This is the belongs_to_the_class 1.2 Added-Value versus Common-Value Languages relation mentioned previously. Looking for similarities cross many system domains reveals that another common aspect is to describe that something is part of some- thing else. Consequently the relation is_part_of is normally included in common- value languages. For example, UML includes both these types of general relations. Let's now use UML notations (as an example of a common-value language) for creating a very small part of an added-value model in the network system domain. This model (see Fig. 1.2) tells: Two nodes, N1 and N2, are interconnected by a route, R1. N1 includes a layer element L1. N2 includes a layer element L2. L1 and 