Transcription
Mahbouba Gharbi is managing director and ChiefArchitect at ITech Progress GmbH, and chairman ofthe board at the International Software ArchitectureQualification Board (iSAQB). She is a self-confessedsoftware architecture enthusiast and the author ofmany expert articles. She is a welcome guest speakerat numerous international conferences.Prof. Dr. Arne Koschel is a lecturer at the Universityof Applied Sciences and Arts, Hannover, Germanyspecializing in distributed (information) systems.He has many years of industry experience planning anddeveloping distributed information systems. His lecturesinclude a broad range of IT topics, including cloudcomputing, integration, middleware, microservices, andSOA. He is an active member of the iSAQB board.Prof. Dr. Andreas Rausch is head of the softwaresystems department at the Technical University ofClausthal. He is a consultant and lead software architectfor a number of large-scale distributed software systems.
Mahbouba Gharbi · Arne Koschel · Andreas RauschSoftware ArchitectureFundamentalsA Study Guide for the Certified Professionalfor Software Architecture – Foundation Level– iSAQB compliantContent proofreading by Andrew Le Gear
Mahbouba Gharbi · [email protected] Koschel · [email protected] Rausch · [email protected]: Michael Barabas / Christa PreisendanzContent proofreading: Andrew Le GearCopyeditor: Jeremy ClootLayout and type: Josef HegeleCover design: Helmut Kraus, www.exclam.deLibrary of Congress Control Number: 2019931449Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der DeutschenNationalbibliografie; detaillierte bibliografische Daten sind im Internet über ght 2019 dpunkt.verlag GmbHWieblinger Weg 1769123 HeidelbergTitle of the German original: Basiswissen für Softwarearchitekten.Aus- und Weiterbildung nach iSAQB-Standard zum Certified Professional for SoftwareArchitecture – Foundation Level.3., überarb. u. akt. Auflage 2018ISBN 978-3-86490-499-8Many of the designations in this book used by manufacturers and sellers to distinguish theirproducts are claimed as trademarks of their respective companies. Where those designationsappear in this book, and dpunkt.verlag was aware of a trademark claim, the designations havebeen printed in caps or initial caps. They are used in editorial fashion only and for the benefit ofsuch 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 anyform, electronic or mechanical, including photocopying, recording, or by any information storageand retrieval system, without written permission of the copyright owner. While reasonablecare has been exercised in the preparation of this book, the publisher and author assume noresponsibility for errors or omissions, or for damages resulting from the use of the informationcontained herein.This book is printed on acid-free paper.Printed in the U.S.A
vPrefaceIn addition to motivated teams and great management, software architectureis an important factor for the success of any software project. In the contextof systematic design and construction, solid software architecture ensuresthe fulfilment of quality requirements such as extensibility, flexibility, performance, and time-to-market.Software architects reconcile customer requirements with the availabletechnical options and the prevailing conditions and constraints. They ensurethe creation of appropriate structures and smooth interaction of all systemcomponents. As team players, they work closely with software developersand other parties involved in the project.The International Software Architecture Qualification Board (iSAQB) isan 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 Professionalfor Software Architecture – Foundation Level (CPSA-F) course.The text is based on the revised version 4.1.1 of the curriculum, whichhas been expanded to cover new aspects of domain-driven design (DDD).DDD enables software architects to design large-scale functional structuresand gain a better understanding of the overall interaction of functional components. The current curriculum also covers numerous new architecturalpatterns such as microservices.CPSA-F certification ensures that software architects have sound levels ofknowledge and expertise for the design of small and medium-sized systems.Based on a detailed requirements specification, they can then design anddocument appropriate software architectures. CPSA-F graduates have therequisite skills for making problem-specific design decisions that build ontheir previous practical experience.This self-study book enables you to prepare for the certification examination. It assumes that you have practical experience designing and developingsoftware systems, command of a high-level programming language, and an
viPrefaceunderstanding of the basics of UML. Because lectures alone cannot replaceinteraction with other software architects, we also recommend participationat iSAQB attendance-based events.Benefit from our many years of experience in software and systemsengineer ing, and in the design and construction of medium- and large-scaleIT systems.We hope you enjoy reading our book and wish you every success withyour CPSA-F training and certification!Mahbouba Gharbi, Arne Koschel, Andreas RauschDecember 2018
viiContents1Introduction11.1 Software architecture as an aspect of software engineering . . . . . . . . .21.2 iSAQB: The International Software Architecture Qualification Board .41.3 Certified Professional for Software Architecture –Foundation and Advanced Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51.4 The aim of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71.5 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.6 Reader’s guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.7 Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Software Architecture Fundamentals112.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Software-intensive systems and software architectures . . . . . . . . . . . . 132.3 Fundamental software architecture concepts . . . . . . . . . . . . . . . . . . . . 192.4 A bird’s-eye view of software architecture design . . . . . . . . . . . . . . . . . 392.5 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473Designing Software Architectures513.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . . 523.2 Overview of the architecture design process . . . . . . . . . . . . . . . . . . . . 523.3 Design principles and heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4 Architecture-centric development approaches . . . . . . . . . . . . . . . . . . . 653.5 Techniques for a good design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.6 Architectural patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.7 Design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.8 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
viiiContent4Description and Communication of Software Architectures1014.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . . 1014.2 The CoCoME example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.3 Views and templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.4 Technical/cross-cutting concepts in software architectures . . . . . . . . . . 1344.5 Architecture and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374.6 Common document types for software architectures . . . . . . . . . . . . . . 1394.7 Best-practice rules for documentation . . . . . . . . . . . . . . . . . . . . . . . . . 1434.8 Examples of alternative architecture frameworks . . . . . . . . . . . . . . . . 1454.9 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495Software Architectures and Quality1515.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . . 1525.2 Evaluating software architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535.3 Prototypes and technical proof of concept . . . . . . . . . . . . . . . . . . . . . . 1615.4 Architecture analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635.5 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706Tools for Software Architects1736.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . . 1736.2 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736.3 Requirements management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.4 Modeling tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.5 Generation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1776.6 Static code analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786.7 Dynamic analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796.8 Build management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806.9 Configuration and version management tools . . . . . . . . . . . . . . . . . . . 1826.10 Code management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.11 Testing tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846.12 Documentation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.13 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
ContentAppendixASample Questions189A.1 Excerpts from the examination regulations . . . . . . . . . . . . . . . . . . . . . 189A.2 Sample Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191BList of ix
xiTable of ware architecture as an aspect of software engineering . . . . . . . . . 2iSAQB: The International Software Architecture Qualification Board . 4Certified Professional for Software Architecture –Foundation and Advanced Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5The aim of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Reader’s guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Software Architecture Fundamentals2.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . .2.1.1 Learning goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 Software-intensive systems and software architectures . . . . . . . . . . . .2.2.1 What is a software-intensive system? . . . . . . . . . . . . . . . . . . . .2.2.2 Types of software-intensive systems . . . . . . . . . . . . . . . . . . . . .2.2.3 The importance of software architecturefor a software-intensive system . . . . . . . . . . . . . . . . . . . . . . . .2.3 Fundamental software architecture concepts . . . . . . . . . . . . . . . . . . . .2.3.1 What is a software architecture? . . . . . . . . . . . . . . . . . . . . . . .2.3.2 Building blocks, interfaces, and configurations . . . . . . . . . . . .2.3.3 Concepts for describing software architectures . . . . . . . . . . . .2.3.4 Architectural description and architectural levels . . . . . . . . . .2.3.5 Interactions between software architecture and environment .2.3.6 Quality and value of a software architecture . . . . . . . . . . . . . .2.4 A bird’s-eye view of software architecture design . . . . . . . . . . . . . . . .2.4.1 Objectives and functions of software architecture design . . . .2.4.2 Overview of software architecture design . . . . . . . . . . . . . . . .1112121313141819202129333537394041
xiiTable of Contents2.4.3Interplay between activitiesand abstraction levels within the design . . . . . . . . . . . . . . . . . 432.4.4 A software architect’s tasks and relationshipswith other roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473Designing Software Architectures3.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . .3.1.1 Learning goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.2 Overview of the architecture design process . . . . . . . . . . . . . . . . . . . .3.3 Design principles and heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3.1 Top-down and bottom-up . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3.2 Hierarchical (de)composition . . . . . . . . . . . . . . . . . . . . . . . . .3.3.2.1 Divide and conquer . . . . . . . . . . . . . . . . . . . . . . . . . .3.3.2.2 Decomposition principles . . . . . . . . . . . . . . . . . . . . . .3.3.2.3 The “as-simple-as-possible” principle . . . . . . . . . . . . .3.3.2.4 Separation of concerns . . . . . . . . . . . . . . . . . . . . . . . .3.3.3 Lean interfaces and information hiding . . . . . . . . . . . . . . . . . .3.3.3.1 Information hiding . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3.3.2 Use of interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3.4 Regular refactoring and redesign . . . . . . . . . . . . . . . . . . . . . . .3.4 Architecture-centric development approaches . . . . . . . . . . . . . . . . . . .3.4.1 Domain-driven design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.1.1 Functional models as the basis for a design . . . . . . . .3.4.1.2 Systematic management of domain objects . . . . . . . .3.4.1.3 Structuring of the functional domain . . . . . . . . . . . . .3.4.1.4 Types of domains . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.1.5 Integration of domains . . . . . . . . . . . . . . . . . . . . . . . .3.4.2 MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.3 Reference architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.3.1 Generative creation of system building blocks . . . . . .3.4.3.2 Aspect orientation . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.3.3 Object orientation . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4.3.4 Procedural approaches . . . . . . . . . . . . . . . . . . . . . . . .3.5 Techniques for a good design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.1 Degenerated design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.2 Loose coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.3 High cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 070717272737475
Table of Contents3.5.4 The open/closed principle . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.5 Dependency inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.6 Separation of interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5.7 Resolving cyclic dependencies . . . . . . . . . . . . . . . . . . . . . . . . .3.5.8 Liskov’s substitution principle . . . . . . . . . . . . . . . . . . . . . . . . .3.6 Architectural patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.1 Adaptable systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.1.1 Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . .3.6.2 Interactive systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.2.1 Model-view-controller pattern . . . . . . . . . . . . . . . . . .3.6.2.2 Model-view-presenter pattern . . . . . . . . . . . . . . . . . .3.6.2.3 Presentation-abstraction-control . . . . . . . . . . . . . . . .3.6.3 From chaos to structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.3.1 Layered architecture . . . . . . . . . . . . . . . . . . . . . . . . .3.6.3.2 Pipes and filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.3.3 Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.4 Distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.4.1 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.4.2 Service orientation . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.4.3 Modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6.4.4 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7 Design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.2 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.3 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.4 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.5 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.6 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.7 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7.8 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.8 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29394949596974Description and Communication of Software Architectures4.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . .4.1.1 Learning goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2 The CoCoME example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2.1 Use cases in the CoCoME system . . . . . . . . . . . . . . . . . . . . . .4.2.2 Overview of the structure of the CoCoME system . . . . . . . . .101101102102103104xiii
xivTable of Contents4.3 Views and templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.1 Well-established views as defined by the iSAQB . . . . . . . . . . .4.3.2 UML diagrams as a notation tool in view descriptions . . . . . .4.3.3 View description: high-level structure and an example . . . . . .4.3.3.1 High-level structure:template-type view description . . . . . . . . . . . . . . . . . .4.3.3.2 Example: Excerpt from a view descriptionfor a building block view . . . . . . . . . . . . . . . . . . . . . .4.3.4 Context view (or context diagram) . . . . . . . . . . . . . . . . . . . . .4.3.5 Building block view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.6 Runtime view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.7 Deployment/infrastructure view . . . . . . . . . . . . . . . . . . . . . . .4.3.8 Interdependencies of architecture views . . . . . . . . . . . . . . . . . .4.3.9 Hierarchical refinement of architecture views . . . . . . . . . . . . .4.4 Technical/cross-cutting concepts in software architectures . . . . . . . . . .4.4.1 Technical/cross-cutting concepts - sample dimensions . . . . . . .4.4.2 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.5 Architecture and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.5.1 Sample implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6 Common document types for software architectures . . . . . . . . . . . . . .4.6.1 Central architecture description . . . . . . . . . . . . . . . . . . . . . . .4.6.2 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.3 Document overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.4 Overview presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.5 Architecture wallpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.6 Documentation handbook . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.7 Technical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.6.8 Documentation of external interfaces . . . . . . . . . . . . . . . . . . .4.6.9 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.7 Best-practice rules for documentation . . . . . . . . . . . . . . . . . . . . . . . . .4.7.1 Rule 1: Write from the readers’ perspective . . . . . . . . . . . . . . .4.7.2 Rule 2: Avoid unnecessary repetition . . . . . . . . . . . . . . . . . . . .4.7.3 Rule 3: Avoid ambiguity . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.7.4 Rule 4: Standardized organizational structureor templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.7.5 Rule 5: Justify important decisions in writing . . . . . . . . . . . . .4.7.6 Rule 6: Check the documentation’s suitability for use . . . . . . 144144
Table of Contents4.7.7 Rule 7: Uncluttered diagrams . . . . . . . . . . . . . . . . . . . . . . . . .4.7.8 Rule 8: Regular updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.8 Examples of alternative architecture frameworks . . . . . . . . . . . . . . . .4.8.1 The 4 1 framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.8.2 RM-ODP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.8.3 SAGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.9 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1451451451461471481495Software Architectures and Quality5.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . .5.1.1 Learning goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2 Evaluating software architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.1 Qualitative evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.1.1 DIN ISO/IEC 25010 . . . . . . . . . . . . . . . . . . . . . . . . .5.2.1.2 Quality characteristics . . . . . . . . . . . . . . . . . . . . . . . .5.2.1.3 Additional quality characteristics . . . . . . . . . . . . . . . .5.2.1.4 Effects of specific quality characteristics . . . . . . . . . . .5.2.1.5 Tactics and practicesfor fulfilling quality requirements . . . . . . . . . . . . . . . .5.2.2 Quantitative evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.2.1 Checking architecture compliance . . . . . . . . . . . . . . .5.2.2.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.2.3 Cyclomatic complexity . . . . . . . . . . . . . . . . . . . . . . .5.3 Prototypes and technical proof of concept . . . . . . . . . . . . . . . . . . . . . .5.3.1 Technical proof of concept . . . . . . . . . . . . . . . . . . . . . . . . . . .5.3.2 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.3.2.1 Benefits and disadvantages of software prototypes . .5.3.2.2 Types of software prototypes . . . . . . . . . . . . . . . . . . .5.4 Architecture analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.4.1 The ATAM method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.5 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1511521521531531531531551566Tools for Software Architects6.1 Integration with the iSAQB curriculum . . . . . . . . . . . . . . . . . . . . . . . .6.1.1 Learning goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.2 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.2.1 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.2.2 Licenses and licensing conditions . . . . . . . . . . . . . . . . . . . . . 63163170xv
xviTable of Contents6.3 Requirements management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.3.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.3.2 Challenges faced by requirements management tools . . . . . . .6.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.4 Modeling tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.4.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.4.2 Challenges faced by modeling tools . . . . . . . . . . . . . . . . . . . . .6.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.5 Generation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.5.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.5.2 Challenges faced by code generators . . . . . . . . . . . . . . . . . . . .6.5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.6 Static code analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.6.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.6.2 Challenges faced by static code analysis tools . . . . . . . . . . . . .6.6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.7 Dynamic analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.7.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.7.2 Challenges faced by dynamic analysis tools . . . . . . . . . . . . . . .6.7.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.8 Build management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.8.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.8.2 Challenges faced by build management tools . . . . . . . . . . . . .6.8.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.9 Configuration and version management tools . . . . . . . . . . . . . . . . . . .6.9.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.9.2 Challenges faced by configurationand version management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.9.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.10 Code management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.10.1 Challenges faced by code management tools . . . . . . . . . . . . . .6.10.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.11 Testing tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.11.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.11.2 Challenges faced by test tools . . . . . . . . . . . . . . . . . . . . . . . . .6.11.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184185
Table of Contents6.12 Documentation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.12.1 Requirements and decision criteria . . . . . . . . . . . . . . . . . . . . .6.12.2 Challenges faced by documentation tools . . . . . . . . . . . . . . . .6.12.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.13 Test your knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185185185186186AppendixASample Questions189A.1 Excerpts from the examination regulations . . . . . . . . . . . . . . . . . . . . . 189A.2 Sample Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191BList of xvii
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