ted in separate drawings for a number of cuts in that space. In the case of more logical (or abstract) types of systems, such as networks, computers, or software systems, the selection of views is not that obvious. Basically, the selection of views depends on the type of system that the mode- ling language targets. For example, UML (a language designed for software-sys- tem modeling) defines a large number of views, called "diagrams" (use-case diagram, class diagram, state diagram, activity diagram, object diagram, etc.). These are (hopefully) relevant and of interest to software system designers. A lan- guage for computer system modeling may define additional views that show other properties of the system, such as its system bus and connected hardware, memory organization, power supply subsystem, and mechanical design, including cabling. See The UML Reference Manual. Object Management Group, Framingham, MA. http://www.omg.org/. Cited 1998 1 Introduction to Network System Modeling Note however that there is no consensus between similar languages regarding which views should be supported for a particular system domain (the choice of views seems to be a means for competition between languages instead). Added-Value versus Common-Value Languages 1.2.1 General The previous chapter discussed how far you can get on the level of universal abstraction and/or by using common-value languages (e.g., languages for software and/or hardware system modeling). For productive modeling of systems within a particular system domain (e.g., networks) we must define more specialized lan- guages, i.e., modeling languages that are based on the concepts and relations that are unique to a domain (such as the relation "connection" and the entity "layer" used in network modeling, or the entity "exhauster" in modeling cars). This is SO because we neither want, should, nor can model the system in terms of its software and hardware components before it has to be implemented. We will refer to such modeling languages as added-value languages. It h