Today, our everyday life is naturally characterized by interconnected devices and systems. Whether you use your smartphone to find the fastest way to your destination, read the newspaper on the sofa with your tablet or control the smart heating via an app on your smartphone, these systems make our lives more comfortable. However, the convenience gain also requires stricter safety and security requirements that the developers of such systems must follow. This particularly applies to autonomous driving – here coherent safety concepts have top priority. Part 2/2
Software design principles improve software quality
Our whole life is determined by rules, even though some people think they don’t have to stick to them. Everyone has certainly had their own experiences with the subject of Corona and “adherence” to rules and regulations. You probably played Lego yourself as a child, or you do it with your children today. Again, there are rules for how the stones fit together.
The software architect develops the style guide for software development with ever-new knowledge. It describes the rules according to which the software architecture must be developed. Not all rules can be applied or do not apply to all architectures. The application depends on the required requirements. The application of the rules to a software architecture always improves software quality.
An architectural design principle is e.g. high cohesion. The goal here is to avoid redundancies, to process what logically belongs together in an architecture element and not to distribute similar tasks to several architecture elements. There are now publications on special design principles that can be applied to embedded software architectures. With software architecture patterns, the software architect can put the design principles into practice.
Architecture development and architecture patterns must meet security requirements
Based on his technical knowledge, the software architect develops the software architecture. The architect grabs his Pattern catalog Return. In general, patterns are known, tested, evaluated and adaptable solutions to recurring problems (challenges).
For safety-relevant systems, aspects such as functional safety and reliability must be taken into account and fulfilled.
In the case of systems designed to provide us with fully automated support (think automated driving), these aspects are security and reliability crucial to the product’s success:
And not to forget – the view through the safety glasses:
The use of patterns can be a challenge in software architecture development:
For example, a problem may require round contours even though only rectangular blocks are available. One solution would be to place the bricks – following the Lego principle – in one or more rows. Since we are not the first generation to develop software, there are now patterns for almost every area of software development, including software architecture development.
An example here is the Software Layer Pattern (string or non-string). Figure 4 shows a non-strict software layer architecture. Not strict means it includes access across layers. This is especially useful with embedded software to maintain the required performance. In this example, in addition to the classic horizontal layers, there are also vertical ones.
Quality assurance and quality assessment
The software architect is responsible for software quality and co-responsibility for quality assurance. Before the software architect develops an architecture, the quality characteristics must be defined. The architect knows how these features affect their software architecture, and the software testing team knows how to verify them. Moreover, quality cannot only be tested in a product after development has been completed!
In terms of quality, a distinction must be made between
- internal quality (eg software architecture) and
- external quality (as seen by the customer).
Process quality also has a significant influence on product quality. To emphasize the analogy to Lego again here too – all Lego building blocks must be assembled in such a way that they support the construction, otherwise it will collapse at the latest with further expansions. This also applies to the software architecture. It must fulfill all the previously defined quality characteristics and functionalities.
In the past, a software architecture often had to remain viable for 20 years or more. Today it is constantly being expanded and improved. This is due to constantly new requirements, rules and laws. A development process that allows this is therefore extremely important for the further development of the products.
The simplest quality assurance measure
Reviews with other architects and stakeholders represent the simplest quality assurance measure in the development of the software architecture. Here, it is assessed whether the architecture meets the required quality features or not. The software architecture documentation based on a UML model is suitable as a basis for a review.
In the scenario-based review, the participants play through previously defined cases with the architecture. For example, if an architecture is to be portable with respect to the hardware, the hardware is exchanged in a mind game and this proves the software architecture to be appropriate. There is a very comprehensive method to do this BE (Software Engineering Institute at Carnegie Mellon University). It is called ATAM (Architecture Tradeoff Analysis Method).
Other quality assurance measures include creating prototypes or mathematical models, running a simulation, and determining metrics.
The use of tools facilitates the development of the software architecture
The software architect is responsible, or at least co-responsible, for the tool world around software development.
He knows the tool market, identifies the need, develops tool requirements, evaluates tools and ultimately selects them professionally. If there is no tool group in the company, he is also responsible for tool integration. The tools should make the work of everyone involved in software development easier. A little selfishness does not hurt, it is (primarily) the software architect who benefits from it.
Tool themes that make the work of the software architect easier:
- requirements management
- Version and configuration management
- Generation of documentation and program code
- building systems
- Static Analysis
- Dynamic analysis
Implementation of the software architecture
The software architect hands over part or all of the architecture to one or more software developers for further refinement (design and implementation). The code style guide, which the software architect writes together with the software developers, shows, among other things, how the software architecture is reflected in the target programming language. Typical target programming languages for programming embedded systems are currently C and C++.
With C++, the software architecture can be very well mapped using namespaces in the program code.
It is essential for software architects and software developers to ensure that the specified software architecture is maintained throughout its life cycle and is not programmed “broken” – a process also known as software erosion.
If the software developer recognizes a need to change the architecture, all change decisions and the architecture change itself must be made by the responsible software architect.
The higher the requirements for safety, security and modularity of the products, the more important and decisive for success the function of the software architect becomes in the entire development process.
Read part 1 here.