Project-Team RMoD 2013 Activity Report

Activity Report 2013 Project-Team RMOD Analyses and Languages Constructs for Object-Oriented Application Evolutio

A reference architecture for big data systems

Over dozens of years, applying new IT technologies into organizations has always been a big concern for business. Big data certainly is a new concept exciting business. To be able to access more data and empower to analysis big data requires new big data platforms. However, there still remains limited reference architecture for big data systems. In this paper, based on existing reference architecture of big data systems, we propose new high level abstract reference architecture and related reference architecture notations, that better express the overall architecture. The new reference architecture is verified using one existing case and an additional new use case

Separating gesture detection and application control concerns with a multimodal architecture

Comunicação apresentada na conferência internacional - CIT 2015, realizada de 26-28 de outubro de 2015Gesture-controlled applications typically are tied to specific gestures, and also tied to specific recognition methods and specific gesture-detection devices. We propose a concernseparation architecture, which mediates the following concerns: gesture acquisition; gesture recognition; and gestural control. It enables application developers to respond to gesture-independent commands, recognized using plug-in gesture-recognition modules that process gesture data via both device-dependent and deviceindependent data formats and callbacks. Its feasibility is demonstrated with a sample implementation

Representing Variability in Software Architecture

Software Architecture is a high level description of a software intensive system that enables architects to have a better intellectual control over the complete system. It is also used as a communication vehicle among the various system stakeholders. Variability in software-intensive systems is the ability of a software artefact (e.g., a system, subsystem, or component) to be extended, customised, or configured for deployment in a specific context. Although variability in software architecture is recognised as a challenge in multiple domains, there has been no formal consensus on how variability should be captured or represented. In this research, we addressed the problem of representing variability in software architecture through a three phase approach. First, we examined existing literature using the Systematic Literature Review (SLR) methodology, which helped us identify the gaps and challenges within the current body of knowledge. Equipped with the findings from the SLR, a set of design principles have been formulated that are used to introduce variability management capabilities to an existing Architecture Description Language (ADL). The chosen ADL was developed within our research group (ALI) and to which we have had complete access. Finally, we evaluated the new version of the ADL produced using two distinct case studies: one from the Information Systems domain, an Asset Management System (AMS); and another from the embedded systems domain, a Wheel Brake System (WBS). This thesis presents the main findings from the three phases of the research work, including a comprehensive study of the state-of-the-art; the complete specification of an ADL that is focused on managing variability; and the lessons learnt from the evaluation work of two distinct real-life case studies

Architecture Information Communication in Two OSS Projects: the Why, Who, When, and What

Architecture information is vital for Open Source Software (OSS) development, and mailing list is one of the widely used channels for developers to share and communicate architecture information. This work investigates the nature of architecture information communication (i.e., why, who, when, and what) by OSS developers via developer mailing lists. We employed a multiple case study approach to extract and analyze the architecture information communication from the developer mailing lists of two OSS projects, ArgoUML and Hibernate, during their development life-cycle of over 18 years. Our main findings are: (a) architecture negotiation and interpretation are the two main reasons (i.e., why) of architecture communication; (b) the amount of architecture information communicated in developer mailing lists decreases after the first stable release (i.e., when); (c) architecture communications centered around a few core developers (i.e., who); (d) and the most frequently communicated architecture elements (i.e., what) are Architecture Rationale and Architecture Model. There are a few similarities of architecture communication between the two OSS projects. Such similarities point to how OSS developers naturally gravitate towards the four aspects of architecture communication in OSS development.Comment: Preprint accepted for publication in Journal of Systems and Software, 202

An exploratory case study on reusing architecture decisions in software-intensive system projects

Reusing architecture decisions from previous projects promises to support architects when taking decisions. However, little is known about the state of art of decision-reuse and the benefits and challenges associated with reusing decisions. Therefore, we study how software architects reuse architecture decisions, the stakeholders and their concerns related to decision-reuse, and how architects perceive the ideal future state of decision-reuse. We conducted a qualitative explorative case study in the software-intensive systems industry. The study has shown that architects frequently reuse decisions but are confined to decisions they already know or have heard about. The results also suggest that architects reuse decisions in an ad-hoc manner. Moreover this study presents a conceptual model of decision-reuse and lists stakeholder concerns with regards to decision-reuse. The results of this study indicate that improving the documentation and discoverability of decisions holds a large potential to increase reuse of decisions and that decision documentation is not only important for system understanding or in the context of architecture reviews but also to support architects in upcoming projects

Conception architecturale des systèmes robotiques orientée services

Robotics has experienced an increasing evolution and interest from the society in recent years. Robots are no longer produced exclusively to perform repetitive tasks in factories, they have been designed to collaborate with humans in several important application domains. Robotic systems that control these robots are therefore becoming larger, more complex, and difficult to develop. In this scenario, Service-Oriented Architecture (SOA) has been investigated as a promising architectural style for the design of robotic systems in a flexible, reusable, and productive manner. Despite the existence of a considerable amount of Service-Oriented Robotic Systems (SORS), most of them have been developed in an ad hoc manner. The little attention and limited support devoted to the design of SORS software architectures may not only hamper the benefits of SOA adoption, but also reduce the overall quality of robotic systems, which are often used in safety-critical contexts. This thesis aims at improving the understanding and systematization of SORS architectural design.La Robotique a connu une évolution remarquable au cours des dernières années, couplée à un intérêt croissant de la société pour ce domaine. Les robots ne sont plus fabriqués exclusivement pour effectuer des tâches répétitives dans les usines, mais ils sont aussi créés pour collaborer avec les humains dans plusieurs domaines d'application d'importance. Les systèmes robotiques qui contrôlent ces robots sont donc de plus en plus larges, complexes et difficiles à développer. Dans ce contexte, l'Architecture Orientée Services (SOA) a été identifiée comme un style d'architecture logicielle prometteur pour concevoir des systèmes robotiques de manière flexible, réutilisable et productive. Cependant, malgré le nombre considérable de Systèmes Robotiques Orientées Services (SORS) existants aujourd'hui, la plupart d'entre eux ont été développés de manière ad hoc. Le peu d'attention et le soutien limité portés à la conception d'architectures logicielles SORS peuvent non seulement masquer les avantages de l'adoption de la SOA, mais aussi réduire la qualité globale des systèmes robotiques, qui sont souvent utilisés dans des contextes de sécurité critiques. Cette thèse vise à améliorer la compréhension et la systématisation de la conception architecturale SORS. Elle décrit une taxonomie des services pour le domaine de la robotique, puis propose un processus ainsi qu'une architecture de référence afin de systématiser la conception d'architectures logicielles SORS. Les résultats obtenus dans les études d'évaluation montrent qu'à la fois le processus et l'architecture de référence peuvent avoir un impact positif sur la qualité des architectures logicielles SORS et, par conséquent, contribuent à l'amélioration des systèmes robotique

Architectural design decisions that incur technical debt — An industrial case study

Context: During software development, some architectural design decisions incur technical debt, either deliberately or inadvertently. These have serious impact on the quality of a software system, and can cost significant time and effort to be changed. While current research efforts have explored general concepts of architectural design decisions and technical debt separately, debt-incurring architectural design decisions have not been specifically explored in practice. Objective: In this case study, we explore debt-incurring architectural design decisions (DADDs) in practice. Specifically, we explore the main types of DADDs, why and how they are incurred in a software system, and how practitioners deal with these types of design decisions. Method: We performed interviews and a focus group with practitioners working in embedded and enterprise software companies, discussing their concrete experience with such architectural design decisions. Results: We provide the following contributions: 1) A categorization for the types of DADDs, which extend a current ontology on architectural design decisions. 2) A process on how deliberate DADDs are made in practice. 3) A conceptual model which shows the relationships between the causes and triggers of inadvertent DADDs. 4) The main factors that influence the way of dealing with DADDs. Conclusion: The results can support the development of new approaches and tools for Architecture Technical Debt management from the perspective of Design Decisions. Moreover, they support future research to capture architecture knowledge related to DADDs