consists of set of objects that interacts through a set of messages or method invocations. Throughout a system's lifetime objects gets created and garbage collected, thus a system is very dynamic in both its behaviour and con guration. Even with small or m

Structure and Interaction: Architectural AbstractionsNOSA'98 Department of Computer Science, Aalborg University Fredrik Bajers Vej 7E, DK-9220 Aalborg, Denmark E-mail: nowack@cs.auc.dkJune 29, 1998 Palle Nowack

concepts and notations for describing the essential aspects of a software architecture according to our perspective. 4. To develop elements reuse of Problem. An object-oriented software sys- of methodological support that enablesarchitec(parts of) already described software tem consists of set of objects that interacts through a set of messages or method invoca- tures on a design level. tions. Throughout a system's lifetime objects gets created and garbage collected, thus a system is very dynamic in both its behaviour and con guration. Even with small or medium sized The problem: object-oriented systems are comsystems the complexity caused by the number of plex and hard to understand. They are hard objects and method invocations makes it hard to describe. This implies that they are hard to to describe and reason about the system. Espe- reuse. cially it gets hard to understand how the di er- The obvious observation is that typical ent objects are related at run-time: the struc- object-oriented systems are inherently complex tures and collaboration patterns they partici- due to the number of objects they contain, and pate in. On the other hand these structures due to the number of events taking place durand collaborations are considered the hardest ing a system execution. However, it is also the parts to get right when designing new systems, case that object-oriented technology has certain hence it is desirable to reuse successful exam- characteristic properties enhancing this comples. Patterns 2] and frameworks 5] are exam- plexity. ples of object-oriented techniques that has been proposed to counter these problems. In our ap- Design Notations. When designing an proach we seek alternatives, prompted by the object-oriented system, certain design notafact that both patterns and frameworks describe tions are typically applied. From UML 8] we much more than just architecture. The devel- mention: class (object) diagram, component opment and application of patterns and frame- diagram, deployment diagram, interaction works is not our primary concern. (sequence and collaboration) diagram, state (activity) diagram, and use case diagram. We Approach Our interest in this problem has note certain characteristics of these notations: spawned the following set of goals: 1. To idenNotations for describing individual entities tify and analyse some of the main reasons for are strong. This goes for objects, classes the problem. 2. To de ne an interpretation and components. of the weakly understood concept software architecture that facilitates the understanding of Types (classes) are more easily described complex object-oriented systems. 3. To develop than instances (objects).

1 Essential Object-Oriented Design

2 Descriptions