An environment for Ada software development based on formal specification

The domain of transformation systems has been introduced to provide a general integration framework for formal specifications. In this chapter an application of the integration approach to less formal software specifications is discussed. For that purpose models given in the Unified Modeling Language (UML) are considered: class diagrams for the specification of the structure and architecture of the system, and statechart and sequence diagrams for the specification of its behaviour. Analogous to the applications to specification formalisms presented in the previous chapters, the basic idea here is to interpret specifications semantically by sets of transformation systems, exhibit their correspondences, and thereby to check whether a common interpretation of all considered specifications is possible. As opposed to the former examples, however, the investigation cannot be completely formal, since the semantics of the given UML languages is not formally defined. That means the correctness of the transformation system semantics cannot be formally proved. To cope with this situation the interpretation will be open w.r.t. certain semantic decisions, which is then treated as parameters of possible admissible interpretations. On the other hand, the interpretation in the transformation system reference model provides the means for the formalisation and thus precision of the considered software specification languages.KeywordsState MachineUnify Modeling LanguageClass DiagramSequence DiagramClass GraphThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

A recent method combines model checkers with specifica- tion-based mutation analysis to generate test cases from formal software specifications. However high-level software specifications usually must be reduced to make analysis with a model checker feasible.

An alternative scheme to formal software specification is explicitly proposed. In our approach, a formal software specification is formally defined as a set of decision rules performed by a software system. We propose a set of graphical notations called Requirements Particle Network (RPN), to describe the essential preconditions and operations needed by a software system according to the decision rules. A RPN consists of a set of particles and edges to construct a visual model of a decision rule during the software analysis phase. In addition, a number of transformation rules are proposed to perform the formal specification synthesis. A set of predefined formal requirements particle definitions is written in prior and reused during the transformation steps. A developer is provided a practical mean to write a formal specification with a brief experience in mathematical background. In this research, we demonstrate the Z formal specification synthesis using RPN. The usability of the RPN approach is investigated by conducting a workshop. The result indicates that a developer with experience in writing data flow diagram is capable to produce a complete and consistent RPN. Moreover, we show a case study of applying RPN to construct a composite operation to be used in database applications

PurposeThe purpose of this paper is to present the ability of Z‐notation to formulate formal requirements specification of huge application software based on an example of the Manufacturing Resource Planning (MRP II) Standard System. Z‐notation is using formal transformation approach to obtain operating software instead of traditional programming. The original MRP II software requirement specification possesses descriptive form extended by list of control questions. To make formal requirements specification, the original specification must be extending by some definition taken after APICS Dictionary. The definitions respect such concept as: item, item code, location, and order.Design/methodology/approachWriting schemas based on subsystem order of MRP II Standard System and treating the system as three level structures (user interface, business logic, and database), the schemas described business logic level only. As a conclusion was necessity to extend descriptive requirements specification by definitions. The limited size of the presentation contains few examples of formalization process only mainly limited to the main schemas as: item system (full definition), inventory system, bill of material, work centers and routings, generic order system, master production schedule, and material requirement planning.FindingsAs a result of the research, it can be said that Z‐notation apparatus is sufficient to build requirements specifications of big application systems like MRP II, enterprise resource planning, or customer relationship management.Originality/valueLibraries of typical algorithms like MRP II designed through formal approach could replace traditional programming and open new prospects in the future development of broad computerization.

Software testing is one of the most important Software Engineering processes, being the primary activity to check the conformance between the software requirements and its actual behavior. The automation of software testing activities is essential to certify productivity and effectiveness in such activities. Test automation leads testing activities to be conducted under systematic and accurate criteria, raising the chance of testers to reveal faults or inconsistencies. Test oracles are elementary members in software testing automation, being the mechanism responsible for indicating the correctness of software outputs. In testing environments, test oracles can be effectively implemented based on several sources of information about the Software Under Testing (SUT): software specifications, assertions, formal methods (Finite State Machines (FSM), formal specifications, etc, machine-learning methods, and metamorphic relations. Regardless of the implementation strategy, test oracles are vulnerable to false positive/negative verdicts, configuring what the literature describes as "the oracle problem". Therefore, test oracles are a non-trivial and challenging object of studies of the software engineering research area. SUT's outputs in unusual formats make it harder the oracle problem. Audio, images, three-dimensional objects, virtual reality environments, complex statistical compositions, etc, are examples of non-trivial output formats. In the software testing context, SUTs with unusual outputs can be called "complex-output systems". In this doctorate dissertation, we propose and evaluate a novel test oracle approach for complex-output systems called feature-based test oracles. The purpose of feature-based test oracles is the appropriation of a processing image technique called Content-Based Image Retrieval (CBIR) to collect information from features extracted from the SUT's outputs to compose test oracles. Given a query image, CBIR combines feature extraction and similarity functions to alleviate the problem of searching for digital images in large databases. In previous research, we have integrated CBIR concepts in a testing framework to support the automation of testing activities in processing image systems and systems with Graphical User Interfaces (GUI). In this doctorate dissertation, we extended that framework and its concepts to general complex-output systems, addressing the feature-based test oracle approach. We use Text-To-Speech (TTS) systems to validate empirically our test oracle technique. Through the results of five empirical analyses, three of them conducted in line with problems of a real-world industry TTS system, show the proposed technique is a valuable instrument to automate testing activities and alleviate practitioners' efforts on testing complex output systems. We conclude the proposed test oracles are effective because they systematically evaluate the SUT's sensorial output rather than produce verdicts based on subjective specifications. As future work, we plan to conduct investigations towards the reduction of false positives/negatives and the association of the test oracles with machine learning techniques and metamorphic relations.

High quality software components require a representation that allows the implementation-independent description of the structure and behavior of software components. Hence, the static as well as the dynamic structure of the system has to be represented in a structured way. Graph transformation systems support static and dynamic modeling through a single computational framework for the sake of correctness, maintainability, and integrity. The framework introduced along with the corresponding tool, UPGraDE (Universal Programmed Graph Grammar Development Environment), which is based on the universal graph language GRASP (GRAph grammar with Set Productions). Any type of system can be specified through a minimal set of operations (syntax) and rules to specify the behavior of any type of software (semantics). The UPGraDE Environment, consisting of several totally transparent interconnected modules, performing well defined tasks, is a highly modular and extensible environment suited for nearly every GRASP development purpose.

Formal Software Specification with Refinements and Modules of Typed Graph Transformation Systems

On Formal Specification of Software Components and Systems

Software quality enhancement can be achieved in the near term through use of a systematic program testing methodology. The methodology attempts to relate functional software testcases with formal software specifications as a means to achieve correspondence between the software and its specifications. To do this requires generation of appropriate testcase data. Automatic testcase generation is based on a priori knowledge of two forms of internal structure information: a representation of the tree of subschema automatically identified from within each program text, and a representation of the iteration structure of each subschema. This partition of a large program allows for efficient and effective automatic testcase generation using straightforward backtracking techniques. During backtracking a number of simplifying, consolidating, and consistency analyses are applied. The result is either (1) early recognition of the impossibility of a particular program flow, or (2) efficient generation of input variable specifications which cause the testcase to traverse each portion of the required program flow. A number of machine output examples of the backtracking facility are given, and the general effectiveness of the entire process is discussed.

This paper introduces B, a mathematically based method and a computer based tool-kit for software engineering. The B-Method provides a notation and a method for the formal specification and design of software. Incremental construction of layered software as well as incremental mathematical verification have been guiding principles in its development. The method uses a ‘pseudo’ programming language Abstract Machine Notation as the language for design as well as for specification within the software process. AMN is based on an extension of Dijkstra’s guarded command language, with built-in structuring mechanisms for the construction of larger systems. The B-Method is explained in The B-Book [Abrial, 1997].The B-Toolkit supports the method over the spectrum of activities from specification through design and implementation into maintenance. The B-Toolkit comprises automatic and interactive theorem-proving assistants, and a set of software development tools: an AMN syntax & type checker, a specification animator and code generators, and promotes an object oriented approach at all stages of development. All tools are integrated into a window-based development environment. The B-Toolkit is developed and sold by B-Core.KeywordsGeneralise SubstitutionProof ObligationAbstract MachineSoftware Development ToolRefinement RelationThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Software industry produces high quality software, in that software testing plays a vital role. In software testing automatic generation can reduce the process time and cost. Automatic generation of object-oriented unit tests in software testing is a challenging task especially in white box testing. In software engineering Software testing becomes challenging issue with the development of software tools. Using Genetic Algorithm will provide best results in the software testing toolkit. This paper suggests an upgrading of automated search-based test generation of test cases in order to obtain high branch coverage in white box testing. The proposed technique outperforms providing greater efficiency in testing technique which combines Genetic Algorithm and Symbolic Execution named GASE. GASE automatically generates test data in order to obtain high branch coverage in white box testing aiming effective testing process which can be extended for software testing in cloud computing where it becomes necessity.

This paper gives some account of the evolution of ideas and the main advances in the domain of software testing based on formal specifications and reports some personal anecdotes on my activity in this field. Going back to the seventies, being slightly caricatural, software testing was perceived, on the one hand, by its actors as an empirical activity that had nothing to gain from formal methods, on the other hand, by the advocates of these methods as doomed to disappear based on the belief that in the long run programs will be correct by construction. Currently, these two communities haven’t yet reached a complete consensus. But fortunately there have been some significant moves from both sides and various success stories that allow saying that there is a fruitful convergence toward testing methods based on formal specifications.

Formal methods can only gain widespread use in industrial software development if they are integrated into software development techniques, tools, and languages that are used in practice. The objective of this tutorial is to show how formal specification and deductive verification of object-oriented programs can be done within a software development platform that supports contemporary design and implementation methodologies. The KeY System (developed by the tutorial presenters) is used for demonstration purposes, which implements our approach and integrates formal methods into the commercial CASE tool Borland Together Control Center 6.2 and, alternatively, the open extensible IDE Eclipse.

Specification directed testing is an important and largely unexplored area of software testing. We have built a prototype of a system to do specification directed testing of abstract data types. That system is called T-3. In building and using T-3 we have discovered some basic problems that must be addressed before such a system can be useful for most practical applications. This thesis describes those problems and our solutions to them. A correct software implementation can be viewed as one that (a) does everything it should; and (b) only does what it should. We show that specification directed testing should only be used to investigate (a). A new precise goal for specification directed testing based on this result is presented and developed. Previous methods for using PROLOG to produce test cases do not work for inequality predicates and cannot test all arbitrary sequences of function calls. A new method for using PROLOG to generate test cases that overcomes these limitations is presented. Previous methods for test set generation for specification directed software testing are based on the syntax of the axioms in the specifications of the software. We demonstrate the limitations of these methods by presenting simple faults that are never (even with infinite testing) detected by those previous methods. We have developed a new model of the computations of an abstract data type so that a new test set generation methodology could be developed. We have developed a new test set generation methodology that uses the semantics as well as the syntax of the software specification. It is based on: (1) our new computational model, (2) our method for using PROLOG to generate test cases, and (3) our new goal for specification directed software testing. We have validated this new methodology by comparing the number of faults it reveals to the number of faults revealed by previous methods.

The adoption of agility at a large scale often requires the integration of agile and non-agile development practices into hybrid software development and delivery environment. This chapter addresses software testing related issues for Agile software application development. Currently, the umbrella of Agile methodologies (e.g. Scrum, Extreme Programming, Development and Operations – i.e., DevOps) have become the preferred tools for modern software development. These methodologies emphasize iterative and incremental development, where both the requirements and solutions evolve through the collaboration between cross-functional teams. The success of such practices relies on the quality result of each stage of development, obtained through rigorous testing. This chapter introduces the principles of software testing within the context of Scrum/DevOps based software development lifecycle.