Ralf H. Reussner – författare

The goal of software engineering is to achieve high-quality software in a cost-effective, timely, and reproducible manner. Advances in technology offer reductions in cost and schedule, but their effect on software quality often remains unknown. The International Conferenceon the Quality of Software Architectures(QoSA 2005)focusedon software architectures and their relation to software quality, while the International Workshop on Software Quality (SOQUA 2005) mainly focused on quality assurance and more precisely on software testing. These events complement each other in their view on software quality. One of the main motivations for explicitly modelling software architectures is to enable reasoning on software quality. From a software engineering perspective, a so- ware architecture not only depicts the coarse-grained structure of a program, but also includes additional information such as the program's dynamics (i. e. , the ?ows of c- trol through the system) and the mapping of its components and connections to e- cution environments (such as hardware processors, virtual machines, network conn- tions, and the like).In this area, QoSA 2005is concernedwith researchand experiences that investigate the in?uence a speci?c software architecturehas on software quality - pects. Additionally,the developmentof methodsto evaluate software architectureswith respect to these quality attributes is considered to be an important topic. The quality - tributes of interest include external properties, such as reliability and ef?ciency, as well as internal properties, such as maintainability.

This book constitutes the thoroughly refereed post-proceedings of the International Dagstuhl-Seminar on Architecting Systems with Trustworthy Components, held in Dagstuhl Castle, Germany, in December 2004. Presents 10 revised full papers together with 5 invited papers contributed by outstanding researchers. Discusses core problems in measurement and normalization of non-functional properties, modular reasoning over non-functional properties, capture of component requirements in interfaces and protocols, interference and synergy of top-down and bottom-up aspects, and more.

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.

With the growingubiquity of computing systems it is essentialthat we canplace reliance on the services they deliver. This is particularly obvious and important in areas like aircraft avionics, global ?nancial transaction processing, or nuclear power plant control where human lives or large ?nancial values are at stake. But also the worldwide daily nuisances of computer viruses or data corruptions caused by crashing operating systems collectively impose high costs on society, which are beginning to become economically relevant. Within computer science, the termdependability has been introduced as a general term to cover all critical quality aspects of computing systems. Foll- ing the terminology of Laprie [26, 293], a system is dependable if trust can justi?ably be placed in the service it delivers (we will de?ne dependability and related terms more precisely later in this book). In the early days of computer science, researchers thought thatprogram correctness was the key to depe- ability meaning that a programalways terminates and satis?es its postcondition if it is started in a state where its precondition holds. Today we knowthat many other factors in?uence the well-functioning of a computer system.Examples of these factors are: - Hardware reliability: The occurrence of hardware faults, which cannot be neglected in critical systems. - Non-functional properties: The growingimportance of properties which c- not be expressed so easily as pre- and postconditions. As an example, c- sider the performance requirement that the averageresponse time should be below some value.

Researchers and professionals will find in this text the thoroughly refereed post-proceedings of the Third International Conference on the Quality of Software Architectures, QoSA 2007, held in Medford, MA, USA, in 2007. It was mounted in conjunction with the 10th International ACM SIGSOFT Symposium on Component-Based Software Engineering, CBSE 2007. The 13 revised full papers presented together with one keynote lecture were carefully reviewed and selected from 42 submissions.

Severalconferenceand workshopseriesarededicated to formalcomponent m- els and their use in veri?cation and quality prediction, such as FMCO, CBSE, FESCA,FACS andQoSA. There are a plethoraof componentmodels published, all with speci?c merits and bene?ts. However, most often these models are not used for comparison, as each research group concentrates on di?erent aspects of formal component modelling and quality prediction. Like the famous pro- 1 duction cell approach of the FZI, Karlsruhe, which has served since 1995 as a common example for di?erent embedded systems safety veri?cation, in this v- ume we de?ne a commonexample for modelling approachesof component-based systems. This Common Component Modelling Example enables the compa- bility of di?erent approaches, the validation of existing models, a better focus of research to tackle aspects less frequently dealt within the classi?cation of - isting models and approaches, an eased interchange of research ideas, as well as a simpli?ed and increased coordination and research collaborations to join complementary models and approaches. In this volume we de?ne the Common Component Modelling Example and present the models in current modelling and analysis approaches.The book concludes with comments on each modelling approach by an international jury. August 2007 Andreas Rausch Ralf Reussner Ra?aela Mirandola Franti? sek Pl' a? sil 1 Springer LNCS vol. 891. Organization The Dagstuhl research seminar for CoCoME (Common Component Modelling Example)modellingcontestispartofaseriesofseminarsorganizedwithsupport by the German Computer Science Society (Gesellschaft fu ..r Informatik,GI). It was held during August 1-3, 2007 at Schloss Dagstuhl, Germany, as event number 07312.

Models are used in all kinds of engineering disciplines to abstract from the various details of the modelled entity in order to focus on a speci?c aspect. Like a blueprint in civil engineering, a software architecture providesan abstraction from the full software system’s complexity. It allows software designers to get an overview on the system underdevelopmentandtoanalyzeitsproperties.Inthissense,modelsarethefoundation needed for software development to become a true engineering discipline. Especially when reasoning on a software system’s extra-functional properties, its software architecture carries the necessary information for early, design-time analyses. These analyses take the software architecture as input and can be used to direct the design process by allowing a systematic evaluation of different design alternatives. For example, they can be used to cancel out decisions which would lead to architecture - signs whose implementation would not comply with extra-functionalrequirements like performance or reliability constraints. Besides such quality attributes directly visible to the end user, internal quality attributes, e.g., maintainability, also highly depend on the system’s architecture. In addition to the above-mentioned technical aspects of software architecture m- els, non-technical aspects, especially project management-related activities, require an explicit software architecture model. The models are used as input for cost esti- tions, time-, deadline-, and resource planning for the development teams. They serve the project management activities of planning, executing, and controlling, which are necessary to deliver high-quality software systems in time and within the budget.

On behalf of the Organizing Committee we are pleased to present the p- ceedings of the 2008 Symposium on Component-Based Software Engineering (CBSE). CBSE is concerned with the development of software-intensivesystems from independently developed software-building blocks (components), the - velopment of components, and system maintenance and improvement by means of component replacement and customization. CBSE 2008 was the 11th in a series of events that promote a science and technology foundation for achieving predictable quality in software systems through the use of software component technology and its associated software engineering practices. Wewerefortunateto haveadedicatedProgramCommitteecomprisingmany internationallyrecognizedresearchersandindustrialpractitioners.Wewouldlike to thank the members of the Program Committee and associated reviewers for their contribution in making this conference a success. We received 70 subm- sions and each paper was reviewed by at least three Program Committee m- bers (four for papers with an author on the Program Committee). The entire reviewing process was supported by the Conference Management Toolkit p- vided by Microsoft. In total, 20 submissions were accepted as full papers and 3 submissions were accepted as short papers.