Is architectural development even relevant anymore?

And if so, how do we do it correctly today?

Author: Jens Liebehenschel, Frankfurt University of Applied Sciences

Contribution – Embedded Software Engineering Congress 2018

This paper begins with a brief explanation of terms. The benefits of early architectural development are then presented. After introducing a field-tested and internally consistent basic set of (tool-independent) architectural views for system and software architectures for embedded systems, the paper concludes with tips for architectural development.

Conceptual

The architecture of a software system describes its essential aspects. Besides structure and behavior, this includes particularly important decisions, such as the concepts and technologies used.

Every system has an architecture. Sometimes it is intentionally designed, sometimes it evolved organically – often a combination of both. The architecture is necessary to meet qualitative requirements, such as performance, storage capacity, and maintainability, but also safety and security. Based on these requirements, concepts must be found that best achieve the desired trade-off between all qualitative requirements. Fulfillment of these requirements is achieved at the architectural level, not in a separate "performance" or "safety" component.

Architecture documentation serves not only development but also communication. It can take many forms. Today, it is common to use tools that operate according to the model-view paradigm. Each element in the system exists only once, thus preventing redundancy.

The documentation describes the architecture in a meaningful way for all stakeholders. If an architecture is not documented, its visibility is at least reduced. The architecture is definitely not discernible from the code.

Why is architectural development neglected?

Poor architecture (documentation) offers little benefit. If the benefit is not high enough in relation to the effort, then the topic is not given high priority.

Metrics influence behavior. Due to standards, processes, etc., architectural work products must be available at certain milestones. These are created with as little effort as possible. The metric is met, but unfortunately often with little benefit.

In what way and how does architecture development support development?

Unlike tangible objects, we cannot perceive software systems with our senses. A meaningful approach in the form of a suitable representation is needed. State-of-the-art, this is achieved through an architectural model. When developing the architecture, the team needs a basis for discussion. A good model provides a clear overview of the system to be developed and helps to identify and document the appropriate abstractions, such as interfaces and responsibilities.

Contents of the architectural documentation

The architectural model includes structural, behavioral, and other perspectives. Stakeholders decide on the perspectives and the aspects visible within them. Therefore, the specific implementation depends on the project.

Nevertheless, the author has observed in various projects that a sensible set of views is repeatedly used – albeit in adapted form. The necessary adaptation concerns not only the depth and level of detail of the modeling but also the existing domains such as software, hardware, and hydraulics.

Architectural views for embedded systems

The following sections will first present structural views (hierarchical decomposition), then behavioral views, and further perspectives. The modeling is signal flow-oriented; therefore, SysML is the most appropriate tool.

The example system is deliberately chosen to be very simple, so that the diagrams are easy to understand, but transferability is still possible.

(See Fig. 1-11 in the PDF)

Depending on the interests of the stakeholders, other perspectives may be useful, such as component responsibilities or test cases.

The architecture model can provide starting points and a basis for decision-making for other important aspects of development, for example for runtime considerations, schedulability analyses and multicore considerations.

Modeling tips and experience reports

This section contains some tips on creating architectural models. Of course, these must be adapted to the specific characteristics of the system and the development project.

• One or more entry pages to the model, catering to the different interests of various stakeholders, help users navigate the model and increase acceptance.
• Modeling languages like SysML have a large feature set. Often, only a small subset is needed to build meaningful models. The fewer features of the language are used, the easier the models are to understand.
• A legend explaining the essential modeling elements helps stakeholders who do not have this knowledge to understand the model.
• Each diagram should contain information that highlights visible aspects, benefits and/or target audience in a few words.
• The number of views should be as low as possible, but of course as large as necessary. The maintenance effort (versions and variants) must also be taken into account when selecting them.
• The maintenance effort must also be taken into account when considering the depth of the modeling (for example, signal flows).
• The well-known number "7 +/- 2" (the number of information units we can hold in short-term memory) is not necessarily relevant to the number of elements in views. Overview diagrams with all components are often useful and helpful even if they contain significantly more components.
• A view should typically contain only one level of hierarchical decomposition.
• Specific aspects that are complicated to model always arise. A model doesn't always have to include everything. Sometimes a note is better than elaborate modeling.
• In general, diagrams should not mix too many aspects. It's better to separate aspects whenever possible. For example, in longer sequence diagrams, recurring parts can be moved to separate diagrams.
• Under no circumstances should structure and behavior be mixed in a diagram, even if some modeling tools allow this.
• Each element may only be included once in the model. If redundancy is introduced in this way, then the model-views paradigm no longer works.
• The „architecture images“ on the wall should be useful for all stakeholders, especially serving as a basis for discussion during development.
• Documenting essential decisions is important. Often, alternatives can be qualitatively evaluated, yet a sound decision can still be made. This also applies to qualities that need to be quantified later in the development process, such as safety.
• Important methodological decisions should also be documented for traceability purposes, for example, which views exist and why, and which aspects are important to which stakeholders.
• If possible, the team should work on a single model. Parallel editing can usually be achieved. The main benefit of a model lies in its consistency and continuity.
• Consistency in documentation is crucial throughout the development process. Within a model, a good tool, if used correctly, ensures consistency. However, consistency between the model and other work products is usually better achieved through dedicated programs than through reviews.
• Automation (built-in or custom-developed) must also be used when connecting tools.
• There are guidelines for developing architectural models. Those who define these guidelines should also be involved in the work. This is the only way to ensure the effectiveness of the methodological approaches. Short feedback loops are essential in methodology development.

Summary

Architecture development is an essential component of system and software development. The later the project begins, the less benefit it receives. Documenting the resulting system retrospectively offers no further assistance. Architecture development and documentation should begin at the very start of the project and be continuously pursued throughout its duration. It must serve as the basis for all decisions.

To ensure that relevant stakeholders benefit from the architecture documentation, they must be identified and interviewed. Following the interviews, a decision must be made regarding which aspects should be documented and when. The model must support the stakeholders.

author

Professor Dr. Jens Liebehenschel has many years of experience in the methodology and product development of highly configurable software systems. He has worked on numerous products in the automotive sector since 2002. Since 2015, he has been Professor of Mobile Systems Engineering at Frankfurt University of Applied Sciences.