The arrival and popularity of multi-core processors have sparked a renewed interest in the development of parallel programs. Similarly, the availability of low cost microprocessors and sensors has generated a great interest in embedded real-time programs. This book provides students and programmers with traditional backgrounds in sequential programming the opportunity to expand their capabilities into these important emerging paradigms. It also addresses the theoretical foundations of real-time scheduling analysis, focusing on theory that is useful for real applications.

Two excellent books by Burns and Wellings (2007; 2009) provide a complete, in depth presentation of Ada's concurrent and real-time features. They make use of Ada's powerful object-oriented programming features to create high-level concurrent patterns. These books are “required reading” for software engineers working with Ada on real-time projects. However, we found that their coverage of all of Ada's concurrent and real-time features and the additional level of abstraction provided by their clever use of the object-oriented paradigm made it difficult for our undergraduate students to grasp the fundamental concepts of parallel, embedded, and real-time programming. We believe that the subset of Ada presented in this book provides the simplest model for understanding the fundamental concepts. With this basic knowledge, our readers can more easily learn the more detailed aspects of the Ada language and the more widely applicable patterns presented by Burns and Wellings.

The task of programming is a difficult one. Over the decades there have been many promises to eliminate this difficulty. It is interesting to recall that Fortran was first promoted on the basis that it would do away with programming, and allow scientists to enter their mathematical equations directly into the computer. Yet, the difficulty of programming has not gone away, and indeed, the task is more difficult now, especially because of the widespread introduction of parallelism into all realms of programming.

In universities today, many professors find that students shy away from difficult problems and challenges. As a result computer science programs have been made easier and “more fun,” and many recent textbooks reflect this worrisome trend. What we need is not students who find easy stuff fun, we need students who find difficult challenges fun!

In this climate a textbook that tackles the most difficult area of programming, the creation of complex embedded systems in which parallelism and real-time concerns play a major role, is very welcome. We entrust our lives to such complex systems all the time these days, in cars, planes, trains, medical equipment, and many other circumstances.

This book addresses the task of teaching the complex elements required to create such systems. The choice of Ada, though unfamiliar for say the creation of simple web programs, is a natural one for two reasons.

In Chapter 3 we introduced the task. The tasks in all of the examples in that chapter were independent. They did not share any resources nor did they communicate with each other. As suggested by the cooking examples of Chapter 1, the solution to most parallel problems requires cooperation among tasks. Such cooperation involves communication, mutual exclusion, and synchronization. Communication is the exchange of data or control signals between processes. Mutual exclusion is a mechanism that prevents two processes from simultaneously using the same resource. Synchronization ensures that multiple processes working on a job complete the steps of that job in the correct order. There are two approaches for communication among processes. In this chapter we look at indirect communication via shared objects. In Chapter 5, we'll look at direct communication via Ada's rendezvous mechanism.

Mutual exclusion

Let's start with a simple example that illustrates the need for mutually exclusive access to a resource used by multiple tasks. A small but popular museum has a limited capacity. When that capacity is reached, the sale of tickets must be suspended until space is made available by the departure of some visitors. Recently, the museum has installed turnstiles at each of its four entrances and hired a programmer to write the software to monitor the turnstiles and keep count of the number of visitors currently in the museum.

The arrival and popularity of multi-core processors have sparked a renewed interest in the development of parallel programs. Similarly, the availability of low-cost microprocessors and sensors has generated a great interest in embedded real-time programs. Ada is arguably the most appropriate language for development of parallel and real-time applications. Since it was first standardized in 1983, Ada's three major goals have remained:

• Program reliability and maintenance

• Programming as a human activity

• Efficiency

Meeting these goals has made Ada remarkably successful in the domain of mission-critical software. It is the language of choice for developing software for systems in which failure might result in the loss of life or property. The software in air traffic control systems, avionics, medical devices, railways, rockets, satellites, and secure data communications is frequently written in Ada. Ada has been supporting multiprocessor, multi-core, and multithreaded architectures as long as it has existed. We have nearly 30 years of experience in using Ada to deal with the problem of writing programs that run effectively on machines using more than one processor. While some have predicted it will be another decade before there is a programming model for multi-core systems, programmers have successfully used the Ada model for years. In February 2007, Karl Nyberg won the Sun Microsystems Open Performance Contest by building an elegant parallel Ada application (Nyberg, 2007). The parallel Ada code he wrote a decade earlier provided the foundation of this success.

In Chapter 7, we presented an overview of real-time scheduling theory. Those discussions were independent of any programming language. This chapter explains how to write real-time applications in Ada that are compliant with that scheduling theory. A compliant Ada program can be analyzed thereby increasing the application's reliability.

Ada practitioners have two international standards available for producing compliant Ada programs: Ada 2005 and POSIX 1003.1b. In order to apply real-time scheduling theory with these standards, we need some means to:

1. Implement periodic tasks. This implementation requires a way to represent time, a way to enforce periodic task release times, and a way to assign priorities to both tasks and shared resources.

2. Activate priority inheritance protocols for the shared resources.

3. And of course, select and apply a scheduler such as those presented in Chapter 7 (e.g. fixed priority scheduler or Earliest Deadline First).

The Ada 2005 and POSIX 1003.1b standards provide the means to create compliant programs through pragmas and specific packages. Real-time specific pragmas and packages for Ada 2005 are defined in Annex D of the Ada Reference Manual. The Ada binding POSIX 1003.5 provides the packages that allow us to create compliant real-time Ada programs using the POSIX standard.

The first six sections of this chapter discuss and use the packages and pragmas of Annex D. Section 8.1 shows how to express timing constraints of tasks with an Ada package called Ada.Real_Time.

Distribution is an important issue in software engineering, providing scalable systems across networks. Distribution supports a variety of new services from banking systems to social networks to video-on-demand. It is also used in embedded systems like cars and planes built with numerous interconnected computation-intensive blocks. When one processor is not enough, distribution is a natural complement to concurrency. In this chapter, we provide some of the elements to build a distributed system using Ada.

What are distributed systems?

Formally speaking, a distributed system is a federation of interconnected computers that collaborate to fulfill a task. As an example, one can cite web-based applications or constellations of satellites. Distributed systems rely on mechanisms to let information circulate from one node to another. In this section, we review key elements of distributed systems and discuss their strengths and limits.

Why distribute systems?

Before entering into the details of distribution and middleware, it is important to clarify the reasons why someone would want to build a distributed system. Distributing an application across several nodes requires an understanding of (1) the network (topology, technology, etc.), (2) its maintenance lifecycle (potential down time), and (3) its cost (performance and money). In addition, we need to be able to evaluate the value it adds to our application.

From an historic point of view (Vinoski, 2004), distribution was introduced in the early 1960s in large mainframe computer systems used for airline ticketing and banking.

In this chapter we will introduce you to the basic sequential features of the Ada programming language. You may find it useful to skim this chapter on first reading and then return to it when you encounter an unfamiliar language feature in later chapters. One chapter is not adequate to discuss all aspects of sequential programming with Ada. We discuss those that are most relevant to concurrent, embedded, and real-time programming and the examples used in this book. Barnes (2006) presents a comprehensive description of the Ada programming language. Ben-Ari (2009) does an excellent job describing the aspects of Ada relevant to software engineering. Dale et al. (2000) provide an introduction to Ada for novice programmers. You can find Ada implementations of the common data structures in Dale and McCormick (2007). There are also many Ada language resources available online that you may find useful while reading this chapter including English (2001), Riehle (2003), and Wikibooks (2010a). We will often refer you to the ARM, the Ada Reference Manual (Taft et al., 2006), which is available in both print and electronic forms.

DeRemer and Kron (1975) distinguished the activities of writing large programs from those of writing small programs. They considered large programs to be systems built from many small programs (modules), usually written by different people. It is common today to separate the features of a programming language along the same lines.

In Chapter 1 we demonstrated the effectiveness of concurrent algorithms. Together, Horace and Mildred can prepare a meal faster than one of them alone. The concurrent algorithm for controlling the process of chutney cooking provides a simpler and more reusable solution than the original sequential algorithm. Now that you have a basic understanding of sequential programming with Ada we are ready to create concurrent Ada programs.

Ada is a concurrent programming language — it provides the constructs needed to support the creation of programs with multiple threads of control. Ada's task is an implementation of Dijkstra's (1968) process. An Ada program is composed of one or more tasks that execute concurrently to solve a problem. In this chapter we examine the Ada task as an independent entity. In the next two chapters, we'll examine the facilities that allow tasks to communicate, synchronize, and share resources.

Defining tasks

As with packages, the definition of a task has two parts: a declaration and a body. We can define a task type from which we can create multiple tasks that execute the same sequence of statements. Alternatively, we can define a singleton task that ensures that only one task executes the sequence of statements in the body. Let's look at a program that illustrates both alternatives.

In the previous chapters, we introduced both Ada concurrency features (tasks, protected objects, and rendezvous) and advanced features to support real-time constructs (notion of priority, protocols to bound priority inversion, and task dispatching policies). Our Ada applications do not run alone. They execute within a run-time configuration. A run-time configuration consists of the processor that executes our application and the environment in which that application operates. This environment includes memory systems, input/output devices, and operating systems.

An important early design goal of Ada was to provide a compilation system that can create from one Ada program different executables that run in an equivalent way within a wide variety of run-time configurations. With little or no modifications to the Ada code, the same program should run on a variety of platforms — from small embedded platforms, such as those based on 8-bit micro-controllers and PDAs, to single processor microcomputers, multi-core processors, and multiprocessor systems. The run-time configuration may include no operating system; may include an RTOS (real-time operating system) like VxWorksTM, LynxOSTM, ORK+, MaRTE OS, and RTEMS; or may include a complete general purpose operating system such as Linux, WindowsTM, and Mac OSTM.

In this chapter, we detail how Ada concurrency constructs are supported by the Ada run-time environment. We first introduce a generic architecture for mapping Ada constructs onto an operating system. Then, we examine three different run-times for the open-source Ada compiler GNAT.

The static model addresses the static structural view of a problem, which does not vary with time. A static model describes the static structure of the system being modeled, which is considered less likely to change than the functions of the system. In particular, a static model defines the classes in the system, the attributes of the classes, the relationships between classes, and the operations of each class. In this chapter, static modeling refers to the modeling process and the UML class diagram notation is used to depict the static model.

The concepts of objects, classes, and class attributes are described in Chapter 4. This chapter describes the relationships between classes. Three types of relationships are described: associations, whole/part (composition and aggregation) relationships, and generalization/specialization (inheritance) relationships. In addition, this chapter addresses special considerations in static modeling of the problem domain, including static modeling of the total system context and software system context, as well as static modeling of entity classes. Design of class operations is deferred to the design phase, and is addressed during class design, as described in Chapter 14.

Static models are depicted on class diagrams, as described in this chapter. Section 7.1 describes the different kinds of associations between classes. Section 7.2 describes whole/part relationships, particularly composition and aggregation hierarchies. Section 7.3 describes generalization/specialization hierarchies. Section 7.4 provides an overview of constraints. Section 7.5 describes static modeling with UML, in which the initial emphasis is on modeling the physical classes and entity classes.

A template for describing a pattern typically addresses the following items from the perspective of the prospective user of the pattern:

• Pattern name

• Aliases. Other names by which this pattern is known.

• Context. The situation that gives rise to this problem.

• Problem. Brief description of the problem.

• Summary of solution. Brief description of the solution.

• Strengths of solution. Use to determine if the solution is right for your design problem.

• Weaknesses of solution. Use to determine if the solution is wrong for your design problem.

• Applicability. Situations in which you can use the pattern.

• Related patterns. Other patterns to consider for your solution.

• Reference. Where you can find more information about the pattern.

The architectural structure patterns, architectural communication patterns, and architectural transaction patterns are documented with this template in Sections A.1, A.2, and A.3, respectively.

OVERVIEW

The material in this book may be taught in different ways depending on the time available and the knowledge level of the students. This appendix describes possible academic and industrial courses that could be based on this book.

A prerequisite of these courses is an introductory course on software engineering that covers the software life cycle and the main activities in each phase of the life cycle. This prerequisite course would cover the material described in introductory books on software engineering, such as Pressman (Pressman 2009), or Sommerville (Sommerville 2010).

Each of these courses has three parts: description of the method, presentation of at least one case study using the method, and a hands-on design exercise for students to apply the method to a real-world problem.

SUGGESTED ACADEMIC COURSES

The following academic courses could be based on the material covered in this book:

1. A senior undergraduate or graduate level course on software modeling and design, with an overview of each of the architecture categories.

2. A variation on the preceding course is to concentrate on one of the architecture categories, such as service-oriented architectures or component-based software architectures, with a detailed case study and hands-on design exercise.

3. A design lab course is held as a follow-up course to the software modeling and design course (course 1) in which the students work in groups to develop a solution to a substantial software problem for one of the categories of software architecture. In this case, students could also implement all or part of the system.

The software modeling and design method described in this book is called COMET (Collaborative Object Modeling and Architectural Design Method), which uses the UML notation. COMET is an iterative use case–driven and object-oriented method that specifically addresses the requirements, analysis, and design modeling phases of the software development life cycle. This chapter considers the COMET method from a software life cycle perspective. The development process for the COMET method is a use case–based software process, which is compatible with the Unified Software Development Process (USDP) (Jacobson, Booch, and Rumbaugh 1999) and the spiral model (Boehm 1988). This chapter presents the COMET use case–based software life cycle and describes how the COMET method may be used with the USDP or the spiral model. It then outlines the main activities of the COMET method and concludes with a description of the steps in using COMET.

Section 5.1 describes the COMET use case–based software life cycle, and Section 5.2 compares COMET with other software processes. Section 5.3 gives an overview of the requirements, analysis, and design modeling activities in COMET. Section 5.4 gives an overview of the design of different kinds of software architectures covered in this textbook.

COMET USE CASE–BASED SOFTWARE LIFE CYCLE

The COMET use case–based software life cycle model is a highly iterative software development process based around the use case concept. In the requirements model, the functional requirements of the system are described in terms of actors and use cases.