Software Architecture Fundamentals E-Book

Mahbouba Gharbi

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2019

Seitenzahl: 236

Beschreibung

Software architecture is an important factor for the success of any software project. In the context of systematic design and construction, solid software architecture ensures the fulfilment of quality requirements such as expandability, flexibility, performance, and time-to-market. Software architects reconcile customer requirements with the available technical options and the prevailing conditions and constraints. They ensure the creation of appropriate structures and smooth interaction of all system components. As team players, they work closely with software developers and other parties involved in the project. This book gives you all the basic know-how you need to begin designing scalable system software architectures. It goes into detail on all the most important terms and concepts and how they relate to other IT practices. Following on from the basics, it describes the techniques and methods required for the planning, documentation, and quality management of software architectures. It details the role, the tasks, and the work environment of a software architect, as well as looking at how the job itself is embedded in company and project structures. The book is designed for self-study and covers the curriculum for the Certified Professional for Software Architecture – Foundation Level (CPSA-F) exam as defined by the International Software Architecture Qualification Board (iSAQB).

Leseprobe

Mahbouba Gharbi is managing director and Chief Architect at ITech Progress GmbH, and chairman of the board at the International Software Architecture Qualification Board (iSAQB). She is a self-confessed software architecture enthusiast and the author of many expert articles. She is a welcome guest speaker at numerous international conferences.

Prof. Dr. Arne Koschel is a lecturer at the University of Applied Sciences and Arts, Hannover, Germany specializing in distributed (information) systems. He has many years of industry experience planning and developing distributed information systems. His lectures include a broad range of IT topics, including cloud computing, integration, middleware, microservices, and SOA. He is an active member of the iSAQB board.

Prof. Dr. Andreas Rausch is head of the software systems department at the Technical University of Clausthal. He is a consultant and lead software architect for a number of large-scale distributed software systems.

Mahbouba Gharbi · Arne Koschel · Andreas Rausch

Software Architecture Fundamentals

A Study Guide for the Certified Professional for Software Architecture®

– Foundation Level– iSAQB compliant

Content proofreading by Andrew Le Gear

Mahbouba Gharbi · [email protected]

Arne Koschel · [email protected]

Andreas Rausch · [email protected]

Editor: Michael Barabas / Christa Preisendanz

Content proofreading: Andrew Le Gear

Copyeditor: Jeremy Cloot

Layout and type: Josef Hegele

Cover design: Helmut Kraus, www.exclam.de

Library of Congress Control Number: 2019931449

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

978-3-86490-625-1

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Title of the German original: Basiswissen für Softwarearchitekten.

Aus- und Weiterbildung nach iSAQB-Standard zum Certified Professional for Software Architecture – Foundation Level.

3., überarb. u. akt. Auflage 2018

ISBN 978-3-86490-499-8

Many of the designations in this book used by manufacturers and sellers to distinguish their products are claimed as trademarks of their respective companies. Where those designations appear in this book, and dpunkt.verlag was aware of a trademark claim, the designations have been printed in caps or initial caps. They are used in editorial fashion only and for the benefit of such companies, they are not intended to convey endorsement or other affiliation with this book. No part of the material protected by this copyright notice may be reproduced or utilized in any form, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission of the copyright owner. While reasonable care has been exercised in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

This book is printed on acid-free paper.

Printed in the U.S.A

Preface

In addition to motivated teams and great management, software architecture is an important factor for the success of any software project. In the context of systematic design and construction, solid software architecture ensures the fulfilment of quality requirements such as extensibility, flexibility, performance, and time-to-market.

Software architects reconcile customer requirements with the available technical options and the prevailing conditions and constraints. They ensure the creation of appropriate structures and smooth interaction of all system components. As team players, they work closely with software developers and other parties involved in the project.

The International Software Architecture Qualification Board (iSAQB) is an independent international body that defines standards for training, examination, and certification of software architects. Software Architecture Fundamentals is based on the curriculum for the iSAQB’s Certified Professional for Software Architecture – Foundation Level (CPSA-F) course.

The text is based on the revised version 4.1.1 of the curriculum, which has been expanded to cover new aspects of domain-driven design (DDD). DDD enables software architects to design large-scale functional structures and gain a better understanding of the overall interaction of functional components. The current curriculum also covers numerous new architectural patterns such as microservices.

CPSA-F certification ensures that software architects have sound levels of knowledge and expertise for the design of small and medium-sized systems. Based on a detailed requirements specification, they can then design and document appropriate software architectures. CPSA-F graduates have the requisite skills for making problem-specific design decisions that build on their previous practical experience.

This self-study book enables you to prepare for the certification examination. It assumes that you have practical experience designing and developing software systems, command of a high-level programming language, and an understanding of the basics of UML. Because lectures alone cannot replace interaction with other software architects, we also recommend participation at iSAQB attendance-based events.

Benefit from our many years of experience in software and systems engineering, and in the design and construction of medium- and large-scale IT systems.

We hope you enjoy reading our book and wish you every success with your CPSA-F training and certification!

Mahbouba Gharbi, Arne Koschel, Andreas RauschDecember 2018

Content

1Introduction

1.1Software architecture as an aspect of software engineering

1.2iSAQB: The International Software Architecture Qualification Board

1.3Certified Professional for Software Architecture – Foundation and Advanced Level

1.4The aim of this book

1.5Prerequisites

1.6Reader’s guide

1.7Target audience

1.8Acknowledgements

2Software Architecture Fundamentals

2.1Integration with the iSAQB curriculum

2.2Software-intensive systems and software architectures

2.3Fundamental software architecture concepts

2.4A bird’s-eye view of software architecture design

2.5Test your knowledge

3Designing Software Architectures

3.1Integration with the iSAQB curriculum

3.2Overview of the architecture design process

3.3Design principles and heuristics

3.4Architecture-centric development approaches

3.5Techniques for a good design

3.6Architectural patterns

3.7Design patterns

3.8Test your knowledge

4Description and Communication of Software Architectures

4.1Integration with the iSAQB curriculum

4.2The CoCoME example

4.3Views and templates

4.4Technical/cross-cutting concepts in software architectures

4.5Architecture and implementation

4.6Common document types for software architectures

4.7Best-practice rules for documentation

4.8Examples of alternative architecture frameworks

4.9Test your knowledge

5Software Architectures and Quality

5.1Integration with the iSAQB curriculum

5.2Evaluating software architectures

5.3Prototypes and technical proof of concept

5.4Architecture analysis

5.5Test your knowledge

6Tools for Software Architects

6.1Integration with the iSAQB curriculum

6.2General information

6.3Requirements management tools

6.4Modeling tools

6.5Generation tools

6.6Static code analysis tools

6.7Dynamic analysis tools

6.8Build management tools

6.9Configuration and version management tools

6.10Code management tools

6.11Testing tools

6.12Documentation tools

6.13Test your knowledge

Appendix

ASample Questions

A.1Excerpts from the examination regulations

A.2Sample Questions

BList of Abbreviations

CGlossary

DReferences

Table of Contents

1Introduction

1.1Software architecture as an aspect of software engineering

1.2iSAQB: The International Software Architecture Qualification Board

1.3Certified Professional for Software Architecture – Foundation and Advanced Level

1.4The aim of this book

1.5Prerequisites

1.6Reader’s guide

1.7Target audience

1.8Acknowledgements

2Software Architecture Fundamentals

2.1Integration with the iSAQB curriculum

2.1.1Learning goals

2.2Software-intensive systems and software architectures

2.2.1What is a software-intensive system?

2.2.2Types of software-intensive systems

2.2.3The importance of software architecture for a software-intensive system

2.3Fundamental software architecture concepts

2.3.1What is a software architecture?

2.3.2Building blocks, interfaces, and configurations

2.3.3Concepts for describing software architectures

2.3.4Architectural description and architectural levels

2.3.5Interactions between software architecture and environment

2.3.6Quality and value of a software architecture

2.4A bird’s-eye view of software architecture design

2.4.1Objectives and functions of software architecture design

2.4.2Overview of software architecture design

2.4.3Interplay between activities and abstraction levels within the design

2.4.4A software architect’s tasks and relationships with other roles

2.5Test your knowledge

3Designing Software Architectures

3.1Integration with the iSAQB curriculum

3.1.1Learning goals

3.2Overview of the architecture design process

3.3Design principles and heuristics

3.3.1Top-down and bottom-up

3.3.2Hierarchical (de)composition

3.3.2.1Divide and conquer

3.3.2.2Decomposition principles

3.3.2.3The “as-simple-as-possible” principle

3.3.2.4Separation of concerns

3.3.3Lean interfaces and information hiding

3.3.3.1Information hiding

3.3.3.2Use of interfaces

3.3.4Regular refactoring and redesign

3.4Architecture-centric development approaches

3.4.1Domain-driven design

3.4.1.1Functional models as the basis for a design

3.4.1.2Systematic management of domain objects

3.4.1.3Structuring of the functional domain

3.4.1.4Types of domains

3.4.1.5Integration of domains

3.4.2MDA

3.4.3Reference architectures

3.4.3.1Generative creation of system building blocks

3.4.3.2Aspect orientation

3.4.3.3Object orientation

3.4.3.4Procedural approaches

3.5Techniques for a good design

3.5.1Degenerated design

3.5.2Loose coupling

3.5.3High cohesion

3.5.4The open/closed principle

3.5.5Dependency inversion

3.5.6Separation of interfaces

3.5.7Resolving cyclic dependencies

3.5.8Liskov’s substitution principle

3.6Architectural patterns

3.6.1Adaptable systems

3.6.1.1Dependency Injection

3.6.2Interactive systems

3.6.2.1Model-view-controller pattern

3.6.2.2Model-view-presenter pattern

3.6.2.3Presentation-abstraction-control

3.6.3From chaos to structure

3.6.3.1Layered architecture

3.6.3.2Pipes and filters

3.6.3.3Blackboard

3.6.4Distributed systems

3.6.4.1Broker

3.6.4.2Service orientation

3.6.4.3Modularization

3.6.4.4Microservices

3.7Design patterns

3.7.1Adapter

3.7.2Observer

3.7.3Decorator

3.7.4Proxy

3.7.5Facade

3.7.6Bridge

3.7.7State

3.7.8Mediator

3.8Test your knowledge

4Description and Communication of Software Architectures

4.1Integration with the iSAQB curriculum

4.1.1Learning goals

4.2The CoCoME example

4.2.1Use cases in the CoCoME system

4.2.2Overview of the structure of the CoCoME system

4.3Views and templates

4.3.1Well-established views as defined by the iSAQB

4.3.2UML diagrams as a notation tool in view descriptions

4.3.3View description: high-level structure and an example

4.3.3.1High-level structure: template-type view description

4.3.3.2Example: Excerpt from a view description for a building block view

4.3.4Context view (or context diagram)

4.3.5Building block view

4.3.6Runtime view

4.3.7Deployment/infrastructure view

4.3.8Interdependencies of architecture views

4.3.9Hierarchical refinement of architecture views

4.4Technical/cross-cutting concepts in software architectures

4.4.1Technical/cross-cutting concepts - sample dimensions

4.4.2Error handling

4.4.3Security

4.5Architecture and implementation

4.5.1Sample implementation

4.6Common document types for software architectures

4.6.1Central architecture description

4.6.2Architecture overview

4.6.3Document overview

4.6.4Overview presentation

4.6.5Architecture wallpaper

4.6.6Documentation handbook

4.6.7Technical Information

4.6.8Documentation of external interfaces

4.6.9Template

4.7Best-practice rules for documentation

4.7.1Rule 1: Write from the readers’ perspective

4.7.2Rule 2: Avoid unnecessary repetition

4.7.3Rule 3: Avoid ambiguity

4.7.4Rule 4: Standardized organizational structure or templates

4.7.5Rule 5: Justify important decisions in writing

4.7.6Rule 6: Check the documentation’s suitability for use

4.7.7Rule 7: Uncluttered diagrams

4.7.8Rule 8: Regular updates

4.8Examples of alternative architecture frameworks

4.8.1The 4+1 framework

4.8.2RM-ODP

4.8.3SAGA

4.9Test your knowledge

5Software Architectures and Quality

5.1Integration with the iSAQB curriculum

5.1.1Learning goals

5.2Evaluating software architectures

5.2.1Qualitative evaluation

5.2.1.1DIN ISO/IEC 25010

5.2.1.2Quality characteristics

5.2.1.3Additional quality characteristics

5.2.1.4Effects of specific quality characteristics

5.2.1.5Tactics and practices for fulfilling quality requirements

5.2.2Quantitative evaluation

5.2.2.1Checking architecture compliance

5.2.2.2Metrics

5.2.2.3Cyclomatic complexity

5.3Prototypes and technical proof of concept

5.3.1Technical proof of concept

5.3.2Prototype

5.3.2.1Benefits and disadvantages of software prototypes

5.3.2.2Types of software prototypes

5.4Architecture analysis

5.4.1The ATAM method

5.5Test your knowledge

6Tools for Software Architects

6.1Integration with the iSAQB curriculum

6.1.1Learning goals

6.2General information

6.2.1Costs

6.2.2Licenses and licensing conditions

6.3Requirements management tools

6.3.1Requirements and decision criteria

6.3.2Challenges faced by requirements management tools

6.3.3Examples

6.4Modeling tools

6.4.1Requirements and decision criteria

6.4.2Challenges faced by modeling tools

6.4.3Examples

6.5Generation tools

6.5.1Requirements and decision criteria

6.5.2Challenges faced by code generators

6.5.3Examples

6.6Static code analysis tools

6.6.1Requirements and decision criteria

6.6.2Challenges faced by static code analysis tools

6.6.3Examples

6.7Dynamic analysis tools

6.7.1Requirements and decision criteria

6.7.2Challenges faced by dynamic analysis tools

6.7.3Examples

6.8Build management tools

6.8.1Requirements and decision criteria

6.8.2Challenges faced by build management tools

6.8.3Examples

6.9Configuration and version management tools

6.9.1Requirements and decision criteria

6.9.2Challenges faced by configuration and version management tools

6.9.3Examples

6.10Code management tools

6.10.1Challenges faced by code management tools

6.10.2Examples

6.11Testing tools

6.11.1Requirements and decision criteria

6.11.2Challenges faced by test tools

6.11.3Examples

6.12Documentation tools

6.12.1Requirements and decision criteria

6.12.2Challenges faced by documentation tools

6.12.3Examples

6.13Test your knowledge

Appendix

ASample Questions

A.1Excerpts from the examination regulations

A.2Sample Questions

BList of Abbreviations

CGlossary

DReferences

1Introduction

Nowadays, software is everywhere, from commercial enterprises to virtually all areas of our day-to-day professional, public, and private lives. Air travel, phone calls, bank transfers, or driving would all be next to impossible without software. Software-controlled components can be found in every home and in many everyday devices, from washing machines to cars [BJ+06]. Software is not usually autonomous, but is instead embedded along with hardware and electronics, or as part of the business processes that companies use to generate value [TT+00].

The value and commercial success of companies and products is increasingly determined by software and software quality (see [BM00], [SV99], [TT+00]). Software engineers are thus faced with the challenge of implementing increasingly complex requirements at ever-increasing speed using ever-decreasing budgets while maintaining a high level of software quality.

Continual increase in the size and complexity of software systems has made them some of the most complex human-made systems ever created. The best example is the Internet, which is a truly global software-based system. Internet is now available beyond the bounds of our home planet on the International Space Station (ISS).

A structured and systematic approach to design is essential for the success of software-based systems. Despite the use of established software development methods, the number of unsuccessful software projects remains alarmingly large. To counter this, we need to avoid as many errors as possible, or identify and eliminate them during the early phases of software engineering. Requirements engineering and software architecture are two of these phases. In the words of Ernst Denert, one of the fathers of methodical software development, software architecture is the “Ultimate software engineering discipline” (taken from Denert’s foreword in [Sie04]).

1.1Software architecture as an aspect of software engineering

Problems with software projects were identified as early as the 1960s, and were referred to then as “the software crisis”. From 7–11 October 1968, the NATO Science Committee invited 62 internationally renowned researchers and experts to a conference in Garmisch, Germany, to address the future of software development. This conference is now regarded as the birth of modern software engineering [Dij72].

Figure 1-1Publications on the subject of software architecture since 1973 [Reu12]

Compared to traditional engineering disciplines (such as construction) that can fall back on several thousand years of experience, software engineering is still an extremely young discipline. It is therefore no surprise that the sub-discipline of software architecture is even younger. Figure 1-1 shows an increasing number of publications on the subject of software architecture from the 1990s onward [Reu12]. These figures are taken from The Web of Knowledge—one of the largest and most renowned publication databases.

With a view to the long history of construction architecture, Marcus Vitruvius Pollio (a Roman architect from the first century BC) was an architectural pioneer. In De architecture—nowadays known as Ten Books on Architecture[Vit60]—he argued that good architecture can be achieved using a clever combination of the following elements:

Utilitas (usefulness):

The building performs its function.

Firmitas (solidity):

The building is stable and long-lasting.

Venustas (elegance):

The building is aesthetically pleasing.

Figure 1-2Architecture in ancient Rome

This hypothesis can be directly applied to the discipline of software architecture. The objective of software architecture (and thus a software architect’s primary task) is to construct a system that balances the following three attributes:

Utilitas (usefulness

):

The software fulfills the functional and non-functional requirements of the customer and its users.

Firmitas (solidity):

The software is stable in terms of the specified quality requirements (for example, the number of simultaneously supported users). It also has to allow future enhancements without having to completely rebuild the system.

Venustas (elegance):

The software’s structure makes it intuitive to use, but also easy to maintain and develop.

1.2iSAQB: The International Software Architecture Qualification Board

Software architecture is an extremely young discipline and, despite many publications on the subject, various opinions still exist regarding its precise scope and design in the context of computer science and information technology. The tasks and responsibilities of software architects are defined in very different ways and are subject to continual renegotiation during a project.

In contrast, software engineering disciplines such as project management, requirements engineering, and testing have a more mature knowledge base. Various independent organizations offer training curricula that clearly define the knowledge and skills required by these disciplines (for testing, visit www.istqb.org; for requirements engineering, visit www.ireb.org; for project management, visit www.pmi.org).

In 2008, a group of software architecture experts from business, industry, and scientific communities formed the International Software Architecture Qualification Board as a registered association under German law (iSAQB e.V., www.isaqb.org). The goal of the iSAQB is to define product- and manufacturer-independent standards for the training and certification of software architects. Certifications at Foundation, Advanced, and Expert levels allow software architects to certify their knowledge, experience, and skills using a recognized procedure (see figure 1-3).

Because it eliminates the terminological uncertainty referred to earlier, standardized training benefits established and aspiring software architects, companies, and training organizations. Precise training curricula are essential for the examination and certification of aspiring software, and ensure that high-quality training is available on the basis of an accepted canon of knowledge.

Certification as a Certified Professional for Software Architecture (CPSA) is carried out by independent bodies. CPSA Foundation Level certification is based on a subset of a non-public catalogue of demanding questions developed by the iSAQB and matched to the curriculum. Advanced Level certification also requires practical certification and participation in licensed training courses (or acknowledgement of equivalent non-iSAQB qualifications). Expert Level certification is currently in development.

Figure 1-3iSAQB certification levels (www.isaqb.org)

Various licensed training institutions offer multi-day courses designed to refresh and deepen candidates’ existing knowledge in these subject areas. Participation in a course is recommended, but is not a prerequisite for registration for the certification examination.

1.3Certified Professional for Software Architecture – Foundation and Advanced Level

The iSAQB has now defined clear certification guidelines for CPSA Foundation Level and Advanced Level certification.

Advanced Level certification is modular and consists of individual courses dedicated to specific core competences for IT professionals:

Methodical competence

Technology-independent skills for systematic approaches to IT projects

Technical competence

Skills in the use of technology for solving design tasks

Communicative competence

Communication, presentation, rhetorical, and meeting skills that increase efficiency during the software development process

Prerequisites for Advanced Level certification are:

CPSA-F (

Foundation Level

) training and certification

At least 3 years’ professional experience in the IT sector

Active participation in the design and development of at least two different IT systems

At least 70 credit points from all three competence areas (with a minimum of 10 credit points for each)

The examination consists of solving a prescribed task and discussion of the solution with two independent examiners.

For Foundation Level certification is based on knowledge and skills defined in the iSAQB curriculum [isaqb-curriculum]. These are as follows:

The definition and importance of software architecture

The tasks and responsibilities of software architects

The role of the software architect within a project

State-of-the-art methods and techniques for the development of software architectures

The focus is on the acquisition of the following skills:

Coordinating critical software architecture decisions with other parties involved in requirements management, project management, testing, and development

Documenting and communicating software architectures on the basis of views, architectural patterns, and technical concepts

Understanding the main steps involved in the design of software architectures and performing them independently for small and medium-sized systems

Foundation Level training provides the knowledge necessary for designing and documenting a solution-based software architecture for small and medium-sized systems, based on a sufficiently detailed requirements specification. This architecture can then serve as a template for implementation. Participants are trained to make problem-oriented design decisions on the basis of previous practical experience.

Figure 1-4 shows the content and weighting of the individual areas of the curriculum for iSAQB Certified Professional for Software Architecture (CPSA) Foundation Level training.

Figure 1-4Structure of the iSAQB curriculum for the CPSA Foundation Level training

Various independent bodies offer certification based on the iSAQB curriculum. Examiners use standardized questions prepared by the iSAQB.

Questions are multiple-choice, so the results are objectively measurable.

The examination validates your software architecture capabilities on paper. It is up to you to prove yourself in real-world situations.

1.4The aim of this book

Members of the iSAQB developed this book during the creation of the Certified Professional for Software Architecture, Foundation Level curriculum. The main aim of the book is to provide a concise summary of the knowledge required to pass the CPSA Foundation Level examination, and thus the basic knowledge required for the creation of successful software architectures. This makes the book an ideal reference manual when preparing for the examination. In addition to reading the book, we also strongly recommend participation in the corresponding training courses, which offer practical examples of software architectures and the personal experience of our training staff, both of which go beyond the scope of this book.

The book focuses primarily on methodical skills and knowledge, so specific implementation technologies and tools are not part of the standardized training content. Specific notations and acronyms (such as UML) are to be understood only as examples. The book does not describe individual, specific procedure models or specific development processes, and instead provides various examples.

It explains important terms and concepts involved in software architecture and their relationships with other disciplines. Building on this, it provides an introduction to the fundamental methods and techniques required for design and development, description and communication, and quality assurance in software architectures. It also addresses the roles, tasks, interactions, and work environment of software architects, and describes how they integrate with company and project structures.

1.5Prerequisites

In line with the aims described above, the book and the iSAQB curriculum assume you have previous experience in software development. The following content is neither part of the book nor the curriculum, although it forms an essential part of every software architect’s skill set:

Several years of practical experience in software development, gained by programming differing projects or systems

Advanced knowledge of and practical experience with at least one high-level programming language

Fundamentals of modeling, abstraction, and UML; in particular class, package, component, and sequence diagrams and how they relate to source code

Practical experience in technical documentation; in particular the documentation of source code, system designs, and technical concepts

Knowledge and experience of object orientation is also advantageous for an understanding of some of the concepts involved. Experience in the design and implementation of distributed applications (such as client-server systems or web applications) is also desirable.

1.6Reader’s guide

The structure of this book is primarily oriented to the structure and content of the iSAQB Foundation Level curriculum. For more details, see figure 1-4 and [isaqb-curriculum]:

In

Chapter 2

we describe terms and software architecture basics, which are then addressed in more detail in subsequent chapters. For example, the concept of a software system “view” is introduced within the context of software architecture.

Practical software architecture design is addressed in

Chapter 3

. Topics covered include variants of the architecture development procedure; important architectural patterns such as views, pipes and filters, and model view controllers; and design principles such as coupling, cohesion, and separation of concerns.

Chapter 4

covers proven description tools and guidelines that enable you to document your software architecture and communicate it to others. This is oriented toward a specific target group. Topics covered include the iSAQB view model and cross-cutting concerns in software architectures.

In

Chapter 5

we take a look at the relationship between software architecture and quality issues. Important terms include quality, quality characteristics, ATAM (Architecture Tradeoff Analysis Method), quality tree, compromises (in the implementation of quality characteristics), qualitative architecture evaluation, and the risks involved in achieving quality assurance objectives.

Chapter 6

lists sample support tools for modeling, generating, and documenting software architectures.

The appendices include sample questions, a glossary, and a list of reference resources.

Chapters 2 to 5 are essential when preparing for the iSAQB examination, and the other sections are useful too. For general reading, we recommend that you thoroughly read Chapter 2 and then move on to the topics that interest you most.

1.7Target audience

The primary target audience for this book is anyone who is preparing for iSAQB certification and/or attending iSAQB training courses. The book is also aimed at IT professionals and students who wish to familiarize themselves with the basic terms used in software architecture.

The book also provides an overview of software architecture for software project managers, product managers, and decision makers at the intermediate software development level.

1.8Acknowledgements

We would like to take this opportunity to thank the iSAQB for its support, and in particular our iSAQB reviewers of previous editions Andreas Rothmann, Phillip Ghadir, and Stefan Zörner. Many thanks to Roger E. Rhoades for the review of the English text. We would also like to thank Ingrid Schindler from the Chair for Software Systems Engineering at Clausthal University of Technology, and the staff at ITech Progress, who provided invaluable support in the preparation of the diagrams. In particular, Christine O’Brien and Robert Kerns have been very supportive in creating the English edition of this book, thank you!

Our thanks also go to our editor Christa Preisendanz for her patience.

Finally, we particularly want to thank our families and partners who gave us the time and space to work together on this book.

2Software Architecture Fundamentals

As already explained in the introduction, software is nowadays just about everywhere. For almost a full 24 hours a day we rely on software operating correctly, starting with the alarm clock in the morning, via proper functioning of car and train brakes, through to the management of our money in bank accounts.

Despite this omnipresence and our dependence on software, we software engineers have still not understood in sufficient detail how to successfully construct software on a repeatable basis. Software projects take too long, cost too much, and fail too often. And even when a software project successfully goes into operational use, the result is often inadequate for those involved. This is confirmed time and time again on an annual basis in the CHAOS Report from the Standish Group [Sta99]. Despite all the criticism of the CHAOS Report, the fact can not be denied that other methods for evaluating success provide very similar, less than flattering results (see [EK08], [EV10]). The bottom line is that our ability to successfully manage software projects within the magic rectangle (see [Bal00], [Die00], [Dum01], [Lit05], [May05]), as shown in figure 2-1, is extremely limited. We are still not able to create high-quality software repeatably with the necessary functionality at affordable costs and within the specified timeframe.

Figure 2-1The magic rectangle of successful software projects

Two key factors for successfully developing software are requirements engineering and architecture design. With both of these disciplines the risk of serious undesirable developments is high, since decisions with far-reaching impacts (that in some cases can only be identified much later in the course of the project) have to be made at an early stage—in particular when the level of available knowledge is still limited (see [Nus01], [GEM04]).

For this reason, software architecture is one of the decisive success factors in software development, since it decides how to structure millions of lines of program code for large, software-intensive systems in such a way that the specified functionality is available in the end result with the desired quality, within budget, and on time (see fig. 2-1).