Christine Hofmeister – författare

For more and more systems, software has moved from a peripheral to a central role, replacing mechanical parts and hardware and giving the product a competitive edge. Consequences of this trend are an increase in: the size of software systems, the variability in software artifacts, and the importance of software in achieving the system-level properties. Software architecture provides the necessary abstractions for managing the resulting complexity. We here introduce the Third Working IEEFlIFIP Conference on Software Architecture, WICSA3. That it is already the third such conference is in itself a clear indication that software architecture continues to be an important topic in industrial software development and in software engineering research. However, becoming an established field does not mean that software architecture provides less opportunity for innovation and new directions. On the contrary, one can identify a number of interesting trends within software architecture research. The first trend is that the role of the software architecture in all phases of software development is more explicitly recognized. Whereas initially software architecture was primarily associated with the architecture design phase, we now see that the software architecture is treated explicitly during development, product derivation in software product lines, at run-time, and during system evolution. Software architecture as an artifact has been decoupled from a particular lifecycle phase.

As the field of software architecture matures, several trends can be observed. The first is a recognition of the role of software architecture in all phases of software development. Whereas initially software architecture was primarily associated with the architecture design phase, we now see that software architecture is treated explicitly during development, product derivation in software product lines, at run-time, and during system evolution. A second trend is explicitly relating architecture design decisions to the requirements satisfied by these design decisions. Another trend is the increased use of quantitative assessment of software architectures. Finally, we see continued work on dynamic software architectures, with challenges arising from applications involving ubiquitous computing, mobile collaboration, and mobile computing. These trends can be seen in the papers collected in this volume, which represent some of the latest work by researchers and practitioners.The papers were presented at the 3rd Working IEEE/IFIP Conference on Software Architecture (WICSA3), which was held in conjunction with the 17th World Computer Congress, sponsored by the International Federation for Information Processing (IFIP), and which convened in Montreal, Quebec, Canada in August 2002. WICSA3 is a working conference, with paper sessions for presenting new results from research and practice, and working sessions for identifying new research directions. The papers were organized into five sessions. Two of these sessions, "Dynamic Software Architectures" and "Component-based Architectures", contain papers that focus on a particular architectural style and its properties. The remaining sessions, "Architecture Analysis", "Architecture Description" and "Architecture Reconstruction and Evolution", contain papers that describe new approaches and techniques related to software architecture.

For more and more systems, software has moved from a peripheral to a central role, replacing mechanical parts and hardware and giving the product a competitive edge. Consequences of this trend are an increase in: the size of software systems, the variability in software artifacts, and the importance of software in achieving the system-level properties. Software architecture provides the necessary abstractions for managing the resulting complexity. We here introduce the Third Working IEEFlIFIP Conference on Software Architecture, WICSA3. That it is already the third such conference is in itself a clear indication that software architecture continues to be an important topic in industrial software development and in software engineering research. However, becoming an established field does not mean that software architecture provides less opportunity for innovation and new directions. On the contrary, one can identify a number of interesting trends within software architecture research. The first trend is that the role of the software architecture in all phases of software development is more explicitly recognized. Whereas initially software architecture was primarily associated with the architecture design phase, we now see that the software architecture is treated explicitly during development, product derivation in software product lines, at run-time, and during system evolution. Software architecture as an artifact has been decoupled from a particular lifecycle phase.

Although the quality of a system’s software architecture is one of the critical factors in its overall quality, the architecture is simply a means to an end, the end being the implemented system. Thus the ultimate measure of the quality of the software architecture lies in the implemented system, in how well it satis?es the system and project requirements and constraints and whether it can be maintained and evolved successfully. In order to treat design as a science rather thananart,weneedtobeabletoaddressthequalityofthesoftwarearchitecture directly, not simply as it is re?ected in the implemented system. Therefore, QoSA is concerned with software architecture quality directly by addressing the problems of: – Designing software architectures of good quality – De?ning, measuring, evaluating architecture quality – Managing architecture quality, tying it upstream to requirements and do- stream to implementation, and preserving architecture quality throughout the lifetime of the system Cross-cutting these problems is the question of the nature of software archit- ture. Software architecture organizes a system, partitioning it into elements and de?ning relationships among the elements. For this we often use multiple views, each with a di?erent organizing principle.

Although the quality of a system’s software architecture is one of the critical factors in its overall quality, the architecture is simply a means to an end, the end being the implemented system. Thus the ultimate measure of the quality of the software architecture lies in the implemented system, in how well it satis?es the system and project requirements and constraints and whether it can be maintained and evolved successfully. In order to treat design as a science rather thananart,weneedtobeabletoaddressthequalityofthesoftwarearchitecture directly, not simply as it is re?ected in the implemented system. Therefore, QoSA is concerned with software architecture quality directly by addressing the problems of: – Designing software architectures of good quality – De?ning, measuring, evaluating architecture quality – Managing architecture quality, tying it upstream to requirements and do- stream to implementation, and preserving architecture quality throughout the lifetime of the system Cross-cutting these problems is the question of the nature of software archit- ture. Software architecture organizes a system, partitioning it into elements and de?ning relationships among the elements. For this we often use multiple views, each with a di?erent organizing principle.

Much of a software architect’s life is spent designing software systems to meet a set of quality requirements. General software quality attributes include scalability, security, performance or reliability. Quality attribute requirements are part of an application’s non-functional requirements, which capture the many facets of how the functional - quirements of an application are achieved. Understanding, modeling and continually evaluating quality attributes throughout a project lifecycle are all complex engineering tasks whichcontinuetochallengethe softwareengineeringscienti ccommunity. While we search for improved approaches, methods, formalisms and tools that are usable in practice and can scale to large systems, the complexity of the applications that the so- ware industry is challenged to build is ever increasing. Thus, as a research community, there is little opportunity for us to rest on our laurels, as our innovations that address new aspects of system complexity must be deployed and validated. To this end the 5th International Conference on the Quality of Software Archit- tures (QoSA) 2009 focused on architectures for adaptive software systems. Modern software systems must often recon guretheir structure and behavior to respond to c- tinuous changes in requirements and in their execution environment. In these settings, quality models are helpful at an architectural level to guide systematic model-driven software development strategies by evaluating the impact of competing architectural choices.

Much of a software architect’s life is spent designing software systems to meet a set of quality requirements. General software quality attributes include scalability, security, performance or reliability. Quality attribute requirements are part of an application’s non-functional requirements, which capture the many facets of how the functional - quirements of an application are achieved. Understanding, modeling and continually evaluating quality attributes throughout a project lifecycle are all complex engineering tasks whichcontinuetochallengethe softwareengineeringscienti ccommunity. While we search for improved approaches, methods, formalisms and tools that are usable in practice and can scale to large systems, the complexity of the applications that the so- ware industry is challenged to build is ever increasing. Thus, as a research community, there is little opportunity for us to rest on our laurels, as our innovations that address new aspects of system complexity must be deployed and validated. To this end the 5th International Conference on the Quality of Software Archit- tures (QoSA) 2009 focused on architectures for adaptive software systems. Modern software systems must often recon guretheir structure and behavior to respond to c- tinuous changes in requirements and in their execution environment. In these settings, quality models are helpful at an architectural level to guide systematic model-driven software development strategies by evaluating the impact of competing architectural choices.

The 2009 Symposium on Component-Based Software Engineering (CBSE 2009) was the 12thin a series ofsuccessful eventsthat havegrowninto the main forum for industrial and academic experts to discuss component technology. Component-based software engineering (CBSE) has emerged as the under- ing technology for the assembly of ?exible software systems. In essence, CBSE is about composing computational building blocks to construct larger building blocks that ful?ll client needs. Most software engineers are involved in some form of component-based development. Nonetheless, the implications of CBSE adoption are wide-reaching and its challenges grow in tandem with its uptake, continuing to inspire our scienti?c speculation. Component-based development necessarily involves elements of software - chitecture, modular software design, software veri?cation, testing, con?guration and deployment. This year’s submissions represent a cross-section of CBSE - search that touches upon all these aspects. The theoretical foundations of c- ponent speci?cation, composition, analysis, and veri?cation continue to pose research challenges. What exactly constitutes an adequate semantics for c- munication and composition so that bigger things can be built from smaller things? How can formal approaches facilitate predictable assembly through b- ter analysis? We have grouped the proceedings into two sub-themes that deal with these issues: component models and communication and composition. At the same time, the world is changing.