Computational mechanisms are presented for analogical retrieval of domain knowledge as a basis for intelligent tool-based assistance for requirements engineers. A first mechanism, called the domain matcher, retrieves object system models which describe key features for new problems. A second mechanism, called the problem classifier, reasons with analogical mappings inferred by the domain matcher to detect potential incompleteness, overspecification and inconsistencies in entered facts and requirements. Both mechanisms are embedded in AIR, a toolkit that provides co-operative reuse-oriented assistance for requirements engineers.
Rapid changes in hardware and software architecture are transforming the nature of application software systems, leading to upheaval in the methods and tools used to develop software, The paper offers a brief review of recent developments and dilemmas in the state and usage of structured and object-oriented methods, RAD, GUI design and software process management, and CASE tools and repositories. It notes an emphasis on technology-specific skills and engineering pragmatism over software engineering theory.
The incorporation of optional components (i.e. software modules that cannot be analysed to produce realistic worst case execution times) into hard real-time applications has been recognised as a key issue for the next generation of real-time systems. A system model is presented that caters for the three main approaches to integrating optional components: milestone methods, sieve functions and multiple versions. The formal language TAM is used to describe this model. Further, an approach to ensuring that the mandatory components of this model are guaranteed to meet their deadlines is described, and the optional components are admitted for scheduling such that the utility of the system is maximised.
Interactive systems involve both events which occur at specific moments (e.g. keystrokes, mouse clicks and beeps) and more persistent status phenomena which can be observed at any time (e.g. the position of the mouse, the image on the screen). Most formalisms used for interactive systems concentrate on one aspect or another, and may be asymmetric in their treatment of input and output. Notationsand models for interface specification are classified in the paper by the way they treat status and event phenomena in their input and output. This is used to construct a model and associated notation which incorporates both. By specifying examples using this model important design issues are highlighted which would be missed if either status or event phenomena were not properly treated.
Recent disasters at Bhopal, Chernobyl, Habsheim and Kegworth illustrate the point that software is rarely the sole cause behind major accidents. Operator intervention, hardware faults, even the weather conditions and malicious acts all combine to create the conditions for failure. In the aftermath of these accidents, it seems difficult for software engineers, systems developers, forensic scientists and interface designers to predict all of the ways in which systems can fail. It is therefore important that we learn as much as possible from those failures that do occur. Unfortunately, it is often difficult to gain a coherent overview from the mass of detail that is typically contained in many accident reports. This makes it difficult for readers to identify the 'catastrophic' events that produced the necessary conditions for disaster. The paper argues that formal specification techniques can be used to resolve these problems. In particular, Temporal Logic of Actions is used to build a unified account of the human errors and system failures that contributed to the Three Mile Island accident. This notation provides high-level abstractions that can be used to strip away the mass of irrelevant details that often obscures important events during disasters. Formal proof techniques can then be applied to the model as a means of identifying the causal relationships that must be broken in order to prevent future failures.
Minimum requirements for interactive systems to be usable and reliable include computer systems performing as intended, and users not making errors in issuing commands or in interpreting information from the device display. Traditionally, most approaches to software engineering have focused on the first of these concerns; correctness of system performance. However, it is equally important to deal with the user concerns. An Instruction Language is presented for describing the knowledge a user needs to perform tasks with the device. The constraints provided by a semi-formal description language help the designer to identify possible mismatches between the system model and the user's model of that system. This type of mismatch is illustrated with an example taken from the design of the Macintosh desktop. If a further step is taken, formalising that description and adding principles about users' cognitive processes, inferences may also be made about possible user errors. This is illustrated with an example taken from the design of a mail tool. The Instruction Language and associated principles provide a means of evaluating system design in relation to user knowledge prior to implementation.
The increasing scale and complexity of software is imposing serious burdens an many industries. Formal notations, such as Z, VDM and temporal logic, have been developed to address these problems. There are, however, a number of limitations that restrict the use of mathematical specifications for large-scale software development. Many projects take months or years to complete, This creates difficulties because abstract mathematical requirements cannot easily be used by new members of a development team to understand past design decisions. Formal specifications describe what software must do, they do not explain why it must do it. In order to avoid these limitations, a literate approach to software engineering is proposed, This technique integrates a formal specification language and a semi-formal design rationale, The Z schema calculus is used to represent what a system must do. In contrast, the Questions, Options and Criteria notation is used to represent the justifications that lie behind development decisions, Empirical evidence is presented that suggests the integration of these techniques provides significant benefits over previous approaches to mathematical analysis and design techniques, A range of tools is described that have been developed to support our literate approach to the specification of large-scale software systems.
Much work has been published in recent years relating to the field of hierarchical software metrics. These are the structural measures, defined recursively over the program or flowgraph decomposition into sequences of prime flowgraphs, nested level-by-level. The theory of hierarchical metrics is generalised and extended well beyond its original framework, introducing a notion of convexity that permits combinations of (generalised) hierarchical metrics to be studied, so that weights can be given to various software attributes of interest to the individual investigator. It is found that certain concepts, for example those of independence and rank, that have their roots in linear algebra are applicable here. Examples are described that show the range of application of these fundamental notions.
The paper presents ORIENTMAN, an Intelligent Tutoring System that teaches the ORIENT methodology for object-oriented analysis and design, This methodology has already been implemented in the ORIENT CASE toolset, which was designed to support and automate the system development process using a complete (from analysis to construction-generation) object-oriented approach, ORIENTMAN has been developed using GENITOR, an ITS generator that supports the design, implementation, evaluation and revision of ITSs that specialise in methodology training. It is a stand-alone training application that combines the features of a computer coach and a gaming environment in simulation based training, It guides the trainees through a three-stage training cycle: the first stage trains them, with the use of an expert system, in the structure of the ORIENT methodology; the second stage presents, under the control of another expert system, supporting and explanatory information on the application of the methodology; and the third stage supports the self-evaluation of the acquired skills, ORIENTMAN has already been put in use, with encouraging results, as a companion training tool that will help ORIENT users in understanding and applying the ORIENT methodology.
A quantitative evaluation of the functional and object-oriented paradigms is presented. The aim of this project is to investigate whether the quality of code produced using a functional language is significantly different from that produced using an object-oriented language. 12 sets of algorithms are developed, together with a number of utility functions, in both Standard ML (SML) and C++. Strict constraints are imposed during the development cycle to improve the reliability of the results. The statistical tests do not reveal any significant differences for direct measures of the development metrics used which are associated with quality, such as the number of known errors, the number of modification requests, a subjective complexity assessment, etc. However, significant differences are found for an indirect measure, the number of known errors per thousand non-comment source lines, and for various code metrics, including the number of distinct functions called, the number of distinct library functions called, and the ratio of these, which is a measure of code reuse. A difference is also found for the time taken to test the programs, due to different compilation techniques and a difference in the number of test cases executed.
An overview of knowledge engineering research, practice, theories, methodologies, and tools is presented, and parallels are drawn with analogous phenomena and activities in requirements engineering. Knowledge based systems are distinguished from other advanced information systems by their reflective emphasis on meta information processing about the basis of system operation. In terms of requirements elicitation, this corresponds to an emphasis on maintaining an audit trail from requirements through design, implementation, use and maintenance that supports continuing user involvement in system specification, design and evolution. Examples of knowledge elicitation methodologies and tools are provided, and it is suggested that they all have some applicability in requirements elicitation for advanced information system development. It is concluded that closer collaboration between the knowledge engineering and requirements engineering communities will be mutually beneficial
The paper discusses the methods adopted to ensure that the operational software for the Channel Tunnel was delivered to a very high quality standard.
Methods for estimating the performance of database management systems can aid the design of database systems by identifying potential performance bottle-necks or by predicting the relative performance of different designs. Performance estimation is critical in parallel database systems with distributed memory, where an effective overall performance depends on a good choice among a wide range of ways of placing data. An approach is described for performance estimation for shared-nothing parallel database systems. It estimates system throughput for a given benchmark or set of queries, and can exercise different data placement schemes to determine the data layout that provides the best throughput value.
Some of the more common descriptions of inheritance, and particularly multiple inheritance are analysed; these are frequently unclear and even contradictory in much of the published literature. Using abstract data types to provide examples, it is shown how a consistent basis for inheritance and multiple inheritance may be built up, which helps to clarify the true meaning of inheritance.
How can we be sure that a set of viewpoints is valid, in the sense that it is possible to build a system consistent with each and every one of them? Our approach is based on the idea of amalgamating the individual viewpoints into a single coherent whole. A formal study of this process leads to a proposed approach for combining viewpoints that identifies conditions under which the resulting specification reflects all the properties of the constituent viewpoints. These ideas are applied to the development of Z specifications, and it is shown how they might be used in other contexts.
Although some progress has been made in recent years towards developing more effective methods for eliciting and representing requirements for software systems, little progress has been made towards developing tools and techniques that address the impact of changing requirements or of proposing changes to the a priori processes and structures for requirements analysis that dominate current systems development practice. The paper presents some of the interim results from PROTEUS, a DTI Project looking at requirements change practice in British industry, with a particular emphasis on safety-related system developments. Two sets of case study results, one drawn from collaboration with an industrial partner and the other looking at requirements handling experiences in a range of companies, present a disturbing picture of the state of requirements change practice. The results point to predominantly social, rather than technical, problems primarily in the professional relationships between client and developer* on software development projects. The paper concludes by arguing that contractual relationships on fixed cost projects, the lack of trust between partners, and the overwhelming level of software control required to handle change all marginalise the opportunity to create efficient software systems.
Large-scale software development is an evolutionary process. In an evolving specification, multiple development participants often hold multiple inconsistent views on the system being developed, and considerable effort is spent handling recurrent inconsistencies. Detecting and resolving inconsistencies is only part of the problem; a resolved inconsistency might not stay resolved as a specification evolves. Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed. However, the evolution of a specification may affect both resolved and unresolved inconsistencies. A framework is presented and elaborated in which software development knowledge is partitioned into multiple views called ViewPoints. Inconsistencies between ViewPoints are managed by explicitly representing relationships between them, and recording both resolved and unresolved inconsistencies. It is assumed that ViewPoints will often be inconsistent, and so a complete work record is kept, detailing any inconsistencies that have been detected and what actions, if any, have been taken to resolve them. The work record is then used to reason about the effects of subsequent changes to ViewPoints, without constraining the development process. The paper demonstrates how inconsistency management is used as a tool for requirements elicitation and how ViewPoints provide a vehicle for achieving this. Inconsistency is used as a stimulus for eliciting missing information and capturing user-defined relationships that arise between elements of an evolving specification.
