OOSA’98 - ECOOP'98 Workshop on Object-Oriented Software Architectures
|Title:||OOSA’98 - ECOOP'98 Workshop on Object-Oriented Software Architectures|
|Editor:||Jan Bosch, Helene Bachatene, Görel Hedin, Kai Koskimies|
|Organization:||Blekinge Institute of Technology|
|Department:||Dept. of Computer Science and Business Administration (Institutionen för datavetenskap och ekonomi)
Dept. of Computer Science and Business Administration S-372 25 Ronneby
+46 455 780 00
|Abstract:||Recently, one can recognize an increased awareness in the object-oriented research community with respect to the
role of software architectures. Examples of this can, among others, be found in object-oriented frameworks and design patterns. In the call for papers for the workshop, the following topics were identified where software architecture, patterns and frameworks should be studied in more detail:
· Building OO software architectures: How can design patterns, frameworks and components be included in the traditional object-oriented analysis and design? How are architecture constraints processed to build OO software architectures? Which techniques can help to build an OO architecture that supports reuse and is scalable?
· Language role in architecture: What is the role of a particular object-oriented language when designing an architecture?
· Architecture documentation: It has been suggested that design patterns can be used to document the design and rationale of an object-oriented architecture. How well does this work in practice?
· OO architectural styles: What is the relation between the architectural styles of Garlan and Shaw and OO design?
· Composition of architectures: Since object-oriented frameworks are an accepted technology within the software industry, the composition of two or more frameworks in an application occurs increasingly often.
The composition may be far from trivial and the problems that may appear as well as solutions should be investigated.
· Component technologies and architectures: Components are becoming key elements of reusable software development, and various technologies have emerged to support the specification of components and their use in unpredictable combinations (e.g. Java Beans). What are the relations between component-oriented and framework-oriented architectures? How do different component communication mechanisms affect the architecture?
· Architecture evaluation: Even though object-oriented frameworks claim to promote reuse and decrease
development cost, there are no techniques available to evaluate a concrete framework to determine whether it supports the functional and, especially, non-functional requirements for an application intended to be built based on the framework.
'Domain creep': Several examples of frameworks exist that, over time, are applied in domains differing from the originally intended domain. The framework then needs to be adapted to include the new domain as well, either as an integrated framework or as two versions. The problems associated with domain creep need to be identified and solution strategies identified.
· Experiences: Object-oriented software architectures are used out in industry and academia. However, often no explicit evaluation is performed and experiences are not captured and described objectively. The experiences, case studies and concrete systems and identify problems and weaknesses, but also successful structures and approaches need to be described.
· Tool support: A considerable need for architecture tool support exists. Examples are visualization, editing, design, and documentation of architectures.
The goal of the OOSA'98 workshop was to study the aforementioned topics, define the research area and state-of-the-art in more detail and to identify open problems. The call resulted in 15 papers accepted for the workshop. These
papers were divided over 5 sessions. Each session was divided in a presentation part, in which the authors briefly
presented their work, and a discussion part where the audience was able to discuss the presented and related ideas with the authors and each other. In the remainder of this workshop summary, the results from each session are