Exploring Maintainability Assurance Research for Service- and Microservice-Based Systems: Directions and Differences

To ensure sustainable software maintenance and evolution, a diverse set of activities and concepts like metrics, change impact analysis, or antipattern detection can be used. Special maintainability assurance techniques have been proposed for service- and microservice-based systems, but it is difficult to get a comprehensive overview of this publication landscape. We therefore conducted a systematic literature review (SLR) to collect and categorize maintainability assurance approaches for service-oriented architecture (SOA) and microservices. Our search strategy led to the selection of 223 primary studies from 2007 to 2018 which we categorized with a threefold taxonomy: a) architectural (SOA, microservices, both), b) methodical (method or contribution of the study), and c) thematic (maintainability assurance subfield). We discuss the distribution among these categories and present different research directions as well as exemplary studies per thematic category. The primary finding of our SLR is that, while very few approaches have been suggested for microservices so far (24 of 223, ?11%), we identified several thematic categories where existing SOA techniques could be adapted for the maintainability assurance of microservices

Architecting system of systems: artificial life analysis of financial market behavior

This research study focuses on developing a framework that can be utilized by system architects to understand the emergent behavior of system architectures. The objective is to design a framework that is modular and flexible in providing different ways of modeling sub-systems of System of Systems. At the same time, the framework should capture the adaptive behavior of the system since evolution is one of the key characteristics of System of Systems. Another objective is to design the framework so that humans can be incorporated into the analysis. The framework should help system architects understand the behavior as well as promoters or inhibitors of change in human systems. Computational intelligence tools have been successfully used in analysis of Complex Adaptive Systems. Since a System of Systems is a collection of Complex Adaptive Systems, a framework utilizing combination of these tools can be developed. Financial markets are selected to demonstrate the various architectures developed from the analysis framework --Introduction, page 3

From evolutionary computation to the evolution of things

Evolution has provided a source of inspiration for algorithm designers since the birth of computers. The resulting field, evolutionary computation, has been successful in solving engineering tasks ranging in outlook from the molecular to the astronomical. Today, the field is entering a new phase as evolutionary algorithms that take place in hardware are developed, opening up new avenues towards autonomous machines that can adapt to their environment. We discuss how evolutionary computation compares with natural evolution and what its benefits are relative to other computing approaches, and we introduce the emerging area of artificial evolution in physical systems

Guidelines for architecting android apps:A mixed-method empirical study

For surviving in the highly competitive market of Android apps, it is fundamental for app developers to deliver apps of high quality and with short release times. A well architected Android app is beneficial for developers, e.g. in terms of maintainability, testability, performance, and avoidance of resource leaks. However, how to properly architect Android apps is still debated and subject to conflicting opinions usually influenced by technological hypes rather than objective evidence. In this paper we present an empirical study on how developers architect Android apps, what architectural patterns and practices Android apps are based on, and their potential impact on quality. We apply a mixed-method empirical research design that combines (i) semi-structured interviews with Android practitioners in the field and (ii) a systematic analysis of both the grey (i.e., websites, on-line blogs) and white literature (i.e., academic studies) on the architecture of Android apps. Based on the analysis of the state of the art and practice about architecting Android apps, we systematically extract a set of 42 evidence based guidelines supporting developers when architecting their Android apps

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

A Quantitative Approach to Assessing System Evolvability

When selecting a system from multiple candidates, the customer seeks the one that best meets his or her needs. Recently the desire for evolvable systems has become more important and engineers are striving to develop systems that accommodate this need. In response to this search for evolvability, we present a historical perspective on evolvability, propose a refined definition of evolvability, and develop a quantitative method for measuring this property. We address this quantitative methodology from both a theoretical and practical perspective. This quantitative model is then applied to the problem of evolving a lunar mission to a Mars mission as a case study

On microelectronic self-learning cognitive chip systems

After a brief review of machine learning techniques and applications, this Ph.D. thesis examines several approaches for implementing machine learning architectures and algorithms into hardware within our laboratory. From this interdisciplinary background support, we have motivations for novel approaches that we intend to follow as an objective of innovative hardware implementations of dynamically self-reconfigurable logic for enhanced self-adaptive, self-(re)organizing and eventually self-assembling machine learning systems, while developing this new particular area of research. And after reviewing some relevant background of robotic control methods followed by most recent advanced cognitive controllers, this Ph.D. thesis suggests that amongst many well-known ways of designing operational technologies, the design methodologies of those leading-edge high-tech devices such as cognitive chips that may well lead to intelligent machines exhibiting conscious phenomena should crucially be restricted to extremely well defined constraints. Roboticists also need those as specifications to help decide upfront on otherwise infinitely free hardware/software design details. In addition and most importantly, we propose these specifications as methodological guidelines tightly related to ethics and the nowadays well-identified workings of the human body and of its psyche

Risks, Safety and Security in the Ecosystem of Smart Cities

We have performed a review of systemic risks in smart cities dependent on intelligent and partly autonomous transport systems. Smart cities include concepts such as smart transportation/use of autonomous transportation systems (i.e., autonomous cars, subways, shipping, drones) and improved management of infrastructure (power and water supply). At the same time, this requires safe and resilient infrastructures and need for global collaboration. One challenge is some sort of risk based regulation of emergent vulnerabilities. In this paper we focus on emergent vulnerabilities and discussion of how mitigation can be organized and structured based on emergent and known scenarios cross boundaries. We regard a smart city as a software ecosystem (SEC), defined as a dynamic evolution of systems on top of a common technological platform offering a set of software solutions and services. Software ecosystems are increasingly being used to support critical tasks and operations. As a part of our work we have performed a systematic literature review of safety, security and resilience software ecosystems, in the period 2007–2016. The perspective of software ecosystems has helped to identify and specify patterns of safety, security and resilience on a relevant abstraction level. Significant vulnerabilities and poor awareness of safety, security and resilience has been identified. Key actors that should increase their attention are vendors, regulators, insurance companies and the research community. There is a need to improve private-public partnership and to improve the learning loops between computer emergency teams, security information providers (SIP), regulators and vendors. There is a need to focus more on safety, security and resilience and to establish regulations of responsibilities on the vendors for liabilities