2.1 Conceptual Models and OOP

[ Table of Contents ] [ Chapter Overview ] [ Next ] [ Glossary/Index ]

Three ways of thinking about an Ada program.

• The first way, mentioned in the previous page, is to view (mentally model) the program as a collection of modules called program units, connected together to form an architectural whole. This chapter contains examples that illustrate the different kinds of connections between program units.
• The second way is to view the program as a collection of source text files, where each file is known as a compilation unit. Sometimes a compilation unit is nothing more than the text defining a program unit, but often it's more than that and sometimes it's less than that. By the time you are half-way through this chapter you should understand the difference.
• The third way to think about a program is to view it as a set of concurrent threads of execution or processes. This third way is covered in Chapter 6, on concurrency and synchronization. Before Chapter 6, all example programs are single-thread programs.

How Object Technology Fits In

The central concept of object technology, including object oriented design (OOD) and object oriented programming (OOP), is that a program is viewed as a collection of interacting objects and that each object is an instance of a class of objects, all having the same structure and the same set of operations. A related concept is that classes are often viewed as part of some class hierarchy whose members are related via inheritance. These concepts and Ada's support of this style of programming is the subject of Chapter 5.

The first viewpoint mentioned at the top of this page (that Ada programs are collections of related program units) is actually a more general notion than the central concept of object technology. To the extent that the program units represent objects or classes of objects, that program is created in the spirit of object technology. To the extent that other program units do not fall into those categories, those parts of the program are created using other design paradigms. (Recall that Ada is a hybrid language; it fully supports OOD and OOP but does not confine developers to that single paradigm.)

Here's an example of a more general paradigm: Consider a program as a collection of interacting machines, where some machines are objects and others are stand-alone "stimulus-response machines" with no state. Moreover, some of the objects may be one-of-a-kind objects (not considered instances of any particular class), in some cases composed of other objects. In the examples presented prior to Chapter 5 much (but not all) of what you will see is created in the spirit of object technology. Furthermore, many examples (or parts thereof) can be viewed as illustrations of the composition style of OOD (mentioned in Chapter 1 and described in [Rosen92]), in contrast to the classification style (the subject of Chapter 5). Ada provides elegant support for both styles of object technology as well as other paradigms, including classical functional decomposition.

Ada in a Nutshell

The next two sections are crucial. They describe the entire Ada language, at a high level of abstraction. First, we define (and portray graphically) the different kinds of modules. Second, we define (and portray graphically) the different ways of connecting the modules. Everything after that may be considered just a matter of filling in details. (Of course, you need to understand those details if you actually want to write Ada programs.)

Related Topics

[ Back to top of page ]  [ Next ]