Search

Product-line architectures, i.e. a software architecture and component set shared by a family of products, represents a promising approach to achieving reuse of software. Several companies are initiating or have recently adopted a product-line architecture. However, little experience is available with respect to the evolution of the products, the software components and the software architecture. Due to the higher level of interdependency between the various software assets, software evolution is a more complex process. In this paper, we discuss the results of two case studies concentrating on the evolution of software assets in two swedish organizations that have employed the product-line architecture approach for several years. Based on these two cases, we discuss the commonalities, presented as categorizations of the evolution of the requirements, the software architecture and the software components, and also the differences between the two cases. Published in an edited form as: Mikael Svahnberg, Jan Bosch, Evolution in Software Product Lines: Two Cases, in Journal of Software Maintenance - Research and Practice 11(6), pp. 391-422, 1999.

The software architecture plays an important role in achieving a modifiable system, but few methods for modifiability analysis exist. In this paper, we propose an analysis method for software architecture modifiability that has successfully been applied in several cases. The method consists of five main steps, i.e. goal selection, software architecture description, scenario elicitation, scenario evaluation and interpretation.

Modifiability is an important quality for software systems, because a large part of the costs associated with these systems is spent on modifications. The effort, and therefore cost, that is required for these modifications is largely determined by a system’s software architecture. Analysis of software architectures is therefore an important technique to achieve modifiability and reduce maintenance costs. However, few techniques for software architecture analysis currently exist. Based on our experiences with software architecture analysis of modifiability, we have developed an analysis method consisting of five steps. In this paper we report on our experiences with this method. We illustrate our experiences with examples from two case studies of SAA of modifiability. These case studies concern a system for mobile positioning at Ericsson Software Techology and a system for freight handling at DFDS Fraktarna. Our experiences are related to each step of the analysis process. In addition, we made some observations on SAA of modifiability in general. Beskriver erfarenheterna från två fall studier. submitted for publication at HICSS conference.

Object-oriented application frameworks present one of the most successful approaches to developing reusable assets in industry, but developing frameworks is both difficult and expensive. Framework generally evolve to maturity through a number of iterations due to the incorporation of new requirements and better domain understanding. Since changes to frameworks have a large impact due to the effects on the applications build based on the asset, it is important to assess the maturity of a framework. Bansiya [3, 4] presents an approach to assessing framework maturity based on a set of design metrics and formulates four statements. In this paper, we present the results of a replicated case study of the framework maturity assessment approach. Our study subject consists of four successive versions of a proprietary black-box application framework. Our findings partly support the statements formulated in the original study, but differ in some places. The differences are discussed and explanations and argumentation provided.

Scenario profiles are used increasingly often for the assessment of quality attributes during the architectural design of software systems. However, the definition of scenario profiles is subjective and no data is available on the effects of individuals on scenario profiles. In this paper we present the design, analysis and results of a controlled experiment on the effect of individuals on scenario profiles, so that others can replicate the experiments on other projects and people. Both scenario profiles created by individuals and by groups are studied. The findings from the experiment showed that groups with prepared members proved to be the best method for creating scenario profiles. Unprepared groups did not perform better than individuals when creating scenario profiles.

Product-line architectures present an important approach to increasing software reuse and reducing development cost by sharing an architecture and set of reusable components among a family of products. However, evolution in product-line architectures is more complex than in traditional software development since new, possibly conflicting, requirements originate from the existing products in the product-line and new products that are to be incorporated. In this paper, we present a case study of product-line architecture evolution. Based on the case study, we develop categorizations for the evolution of requirements, the product-line architecture and product-line architecture components. Subsequently, we analyze and present the relations between these categorizations.

Product-line architectures present an important approach to increasing software reuse and reducing development cost by sharing an architecture and set of reusable components among a family of products. However, evolution in product-line architectures is more complex than in traditional software development since new, possibly conflicting, requirements originate from the existing products in the product-line and new products that are to be incorporated. In this paper, we present a case study of product-line architecture evolution. Based on the case study, we develop categorizations for the evolution of requirements, the product-line architecture and product-line architecture components. Subsequently, we analyze and present the relations between these categorizations.

Object-oriented framework technology has become a common reuse technology in object-oriented software development. As with all software, frameworks tend to evolve. Once the framework has been deployed, new versions of a framework cause high maintenance cost for the products built with the framework. This fact in combination with the high costs of developing and evolving an object-oriented framework make it important to have controlled and predictable evolution of the framework?s functionality and costs. We present three methods 1) Evolution Identification Using Historical Information, 2) Stability Assessment and 3) Distribution of Development Effort which have been applied to between one to three different frameworks, both in the proprietary and commercial domain. The methods provide management with information which will make it possible to make well-informed decisions about the framework?s evolution, especially with respect to the following issues; identification of evolution-prone modules, framework deployment, change impact analysis, benchmarking and requirements management. Finally, the methods are compared to each other with respect to costs and benefits.

Reuse of software has been one of the main goals of software engineering for decades. Reusing software is not simple and most efforts resulted in small reusable, black-box components. With the emergence of the object-oriented paradigm, the enabling technology for reuse of larger components became available and resulted in the definition of object-oriented frameworks. Frameworks attracted attention from many researchers and software engineers and frameworks have been defined for a large variety of domains. The claimed advantages of frameworks are, among others, increased reusability and reduced time to market for applications. Although several examples have shown these advantages to exist, there are problems and hindrances associated with frameworks that may not appear before their usage in real projects. The authors have been involved in the design, maintenance and usage of several object-oriented frameworks and based on the experiences from these projects, a number of problems related to frameworks are descr ibed. The problems are organised according to four categories, i.e. framework development, usage, composition and maintenance. For each category, the most relevant problems and experiences are presented. This paper may help software engineers to avoid the described problems, whereas researchers may try to address these topics in their research.

The conventional object-oriented paradigm provides client-server message passing as the primary means of interaction between objects. Although this is appropriate in situations where one objects requests a service from another object, there are other situations where one object, the observer, depends on state-changes or actions occurring at another object, the target. In those situations, the object-oriented paradigm requires the target object to notify the observer objects, despite the fact that the target object does not benefit from the interaction. This inverted interaction scheme leads to problems such as increased coupling and decreased understandability, maintainability and reusability of the resulting classes. In the analysis of object interactions one can identify four roles: the benefitor, the establisher, the sender and the receiver. The aforementioned problems result from the fact that in client-server interaction, the benefitor and the sender are not always the same object. To address this, we pr opose the notion of causal connections, an alternative interaction mechanism complementing the traditional client-server interaction. Two implementations of causal connections are described; one in the context of C++ and another using the layered object model. It is shown that causal connections solve the problems mentioned above.

Measurement systems are of increasing importance for manufacturing, due to high automation level of production processes. Although most measurement systems have much in common and are expensive to construct, these systems are often developed from scratch, hardly reusing the available designs and implementations. To address this, we have designed and implemented an object-oriented framework for the domain of measurement systems that can be used as the core of measurement systems. Evaluations of the framework show that it captures the main concepts in the domain and that the required extensions for individual applications are limited. In this paper, a number of example framework instantiations are presented. The lessons we learned during the framework design and an evaluation of the object-oriented modelling paradigm are presented.

Design patterns have proven to be useful for the design of object-oriented systems. The power of a design pattern lies in its ability to provide generic solutions that can be specialised for particular situations. The implementation of design patterns has received only little attention and we have identified two relevant problems associated with the implementation. First, the traceability of a design pattern in the implementation is often insufficient; often the design pattern is `lost'. Second, implementing design patterns may present significant implementation overhead for the software engineer. Often, a, potentially large, number of simple methods has to be implemented with trivial behaviour, e.g. forwarding a message to another object. In this paper, the layered object model (LayOM) is presented. LayOM provides language support for the explicit representation of design patterns in the programming language. LayOM is an extended object-oriented language in that it contains several components that are not pa rt of the conventional object model, such as states, categories and layers. Layers are used to represent design patterns at the level of the programming language and example layer types for four design patterns are presented. LayOM is supported by a development environment that translates LayOM code into C++. The generated C++ code can be used as any C++ code for the development of applications. An important aspect of LayOM is that the language itself is extensible. This allows new design patterns to be added to the language model.

The requirements on real-time systems are changing. Traditionally, reliability and predictability of, especially hard, real-time systems were the main requirements. This lead to systems that were stand-alone, embedded and static. Future real-time systems, but also current systems, still require reliability and predictability, but also distribution of the real-time system, integration with non real-time systems and the ability to dynamically change the components of the system at runtime. Traditional approaches to real-time system development have difficulties in addressing these additional requirements. Therefore, new ways of constructing real-time systems have to be explored. In this article, we develop a real-time object-oriented model that facilitates the requirements of flexibility without sacrificing the predictability, integration and dynamicity aspects.

During the last years, one can recognise a development towards application domain languages and extensible language models. Due to their extended expressiveness, these language models have considerable advantages over rigid general purpose languages. However, a complicating factor in the use of extensible language models are the conventional compiler construction techniques. Compilers constructed using these techniques often are large entities that are highly complex, difficult to maintain and hard to reuse. As we have experienced, these characteristics clearly complicate extending existing compilers. As a solution to this, we developed an alternative approach to compiler construction is proposed, based on object-oriented principles. The approach is based on delegating compiler objects (dcos) that provide a structural decomposition of compilers in addition to the conventional functional decomposition. The dco approach supports modularisation and reuse of compiler specifications, such as lexer and parser speci fications. We constructed an integrated tool set, letos, implementing the functionality of delegating compiler objects.

Large object-oriented systems have, at least, four characteristics that complicate object communication, i.e the system is distributed and contains large numbers, e.g. thousands, of objects, objects need to be reallocated at run-time and objects can be replaced by other objects in order to adapt to the dynamic changes in the system. Traditional object communication is based on sending a message to a receiver object known to the sender of the message. At linking or instantiation time, an object establishes its acquaintances through name/class-based binding and uses these objects through its life time. If this is too rigid, the software engineer has to implement the binding of objects manually using pointers. In our experiments we found the traditional acquaintance communication semantics too limited and we identified several problems, related to the reusability of objects and selection mechanisms, understandability and expressiveness. We recognised that it is important to separate a class or object's requirements on its acquaintances from the way an object selects and binds its acquaintances in actual systems. Based on this observation, we studied the required expressiveness for acquaintance handling and identified four relevant aspects: type and duration of binding, conditions for binding, number of selected objects and selection region for binding. To implement these aspects, we defined acquaintance layers as part of the layered object model. Acquaintance layers uniformly extend the traditional object-oriented acquaintance handling semantics and allow for the first-class representation of acquaintance selection and binding, thereby increasing traceability and reusability.

Traditionally, finite state machines based approaches are used in real-time object-oriented systems development for modelling the dynamic behaviour of an object. Finite state machines based approaches, however, suffer from several problems when used for modelling large and complex objects. As an alternative, an extended object model, LayOM, and an associated modelling approach is proposed aiming to solve the aforementioned problems and other problems related to object state.

Conventional compilers often are large entities that are highly complex, difficult to maintain and hard to reuse. In this article it is argued that this is due to the inherently functional approach to compiler construction. An alternative approach to compiler construction is proposed, based on object-oriented principles, which solves (or at least lessens) the problems of compiler construction. The approach is based on delegating compiler objects (DCOs) that provide a structural decomposition of compilers in addition to the conventional functional decomposition. The DCO approach makes use of the parser delegation and lexer delegation techniques, that provide reuse and modularisation of syntactical, respectively, lexical specifications.

In this paper, a number of problems of conventional automated software engineering support environments are described. These problems are related to the functional approach these environments take, the lack of initiative these systems exhibit and the causal connection gap between design information and the operational entity. As an alternative, we suggest an autonomous agent approach. Each artifact is modelled as an autonomous agent that is responsible for its own development. Artifacts are organised in specialisation hierarchies which can be traversed by agents. As a consequence, the methodology needs to be inverted, i.e. specified from the artifact's perspective rather than from the software engineer's perspective.

Conventional grammar specification and parsing is generally done in a monolithic manner, i.e. the syntax and semantics of a grammar are specified in one large specification. Although this might be sufficient in static environments, a modular approach is required in situations where the syntax or semantics of a grammar specification are subject to frequent changes. The problems with monolithic grammars are related to (1) dealing with the complexity, (2) extensibility and (3) reusability. We propose the concept of {\em parser delegation} as a solution to these problems. Parser delegation allows one to modularise and reuse grammar specifications. To achieve this, the notion of a production rule is specialised into (1) overriding, (2) extending and (3) delegating production rule types. To experiment with parser delegation, we have developed D-yacc, a graphical tool for defining grammars. Parser delegation has been applied for constructing a translator for an experimental language and is currently applied in other domains.

Programming languages and software engineering methods are highly related in that both are images of an underlying paradigm. In this paper we investigate the role of the paradigm, the language model and the software development method and define requirements on each of the three concepts. Subsequently, we describe the {\em layered object model}, an extended object model which allows for first-class representation of relations between objects and constraints on the behaviour of an object, and discuss how it achieves {\em paradigm extensibility}, i.e. extensibility of the paradigm and the supporting language model.

Although object-oriented methods make extensive use of relations between objects, these relations, other than inheritance and part-of, can not directly be represented by the conventional object-oriented model. This means that relations which are identified during analysis and design have to be implemented on top of the object model, i.e. by using method code and message passing, rather than by expressing relations directly within in the model. It would be beneficial if the object-oriented model would support the specification of all relevant types of relations within the model, including application-domain specific relation types. Therefore, we propose a mechanism, implemented in LayOM -- an extended object model, that supports the specification of all types of relations between objects within the model as components of the object model. In addition, an approach for identifying and specifying application-domain relation types is presented.

WCOP 2000, held in conjunction with ECOOP 2000 in Sophia Antipolis, France, was the fifth workshop in the successful series of workshops on component-oriented programming. The previous workshops were held in conjunction with the respective ECOOP conferences in Linz, Austria, Jyväskylä, Finland, Brussels, Belgium and Lisbon, Portugal. WCOP96 had focused on the principal idea of software components and worked towards definitions of terms. In particular, a high-level definition of what a software component is was formulated. WCOP97 concentrated on compositional aspects, architecture and gluing, substitutability, interface evolution, and non-functional requirements. WCOP98 had a closer look at issues arising in industrial practice and developed a major focus on the issues of adaptation. WCOP'99 moved on to address issues of component frameworks, structured architecture, and some bigger systems built using components frameworks. The topics for WCOP 2000 focused on component composition, validation and refinement and the use of component technology in the software industry.

This report presents the results of a course on software product lines. The assignment in the course was to develop a software product line. . During the course, the students had to develop the following artifacts in groups: product line architecture, component designs, product derivations, modifiability assessment and a prototype. The results of the course are described in this report

WCOP 2000, held in conjunction with ECOOP 2000 in Sophia Antipolis, France, was the fifth workshop in the successful series of workshops on component-oriented programming. The previous workshops were held in conjunction with the respective ECOOP conferences in Linz, Austria, Jyväskylä, Finland, Brussels, Belgium and Lisbon, Portugal. WCOP96 had focused on the principal idea of software components and worked towards definitions of terms. In particular, a high-level definition of what a software component is was formulated. WCOP97 concentrated on compositional aspects, architecture and gluing, substitutability, interface evolution, and non-functional requirements. WCOP98 had a closer look at issues arising in industrial practice and developed a major focus on the issues of adaptation. WCOP'99 moved on to address issues of component frameworks, structured architecture, and some bigger systems built using components frameworks. The topics for WCOP 2000 focused on component composition, validation and refinement and the use of component technology in the software industry.

This report presents the results of a course on software product lines. The assignment in the course was to develop a software product line. . During the course, the students had to develop the following artifacts in groups: product line architecture, component designs, product derivations, modifiability assessment and a prototype. The results of the course are described in this report

WCOP'99 is the fourth event in a series of highly successful workshops, which took place in conjunction with every ECOOP since 1996, focusing on the important field of component-oriented programming (COP). COP has been described as the natural extension of object-oriented programming to the realm of independently extensible systems. Several important approaches have emerged over the recent years, including CORBA, COM (COM+, DCOM, ActiveX, DirectX, ...), JavaBeans. A component is not an object, but provides the resources to instantiate objects. Often, a single component will provide interfaces to several closely related classes. Hence, COP is about architecure and packaging, besides interoperation between objects. After WCOP'96 focused on the fundamental terminology of COP, the subsequent workshops expanded into the many re- lated facets of component software. WCOP'99 shall emphasis architectural design and construction of component-based systems beyond ad-hoc reuse of unrelated components. To enable lively and productive discussions, the workshop will be limited to 25 participants. Depending on the actually submitted positions papers, the workshop will be organized into three or four subsequent mini-sessions, each initiated by a presentation of two or three selected positions and followed by discussions. Instead of splitting the workshop into task forces, it is intended to provoke lively discussion by preparing lists of critical questions and some, perhaps provocative, statements (to be used on demand). Position papers will be formally reviewed, each by at least two independent reviewers. As an incentive for submission of high quality statements, the best position statements will be combined with transcripts of workshop results and published.

The articles in this research report are the result of the efforts of the students of the master course on advanced object-oriented concepts. The course is part of the software engineering master year at the University of Karlskrona/Ronneby. During the course, the students were introduced to about 20 advanced object-oriented concepts, such as delegation, prototype-based languages, reflection, typing, real-time and concurrent object-oriented languages, dynamic binding, garbage collection, delegating compiler objects, design patterns and frameworks. Rather than passively being present at the classes and listening to the lectures, the students were required to themselves present these new concepts. This required considerable amounts of active searching and independent knowledge acquisition from the students that had, subsequently, to be converted in a one to two hour lecture. The lecture was followed by a discussion involving all students. The organisation of the course lead to a very effective learning of the various concepts that were part of the course. Another, very important, aspect of the course was that each student was required to write a research paper on a subject within the object-oriented domain. One requirement on the article was that it had to be problem-oriented in that it had to identify a problem and subsequently propose a solution to the problem. Rather than writing a literature survey, the student was required to write a paper that contained a (possibly minor) scientific contribution to the object-oriented domain. During the course, writers workshops were organised during which students, in groups, read and commented on papers written by their colleagues. The results of this part of the course are gathered in this research report. Fourteen student research papers form the contents of this research report. The articles have been classified into four categories, i.e. reuse and evolution, object-oriented languages, software design and object-oriented frameworks. The reader will recognise, perhaps surprisingly, that many of the papers are strongly founded in practical experiences and address relevant technical problems that our software industry has to deal with on day to day basis. The explanation for this can be found in the project-oriented organisation of the software engineering study program and the strong relation to the local software industry. During the first three years of their studies, the students have experienced the real problems in software engineering and during the master year the students learn to reflect on these problems and to develop solutions. At the end of the course for this year, I am happy that I can conclude that the goals of the course have been more than achieved. Many of the lectures were of very good quality, the participation in the discussions was more than satisfactory and the research papers are very worthwhile reading. The course required from the students, but also from the teacher, a considerable effort, that, almost certainly, resulted in a highly valuable learning experience. For my part, I look with great satisfaction back on the course and hope for many successful repetitions in the future.

Software architecture research is receiving increased amounts of attention in academia as well as in industry. Therefore, in 1997 the initiative was taken by the University of Karlskrona/Ronneby to start a network of academic and industrial partners, SARIS, interested in various aspects of software architecture. The intention of the SARIS (Software Architec-ture Research in Sweden) network is to bring together partners with common interests, exchange experiences through the mailing list and regular meetings and to develop cooperation wherever possible. The term software architecture is somewhat overloaded, but most experts agree that it primarily refers to the top-level decomposition of a system into its main components and the interaction between these components. A second aspect is that software architecture design is primarily concerned with the non-functional requirements (also properties or quality attributes) of software systems, rather than their functionality. Attributes can be categorized into operational attributes, such as efficiency, reliability, robustness and cor-rectness, and development attributes, such as maintainability, flexibility and reusability. The architecture structures the functionality required from a system such that the non-functional requirements are fulfilled.

The articles in this research report are the result of the efforts of the students of the master course on advanced object-oriented concepts. The course is part of the software engineering master year at the University of Karlskrona/Ronneby. During the course, the students were introduced to about 20 advanced object-oriented concepts, such as delegation, prototype-based languages, reflection, typing, real-time and concurrent object-oriented languages, dynamic binding, garbage collection, delegating compiler objects, design patterns and frameworks. Rather than passively being present at the classes and listening to the lectures, the students were required to themselves present these new concepts. This required considerable amounts of active searching and independent knowledge acquisition from the students that had, subsequently, to be converted in a one to two hour lecture. The lecture was followed by a discussion involving all students. The organisation of the course lead to a very effective learning of the various concepts that were part of the course. Another, very important, aspect of the course was that each student was required to write a research paper on a subject within the object-oriented domain. One requirement on the article was that it had to be problem-oriented in that it had to identify a problem and subsequently propose a solution to the problem. Rather than writing a literature survey, the student was required to write a paper that contained a (possibly minor) scientific contribution to the object-oriented domain. During the course, writers workshops were organised during which students, in groups, read and commented on papers written by their colleagues. The results of this part of the course are gathered in this research report. Fourteen student research papers form the contents of this research report. The articles have been classified into four categories, i.e. reuse and evolution, object-oriented languages, software design and object-oriented frameworks. The reader will recognise, perhaps surprisingly, that many of the papers are strongly founded in practical experiences and address relevant technical problems that our software industry has to deal with on day to day basis. The explanation for this can be found in the project-oriented organisation of the software engineering study program and the strong relation to the local software industry. During the first three years of their studies, the students have experienced the real problems in software engineering and during the master year the students learn to reflect on these problems and to develop solutions. At the end of the course for this year, I am happy that I can conclude that the goals of the course have been more than achieved. Many of the lectures were of very good quality, the participation in the discussions was more than satisfactory and the research papers are very worthwhile reading. The course required from the students, but also from the teacher, a considerable effort, that, almost certainly, resulted in a highly valuable learning experience. For my part, I look with great satisfaction back on the course and hope for many successful repetitions in the future.

WCOP'99 is the fourth event in a series of highly successful workshops, which took place in conjunction with every ECOOP since 1996, focusing on the important field of component-oriented programming (COP). COP has been described as the natural extension of object-oriented programming to the realm of independently extensible systems. Several important approaches have emerged over the recent years, including CORBA, COM (COM+, DCOM, ActiveX, DirectX, ...), JavaBeans. A component is not an object, but provides the resources to instantiate objects. Often, a single component will provide interfaces to several closely related classes. Hence, COP is about architecure and packaging, besides interoperation between objects. After WCOP'96 focused on the fundamental terminology of COP, the subsequent workshops expanded into the many re- lated facets of component software. WCOP'99 shall emphasis architectural design and construction of component-based systems beyond ad-hoc reuse of unrelated components. To enable lively and productive discussions, the workshop will be limited to 25 participants. Depending on the actually submitted positions papers, the workshop will be organized into three or four subsequent mini-sessions, each initiated by a presentation of two or three selected positions and followed by discussions. Instead of splitting the workshop into task forces, it is intended to provoke lively discussion by preparing lists of critical questions and some, perhaps provocative, statements (to be used on demand). Position papers will be formally reviewed, each by at least two independent reviewers. As an incentive for submission of high quality statements, the best position statements will be combined with transcripts of workshop results and published.

Software architecture research is receiving increased amounts of attention in academia as well as in industry. Therefore, in 1997 the initiative was taken by the University of Karlskrona/Ronneby to start a network of academic and industrial partners, SARIS, interested in various aspects of software architecture. The intention of the SARIS (Software Architec-ture Research in Sweden) network is to bring together partners with common interests, exchange experiences through the mailing list and regular meetings and to develop cooperation wherever possible. The term software architecture is somewhat overloaded, but most experts agree that it primarily refers to the top-level decomposition of a system into its main components and the interaction between these components. A second aspect is that software architecture design is primarily concerned with the non-functional requirements (also properties or quality attributes) of software systems, rather than their functionality. Attributes can be categorized into operational attributes, such as efficiency, reliability, robustness and cor-rectness, and development attributes, such as maintainability, flexibility and reusability. The architecture structures the functionality required from a system such that the non-functional requirements are fulfilled.

The report is the result of a course for PhD students on software architecture. An overview of the state of the art is presented. Discussed topics include describing, evaluating and designing architectures, product-line architectures, object-oriented frameworks and component-based software engineering.

Software architecture research is receiving increased amounts of attention in academia as well as in industry. Therefore, in 1997 the initiative was taken by the University of Karlskrona/Ronneby to start a network of academic and industrial partners, SARIS, interested in various aspects of software architecture. The intention of the SARIS (Software Architecture Research in Sweden) network is to bring together partners with common interests, exchange experiences through the mailing list and regular meetings and to develop cooperation wherever possible. The term software architecture is somewhat overloaded, but most experts agree that it primarily refers to the top-level decomposition of a system into its main components and the interaction between these components. A second aspect is that software architecture design is primarily concerned with the non-functional requirements (also properties or quality attributes) of software systems, rather than their functionality. Attributes can be categorized into operational attributes, such as efficiency, reliability, robustness and cor-rectness, and development attributes, such as maintainability, flexibility and reusability. The architecture structures the functionality required from a system such that the non-functional requirements are fulfilled.

The report is the result of a course for PhD students on software architecture. An overview of the state of the art is presented. Discussed topics include describing, evaluating and designing architectures, product-line architectures, object-oriented frameworks and component-based software engineering.

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 presented.

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 presented.

Software architecture research is receiving increased amounts of attention in academia as well as in industry. Therefore, in 1997 the initiative was taken by the University of Karlskrona/Ronneby to start a network of academic and industrial partners, SARIS, interested in various aspects of software architecture. The intention of the SARIS (Software Architecture Research in Sweden) network is to bring together partners with common interests, exchange experiences through the mailing list and regular meetings and to develop cooperation wherever possible. The term software architecture is somewhat overloaded, but most experts agree that it primarily refers to the top-level decomposition of a system into its main components and the interaction between these components. A second aspect is that software architecture design is primarily concerned with the non-functional requirements (also properties or quality attributes) of software systems, rather than their functionality. Attributes can be categorized into operational attributes, such as efficiency, reliability, robustness and cor-rectness, and development attributes, such as maintainability, flexibility and reusability. The architecture structures the functionality required from a system such that the non-functional requirements are fulfilled.

The work done concerning object oriented frameworks is in its beginning and most of it tend to concentrate on object oriented frameworks that has been built and how these were built and documented. But there is one question that remains unsatisfactorily answered, i.e. what is a object oriented framework? This is still one of the most common questions and there still exists no answer that is generally agreed on. In this paper some important characteristics of object oriented frameworks are presented, existing definitions discussed and an improved definition is suggested.

The work done concerning object oriented frameworks is in its beginning and most of it tend to concentrate on object oriented frameworks that has been built and how these were built and documented. But there is one question that remains unsatisfactorily answered, i.e. what is a object oriented framework? This is still one of the most common questions and there still exists no answer that is generally agreed on. In this paper some important characteristics of object oriented frameworks are presented, existing definitions discussed and an improved definition is suggested.