Rafael Capilla

A comparative study of architecture knowledge management tools

Recent research suggests that architectural knowledge, such as design decisions, is important and should be recorded alongside the architecture description. Different approaches have emerged to support such architectural knowledge (AK) management activities. However, there are different notions of and emphasis on what and how architectural activities should be supported. This is reflected in the design and implementation of existing AK tools. To understand the current status of software architecture knowledge engineering and future research trends, this paper compares five architectural knowledge management tools and the support they provide in the architecture life-cycle. The comparison is based on an evaluation framework defined by a set of 10 criteria. The results of the comparison provide insights into the current focus of architectural knowledge management support, their advantages, deficiencies, and conformance to the current architectural description standard. Based on the outcome of this comparison a research agenda is proposed for future work on AK tools.

A web-based tool for managing architectural design decisions

Software architectures represent the design for describing the main parts of a software system. In software projects, different stakeholders with different roles may need to share the documentation generated during the project. Also, during the architecture construction phase we need to communicate the architecture to the stakeholders involved in the process, but the lack of tools for documenting, managing and sharing this architectural knowledge constitutes a big barrier. In other cases it can be useful to recreate the design decisions taken because such decisions are frequently lost during the development process. To cover these issues, we outline in this paper a web-based tool able to record and manage architecture design decisions.

An overview of Dynamic Software Product Line architectures and techniques: Observations from research and industry

Over the last two decades, software product lines have been used successfully in industry for building families of systems of related products, maximizing reuse, and exploiting their variable and configurable options. In a changing world, modern software demands more and more adaptive features, many of them performed dynamically, and the requirements on the software architecture to support adaptation capabilities of systems are increasing in importance. Today, many embedded system families and application domains such as ecosystems, service-based applications, and self-adaptive systems demand runtime capabilities for flexible adaptation, reconfiguration, and post-deployment activities. However, as traditional software product line architectures fail to provide mechanisms for runtime adaptation and behavior of products, there is a shift toward designing more dynamic software architectures and building more adaptable software able to handle autonomous decision-making, according to varying conditions. Recent development approaches such as Dynamic Software Product Lines (DSPLs) attempt to face the challenges of the dynamic conditions of such systems but the state of these solution architectures is still immature. In order to provide a more comprehensive treatment of DSPL models and their solution architectures, in this research work we provide an overview of the state of the art and current techniques that, partially, attempt to face the many challenges of runtime variability mechanisms in the context of Dynamic Software Product Lines. We also provide an integrated view of the challenges and solutions that are necessary to support runtime variability mechanisms in DSPL models and software architectures.

Modeling and Documenting the Evolution of Architectural Design Decisions

All software systems are built as a result of a set of design decisions that are made during the architecting phase. At present, there is still a lack of appropriate notations, methods and tools for recording and exploiting these architectural design decisions. In addition, the need for maintaining and evolving the decisions made in the past turns critical for the success of the evolution of the system. In this research paper we extend a previous work to detail those issues related to the evolution of architectural design decisions.

Systems and Software Variability Management: Concepts, Tools and Experiences

The success of product line engineering techniques in the last 15 years has popularized the use of software variability as a key modeling approach for describing the commonality and variability of systems at all stages of the software lifecycle. Software product lines enable a family of products to share a common core platform, while allowing for product specific functionality being built on top of the platform. Many companies have exploited the concept of software product lines to increase the resources that focus on highly differentiating functionality and thus improve their competitiveness with higher quality and reusable products and decreasing the time-to-market condition. Many books on product line engineering either introduce specific product line techniques or include brief summaries of industrial cases. From these sources, it is difficult to gain a comprehensive understanding of the various dimensions and aspects of software variability. Here the editors address this gap by providing a comprehensive reference on the notion of variability modeling in the context of software product line engineering, presenting an overview of the techniques proposed for variability modeling and giving a detailed perspective on software variability management. Their book is organized in four main parts, which guide the reader through the various aspects and dimensions of software variability. Part 1 which is mostly written by the editors themselves introduces the major topics related to software variability modeling, thus providing a multi-faceted view of both technological and management issues. Next, part 2 of the book comprises four separate chapters dedicated to research and commercial tools. Part 3 then continues with the most practical viewpoint of the book presenting three different industry cases on how variability is managed in real industry projects. Finally, part 4 concludes the book and encompasses six different chapters on emerging research topics in software variability like e.g. service-oriented or dynamic software product lines, or variability and aspect orientation. Each chapter briefly summarizes What you will learn in this chapter, so both expert and novice readers can easily locate the topics dealt with. Overall, the book captures the current state of the art and best practices, and indicates important open research challenges as well as possible pitfalls. Thus it serves as a reference for researchers and practitioners in software variability management, allowing them to develop the next set of solutions, techniques and methods in this complicated and yet fascinating field of software engineering.

The decision view of software architecture

Documenting software architectures is a key aspect to achieve success when communicating the architecture to different stakeholders. Several architectural views have been used with different purposes during the design process. The traditional view on software architecture defines this in terms of components and connectors. Also, the “4+1” view model proposes several views from the same design to satisfy the interests of the different stakeholders involved in the modelling process. In this position paper we try to go a step beyond previous proposals, to detail the idea of considering the architecture as a composition of architectural design decisions. We will propose a set of elements, information and graphical notation to record the design decisions during the modelling process.

Dynamic Variability in Software-Intensive Embedded System Families

Dynamic software product lines address many of the challenges of building highly configurable software and use runtime variability mechanisms to support automatic decision making.

The value of design rationale information

A complete and detailed (full) Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, this is typically too onerous for systematic industrial use as it is not cost effective to write, maintain, or read. The key idea investigated in this article is that DRD should be developed only to the extent required to support activities particularly difficult to execute or in need of significant improvement in a particular context. The aim of this article is to empirically investigate the customization of the DRD by documenting only the information items that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a specific DRD information item depends on its category (e.g., assumptions, related requirements, etc.) and on the activity it is meant to support. We investigate this hypothesis through two controlled experiments involving a total of 75 master students as experimental subjects. Results show that the value of a DRD information item significantly depends on its category and, within a given category, on the activity it supports. Furthermore, on average among activities, documenting only the information items that have been required at least half of the time (i.e., the information that will probably be required in the future) leads to a customized DRD containing about half the information items of a full documentation. We expect that such a significant reduction in DRD information should mitigate the effects of some inhibitors that currently prevent practitioners from documenting design decision rationale.

Light-weight product-lines for evolution and maintenance of Web sites

Software reengineering and maintenance are two classical activities in software engineering. Today, software maintenance is a time consuming task because requirements change and evolve frequently. Moreover, in certain domains, such as the Web domain is, these changes happen very often. In this way, new techniques to engineer Web sites are needed in order to reduce the time to market of Web products. In this work we describe the process of creation of a product-line using reengineering techniques, from already available products, applied to the Web domain. The aims of setting-up this product-line are to ease the maintenance of Web sites, and to accelerate the development of new ones. A product-line captures the common and variable aspects of software systems as key assets, under a common architecture in order to reduce the time to market of new software products; and software companies are increasingly adopting this approach. The reason for this is because Web maintenance operations must be often performed in a very short time, frequently motivated by changes in the customer requirements that usually expect to obtain results in a few days or weeks.

Modeling the Variability of Web Services from a Pattern Point of View

In the last couple of years, Web services have been used in the development of Web systems, which are often composed by interoperable components. These interoperable components cooperate under a Client/Server style to accomplish the application integration and it is aimed to use the service components in several systems. Therefore, the development of such Web services, as high quality and reusable components is a goal to achieve. In this sense, suitable design and modeling techniques can improve the customisation of similar services built by one or more service provider. On the other hand, the development, the management and evolution of many modern software systems rely on the notion of variability and pattern-based approaches as suitable design techniques. In this work we will try to describe how the development of Web systems using Web services can be improved with a suitable description of the variability as a technique for building and customizing similar systems. We will focus on the modelling of variability of Web services from a pattern point of view.