Artificial intelligence approaches to software engineering

Artificial intelligence approaches to software engineering are examined. The software development life cycle is a sequence of not so well-defined phases. Improved techniques for developing systems have been formulated over the past 15 years, but pressure continues to attempt to reduce current costs. Software development technology seems to be standing still. The primary objective of the knowledge-based approach to software development presented in this paper is to avoid problem areas that lead to schedule slippages, cost overruns, or software products that fall short of their desired goals. Identifying and resolving software problems early, often in the phase in which they first occur, has been shown to contribute significantly to reducing risks in software development. Software development is not a mechanical process but a basic human activity. It requires clear thinking, work, and rework to be successful. The artificial intelligence approaches to software engineering presented support the software development life cycle through the use of software development techniques and methodologies in terms of changing current practices and methods. These should be replaced by better techniques that that improve the process of of software development and the quality of the resulting products. The software development process can be structured into well-defined steps, of which the interfaces are standardized, supported and checked by automated procedures that provide error detection, production of the documentation and ultimately support the actual design of complex programs

Declarative Specification

Deriving formal specifications from informal requirements is extremely difficult since one has to overcome the conceptual gap between an application domain and the domain of formal specification methods. To reduce this gap we introduce application-specific specification languages, i.e., graphical and textual notations that can be unambiguously mapped to formal specifications in a logic language. We describe a number of realised approaches based on this idea, and evaluate them with respect to their domain specificity vs. generalit

Evolution Of Object-Oriented Methods From The Reverse Engineering Of Programming Code

Many software development projects fail because of their inability to deliver the product in a timely and cost-effective manner, i.e. the software crisis. In a commercial airline company, a safety-critical system for preventing a “single-point of failure” needs to be developed and certified. To meet the project deadline an Agile approach was used in developing the first portion of the system. An appropriate software development methodology, i.e. reverse-engineering was then applied to the software system to develop method that would be used in system maintenance and evaluation. The goals of this research study were to develop a segment of one of the UML activity diagrams as a purposeful and systematic methodology for conducting reverse-engineering on complete safety critical systems of the airline system. This was done to capture very high and very low-level designs of software engineering and to verify and validate the source code. The UML activity diagram was developed from a source code of an aircraft-gate assignment system. This was done in order to capture very low-level details of the program code, from which the model was reversed engineered. The diagram was made to represent the entire source code, by going through and analyzing the source code line-by-line. Whenever there is a condition in the source code, the diagram branches out and interacts with other activities. To directly see the flow of the program, the directional arrows in the diagram were assigned. With the data flow of the source code being represented in the visual format of the UML activity diagram, the interaction of each component can be easily understood and identified. The user can see the information that goes into each method, and what each method required. Once the user understands the flow of data within the program, the user can validate and verify that the software was developed with correct methods. As the UML activity diagram represented the pseudo code of the program in a graphic way, it should be a good candidate to be used as a tool to help in reverse-engineering safety critical systems of an airline system. The UML activity diagram should be able to represent all aspects required in the deconstruction phrase of the reverse-engineering methodology. With the source code in the graphic diagram form, it should be much easier to identify the structure, functions and determine how each aspect of the program interact with each other so that the activity diagram can be used in a formal methodology for reverse-engineering

Integrating IVHM and Asset Design

Integrated Vehicle Health Management (IVHM) describes a set of capabilities that enable effective and efficient maintenance and operation of the target vehicle. It accounts for the collection of data, conducting analysis, and supporting the decision-making process for sustainment and operation. The design of IVHM systems endeavours to account for all causes of failure in a disciplined, systems engineering, manner. With industry striving to reduce through-life cost, IVHM is a powerful tool to give forewarning of impending failure and hence control over the outcome. Benefits have been realised from this approach across a number of different sectors but, hindering our ability to realise further benefit from this maturing technology, is the fact that IVHM is still treated as added on to the design of the asset, rather than being a sub-system in its own right, fully integrated with the asset design. The elevation and integration of IVHM in this way will enable architectures to be chosen that accommodate health ready sub-systems from the supply chain and design trade-offs to be made, to name but two major benefits. Barriers to IVHM being integrated with the asset design are examined in this paper. The paper presents progress in overcoming them, and suggests potential solutions for those that remain. It addresses the IVHM system design from a systems engineering perspective and the integration with the asset design will be described within an industrial design process

Integrating IVHM and asset design

Integrated Vehicle Health Management (IVHM) describes a set of capabilities that enable effective and efficient maintenance and operation of the target vehicle. It accounts for the collecting of data, conducting analysis, and supporting the decision-making process for sustainment and operation. The design of IVHM systems endeavours to account for all causes of failure in a disciplined, systems engineering, manner. With industry striving to reduce through-life cost, IVHM is a powerful tool to give forewarning of impending failure and hence control over the outcome. Benefits have been realised from this approach across a number of different sectors but, hindering our ability to realise further benefit from this maturing technology, is the fact that IVHM is still treated as added on to the design of the asset, rather than being a sub-system in its own right, fully integrated with the asset design. The elevation and integration of IVHM in this way will enable architectures to be chosen that accommodate health ready sub-systems from the supply chain and design trade-offs to be made, to name but two major benefits. Barriers to IVHM being integrated with the asset design are examined in this paper. The paper presents progress in overcoming them, and suggests potential solutions for those that remain. It addresses the IVHM system design from a systems engineering perspective and the integration with the asset design will be described within an industrial design process

Production of Reliable Flight Crucial Software: Validation Methods Research for Fault Tolerant Avionics and Control Systems Sub-Working Group Meeting

The state of the art in the production of crucial software for flight control applications was addressed. The association between reliability metrics and software is considered. Thirteen software development projects are discussed. A short term need for research in the areas of tool development and software fault tolerance was indicated. For the long term, research in format verification or proof methods was recommended. Formal specification and software reliability modeling, were recommended as topics for both short and long term research

On the engineering of crucial software

The various aspects of the conventional software development cycle are examined. This cycle was the basis of the augmented approach contained in the original grant proposal. This cycle was found inadequate for crucial software development, and the justification for this opinion is presented. Several possible enhancements to the conventional software cycle are discussed. Software fault tolerance, a possible enhancement of major importance, is discussed separately. Formal verification using mathematical proof is considered. Automatic programming is a radical alternative to the conventional cycle and is discussed. Recommendations for a comprehensive approach are presented, and various experiments which could be conducted in AIRLAB are described

CP-driven Production Process Planning in Multiproject Environment

The way enterprise capabilities are used decides about its competitiveness among other ones. In that context modeling aimed at production tasks allocation planning plays a crucial role especially at concurrently executed production orders. The introduced reference model employing constraint programming (CP) paradigm describes both an enterprise and a set of project-like production orders. Moreover, encompassing consumer orders requirements and available production capabilities, the model provides the formal framework allowing one to develop a class of decision support systems aimed at interactive production process planning subject to multiproject environment constraints. In that context our contribution is a knowledge-based and CP-driven approach to resource allocation assuming precise character of decision variables. The conditions sufficient for deadlock avoidance are the main goal. The conditions delivered provide formal framework for developing a task oriented Decision Support Tool for Project Portfolio Prototyping (DST4P, Banaszak 2006). The tool provides a prompt and interactive service to a set of routine queries formulated either in straight or reverse way

Formally-based tools and techniques for human-computer dialogues

With ever cheaper and more powerful technology. the proliferation of computer systems, and higher expectations of their users, the user interface is now seen as a crucial part of any interactive system. As the designers and users of interactive software have found, though, it can be both difficult and costly to create good interactive software. It is therefore appropriate to look at ways of "engineering" the interface as well as the application. which we choose to do by using the software engineering techniques of specification and prototyping. Formally specifying the user interface allows the designer to reason about its properties in the light of the many guidelines on the subject. Early availability of prototypes of the user interface allows the designer to experiment with alternative options and to elicit feedback from potential users. This thesis presents tools and techniques (collectively called SPI for specifying and prototyping the dialogues between an interactive system and its users. They are based on a formal specification and rapid prototyping method and notation called me too. and were originally designed as an extension to me too. They have also been implemented under UNIX*. thus enabling a transition from the formal specification to its implementation. *UNIX is a trademark of AT&T Bell Laboratorie

Declarative specifications

Deriving formal specifications from informal requirements is extremely difficult since one has to overcome the conceptual gap between an application domain and the domain of formal specification methods. To reduce this gap we introduce application-specific specification languages, i.e., graphical and textual notations that can be unambiguously mapped to formal specifications in a logic language. We describe a number of realised approaches based on this idea, and evaluate them with respect to their domain specificity vs. generalit