an added-value model. Although an AMLn model and a set of corresponding UML models are strictly related, there is no simple one-to-one relation between software elements and entities of an AMLn model. An AMLn entity is often realized by an aggregate of software elements, or by a blend of software and hardware elements. An added-value system belongs to a particular system domain (e.g., "network systems") with its own vocabulary, language, and to some extent also a de facto modeling notation. This is of immense value and importance to the actual system 1 Introduction to Network System Modeling domain. Since using a common-value language for modeling added-value systems means that this vocabulary and notations cannot be used, it is not just inconceiva- ble, but also counterproductive to use a common-value language for modeling added-value systems. The impact UML has had on the industry is partly an effect of that it tries to unify several pre-UML object-oriented languages, but mostly because it became standardized. UML has been much criticized for its complex and imprecise seman- tics. However, since it is a standard, it is regarded as something good: it is assumed that communication is easier when everybody talks the same language, pointless notational differences are avoided, and it is easier for the industry to hire people and for engineers to reuse their language knowledge. UML was designed for being a common-value language for modelling all kinds of software systems in an object-oriented way. Due to its wide-spread use today, some people believe that it can also become the modeling language for everything. We must therefore ask how UML deals with the problem of modeling different kinds of added-value systems. The UML solution to this problem is to extend the basic language with meta-language mechanisms (called "stereotypes" and "tags"), intended to allow users to include added-value semantics in their UML models. UML also assumes that such extensions are isolated in a UML "profile" for each system domain. Addin