Using non-functional requirements in component-based software construction

The main concern of this paper is to present the author's approach to support software development in the component programming framework taking functional and non-functional requirements into account. Functional requirements are written as algebraic specifications, while non-functional information is bound to specifications and implementations by means of ad hoc modules: the nonfunctional information is used to select automatically the most appropriate implementations of software components (the selection algorithm is not presented here). The existence of multiple type implementations is supported by a process model based on the prototyping paradigm. Prototyping is achieved by means of a mixed execution mechanism being able to operate in the context of incremental software development process allowing the execution of incomplete (partially implemented) systems. The ideas we present here are not bound to any particular programming language, giving rise to a method of wide applicability.Peer ReviewedPostprint (published version

Supporting software maintenance with non-functional information

The paper highlights the role of non functional information (about efficiency, reliability and other software attributes) of software components in software maintenance, focusing in the component programming framework. Non functional information is encapsulated in modules bound to both definitions and implementations of software components and it is written as expressions in a classical programming language. It is shown with an example how this notation supports software maintenance, with the help of an algorithm which is able to select the best implementation of a software component in its context of use, meaning byPeer ReviewedPostprint (published version

Loop squashing transformations for amorphous slicing

Program slicing is a source code extraction technique that can be used to support reverse engineering by automatically extracting executable subprograms that preserve some aspect of the original program's semantics. Although minimal slices are not generally computable, safe approximate algorithms can be used to good effect. However, the precision of such slicing algorithms is a major factor in determining the value of slicing for reverse engineering. Amorphous slicing has been proposed as a way of reducing the size of a slice. Amorphous slices preserve the aspect of semantic interest, but not the syntax that denotes it, making them generally smaller than their syntactically restricted counterparts. Amorphous slicing is suitable for many reverse engineering applications, since reverse engineering typically abandons the existing syntax to facilitate structural improvements. Previous work on amorphous slicing has not attempted to exploit its potential to apply loop-squashing transformations. This paper presents an algorithm for amorphous slicing of loops, which identifies induction variables, transformation rule templates and iteration-determining compile-time expressions. The algorithm uses these to squash certain loops into conditional assignments. The paper also presents an inductive proof of the rule templates and illustrates the application of the algorithm with a detailed example of loop squashing

The convenience for a notation to express non-functional characteristics of software components

Software systems are characterised both by their functionality (what the system does) and by their non-functionality (how does the system behave with respect to some observable attributes like performance, reusability, reliability, etc.). Both aspects are relevant to software development. However, non-functional issues have received little attention compared to functional ones. In this position paper we highlight the role of non-functionality, and we claim for a notation to deal with them. We enumerate some design principles for such a notation, and then we make a proposal, which allows to de ne non-functional attributes of software, non-functional behaviour of components with respect to these attributes, and also non-functional requirements over implementations.Peer ReviewedPostprint (author's final draft

Recovering Grammar Relationships for the Java Language Specification

Grammar convergence is a method that helps discovering relationships between different grammars of the same language or different language versions. The key element of the method is the operational, transformation-based representation of those relationships. Given input grammars for convergence, they are transformed until they are structurally equal. The transformations are composed from primitive operators; properties of these operators and the composed chains provide quantitative and qualitative insight into the relationships between the grammars at hand. We describe a refined method for grammar convergence, and we use it in a major study, where we recover the relationships between all the grammars that occur in the different versions of the Java Language Specification (JLS). The relationships are represented as grammar transformation chains that capture all accidental or intended differences between the JLS grammars. This method is mechanized and driven by nominal and structural differences between pairs of grammars that are subject to asymmetric, binary convergence steps. We present the underlying operator suite for grammar transformation in detail, and we illustrate the suite with many examples of transformations on the JLS grammars. We also describe the extraction effort, which was needed to make the JLS grammars amenable to automated processing. We include substantial metadata about the convergence process for the JLS so that the effort becomes reproducible and transparent

Composing Feature Models

International audienceFeature modeling is a widely used technique in Software Product Line development. Feature models allow stakeholders to describe domain concepts in terms of commonalities and differences within a family of software systems. Developing a complex monolithic feature model can require significant effort and restrict the reusability of a set of features already modeled. We advocate using modeling techniques that support separating and composing concerns to better manage the complexity of developing large feature models. In this paper, we propose a set of composition operators dedicated to feature models. These composition operators enable the development of large feature models by composing smaller feature models which address well-defined concerns. The operators are notably distinguished by their documented capabilities to preserve some significant properties

Putting non-functional requirements into software architecture

This paper presents an approach for incorporating non-functional information of software system into software architectures. To do so, components present two distinguished slots: their non-functional specification, where non-functional requirements on components are placed, and their non-functional behaviour with respect to these requirements. Also, connector protocols may describe which non-functional aspects are relevant to component connections. We propose a notation to describe non-functionality in a systematic manner, and we use it to analyse two particular aspects of the meeting scheduler case study, user interaction and performance.Peer ReviewedPostprint (published version

Including non-functional issues in Anna/Ada programs for automatic implementation selection

We present an enrichment of the Anna specification language for Ada aimed at dealing not only with functional specification of packages but also with non-functional information about them. By non-functional information we mean information about efficiency, reliability and, in general, any software attribute measuring somehow the quality of software (perhaps in a subjective manner). We divide this information into three kinds: definition of non-functional properties, statement of non-functional behaviour and statement of non-functional requirements; like Anna annotations, all of this information appears in Ada packages and package bodies and their syntax is close to Ada constructs. Non-functional information may be considered not only as valuable comments, but also as an input for an algorithm capable of selecting the “best” package body for every package definition in a program, the “best” meaning the one that fits the set of non-functional requirements of the package in the program.Peer ReviewedPostprint (author's final draft