Disciplined Software Engineering (original) (raw)
Related papers
Towards a comparative evaluation of text-based specification formalisms and diagrammatic notations
International Journal of Data Mining, Modelling and Management, 2019
Specification plays a vital role in software engineering to facilitate the development of highly dependable software. The importance of specification in software development is to serve, amongst others, as a communication tool for stakeholders in the software project. The specification also adds to the understanding of operations, and describes the properties of a system. Various techniques may be used for specification work. Z is a formal specification language that is based on a strongly-typed fragment of Zermelo-Fraenkel set theory and first-order logic to provide for precise and unambiguous specifications. Z uses mathematical notation to build abstract data, which is necessary for a specification. The role of abstraction is to describe what the system does without prescribing how it should be done. Diagrams, on the other hand, have also been used in various areas, and in software engineering they could be used to add a visual component to software specifications. It is plausible that diagrams may also be used to reason in a semi-formal way about the properties of a specification. Many diagrammatic languages are based on contours and set theory. Examples of these languages are Euler-, Spider-, Vennand Pierce diagrams. Euler diagrams form the foundation of most diagrams that are based on closed curves. The purpose of this research is to demonstrate the extent to which diagrams can be used to represent a Z specification. A case study is used to transform the specification modelled with Z language into a diagrammatic specification. Euler, spider, Venn and Pierce diagrams are combined for this purpose, to form one diagrammatic notation that is used to transform a Z specification.
Formality in Software Requirements
arXiv (Cornell University), 2019
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.
Proceedings of the 33rd International Conference on Software Engineering and Knowledge Engineering, 2021
It is pivotal to have well-specified requirements to eliminate errors at an early stage of the system development life cycle. Some quality standards recommend the use of formal methods-mandate requirements to be expressed in formal notations-to detect errors. However, formal notations are not suitable for non-experts and may not be understood by all the stakeholder. To fix this, bidirectional transformations among requirement representation levels are required to maintain traceability and facilitate the communication of requirements among all the involved parties. This paper reflects on the different formality levels of requirements specifications including: informal, semi-formal, and formal notations. In addition, an automated multi-layer transformation approach is proposed to enable bi-directional transformation among requirements levels.
Formal Specification and Documentation Using Z: A Case Study Approach
International Thomson Computer Press, 1996
Formal methods are becoming more accepted in both academia and industry as one possible way in which to help improve the quality of both software and hardware systems. It should be remembered however that they are not a panacea, but rather one more weapon in the armoury against making design mistakes. To quote from Prof. Tony Hoare: "Of course, there is no fool-proof methodology or magic formula that will ensure a good, efficient, or even feasible design. For that, the designer needs experience, insight, flair, judgement, invention. Formal methods can only stimulate, guide, and discipline our human inspiration, clarify design alternatives, assist in exploring their consequences, formalize and communicate design decisions, and help to ensure that they are correctly carried out." - C.A.R. Hoare, 1988 Thus we should not expect too much from formal methods, but rather use them to advantage where appropriate. Even within the formal methods community, there are many camps: for example, those that believe that a formally correct system must be proved correct mechanically, one small step at a time, and those who use the term formal to mean mathematical, using high-level pencil-and-paper style proofs to verify a design is ‘correct’ with respect to its specification. Sometimes the latter method is known as ‘rigorous’ to differentiate it from the former; and of course there are positions between these two extremes. Even if a system is proved correct, there are still many assumptions which may be invalid. The specification must be ‘obviously right.’ There is no way that this can be formally verified to be what is wanted. It must be simple enough to be understandable and should be acceptable to both the designer and the customer. This book presents an even more pragmatic view of the use of formal methods than that held by some academics: that is that formal specification alone can still be beneficial (and is much more cost effective in general) than attempting proofs in many cases. While the cost of proving a system correct may be justified in safety-critical systems where lives are at risk, many systems are less critical, but could still benefit from formalization earlier on in the design process than is normally the case in much industrial practice. Ultimately the computer system will be communicating with the outside world. In a control system, we will probably be dealing with physical laws, continuous mathematics (e.g., differential equations), etc. This will have to be converted into digital values and approximations will have to be made. In many cases, a Human-Computer Interface will be involved. Great engineering skill will be needed to ensure that any assumptions made are correct and will not invalidate any formally verified design. It is very important to apportion responsibility between the engineers associated with each design task. Mutually agreed interfaces must be drawn up. Ideally these should be formalized to reduce the risk of ambiguity and misunderstanding on each side of the interfaces. This book presents the use of one notation in the accumulation of available mathematical techniques to help ensure the correctness of computer-based systems, namely the Z notation (pronounced ‘zed’), intended for the specification of such systems. The formal notation Z is based on set theory and predicate calculus, and has been developed at the Oxford University Computing Laboratory since the late 1970’s. The use of a formal notation early on in the design process helps to remove many errors that would not otherwise be discovered until a later stage. The book includes specification of a number of digital systems in a variety of areas to help demonstrate the scope of the notation. Most of the specifications are of real systems that have been built, either commercially or experimentally. It is hoped that the variety of examples in this book will encourage more developers to attempt to specify their systems in a more formal manner before they attempt the development or programming stage. In Part I, the first two chapters give an introduction to formal specification, using Z in particular, and also to the issues concerning the practical take-up and use of formal methods in industry. Chapter 2 gives an overview of some industrial issues, for those contemplating the use of formal methods as part of the software development process. Some guidelines to help with successful use are given. Finally a brief tutorial is given in Chapter 3, which introduces Z for those who have not seen the notation before, but who wish to tackle the rest of the book. However, it should be noted that this is not a substitute for a fuller treatment, which if required should be sought from one of the numerous Z textbooks now available. Z has been designed to be read by (suitably trained) humans, rather than by computers, and as such may be included in manuals documenting computer-based systems. Part II gives some examples, using network services designed and built at Oxford University. Two types of manual have been developed, one of the user of a service, giving an idealized external abstract view, and one for potential implementors, giving more details of the suggested internal structure of the service. In Part III, Chapter 6 details the specification of a text formatting tool designed for using under the UNIX operating system. The structure of UNIX files is discussed in this context. A specification of a mouse-based input system for UNIX workstations is also presented in Chapter 7. Although Z has mainly been applied to software systems, it is also applicable to hardware. In Part IV, a number of aspects important in the specification of machine instruction sets are discussed. Chapter 8 formally defines some concepts which are useful in the specification of any microprocessor. Building of this, a part of a specific instruction set, namely that of the Transputer, is then presented in Chapter 9. Part V details some graphical concepts. Chapter 10 introduces general concepts useful for specifying pixel maps and window systems. Chapter 11 defines the rasterop function which is fundamental to many graphics operations. Window systems are now one of the most popular interfaces for computers. Part VI builds on the ideas presented in Part V and gives details of three window systems, including the highly successful XWindow System. Chapter 15 remarks on experience gained by formally specifying the three window systems and other case studies. Appendix A gives some indications on how to obtain further up-to-date information on Z. A glossary of the Z notation may be found in Appendix B. A literature guide in Appendix C together with a substantial bibliography at the end of the book are included to allow readers to follow up on another aspect of Z and formal methods that are of special interest. Finally an index, particularly of names of definitions in the specifications presented in the book, will aid the reader in navigating the text, especially the formal parts. It is hoped that the specifications presented here will help students and industrial practitioners alike to produce better specifications of their designs, be they large or small. Even if no proofs or refinement of a system are attempted, mere formalization early on in the design process will help to clarify a designer’s thoughts (especially when undertaken as part of a team) and remove many errors before they become implemented, and therefore much more difficult and expensive to rectify. For further on-line information related to this book, held as part of the distributed World Wide Web (WWW) Virtual Library, the reader is referred to the following URL (Uniform Resource Locator): http://http://formalmethods.wikia.com/zbook J.P.B. June 1995
Design languages, notation systems, and instructional technology: A case study
Educational technology research and …, 2004
Notational systems, used in mature fields of study, are closely related to design languages. The future of a technological field depends on the ability to communicate ideas and changes with others in the field. Instructional technology is one field that can benefit from a notation system enabling designers to duplicate, execute, and communicate their ideas.
The influence of formal representation on solution specification
Requirements Engineering, 2003
The effectiveness and value of a notation is determined by how well its users are able to work with it. This paper reports upon an empirical study aiming at investigating the influence of employing the Z specification notation upon how users approach system development. The study illustrates how the desire to employ formality can have a significant influence upon preferred choice between different solution approaches. Despite the formal representation increasing the awareness of the characteristics of a given design problem, the notation is apparently detrimental in the subjects' consideration of good-quality generic solutions. The human factor issues of the notation need to be carefully considered and the notation should be embedded into a proper method if effective use is to be achieved.
Software Engineering and Formal Methods
Communications of the ACM, 2008
The software engineering community has devised many techniques, tools, and approaches aimed at improving software reliability and dependability. These have had varying degrees of success, some with better results in particular domains than others, or in particular classes of applications. A popular, although not uncontroversial, approach is known as formal methods, hereby a specification notation with formal semantics, along with a deductive apparatus for reasoning, is used to specify, design, analyze, and ultimately implement a hardware or software (or hybrid) system.