Lucia Rapanotti

Relating software requirements and architectures using problem frames

Problem frames provide a means of analyzing and decomposing problems. They emphasise the world outside of the computer, helping the developer to focus on the problem domain, instead of drifting into inventing solutions. However, even modestly complex problems can force us into detailed consideration of the architecture of the solution. This is counter to the intention of the problem frames approach, which is to delay consideration of the solution space until a good understanding of the problem is gained. We therefore extend problem frames, allowing architectural structures, services and artifacts to be considered as part of the problem domain. Through a case study, we show how this extension enhances the applicability of problem frames in permitting an architecture-based approach to software development. We conclude that, through our extension, the applicability of problem frames is extended to include domains with existing architectural support.

Architecture-driven problem decomposition

Jacksons problem frames provide a means of analysing and decomposing problems. They emphasise the world outside the computer helping the developer to focus on the problem domain instead of drifting into inventing solutions. The intention is to delay consideration of the solution space until a good understanding of the problem is gained. In contrast, early consideration of a solution architecture is common practice in software development. Software is usually developed by including existing components and/or reusing existing frameworks and architectures. This has the advantage of shortening development time through reuse, and increasing the robustness of a system through the application of tried and tested solutions. In This work, we show how these two views can be reconciled and demonstrate how a choice of architecture can facilitate problem analysis, decomposition and subsequent recomposition, within the problem frames framework. In particular, we introduce architectural frames - combinations of architectural styles and problem frames - and illustrate their use by applying them to two problems from the literature.

Problem Oriented Software Engineering: Solving the Package Router Control Problem

Problem orientation is gaining interest as a way of approaching the development of software intensive systems, and yet, a significant example that explores its use is missing from the literature. In this paper, we present the basic elements of Problem Oriented Software Engineering (POSE), which aims at bringing both nonformal and formal aspects of software development together in a single framework. We provide an example of a detailed and systematic POSE development of a software problem: that of designing the controller for a package router. The problem is drawn from the literature, but the analysis presented here is new. The aim of the example is twofold: to illustrate the main aspects of POSE and how it supports software engineering design and to demonstrate how a nontrivial problem can be dealt with by the approach.

Problem frame semantics for software development

This paper presents a framework for understanding Problem Frames that locates them within the Requirements Engineering model of Zave and Jackson, and its subsequent formalization in the Reference Model of Gunter et al. It distinguishes between problem frames, context diagrams and problem diagrams, and allows us to formally define the relationship between them as assumed in the Problem Frames framework.The semantics of a problem diagram is given in terms of ‘challenges’, a notion that we also introduce. The notion of a challenge is interesting in its own right for two reasons: its proof theoretic derivation leads us to consider a challenge calculus that might underpin the Problem Frame operations of decomposition and recomposition; and it promises to extend the notion of formal refinement from software development to requirements engineering.In addition, the semantics supports a textual representation of the diagrams in which Problem Frames capture problems and their relationship to solutions. This could open the way for graphical Problem Frames tools.

Problem Oriented Software Engineering: A design-theoretic framework for software engineering

A key challenge for software engineering is to learn how to reconcile the formal world of the machine and its software with the non-formal real world. In this paper, we discuss elements of problem oriented software engineering (POSE), an approach that brings both non- formal and formal aspects of software development together in a single theoretical framework for software engineering design. POSE presents development as the representation and step-wise transformation of software problems. It allows for the identification and clarification of system requirements, the understanding and structuring of the problem world, the structuring and specification of a hardware/software machine that can ensure satisfaction of the requirements in the problem world, and the construction of adequacy arguments, convincing both to developers and to customers, users and other interested parties, that the system will provide what is needed. Examples are used throughout the paper to illustrate how formal and non-formal descriptions are reconciled under POSE.

Arguing safety with Problem Oriented Software Engineering

Standards demand that assurance cases support safety critical developments. It is widely acknowledged, however, that the current practice of post-hoc assurance-that the product is built and only then argued for safety-leads to many engineering process deficiencies, extra expense, and poorer products. This paper argues how the problem oriented software engineering framework can be used in the concurrent design of a safe product and its safety case, by which these deficiencies can be addressed. The basis of the paper is a real development, undertaken by the second author of this paper, of safety-related subsystems flying in real aircraft. The case study retains all essential detail and complexity.

A reference model for requirements engineering

The reference model of Gunter et al, 2000, provides a framework for describing and analyzing key software engineering artifacts and their properties. We propose a reification of this framework in which behaviour is explicitly trace-based. We find that this benefits the formalism in adding structure in ways which are meaningful and practical from an engineering viewpoint. In particular, we develop notions of points of introduction and reachability in the new framework, and show how they strengthen the properties of the reference model.

Deriving specifications from requirements through problem reduction

Software problems – problems whose solution is software-intensive – come in many forms. Given that software and computers are deeply embedded in society, one general characteristic of software problems is that their early requirements are expressed ‘deep into the world’, that is, in terms that end-users and other stake-holders would recognise and understand. The developer is left with the difficult task of interpreting such requirements closer to the software solution.Problem reduction is proposed as a systematic transformation for deriving specifications from requirements in the context of problem-oriented analysis. It allows the context of a problem to be simplified while re-expressing the requirement. It was applied in the context of Problem Frames and argued that it can be used as a systematic way of deriving specification statements from requirement statements via a sequence of transformed problems. The approach is illustrated in two examples.

Problem-based analysis of organisational change: a real-world example

An organizations competitive advantage is increasingly reliant on the alignment of its socio-technical systems with its business processes. These are complex and volatile due to the rapid pace of change in the marketplace, hence an organisations continued success is increasingly reliant on its ability to adapt to change. In this paper, we take a small step towards providing tools which can help in the analysis and synthesis of change which impacts on an organisations socio-technical systems, in the identification and codification of recurrent change scenarios, and in the application of codified wisdom to new change problems. The tools we propose are inspired by Problem Frames. We exemplify the approach on a small real-world example.

From requirements to specifications: a formal approach

Achieving a proper understanding of the problem space before providing the design in the solution space is one of the basic tenets in requirements engineering. The Problem Frames approach provides a way for people to understand and solve software problems.Recently, a denotational semantics for Problem Frames was defined to relate the various elements of Problem Frames together. One of the problems of the semantics is that, as denotation, a problem has the set of all satisfying solution specifications. Whereas this is a sensible initial choice, it does not lend itself easily to the construction of solution specifications.The contribution of this paper is to provide a formal technique which in the context of the given semantics allows for the systematic derivation of software specifications from requirements.