Today I would like to present a guest contribution by Alexander Eisenhuth, which deals with what makes a good software architecture. Alexander has been self-employed in software engineering since 1996. As a software architect, he has been supporting development teams in their software architecture work for embedded systems for more than ten years. Alexander writes about his passion: good software architecture.
Rainer Grimm has been working as a software architect, team leader and training manager for many years. He likes to write articles on the programming languages C++, Python and Haskell, but also likes to speak frequently at specialist conferences. On his blog Modernes C++ he deals intensively with his passion for C++.
“How do you recognize a good software architecture?” That was the question at the end of my webinar on “Agile Software Architecture”. Previously, the contestant shared this story: “We are getting to the point with our embedded software where we can no longer expand it. The software has been supporting our device families for over ten years. After changes for one product, unexpected behavior occurs in other products“.
Have you ever heard of a similar story? The state of software is then also referred to as “historically grown” or “big ball of mud”.
Quality features are the answer
The question of good software architecture is easily answered: You can recognize good software architecture by the fact that it implements the required quality features. In the case of the above story, it falls under the maintainability quality of software. In principle, the “historically grown” software is maintainable, but it is expensive to convert it back to the desired, technically correct state. In any case, the result is unsatisfactory:
- high effort and
- the necessary extensions to the functionality are probably distributed over many places in the software.
Quality features are described in detail in the ISO 25010 quality model. It can be seen that quality characteristics affect different phases of the software life cycle.
There is an important aspect to prioritizing quality attributes. They can be divided into important, critical and irrelevant quality characteristics.
The critical quality features must be guaranteed, as without these the operation and sale of the software or the system is not permitted. Compliance with these quality features must be ensured.
In any case, important quality features must also be taken into account in the software architecture work, but they are not directly critical.
Maintainability is usually an important quality feature. The effects of poor maintainability are noticeable over the years, as our example from the beginning shows.
Quality feature maintainability
The quality feature of maintainability is understood as the quality with which time expenditure maintenance activities can be carried out on a software.
Maintenance activities are:
- Expand functionality: implement new functional requirements,
- perform analyses: perform or interpret error analysis or static code analysis,
- Eliminate programming errors and
- Carry out verifications: rule out errors after changes.
How do I get maintainable software?
In order for a team to be able to efficiently carry out the activities listed above, it is particularly important that the source code has a fundamentally suitable structure. The team must be clear where functionalities are located in the source code and how software is developed so that the software remains easy to maintain. Roughly speaking, this is the result of the software architecture work:
- architectural decisions
- design work
- concept work
Technical concepts describe the basic solution to a requirement that affects several building blocks (component, module, class) of the software. Their mode of action is referred to as cross-sectional. They affect maintainability because there should be exactly one technical solution for a requirement. Technical concepts describe the concrete implementation in the technology of the platform or programming language used.
Concepts that support maintainability
The following table lists typical technical concepts to achieve software maintainability:
Architectural style and pattern using a medical thermometer as an example
At the beginning of the design work, the basic organization of the software is determined. An architectural style describes this basic structure. Architectural patterns are the technically concrete design of the architectural style.
To illustrate which aspects play a role in the selection of the architectural pattern, I would like to look at it using a medical thermometer.
A digital medical thermometer is an embedded system organized in a hierarchical system architecture style. At the top level is the software that uses the underlying hardware. The software itself is also structured hierarchically. This is due to the fact that the lowest layer of the software contains the hardware abstraction with which the hardware is controlled.
The selection of the architecture pattern is an architectural decision. Architectural decisions are made against the background of a development project in a company that creates the framework for the decision with its technical and organizational framework.
I will introduce two architecture patterns and describe aspects related to maintainability. I have shown the structure of the two architecture patterns in a very simplified form with blocks without depicting the dependencies in the following diagrams.
The layered architecture
The structuring of software in layers has been around for many years. The basic concept is to create levels of abstraction to organize functions. In the layers, the upper layers may only access the layers below. This rules out the possibility of cyclic dependencies. Layers could be swapped out and the overall functionality is retained. The following architecture pattern is common in embedded systems:
The software of the thermometer is divided into three layers in my view:
- application: Contains the use cases of the system. In this case, the temperature measurement and the behavior when the battery is running low.
- Service: Provides access to technical abstractions with which applications can be implemented. Here the possibility to measure temperatures, to display them and to output a tone for signalling. It is important here that the level of abstraction is maintained and that no knowledge of the type of hardware access is required for the application.
- Hardware Abstraction Layer: Offers an interface to control the hardware
Remarks:
- ADC: Measurement of voltages
- LCD: control of the display
- HAL: Hardware Abstraction Layer
The component architecture
Components provide a system-specific functionality via offered interfaces. In order to function, components require further functionality, which they receive via the required interfaces.
Components can be developed independently of each other if the required and provided interfaces are declared. In addition, components require technical functionalities such as runtime libraries of the programming language. In embedded systems without an operating system, components are implemented as static libraries.
Reusability is the driving force behind building software from components.
The component architecture shown here is also a hierarchical architecture style. The application layer is the top layer and uses the components shown. The components have a service layer and a HAL.
Comparison of maintainability layered architecture and component architecture
The most noticeable difference is that the first level component architecture software is divided into six blocks and the layered architecture is divided into three blocks. In the case of the component architecture, there is a finer division of the software.
Another difference is that the component architecture forms functional blocks with cohesion. Cohesion describes the belonging together within a block. The cohesion is dictated by the functionality of the component.
The ADC block occurs several times in the component architecture.
Comparison of maintainability in the software of a medical thermometer
evaluation of the differences
The potential benefits of component architecture come at the cost of increased effort when implementing component interfaces. For the selection of the architecture pattern, the quality feature of maintainability is not the only decisive factor. As already mentioned, it depends on the background of a development project.
With a very simple system like the thermometer, it won’t be worth the hassle of breaking the software down into components. However, in the case of systems with greater complexity or when it comes to variants in the products or devices, a component architecture can also make sense for simple systems.
In any case, software architecture work is an important part of a development project. Implementing quality features in software afterwards is more expensive than considering them at the beginning.
Summary
- Maintainability is a quality feature of software,
- the easier it is to maintain software, the less time is spent on maintenance tasks (analysis, expansion, verification) and
- Choosing the software architecture style is an important architectural decision with far-reaching implications.
Maintainability is obtained through
- a suitable software architecture style,
- good technical concepts for maintainability and
- design work appropriate to the problem.
What’s next?
In my next article, I will go deeper into the architecture patterns of Layered Architecture, Pipes-and-Filters, Broker, Model View Controller, and Reactor.
(rme)