1. 3. Designing Software Architectures
2. 4. Description and Communication of Software Architectures
3. 5. Software Architectures and Quality
4. 6. Tools for Software Architects
5. 2. Software Architecture Fundamentals
5.1. Figure 2-1 The magic rectangle of successful software projects
5.2. 2.1. Integration with the iSAQB curriculum
5.2.1. Distinguish between explicit statements and implicit assumptions
5.2.2. Relate the role of software architects to other stakeholders
5.2.3. Understand software architects’ tasks and responsibilities
5.2.4. Understand software architecture as part of the software lifecycle
5.2.5. Discuss definitions of software architecture
5.2.6. Understand and identify the benefits and objectives of software architecture
5.2.7. Ability to explain the correlation between development approaches and software architecture
5.2.8. Differentiate between architecture and project objectives
5.2.9. Know roles and responsibilities of software architects in an organizational context
5.2.10. Understand the differences between types of IT systems
5.3. 2.2. Software-intensive systems and software architectures
5.3.1. 2.2.1. What is a software-intensive system
5.3.1.1. A software-intensive system is a collection of building blocks that are organized in such a way that they together accomplish the purpose of the system. Building blocks of such a system that entirely or for the most part consist of software carry out essential tasks for achievement of the purpose of the system. The software element of the system consists of a collection of programs, procedures, data, and associated documentation
5.3.2. 2.2.2. Types of software-intensive systems
5.3.2.1. Figure 2-2 Multi-dimensional categorization of software-intensive systems
5.3.2.2. Figure 2-3 Categories of software-intensive systems
5.3.2.2.1. Information systems: The focus of information systems is on management and processing of information. Large amounts of data or complex data structures have to be managed, processed, evaluated and calculated, and several thousand users may have to be served both simultaneously and interactively. Examples of information systems are the core insurance management system of an insurance company, SAP systems, CAD systems, complex simulation systems for weather forecasting, or simulation calculations for engineers.
5.3.2.2.2. Embedded systems: contain software that is embedded into physical objects. With significant resource limitations in terms of the available hardware, they carry out tasks that are critical in terms of both data security and functional reliability, and which have to fulfill demanding functional and quality requirements. This functionality mostly involves regulation, control or communication functions. Examples of embedded systems are washing machines, machine tools or production lines in the manufacturing industry, radio cells in mobile phone networks, airbag control systems, and vehicle parking assistants.
5.3.2.2.3. Mobile systems: are (semi-)autonomous, personal units with high interaction requirements. In addition to being mobile, they are characterized by the fact that they provide local and, where necessary, (semi-)autonomous functions. In addition they can, and to an extent also need to, interact with centralized, mainly stationary systems to synchronize themselves or to coordinate information and actions with others. Due to their mobility, however, the link to the central systems is not continuously available. Examples of embedded systems are smartphones, (semi-)autonomous transportation robots, and sensor/actuator nodes in ad-hoc networks.
5.3.3. 2.2.3. The importance of software architecture for a software-intensive system
5.3.3.1. Good software architecture, however, makes it easy to change existing functionalities or introduce new functionalities without endangering the quality characteristics of the existing software
5.3.3.2. An essential element of good software architecture is the mainly hierarchical decomposition of the system into subsystems or building blocks.
5.3.3.3. Software requirements change during the course of development, and also during the software’s entire lifecycle, regardless of how well they are documented. Changing requirements impact the development project.
5.4. 2.3. Fundamental software architecture concepts
5.4.1. 2.3.1. What is a software architecture?
5.4.1.1. The software architecture defines the fundamental principles and rules for the organization of a system and its structure into building blocks and interfaces, and their relationships to each other and to the surrounding environment. It thus defines guidelines for the entire software lifecycle, the developer, and the software’s operator, from analysis via design and implementation to operation and enhancement.
5.4.1.2. Software architecture objectives can also be long-term objectives that extend beyond project objectives and their time horizon, which is usually coupled to the duration of the development project.
5.4.1.3. Software architecture can thus also represent and include an investment in the entire system lifecycle, which possibly only amortizes itself following completion of the associated development project.
5.4.2. 2.3.2. Building blocks, interfaces, and configurations
5.4.2.1. Figure 2-4 Examples of building blocks.
5.4.2.2. Figure 2-5: The relationships between building blocks and interfaces
5.4.2.2.1. Building blocks are also the unit of hierarchical (de)composition of a software-intensive system. In other words, a building block can be implemented using an appropriate configuration of other (sub-)building blocks and their interrelationships. In this case, too, we say that this (super) building block encapsulates the (sub-) blocks. The building block can also delegate external interfaces to internal interfaces and vice versa. This is how relationships between building blocks are defined. (Configuration and hierarchical (de)composition)
5.4.2.2.2. A building block provides interfaces that it guarantees in the sense of a contract. This guarantee, however, only applies when the interfaces that it requires are made available within the scope of a corresponding configuration. (Provided and required interfaces) Via the provided and required interfaces, the building block encapsulates the implementation of these interfaces. It can thus be replaced by other building blocks that provide and, where appropriate, also require the same interfaces. (Encapsulation and interchangeability).
5.4.2.2.3. An interface represents a well-defined access point to the system or its building blocks. In this context, an interface describes the characteristics, (for example, attributes, data, and functions) of this access point. The objective is to define these characteristics as precisely as possible with all the necessary aspects, such as syntax, data structures, functional behavior, error behavior, non-functional characteristics, the interface usage log, technologies, protocols, access modifiers, file formats, conditions/constraints, and semantics.
5.4.2.3. Figure 2-6 Black box, gray box, and white box views
5.4.2.3.1. White box view (also known as the glass box view) provides a view of the internal details of the building block—in other words, its decomposition into the configuration of the sub-building blocks or a different type of implementation. This view also shows the delegation of its provided and required interfaces to the internal workings of the building block. This is the view seen by the implementer of the building block.
5.4.2.3.2. Gray box view shows which additional, mostly technical interfaces are required by the building block—for example, configuration interfaces or interfaces to the runtime environment that are required and used. The gray box view can be described using UML distribution diagrams.
5.4.2.3.3. Black box view we only see the interfaces provided and required by the building block. This is the view seen by the user of the building block. This view respects the information-hiding principle—in other words, it hides the (private) internal details of the building block.
5.4.2.4. Figure 2-7 Hierarchical (de)composition with black box and white box views
5.4.2.5. Figure 2-8 Who defines the interface and the interface agreement?
5.4.2.5.1. Standard interface: This interface is defined by an external third party. Both the providing and requesting building blocks comply with it.
5.4.2.5.2. Provided interface: In this case the interface is defined by the building block that provided it. Apart from the standard interface, this is the type of interface that is most commonly used
5.4.2.5.3. Required interface: In this case the interface is defined by the building block that requires it. This configuration is often found within frameworks. With these types of interfaces you can incorporate building blocks with specific functionality into a program structure.
5.4.2.5.4. Independent interfaces: In this case both the building block that provides the interface and the building block that requires it define their own interfaces. This increases the decoupling of the building blocks, and they can be developed and tested independently. This, however, means that the interfaces do not remain identical over the course of time, and for this reason an adapter has to be placed between them.
5.4.3. 2.3.3. Concepts for describing software architectures
5.4.3.1. Software architecture is not only discussed with other architects. All aspects of the software architecture are presented to representatives of different interests (stakeholders), discussed with them, and jointly further developed. Customers and users, for example, can also become involved in architecture decisions that affect them. Developers should also become involved in the discussion, in particular for communication and discussion of aspects of the architecture that are relevant to the final implementation.
5.4.3.2. Figure 2-11 Conceptual model for descriptions of software architectures
5.4.4. 2.3.4. Architectural description and architectural levels
5.4.4.1. As already explained, an architecture is described at different levels. The selection and organization of these levels provides an initial reference point for the associated design methodology. Architectural levels are often found at different levels of abstraction—for example, a high-level “service-oriented layered architecture” style, or a more specific functional architectural level that includes functional entities and services.
5.4.4.2. Figure 2-12 The different levels in an architectural description
5.4.5. 2.3.5. Interactions between software architecture and environment
5.4.5.1. Project environment and project management provide a variety of constraints and project objectives that must be taken into account where they are relevant to the architecture. Budgets and the development approach, for example, can influence the software architecture, and vice versa. In the surrounding environment of a system there are usually a number of applications and projects. This existing (and continuously changing) project and application landscape often has significant impacts on the software architecture being developed. If additional projects or applications are initiated or suddenly terminated, this can have enormous impact on interfaces to the system for which a software architecture is to be developed.
5.4.5.2. Product Management and Requirements Engineering place functional and, in particular, non-functional requirements, quality objectives, and constraints on the system, all of which can change during the course of the project and thus affect the architecture. On the other hand, the architecture can also identify which requirements generate conflicts of interest with other requirements or project constraints. The architecture can thus also generate impulses for changes to requirements.
5.4.5.3. Execution platform and operation Generally, the execution platform and operations organization already exist within the organization. New systems should use existing systems where possible, and this should be taken into account during the architecture design. On the other hand, new platform and operations requirements can also result from the architecture.
5.4.5.4. Tools and development environment The architecture must ultimately be implemented. This requires appropriate tools and a development organization. Appropriate development environments also have to be provided for the selected programming languages, frameworks, and technologies. Equally, the architecture itself can also place new requirements on tools and the development organization. Expansion of the test infrastructure may, for example, be necessary, depending on the selected technology.
5.4.5.5. Figure 2-13 Software architecture is influenced by its environment and vice versa.
5.4.6. 2.3.6. Quality and value of a software architecture