L2 communicate according to the protocol P1. Legend: entity Route user-defined relation belongs_to_the_type/class is_part_of Protocol Layer Switched specific. element route Classes and types Instances connects_to has attribute protocol connects_to Fig. 1.2 An entity-relation diagram of a network system statement Using a common-value language implies that added-value concepts (here node, route, layer element, protocol, protocol specification and connects_to) must be defined by the modeller by including specific type and class entities, and by textual annotations of user-defined relations. The model also demonstrates that the mean- ing of the statement we model is not given by concepts defined by the common- value language, but (at best) by the added-value model. In other words, the mean- ing with the model is (to a part) to model meaning. The fact that common-value languages use very few symbols may make the impression that they are easy to use and give intelligible models. The model in Fig. 1.2 clearly shows that this is a very deceptive appearance. It does not take too much imagination to see that modeling a larger part of a network system, with all its domain-specific entities, relations, and attributes in a common-value language would create a model that would be extremely complex and hard to understand (and therefore useless). The model would be cluttered with class and type objects, class and part relations, and user-defined annotations that exist only to define what type of entity, relation and attribute is meant. This is definitely something we do not need when modeling a system that is complex in itself. Therefore let's look at how the same statement is modeled in AMLn (see Fig. 1.3). 1 Introduction to Network System Modeling Legend: functional element switched route protocol L1,L2,N1,N2,P1,R1 identifiers or names Fig. 1.3 The AMLn model that corresponds to Fig. 1.2 We leave to readers who work in the networking industry to judge which of the models in Figs. 1.2 and 1.3 they prefer. Here we will only summ