software system modeling (e.g., UML, the Unified Model- ling Language²), but not tools for modeling network systems. Systems modeling has been a rather hot topic for quite a few years. The wide spread use of UML is one result. UML is a standard and therefore perceived by many designers as a modeling language for everything. So, why did I have to develop another? The answer is simply that there is no such thing as "a language for everything" since formal languages are context-dependent. Different languages are needed in different application domains if they are to be useful. Every domain needs to describe its systems in terms of concepts and design rules that are charac- teristic for that domain. For example, you might be able to describe an aircraft sys- tem using the terminology and symbols of the telecom domain, but (obviously) nobody would understand anything. A language such as UML can however play an important role for modeling system types (component systems) that exist in many UML has been standardized by OMG in an effort to unify diverse object oriented languages for modeling software systems Preface other system types, such as software systems and hardware systems (electronic devices). Viewing a network system as consisting of such component systems is something you do first when the standardization phase and the initial phases of an implementor's system development is passed. We may therefore regard UML as a common-value language in relation to added-value languages, such as the one pre- sented in this book. To be useful, a common-value language must be completely transparent to the concepts and semantics of any other system domain, i.e., the model cannot tell you anything of the purposes with the added-value system. It only tells you what its software and hardware components are and how to connect them when building an added-value system (in our case, an operator network). An added-value language, on the other hand, is built on the concepts and architectural principles of a specific system domain (e.g.