Judy Bamberger

An overview of DARK

Ada is now being mandated for a large number of DoD development projects as the sole programming language to be used for developing software. Many of these projects are trying to build distributed real-time systems. Many project managers and contractors are anxious to support this effort, to reap the advantages of Ada, and to use the newer techniques of software engineering that Ada can support. This transition, however, has not always been smooth; some serious problems have been encountered. This paper discusses several of thes e problems and describes a prototype software artifact, called the Distributed Ada Real-Time Kernel (DARK), built to address these concerns and to support execution of real-time Ada applications in a distributed, embedded environment. This prototype is not intended to solve all the problems of real-time, embedded systems, but it does provide one viable, near-term option demonstrating that Ada can be used in real-time systems today.

A Detailed view of DARK

The main purpose of the Distributed Ada Real-Time Kernel (DARK) Project is to demonstrate that it i s possible to develop application code entirely in Ada that will have acceptable quality and real-tim e performance . This purpose is achieved by providing a prototype artifact — a Kernel — that implement s the necessary functionality required by real-time applications, but in a manner that avoids or mitigates th e efficiency and maturity problems found in current Ada runtime implementations .

Distributed Ada real-time kernel

Two distinct needs of real-time applications are considered. These are: distribution and hard real-time scheduling mechanisms. Specifically, the authors reject both the notion of modifying the Ada language to achieve needed real-time solutions, and the practice of extensively modifying the Ada compiler and/or vendor-supplied run-time system. Instead, the functionality of distributed Ada real-time kernel is defined. The goal of this kernel is to support effectively the execution of distributed, real-time Ada applications in an embedded computer environment by returning control to the user.<<ETX>>

Distributed Ada real-time kernel (DARK)

The DARK Project proposes one solution to the problem of using Ada in distributed, real-time, embedded applications - one that can readily be accomplished in the near term. This alternative returns explicit control of scheduling to the application implementor and provides a uniform communication mechanism for supporting distributed processors or a single processor. Other difficult areas, such as fault tolerance and multi-level security, are not directly addressed in the Kernel definition. We have, however, examined our primitives in light of these and other equally demanding issues, and we believe the Kernel definition to be extensible enough to accommodate future development in these areas. Our goal is to provide a viable paradigm of near-term support to a wide number of real-time embedded applications currently being required to use Ada for implementation. We believe that the application builders, not compiler vendors, not language designers, know best the system-level behavior required for their programs. We believe that standardization of such behavior should be provided via a library package interface under the control of the application implementor, not via modifications to the Ada language. We believe our strategy and Kernel definition provide this kind of support.

What makes a good software engineer

Since the term “software engineering” was coined some 20+ years ago, [4] a number of definitions for both the practice and the practitioner, a “software engineer,” have been proposed. The definition from a recent report on undergraduate software engineering curricula [3] states:Software engineering entails the understanding and application of engineering principles, design skills, good management practice, computer science and mathematical formalism. … The Software Engineer must be able to estimate the cost and duration of the software development process, and to determine correctness and reliability and express them with a degree of precision meaningful to other engineers and informed clients. … In recent years, several advanced degree programs in “software engineering” have been instituted in the US and abroad. One example of this can be found at the SEI itself. Two of the goals of the SEI Education Program are to: (1) develop software engineering curriculum modules that identify, organize, and document the body of knowledge that could be taught in software engineering degree programs, and (2) design, develop, support, and maintain model curricula for undergraduate and graduate software engineering programs. The question remains, however, how much of this can be taught in a classroom setting or even in a design lab, and how much must be learned on the job or via some sort of apprentice program? What does Ada have to do with software engineering ? Can Ada exist without it? Can software engineering be done without Ada? There are those who believe the term “software engineering” is just plain wrong: [1] … I deeply resent the misuse of the word “engineering” in the compound term “software engineering.” Such misuse constitutes, in my opinion, a cheap, deceptive attempt to take advantage of the professional reputation and image developed by real engineers over a century or so … it constitutes theft of professional reputation. In 1986, I coordinated a similar panel for the ACM Computer Science Conference (CSC) [2]. The introduction from that session still holds true for this one, and is paraphrased and tuned below: Most universities prepare students for continued growth and development during a lifetime of employment, whether in an industrial or government setting. Since traditionally, such an education has implied better job opportunities, the university student believes that by studying computer science and/or software engineering, she2 will be assured of a good job at a reasonable salary performing interesting and challenging tasks. On the other hand, some universities prepare students for graduate education and research, placing a heavy emphasis on theory. From this perspective, the university student believes that upon completion of a computer science or software engineering degree, she will be able to choose where to pursue her research, at the university, industry, or government site of her choosing. Three years have passed; and I have found other group of articulate people to join us and present new and exciting viewpoints on the topic of software engineering, university education, and, of course Ada. Richard Fairley, who participated in that CSC panel, continues to represent the academic point of view; Marcia Finfer represents the industrial point of view; Garth Glynn also provides the industrial point of view with the interesting addition of evaluating graduate-level software engineering degree curricula; David Markus brings the perspective of the human resource issues; Lyn Plinta provides the view of the recent graduate dealing with veterans of the hacking era; and David Umphress represents the DoD interests. These panelists, bringing together a wealth of experience as educators, practitioners, and policy makers, provide insights from both the demand-side of software engineering and the supply-side, as they take a multi-faceted, multi-national look at industrial, academic, and government expectations of software engineering as it is taught and practiced today.