Environments to support collaborative software engineering

With increasing globalisation of software production, widespread use of software components, and the need to maintain software systems over long periods of time, there has been a recognition that better support for collaborative working is needed by software engineers. In this paper, two approaches to developing improved system support for collaborative software engineering are described: GENESIS and OPHELIA. As both projects are moving towards industrial trials and eventual publicreleases of their systems, this exercise of comparing and contrasting our approaches has provided the basis for future collaboration between our projects particularly in carrying out comparative studies of our approaches in practical use

Architectural reflection for software evolution

Software evolution is expensive. Lehman identifies several problems associated with it: Continuous adaptation, increasing complexity, continuing growth, and declining quality. This paper proposes that a reflective software engineering environment will address these problems by employing languages and techniques from the software architecture community. Creating a software system will involve manipulating a collection of views, including low-level code views and high-level architectural views which will be tied together using reflection. This coupling will allow the development environment to automatically identify inconsistencies between the views, and support software engineers in managing architectures during evolution. This paper proposes a research programme which will result in a software engineering environment which addresses problems of software evolution and the maintenance of consistency between architectural views of a software system

Open-source software product line extraction processes: the ArgoUML-SPL and Phaser cases

Software Product Lines (SPLs) are rarely developed from scratch. Commonly, they emerge from one product when there is a need to create tailored variants, or from existing variants created in an ad-hoc way once their separated maintenance and evolution become challenging. Despite the vast literature about re-engineering systems into SPLs and related technical approaches, there is a lack of detailed analysis of the process itself and the effort involved. In this paper, we provide and analyze empirical data of the extraction processes of two open source case studies, namely ArgoUML and Phaser. Both cases emerged from the transition of a monolithic system into an SPL. The analysis relies on information mined from the version control history of their respective source-code repositories and the discussion with developers that took part in the process. Unlike previous works that focused mostly on the structural results of the final SPL, the contribution of this study is an in-depth characterization of the processes. With this work, we aimed at providing a deeper understanding of the strategies for SPL extraction and their implications. Our results indicate that the source code changes can range from almost a fourth to over half of the total lines of code. Developers may or may not use branching strategies for feature extraction. Additionally, the problems faced during the extraction process may be due to lack of tool support, complexity on managing feature dependencies and issues with feature constraints. We made publicly available the datasets and the analysis scripts of both case studies to be used as a baseline for extractive SPL adoption research and practice.This research was partially funded by CNPq, grant no. 408356/2018-9; FAPPR, grant no. 51435; and FAPERJ PDR-10 Fellowship 202073/2020. Open access funding provided by Johannes Kepler University Lin

Model Based System Engineering for the development of System on Chip

Abstract. Model Based System Engineering (MBSE) has been utilized in auto manufacturing industries, airplane manufacturing and maintenance, and factory process automation industries. These are some of the complex fields. As SoC design is a complex process and requires years of work, MBSE can reduce time, complexity, reuse, and maintenance costs. It seems a fruitful idea/decision to take MBSE into use in SoC design depending on the previously mentioned elements. System on Chip (SoC) is obtaining the interest of many big companies. Therefore, MBSE will represent a huge competitive advantage once it is taken fully into the systems engineering roles of SoC. The existence of geographically dispersed teams, complexity of systems, interdisciplinarity, personalized system description, and their integration can be enabled by MBSE. As an emerging paradigm for the systems of the 21st century, MBSE paved the way for creating successful systems (for the companies) that are end to end connected. This research focuses on making use of MBSE in SoC. The thesis will show how SoC processes can be implemented in one complete model with top to bottom approach. Firstly, the traditional systems engineering approach has been explained with its tools and examples. Secondly, the need for taking up MBSE by the systems engineers is expressed. This contains the applications, use in modern systems, and benefits of MBSE. Moreover, MBSE methodology tools, languages, and their use in SoC is illustrated with examples. As SoC development is a huge and complex process; therefore, a small component of the chip has been taken in consideration for the purpose of understanding and making of the thesis. MBSE is a model-based approach hence a language needs to be present to produce these models and that language is SysML and OPD/OPL. SysML language and MagicDraw tool is used for expressing the architecture of the system. MagicDraw supports several external evaluators for evaluation of expressions and MATLAB is one of them. With MagicDraw we can do simulations, input parameters, and analyze data by processing on it using algorithms developed in MATLAB

A design recording framework to facilitate knowledge sharing in collaborative software engineering

This paper describes an environment that allows a development team to share knowledge about software artefacts by recording decisions and rationales as well as supporting the team in formulating and maintaining design constraints. It explores the use of multi-dimensional design spaces for capturing various issues arising during development and presenting this meta-information using a network of views. It describes a framework to underlie the collaborative environment and shows the supporting architecture and its implementation. It addresses how the artefacts and their meta-information are captured in a non-invasive way and shows how an artefact repository is embedded to store and manage the artefacts

Design Patterns:Supporting Design Process by Automatically Detecting Design Patterns and Giving Some Feedback

Since the nineties, design patterns are of interest. Since the beginning of this century, research is done to the possibilities of recognizing design patterns in source code. There is little research to recognizing design patterns in UML diagrams and possibilities to provide feedback on those designs. This has led to the following research question: Are design patterns in a UML class diagram automatically detectable, and can one automatically supply some feedback? The research question is answered by a literature review followed by creating and testing a prototype, which recognizes design patterns and provides some feedback. In literature UML class diagrams and design patterns are modelled using matrices, decision trees, boolean expressions, Prolog clauses and 4-tuples. Dong describes a method, by which the various types of relationship can be denoted in one matrix. In his article, however, there is no description of the algorithm by which a design pattern can be detected. Unsuccessfully attempt has been made to write a detection algorithm by applying the steepest descent method and Richardson iteration to the method of Dong. Next, four methods for detecting design patterns are compared. The corresponding articles, including the article of Ba-Brahem, contain no description of an algorithm by which design patterns can be detected. The method of Ba-Brahem, which is based on the use of 4-tuples, seemed most promising. This method also offers the possibility to detect design patterns, which are only partially present. It can also be used to give feedback on missing relationships. For the method of Ba-Brahem I have designed and implemented an algorithm, which is able to detect design patterns. The prototype, which implements the method of Ba-Brahem, is able to detect 17 of the 23 Gang of Four patterns. Within one second 13 different design patterns are detected in a class diagram, which contains 57 classes en 61 relationships. In a second experiment a class diagram represented by a XMI files, which contains 33 classes and 49 associations, was used. The XMI file orginates from ArgoUML. This tool is used to design class diagrams. Within one second 17 different design patterns were detected. The prototype is also able to detect design patterns, which are partially present in a class diagram. When a class diagram includes a number of classes and interfaces, which forma design pattern, feedback is specified about the relationships between these classes and interfaces, which are not part of the design pattern. The prototype has made it clear, that instead of a 4-tuple a 3-tuple can be used. One of the attributes of a 4-tuple is intended to indicate whether a class has a self-reference. However, this attribute provides no contribution for the recognition of the Singleton design pattern. An essential characteristic is a self-reference of an object and not a self-reference of a class. The prototype is compared with four programs, which are described in literature. Only one program provides feedback, which is more comprehensive than the feedback from my prototype. Two programs have a graphical user interface, which displays the detected design patterns. How a design patterns is read, is either not disclosed or less simple compared to my prototype. For other issues, such as recall, precision and performance, the score of my prototype is at least equal. The Open University considers to make my prototype user friendly, such that it can be used for educational purposes

Consistent View-Based Management of Variability in Space and Time

Developing variable systems faces many challenges. Dependencies between interrelated artifacts within a product variant, such as code or diagrams, across product variants and across their revisions quickly lead to inconsistencies during evolution. This work provides a unification of common concepts and operations for variability management, identifies variability-related inconsistencies and presents an approach for view-based consistency preservation of variable systems