Programming Safety Tips: Why You Should Use Immutable Objects or How to create programs with bugs that can never be found or fixed.

Program safety deals with how to make programs as error free as possible. The hardest errors in a program for a programmer to find are often errors in using memory. There are two reasons for this. The first is that errors in accessing memory almost never show problems in the proximate area of the program where the error is made. The error has no apparent impact when it is made, but often causes catastrophic results to occur much later in the program, in areas of the program unrelated to memory error that caused it. The second reason memory errors are so difficult to find is that the working of memory is often poorly understood by most novice, and many professional, programmers. This makes it difficult for many programmers to even understand why an action causes the error. This article will show an example of a program error that can easily occur when memory access is poorly understood. This leads to program errors that are very easy to fix when they are found, but extremely difficult to find. The article will then explain how many memory errors can be easily avoided by following the very simple rule, “Make all object immutable unless there is a good reason to make them mutable”, and why immutable objects are an essential tool in good, safe programming practice

Systematic formulation of non-functional characteristics of software

This paper presents NoFun, a notation aimed at dealing with non-functional aspects of software systems at the product level in the component programming framework. NoFun can be used to define hierarchies of non-functional attributes, which can be bound to individual software components, libraries of components or (sets of) software systems. Non-functional attributes can be defined in several ways, being possible to choose a particular definition in a concrete context. Also, NoFun allows to state the values of the attributes in component implementations, and to formulate non-functional requirements over component implementations. The notation is complemented with an algorithm able to select the best implementation of components (with respect to their non-functional characteristics) in their context of use.Peer ReviewedPostprint (published version

Benchmarks of programming languages for special purposes in the space station

Although Ada is likely to be chosen as the principal programming language for the Space Station, certain needs, such as expert systems and robotics, may be better developed in special languages. The languages, LISP and Prolog, are studied and some benchmarks derived. The mathematical foundations for these languages are reviewed. Likely areas of the space station are sought out where automation and robotics might be applicable. Benchmarks are designed which are functional, mathematical, relational, and expert in nature. The coding will depend on the particular versions of the languages which become available for testing

Ada in AI or AI in Ada. On developing a rationale for integration

The use of Ada as an Artificial Intelligence (AI) language is gaining interest in the NASA Community, i.e., by parties who have a need to deploy Knowledge Based-Systems (KBS) compatible with the use of Ada as the software standard for the Space Station. A fair number of KBS and pseudo-KBS implementations in Ada exist today. Currently, no widely used guidelines exist to compare and evaluate these with one another. The lack of guidelines illustrates a fundamental problem inherent in trying to compare and evaluate implementations of any sort in languages that are procedural or imperative in style, such as Ada, with those in languages that are functional in style, such as Lisp. Discussed are the strengths and weakness of using Ada as an AI language and a preliminary analysis provided of factors needed for the development of criteria for the integration of these two families of languages and the environments in which they are implemented. The intent for developing such criteria is to have a logical rationale that may be used to guide the development of Ada tools and methodology to support KBS requirements, and to identify those AI technology components that may most readily and effectively be deployed in Ada

Software engineering and Ada (Trademark) training: An implementation model for NASA

The choice of Ada for software engineering for projects such as the Space Station has resulted in government and industrial groups considering training programs that help workers become familiar with both a software culture and the intricacies of a new computer language. The questions of how much time it takes to learn software engineering with Ada, how much an organization should invest in such training, and how the training should be structured are considered. Software engineering is an emerging, dynamic discipline. It is defined by the author as the establishment and application of sound engineering environments, tools, methods, models, principles, and concepts combined with appropriate standards, guidelines, and practices to support computing which is correct, modifiable, reliable and safe, efficient, and understandable throughout the life cycle of the application. Neither the training programs needed, nor the content of such programs, have been well established. This study addresses the requirements for training for NASA personnel and recommends an implementation plan. A curriculum and a means of delivery are recommended. It is further suggested that a knowledgeable programmer may be able to learn Ada in 5 days, but that it takes 6 to 9 months to evolve into a software engineer who uses the language correctly and effectively. The curriculum and implementation plan can be adapted for each NASA Center according to the needs dictated by each project

Next generation software environments : principles, problems, and research directions

The past decade has seen a burgeoning of research and development in software environments. Conferences have been devoted to the topic of practical environments, journal papers produced, and commercial systems sold. Given all the activity, one might expect a great deal of consensus on issues, approaches, and techniques. This is not the case, however. Indeed, the term "environment" is still used in a variety of conflicting ways. Nevertheless substantial progress has been made and we are at least nearing consensus on many critical issues.The purpose of this paper is to characterize environments, describe several important principles that have emerged in the last decade or so, note current open problems, and describe some approaches to these problems, with particular emphasis on the activities of one large-scale research program, the Arcadia project. Consideration is also given to two related topics: empirical evaluation and technology transition. That is, how can environments and their constituents be evaluated, and how can new developments be moved effectively into the production sector

The TASTE Toolset: turning human designed heterogeneous systems into computer built homogeneous software.

The TASTE tool-set results from spin-off studies of the ASSERT project, which started in 2004 with the objective to propose innovative and pragmatic solutions to develop real-time software. One of the primary targets was satellite flight software, but it appeared quickly that their characteristics were shared among various embedded systems. The solutions that we developed now comprise a process and several tools ; the development process is based on the idea that real-time, embedded systems are heterogeneous by nature and that a unique UML-like language was not helping neither their construction, nor their validation. Rather than inventing yet another "ultimate" language, TASTE makes the link between existing and mature technologies such as Simulink, SDL, ASN.1, C, Ada, and generates complete, homogeneous software-based systems that one can straightforwardly download and execute on a physical target. Our current prototype is moving toward a marketed product, and sequel studies are already in place to support, among others, FPGA systems

Team-oriented process programming

Team-oriented process programming promises to provide significant support for the planning, directing, and controlling of software engineering projects. In this paper we apply process programming to software engineering teams and show how this can provide powerful new capabilities for the management of software projects. We identify key issues which must be addressed to apply process programming to teams, and present our vision for team-oriented process programming