A practical guide to designing and implementing software architectures.

Jan Bosch is Professor of Software Engineering at the University of Karlskrona/Ronneby, Sweden.

Preface Software has entered virtually all parts of society, ranging from basic utilities such as electricity generation and distribution and telecommunications to personal devices such as mobile phones and cars. Whereas traditionally the competitiveness of a company was defined by its ability to construct and maintain mechanical systems, and later on hardware systems, currently it is the ability to develop and evolve software systems efficiently and effectively which is central. These developments imply an increasing level of responsibility on the software engineering community. With the increase in integration between software systems, failures in one system may have effects which extend beyond the system itself and affect other systems, with possible consequences in the physical world that were not conceivable even a decade ago. On the other hand, software has allowed for unprecedented flexibility and agility in organizations and systems that have many positive effects on society, organizations and individuals. Despite the success of software, software engineering still has many challenges to address. In particular, the following primary objectives can be identified: to drastically decrease the cost of developing and maintaining software and the time-to-market of new software products and to improve (and manage) the quality attributes of software products. Although software systems have always had an architecture, during the last decade the notion of an explicit software architecture has been recognized as being important. One can identify three purposes for an explicitly defined software architecture. First, it allows for early assessment of and design for the quality attributes of a software system. Second, the software architecture represents a concrete artefact that can be used for discussions with and between stakeholders. Finally, it defines the architectural components and their interactions, which facilitates reuse in general and software product lines in particular. This book is concerned with two aspects of software architecture: the design of software architectures and software product lines. In Part I of the book, we present our software architectural design method. This method has been developed and refined through our involvement in a number of software architecture design projects. The three main projects are described as case studies in this book. In Part II of the book, we present the notion of software product lines and the process of adopting and evolving a product-line approach to software development. Again, our approach has been shaped by the co-operation projects that we have had with a number of companies which use software product lines. Consequently, the contents of Part II are shaped by the experiences from these co-operation projects. Foreword Our nice little puppy has really grow and now needs a doghouse. A few boards, some two-by-fours and leftover cedar shingles, a handful of nails, and voil#xE0;! Our puppy has a brand new home. Now, let''s say you didn''t get it quite right at first, so you made some adjustments along the way, then even more a week later. You could even imagine applying some of these techniques to your house if, like me, you live in an area where most houses are made of wood, but you''d be hard pressed to make a living at it. Some of the fixes along the way may have drastic consequences, or may violate the building codes. Now try taking this ''build and fix'' approach to a sky-scraper, and I''m afraid you''d have to completely rethink your strategy.1 If you think of the parallel between construction and software development, the fact is that most software today is still developed and built according to the ''code and fix'' approach - by writing the code, summarily testing it, and shipping it to the customer to use, or to finish the testing. Also in the software world, all doghouses and most log cabins have already been built, and now companies are mostly tackling the sky scrapers. The ''code and fix'' approach does not work and development organizations realize that they need to engineer their software intensive systems.2 They go from developing ''one-off'' systems, to multiple instances, to families of systems or product lines, to leveraging their efforts, as you cannot build these sky-scrapers from scratch all the time. This is where software architecture comes into play. All software intensive systems have an architecture, but, unlike building architecture, this architecture is often hidden, fuzzy, and seems to be produced more by black magic or by accident than by human intent or design. It was only five years ago that Mary Shaw and David Garlan published their book Software Architecture: Perspectives on an Emerging Discipline3 and although this discipline has made some progress, not much has been published since. It has been slow to emerge as a mature software engineering discipline. There are three main aspects where software architecture needs to make progress to establish itself: n Architecture representation - By defining how to represent the architecture of software intensive systems and reaching some industry-wide consensus, we''ll be able to communicate architectural designs or blueprints, to reason about them, and to evaluate and compare architectures. This is where the future standard IEEE 1471 on architecture representation will fill a void. This is also a place where the Unified Modeling Language (UML) has a role to play as a uniform notation for architectural blueprints. n Architectural process - By defining the methods to design and assess architectures, focusing on quality attributes (the non-functional or ''afunctional'' requirements), and addressing them in a systematic fashion. The architectural design approaches need to be supported by a matching organization that takes architecture as a key function, and understands its value and how it flows into other areas, such as planning, project management, product management, design or deployment. n Architectural assets - By collecting, cataloging, and presenting fragments of successful architectures, or even complete architectures, whether they are called patterns, frameworks, components, mechanisms or standards, we will enable software development organizations to design architecture without re-inventing the wheel. This will also foster better communication across the industry, allowing practitioners to simply name the pattern rather than describing it completely. However, as architectures are usually prized company assets, many companies are reluctant to exhibit their architectural assets in a public forum. They''d rather patent them or carefully hide them in their products. In this context, we really welcome this book Design and Use of Software Architectures, which represents a significant step forward in this discipline. Jan Bosch actually contributes to all three aspects - representation, process, and assets - with a good mix between an academic perspective and an industrial perspective. Most of Jan Bosch''s contribution is on the second point, though: the architectural design process, which is certainly the topic closest to my interests and daily concerns. Method and process are definitely areas where we can say there are many ways to achieve a goal, but at the same time areas where too little has been published yet to allow comparison and evolution. Here Jan Bosch does an excellent job of dishing out engineering wisdom to people who have to design architectures for families o