A Systematic Inspection Approach to Verifying and Validating Formal Specifications based on Specification Animation and Traceability

Writing formal specifications has been suggested to be effective in helping developers understand user’s requirements and in enhancing the quality of the requirements documentation.However, like the other activities in software development, the construction of formal specifications is usually error-prone in practice. In order to effectively detect the defects in the formal specification, in this paper, we propose a novel and practical inspection approach for specification verification and validation.In this approach, an animation method is adopted as a reading technique to guide the reviewer to read the specification. It dynamically presents the specification to the inspector by means of “executing” it in a step-by-step manner. In each step of the animation, the inspector is required to check a group of formal specification items related to the ”execution” based on a traceability-based checklist.The traceability is presented by relations between the formal specification items and their original requirements described in the informal specification, which is used to document the user’s requirements using a structured natural language. In the checklist, the relations are used to raise specific questions to examine each formal specification item to check the consistency between the informal and formal specifications. A prototype supporting tool it built to support specifications construction and the inspection process. An experiment is conducted to evaluate the performance of our inspection approach, and the experiment results indicate that our inspection approach can help inspector find more bugs than the traditional checklist-based animation, especially the bugs that affect the consistency between the informal and formal specifications due to the usage of traceability-based checklist

A Formal Engineering Approach for Interweaving Functional and Security Requirements of RESTful Web APIs

RESTful Web API adoption has become ubiquitous with the proliferation of REST APIs in almost all domains with modern web applications embracing the micro-service architecture. This vibrant and expanding adoption of APIs, has made an increasing amount of data to be funneled through systems which require proper access management to ensure that web assets are secured. A RESTful API provides data using the HTTP protocol over the network, interacting with databases and other services and must preserve its security properties. Currently, practitioners are facing two major challenges for developing high quality secure RESTful APIs. One, REST is not a protocol. Instead, it is a set of guidelines that define how web resources can be designed and accessed over HTTP endpoints. There are a set of guidelines which stipulate how related resources should be structured using hierarchical URIs as well as how specific well-defined actions on those resources should be represented using different HTTP verbs. Whereas security has always been critical in the design of RESTful APIs, there are no clear formal models utilizing a secure-by-design approach that interweaves both the functional and security requirements. The other challenge is how to effectively utilize a model driven approach for constructing precise requirements and design specifications so that the security of a RESTFul API is considered as a concern that transcends across functionality rather than individual isolated operations.This thesis proposes a novel technique that encourages a model driven approach to specifying and verifying APIs functional and security requirements with the practical formal method SOFL (Structured-Object-Oriented Formal Language). Our proposed approach provides a generic 6 step model driven approach for designing security aware APIs by utilizing concepts of domain models, domain primitives, Ecore metamodel and SOFL. The first step involves generating a flat file with APIs resource listings. In this step, we extract resource definitions from an input RESTful API documentation written in RAML using an existing RAML parser. The output of this step is a flat file representing API resources as defined in the RAML input file. This step is fully automated. The second step involves automatic construction of an API resource graph that will work as a blue print for creating the target API domain model. The input for this step is the flat file generated from step 1 and the output is a directed graph (digraph) of API resource. We leverage on an algorithm which we created that takes a list of lists of API resource nodes and the defined API root resource node as an input, and constructs a digraph highlighting all the API resources as an output. In step 3, we use the generated digraph as a guide to manually define the API’s initial domain model as the target output with an aggregate root corresponding to the root node of the input digraph and the rest of the nodes corresponding to domain model entities. In actual sense, the generated digraph in step 2 is a barebone representation of the target domain model, but what is missing in the domain model at this stage in the distinction between containment and reference relationship between entities. The resulting domain model describes the entire ecosystem of the modeled API in the form of Domain Driven Design Concepts of aggregates, aggregate root, entities, entity relationships, value objects and aggregate boundaries. The fourth step, which takes our newly defined domain model as input, involves a threat modeling process using Attack Defense Trees (ADTrees) to identify potential security vulnerabilities in our API domain model and their countermeasures. aCountermeasures that can enforce secure constructs on the attributes and behavior of their associated domain entities are modeled as domain primitives. Domain primitives are distilled versions of value objects with proper invariants. These invariants enforce security constraints on the behavior of their associated entities in our API domain model. The output of this step is a complete refined domain model with additional security invariants from the threat modeling process defined as domain primitives in the refined domain model. This fourth step achieves our first interweaving of functional and security requirements in an implicit manner. The fifth step involves creating an Ecore metamodel that describes the structure of our API domain model. In this step, we rely on the refined domain model as input and create an Ecore metamodel that our refined domain model corresponds to, as an output. Specifically, this step encompasses structural modeling of our target RESTful API. The structural model describes the possible resource types, their attributes, and relations as well as their interface and representations. The sixth and the final step involves behavioral modeling. The input for this step is an Ecore metamodel from step 5 and the output is formal security aware RESTful API specifications in SOFL language. Our goal here is to define RESTful API behaviors that consist of actions corresponding to their respective HTTP verbs i.e., GET, POST, PUT, DELETE and PATCH. For example, CreateAction creates a new resource, an UpdateAction provides the capability to change the value of attributes and ReturnAction allows for response definition including the Representation and all metadata. To achieve behavioral modelling, we transform our API methods into SOFL processes. We take advantage of the expressive nature of SOFL processes to define our modeled API behaviors. We achieve the interweaving of functional and security requirements by injecting boolean formulas in post condition of SOFL processes. To verify whether the interweaved functional and security requirements implement all expected functions correctly and satisfy the desired security constraints, we can optionally perform specification testing. Since implicit specifications do not indicate algorithms for implementation but are rather expressed with predicate expressions involving pre and post conditions for any given specification, we can substitute all the variables involved a process with concrete values of their types with results and evaluate their results in the form of truth values true or false. When conducting specification testing, we apply SOFL process animation technique to obtain the set of concrete values of output variables for each process functional scenario. We analyse test results by comparing the evaluation results with an analysis criteria. An analysis criteria is a predicate expression representing the properties to be verified. If the evaluation results are consistent with the predicate expression, the analysis show consistency between the process specification and its associated requirement. We generate the test cases for both input and output variables based on the user requirements. The test cases generated are usually based on test targets which are predicate expressions, such as the pre and post conditions of a process. when testing for conformance of a process specification to its associated service operation, we only need to observe the execution results of the process by providing concrete input values to all of its functional scenarios and analyze their defining conditions relative to user requirements. We present an empirical case study for validating the practicality and usability of our model driven formal engineering approach by applying it in developing a Salon Booking System. A total of 32 services covering functionalities provided by the Salon Booking System API were developed. We defined process specifications for the API services with their respective security requirements. The security requirements were injected in the threat modeling and behavioral modeling phase of our approach. We test for the interweaving of functional and security requirements in the specifications generated by our approach by conducting tests relative to original RAML specifications. Failed tests were exhibited in cases where injected security measure like requirement of an object level access control is not respected i.e., object level access control is not checked. Our generated SOFL specification correctly rejects such case by returning an appropriate error message while the original RAML specification incorrectly dictates to accept such request, because it is not aware of such measure. We further demonstrate a technique for generating SOFL specifications from a domain model via model to text transformation. The model to text transformation technique semi-automates the generation of SOFL formal specification in step 6 of our proposed approach. The technique allows for isolation of dynamic and static sections of the generated specifications. This enables our technique to have the capability of preserving the static sections of the target specifications while updating the dynamic sections in response to the changes of the underlying domain model representing the RESTful API in design. Specifically, our contribution is provision of a systemic model driven formal engineering approach for design and development of secure RESTful web APIs. The proposed approach offers a six-step methodology covering both structural and behavioral modelling of APIs with a focus on security. The most distinguished merit of the model to text transformation is the utilization of the API’s domain model as well as a metamodel that the domain model corresponds to as the foundation for generation of formal SOFL specifications that is a representation of API’s functional and security requirements.博士(理学)法政大学 (Hosei University

Requirements specification using concrete scenarios

The precision of formal specifications allows us to prove program correctness. Even if formal methods are not used throughout the software project, formalisation improves our understanding of the problem. Formal specifications are amenable to automated analysis and consistency checking. However using them is challenging. Customers do not understand formal notations. Specifiers have difficulty tackling large problems. Once systems are built, formal specifications quickly become outdated during software maintenance. A method of developing formal specifications using concrete scenarios is proposed to tackle the disadvantages just mentioned. A concrete scenario describes system behaviour with successive steps. The pre- and post-states of scenario steps are expressed with actual data rather than variables. Concrete scenarios are expressed in a natural language or formal notation. They increase customer involvement in the creation of formal specifications. Scenarios may be ranked by priorities allowing specifiers to focus on a small part of the system. Formal specifications are constructed incrementally. New requirements are also captured in concrete scenarios which guide the modification of formal specifications. On one hand, concrete scenarios assist the creation and maintenance of formal specifications. On the other hand, they facilitate program correctness proofs without using conventional formal specifications. This is achieved by adding implementation details to customer scenarios. The resulting developer scenarios, encapsulating decisions of data structures and algorithms, are generalised to operation schemas. With the implementation details, the schemas written in formal notations are programs rather than specifications.EThOS - Electronic Theses Online ServiceGBUnited Kingdo

Payload specialist station study: Volume 2, part 3: Program analysis and planning for phase C/D

The controls and displays (C&D) required at the Orbiter aft-flight deck (AFD) and the core C&D required at the Payload Specialist Station (PSS) are identified in this document. The AFD C&D Concept consists of a multifunction display system (MFDS) and elements of multiuse mission support equipment (MMSE). The MFDS consists of two CRTs, a display electronics unit (DEU), and a keyboard. The MMSE consists of a manual pointing controller (MPC), five digit numeric displays, 10 character alphanumeric legends, event timers, analog meters, rotary and toggle switches. The MMSE may be hardwired to the experiment, or interface with a data bus at the PSS for signal processing. The MFDS has video capability, with alphanumeric and graphic overlay features, on one CRT and alphanumeric and graphic (tricolor) capability on a second CRT. The DEU will have the capability to communicate, via redundant data buses, with both the spacelab experiment and subsystem computers

Proceedings of the Fifteenth Annual Software Engineering Workshop

The Software Engineering Laboratory (SEL) is an organization sponsored by GSFC and created for the purpose of investigating the effectiveness of software engineering technologies when applied to the development of applications software. The goals of the SEL are: (1) to understand the software development process in the GSFC environment; (2) to measure the effect of various methodologies, tools, and models on this process; and (3) to identify and then to apply successful development practices. Fifteen papers were presented at the Fifteenth Annual Software Engineering Workshop in five sessions: (1) SEL at age fifteen; (2) process improvement; (3) measurement; (4) reuse; and (5) process assessment. The sessions were followed by two panel discussions: (1) experiences in implementing an effective measurement program; and (2) software engineering in the 1980's. A summary of the presentations and panel discussions is given

Proceedings of the 19th Annual Software Engineering Workshop

The Software Engineering Laboratory (SEL) is an organization sponsored by NASA/GSFC and created to investigate the effectiveness of software engineering technologies when applied to the development of applications software. The goals of the SEL are: (1) to understand the software development process in the GSFC environment; (2) to measure the effects of various methodologies, tools, and models on this process; and (3) to identify and then to apply successful development practices. The activities, findings, and recommendations of the SEL are recorded in the Software Engineering Laboratory Series, a continuing series of reports that include this document

Explanation of the Model Checker Verification Results

Immer wenn neue Anforderungen an ein System gestellt werden, müssen die Korrektheit und Konsistenz der Systemspezifikation überprüft werden, was in der Praxis in der Regel manuell erfolgt. Eine mögliche Option, um die Nachteile dieser manuellen Analyse zu überwinden, ist das sogenannte Contract-Based Design. Dieser Entwurfsansatz kann den Verifikationsprozess zur Überprüfung, ob die Anforderungen auf oberster Ebene konsistent verfeinert wurden, automatisieren. Die Verifikation kann somit iterativ durchgeführt werden, um die Korrektheit und Konsistenz des Systems angesichts jeglicher Änderung der Spezifikationen sicherzustellen. Allerdings ist es aufgrund der mangelnden Benutzerfreundlichkeit und der Schwierigkeiten bei der Interpretation von Verifizierungsergebnissen immer noch eine Herausforderung, formale Ansätze in der Industrie einzusetzen. Stellt beispielsweise der Model Checker bei der Verifikation eine Inkonsistenz fest, generiert er ein Gegenbeispiel (Counterexample) und weist gleichzeitig darauf hin, dass die gegebenen Eingabespezifikationen inkonsistent sind. Hier besteht die gewaltige Herausforderung darin, das generierte Gegenbeispiel zu verstehen, das oft sehr lang, kryptisch und komplex ist. Darüber hinaus liegt es in der Verantwortung der Ingenieurin bzw. des Ingenieurs, die inkonsistente Spezifikation in einer potenziell großen Menge von Spezifikationen zu identifizieren. Diese Arbeit schlägt einen Ansatz zur Erklärung von Gegenbeispielen (Counterexample Explanation Approach) vor, der die Verwendung von formalen Methoden vereinfacht und fördert, indem benutzerfreundliche Erklärungen der Verifikationsergebnisse der Ingenieurin bzw. dem Ingenieur präsentiert werden. Der Ansatz zur Erklärung von Gegenbeispielen wird mittels zweier Methoden evaluiert: (1) Evaluation anhand verschiedener Anwendungsbeispiele und (2) eine Benutzerstudie in Form eines One-Group Pretest-Posttest Experiments.Whenever new requirements are introduced for a system, the correctness and consistency of the system specification must be verified, which is often done manually in industrial settings. One viable option to traverse disadvantages of this manual analysis is to employ the contract-based design, which can automate the verification process to determine whether the refinements of top-level requirements are consistent. Thus, verification can be performed iteratively to ensure the system’s correctness and consistency in the face of any change in specifications. Having said that, it is still challenging to deploy formal approaches in industries due to their lack of usability and their difficulties in interpreting verification results. For instance, if the model checker identifies inconsistency during the verification, it generates a counterexample while also indicating that the given input specifications are inconsistent. Here, the formidable challenge is to comprehend the generated counterexample, which is often lengthy, cryptic, and complex. Furthermore, it is the engineer’s responsibility to identify the inconsistent specification among a potentially huge set of specifications. This PhD thesis proposes a counterexample explanation approach for formal methods that simplifies and encourages their use by presenting user-friendly explanations of the verification results. The proposed counterexample explanation approach identifies and explains relevant information from the verification result in what seems like a natural language statement. The counterexample explanation approach extracts relevant information by identifying inconsistent specifications from among the set of specifications, as well as erroneous states and variables from the counterexample. The counterexample explanation approach is evaluated using two methods: (1) evaluation with different application examples, and (2) a user-study known as one-group pretest and posttest experiment

A documentation paradigm for an integrated software maintenance support environment

Recent advances in computer hardware have not been matched by comparable advances in computer software, inhibiting the production of reliable software at greater levels of productivity. Development of software is restricted by the so-called "maintenance backlog". Productivity in the maintenance sector has not kept pace with increasing annual labour costs, making the maintenance of software the major item in the budget, of organisations responsible for the development and maintenance of software. Gains in productivity can be anticipated by the exploitation of software-maintenance tools, within the framework of an Integrated .Software Maintenance Support Environment (ISMSE). for which a high-level design has been proposed in this thesis, offering comprehensive support for all phases of the software life-cycle, particularly the maintenance phase. A key factor in the reliable modification of software is the time taken to gain the prerequisite understanding, by a study of the system's documentation. This documentation degrades over a period of time, becoming unreliable, inhibiting maintenance of the software, which may be a large capital asset, ultimately, the software may become impossible to maintain, requiring replacement. Understanding gained during maintenance is wide-ranging and at various levels of abstraction, but is often NOT well-recorded, since no effective documentation system exists for recording the maintenance history of large software systems. The documentation paradigm in this thesis, used within the framework of an ISMSE, aims to provide a means of recording the knowledge gained during maintenance, facilitating easier future maintenance, and preserving the reliability of the documentation, so reducing the time required to gain an understanding of the software being maintained. This provides a powerful means of increasing productivity, while simultaneously preserving a valuable capital asset

A process model of maintenance with reuse: an investigation and an implementation abstract

Sixty to eighty per cent of the software life-cycle cost is spent on the software maintenance phase because software maintenance is usually more difficult than original development and legacy systems are generally large and complex. Software reuse has recently been considered as a best solution to enhance the productivity of a software development team and to reduce maintenance costs. In addition, Software Configuration Management (SCM) is a central part of software maintenance as it is associated with changing existing software and is a discipline for controlling these changes. Thus, both software reuse and SCM have been proposed for making a significant improvement in productivity, quality and cost. However, so far these two technologies have been investigated separately. In order for software reuse and SCM to produce effects by synergy, both approaches require to be introduced into a maintenance environment together. Since software reuse and SCM, and software reuse and software maintenance have many similarities in their activities, these disciplines can be integrated within a software maintenance environment. This research has therefore developed an integrated process model for 'Maintenance with Reuse (MwR)', that supports SCM for a reuse library which is actively maintained for use in a software maintenance environment. This thesis addresses an integrated process model called the MwR model and its prototype tool TERRA (Tool for Evolution of a Reusable and Reconfigurable Assets Library) that consist of a configuration management (CM) process, reuse process, maintenance process and administration of a reuse library. The MwR model and TERRA provide reusers and maintainers with many activities of these four processes such as classifying, storing, retrieving, evaluating, and propagating reusable components, including controlling changes to both reusable components and existing systems. The process model of an integrated approach has been developed and validated using Process Weaver. The TERRA tool has been implemented on the WWW so that the prototype can provide portability, traceability, integration with existing tools, and a distributed maintenance environment. The TERRA prototype has been tested and evaluated through a scenario based case study. Several scenarios based on real data have been created and used for the case study so that an organisation can apply the model and tool to its maintenance environment without many problems. The software maintenance community is facing serious problems with legacy systems, such as a ever increasing frequency of changes and backlogs, lack of integrated tools and methods, and lack of software maintenance support environments. The control and management of changes to the software components in a reuse repository are crucial to successful software development and maintenance. If the component is being used in multiple systems effects of uncontrolled change are more critical. However, reuse libraries and servers currently available have not been successful as they do not support further development or maintenance of the reusable components. In addition, most of them are not sophisticated since they have not been linked to a development/maintenance environment. The integrated model of MwR can overcome many problems that exist in software maintenance and reuse through introduction of SCM functionalities into a maintenance environment. Thus, the integration of these common activities will greatly contribute to enhancing the productivity and quality of software, and will additionally lead to reducing the costs and backlogs of changes within a maintenance environment