Documenting after the fact: Recovering architectural design decisions

Software architecture documentation helps people in understanding the software architecture of a system. In practice, software architectures are often documented after the fact, i.e. they are maintained or created after most of the design decisions have been made and implemented. To keep the architecture documentation up-to-date an architect needs to recover and describe these decisions.This paper presents ADDRA, an approach an architect can use for recovering architectural design decisions after the fact. ADDRA uses architectural deltas to provide the architect with clues about these design decisions. This allows the architect to systematically recover and document relevant architectural design decisions. The recovered architectural design decisions improve the documentation of the architecture, which increases traceability, communication, and general understanding of a system.     

An exploratory study of architectural effects on requirements decisions

The question of the “manner in which an existing software architecture affects requirements decision-making” is considered important in the research community; however, to our knowledge, this issue has not been scientifically explored. We do not know, for example, the characteristics of such architectural effects. This paper describes an exploratory study on this question. Specific types of architectural effects on requirements decisions are identified, as are different aspects of the architecture together with the extent of their effects. This paper gives quantitative measures and qualitative interpretation of the findings. The understanding gained from this study has several implications in the areas of: project planning and risk management, requirements engineering (RE) and software architecture (SA) technology, architecture evolution, tighter integration of RE and SA processes, and middleware in architectures. Furthermore, we describe several new hypotheses that have emerged from this study, that provide grounds for future empirical work. This study involved six RE teams (of university students), whose task was to elicit new requirements for upgrading a pre-existing banking software infrastructure. The data collected was based on a new meta-model for requirements decisions, which is a bi-product of this study.     

An empirical analysis of information retrieval based concept location techniques in software comprehension

Concept location, the problem of associating human oriented concepts with their counterpart solution domain concepts, is a fundamental problem that lies at the heart of software comprehension. Recent research has attempted to alleviate the impact of the concept location problem through the application of methods drawn from the information retrieval (IR) community. Here we present a new approach based on a complimentary IR method which also has a sound basis in cognitive theory. We compare our approach to related work through an experiment and present our conclusions. This research adapts and expands upon existing language modelling frameworks in IR for use in concept location, in software systems. In doing so it is novel in that it leverages implicit information available in system documentation. Surprisingly, empirical evaluation of this approach showed little performance benefit overall and several possible explanations are forwarded for this finding.

Can observational techniques help novices overcome the software inspection learning curve? An empirical investigation

When learning a new software engineering technique, there is a learning curve that must be overcome. In particular, when studies are conducted in a classroom setting, researchers need a method for quickly accelerating the experience of novice subjects to allow the results to be more applicable in industrial settings. In this paper, we propose and test a method to enable novices to gain process experience to allow them to more quickly overcome the learning curve. The method we evaluate allows an inspector to gain experience with the inspection process by observing an inspection performed by someone else. The results of the study show that the proposed method for gaining experience appears to be useful in some limited cases, that is, for low experienced subjects who were inspecting a requirements document from a domain in which they had low knowledge. Based on the results of this study, we are able to propose some new related hypotheses to be tested in future studies.     

Advanced quality prediction model for software architectural knowledge sharing

In the field of software architecture, a paradigm shift is occurring from describing the outcome of architecting process to describing the Architectural Knowledge (AK) created and used during architecting. Many AK models have been defined to represent domain concepts and their relationships, and they can be used for sharing and reusing AK across organizations, especially in geographically distributed contexts. However, different AK domain models can represent concepts that are different, thereby making effective AK sharing challenging. In order to understand the mapping quality from one AK model to another when more than one AK model coexists, AK sharing quality prediction based on the concept differences across AK models is necessary. Previous works in this area lack validation in the actual practice of AK sharing. In this paper, we carry out validation using four AK sharing case studies. We also improve the previous prediction models. We developed a new advanced mapping quality prediction model, this model (i) improves the prediction accuracy of the recall rate of AK sharing quality; (ii) provides a better balance between prediction effort and accuracy for AK sharing quality.     

Requirements-document-based prototyping of CARA software

Computer-aided prototyping evaluates and refines software requirements by defining requirements specifications, designing underlying compositional architecture, doing restricted real-time scheduling, and constructing a prototype by using reusable executable software components. This paper presents a case study of the Computer Assisted Resuscitation Algorithm (CARA) software for a casualty intravenous fluid infusion pump and explores the effectiveness of performing rapid prototyping with parallel conceptualization to expose requirements issues. Using a suite of prototyping tools, five different design model alternatives are generated based on the analysis of customer requirements documents. Further comparison is conducted with specific focus on a sample of comparative criteria: simplicity of design, safety aspects, requirements coverage, and enabling architecture. The case study demonstrates the usefulness of comparative rapid prototyping for revealing the omissions and discrepancies in the requirements document. The study also illustrates the efficiency of creating/modifying parallel models and reason for their complexity by using the tool suite. Additional enhancements for the prototyping suite are highlighted.     

Using software evolution to focus architectural recovery

Ideally, a software project commences with requirements gathering and specification, reaches its major milestone with system implementation and delivery, and then continues, possibly indefinitely, into an operation and maintenance phase. The software system's architecture is in many ways the linchpin of this process: it is supposed to be an effective reification of the system's technical requirements and to be faithfully reflected in the system's implementation. Furthermore, the architecture is meant to guide system evolution, while also being updated in the process. However, in reality developers frequently deviate from the architecture, causing architectural erosion, a phenomenon in which the initial, “as documented' architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold. Architectural recovery is a process frequently used to cope with architectural erosion whereby the current, “as implemented” architecture of a software system is extracted from the system's implementation. In this paper we propose a light-weight approach to architectural recovery, called Focus, which has three unique facets. First, Focus uses a system's evolution requirements to isolate and incrementally recover only the fragment of the system's architecture affected by the evolution. In this manner, Focus allows engineers to direct their primary attention to the part of the system that is immediately impacted by the desired change; subsequent changes will incrementally uncover additional parts of the system's architecture. Secondly, in addition to software components, which are the usual target of existing recovery approaches, Focus also recovers the key architectural notions of software connector and architectural style. Finally, Focus does not only recover a system's architecture, but may in fact rearchitect the system. We have applied and evaluated Focus in the context of several off-the-shelf applications and architectural styles to date. We discuss its key strengths and point out several open issues that will frame our future work.     

Classifying architectural constraints as a basis for software quality assessment

Architectural styles and patterns have been studied since the inception of software architecture as a discipline. We generalise architectural styles, patterns and similar concepts by introducing the notion of architectural constraints. An architectural constraint is a vehicle for the reuse of architectural design knowledge and for the improvement of software quality. It may be used for improving architectural analyses of quality characteristics of the software system to be realised. We present the method for surveying the literature on architectural constraint concepts, and provide a taxonomy covering various definitions of architectural styles and patterns.     

Quality of manual data collection in Java software: an empirical investigation

Data collection, both automatic and manual, lies at the heart of all empirical studies. The quality of data collected from software informs decisions on maintenance, testing and wider issues such as the need for system re-engineering. While of the two types stated, automatic data collection is preferable, there are numerous occasions when manual data collection is unavoidable. Yet, very little evidence exists to assess the error-proneness of the latter. Herein, we investigate the extent to which manual data collection for Java software compared with its automatic counterpart for the same data. We investigate three hypotheses relating to the difference between automated and manual data collection. Five Java systems were used to support our investigation. Results showed that, as expected, manual data collection was error-prone, but nowhere near the extent we had initially envisaged. Key indicators of mistakes in manual data collection were found to be poor developer coding style, poor adherence to sound OO coding principles, and the existence of relatively large classes in some systems. Some interesting results were found relating to the collection of public class features and the types of error made during manual data collection. The study thus offers an insight into some of the typical problems associated with collecting data manually; more significantly, it highlights the problems that poorly written systems have on the quality of visually extracted data.     

Class movement and re-location: An empirical study of Java inheritance evolution

Inheritance is a fundamental feature of the Object-Oriented (OO) paradigm. It is used to promote extensibility and reuse in OO systems. Understanding how systems evolve, and specifically, trends in the movement and re-location of classes in OO hierarchies can help us understand and predict future maintenance effort. In this paper, we explore how and where new classes were added as well as where existing classes were deleted or moved across inheritance hierarchies from multiple versions of four Java systems. We observed first, that in one of the studied systems the same set of classes was continuously moved across the inheritance hierarchy. Second, in the same system, the most frequent changes were restricted to just one sub-part of the overall system. Third, that a maximum of three levels may be a threshold when using inheritance in a system; beyond this level very little activity was observed, supporting earlier theories that, beyond three levels, complexity becomes overwhelming. We also found evidence of ‘collapsing’ hierarchies to bring classes up to shallower levels. Finally, we found that larger classes and highly coupled classes were more frequently moved than smaller and less coupled classes. Statistical evidence supported the view that larger classes and highly coupled classes were less cohesive than smaller classes and lowly coupled classes and were thus more suitable candidates for being moved (within an hierarchy).     

An architectural approach to the correct and automatic assembly of evolving component-based systems

Software components are specified, designed and implemented with the intention to be reused, and they are assembled in various contexts in order to produce a multitude of software systems. However, in the practice of software development, this ideal scenario is often unrealistic. This is mainly due to the lack of an automatic and efficient support to predict properties of the assembly code by only assuming a limited knowledge of the properties of single components. Moreover, to make effective the component-based vision, the assembly code should evolve when things change, i.e., the properties guaranteed by the assembly, before a change occurs, must hold also after the change. Glue code synthesis approaches technically permit one to construct an assembly of components that guarantees specific properties but, practically, they may suffer from the state-space explosion phenomenon.In this paper, we propose a Software Architecture (SA) based approach in which the usage of the system SA and of SA verification techniques allows the system assembler to design architectural components whose interaction is verified with respect to the specified properties. By exploiting this validation, the system assembler can perform code synthesis by only focusing on each single architectural component, hence refining it as an assembly of actual components which respect the architectural component observable behaviour. In this way code synthesis is performed locally on each architectural component, instead of globally on the whole system interactions, hence reducing the state-space explosion phenomenon.The approach can be equally well applied to efficiently manage the whole reconfiguration of the system when one or more components need to be updated, still maintaining the required properties. The specified and verified system SA is used as starting point for the derivation of glue adaptors that are required to apply changes in the composed system. The approach is firstly illustrated over an explanatory example and is then applied and validated over a real-world industrial case study.     

An investigation of the maintenance and support characteristics of commercial software

This study demonstrates an objective method used to evaluate the enhanceability of commercial software. It examines the relationship between enhancement and repair, and suggests that enhancement be considered when developing formal models of defect cause. Another definition of defect-prone software is presented that concentrates attention on software that requires unusually high repair considering the magnitude of planned enhancement.     

On the use of software design models in software development practice: An empirical investigation

Research into software design models in general, and into the UML in particular, focuses on answering the question how design models are used, completely ignoring the question if they are used. There is an assumption in the literature that the UML is the de facto standard, and that use of design models has had a profound and substantial effect on how software is designed by virtue of models giving the ability to do model-checking, code generation, or automated test generation. However for this assumption to be true, there has to be significant use of design models in practice by developers.This paper presents the results of a survey summarizing the answers of 3785 developers answering the simple question on the extent to which design models are used before coding. We relate their use of models with (i) total years of programming experience, (ii) open or closed development, (iii) educational level, (iv) programming language used, and (v) development type.The answer to our question was that design models are not used very extensively in industry, and where they are used, the use is informal and without tool support, and the notation is often not UML. The use of models decreased with an increase in experience and increased with higher level of qualification. Overall we found that models are used primarily as a communication and collaboration mechanism where there is a need to solve problems and/or get a joint understanding of the overall design in a group. We also conclude that models are seldom updated after initially created and are usually drawn on a whiteboard or on paper.