Pim van den Broek

Software development with imperfect information

Delivering software systems that fulfill all requirements of the stakeholders is very difficult, if not at all impossible. We consider the problem of coping with imperfect information, like interpreting incomplete requirement specifications or vagueness in decisions, one of the main reasons that makes software design difficult. We define a method for tracing design decisions under imperfect information. To model and compare requirements with estimations, we present fuzzy and stochastic techniques. This approach offers adequate decision support that can deal with imperfect information during software design. The approach is illustrated by a real-world example, based on a storm surge barrier system.

A model for variability design rationale in SPL

The management of variability in software product lines goes beyond the definition of variations, traceability and configurations. It involves a lot of assumptions about the variability and related models, which are made by the stakeholders all over the product line but almost never handled explicitly. In order to better manage the design with variability, we must consider the rationale behind its specification. In this paper we present a model for the specification of variability design rationale and its application to the modelling of architectural variability in software product lines.

Imperfect requirements in software development

Requirement Specifications are very difficult to define. Due to lack of information and differences in interpretation, software engineers are faced with the necessity to redesign and iterate. This imperfection in software requirement specifications is commonly addressed by incremental design. In this paper, we advocate an approach where the imperfect requirements in requirement specifications are modeled by fuzzy sets. By supporting this approach with a requirement tracing and an optimization approach, the necessity for design iteration can be reduced.

Graph-based verification of static program constraints

Software artifacts usually have static program constraints and these constraints should be satisfied in each reuse. In addition to this, the developers are also required to satisfy the coding conventions used by their organization. Because in a complex software system there are too many coding conventions and program constraints to be satisfied, it becomes a cumbersome task to check them all manually. This paper presents a process and tools that allow computer-aided program constraint checking that work on the source code. We developed a modeling language called Source Code Modeling Language (SCML) in which program elements from the source code can be represented. In the process, the source code is converted into SCML models. The constraint detection is realized by graph transformation rules which are also modeled in SCML; the rules detect the violation and extract information from the SCML model of the source code to provide feedback on the location of the problem. The constraint violations can be queried from a querying mechanism that automatically searches the graph for the extracted information. The process has been applied to an industrial software system.

Dealing with imprecise quality factors in software design

During the design of a software system impreciseness can manifest itself in for instance the requirements or performance estimations. While it is common to eliminate the impreciseness by information that can not be justified, it is better to model the impreciseness since it is the most accurate description that is available at the current point in time. In this paper we present an approach, which allows the explicit specification of quality estimations and quality requirements including the imprecise nature. In this approach the impreciseness is modeled and addressed using representations from probability theory and fuzzy set theory.

Automating Object-Oriented Software Development Methods

Current software projects have generally to deal with producing and managing large and complex software products. It is generally believed that applying software development methods are useful in coping with this complexity and for supporting quality. As such numerous object-oriented software development methods have been defined. Nevertheless, methods often provide a complexity by their own due to their large number of artifacts, method rules and their complicated processes. We think that automation of software development methods is a valuable support for the software engineer in coping with this complexity and for improving quality. This paper presents a summary and a discussion of the ideas that were raised during the workshop on automating object-oriented software development methods.

Active Software Artifacts

There are many similarities between industrial goods manufacturing and software development processes. This paper first briefly analyzes the recent developments in goods manufacturing, and then identifies the equivalent techniques in software technology. It is claimed that products developed during software manufacturing must be modeled as active artifacts. As a possible approach in this direction, an object-oriented artifact production framework is presented and evaluated.

Imperfect information in software product line engineering

In this chapter, we examine the phenomenon of imperfect information, the problems it causes during SPL engineering and we outline a generalised approach for addressing these problems. In the final section of this chapter we will examine the way forward for achieving life-cycle wide supprt for imperfect information in SPL engineering.

Using design rationale to improve SPL traceability

In order to improve SPL traceability by using design rationale, this chapter introduces the traceability analysis framework (TAF), which, when combined with the AMPLE Traceability Framework, provides extra traceability capabilities for variability management. The TAF is a programmable and extensible framework that aims to support the product line developers to understand the context, evolution and shortcomings in the design by means of the simulation of the design and the explanation of design rationale. Good expressiveness of the design rationale and the design issues is obtained by making the distinction between model-level semantics and method-level semantics clear and sepatately verifiable. Traceability is based on verifying both semantics, querying the design rationale and querying the model dependencies.

Verifying Runtime Reconfiguration Requirements on UML Models

Runtime reconfiguration is a method used for changing the structure and the call pattern such that the software can adapt itself to the client’s computing environment. The current practice of verifying software models with respect to the reconfiguration requirements is rather subjective: based on the stakeholders’ needs, architects define a set of reconfiguration scenarios and manually trace the models. This chapter presents a novel process and a tool for automating the verification of the UML class and sequence diagrams with respect to runtime reconfiguration requirements. In this process, the models are simulated, which generates the execution tree. In the execution tree, each path from root to a leaf node is an execution sequence. The branching in this tree is caused by the reconfiguration of the structure and the call pattern. The runtime reconfiguration requirements are expressed with a visual state-based language which is verified against the execution tree. If the verification fails, feedback about the possible location of the problem is presented to the designers. The process has been tested with case studies and experiments conducted on the UML class and sequence diagrams of a software system from Philips Healthcare MRI