Conference Paper

Unifying Requirements and Code: An Example

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

Requirements and code, in conventional software engineering wisdom, belong to entirely different worlds. Is it possible to unify these two worlds? A unified framework could help make software easier to change and reuse. To explore the feasibility of such an approach, the case study reported here takes a classic example from the requirements engineering literature and describes it using a programming language framework to express both domain and machine properties. The paper describes the solution, discusses its benefits and limitations, and assesses its scalability.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... • Up-traceability: every element of every artifact of a project follows from some element of the requirements. [90] contains a detailed application of the multirequirements method to a well-known example of a cyber-physical system. 4.5.2 ...
... Programming languages describe more than implementation. When applying them to requirements we may ignore their imperative aspects (although some of the authors' work does take advantage of imperative features [84,[86][87][88]90]). Language mechanisms developed over decades, particularly through object technology, have turned them into modeling tools for big things. ...
Article
A major determinant of the quality of software systems is the quality of their requirements, which should be both understandable and precise. Most requirements are written in natural language, good for understandability but lacking in precision. To make requirements precise, researchers have for years advocated the use of mathematics-based notations and methods, known as “formal”. Many exist, differing in their style, scope and applicability. The present survey discusses some of the main formal approaches and compares them to informal methods. The analysis uses a set of 9 complementary criteria, such as level of abstraction, tool availability, traceability support. It classifies the approaches into five categories: general-purpose, natural-language, graph/automata, other mathematical notations, seamless (programming-language-based). It presents approaches in all of these categories, altogether 22 different ones, including for example SysML, Relax, Eiffel, Event-B, Alloy. The review discusses a number of open questions, including seamlessness, the role of tools and education, and how to make industrial applications benefit more from the contributions of formal approaches. This is the full version of the survey, including some sections and two appendices which, because of length restrictions, do not appear in the submitted version. This article can be downloaded here: https://arxiv.org/pdf/1911.02564.pdf.
... These tags may be helpful for debugging the corresponding assertions' violations. Application of the multirequirements method to requirements "R 11 bis" and "R 12 bis" results in the following formal representation in Eiffel: Work [78] contains a detailed application of the multirequirements method to a well-known example of a cyber-physical system. ...
... This concern, however, is not justified. Programming languages describe more than implementation, and when applying them to requirements we may ignore their imperative aspects (although some of the authors' work develops a pure-requirements approach that actually takes advantage of imperative features [74][75][76][77][78]). Some of the major contributions of modern programming languages, the result of decades of progress and particularly of the concepts of object technology, equip them with the ability to describe big things. ...
Preprint
Full-text available
A major determinant of the quality of software systems is the quality of their requirements, which should be both understandable and precise. Natural language, the most commonly used for writing requirements, helps understandability, but lacks precision. To achieve precision, researchers have for many years advocated the use of"formal" approaches to writing requirements. These efforts have produced many requirements methods and notations, which vary considerably in their style, scope and applicability. The present survey discusses some of the principal approaches. The analysis uses a number of complementary criteria, such as traceability support, level of abstraction and tool support. It classifies the surveyed techniques into five categories: general-purpose, natural-language-based, graph and automata, other mathematical notations, and programming-language-based). The review includes examples from all of these categories, altogether 22 different methods, including for example SysML, Relax, Petri Nets, VDM, Eiffel, Event-B, Alloy. The review discusses a number of important open questions, including the role of tools and education and how to make industrial applications benefit more from the contributions of formal approaches.
... @BULLET Revise verification methodology underlying AutoProof: in essence, specification drivers are a new syntactical specification construct, which may potentially remove some particularly egregious verification challenges. Work [14] introduces the notion of multirequirements, and work [15] illustrates how to apply this notion in practice. The underlying idea is that a separate item in a software requirements document should be expressed using several interwoven notations, e.g. ...
Article
Full-text available
Existing techniques of Design by Contract do not allow software developers to specify complete contracts in many cases. Incomplete contracts leave room for malicious implementations. This article complements Design by Contract with a simple yet powerful technique that removes the problem without adding syntactical mechanisms. The proposed technique makes it possible not only to derive complete contracts, but also to rigorously check and improve completeness of existing contracts without instrumenting them.
... • Revise verification methodology underlying AutoProof: in essence, specification drivers are a new syntactical specification construct, which may potentially remove some particularly egregious verification challenges. Work [14] introduces the notion of multirequirements, and work [15] illustrates how to apply this notion in practice. The underlying idea is that a separate item in a software requirements document should be expressed using several interwoven notations, e.g. ...
... Applicability of the multirequirements method has also been studied on a realistic example [22]. ...
Article
Full-text available
Popular notations for functional requirements specifications frequently ignore developers' needs, target specific development models, or require translation of requirements into tests for verification; the results can give out-of-sync or downright incompatible artifacts. Seamless Requirements, a new approach to specifying functional requirements, contributes to developers' understanding of requirements and to software quality regardless of the process, while the process itself becomes lighter due to the absence of tests in the presence of formal verification. A development case illustrates these benefits, and a discussion compares seamless requirements to other approaches.
... This introduces another gap with DbC, which is designed from the beginning to deal with synchronous software. For non-life-critical systems [24] one may sacrifice the asynchronicity under additional assumptions [35], but the landing gear system clearly does not fall into this category. ...
Article
Full-text available
Writing requirements for embedded software is pointless unless they reflect actual needs and the final software implements them. In usual approaches, the use of different notations for requirements (often natural language) and code (a programming language) makes both conditions elusive. To address the problem, we propose to write requirements in the programming language itself. The expected advantages of this seamless approach, called AutoReq include: avoiding the potentially costly miss due to the use of different notations; facilitating software change and evolution, by making it easier to update code when requirements change and conversely; benefiting from the remarkable expressive power of modern object-oriented programming languages, while retaining a level of abstraction appropriate for requirements; leveraging, in both requirements and code, the ideas of Design by Contract, including (as the article shows) applying Hoare-style assertions to express temporal-logic-style properties and timing constraints; and taking advantage of the powerful verification tools that have been developed in recent years. The last goal, verification, is a focus of this article. While the idea of verifying requirements is not widely applied, the use of a precise formalism and a modern program prover (in our case, AutoProof for Eiffel) makes it possible at a very early stage to identify errors and inconsistencies which would, if not caught in the requirements, contaminate the final code. Applying the approach to a well-documented industrial example (a landing gear system) allowed a mechanical proof of consistency and uncovered an error in a previously published discussion of the problem.
... -Seamless development ( [11], [20], [12] [14], [13]). ...
Conference Paper
Full-text available
This paper describes our experience of training a team of developers of an East-European phone service provider. The training experience was structured in two sessions of two days each conducted in different weeks with a gap of about fifteen days. The first session was dedicated to the Continuous Integration Delivery Pipeline, and the second on Agile methods. We summarize the activity, its preparation and delivery and draw some conclusions out of it, in particular on our mistakes and how future session should be addressed.
... -Seamless development ( [12], [23], [13] [17], [15], [16]). ...
Preprint
Full-text available
This paper describes our experience of training a team of developers of an East-European phone service provider. The training experience was structured in two sessions of two days each conducted in different weeks with a gap of about fifteen days. The first session was dedicated to the Continuous Integration Delivery Pipeline, and the second on Agile methods. We summarize the activity, its preparation and delivery and draw some conclusions out of it, in particular on our mistakes and how future session should be addressed.
... These mechanisms are natively supported by the language. Having contracts, one can then verify that the implementation is indeed the intended, and also one can track the specifications against the implementation [10]. This paper presents a series of rules to produce Eiffel programs from Event-B model, bridging both top-down and bottom-up approaches. ...
Preprint
Formal modelling languages play a key role in the development of software: they enable users to specify functional requirements that serve as documentation as well; they enable users to prove the correctness of system properties, especially for critical systems. However, there is still an open question on how to map formal models to a specific programming language. In order to propose a solution, this paper presents a source-to-source mapping between Event-B models, a formal modelling language for reactive systems, and Eiffel programs, an Object Oriented (O-O) programming language. The mapping not only generates actual Eiffel code of the Event-B model, but also translates model properties as contracts. Contracts follow the Design by Contract principle and are natively supported by the programming language. The mapping is implemented in the freely available Rodin plug-in EB2Eiffel. Thus, users can develop systems (i) starting with the modelling of functional requirements (properties) in Event-B, then (ii) formally proving the correctness of such properties in Rodin and finally (iii) using EB2Eiffel to translate the model into Eiffel. In Eiffel, users can extend/customise the implementation of the model and formally prove it against the initial model. This paper also presents the different Event-B models from the literature to test EB2Eiffel and its limitations.
... -Seamless development ( [12], [23], [13] [17], [15], [16]). ...
Conference Paper
Full-text available
This paper describes our experience of training a team of developers of an East-European phone service provider. The training experience was structured in two sessions of two days each conducted in different weeks with a gap of about fifteen days. The first session was dedicated to the Continuous Integration Delivery Pipeline, and the second on Agile methods. We summarize the activity, its preparation and delivery and draw some conclusions out of it on our mistakes and how future session should be addressed.
... These mechanisms are natively supported by the language (as opposed to other programming languages). Having contracts, one can then verify that the implementation is indeed the intended (this can done statically by using a static verifier like Autoproof), and also one can track the specifications against the implementation [10]. This paper presents a series of rules to produce Eiffel programs from Event-B models, bridging both top-down and bottom-up approaches. ...
Article
Full-text available
Formal modelling languages play a key role in the development of software: they enable users to specify functional requirements that serve as documentation as well; they enable users to prove the correctness of system properties, especially for critical systems. However, there is still an open question on how to map formal models to a specific programming language. In order to propose a solution, this paper presents a source-to-source mapping between Event-B models, a formal modelling language for reactive systems, and Eiffel programs, an Object Oriented (O-O) programming language. The mapping not only generates an actual Eiffel code of the Event-B model, but also translates model properties as contracts. The contracts follow the Design by Contract principle and are natively supported by the programming language. The mapping is implemented in the freely available Rodin plug-in EB2Eiffel. Thus, users can develop systems (i) starting with the modelling of functional requirements (properties) in Event-B, then (ii) formally proving the correctness of such properties in Rodin and finally (iii) by using EB2Eiffel to translate the model into Eiffel. In Eiffel, users can extend/customise the implementation of the model and formally prove it against the initial model. This paper also presents different Event-B models from the literature to test EB2Eiffel and its limitations. The article is published in the authors’ wording.
... -Seamless development ( [12], [22], [13] [16], [14], [15]). ...
Chapter
This paper describes our experience of training a team of developers of an East-European phone service provider. The training experience was structured in two sessions of two days each conducted in different weeks with a gap of about fifteen days. The first session was dedicated to the Continuous Integration Delivery Pipeline, and the second on Agile methods. We summarize the activity, its preparation and delivery and draw some conclusions out of it on our mistakes and how future session should be addressed.
... The idea to use a programming language as a requirements notation is not new [8], [11], [12] and is well justified. Many groups of stakeholders prefer descriptions of operational activity paths over declarative requirements specifications [13]. ...
Preprint
Insufficient requirements reusability, understandability and verifiability jeopardize software projects. Empirical studies show little success in improving these qualities separately. Applying object-oriented thinking to requirements leads to their unified treatment. An online library of reusable requirement templates implements recurring requirement structures, offering a starting point for practicing the unified approach.
... Other applications of specification drivers include seamless requirements specification [NM17] and its narrower application in the context of embedded systems [NMM + 17]. These approaches contribute to seamless development ( [WN95], [Mey13], [NMR16]) -a research program pursuing unification of requirements and code. ...
Chapter
Existing techniques of Design by Contract do not prevent developers from specifying inconsistent contracts. Any attempt to write a program to meet an inconsistent contract will fail, leading to wasted resources. The present article describes a technique for catching inconsistent contracts in the development time. Applying the technique may save projects’ resources and lower the likelihood of failure.
... These mechanisms are natively supported by the language. Having contracts, one can then verify that the implementation is indeed the intended, and also one can track the specifications against the implementation [NMR15]. After the implementation of the class, one can give more speciality or generalization by using inheritance. ...
Chapter
Full-text available
Formal modelling languages play a key role in the development of software since they enable users to prove correctness of system properties, in particular critical systems such as transportation systems. However, there is still not a clear understanding on how to map a formal model to a specific programming language. In order to propose a solution, this paper presents a source-to-source mapping between Event-B models and Eiffel programs, therefore enabling the proof of correctness of certain system properties via Design-by-Contract (natively supported by Eiffel), while still making use of all features of O-O programming.
... More specifically, through the notion of multirequirements -requirements expressed in several notations, one of which is a programming language with contracts [36]. Mutlirequirements seamlessly connect requirements and their implementations in the same programming language [42]. Automated program proving [59] adds the possibility to formally reason about requirements' completeness and consistency [37,39]. ...
Chapter
Formal specification, model checking and model-based testing are recommended techniques for engineering of mission-critical systems. In the meantime, those techniques struggle to obtain wide adoption due to inherent learning barrier, i.e. it is considered difficult to use those methods. There is also a common difficulty in translating the specifications in natural language, a common practice nowadays, to formal specifications. In this position paper we discuss the concept of an end-to-end methodology that helps identify specifications from various sources, automatically create formal specifications and apply them to verification of cyber-physical systems. Thus, we intent to address the challenges of creation of formal specifications in an efficient automated and tool-supported manner. The novelty of the approach is analyzed through a survey of state of the art. It is currently planned to implement this concept and evaluate it with industrial case studies.
... The idea to use a programming language as a requirements notation is not new [6], [10], [8], [9] and is well justified. Many groups of stakeholders prefer descriptions of operational activity paths over declarative requirements specifications [12]. ...
Chapter
Insufficient requirements reusability, understandability and verifiability jeopardize software projects. Empirical studies show little success in improving these qualities separately. Applying object-oriented thinking to requirements leads to their unified treatment. An online library of reusable requirement templates implements recurring requirement structures, offering a starting point for practicing the unified approach.
... The author found more scalable and intuitively plausible way to formalize this requirement in Eiffel. The corresponding formalism will be available in work [12] ...
Article
Full-text available
Requirements and code, in conventional software engineering wisdom, belong to entirely different worlds. Is it possible to unify these two worlds? A unified framework could help make software easier to change and reuse. To explore the feasibility of such an approach, the case study reported here takes a classic example from the requirements engineering literature and describes it using a programming language framework to express both domain and machine properties. The paper describes the solution, discusses its benefits and limitations, and assesses its scalability.
Article
Full-text available
As software developers we are engineers because we make useful machines. We are concerned both with the world, in which the machine serves a useful purpose, and with the machine itself. The competing demands and attractions of these two concerns must be appropriately balanced. Failure to balance them harms our work. Certainly it must take some of the blame for the gulf between researchers and practitioners in software development. To achieve proper balance we must sometimes fight against tendencies and inclinations that are deeply in-grained in our customary practices and attitudes in software development. In this paper some aspects of the relationship between the world and the machine are explored; some sources of distortion are identified; and some suggestions are put forward for maintaining a proper balance.
Conference Paper
Full-text available
A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour sufficient to achieve the requirement. A specification is a restricted kind of requirement: all the environment phenomena mentioned in a specification are shared with the machine; the phenomena constrained by the specification are controlled by the machine; and the specified constraints can be determined without refer- ence to the future. Specifications are derived from re- quirements by reasoning about the environment, using properties that hold independently of the behaviour of the machine. These ideas, and some associated tech- niques of description, are illustrated by a simple ex- ample.
Article
Full-text available
Specification is the software life-cycle phase concerned with precise definition of the tasks to be performed by the system. A critique of a natural-language specification, followed by presentation of a mathematical alternative, demonstrates the weakness of natural language and the strength of formalism in requirements specifications. We in no way advocate formal specifications as a replacement for natural-language requirements; rather, we view them as a complement to natural-language descriptions and, as will be illustrated by an example, as an aid in improving the quality of natural-language specifications.
Chapter
Static program verifiers such as Spec#, Dafny, jStar, and VeriFast define the state of the art in automated functional verification techniques. The next open challenges are to make verification tools usable even by programmers not fluent in formal techniques. This paper discusses some techniques used in AutoProof, a verification tool that translates Eiffel programs to Boogie and uses the Boogie verifier to prove them. In an effort to be usable with real programs, AutoProof fully supports several advanced object-oriented features including polymorphism, inheritance, and function objects. AutoProof also adopts simple strategies to reduce the amount of annotations needed when verifying programs (e.g., frame conditions). The paper illustrates the main features of AutoProof’s translation, including some whose implementation is underway, and demonstrates them with examples and a case study.
Article
In this paper an attempt is made to explore the logical foundations of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This involves the elucidation of sets of axioms and rules of inference which can be used in proofs of the properties of computer programs. Examples are given of such axioms and rules, and a formal proof of a simple theorem is displayed. Finally, it is argued that important advantages, both theoretical and practical, may follow from a pursuance of these topics.
Article
Specification is the software life-cycle phase concerned with precise definition of the tasks to be performed by the system. Although software engineering textbooks emphasize its necessity, the specification phase is often overlooked in practice. Or, more precisely, it is confused with either the preceding phase, definition of system objectives, or the following phase, design. In the first case, considered here in particular, a natural-language requirements document is deemed sufficient to proceed to system design — without further specification activity.
Article
In this paper an attempt is made to explore the logical founda- tions of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This in- volves the elucidation of sets of axioms and rules of inference which can be used in proofs of the properties of computer programs. Examples are given of such axioms and rules, and a formal proof of a simple theorem is displayed. Finally, it is argued that important advantages, both theoretical and prac- tical, may follow from a pursuance of these topics.
Article
Object-Oriented Software Construction, second edition is the comprehensive reference on all aspects of object technology, from design principles to O-O techniques, Design by Contract, O-O analysis, concurrency, persistence, abstract data types and many more. Written by a pioneer in the field, contains an in-depth analysis of both methodological and technical issues.
Specified and verified reusable components
  • N Polikarpova
N. Polikarpova, Specified and verified reusable components. PhD thesis, Diss., Eidgenössische Technische Hochschule ETH Zürich, Nr. 21939, 2014, 2014.
Proofs and proof transformations for object-oriented programs
  • D M Nordio
D. M. Nordio, Proofs and proof transformations for object-oriented programs. PhD thesis, Citeseer, 2009.
Jackson-zave zoo turnstile implementation
  • A Naumchev
A. Naumchev, "Jackson-zave zoo turnstile implementation.." https://github. com/anaumche/Zoo-Turnstile-Multirequirements, 2015.