LAUSR

David Harel once said during a talk, “Bridges are made to stand and software is there to do.” This is a very appropriate analogy, because it shows that software is about behavior. As a consequence, many software modeling techniques supported by languages also allow the description of behavior. However, behavior usually is embedded in some structure. In object-oriented systems, this is typically the object, where a system is composed of many object instances, with the class as the describing artifact that defines the blueprint. In many forms of complex or distributed systems, the notion of “component” or “assembly” is also used in various forms to describe structure. At the programming level, there are usually only two forms of structural definitions. On one hand, we have a fully dynamic version, such as classes and the possibility to instantiate and link these classes in the form of objects. Furthermore, an object can be “rewired” dynamically with other objects building dynamic structures at run time. On the other hand, there is also a completely static definition, where all structural and connection aspects of components are defined at design time. This static structure is then replicated exactly as is and never changed at run time. For example, this has been the case in automotive, avionics and other safety critical systems. The strict static structure has advantages, because it allows us to better assess and analyze the behavior attached to the structure. It also has disadvantages, because it hampers reuse, dynamic updates, configurability, and other advantages that software engineers desire. Due to static versus dynamic structure of the system, we also (should) use very different modeling languages for those structures. For example, UML class diagrams model principal structures that allow various forms of dynamic instantiation. Correspondingly, UML object diagrams allow