Authors: Moritz Neukirchner, Guillaume Cordon, Elektrobit Automotive GmbH, Andreas Gaiser, Axivion GmbH<\/p>\n
Managing the complexity of a software project becomes increasingly difficult as the project grows and evolves over time. Software architectural design shall control this complexity by defining clear cut interfaces between components and permitted interactions among them.<\/p>\n
Still, ensuring that the code adheres to the architecture specification is hard, even in the presence of reviews and integration testing. This challenge is even aggravated if multiple software variants must be taken into consideration and when portions of the code are being generated.<\/p>\n
We show how this gap between architecture and code can be closed through automated checks. Complexity is managed at architecture level and the adherence to this architectural design enforced throughout the development process down to the code as deviations are automatically reported by a dedicated tool. As a result, the architecture can serve as a reliable documentation and as a discussion basis for design changes. Further, the automatic checks permit to evaluate the quality of design and implementation (i.e. their consistency), thus allowing to define a quality metric on designs beyond just simple review.<\/p>\n
We illustrate the results using an automotive project and show that the approach scales from checking interface connections of components down to validating global data accesses.<\/p>\n
In order to automate consistency checks between architecture and implementation, strong UML guidelines need to be used across the tested software modules. In the following we use a dedicated example module (referred to as \u201cdesign module\u201d) to illustrate the required UML model scheme and how it relates to the information provided by the used static analysis tool.<\/p>\n
Figure 1 (see\u00a0PDF<\/a>) shows a UML component diagram for the design module. It contains the adjacent modules and all required and provided interfaces which the design module uses.<\/p>\n Figure 2 and Figure 3 (seei\u00a0PDF<\/a>) show how a UML component diagram is used to define UML Interfaces and the operations they implement with parameters and return values.<\/p>\n UML representation of interfaces, operations and relationships between modules allows to detect whether the design module performs unspecified\/unwanted static function calls to a different module using a public interface. Based on the same UML methodology, it is possible to define internal interfaces and sub-components for composed modules (see Figure 4,\u00a0PDF<\/a>).<\/p>\n The previous diagram allows to model global volatile run-time data and their data accesses. Derived from the interfaces view of the model, it is possible to extract how the design module shall access global data and therefore to apply checks on the module source code.<\/p>\n The file mapping view (Figure 5, see\u00a0PDF<\/a>) allows to model the declaration\/implementation relationship between the source code and interfaces.<\/p>\n The architectural model based on these strong UML guidelines form the basis for two aspects:<\/p>\n <\/p>\n As a result we can ensure that architecture documentation and implementation stay in-sync. In the remainder we focus on the automatic consistency check rather than the automatic generation of documentation.<\/p>\n Our approach to automated architectural consistency checking via static analysis is split into the following three steps.<\/p>\n 1. Extraction of code dependencies and architecture dependencies.<\/em> If its format is flexible enough, it is also possible to enrich the dependency graph with architecture entities and dependencies. In this project we have used the Axivion Bauhaus Suite\u00a9 for analysis. In Figure 9 (see\u00a0PDF<\/a>) lower part, an import of the UML component diagram for \u2018Design module\u2019 (Figure 1, see\u00a0PDF<\/a>) is shown.<\/p>\n 2. Create a semantic mapping between dependency graph and architecture model. Further the\u00a0semantic interpretation<\/em>\u00a0of dependencies has to be fixed: which code dependencies does a specific architecture dependency allow? In our project, we e.g. interpret the interface dependency \u2018Public Interface 1\u2019 between \u2018Design Module\u2019 and \u2018External module 1\u2019 as follows: each code entity mapped to \u2018External module 1\u2019 is allowed to call routines mapped to \u2018Public Interface 1\u2019.<\/p>\n Both mapping and semantic interpretation are constructed automatically by Python scripts, which emit warnings if modelling errors or problems with the mapping occur. These provide valuable hints for the software architect.<\/p>\n 3. Architecture conformance check. In the analysed project, each module to be tested exists in multiple versions depending on the configuration that is used for code generation. Each such variant typically has multiple separate test cases to verify correct functionality. Therefore, it is necessary to perform the analysis on an extensive set of test cases, which may use differing code bases depending on the generated code.<\/p>\n For measuring the quality of both test case coverage and the architectural design, it is important to know whether<\/p>\n Figure 1 (see\u00a0PDF<\/a>) shows the automated workflow for checking the questions from above:<\/p>\n The concrete case of our design module depicted in\u00a0Error! Reference source not found.<\/em>\u00a0is raising the following kind of findings (see Figure 11,\u00a0PDF<\/a>).<\/p>\n We have shown how the management of complexity in software development can be assisted through automatic checking of software designs. Based on the requirements of a productive automotive software project, which includes the challenging aspects of a multitude of variants and a large degree of code generation, we have demonstrated that deviations in implementation from the design specification can be effectively detected in an automated way.<\/p>\n This approach guarantees that implementation and design stay in sync such that the design can serve as a\u00a0reliable\u00a0documentation of software. Further, it permits to define quality metrics on design documents beyond just simple review results as deviations can be properly quantified. This allows to enhance quality control and to prevent that design and code diverge over time, i.e. that the quality of the design document deteriorates over time.<\/p>\n The approach was tested on architectural properties such as interface definitions and their connections, file structure and global data accesses. Nonetheless, the approach is not limited to these aspects.<\/p>\n The approach is in use in the qualification of productive code and is currently being used to detect undocumented dependencies between software components and undocumented global variable accesses.<\/p>\n [1]Rainer Koschke and Daniel Simon. \u201cHierarchical Reflexion Models\u201d. In\u00a0Proceedings of the 10th Working Conference on Reverse Engineering<\/em>\u00a0(WCRE ’03). IEEE Computer Society, Washington, DC, USA.<\/p>\n [2] Rainer Koschke. \u201cIncremental reflexion analysis.\u201d In\u00a0Journal of Software: Evolution and Process<\/em>\u00a0(2013), Volume 25, Issue 6.<\/p>\n Beitrag als PDF-Datei herunterladen<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Architektur \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Architektur \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n\n
Checking Architecture Consistency Using Static Analysis<\/h2>\n
\nStatic analysis tools generate a\u00a0dependency graph<\/em>\u00a0from a code base. In\u00a0Error! Reference source not found.<\/em>, a project consisting of four code files is shown. A matching dependency graph is depicted in\u00a0Error! Reference source not found.<\/em>, upper part. It uses node and edge types to express different kinds of code entities and relations. Nodes can be e.g. files, routines, or global variables. Further, they can be nested. Edge types include:<\/p>\n\n
\n<\/em>For an automated check, we have to define how code components\u00a0map<\/em>\u00a0to architectural entities. The names of operations of an interface are explicitly specified in the Interface View (see Figure 2, see\u00a0PDF<\/a>), which is used for mapping them to API functions. Similarly, global objects are mapped to global variables through naming patterns. Mapping between components and the files that implement them is extracted from explicit modelling as shown in Figure 6 (see\u00a0PDF<\/a>).<\/p>\n
\n<\/em>The outcomes of steps 1) and 2) are used to perform the actual comparison between code and architectural model. We use the hierarchical reflexion model approach for the check (see [1,2]). The analysis detects the following three scenarios:<\/p>\n\n
Technical Setup<\/h2>\n
\n
\n
Conclusion<\/h2>\n
References<\/h2>\n
\nArchitektur – MicroConsult Trainings & Coachings<\/h2>\n
\nArchitektur\u00a0– Fachwissen<\/h2>\n