Mapping the Berard Object-Oriented Method into DoD-2167A

By Ronald C. Schultz (Knowledge Systems Corporation)
and
Edward V. Berard (The Object Agency, Inc.)

Abstract

United States Department of Defense standards and corporate policies for software development that exist in many organizations have been developed without object-oriented concepts in mind. Much of what is contained in these standards can be "reused," but certain elements require tailoring to be supportive of object-oriented development. This article provides users with a candidate mapping of the Berard Object-Oriented Method (BOOM) into one practiced software development standard, i.e., that of the military standard DoD-2167A (29 February 1988). (This article assumes the reader has some familiarity with the 2167A Standard.)

Understanding Objects

Objects are the physical and conceptual things we find in the universe around us. Hardware, software, documents, human beings, and even concepts are all examples of objects. For purposes of modeling his or her company, a chief executive officer could view employees, buildings, divisions, documents, and benefits packages as objects. An automotive engineer would see tires, doors, engines, top speed, and the current fuel level as objects. Atoms, molecules, volumes, and temperatures would all be objects a chemist might consider in creating an object-oriented simulation of a chemical reaction. Finally, a software engineer would consider stacks, queues, windows, and check boxes as objects.

Objects are thought of as having state. The state of an object is the condition of the object, or a set of circumstances describing the object. It is not uncommon to hear people talk about the "state information" associated with a particular object. For example, the state of a bank account object would include the current balance, the state of a clock object would be the current time, the state of an electric light bulb would be "on" or "off." For complex objects like a human being or an automobile, a complete description of the state might be very complex. Fortunately, when we use objects to model real world or imagined situations, we typically restrict the possible states of the objects to only those that are relevant to our models.

We also think of the state of an object as something that is internal to an object. For example, if we place a message in a mailbox, the (internal) state of the mailbox object is changed, whereas the (internal) state of the message object remains unchanged.

Sometimes people think of objects as being strictly static. That is, the state of an object will not change unless something outside of the object requests the object to change its state. Indeed, many objects are passive (static). A list of names does not spontaneously add new names to itself, nor would we expect it to spontaneously delete names from itself.

However, it is possible for some objects to change their own state. If an object is capable of spontaneously changing its own state, we refer to it as an "object with life." (Objects with life are sometimes also called "active objects" or "actors.") Clocks and timers are common examples of objects with life. If we were modeling a business process, we would recognize that salespeople and customers were also objects with life.

Classes and Instances

There are two broad categories of objects: classes and instances. Users of object-oriented technology usually think of classes as containing the information necessary to create instances, i.e., the structure and capabilities of an instance is determined by its corresponding class. There are three commonly used (and different) views on the definition for "class":

In this article, we will use the definition of a "class as an `instance factory.'"

All objects have state, i.e., a set of circumstances or attributes characterizing an object at a given time, or the condition of an object. Some people use the term "value" as a synonym for "state." Although we often think of objects as passive, i.e., they do not change their state unless requested to do so, it is possible for some objects to change their own state. If an object is capable of spontaneously changing its own state, we refer to it as an "object with life." (Objects with life are sometimes also called "active objects" or "actors.") Clocks and timers are common examples of objects with life. If we were modeling a business process, we would recognize that salespeople and customers were also objects with life.

We should note that it is possible for an instance of a class to also be a class. A metaclass is a class whose instances themselves are classes. This means when we use the instance creation mechanism in a metaclass, the instance created will itself be a class. The instance creation mechanism of this class can, in turn, be used to create instances -- although these instances may or may not themselves be classes.

A concept very similar to the metaclass is the parameterized class. A parameterized class is a template for a class wherein specific items have been identified as being required to create non-parameterized classes based on the template. In effect, a parameterized class can be viewed as a "fill in the blanks" version of a class. One cannot directly use the instance creation mechanism of a parameterized class. First, we must supply the required parameters, resulting in the creation of a non-parameterized class. Once we have a non-parameterized class, we can use its creation mechanisms to create instances.

In this article, we will use the term "class" to mean metaclass, parameterized class, or a class that is neither a metaclass nor a parameterized class. We will make a distinction only when it is necessary to do so. Further, we will occasionally refer to "non-class instances." A non-class instance is an instance of a class, but is itself not a class. An instance of a metaclass, for example, would not be a non-class instance.

Within BOOM, classes, parameterized classes, metaclasses, and (in certain rare situations) non-class instances are all documented using Object and Class Specification (OCS). See chapter 8 of Essays on Object-Oriented Software Engineering, Volume 1 for a detailed description of OCSs.

Systems of Objects

In constructing object-oriented models and object-oriented applications, one quickly finds that single classes and single instances are not enough. You need some way of creating and dealing with large objects. A system of objects is defined as two or more interacting or interrelated, non-nested objects. (We exclude simple aggregations of composite objects from our definition of systems of objects.)

Systems of objects fall into two general categories:

Figure 1: Kit graphics show collections of items that support large object-oriented concepts. Kits themselves are "granular," i.e., users may take only those items that they need from a kit.

Figure 2: System of interacting objects graphics show the multiple interfaces that these systems present to the outside world. Unlike kits, systems of interacting objects are highly physically cohesive, i.e., they are not libraries. What many consider "applications" are systems of interacting objects.

Kits resemble libraries. Say, for example, that we had to create a computer application with a graphical user interface. Graphical user interfaces normally contain several different types of windows. It would be very useful if we had a library of windows and window components from which we could construct any window we desired. Windows are objects, and the components of windows (buttons and check boxes) are themselves objects. A collection of windows and window components can be viewed as a kit.

Systems of interacting objects, on the other hand, resemble applications. For example, suppose that we wanted to construct an object-oriented application that controlled the elevators in a particular building. We would assemble elevators, buttons, lamps, panels, and other objects into a working application that would control the elevators. Such an application would not be viewed as a library, but as a highly cohesive whole. The elevator controller application is a system of interacting objects.

Kits are documented using Kit Specifications, and Systems of Interacting Objects are documented using System of Interacting Object Specifications. For details on these deliverables please refer to Berard's Object-Oriented Project Management Handbook, Volume 1. Also, see chapter 9 of Essays on Object-Oriented Software Engineering, Volume 1.

How BOOM Uses the Term "Object"

Many methodologies limit their use of the term "object" strictly to non-class instances. This, unfortunately, limits the usefulness and scaleability of the methodology. BOOM applies the term "object" in a larger sense, thereby increasing conceptual integrity, providing scaleability, and extending reusability. Within BOOM, metaclasses and parameterized classes, classes, non-class instances, kits, and systems of interacting objects are all referred to as objects.

What Is BOOM?

A methodology can be defined as an organized collection of algorithms, rules, techniques, tools, procedures, and guidelines used to solve a problem or category of problems. An object-oriented methodology is one that localizes information around objects -- as opposed to around functions or around data.

Someone came up with a particular means of characterizing object-oriented methodologies. This scheme divided the methodologies into two camps: evolutionary and revolutionary. An evolutionary object-oriented methodology was one that retained many of the elements of older (e.g., structured) approaches. For example, an evolutionary methodology might make use of such items as data flow diagrams and entity-relationship diagrams. Evolutionary methodologies also tend to characterize objects using the language, tools, and connotations of data.

Revolutionary object-oriented methodologies, on the other hand, are heavily influenced by the concepts embodied in object-oriented programming languages. Concepts such as inheritance, information hiding, classes, and polymorphism show up throughout revolutionary methodologies, whereas more traditional data and function oriented concepts, graphics, and connotations are almost non-existent. This does not mean that revolutionary approaches are informal, coding oriented affairs. Like evolutionary methodologies, revolutionary methodologies can range from fairly informal to mathematically rigorous.

BOOM is a revolutionary object-oriented methodology. In reality, BOOM is a set of highly-consistent methodologies used to accomplish various object-oriented software engineering activities. These methodologies consist of:

Common Threads

While BOOM has several major components, it has a number of common threads running through all of these components, e.g.:

Figure 3: Semantic networks show static relationships among objects. This one shows that a dialog window is comprised of dialog window items and that an individual dialog window item can be a picture, radio button, or one of four other items.

Figure 4: State transition diagrams show the dynamic behavior of individual objects or systems of objects. They also show allowable transitions.

Figure 5: Petri net graphs can be used to show dynamic interactions among multiple objects. Petri net graphs can show highly sophisticated interactions such as synchronization and multiple exclusion, deadlock, and starvation.

Figure 6: Object-message diagrams show simple interactions among multiple objects. They are sometimes called "object interaction diagrams."

Figure 7: Timing diagrams show which operations are involved in an overall task, the ordering of these operations, the objects in which the operations are encapsulated, and even overhead time (T2 - T1). Timing diagrams can also easily show concurrent operations.

Figure 8: Program unit graphics show the software architecture of an object-oriented application. They are the object-oriented equivalent of a structure chart.

An Overview of BOOM's Object-Oriented Domain Analysis

The "domain" in domain analysis refers to "application domain," e.g., graphical user interfaces, embedded missile applications, and decision support systems. There are two reasons for conducting an "analysis," i.e.:

Although most people understand that the word "domain" in "domain analysis" refers to "application domain," domain can be defined more precisely as:

Object-oriented domain analysis seeks to identify reusable items localized around objects e.g., classes, instances, systems of interacting objects, and kits. Object-oriented domain analysis techniques can also be used to create "business models," allowing people to better understand the how things happen within their environments.

True domain analysis is a never-ending process. Specifically, as long as an organization continues to develop and/or maintain software applications, or wishes to better understand their business practices, the domain analysis effort will remain active.

  1. Defining the domain

  2. Collecting a representative sample of applications in the domain

  3. Analysis of the sample

  4. Defining reusability guidelines

  5. Demonstrations of reuse using the reusable objects

  6. Making recommendations

For more information on object-oriented domain analysis, see chapter 10 of Essays on Object-Oriented Software Engineering, Volume 1.

An Overview of BOOM's Object-Oriented Requirements Analysis

The BOOM process has been used and adapted by Berard clients to perform Object-Oriented Requirements Analysis, and to produce an Object-Oriented Requirements Specification. This process can be used either when starting with no previously-existing requirements documents, or when starting from existing functional requirement specifications. Reusability and traceability play a major role in the process.

It is very important to note that BOOM's object-oriented requirements analysis approach has been used to:

Requirements analysis is really a two step process. First, the analyst must understand the problem at hand. Second, the analyst must propose a (high-level) solution to the client. Steps 1 through 6 below help the analyst understand the problem. Steps 7 through 11 below involve the creation of a requirements specification, i.e., a high-level solution to the client's problem.

  1. Identify sources of requirements information.

  2. Characterize the sources of requirements information.

  3. Identify candidate objects.

  4. Construct and verify object-oriented models of the problem space.

  5. Re-localize information around the problem space objects of interest.

  6. Select (from a reusability system), create (when not available) and verify problem space objects of interest.

  7. Construct and verify object-oriented models of the solution space.

  8. Identify solution space objects.

  9. Re-localize information around the problem space objects of interest.

  10. Select (from a reusability system), create (when not available) and verify problem space objects of interest.

  11. Package and verify the solution.

Figure 9: A high-level view shows the components of and traceability of the Berard OORA Method. All of the documents and all of the relationships are not shown for purposes of clarity.

For more information on the BOOM approach to object-oriented requirements analysis see chapters 11 and 12 of Essays on Object-Oriented Software Engineering, Volume 1.

An Overview of BOOM's Object-Oriented Design

Because object-oriented thinking is more consistent than structured methods, it both simplifies and complicates the transition from the OORA process to the object-oriented design process. On one hand, the "gap" between analysis and design narrows, as both share many graphical techniques and activities in common. On the other hand, the high level of conceptual integrity (consistency) makes it harder to distinguish between OORA and OOD. Here are some notable differences:

The following process has been found to be both systematic and repeatable for producing object-oriented design specifications. Remember that the system boundaries have already been established by the OORA process, either formally (for a large system) or informally (for a small system).

  1. Identify candidate objects.

  2. Identify operations suffered by and required of candidate objects.

  3. Select (from a reusability system), create (when not available) and verify objects.

  4. Decide on programming language implementations for objects.

  5. Create object-oriented graphical models.

  6. Establish the interface for each object-oriented item.

  7. Implement each OO item.

An Overview of BOOM's Testing of Object-Oriented Software

Over the past decade, Edward V. Berard has developed and documented a series of techniques that address the special problems of testing object-oriented software. These techniques include special testing approaches, the specification of test cases for objects, and the planning of the overall testing effort within an object-oriented life-cycle. To be sure, BOOM's approach to testing object-oriented software includes all the usual forms of testing, e.g., unit testing, integration testing, system testing, and acceptance testing. However, where appropriate, these forms have been modified to address the special issues of object-oriented software.

The major differences between testing non-object-oriented software and testing object-oriented software show up in unit testing, integration testing, and acceptance testing.

Object-oriented approaches use different encapsulation strategies than do the more conventional approaches, and that this has a twofold impact on software testing:

  1. The basic testable unit will no longer be the subprogram, and

  2. We will have to modify our strategies for integration testing.

Let's examine each of these separately.

Most technical and managerial software personnel are very familiar with functional decomposition methodologies. Outside of complete programs, the typical program unit produced by such an approach is some form of subprogram, e.g., functions, procedures, subroutines, and paragraphs. Many software standards and procedures are based on subprogram "units." Specifically, the subprogram is considered to be the basic "building block" from which applications are fashioned. In a classic waterfall approach to software development, subprogram units are usually well defined by the end of the design phase, and some may have been introduced as early as the analysis phase.

In an object-oriented environment, we are dealing with program units that are typically larger than subprograms, e.g., a class. Further, the concept of a subprogram is not quite the same as it is in more traditional systems. Specifically, we tend to separate the specification (interface) for the subprogram from its implementation (body). We refer to the specification as a "method interface" (i.e., an advertised capability in the external interface the class presents to the outside world), and to the implementation as a "method" (i.e., the internal (hidden) algorithm by which the operation is carried out). We often further complicate matters by allowing one method interface to be supported by multiple methods.

A class can therefore be thought of as encapsulating many subprograms. In addition, the same subprogram may find itself encapsulated in a number of different classes -- frequently in descendants (specializations) of the class in which it first appeared. We also stipulate that classes may also encapsulate exceptions, other objects, and various forms of state information.

In object-oriented systems, we will most often think of subprograms as being bound (encapsulated) within a larger entity, e.g., a class. Further, these subprograms will work in conjunction with the other items encapsulated within the same object. This means that, in an object-oriented environment, attempting to test a subprogram in isolation is virtually meaningless. In effect, the smallest testable unit is no longer the subprogram, but classes and instances of classes. This impact will be felt even at relatively high levels of abstraction when, for example, we submit the results of analysis or design to the testing process.

Now, let's move to the second point, i.e., integration testing. If we were using a functional decomposition approach, our smallest testable unit would be a subprogram, and, during integration testing (depending on our integration strategy) we would be integrating one, or a few, subprogram(s) at a time. In our object-oriented system, our smallest testable unit will be a class (or comparable object-oriented unit). Given that the methods associated with each method interface often take advantage of the underlying implementation of the class, it is difficult to claim that each method-interface/method combination can be tested in isolation.

Integrating "subprograms" into a class, one at a time, testing the whole as we go, may not be an option. For example, there are usually direct or indirect interactions among the components which make up the class. One method may require that the object be in a specific state -- a state which can only be set by another encapsulated method, or combination of encapsulated methods. Reversing the order of integration may not help since each method may be used to test the other.

There are other implications for integration testing in an object-oriented application. For example, in non-object-oriented systems, invocation hierarchies (module A calls module B, which eventually returns control to module A, et cetera) are the norm. Object-oriented systems are not required to abide by a strict invocation hierarchy, e.g., object A may interact directly with object B without necessarily having to go through an intermediary (controlling) object. This has led some people to say things such as "object-oriented systems have no tops," i.e., there may not be a master controlling module at the apex of some invocation hierarchy.

If we are working with a system that "has no top," then it will be difficult to define such things as "top-down integration testing," "bottom-up integration testing," or "sandwich integration testing." All of these testing strategies assume that there must be a definite "top" and a definite "bottom" for the system. This means that new integration testing strategies will have to be developed.

Advocates of object-oriented technology are fond of citing the black-box nature of objects. Specifically, a user of an object is denied access to the underlying implementation. This creates problems during testing. For example, consider a simple list object. In its interface there are a number of methods, e.g., add, delete, and length. Suppose we add an item to the list using the "add" method. How can we be assured that the specific item was actually added? (If the list is ordered, e.g., how can we be assured that the item was added in the correct position?) Since we cannot directly inspect the underlying implementation, we must seek some other strategy.

A general approach is to first establish an acceptable level of confidence in the state-reporting methods in the object's interface, i.e., those methods that do not change or alter the state of the object, but rather return information on some aspect of the object's state. For example, if we could trust the "length" method in our list object, we could use it to test the "add" and "delete" methods by looking for corresponding increases and decreases in the length after the invocation of these methods. Of course, if we had an acceptable level of confidence in the list's "delete" method, and that method returned or required the actual item to be deleted, we could use that method to help check the "add" method.

If one is working with a language which supports parameterized classes, there will be the issue of how one tests parameterized classes. Using the list example again, if one is able to create a parameterized list class, that class will allow users to define specific list classes, e.g., a list of names class or a list of numbers class. The testing effort will try to demonstrate that at least some of the instances of the list metaclass do not have their intended characteristics.

In testing a generalization-specialization hierarchy, testers will want to demonstrate that the desired combination of characteristics may not be present in a given specialization due to mistakes in the inheritance structure as defined by the software engineers. In languages which support multiple inheritance, testers will seek out improper conflict resolution. In the so-called "classless" object-oriented languages (e.g., Self), testers will attempt to highlight problems with delegation schemes.

For more information on BOOM's approach to testing object-oriented software, see chapters 15 and 16 of Essays on Object-Oriented Software Engineering, Volume 1.

An Overview of BOOM's Object-Oriented Project Management

The management of an object-oriented project is, in many ways, similar to the management of a non-object-oriented project. However, management must be aware that, when compared to more conventional projects, object-oriented projects have:

It is not the job of a project manager to be a technical expert in object-oriented technology, but it is the job of a project manager to understand what is going on, and to facilitate the software development process.

Ronald Shultz and Edward Berard developed A Project Management Handbook for Object-Oriented Development after developing several such manuals for different clients. This handbook:

Mapping BOOM Deliveralbles to DoD-2167A

For Details of the any mentioned BOOM deliverable, see A Project Management Handbook for Object-Oriented Development.

2167A Phase 2167A Deliverable BOOM Deliverable If Different than 2167A BOOM Activity and Coverage
System Requirements Analysis Preliminary System Specification 2167A products plus:

Object-Oriented Requirements Analysis Products, e.g., object-oriented models, object and class specifications, kit specifications, and systems of interacting objects specifications

a unique characteristic of BOOM is its ability to depict both hardware and software architectures:

  • identify sources of requirements information

  • characterize sources of requirements information

  • identify candidate objects

  • construct and verify object-oriented models of the problem space

  • relocalize requirements information around problem-space objects of interest

  • select, create, and verify problem space objects of interest
Covered in BOOM Object-Oriented Requirements Analysis Course
System Design System Specification 2167A products plus:

Object-Oriented Requirements Analysis Products, e.g., object-oriented models, object and class specifications, kit specifications, system of interacting object specifications

  • construct and verify solution space models

  • identify solution space objects

  • relocalize requirements information around solution space objects

  • select, create, and verify solution space objects

  • package and verify the solution

Covered in BOOM Object-Oriented Requirements Analysis Course

N/A System Segment Design Definition 2167A products plus:

Object-Oriented Requirements Analysis Products, e.g., object-oriented models, object and class specifications, kit specifications, system of interacting object specifications

This effort involves recursively applying OORA to the components of the system design, following the object-oriented decomposition of the system architecture depicted in the System Design.

  • construct and verify solution space models

  • identify solution space objects

  • relocalize requirements information around solution space objects

  • select, create, and verify solution space objects

  • package and verify the solution

Covered in BOOM Object-Oriented Requirements Analysis Course

N/A Preliminary Software Requirements Specification(s) Object-Oriented Requirements Analysis Products, e.g., object-oriented models, object and class specifications, kit specifications, system of interacting object specifications
  • identify sources of requirements information

  • characterize sources of requirements information

  • identify candidate objects

  • construct and verify object-oriented models of the problem space

  • relocalize requirements information around problem-space objects of interest

  • select, create, and verify problem space objects of interest
Covered in BOOM Object-Oriented Requirements Analysis Course
N/A Software Development Plan N/A Described in A Project Management Handbook for Object-Oriented Development

Covered in BOOM Object-Oriented Project Management Course

Software Requirements Analysis Software Requirements Specification(s) Object-Oriented Requirements Specification (OORS)
  • construct and verify solution space models

  • identify solution space objects

  • relocalize requirements information around solution space objects

  • select, create, and verify solution space objects

  • package and verify the solution

Covered in BOOM Object-Oriented Requirements Analysis Course

N/A Interface Requirements Specification An extract of all interfaces from the list of Operations, Constants, and Exceptions contained in the Object and Class Specifications, Kit Specifications, and System of Interacting Objects Specifications present in the OORS Done as part of the last step above (Package and Verify the Solution into an OORS)

Covered in BOOM Object-Oriented Requirements Analysis Course

Preliminary Design Software Design Documents (Preliminary Design) Object and Class Specifications, Kit Specifications, and System of Interacting Objects Specifications developed or reused during object-oriented design (OOD)
  • identify candidate objects

  • identify operations suffered by, and required of, candidate objects

  • select, create, and verify objects for design

Covered in BOOM Object-Oriented Design Course

N/A Software Test Plan (Test IDs) Test IDs assigned to each object and class, kit, and system of interacting objects Done during the verification process for each object.

Covered in BOOM Testing of Object-Oriented Software Course

N/A Preliminary Interface Design Document An extract of all operations from the list of Operations, Constants, and Exceptions contained in the Object and Class Specifications, Kit Specifications, and System of Interacting Objects Specifications present in those object identified during OOD. Done during the verification process for each object.

Covered in BOOM Object-Oriented Design Course and Testing of Object-Oriented Software Course

Detailed Design Software Design Documents (Detailed Design) An extract from the Design Log of each object and class, kit, and system of interacting objects' programming language implementation considerations, implementation graphics, and interface specifications (e.g., PDL)
  • decide on programming language implementations for objects

  • create object-oriented graphical implementation models

  • establish the interface for each object-oriented item

Covered in BOOM Object-Oriented Design Course

N/A Software Test Descriptions (Test Cases) Object-Oriented Test Cases Done during the review of the implementation design for each object

Covered in BOOM Testing of Object-Oriented Software Course

N/A Interface Design Document Extract of the interface specifications developed for each object and class, kit, and system of interacting objects Done during the verification process for each object.

Covered in BOOM Object-Oriented Design Course

Coding and CSU Testing Source Code Listings N/A implement each object-oriented item

Covered in BOOM Object-Oriented Design Course

N/A Source Code N/A implement each object-oriented item

Covered in BOOM Object-Oriented Design Course, as well as in language-specific training (e.g., C++ and Smalltalk)

CSC Integration and Testing Software Test Descriptions (Procedures) Object-Oriented Test Cases, Scripts, and Suites for Systems of Interacting Objects Described in Berard's Essays On Object-Oriented Software Engineering, Vol. 1, Chapter 16, "Specifying Test Cases for Object-Oriented Software"

Covered in BOOM Testing of Object-Oriented Software Course

CSCI Testing Updated Source Code N/A Described in Berard's Essays On Object-Oriented Software Engineering, Vol. 1, Chapter 16, "Specifying Test Cases for Object-Oriented Software"

Covered in BOOM Testing of Object-Oriented Software Course

N/A Software Test Report(s) N/A Described in Berard's Essays On Object-Oriented Software Engineering, Vol. 1, Chapter 16, "Specifying Test Cases for Object-Oriented Software"

Covered in BOOM Testing of Object-Oriented Software Course

N/A Operation and Support Documents N/A Covered in BOOM Object-Oriented Project Management Course
N/A Version Description Documents N/A Covered in BOOM Object-Oriented Project Management Course
N/A Software Product Specifications N/A Covered in BOOM Object-Oriented Project Management Course, Object-Oriented Requirements Analysis Course, Object-Oriented Design Course, and The Testing of Object-Oriented Software Course

Candidate Object-Oriented System Breakdown

Many software engineers, programmers, and managers have a significant amount of experience (e.g., two or more years) with traditional software engineering approaches (e.g., functional decomposition). Often, when these people are confronted with an object-oriented design problem, they imagine the architecture of the resulting system will be very similar to the more traditional module invocation hierarchies. This is simply not the case. In particular, under DoD 2167A the selection of CSCI and other configuration components must tie to objects and not functions.

Figure 10: A traditional module invocation hierarchy shows several levels of modules. In such hierarchies, each module is usually thought of as a subprogram (e.g., a subroutine, a paragraph, a procedure, or a function).

In a module invocation hierarchy, each module is thought of as some form of subprogram, e.g., a subroutine, procedure, or function. Modules in these systems pass both control and data among themselves, although it is possible (in fact, all too common) for there to be global areas of data that are accessible by many modules.

The architecture of object-oriented systems is different. One obvious difference is the inclusion of objects as program units. Although, depending on the implementation language, object-oriented systems can still contain subprograms, each must contain at least one object.

Object-oriented systems can exhibit a number of different "program unit hierarchies:"

A "top subprogram" controlling a number of passive objects (in a sequential, i.e., non-parallel, system) is usually the first architecture adopted by people moving to an object-oriented mindset. Sometimes it arises out of a view that objects are all passive, i.e., some subprogram must be present to manipulate the (otherwise passive) objects. See, for example, figures 11 and 12.

Figure 11: A program architecture showing a single top subprogram and five objects illustrates the "flatness" of such architectures. Specifically, all the objects are at the same level of abstraction, and the subprogram occupies the only other level of abstraction.

Figure 12: An alternative "top subprogram" architecture is not as "flat" as the single subprogram model, i.e., there are at least 3 levels of abstraction in this architecture. Such systems do, however, tend to be less object-oriented than they could be, i.e., there are often fewer objects and more functions.

While a top subprogram model may appear somewhat familiar to those more accustomed to a functional decomposition approach, there are some significant differences, e.g.:

In sequential object-oriented systems, the "top" program unit need not be a subprogram. It can be a genuine object, with suffered operations and state information. Of course, for this "top object" to control the application, it must be an object with life. Figures 13 and 14 show two variations on this theme.

It is important to realize that this "top object" must be a true object, e.g.:

Figure 13: The "Post Office" is actually a system of interacting objects. The object that is at the "top," controlling the functionality of the post office is the "clerk" object.

Figure 14: An architecture with a "top object" can itself contain subsystems that are controlled by other "top objects." These other "top objects" do not, however, have to be objects with life.

It is entirely possible to have a sequential object-oriented application that has neither a definitive "top subprogram," nor a definitive "top object." These applications have a single point of control that is passed from object to object. As the control is passed from one object to the next, any information needed by the object receiving the control is also passed to that object. (See figure 15.)

Although possible, it is unlikely that such systems possess unencapsulated composite operations at the top level of abstraction. This would call for the pathological situation where an object knew of the existence of an unencapsulated composite operation.

Figure 15: In this sequential object-oriented system, there is no obvious "top object." This situation occurs much more frequently in object-oriented systems than in non-object-oriented systems.

In a concurrent system, by definition, there is more than one thread of control (more than one point of execution). In an object-oriented concurrent system, we can have:

There are a number of things we should know about concurrent systems:

Each active object (sometimes referred to as "actors" or "objects with life") has at least one, internal, independently-executing thread of control. In concurrent applications, we have one of two different forms of "main program," i.e.:

In either case, the "main program" may be implemented in either a physical or a conceptual manner.

Figure 16: The main program (the "Elevator Scheduler and Controller") is a system of interaction objects and is thus an object with life. The other objects (i.e., the button, the destination panel, the weight sensor, and the floor sensor) are also objects with life.

Figure 17: A "main program" may serve only as a shell, i.e., as a context in which its internal concurrent components can interact. In this type of concurrent object-oriented architecture, there is often no discernible "top unit."

Occasionally, software engineers will be required to develop systems that are composed solely of two or more concurrently executing components that do not interact (or are not supposed to interact). Such systems come in one of two forms:

The developers and/or users of such systems may think of the components of these systems as logically (as opposed to physically) being part of the same "system."

The selection and depiction of the architecture of an object-oriented system has significant impacts as to the ease and consistency by which object-oriented analysis and design can be applied. Additional issues of concurrency are also introduced. It is extremely important to be aware that shifts in localization (e.g., to a data or function perspective) within the architecture can dramatically reduce the benefits of using an object-oriented approach (e.g., loss in consistency, diminished reuse, reduced testability).

Summary

This article addresses some of the mapping issues associated with using the BOOM approach under 2167A. The specific tailoring for 2167A varies from project to project, but this overview should provide guidance in completing the tailoring in a manner that will facilitate effective use of BOOM within DoD-2167A.

Bibliography

[Barr and Feigenbaum, 1981]. A. Barr and E.A. Feigenbaum, Editors, The Handbook of Artificial Intelligence, Volume 1, HeurisTech Press, Stanford, California, 1981.

[Berard, 1985]. E.V. Berard, An Object-Oriented Design Handbook for Ada Software, EVB Software Engineering, Inc., Frederick, Maryland, 1985.

[Berard, 1986b]. E.V. Berard, "Creating Reusable Ada Software," Proceedings of the National Conference on Software Reusability and Maintainability, September, 1986.

[Berard, 1987a]. E.V. Berard, "Object-Oriented Development,Methodologies and Tools for Real-Time Systems Conference Proceedings, National Institute for Software Quality and Productivity, Washington, D.C., March 1987, pp. E1 - E27.

[Berard, 1987b]. E.V. Berard, "Software Reusability Cannot Be Considered in a Vacuum," Digest of Papers COMPCON, Spring 1987, IEEE Catalog Number 87CH2409-1, Computer Society Order Number 764, Computer Society Press of the IEEE, Washington, D.C., pp. 390 - 393.

[Berard, 1990a]. E.V. Berard, "Life-Cycle Approaches," Hotline On Object-Oriented Technology, Vol. 1, No. 6, April 1990, pp. 1, 3 - 4.

[Berard, 1990b]. E.V. Berard, "Understanding the Recursive/Parallel Life-Cycle," Hotline On Object-Oriented Technology, Vol. 1, No. 7, May 1990, pp. 10 - 13.

[Berard, 1990c]. E.V. Berard, "Object-Oriented Requirements Analysis," Hotline On Object-Oriented Technology, Vol. 1, No. 8, June 1990, pp. 9 - 11.

[Berard, 1990d]. E.V. Berard, "Readings In Object-Oriented Technology," OOPS Newsletter, Issue 10, British Computer Society Specialist Group on Object-Oriented Programming and Systems, 1990, pp. 6 - 8.

[Berard, 1990e]. E.V. Berard, "Motivation for an Object-Oriented Approach to Software Engineering," OOPS Newsletter, Issue 11, British Computer Society Specialist Group on Object-Oriented Programming and Systems, 1990, pp. 10 - 20.

[Berard, 1993a]. E.V. Berard, Essays on Object-Oriented Software Engineering, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993.

[Berard, 1993b]. E.V. Berard, Selecting and Using Consultants for Object-Oriented Technology," Journal of Object-Oriented Programming, Vol. 6, No. 5, September 1993, pp. 48 - 53.

[Berard, 1994]. E.V. Berard, "Object-Oriented Design," The Encyclopedia of Software Engineering, Volume 2, J.J. Marciniak, Editor, John Wiley and Sons, New York, New York, 1994, pp. 721 - 729.

[Booch, 1991]. G. Booch, Object-Oriented Design With Applications, Benjamin/Cummings, Menlo Park, California, 1991.

[Booch, 1994]. G. Booch, Object-Oriented Analysis and Design With Applications, Second Edition, Benjamin/Cummings Publishing Company, Redwood City, California, 1994.

[Booth, 1967]. T.L. Booth, Sequential Machines and Automata Theory, John Wiley & Sons, New York, New York, 1967.

[BSE, 1994a]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Software Engineering, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994b]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Requirements Analysis, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994c]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Design, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994d]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Domain Analysis, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994e]. Berard Software Engineering, Inc., Course Notes for Testing Object-Oriented Software, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994f]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Project Management, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[BSE, 1994g]. Berard Software Engineering, Inc., Course Notes for Object-Oriented Business Process Modeling, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1994.

[Buhr, 1990]. R.J.A. Buhr, Practical Visual Techniques in System Design: With Applications to Ada, Prentice Hall, Englewood Cliffs, New Jersey, 1990.

[Colbert, 1989]. E. Colbert, "The Object-Oriented Software Development Method: A Practical Approach to Object-Oriented Development," Proceedings of TRI-Ada '89 -- Ada Technology In Context: Application, Development, and Deployment, October 23-26, 1989, Association for Computing Machinery, New York, New York, pp. 400 - 415.

[Cunningham and Beck, 1986]. W. Cunningham and K. Beck, "A Diagram for Object-Oriented Programs," OOPSLA '86 Conference Proceedings, special issue of SIGPLAN Notices, Vol. 21, No. 11, pp. 361 - 367.

[Ghezzi et al., 1989]. C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezze, "A General Way to Put Time in Petri Nets," Proceedings of the Fifth International Workshop On Software Specification and Design, May 19-20, 1989, Pittsburgh, Pennsylvania, IEEE Computer Society Press, Washington, D.C., May 1989, pp. 60 - 67.

[Ghezzi et al., 1991]. C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering, Prentice Hall, Englewood Cliffs, New Jersey, 1991.

[Hatley and Pirbhai, 1988]. D.J. Hatley and I.A. Pirbhai, Strategies for Real-Time System Specification, Dorset House Publishing, New York, New York, 1988.

[Hopcroft and Ullman, 1980]. J. Hopcroft and J. Ullman, Introduction to Automata Theory: Languages and Computation, Addison-Wesley, Reading, Massachusetts, 1980.

[Margono and Berard, 1987]. J. Margono and E.V. Berard, "A Modified Booch's Taxonomy for Ada Generic Data-Structure Components and Their Implementation," Ada Components: Libraries and Tools - Proceedings of the Ada-Europe International Conference, Stockholm, 26-28 May, 1987, Edited by S. Tafvelin, Cambridge University Press, Cambridge, United Kingdom, pp. 61 - 74.

[Peterson, 1977]. J.L. Peterson, "Petri Nets," ACM Computing Surveys, Vol. 9, No. 3, September 1977, pp. 223 - 252.

[Peterson, 1981]. J.L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice Hall, Englewood Cliffs, New Jersey, 1981.

[Richardson et al., 1992]. J.E. Richardson, R.C. Schultz, and E.V. Berard, A Complete Object-Oriented Design Example, Berard Software Engineering, Gaithersburg, Maryland, 1992.

[Schultz, 1992]. R.C. Schultz, A Project Management Handbook for Object-Oriented Software Development, Volume 1, Berard Software Engineering, Gaithersburg, Maryland, 1992.

[Schalkoff, 1990]. R.J. Schalkoff, Artificial Intelligence: An Engineering Approach, McGraw-Hill Publishing Company, New York, New York, 1990.

[Ward and Mellor, 1985]. P.T. Ward and S.J. Mellor, Structured Development for Real-Time Systems, Volume 1, Yourdon Press, New York, New York, 1985.

[Winston, 1984]. P.H. Winston, Artificial Intelligence, Second Edition, Addison-Wesley, Reading, Massachusetts, 1984.

[TOA Home Page] [HTML Documents] [Contact TOA]