Jon G. Hall

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.

Relating Software Requirements and Architectures

Why have a book about the relation between requirements and software architecture? Understanding the relation between requirements and architecture is important because the requirements, be they explicit or implicit, represent the function, whereas the architecture determines the form. While changes to a set of requirements may impact on the realization of the architecture, choices made for an architectural solution may impact on requirements, e.g., in terms of revising functional or non-functional requirements that cannot actually be met.Although research in both requirements engineering and software architecture is quite active, it is in their combination that understanding is most needed and actively sought. Presenting the current state of the art is the purpose of this book. The editors have divided the contributions into four parts: Part 1 Theoretical Underpinnings and Reviews addresses the issue of requirements change management in architectural design through traceability and reasoning. Part 2 Tools and Techniques presents approaches, tools, and techniques for bridging the gap between software requirements and architecture. Part 3 Industrial Case Studies then reports industrial experiences, while part 4 on Emerging Issues details advanced topics such as synthesizing architecture from requirements or the role of middleware in architecting for non-functional requirements. The final chapter is a conclusions chapter identifying key contributions and outstanding areas for future research and improvement of practice.The book is targeted at academic and industrial researchers in requirements engineering or software architecture. Graduate students specializing in these areas as well as advanced professionals in software development will also benefit from the results and experiences presented in this volume.

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.

Relating software requirements and architectures

Requirements engineering and software architecture have become established areas of software engineering research, education, and practice. Requirements engineering is concerned with discovering the purpose of a software system and the contexts in which it will be used (Nuseibeh and Easterbrook, 2000). Software architecture is concerned with the study of the structure of software, including its topology, properties, constituent components and their relationships and patterns of combination (Perry and Wolf, 1992). There have been significant research advances made in both software requirements and architectures, and fundamental differences and relationships between the two areas have come to light which are outlined.