g these mechanisms increase the complexity of an already complex language, of course. As a matter of fact, there is nothing but confusion to gain by trying to incorporate added-value semantics in a common-value language such as UML, not to mention the costs of maintaining the language. A recommen- dation increasingly advocated, therefore, is to scale UML down to a simpler and more general modeling level. The author's suggestion (since the birth of UML some seven years ago) is to divide UML into three general parts, and leave specific system domains to define their own added-value languages. These general parts 1. One part that covers the universal abstraction level we discussed previously (in UML, comprising concepts such as "class," "classification," "collaboration," and "association"). This part is useful for producing semantic diagrams, concep- tual models or entity-relation diagrams of almost anything. 2. A common-value part for software system modelling, with and without object oriented features. 3. A good meta-language (replacing UML's stereotypes, tags and profiles). Such a tool can be used for creating interpreters that can translate a model in an added- value language to UML models. Considering this perspective, the author has always regarded any effort to extend UML to also cover the modeling needs for network systems as a dead end. 2 2 This statement has to be made, since it explains why AMLn has been developed and why this book and its predecessor (see Muth (2001)), have been written. 1.2 Added-Value versus Common-Value Languages 1.2.3 The AMLn Process Context To develop network systems, producing network solutions, operating and maintain- ing networks are the core tasks of the telecom industry. These tasks are performed by a variety of businesses, traditionally called (telecom-) supplier, operator and standardization body. The roles these players take are not so distinct as the men- tioned tasks suggest, however. They also change over time: A supplier may restrict his role to deliver network componen