Empirical Study on the Effect of a Software Architecture Representation's Abstraction Level on the Architecture-Level Software Understanding

Abstract-Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. Using the architectural component model it is possible to perceive the interactions between the system's major parts and to understand the overall system's structure. In this paper we present a study that examines the effect of the level of abstraction of the software architecture representation on the architecture-level understandability of a software system. Three architectural representations of the same software system that differ in the level of abstraction (and hence in the number of components used in the architecture) are studied. Our results show that an architecture at the abstraction level that is sufficient to adequately maps the system's relevant functionalities to the corresponding architectural components (i.e., each component in the architecture corresponds to one system's relevant functionality) significantly improves the architecturelevel understanding of the software system, as compared to two other architectures that have a low and a high number of elements and hence tangles or scatters the system's relevant functionalities into several architectural components

A Variability-Aware Design Approach to the Data Analysis Modeling Process

The massive amount of current data has led to many different forms of data analysis processes that aim to explore this data to uncover valuable insights such as trends, anomalies and patterns. These processes support decision makers in their analysis of varied and changing data ranging from financial transactions to customer interactions and social network postings. These data analysis processes use a wide variety of methods, including machine learning, in several domains such as business, finance, health and smart cities. Several data analysis processes have been proposed by academia and industry, including CRISP-DM and SEMMA, to describe the phases that data analysis experts go through when solving their problems. Specifically, CRISP-DM has modeling as one of its phases, which involves selecting a modeling technique, generating a test design, building a model, and assessing the model. However, automating these data analysis modeling processes faces numerous challenges, from a software engineering perspective. First, software users expect increased flexibility from the software as to the possible variations in techniques, types of data, and parameter settings. The software is required to accommodate complex usage and deployment variations, which are difficult for non-experts. Second, variability in functionality or quality attributes increases the complexity of these systems and makes them harder to design and implement. There is a lack of a framework design that takes variability into account. Third, the lack of a more comprehensive analysis of variability makes it difficult to evaluate opportunities for automating data analysis modeling. This thesis proposes a variability-aware design approach to the data analysis modeling process. The approach involves: (i) the assessment of the variabilities inherent in CRISP-DM data analysis modeling and the provision of feature models that represent these variabilities; (ii) the definition of a preliminary framework design that captures the identified variabilities; and (iii) evaluation of the framework design in terms of possibilities of automation. Overall, this work presents, to the best of our knowledge, the first approach based on variability assessment to design data modeling process such as CRISP-DM. The approach advances the state of the art by offering a variability-aware design a solution that can enhance system flexibility and a novel software design framework to support data analysis modeling

Formalizing and Verifying Design Decisions in Single Systems and Software Product Lines

Master'sMASTER OF SCIENC

Feature-based methodology for supporting architecture refactoring and maintenance of long-life software systems

Zusammenfassung Langlebige Software-Systeme durchlaufen viele bedeutende Veraenderungen im Laufe ihres Lebenszyklus, um der Weiterentwicklung der Problemdomaenen zu folgen. Normalerweise ist es schwierig eine Software-Systemarchitektur den schnellen Weiterentwicklungen einer Problemdomaene anzupassen und mit der Zeit wird der Unterschied zwischen der Problemdomaene und der Software-Systemarchitektur zu groß, um weitere Softwareentwicklung sinnvoll fortzufuehren. Fristgerechte Refactorings der Systemarchitektur sind notwendig, um dieses Problem zu vermeiden. Aufgrund des verhaeltnismaeßig hohen Gefahrenpotenzials und des zeitlich stark verzoegerten Nutzens von Refactorings, werden diese Maßnahmen normalerweise bis zum letztmoeglichen Zeitpunkt hinausgeschoben. In der Regel ist das Management abgeneigt Architektur-Refactorings zu akzeptieren, außer diese sind absolut notwendig. Die bevorzugte Vorgehensweise ist, neue Systemmerkmale ad hoc hinzuzufuegen und nach dem Motto ”Aendere nie etwas an einem funktionierenden System!” vorzugehen. Letztlich ist das Ergebnis ein Architekturzerfall (Architekturdrift). Die Notwendigkeit kleiner Refactoring-Schritte fuehrt zur Notwendigkeit des Architektur-Reengineerings. Im Gegensatz zum Refactoring, das eine normale Entwicklungstaetigkeit darstellt, ist Reengineering eine Form der Software- ”Revolution”. Reengineeringprojekte sind sehr riskant und kostspielig. Der Nutzen des Reengineerings ist normalerweise nicht so hoch wie erwartet. Wenn nach dem Reengineering schließlich die erforderlichen Architekturaenderungen statt.nden, kann dies zu spaet sein. Trotz der enormen in das Projekt gesteckten Bemuehungen erfuellen die Resultate des Reengineerings normalerweise nicht die Erwartungen. Es kann passieren, dass sehr bald ein neues, kostspieliges Reengineering erforderlich wird. In dieser Arbeit werden das Problem der Softwareevolution und der Zerfall von Softwarearchitekturen behandelt. Eine Methode wird vorgestellt, welche die Softwareentwicklung in ihrer entscheidenden Phase, dem Architekturrefactoring, unterstuetzt. Die Softwareentwicklung wird sowohl in technischer als auch organisatorischer Hinsicht unterstuetzt. Diese Arbeit hat neue Techniken entwickelt, welche die Reverse-Engineering-, Architecture-Recovery- und Architecture-Redesign-Taetigkeiten unterst uetzen. Sie schlaegt auch Aenderungen des Softwareentwicklungsprozesses vor, die fristgerechte Architekturrefactorings erzwingen koennen und damit die Notwendigkeit der Durchfuehrung eines Architektur- Reengineerings vermeiden. In dieser Arbeit wird die Merkmalmodellierung als Hauptinstrument verwendet. Merkmale werden genutzt, um die Abstraktionsluecke zwischen den Anforderungen der Problemdomaene und der Systemarchitektur zu fuellen. Merkmalmodelle werden auch als erster Grundriss fr die Wiederherstellung der verlorenen Systemarchitektur genutzt. Merkmalbasierte Analysen fuehren zu diversen, nuetzlichen Hinweisen fuer den erneuten Entwurf (das Re-Design) einer Architektur. Schließlich wird die Merkmalmodellierung als Kommunikationsmittel zwischen unterschiedlichen Projektbeteiligten (Stakeholdern) im Verlauf des Softwareengineering-Prozesses verwendet und auf dieser Grundlage wird ein neuer Anforderungsde.nitionsprozess vorgeschlagen, der die erforderlichen Architekturrefactorings erzwingt.The long-life software systems withstand many significant changes throughout their life-cycle in order to follow the evolution of the problem domains. Usually, the software system architecture can not follow the rapid evolution of a problem domain and with time, the diversion of the architecture in respect to the domain features becomes prohibiting for software evolution. For avoiding this problem, periodical refactorings of the system architecture are required. Usually, architecture refactorings are postponed until the very last moment, because of the relatively high risk involved and the lack of short-term profit. As a rule, the management is unwilling to accept architecture refactorings unless they become absolutely necessary. The preferred way of working is to add new system features in an ad-hoc manner and to keep the rule ”Never touch a running system!”. The final result is an architecture decay. The need of performing small refactoring activities turns into need for architecture reengineering. In contrast to refactoring, which is a normal evolutionary activity, reengineering is a kind of software ”revolution”. Reengineering projects are risky and expensive. The effectiveness of reengineering is also usually not as high as expected. When finally after reengineering the required architecture changes take place, it can be too late. Despite the enormous invested efforts, the results of the reengineering usually do not satisfy the expectations. It might happen that very soon a new expensive reengineering is required. This thesis deals with the problem of software evolution and the decay of software architectures. It presents a method, which assists software evolution in its crucial part, the architecture refactoring. The assistance is performed for both technical and organizational aspects of the software evolution. The thesis provides new techniques for supporting reverse engineering, architecture recovery and redesigning activities. It also proposes changes to the software engineering process, which can force timely architecture refactorings and thus avoid the need of performing architecture reengineering. For the work in this thesis feature modeling is utilized as a main asset. Features are used to fill the abstraction gap between domain requirements and system architecture. Feature models are also used as an outline for recovering of lost system architectures. Through feature-based analyses a number of useful hints and clues for architecture redesign are produced. Finally, feature modeling is used as a communication between different stakeholders of the software engineering process and on this basis a new requirements engineering process is proposed, which forces the needed architecture refactorings

Predicting change propagation using domain-based coupling

Most enterprise systems operate in domains where business rules and requirements frequently change. Managing the cost and impact of these changes has been a known challenge, and the software maintenance community has been tackling it for more than two decades. The traditional approach to impact analysis is by tracing dependencies in the design documents and the source code. More recently the software maintenance history has been exploited for impact analysis. The problem is that these approaches are difficult to implement for hybrid systems that consist of heterogeneous components. In today’s computer era, it is common to find systems of systems where each system was developed in a different language. In such environments, it is a challenge to estimate the change propagation between components that are developed in different languages. There is often no direct code dependency between these components, and they are maintained in different development environments by different developers. In addition, it is the domain experts and consultants who raise the most of the enhancement requests; however, using the existing change impact analysis methods, they cannot evaluate the impact and cost of the proposed changes without the support of the developers. This thesis seeks to address these problems by proposing a new approach to change impact analysis based on software domain-level information. This approach is based on the assumption that domain-level relationships are reflected in the software source code, and one can predict software dependencies and change propagation by exploiting software domain-level information. The proposed approach is independent of the software implementation, inexpensive to implement, and usable by domain experts with no requirement to access and analyse the source code. This thesis introduces domain-based coupling as a novel measure of the semantic similarity between software user interface components. The hypothesis is that the domain-based coupling between software components is correlated with the likelihood of the existence of dependencies and change propagation between these components. This hypothesis has been evaluated with two case studies: • A study of one of the largest open source enterprise systems demonstrates that architectural dependencies can be identified with an accuracy of more than 70% solely based on the domain-based coupling. • A study of 12 years’ maintenance history of the five subsystems of a significant sized proprietary enterprise system demonstrates that the co-change coupling derived from over 75,000 change records can be predicted solely using domain-based coupling, with average recall and precision of more than 60%, which is of comparable quality to other state-of-the-art change impact analysis methods. The results of these studies support our hypothesis that software dependencies and change propagation can be predicted solely from software domain-level information. Although the accuracy of such predictions are not sufficiently strong to completely replace the traditional dependency analysis methods; nevertheless, the presented results suggest that the domain-based coupling might be used as a complementary method or where analysis of dependencies in the code and documents is not a viable option

Using feature modeling for program comprehension and software architecture recovery

Abstract: The available evidence in a legacy software system, which can help in its understanding and recovery of its architecture are not always sufficient. Very often the system’s documentation is poor and outdated. One may argue that the most reliable resource of information is the system’s source code. Nevertheless a significant knowledge about the problem domain is required in order to facilitate the extraction of the system’s useful architectural information. In this approach feature modeling is introduced as an additional step in a system’s architectural recovery process. Feature modeling structures the system’s functionality and supports reverse engineering by detecting the relations between source code elements and requirements. Tracing these relations may lead to a better understanding of the program’s behavior and the recovery of various architectural elements. In this way, by providing a mapping between source code and features, the system’s feature model supports program comprehension and architectural recovery. The approach is developed as first part of a migration methodology towards a component-based architecture of legacy systems. Recovered information about features and architecture is collected in a repository to enable a refactoring as next step. The approach is currently applied in a large project for reengineering of an industrial Image Processing System

Evolution und Komposition von Softwaresystemen: Software-Produktlinien als Beitrag zu Flexibilität und Langlebigkeit

Software systems are today bigger, more complex and of higher importance for products and services than a decade before. At the same time changes are required many more frequently and of a larger size. Furthermore, they have to be implemented faster. Additionally, the software must achieve a higher life span, particularly because of the cost of its development. In the past, Object-Oriented Programming and Reuse techniques did not provide the expected success. The introduction of software product lines respectively system families makes possible it to reach a degree of prefabrication similar to the one of serial production. At the same time they facilitate the delivery of product variants with a short time to market. In this work methods of the methods of domain analysis are integrated with Reuse approaches and techniques of Generative Programming, and a methodology for product line development is presented. Feature models are used as means expressing variability and product configurations, so that the prefabrication be planned and the production of customer-specific products can be controlled. By enforcing the formalization in terms of syntax and semantics, feature models are made accessible to tools and automation. Object-oriented design models and architecture are separated into fine-granular components in such a way that new products can easily be developed as combinations of those components. The implementation of such products is automated by the composition of source code components. The composition of object models separated similarly enables a uninterrupted automation for the product development, which is controlled by a customer by means of a feature selection. To facilitate such a composition, the Hyperspace approach is applied to UML to Hyper/UML, which makes possible a feature-driven separation and composition of object models. In this way slim products can be developed, containing only the actually needed functionality. For the evolution of product lines and for the integration of existing solutions and components into the evolution, Reverse Engineering and Refactoring techniques are integrated. Requirements, models and implementation are connected by Traceability links to perform changes consistently. As a consequence, the loss of architectural quality - so-called Architectural Decay - can be avoided during the iterative development process. Measures for the improvement of the project and quality management are regarded briefly, as far as they are of importance for the effectiveness of the developed methods. The applicability and suitability of the results of the work were examined in several industrial projects.Softwaresysteme sind heute umfangreicher, komplexer und von entscheidenderer Bedeutung für Produkte und Dienstleistungen als eine Dekade zuvor. Gleichzeitig sind Änderungen viel häufiger und in größerem Umfang erforderlich. Sie müssen auch schneller realisierbar sein. Zudem muss die Software eine höhere Lebensdauer erreichen, vor allem wegen des Aufwandes zu ihrer Entwicklung. Objektorientierte Programmierung und Wiederverwendungstechniken haben dabei nicht den erwarteten Erfolg gebracht. Die Einführung von Software-Produktlinien beziehungsweise Systemfamilien ermöglichen es, einen der Serienfertigung ähnlichen Vorfertigungsgrad zu erreichen und erlauben es gleichzeitig, kurzfristig Produktvarianten zu erstellen. In dieser Arbeit werden Methoden der Domänenanalyse mit Wiederverwendungsansätzen und Generativen Programmiertechniken verknüpft und eine Methodik zur Produktlinien-Entwicklung vorgestellt. Featuremodelle werden als Ausdrucksmittel für Variabilität und Produktkonfigurationen eingesetzt, damit die Vorfertigung geplant und die Erstellung von kundenspezifischen Produkten gesteuert werden kann. Durch Präzisierung ihrer Syntax und Erweiterung ihrer Semantik werden Featuremodelle einer Nutzung in Werkzeugen zugänglich gemacht. Objektorientierte Entwurfsmodelle und Architektur werden so in feingranulare Komponenten zerlegt, dass Varianten als neue Produkte mit geringem Aufwand erstellbar sind. Die Erstellung der Implementierung solcher Produkte wird durch die Komposition von Quelltext-Komponenten automatisiert. Die Komposition von ebenfalls zerlegten Objektmodellen ermöglicht eine durchgehende Automatisierung der Produkterstellung, die durch einen Kunden mittels der Feature-Auswahl gesteuert wird. Dafür wird mit Hyper/UML eine Umsetzung des Hyperspace-Ansatzes auf die Modellierungssprache UML entwickelt, die eine Feature-gesteuerte Zerlegung und Komposition von Objektmodellen ermöglicht. Damit lassen sich schlanke Produkte entwickeln, die nur die tatsächlich benötigte Funktionalität enthalten. Zur Evolution von Produktlinien und zur Einbindung existierender Lösungen und Komponenten in die Evolution werden Reverse-Engineering- und Refactoring-Techniken integriert. Anforderungen, Modelle und Implementierung werden durch Traceability-Links verbunden, damit Änderungen konsistent durchgeführt werden können. Diese Mittel tragen dazu bei, dass während einer iterativen Entwicklung der Verlust an Architektur-Qualität, das sogenannte Architectural Decay, vermieden werden kann. Maßnahmen zur Verbesserung des Projekt- und Qualitätsmanagements werden kurz betrachtet, soweit sie wichtige Randbedingungen für die Wirksamkeit der Methoden schaffen müssen. Die Anwendbarkeit und Eignung der Ergebnisse der Arbeiten wurde in mehreren industriellen Projekten überprüft.Ilmenau, Techn. Univ., Habil.-Schr., 200