eractions between objects, requesting operations and responding to requests (sometimes described as "protocols" between objects). Object oriented (OO) modeling languages in use today have, in reality, only been developed and used for software system modelling. A well known language of this kind is the Unified Modeling Language (UML). 1 The fact that such lan- guages are constrained to systems that have a single object type (which is a piece of software or data), makes it possible to pre-define a larger number of relations than just is_part_o and belongs_to_the_class. For example, software objects exist both as classes, types and as instances, where an instance is related to a type by an is_an_instance_of relation. Most operating systems also offer connectivity rela- tions between functional elements, which can be modeled as an is_connected_to relation, etc. OO modeling languages were preceded by OO software design languages, such as Smalltalk, Ada, Eiffel, C++, and Java. Since you can express almost the same thing in these languages as you do in UML and similar modeling languages, the lat- ter tend to be merely graphical versions of OO design languages. The extra value they give, besides a graphical notation and concepts for the universal abstraction level, is when diverse packaging concepts are added that make the model useful in managing the overall complexity of a large software system. When modeling languages have the ambition to be useful beyond the level of universal abstraction and/or include behavior modeling, the complexity of the models normally require the language to define some kind of views. One distin- guishing aspect between languages is therefore their choice of views. Some lan- guages that are called "modeling language" offer no views at all, and should therefore be called "drawing languages" instead. A view is the picture you get of a system model when looking at it from a particular "angle." For example, a mechan- ical design exists in 3-dimensional space and the model of it is normally presen