1 Essential Object-Oriented Design(3)

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

gramming languages and conceptual programming 6]. The model in Figure 1 can be applied to describe conventional object-oriented technology. A class describes a concept exempli ed by a set of phenomena described by a set of objects. A class can be composed of (references to) other class descriptions, and classes can be parts of generalization hierarchies.3.1 Basic Model

component types can be related in generalization hierarchies. following mechanisms and situations: object creation, object deletion, and method invocation (message sending). Events are classi ed by event types. An event type describes the participating component roles. Event types can be part of generalization and aggregation hierarchies. In this way a single event can be an abstraction over a large number of method invocations or object creations. When choosing the events and the components for the description of a system it is important that the selections support each other. I.e. that the events makes sense on the chosen components, and vice versa. The chosen components and events are the common abstract basis for the description of the system architecture.

Events An event is an abstraction over the

Classes and objects are the fundamental constructs of conventional object-oriented technology. In Figure 2 we illustrate how four additional concepts, architectural abstractions, can be applied to describe an object-oriented system. Other examples of architectural abstractions include patterns and frameworks 4], 7].Interactions Structures

software. Components and events are as abstractions the foundation for the formulation of the ab- Interactions An interaction type describes a set of event roles that are related through a temstractions structures and interactions.

component roles (quali ed by component types) that are related through a structural relation. Events Components Possible structural relations include encapsulation and association. The di erent structural relations puts di erent constraints on the possible events that the components can participate in. A composite component has an associated internal structure. The architecture of a system (which can also be considered a comObject-Oriented System ponent) can be partly described by a set of corresponding Figure 2: We form abstractions over software sys- structure instances and can be part of structure types. Structure types tems (wide arrows). These abstractions can be ap- tion and generalization hierarchies. aggregaplied to describe and understand (thin arrows)

the poral relation. Temporal relations include sequence, alternation, concurrency, and iteration. A composite event has an associated internal interaction description. The architecture of a system can be partly described by a set of interaction instances and corresponding interaction types. Interaction types can be part of aggregation and generalization hierarchies.

Structures A structure type describes a set of

merely a focus point for interactions and structures. A component is an abstraction over an object. A set of components can be categorised and described as a component type. A component type identi es a set of in- and out-ports through which a component communicates. In- 3.2 Persistent and Transient ports describes all the events that a component Structures can receive and react upon. Out-ports describes all the events that a component can initiate and The structure of a system is static to some deemit. Component types can be applied in the gree{ it provides the frame for the interactions description of composite component types, and among the components. However sometimes 3

Components In our model, a component is

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

events (in the interactions) in the system im- The next steps in our approach: plies that the structure breaks down, changes or Further elaborate on the relations between extends. Structure is related with interactions the four concepts in our model. in two ways: some interactions are dominating Develop notation for expressing types and the structure, while other interactions are dominstances of all four concepts. inated by the structure. During a system's life time structures between Apply the model and notation in the decomponents are created and deleted. Composcription of examples: selected patterns, nents are created, introduced into structures, frameworks, architectural styles and appliremoved from structures, and deleted. cations. In an object-oriented system references to objects are passed around as part of messages and We thank Eydun Eli Jacobsen and Bent method invocations. This makes the structure Bruun Kristensen for interesting and inspiring very dynamic, and we term this type of struc- discussions on this and other architecture reture transient. Other structures are of a more lated topics. permanent character: object attributes being assigned statically to the same object is an example. Aggregated objects could be another example. This means that varying degrees of per- 1] Buschmann, F., Meunier, R., Rohnert R., sistent structures exist. Sommerlad P., Stal, M.: Pattern-Oriented Because we aim to describe structural aspects Software Architecture: A System of Patof a system that can be interpreted as the\arterns. John Wiley& Sons, 1996. chitecture" of the system, we are interested in describing structural changes over time from two 2] Gamma, E., Helm, R., Johnson, R.E, Vlissides, J.: Design Patterns Elements of perspectives: What interactions cause structure Reusable Object-Oriented Software, Addichanges? Wha

t abstractions can be made over son Wesley, 1995. both structure and time? 3] Garlan, D., Shaw, M.: Software Architecture Perspectives on an Emerging Discipline. Prentice Hall, 1996. In this paper we have argued that a software 4] Jacobsen, E.E., Nowack, P: Frameworks architecture concept can be applied to enhance and Patterns: Architectural Abstracthe possibilities for understanding and reusing tions. Accepted for publication in Object(parts of) complex object-oriented systems. ExOriented Application Frameworks (Moamples of systems include applications, framehamed E. Fayad, Douglas Schmidt, and works, architectural styles, and patterns. This Ralph Johnson, editors), John Wiley, New perspective de nes the architecture of a sysYork, NY, 1998. tem as a collection of structure and interaction descriptions. More precisely the descriptions 5] Johnson, R.E., Foote, B.: Designing Reusable Classes. Journal of Objectcontains a set of structure and interactions inOriented Programming, 2(1), 1988. stances together with a set of structure and interaction types. Structure and interaction are 6] Kristensen, B.B., sterbye, K.. Roles: de ned in terms of the abstractions component Conceptual Abstraction Theory& Practiand event. It is argued that the speci cation and cal Language Issues. Theory and Practice description of structures and interactions would of Object Systems, 1996. ll a gap in the contemporary design notations and implementation languages which tend to fo- 7] Kristensen, B.B.: Architectural Abstractions and Language Mechanisms. Proceedcus on object-centric mechanisms. ings of Asia Paci c Software Engineering We have described in general how structures Conference (AISEC'96), 1996. and interactions mutually a ect each other. Similarly component and events are related by 8] Rational. Uni ed Modelling Language the fact that components communicate through v.1.1. . certain events.

References

4 Conclusion