Henry Muccini

Using software architecture for code testing

Our research deals with the use of software architecture (SA) as a reference model for testing the conformance of an implemented system with respect to its architectural specification. We exploit the specification of SA dynamics to identify useful schemes of interactions between system components and to select test classes corresponding to relevant architectural behaviors. The SA dynamics is modeled by labeled transition systems (LTSs). The approach consists of deriving suitable LTS abstractions called ALTSs. ALTSs offer specific views of SA dynamics by concentrating on relevant features and abstracting away from uninteresting ones. Intuitively, deriving an adequate set of test classes entails deriving a set of paths that appropriately cover the ALTS. Next, a relation between these abstract SA tests and more concrete, executable tests needs to be established so that the architectural tests derived can be refined into code-level tests. We use the TRMCS case study to illustrate our hands-on experience. We discuss the insights gained and highlight some issues, problems, and solutions of general interest in architecture-based testing.

Software testing of mobile applications: challenges and future research directions

While mobile applications are becoming so extraordinarily adopted, it is still unclear if they deserve any specific testing approach for their verification and validation. This paper wants to investigate new research directions on mobile applications testing automation, by answering three research questions: (RQ1) are mobile applications (so) different from traditional ones, so to require different and specialized new testing techniques?, (RQ2) what are the new challenges and research directions on testing mobile applications?, and (RQ3) which is the role automation may play in testing mobile applications?. We answer those questions by analyzing the current state of the art in mobile applications development and testing, and by proposing our view on the topic.

Towards Testing Product Line Architectures

Abstract A product line architecture is a single specification capturing the overall architecture of a series of closely related products. Its structure consists of a set of mandatory elements and a set of variation points. Whereas mandatory elements are part of the architecture of every product in the product line architecture, variation points precisely define the dimensions along which the architectures of individual products differ from each other. The increased use of product line architectures in todays software development projects poses several challenges for existing testing techniques. In this paper we discuss those challenges and discuss what we believe are opportunities for addressing them.

Deriving test plans from architectural descriptions

The paper presents an approach for deriving test plans for the conformance testing of a system implementation with respect to the formal description of its software architecture (SA). The SA describes a system in terms of its components and connections, therefore the derived test plans address the integration testing phase. We base our approach on a labelled transition system (LTS) modeling the SA dynamics, and on suitable abstractions of it, the Abstract Labelled Transition Systems (ALTSs). ALTSs offer specific views of the SA dynamics by concentrating on relevant features and abstracting away from uninteresting ones. ALTS is a tool we provide to the software architect that lets him/her focus on relevant behavioral patterns and more easily identify those that are meaningful for validation purposes. Intuitively, deriving an adequate set of functional test classes means deriving a set of paths appropriately covering the ALTS. We describe our approach in the scope of a real world case study and discuss in detail all the steps of our methodology, from ALTS identification to test plan generation.

CHARMY: A Framework for Designing and Verifying Architectural Specifications

Introduced in the early stages of software development, the Charmy framework assists the software architect in making and evaluating architectural choices. Rarely, the software architecture of a system can be established once and forever. Most likely poorly defined and understood architectural constraints and requirements force the software architect to accept ambiguities and move forward to the construction of a suboptimal software architecture. Charmy aims to provide an easy and practical tool for supporting the iterative modeling and evaluation of software architectures. From an UML-based architectural design, an executable prototype is automatically created. Charmy simulation and model checking features help in understanding the functioning of the system and discovering potential inconsistencies of the design. When a satisfactory and stable software architecture is reached, Java code conforming to structural software architecture constraints is automatically generated through suitable transformations. The overall approach is tool supported.

Introducing a Reasonably Complete and Coherent Approach for Model-based Testing

Both in the component- and object-based contexts it is extremely important to derive as early as possible suitable test cases based on the UML specifications available during development. In this paper we focus on the integrated use of Sequence and State Diagrams for deriving a “reasonably” complete reference model, which will then be used for automatically deriving the test cases. The approach is meant to overcome some of the limitations of previously proposed model-based testing solutions, and is specifically conceived for industrial contexts, in which methodologies for producing effective test results soon, and even when the software is only partially modelled, are required.

A scoped approach to traceability management

Traceability is the ability to describe and follow the life of a software artifact and a means for modeling the relations between software artifacts in an explicit way. Traceability has been successfully applied in many software engineering communities and has recently been adopted to document the transition among requirements, architecture and implementation. We present an approach to customize traceability to the situation at hand. Instead of automating tracing, or representing all possible traces, we scope the traces to be maintained to the activities stakeholders must carry out. We define core traceability paths, consisting of essential traceability links required to support the activities. We illustrate the approach through two examples: product derivation in software product lines, and release planning in software process management. By using a running software product line example, we explain why the core traceability paths identified are needed when navigating from feature to structural models and from family to product level and backward between models used in software product derivation. A feasibility study in release planning carried out in an industrial setting further illustrates the use of core traceability paths during production and measures the increase in performance of the development processes supported by our approach. These examples show that our approach can be successfully used to support both product and process traceability in a pragmatic yet efficient way.

A classification and comparison of model checking software architecture techniques

Software architecture specifications are used for many different purposes, such as documenting architectural decisions, predicting architectural qualities before the system is implemented, and guiding the design and coding process. In these contexts, assessing the architectural model as early as possible becomes a relevant challenge. Various analysis techniques have been proposed for testing, model checking, and evaluating performance based on architectural models. Among them, model checking is an exhaustive and automatic verification technique, used to verify whether an architectural specification conforms to expected properties. While model checking is being extensively applied to software architectures, little work has been done to comprehensively enumerate and classify these different techniques. The goal of this paper is to investigate the state-of-the-art in model checking software architectures. For this purpose, we first define the main activities in a model checking software architecture process. Then, we define a classification and comparison framework and compare model checking software architecture techniques according to it.

Automated check of architectural models consistency using SPIN

In recent years the necessity for handling different aspects of the system separately has introduced the need to represent SA (software architectures) from different viewpoints. In particular, behavioral views are recognized to be one of the most attractive features in the SA description, and in practical contexts, state diagrams and scenarios are the most widely used tools to model this view. Although very expressive, this approach has two drawbacks: system specification incompleteness and view consistency. Our work can be put in this context with the aim of managing incompleteness and checking view conformance: we propose the use of state diagrams and scenario models for representing system dynamics at the architectural level; they can be incomplete and we want to prove that they describe, from different viewpoints, the same system behavior. To reach this goal, we use the SPIN model checker and we implement a tool to manage the translation of architectural models in Promela and LTL.

Software architecture-based regression testing

Abstract Software architectures are becoming centric to the development of quality software systems, being the first concrete model of the software system and the base to guide the implementation of software systems. When architecting dependable systems, in addition to improving system dependability by means of construction (fault-tolerant and redundant mechanisms, for instance), it is also important to evaluate, and thereby confirm, system dependability. There are many different approaches for evaluating system dependability, and testing has been always an important one, being fault removal one of the means to achieve dependable systems. Previous work on software architecture-based testing has shown it is possible to apply conformance testing techniques to yield some confidence on the implemented system conformance to expected, architecture-level, behaviors. This work explores how regression testing can be systematically applied at the software architecture level in order to reduce the cost of retesting modified systems, and also to assess the regression testability of the evolved system. We consider assessing both “low-level” and “high-level” evolution, i.e., whether a slightly modified implementation conforms to the initial architecture, and whether the implementation continues to conform to an evolved architecture. A better understanding on how regression testing can be applied at the software architecture level will help us to assess and identify architecture with higher dependability.