An aspect-oriented approach for improving architecture design efficiency

Major issues in software engineering today are the ever increasing size and complexity of systems with, at the same time, high demands for quality. Software architectures are a means for coping with size and complexity of systems and also for assuring required qualities. The processes of creating architectures, however, remain affected by these issues. Since, in practice, architectures have to be constructed iteratively, the number of established architectural strategies and the number of inter-related models heavily increase over time. Hence, the impact analysis of newly introduced quality strategies during later stages becomes highly effort-intensive and error-prone. With our approach we aim at the mitigation of effort needed for such quality impact analyses by enabling efficient separation of concerns. For achieving efficiency, we introduce an aspect-oriented approach that enables the automatic weaving of quality strategies into architectural artifacts. By doing so, we are able to conduct selective quality impact evaluations with significantly reduced effort

Architecture compliance checking at runtime: An industry experience report

In this paper, we report on our experiences we made with architecture compliance checking at run-time. To that end, we constructed hierarchical colored Petri nets (CP-nets), using existing general purpose functional programming languages, for bridging the abstraction gap between architectural views and run-time traces. In an industry example, we were able to extract views that helped us to identify a number of architecturally relevant issues (e.g., style constraint violations) that would not have been detected otherwise. Finally, we demonstrate how to systematically design reusable hierarchical CP-nets, and package valuable experiences and lessons learned from the example application

Recovering Runtime Structures of Software Systems from Static Source Code

Abstract: While software building blocks and their interdependencies can be recovered from the source code using static fact extraction, behavior and communication paths at runtime are typically gathered from instrumented executions of the system. However, more often than not it is not possible to retrieve data from the running system – either due to a high effort for instrumentation, missing (hardware) infrastructure, or because of advanced communication mechanisms hidden by middleware, frameworks or platforms. In this paper, we present an approach to semiautomatically reconstruct runtime components and connectors using source code analysis, pattern matching, and expert knowledge. We present two applications where we could recover runtime communication paths and component interactions despite the absence of runtime traces.

Systemeigenschaften dank Architektur fest im Griff

Konkurrierende Eigenschaften von software-intensiven Systemen, wie funktionale Sicherheit, Performanz oder Wartbarkeit abzuwägen und miteinander zu koordinieren, zählen zu den Hauptherausforderungen bei der Entwicklung komplexer Systeme. Ein Architektur-zentriertes Vorgehen erlaubt es frühzeitig Lösungskonzepte auf ihre Tragfähigkeit zu untersuchen und über Entwicklungsphasen hinweg stetig auf konsistente Umsetzung zu überprüfen. In dem Beitrag wird eine Übersicht über typische Modelle und deren Einsatz bei der Entwicklung gegeben

A non-invasive approach to trace architecture design, requirements specification, and agile artifacts

Agile processes emphasize iterative delivery rather than assuming the definition of all detailed requirements and architecture up front. This "just enough" approach generally considers user stories and acceptance tests as sufficient documentation for successful system development. However, industry practices have shown that this minimalism is appropriate for projects with short duration and small collocated teams. In the development of large systems, the "just enough" documentation goes beyond the traditional set recommended by the Agile evangelists, due to the diversity of elements to be considered, as for instance geographic distribution of the teams, necessity to comply with industry regulations, strict IT governance programs, integration of the system being developed with others, or even the presence of not-so-agile people in the teams. In this context, a more complex set of artifacts is required to ensure the proper development of systems, such as more detailed requirements documents and architectural specification. In this regard, to support the agile development of large systems, we introduce TraceMan - Traceability Manager as a mechanism for ensuring traceability among user stories, traditional requirements documents, test specifications, architecture design, and source code. We also present an experience report on how TraceMan has been used in the daily activities at John Deere Intelligent Solutions Group (ISG) to support traceability among development artifacts

Recovering component dependencies hidden by frameworks - experiences from analyzing OSGi and Qt

In this paper we present experiences we made in the identification and analysis of software dependencies in the context of two popular software development frameworks: OSGi and Qt. Both frameworks are designed for minimizing coupling between software entities by enabling late binding. In case of OSGi, it is the service-oriented bundle concept, in Qt it is the signals and slots mechanisms, that hide dependencies from the programmer at development-time. However, in order to keep an overview of the system it is mandatory to reveal a bigger picture in terms of components and their connections as they are going to exist during runtime. In this paper, we elaborate on the experiences we made in dependency identification and analysis in the context of an industrial and an academic project. In particular, we show how the framework mechanisms of Qt and OSGi can be analyzed in order to reveal a system's component dependencies without having to execute the software

RTLOpen Plattform Handbuch. Teil 3 - Softwareentwicklung von Echtzeitsystemen

In diesem Dokument wird der Gesamtprozess zur Entwicklung von Software für Echtzeitsysteme beschrieben. Dabei ist der Prozess der Vorgehensweise an das Prinzip des V-Modells angelehnt. Das 3-Ebenen-Vorgehensmodell aus dem EQUAL-Projekt [Ben+05] unterstützt dabei die qualitätsorientierte multidisziplinäre Entwicklung von mechatronischen Echtzeitsystemen. Die ProMiS Methode ("Projektmanagement für interdisziplinäre Systeme") kann dabei als Projektmanagementmethode herangezogen werden. Zusätzlich unterstützt die vorgestellte Methode Wiederverwendung im Kontext von Systemen mit harten Echtzeitanforderungen durch Anwendung bereits bekannter Konzepte wie der komponentenbasierten Systementwicklung