Software Architecture: A Comprehensive Framework and Guide for Practitioners
Oliver Vogel, Ingo Arnold, Arif Chughtai, Timo Kehrer
Format: PDF / Kindle (mobi) / ePub
As a software architect you work in a wide-ranging and dynamic environment. You have to understand the needs of your customer, design architectures that satisfy both functional and non-functional requirements, and lead development teams in implementing the architecture. And it is an environment that is constantly changing: trends such as cloud computing, service orientation, and model-driven procedures open up new architectural possibilities.
This book will help you to develop a holistic architectural awareness and knowledge base that extends beyond concrete methods, techniques, and technologies. It will also help you to acquire or expand the technical, methodological, and social competences that you need. The authors place the spotlight on you, the architect, and offer you long-term architectural orientation. They give you numerous guidelines, checklists, and best practices to support you in your practical work.
"Software Architecture" offers IT students, software developers, and software architects a holistic and consistent orientation across relevant topics. The book also provides valuable information and suggestions for system architects and enterprise architects, since many of the topics presented are also relevant for their work. Furthermore, IT project leads and other IT managers can use the book to acquire an enhanced understanding of architecture.
Further information is available at www.software-architecture-book.org.
elegance. Architecture as a compromise An architecture is therefore created based on different requirements and is influenced by these requirements (see Figure 3.1-2). Elegance influences Architecture influences Usefulness influences Durability Figure 3.1-2: Architecture influenced by classic requirements Architectures fulfill requirements to different degrees. They are therefore always a compromise and the result of your considerations and decisions (see Chapter 5). Architect
relating to system operation in the architecture (architecture discipline: system management architecture). > In addition, you must generally develop systems in accordance with predefined standards and guidelines defined within an enterprise (architecture discipline: enterprise architecture). We will explain the architecture disciplines specified above briefly below for the purposes of differentiation. Network architecture 50 Network architecture is concerned with the network infrastructure
that covers the use cases. However, this only works if you have explicitly considered architecture views from the very beginning when you created or documented (see Section 8.7) an architecture. If this is not the case, the business analysts would have to search for the use cases in the documentation “jungle”. Relevance of architecture views Architecture covers different aspects of a system, such as interfaces of system building blocks or the interactions of system building blocks. However, in
Figure 6.1-4). As with loose coupling, the issue here is the local modifiability of system building blocks and their ability to be understood [Yourdon and Constantine 1978]. If a system building block unites all features relevant for understanding and changing it in its description, you can change it without having to understand or change other system building blocks. But only in case of semantically correct dependencies within a system building block high cohesion is given. For example even
more independent from their environment (that is, more loosely coupled) than objects. Another principle that many component architectures implement more strongly than objects is separation of concerns. The runtime environment separates technical and functional concerns and encapsulates them in different building blocks. The separation of these concerns enables you to develop them further independently of one another and you can reuse the technical concerns in different systems.