Plete

DRAFT
Handbook for Object-Oriented

Technology in Aviation (OOTiA)
Volume 1: Handbook Overview

Revision 0
October 26, 2004
This Handbook does not constitute Federal Aviation Administration (FAA)

policy or guidance, nor is it intended to be an endorsement of object-oriented
technology (OOT). This Handbook is not to be used as a standalone product
This Handbook does not constitute Federal Aviation Administration (FAA) policy or guidance nor is
it intended to be an endorsement of OOT. This Handbook is not to be used as a standalone product
but, rather,
but, rather,as input
as input whenwhen considering
considering issues in
issues in a project-specific a project-specific context.
context.
Volume 1
NOTE: This Handbook does not constitute Federal Aviation Administration (FAA) policy or guidance, nor is it
intended to be an endorsement of object-oriented technology (OOT). This Handbook is not to be used as a
standalone product but, rather, as input when considering issues in a project-specific context.
1-ii
Volume 1
Contents
1.1 HANDBOOK INTRODUCTION .................................................................................................................... 1-1
1.1.1 Purpose.............................................................................................................................................. 1-1
1.1.2 Background........................................................................................................................................ 1-1
1.2 HANDBOOK ORGANIZATION .................................................................................................................... 1-2
1.2.1 Scope.................................................................................................................................................. 1-2
1.2.2 Approach ........................................................................................................................................... 1-2
1.3 OOT BACKGROUND ................................................................................................................................ 1-4
1.3.1 OOT Basics........................................................................................................................................ 1-4
1.3.2 Principles of OOT.............................................................................................................................. 1-5
1.3.3 OOT Methodology ............................................................................................................................. 1-6
1.3.4 OOT Languages................................................................................................................................. 1-7
1.3.5 Additional Key OO Concepts............................................................................................................. 1-7
1.3.6 Further OOT Reading........................................................................................................................ 1-8
1.4 ACRONYM LIST ....................................................................................................................................... 1-9
1.5 GLOSSARY............................................................................................................................................. 1-11
1.6 OOTIA WORKSHOPS ............................................................................................................................. 1-25
1.6.1 Workshop Committee....................................................................................................................... 1-25
1.6.2 Participants in Workshop #1 ........................................................................................................... 1-25
1.6.3 Participants in Workshop #2 ........................................................................................................... 1-28
1.7 REFERENCES ......................................................................................................................................... 1-32
1.8 FEEDBACK FORM .................................................................................................................................. 1-33
Figures
Figure 1.2-1 Handbook Approach............................................................................................................................. 1-2
Figure 1.3-1 Object-Oriented Class Representation ................................................................................................. 1-5
Figure 1.3-2 OOA Tasks............................................................................................................................................ 1-7
NOTE: This Handbook does not constitute Federal Aviation Administration (FAA) policy or guidance, nor is it intended
to be an endorsement of object-oriented technology (OOT). This Handbook is not to be used as a standalone product but,
rather, as input when considering issues in a project-specific context. 1-iii
Volume 1
1.1 Handbook Introduction
1.1.1 Purpose
The purpose of this four-volume Handbook is to identify key issues and provide some potential approaches to
address these issues when using OOT in airborne products. Although some of the issues identified in this Handbook
are not unique to OOT, they are discussed in the Handbook because the way they are addressed is key to safe
implementation of OOT. This Handbook also provides an approach for certification authorities and their designees
to help ensure that OOT issues have been addressed in the projects they are reviewing or approving.
1.1.2 Background
Compliance with the objectives of RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment
Certification [1], is the primary means of obtaining approval of software used in civil aviation products. When DO-
178B was published in 1992, procedure programming was the predominant technique for organizing and coding
computer programs. Consequently, DO-178B provides guidelines for software developed using a functional
technique and does not specifically consider software developed using OOT. OOT is a software development
technique that is “expressed in terms of objects and connections between those objects” [9]. Since object-oriented
technology differs from the traditional functional approach to software development, satisfying some of the DO-
178B objectives when using OOT may be unclear and/or complicated.
To date, few airborne computer systems in civil aviation have been implemented using OOT. Although OOT is
intended to promote productivity, increase reusability of software, and improve quality, uncertainty about how to
comply with certification requirements has been a key obstacle to using OOT in airborne systems.
Although organizations such as the Object Management Group (OMG) work to develop specifications for OOT, no
universal guidelines exist for using OOT in safety-critical systems. Certification authorities have been using issue
papers on a project-by-project basis to address OOT concerns. These project-specific issue papers document high-
level safety issues and concerns with OOT but do not suggest or provide detailed issues or acceptable solutions.
This Handbook extends the use of issue papers by identifying key issues and providing some guidelines to help the
software community satisfy applicable DO-178B objectives when using OOT. It also provides an approach for
certification authorities and their designees when evaluating OOT projects.
The FAA co-sponsored the Object-Oriented Technology in Aviation (OOTiA) project with the National Aeronautics
and Space Administration (NASA) to address OOT challenges in aviation. The FAA, NASA, other government
organizations, academia, international certification authorities, airborne systems manufacturers, and aircraft
manufacturers collaborated through two OOTiA workshops and the OOTiA workshop committee to produce this
Handbook [see Section 1.6 for additional information on the workshops].
It is anticipated that this Handbook and other documents may be used to impact future changes to the FAA’s
software guidance (e.g., to impact future revisions to DO-178B or supplementary guidance). It is also anticipated
that this Handbook will be updated in the future as OOT in aviation matures and lessons are learned. If you have
comments, suggested improvements to this Handbook, additional issues, or potential solutions to address an issue(s),
please complete and submit the feedback form in Section 1.8 of this volume.
rather, as input when considering issues in a project-specific context. 1-1
Volume 1
1.2 Handbook Organization
1.2.1 Scope
This Handbook documents key issues and some potential approaches to address these issues when using OOT in
airborne systems. It is intended to be informational and educational – a compilation of what we know to date
regarding the use of OOT in aviation systems. This Handbook does not constitute Federal Aviation
Administration (FAA) policy or guidance nor is it intended to be an endorsement of OOT. This Handbook is
not to be used as a standalone product but, rather, as input when considering issues in a project-specific
context. In addition, this Handbook does not attempt to define the project criteria or circumstances under which this
Handbook should or should not be used in software development. That determination is left to project planners,
decision makers, or developers, as appropriate.
This Handbook addresses issues that were identified as having potential impact in safely applying OOT in airborne
systems. Certification authorities, industry, and others submitted potential issues through a web site dedicated to the
OOTiA project [7]. Some of the issues are not unique to OOT (e.g., inlining and templates); however, these issues
are discussed in the Handbook because the way they are addressed is key to safe implementation of OOT. Note that
this Handbook does not address all potential issues, nor are the guidelines in Volume 3 the only possible solutions to
addressing the related issues. As technology advances and experience with OOT increases within the aviation
community, this Handbook will likely be updated.
1.2.2 Approach
The Handbook follows a “tiered” approach as shown in Figure 1.2-1 in which each of its four volumes provides the
foundation for all volumes above it. For example, Volume 3: Best Practices relies on contents in both Volume 1:
Handbook Overview and Volume 2: Considerations and Issues in substantiating its guidelines.
The four volumes are:
• Volume 1: Handbook Overview (this volume)
• Volume 2: Considerations and Issues
• Volume 3: Best Practices
• Volume 4: Certification Practices
Volume 4:
Certification Practices
Volume 3: Best Practices
Volume 2: Considerations and Issues
Volume 1: Handbook Overview
Figure 1.2-1 Handbook Approach
1-2
rather, as input when considering issues in a project-specific context.
Volume 1
Each volume is written for a unique combination of target audience and purpose. Each volume is self-contained in
that each has a separate list of references applicable to that volume alone. However, to provide a consistent basis
among volumes, Volume 1: Handbook Overview contains the Acronym List (see section 1.4) and Glossary (see
section 1.5) common to all volumes.
The following sections provide the title, target audience, purpose, and overview of the contents for each volume.
1.2.2.1 Volume 1: Handbook Overview

Target Audience: All Handbook users
Purpose: Provide background and foundational information needed to use all other volumes
Contents: Handbook introduction
Organizational overview of Handbook into volumes
OOT background
Handbook acronym list
Handbook glossary
OOTiA workshop committee and participants lists
References for Volume 1
Feedback form for suggested improvements to the Handbook
1.2.2.2 Volume 2: Considerations and Issues

Target Audience: Project planners, decision makers, certification authorities, designees
Purpose: Report and discuss the challenges collected throughout the OOTiA project
Contents: Considerations before making the decision to use OOT
Considerations after making the decision to use OOT
Open issues (summary of OOTiA Workshop #2 brainstorming session)
Summary
Results of the “Beyond the Handbook” session of OOTiA Workshop #2
Mapping of issue list to considerations
Additional considerations for project planning
1.2.2.3 Volume 3: Best Practices

Target Audience: Airborne systems and OOT software developers, certification authorities, designees
Purpose: Identify best practices to safely implement OOT in airborne systems by providing some known
ways to address the issues documented in Volume 2
Contents: Mapping of Volume 2 issues to Volume 3 guidelines
Guidelines for demonstrating DO-178B compliance and safely addressing:
Single inheritance and dynamic dispatch
Multiple inheritance
1-3
Volume 1
Templates
Inlining
Type conversion
Overloading and method resolution
Dead and deactivated code, and reuse
Object-oriented tools
Traceability
Structural coverage
Index of terms
Frequently asked questions
Extended guidelines and examples
1.2.2.4 Volume 4: Certification Practices

Target Audience: Certification authorities and designees
Purpose: Provide an approach to ensure that OOT issues are addressed
Contents: Activities for Stages of Involvement 1- 4
1.3 OOT Background
1.3.1 OOT Basics

Object-oriented approaches date to the introduction of the programming language Simula in 1967. Most recently
they have been standardized by the Object Management Group (OMG) through their definition of a Unified
Modeling Language (UML) [16], and in other specifications related to model-driven architectures, distributed object
communication, etc.
OOT is a software development technique that is centered on “objects.” The Institute of Electrical and Electronics
Engineers (IEEE) refers to OOT as “a software development technique in which a system or component is expressed
in terms of objects and connections between those objects” [9]. An object can be compared to a “black box” at the
software level – it sends and receives messages. The object contains both code (methods) and data (structures). The
user does not need to have insight into the internal details of the object in order to use the object, hence the
comparison to a black box. An object can model real world entities, such as a sensor or hardware controller, as
separate software components with defined behaviors.
A major concept in OOT is the “class.” A class is a set of objects that share the same attributes, methods,
relationships, and semantics – they share a common structure and behavior [16]. A class describes the characteristics
and behavior of a real world entity. Figure 1.3-1 illustrates a representation of a class definition for an object.
1-4
Volume 1
Class Name
Attributes:
Operations:
Figure 1.3-1 Object-Oriented Class Representation
1.3.2 Principles of OOT

There are seven principles that form the foundation for OOT: abstraction, encapsulation, modularity, hierarchy,
typing, concurrency, and persistence [8]. Not all of these principles are unique to OOT, but the OOT development
methodology embodies these seven principles. Abstraction, modularity, concurrency, and persistence are principles
that are commonly used in other development methodologies. However, encapsulation (using a technique called
information hiding), hierarchy (using a technique called inheritance), and typing (using a concept called
polymorphism) are relatively unique to OOT. Each of the seven principles is described below.
Abstraction is one of the fundamental ways that complexity is addressed in software development. “An abstraction
denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide
crisply defined conceptual boundaries, relative to the perspective of the viewer" [8].
Encapsulation is the process of hiding the design details in the object implementation. Encapsulation can be
described as “the mechanism that binds together code and the data it manipulates, and keeps both safe from outside
interference and misuse” [15]. Encapsulation is generally achieved through information hiding, which is the process
of hiding the aspects of an object that are not essential for the user to see. Typically, both the structure and the
implementation methods of the object are hidden.
Modularity is the process of dividing a program into logically separated and defined components that possess
defined interactions and limited access to data. Booch writes that modularity is a “property of a system that has been
decomposed into a set of cohesive and loosely coupled modules” [8].
Hierarchy is simply the ordering of abstractions. Examples of hierarchy are single inheritance and multiple
inheritance. In OOT, when a sub-class is created, this new class “inherits” all of the existing attributes and
operations of the original class, called the “parent” or “superclass” [13]. Inheritance is a relationship between classes
where one class is the “parent” (also called “base,” “superclass,” or “ancestor”) class of another [6]. One author puts
it this way, “Inheritance is a relationship among classes where a child class can share the structure and operations of
a parent class and adapt it for its own use” [10].
Inheritance is one of the key differences between OOT and conventional software development. There are two types
of inheritance: single inheritance and multiple inheritance. In single inheritance, the sub-class inherits the attributes
and operations from a single superclass. In multiple inheritance, the sub-class inherits some attributes from one class
and others from another class. Multiple inheritance is controversial, because it complicates the class hierarchy and
configuration control [14].
1-5
Volume 1
Typing is a principle that is used in OOT that has many definitions. Booch presents one of the most clear and
concise definitions by stating, “Typing is the enforcement of the class of an object, such that objects of different
types may not be interchanged, or at the most, they may be interchanged only in very restricted ways” [8]. Examples
of OOT typing are strong typing, weak typing, static typing, and dynamic typing. Each OOT programming language
varies in its implementation of typing.
Another OOT concept closely related to typing is polymorphism. Polymorphism comes from the Greek meaning
“many forms.” It allows one name to be used for two or more related but different purposes [15]. It is the ability of
an object to assume or become many different forms of an object. Polymorphism specifies slightly different or
additional structure or behavior for an object, when assuming or becoming an object [11]. This allows different
underlying implementations for the same command. For example, assume there exists a vehicle class that includes a
steer-left command. If a boat object was created from the vehicle class, the steer-left command would be
implemented by a push to the right on a tiller. However, if a car object was created from the same class, it might use
a counter-clockwise rotation of the steering wheel to achieve the same command.
Concurrency is the process of carrying out several events simultaneously.
Persistence is “the property of an object through which its existence transcends time (i.e., the object continues to
exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which
it was created)” [8].
1.3.3 OOT Methodology

OOT can typically be described in four processes: Object-Oriented Analysis (OOA), Object-Oriented Design
(OOD), Object-Oriented Programming (OOP), and Object-Oriented Verification/Test (OOV/T). The
implementation of these processes is typically iterative or evolutionary. An overview of each process is addressed
below.
OOA is the process of defining all classes that are relevant to solve the problem and the relationships and behavior
associated with them [14].
A number of tasks occur to carry out the OOA as shown in Figure 1.3-2. The tasks are reapplied until the model is
completed. As shown in Figure 1.3-2, use cases, class-responsibility-collaborator (CRC) models, object-relationship
(OR) models, and object-behavior (OB) models are methods typically used to carry out the OOA. The use case is a
method utilized to identify the user’s requirements. The CRC model is used to identify the class attributes,
operations, and hierarchy. The OR model is used to illustrate the relationship between the numerous objects. And,
the OB model is used to model the behavior of each object.
OOD transforms the OOA into a “blueprint” for software “construction.” Four layers of design are usually defined:
subsystem layer, class and object layer, message layer, and responsibilities layer. The subsystem design layer
represents each subsystem that enables software to achieve the requirements. The class and object design layer
contains class hierarchies and object designs. The message design layer contains the internal and external interfaces
to communicate between objects. The responsibilities design layer contains the algorithm design and data structures
for attributes and operations of each object.
OOP is the coding process of the software development, using an OO language (e.g., C++, Ada 95).
OOV/T is the process of detecting errors and verifying the correctness of the OOA, OOD, and OOP. OOV/T
includes reviews, analyses, and tests of the software requirements, design, and implementation. OOV/T requires
slightly different strategies and tactics than the traditional functional approach. The variance in the approach is
driven by characteristics like inheritance, encapsulation, and polymorphism. Many developers use a design for
testability approach to begin addressing any verification/test issues early in the program.
1-6
Volume 1
Identify user
requirements
(use cases)
Identify classes
(attributes &
operations) (CRC)
Reapply as needed
Specify class
hierarchy
(CRC)
Identify object-
to-object
relationships (OR)
Model object
behavior (OB)
Figure 1.3-2 OOA Tasks
1.3.4 OOT Languages

Many OO languages exist. Some of the most well known are C++, Smalltalk, Ada 95, and Java. C++, Ada 95, and
Java are of particular interest for designers of embedded software. C++’s tool support, Ada 95’s extension of Ada
83, and Java’s platform independence make these languages very appealing to the developers of airborne systems.
But each language has its own set of challenges. Volume 3 of this Handbook attempts to address language-specific
issues, where possible. Other volumes are intended to be language-independent. C# is another OO language being
considered for embedded software. However, it is still maturing and is not yet addressed in this Handbook.
1.3.5 Additional Key OO Concepts

In addition to the OO concepts described above, the following concepts are important OO concepts mentioned in
this Handbook.
Dynamic dispatch is the association of a method with a call based on the run-time type of the target object. Dynamic
dispatch is not related to dynamic linking nor dynamic link libraries. Dynamic dispatch is sometimes referred to as
“dynamic binding.” There are two types of dynamic dispatch used in OO:
• Single dispatch is dynamic dispatch based on only the run-time type of the target object. Most OO
languages, including Java, Ada 95 and C++ are single dispatching.
• Multiple dispatch is dynamic dispatch based on the run-time types of all the arguments to a call, rather than
only the run-time type of the target object.
1-7
Volume 1
The Liskov substitution principle (LSP) is a set of subtyping rules that ensure that instances of a subclass are
substitutable for instances of all parent classes in every context in which they may appear. These rules go beyond the
simple checking of signatures, taking into account the behavior of operations (as defined by their pre- and post-
conditions) and the invariants defined by classes. Even if classes are not defined formally, the principle can be
upheld by requiring the inheritance of test cases. Reference [17] provides additional insight into the LSP concept.
1.3.6 Further OOT Reading

The section identifies some resources recommended for those who desire to study OOT in more depth. While this is
not an exhaustive list of OO references, it is intended to provide a starting point for those interested in learning more
about OOT. The Reference sections of this volume and the other Handbook volumes provide additional resources.
• The Object-Oriented Thought Process by Matt Weisfeld (SAMS Publishing, 2000): This book provides a
simple introduction to the OO fundamentals. It is a good resource for those transitioning from the
functional approach to OO.
• Object-Oriented Analysis and Design by Grady Booch (Addison-Wesley, 2nd edition, 1994): This book
provides a practical introduction to OO concepts, methods, and applications.
• Pitfalls of Object-Oriented Development by Bruce Webster (M&T Books, 1995): Although somewhat
dated, this book provides a sound overview of the potential problems in OO development. A summary of
its main points are included in Appendix C of Volume 2 since the book is now out of print.
• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph
Johnson and John Vlissides (Addison-Wesley, 1995): Patterns are widely used by the OO community to
address analysis and design problems. This book provides a guide for effective development and use of
patterns.
• Object-Oriented Software Construction by Bertrand Meyer (Prentice Hall, 2nd edition, 1997): Although a
large book, this one provides good fundamental information for OO developers.
• Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert V. Binder (Addison-Wesley,
Reading, MA, 2000): This book addresses one of the more difficult aspects of OOT testing.
1-8
Volume 1
1.4 Acronym List

The following acronym list applies to all volumes of this Handbook:
AC Advisory Circular
ACB Anomalous Construction Behavior
AMJ Advisory Material Joint
API Application Programming Interface
AVSI Aerospace Vehicle Systems Institute
BIT Built-in Test
CAST Certification Authorities Software Team
CC Control Category
CM Configuration Management
CORBA Common Object Request Broker Architecture
COTS Commercial Off-The-Shelf
CRC Class-Responsibility-Collaborator
DBC Design By Contract
DER Designated Engineering Representative
EASA European Aviation Safety Agency
EUROCAE European Organization for Civil Aviation Equipment
FAA Federal Aviation Administration
HIT Hierarchical Incremental Testing
IEEE Institute of Electrical and Electronics Engineers
IL Issue List
IP Issue Paper
JAA Joint Aviation Authorities
LRU Line Replaceable Unit
LSP Liskov Substitution Principle
MC/DC Modified Condition / Decision Coverage
NASA National Aeronautics and Space Administration
OB Object Behavior
OMG Object Management Group
OO Object-Oriented
OOA Object-Oriented Analysis
OOD Object-Oriented Design
OOP Object-Oriented Programming
OOT Object-Oriented Technology
OOTiA Object-Oriented Technology in Aviation
OOV/T Object-Oriented Verification/Test
OR Object Relationship
PDS Previously Developed Software
PSAC Plan for Software Aspects of Certification
RBT Requirements-Based Testing
R-D-C Requirements-Design-Code
RSC Reusable Software Component
RTCA RTCA, Inc.
1-9
Volume 1
SAS Software Accomplishment Summary

SCI Software Configuration Index
SDA State Definition Anomaly
SDI State Defined Incorrectly
SDIH State Definition Inconsistency
SOI Stage of Involvement
SSA System Safety Assessment
SVA State Visibility Anomaly
UML Unified Modeling Language
1-10
Volume 1
1.5 Glossary
This glossary provides definitions for terms used in this Handbook to discuss object-oriented technology issues. It is
intended to provide terminology for consistent communication and discussion of issues. Many terms are taken
directly from the glossary 1 of RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment
Certification [1]. Other terms are taken from references on object-oriented technology. References are noted, as
appropriate, after each definition. Relationships between terms are denoted as contrast, synonym, and see, where
specifically pertinent to the definition. This glossary is a resource to be used for all volumes of the Handbook.
Abstract class - A class that cannot be directly instantiated. Any class containing an abstract operation must itself be
abstract. Contrast: concrete class. [2], [16]
Abstract operation - An operation that is declared but not implemented by an abstract class. Abstract operations do
not have associated methods (bodies) in the class that defines them, but must have an associated implementation in
concrete subclasses. See: operation, method. [2], [8] Contrast: concrete operation.
Abstract pattern - A pattern that does not prescribe a particular approach. Additional guidelines are defined by sub-
patterns of the abstract pattern where these guidelines vary by the approach used.
Access mechanism - The manner in which a software component is called upon to perform its intended function.
This includes invocation mechanisms and data flow to and from the component. This is typically part of the
interface description data. [3]
Actual parameter - See: argument.
Aggregation - A composition technique for building a new object from one or more existing objects that support
some or all of the new object's required interfaces. Synonym: composition. [18]
Algorithm - A finite set of well-defined rules that gives a sequence of operations for performing a specific task. [1]
Anomalous behavior - Behavior that is inconsistent with specified requirements. [1]
Applicant - A person or organization seeking approval from the certification authority. [1]
Approval - The act or instance of expressing a favorable opinion or giving formal or official sanction. [1]
Argument - A binding for a parameter that resolves to a run-time instance. Synonym: actual parameter. Contrast:
parameter. [16]
Aspect-oriented programming - An approach used to encapsulate policies and strategies that cross-cut the core
functionality of a system. Such system- or subsystem-wide policies are referred to aspects. They include policies for
error handling, synchronization, resource allocation, fault-tolerance, performance, software monitoring, distributed
data access, and other potentially safety related issues. Aspect-oriented programming is generally viewed as
complementary to object-oriented development. [2]
Assertion - A Boolean expression whose value should always evaluate to true at a given point in a program's
execution. For example, a pre-condition, whose value should evaluate to true whenever a given operation is called; a
post-condition, whose value should evaluate to true upon the normal (non-exceptional) return from a given
operation; or a class invariant, whose value should evaluate to true after the execution of a class constructor and
before/after the execution of every externally visible operation on the class.
Association - The semantic relationship between two or more classifiers that specifies connections among their
instances. Such connections may be represented as pointers or access types that reference other objects. They may
also be computed rather than stored. [2], [16]
Assurance - The planned and systematic actions necessary to provide adequate confidence and evidence that a
product or process satisfies given requirements. [1]
1
The glossary definitions from RTCA/DO-178B are used with permission of RTCA.
1-11
Volume 1
Attribute - A feature within a class that describes a range of values those instances of the class may hold. Attributes
are stored values or fields in Ada 95, C++, and Java. They may represent either data values or references to other
objects (association ends). [2], [16]
Audit - An independent examination of the software life cycle processes and their outputs to confirm required
attributes. [1]
Baseline - The approved, recorded configuration of one or more configuration items, that thereafter serves as the
basis for further development, and that is changed only through change control procedures. [1]
Certification - Legal recognition by the certification authority that a product, service, organization, or person
complies with the requirements. Such certification comprises the activity of technically checking the product,
service, organization, or person and the formal recognition of compliance with the applicable requirements by issue
of a certificate, license, approval, or other documents as required by national laws and procedures. In particular,
certification of a product involves: (a) the process of assessing the design of a product to ensure that it complies with
a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety; (b) the process
of assessing an individual product to ensure that it conforms with the certified type design; (c) the issuance of a
certificate required by national laws to declare that compliance or conformity has been found with standards in
accordance with items (a) or (b) above. [1]
Certification authority - The organization or person responsible within the state or country concerned with the
certification of compliance with the requirements.
Note: A matter concerned with aircraft, engine, or propeller type certification or with equipment approval would
usually be addressed by the certification authority; matters concerned with continuing airworthiness might be
addressed by what would be referred to as the airworthiness authority. [1]
Certification credit - Acceptance by the certification authority that a process, product, or demonstration satisfies a
certification requirement. [1] See: credit.
Change control - (1) The process of recording, evaluating, approving, or disapproving and coordinating changes to
configuration items after formal establishment of their configuration identification or to baselines after their
establishment. (2) The systematic evaluation, coordination, approval, or disapproval and implementation of
approved changes in the configuration of a configuration item after formal establishment of its configuration
identification or to baselines after their establishment.
Note: This term may be called configuration control in other industry standards. [1]
Checked type conversion - Types are checked if conversion from one type to the other includes a determination
either by the compiler or at run-time as to whether they are normally convertible.
Child - In a generalization relationship, the specialization of another element, the parent. See: subclass, subtype.
Contrast: parent, superclass, supertype. Child classes inherit from their parent classes. Similarly, subclasses inherit
from their superclasses. [2], [16]
Class - Informally, any classifier. Formally, a description of a set of objects that share the same attributes,
operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of
operations it provides to its environment. [2], [16]
Class hierarchy - A collection of classes connected by generalization relationships. The root of the hierarchy
represents the most general of these classes. The leaves represent the most specific of these classes. Synonym:
inheritance hierarchy.
Classifier - The Unified Modeling Language (UML) defines the term classifier to include interfaces, classes,
datatypes, and components. In the Aerospace Vehicle Systems Institute (AVSI) guide (and elsewhere), the term
“class” is often used informally as a synonym for classifier. Formally, however, classes describe only objects, which Mis en forme
have an identity and state, and not datatypes, interfaces, or components. [2], [16]
Client class - A class that can reference the attributes of another class.
1-12
Volume 1
Client operation - An operation accessible to classes other than the defining class and its subclasses.
Code - The implementation of particular data or a particular computer program in a symbolic form, such as source
code, object code, or machine code. [1]
Code-sharing - The sharing of code by more than one class or component (e.g., by means of implementation
inheritance or delegation). See: implementation inheritance, delegation.
Note: There are many ways to support the sharing of code. The risk is that inheritance can be misused to support
only the sharing of code and data structure, without attempting to follow behavioral subtyping rules.
Commercial off-the-shelf (COTS) software - Commercially available applications sold by vendors through public
catalog listings. COTS software is not intended to be customized or enhanced. Contract-negotiated software
developed for a specific application is not COTS software. [1]
Compiler - Program that translates source code statements of a high level language, such as FORTRAN or Pascal,
into object code. [1]
Component - (1) A self-contained part, combination of parts, sub-assemblies or units, which performs a distinct
function of a system. (2) A physical, replaceable part of a system that packages implementation and provides the
realization of a set of interfaces. [1], [16]
Composition - See: aggregation.
Concrete class - A class that can be directly instantiated. A concrete class has no abstract operations. Contrast:
abstract class. [2], [16]
Concrete operation - An operation that has an associated method in the context of a given class. Contrast: abstract
operation. [2]
Concurrency - (1) Process of carrying out several events simultaneously. (2) A technique used in an operating
system for sharing a single processor between several independent jobs. [18]
Condition - A Boolean expression containing no Boolean operators. [1]
Condition/Decision Coverage - Every point of entry and exit in the program has been invoked at least once, every
condition in a decision in the program has taken on all possible outcomes at least once, and every decision in the
program has taken on all possible outcomes at least once. [1]
Configuration identification - (1) The process of designating the configuration items in a system and recording their
characteristics. (2) The approved documentation that defines a configuration item. [1]
Configuration item - (1) One or more hardware or software components treated as a unit for configuration
management purposes. (2) Software life cycle data treated as a unit for configuration management purposes. [1]
Configuration management - (1) The process of identifying and defining the configuration items of a system,
controlling the release and change of these items throughout the software life cycle, recording and reporting the
status of configuration items and change requests and verifying the completeness and correctness of configuration
items. (2) A discipline applying technical and administrative direction and surveillance to: (a) identify and record the
functional and physical characteristics of a configuration item, (b) control changes to those characteristics, and (c)
record and report change control processing and implementation status. [1]
Configuration status accounting - The recording and reporting of the information necessary to manage a
configuration effectively, including a listing of the approved configuration identification, the status of proposed
changes to the configuration and the implementation status of approved changes. [1]
Constraint - A semantic condition or restriction. Constraints include pre-conditions, post-conditions, and invariants.
They may apply to a single class of objects, to relationships between classes of objects, to states, or to use cases.
[16]
Constructor - An operation that creates an object and/or initializes its state. Formally, the constructor is responsible
for establishing any class invariant.
1-13
Volume 1
Control coupling - The manner or degree by which one software component influences the execution of another
software component. [1]
Control coupling analysis - Evaluation of the execution relationships and dependencies between software
components and in component logic to ensure application execution is correctly designed and implemented.
Control flow analysis - (1) Analysis typically used in the identification and confirmation of control coupling. DO-
178B does not explicitly define this term or the related term control flow. However, it references both (on pages 21,
28, 52, 61, and 57). [1] (2) Analysis whose objectives are: to ensure the code is executed in the right sequence, to
ensure the code is well structured, to locate any syntactically unreachable code, and to highlight parts of the code
where termination needs to be considered (i.e., loops and recursion). Call tree analysis is cited as an example of one
of many control flow analysis techniques, and is offered as a means of confirming that design rules for the
partitioning of critical and non-critical code have been followed. [5]
Control program - A computer program designed to schedule and to supervise the execution of programs in a
computer system; e.g., operating system, executive, run-time system. [1]
Conversion - See: type conversion.
CORBA - An industry wide standard for communication between distributed objects, independent of their location
and target language. The CORBA standard is defined by the Object Management Group (OMG). CORBA itself is
an acronym for Common Object Request Broker Architecture. [2]
Coupling - A relationship between components or elements.
Coverage analysis - The process of determining the degree to which a proposed software verification process
activity satisfies its objective. [1]
Credit - The compliance to one or more RTCA/DO-178B objectives supported by RTCA/DO-178B software life
cycle data. This compliance is used to show that the certification basis has been met and the equipment may receive
a certificate. Three types of credit are referred to throughout AC 20-148 [3]:
1. Full credit: fully meets the RTCA/DO-178B objective and requires no further activity by the user.
2. Partial credit: partially meets the RTCA/DO-178B objective and requires additional activity by the user to
complete compliance.
3. No credit: does not meet the RTCA/DO-178B objective and must be completed by the user for
compliance. [3]
Data abstraction - An abstraction denotes the essential characteristics of an object that distinguish it from all other
kinds of objects, suppressing all non-essential details. In data abstraction the non-essential details deal with the
underling data representation. [8] [16]
Database - A set of data, part or the whole of another set of data, consisting of at least one file that is sufficient for a
given purpose or for a given data processing system. [1]
Data coupling - The dependence of a software component on data not exclusively under the control of that software
component. [1]
Data coupling analysis - An evaluation of the data flow relationships and dependencies between software
components to ensure they are correctly designed and implemented.
Data dictionary - The detailed description of data, parameters, variables, and constants used by the system. [1]
Data flow analysis - (1) Analysis typically used in the identification and confirmation of data coupling. DO-178B
does not explicitly define this term or the related term data flow. However, it references both (on pages 21, 28, 52,
61, and 57). [1] (2) Analysis whose objective is to show that there is no execution path in the software that would
access a variable that does not have a set value. Data flow analysis uses the results of control flow analysis in
conjunction with the read or write access to variables to perform the analysis. Data flow analysis can also detect
other code anomalies such as multiple writes without intervening reads. [5]
1-14
Volume 1
Data type, Datatype - (1) A class of data characterized by the members of the class and the operations that can be
applied to them. Examples are character types and enumeration types. (2) A descriptor of a set of values that lack
identity and whose operations do not have side effects. Datatypes include primitive pre-defined types and user-
definable types. Pre-defined types include numbers, string and time. User-definable types include enumerations.
Note: Instances of datatypes, unlike objects, do not have identity or state, but are immutable. As a result,
operations on datatypes do not change the state of values they act upon, but compute new values based on existing
ones. Some languages use the term immutable in combination with terms class and object to denote a datatype and
its values. [1], [2] See: immutable.
Deactivated code - Executable object code (or data) which by design is either (a) not intended to be executed (code)
or used (data), for example, a part of a previously developed software component, or (b) is only executed (code) or
used (data) in certain configurations of the target computer environment, for example, code that is enabled by a
hardware pin selection or software programmed options. [1]
Dead code - Executable object code (or data) which, as a result of a design error cannot be executed (code) or used
(data) in a operational configuration of the target computer environment and is not traceable to a system or software
requirement. An exception is embedded identifiers. [1]
Decision - A Boolean expression composed of conditions and zero or more Boolean operators. A decision without a
Boolean operator is a condition. If a condition appears more than once in a decision, each occurrence is a distinct
condition. [1]
Decision Coverage - Every point of entry and exit in the program has been invoked at least once and every decision
in the program has taken on all possible outcomes at least once. [1]
Declared type - The type associated with a name (such as a variable, constant or parameter) at its point of
declaration. The run-time type of any associated object must be a subtype of its declared type. [2]
Delegation - The implementation of an operation by means of a call to an equivalent operation on a component
object (the delegate). Delegation can be used as an alternative to implementation inheritance. Contrast: inheritance.
[2]
Derived requirements - Additional requirements resulting from the software development processes, which may not
be directly traceable to higher level requirements. [1]
Derived type - A type derived for specialization from another type. The derived type is a specialization from the
conceptual point of view and may be an expansion from the structural point of view. [4]
Design pattern - A documented solution to a commonly encountered design problem. In general, a design pattern
presents a problem, followed by a description of its solution in a given context and programming language. [2]
Designee - An industry representative that has been authorized by the FAA to make findings of compliance on
behalf of the FAA.
Destructor - An operation that frees the state of an object and/or destroys the object itself. [8]
Dynamic binding - See: dynamic dispatch.
Dynamic classification - A semantic variation of generalization in which an object may change its classifier.
Contrast: static classification. Using dynamic classification, the class of an object may change during its lifetime.
Using static classification, it may not. [2], [16]
Dynamic dispatch - The association of a method with a call based on the run-time type of the target object. Dynamic
dispatch is not related to dynamic linking or dynamic link libraries. Synonym: dynamic binding. [2]
Dynamic loading (of classes) - The loading of classes dynamically (at run-time) when they are first referenced by an
application. The desktop Java environment, for example, provides a class loader capable of finding and loading a
named class appearing in any of a prescribed list of locations, which may be either local or remote. In real-time
systems, class loading is generally not supported or permitted.
1-15
Volume 1
Emulator - A device, computer program, or system that accepts the same inputs and produces the same output as a
given system using the same object code. [1]
Equivalence class - The partition of the input domain of a program such that a test of a representative value of the
class is equivalent to a test of other values of the class. [1]
Error - With respect to software, a mistake in requirements, design or code. [1]
Executable Object Code - Consists of a form of Source/Object Code that is directly usable by the central processing
unit of the target computer and is, therefore, the software that is loaded into the hardware or system. [1]
Explicit type conversion - Conversion of a value from its type to a designated type by use of a conversion routine.
Failure - The inability of a system or system component to perform a required function within specified limits. A
failure may be produced when a fault is encountered. [1]
Failure condition - The effect on the aircraft and its occupants both direct and consequential, caused or contributed
to by one or more failures, considering relevant adverse operational and environmental conditions. A failure
condition is classified according to the severity of its effect as defined in FAA AC 25.1309-1A or JAA AMJ
25.1309. [1]
Fault - A manifestation of an error in software. A fault, if it occurs, may cause a failure. [1]
Fault tolerance - The built-in capability of a system to provide continued correct execution in the presence of a
limited number of hardware or software faults. [1]
Feature - An attribute, operation, or method. This includes attributes that reference other objects (i.e., association
ends). Features correspond to methods and fields in Java, methods and member functions in C++, and subprograms
and record fields in Ada 95.
Flattened class - The flattened form of a class is a self contained module representing the composition of its
elements with those inherited by it, taking into account the rules for inheritance associated with the language.
Inherited elements appear in the flattened class if: 1) they are defined by a superclass and never overridden, or 2)
they are defined by a superclass and referenced by some other element that is not overridden. Some languages (e.g.,
Eiffel) allow you to print the flattened form of a class interface. This is useful to clients because it specifies the full
client interface, eliminating the need to refer to superclass definitions. [12]
Flow analysis - A term encompassing both control flow analysis and data flow analysis. [2]
Formal analysis - A type of analysis with a range of acceptable approaches, some of which are only minimally
formal (assertions are specified in a reasonably precise manner), others of which are highly formal (involve use of
formal specification languages and supporting tools). The former would involve writing assertions in some agreed
upon, reasonably precise form, and some simple inspections (involving checking of signatures and pre-/post-
conditions) where the basis for the checks is formal, but no training in formal methods is required and no formal
methods tools need be used. The latter would involve formal methods to provide an automated approach with more
precise, more completely specified assertions that serve as the basis for model checking and other forms of analysis.
Formal methods - Descriptive notations and analytical methods used to construct, develop, and reason about
mathematical models of system behavior. [1]
Framework - A framework is a partially completed software application, which has a set of related classes that can
be specialized and/or instantiated to implement the application. Since the UML is a formally defined language, some
of the existing visual modeling tools use existing frameworks to help the coder/developer generate complete
applications from UML models.
Generalization - A taxonomic relationship between a more general element and a more specific element. The more
specific element is fully consistent with the more general element and contains additional information. An instance
of the more specific element may be used where the more general element is allowed. See: inheritance. [16]
Generic - In an Ada program, a generic is a unit that allows the same logical function on more than one type of data.
1-16
Volume 1
Hard real-time system - A real-time system in which lateness is not accepted under any circumstance. [6]
Hardware/software integration - The process of combining the software into the target computer. [1]
High-level requirements - Software requirements developed from analysis of system requirements, safety-related
requirements, and system architecture. [1]
Host computer - The computer on which the software is developed. [1]
Immutable - Incapable of being changed. Immutable objects represent values whose state cannot be changed (e.g.,
the string literal “ABC” or the integer literal “4”). Immutable values, however, may be combined to produce new
values. The string “ABC”, for example, may be concatenated with the string “DEF” to produce a new immutable
string value “ABCDEF”. See: data type, datatype.
Implementation - A definition of how something is constructed or computed. For example, a class is an
implementation of a type, a method is an implementation of an operation. [16]
Implementation inheritance - The inheritance of the implementation of a more specific element. Includes inheritance
of the interface. Contrast: interface inheritance. Unlike interface inheritance, the inherited elements are more than
specifications. They contribute to the executable object code. [2], [16]
Implicit type conversion - A type conversion generated by the compiler as the result of an association between
variables of different types, resulting in a value being converted to an expected type based on context.
Independence - Separation of responsibilities which ensures the accomplishment of objective evaluation. (1) For
software verification process activities, independence is achieved when the verification activity is performed by a
person(s) other than the developer of the item being verified, and a tool(s) may be used to achieve an equivalence to
the human verification activity. (2) For the software quality assurance process, independence also includes the
authority to ensure corrective action. [1]
Inheritance - A mechanism by which more specific elements incorporate (inherit) the structure and behavior of more
general elements. Inheritance can be used to support generalization, or misused to support only code sharing,
without attempting to follow behavioral subtyping rules. See: generalization, Liskov substitution principle. [16]
Inheritance hierarchy - See: class hierarchy.
Inherited element - An element of a class inherited by its subclasses. In UML, inherited elements include operations,
methods, associations, and constraints involving classes.
Inline - A command used in Java, Ada, and C++ to hint to the compiler that expansion of a method body within the
code of a calling method is to be preferred to the usual call implementation. For all of these languages, the compiler
can follow or ignore the recommendation to inline. [2]
Instance - An entity to which a set of operations can be applied and which has a state that stores the effects of the
operations. See: object. [2]
Integral process - A process which assists the software development processes and other integral processes and,
therefore, remains active throughout the software life cycle. The integral processes are the software verification
process, the software quality assurance process, the software configuration management process, and the
certification liaison process. [1]
Integrator - The manufacturer responsible for integrating a software component (e.g., a reusable software
component) into the target computer and system with other software components. [3]
Interface – For object-oriented technology, an interface is a definition of the features accessible to clients of a class.
Interfaces are distinct from classes, which may also contain methods, associations and modifiable attributes.
Note: The UML definition of interface differs slightly from that defined by Java in that Java interfaces may
contain constant fields, while UML interfaces may contain only operations. [2]
Interface description data - Data that identifies the interface details of the reusable software component. It is
provided by the reusable software component developer to the integrator and applicant. \ The interface description
1-17
Volume 1
data should explicitly define what activities are required by the integrator and/or applicant to ensure that the reusable
software component will function in accordance with its approval basis. [3]
Interface inheritance - The inheritance of the interface of a more specific element. Does not include inheritance of
the implementation. Contrast: implementation inheritance. Unlike implementation inheritance, the inherited
elements are only specifications. They are not contained in the executable object code. [2], [16]
Interrupt - A suspension of a task, such as the execution of a computer program, caused by an event external to that
task, and performed in such a way that the task can be resumed. [1]
Invariant - A condition associated with a class that is established when a new instance of the class is created and
must be maintained by all its publicly accessible operations. As a result, the invariant is effectively a part of the pre-
condition and the post-condition of every such operation. It may be violated in the intermediate states that represent
the execution of a given method so long as the operations of the object are properly synchronized and such
violations are not externally observable. [2]
Liskov substitution principle (LSP) - A set of subtyping rules that ensure that instances of a subclass are
substitutable for instances of all parent classes in every context in which they may appear. These rules go beyond the
simple checking of signatures, taking into account the behavior of operations (as defined by their pre and post
conditions) and the invariants defined by classes. Even if classes are not defined formally, the principle can be
upheld by requiring the inheritance of test cases. [2] See: inheritance.
Logically unrelated types - Types are logically unrelated when one does not define a set of operations that is a subset
of the other.
Low-level requirements - Software requirements derived from high-level requirements, derived requirements, and
design constraints from which source code can be directly implemented without further information. [1]
Macro-expansion - Full expansion of the code generated by the compiler for each instantiation of a template.
Maintenance code - Code residing in a airborne computer-based system that interfaces with an onboard maintenance
computer or computer used by maintenance personnel. The function of this code is usually to report to the
maintenance computer any problems detected during normal operations. [3]
Means of compliance - The intended method(s) to be used by the applicant to satisfy the requirements stated in the
certification basis for an aircraft or engine. Examples include statements, drawings, analyses, calculations, testing,
simulation, inspection, and environmental qualification. Advisory material issued by the certification authority is
used if appropriate. [1]
Media - Devices or material which act as a means of transferal or storage of software, for example, programmable
read-only memory, magnetic tapes or discs, and paper. [1]
Member Function - A method in C++. [17]
Memory device - An article of hardware capable of storing machine-readable computer programs and associated
data. It may be an integrated circuit chip, a circuit card containing integrated circuit chips, a core memory, a disk, or
a magnetic tape. [1]
Memory usage analysis - See: other memory usage analysis and stack usage analysis.
Message - In object-oriented programming, the invocation of an operation is referred to as a message, i.e., a
message that identifies the operation being called and provides argument values for associated parameters.
Method - The implementation of an operation. A method specifies the algorithm or procedure associated with an
operation. A method corresponds to a subprogram with a body in Ada 95, to a member function with a body in C++,
and to a concrete method in Java. See: operation. [2], [16] Contrast: multimethod.
Modified Condition/Decision Coverage - Every point of entry and exit in the program has been invoked at least
once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in
the program has taken all possible outcomes at least once, and each condition in a decision has been shown to
1-18
Volume 1
independently affect that decision's outcome. A condition is shown to independently affect a decision's outcome by
varying just that condition while holding fixed all other possible conditions. [1]
Monitoring - (1) [Safety] Functionality within a system which is designed to detect anomalous behavior of that
system. (2) [Quality Assurance] The act of witnessing or inspecting selected instances of test, inspection, or other
activity, or records of those activities, to assure that the activity is under control and that the reported results are
representative of the expected results. Monitoring is usually associated with activities done over an extended period
of time where 100% witnessing is considered impractical or unnecessary. Monitoring permits authentication that the
claimed activity was performed as planned. [1]
Multimethod - A method invoked using multiple dispatch. Multimethods differ from ordinary methods in that the
run-time classes of all parameters (rather than only the target object) are considered when selecting the method to be
executed at the point of call. See: method.
Multiple dispatch - Dynamic dispatch based on the run-time types of all the arguments to a call, rather than only the
run-time type of the target object. Contrast: single dispatch. [2]
Multiple inheritance - A semantic variation of generalization in which a type (a class) may have more than one
supertype (superclass). Contrast: single inheritance. [16]
Multiple-version dissimilar software - A set of two or more programs developed separately to satisfy the same
functional requirements. Errors specific to one of the versions are detected by comparison of the multiple outputs.
[1]
Non-virtual - A C++ keyword that specifies that a given member function may be overridden in subclasses and calls
to it are resolved at compile time (static binding).
Object - An entity with a well-defined boundary and identity that encapsulates state and behavior. State is
represented by attributes and relationships; behavior is represented by operations, methods, and state machines. An
object is an instance of a class. See: class, instance. [16]
Object Code - A low-level representation of the computer program not usually in a form directly usable by the target
computer but in a form which includes relocation information in addition to the processor instruction information.
[1]
Object Management Group (OMG) - A standards body for the object-oriented development community. The
membership includes all major object-oriented tool vendors, many companies offering OO training and consulting
services, many companies offering COTS software, and many end users of OO technology, including several of the
members of AVSI. The OMG defines interface standards for distributed object communication (e.g., CORBA) and
for OO modeling tools (e.g., UML). [2]
Object-oriented (OO) - (1) the use of classes to support encapsulation, (2) the use of inheritance of interfaces to
support subtyping, (3) the use of inheritance of implementation (state and code) to support subclassing, and (4) the
use of dynamic dispatch (virtual method invocation) to support polymorphism and the inheritance of code. [2]
Operation - A service that can be requested of an object. An operation has a signature, which may restrict the actual
parameters that are possible. An operation corresponds to a subprogram declaration in Ada 95, to a function member
declaration in C++, and to an abstract method declaration in Java. It does not define an associated implementation.
See method. [2], [16]
Other memory usage analysis - Analysis related to the sharing of resources between different software ‘partitions’.
These forms of analysis include, but are not limited to, memory (heap), input/output (I/O) ports, and special purpose
hardware, which perform specific computations or watchdog timer functions. [5]
Overloading - Use of the same name for different operators or behavioral features (operations or methods) visible
within the same scope.
Overriding - The redefinition of an operation or method in a subclass. [2]
1-19
Volume 1
Parameter - The specification of a variable that can be changed, passed, or returned. A parameter may include a
name, type, and direction. Parameters are used for operations, messages, and events. [16] See: argument.
Parent - In an inheritance relationship, the generalization of another element, producing the child. See: superclass,
supertype. Contrast: child, subclass, subtype. Child classes inherit from their parent classes. Similarly, subclasses
inherit from their superclasses. [2], [16]
Part number - A set of numbers, letters or other characters used to identify a configuration item. [1]
Partitioning - See: software partitioning.
Patch - A modification to an object program, in which one or more of the planned steps of re-compiling, re-
assembling or re-linking is bypassed. This does not include identifiers embedded in the software product, for
example, part numbers and checksums. [1]
Pattern - A documented solution to a commonly encountered analysis or design problem. Each pattern documents a
single solution to the problem in a given context. [2] See: process pattern.
Polymorphism - A concept in type theory, according to which a name (such as a variable) may denote objects of
many different classes that are related by some common superclass; thus, any object denoted by this name is able to
respond to some common set of operations in different ways. [8]
Post-condition - A constraint that must be true at the completion of an operation. [16]
Pre-condition - A constraint that must be true when an operation is invoked. [16]
Process - A collection of activities performed in the software life cycle to produce a definable output or product. [1]
Process pattern - A documented solution to a problem with the software development process. A process pattern
presents the problem, followed by a description of its solution in a given context. [2] See: pattern.
Product service history - A contiguous period of time during which the software is operated within a known
environment, and during which successive failures are recorded. [1]
Proof of correctness - A logically sound argument that a program satisfies its requirements. [1]
Range checking - The verification that data values lie within specified ranges and maintain a specified accuracy.
Range checking includes, but is not limited to, overflow and underflow analysis, the detection of rounding errors,
range checking, and the checking of array bounds. [5]
Real-time system - A system that responds in a (timely) predictable way to unpredictable external stimuli arrivals. A
real-time system has to fulfill under extreme load conditions including:
• timeliness: meet deadlines, it is required that the application has to finish certain tasks within the time
boundaries it has to respect;
• simultaneity or simultaneous processing: more than one event may happen simultaneously, all deadlines
should be met;
• predictability: the real-time system has to react to all possible events in a predictable way; and
• dependability or trustworthiness: it is necessary that the real-time system environment can rely on it. [6]
Relationship - A semantic connection among model elements. Examples of relationships include associations and
generalizations. [16]
Release - The act of formally making available and authorizing the use of a retrievable configuration item. [1]
Repeated inheritance - The inheritance of an element via more than one path through the inheritance hierarchy.
Requirements-based testing - (1) Testing performed using test cases and procedures developed to confirm that the
software performs its intended function as specified by its requirements. Requirements-based testing includes both
normal range test cases, and robustness (abnormal range) test cases. The test cases are to be developed from the
software requirements and the errors sources inherent in the software development process. [1] (2) Testing
1-20
Volume 1
performed with the objective of showing that the actual behavior of the program is in accordance with its
requirements. Two common methods are cited for conducting requirements-based testing: equivalence class testing,
and boundary value testing. [5] The use of the term in this Handbook is intended to encompass both definitions.
Requirements, Design, and Code Standards (R-D-C Standards) - Guidelines used to control, develop, and review
software requirements, design, and code. [1]
Reusable software component (RSC) - The software, its supporting RTCA/DO-178B software life cycle data, and
additional supporting documentation being considered for reuse. The component designated for reuse may be any
collection of software, such as, libraries, operating systems, or specific system software functions. [3]
Reverse engineering - The method of extracting software design information from the source code. [1]
Robustness - The extent to which software can continue to operate correctly despite invalid inputs. [1]
Run-time type/class - The type/class associated with an object at run-time (e.g., when the object is first created). In
Ada 95, this is the tag associated with objects of a tagged type. [2]
Scalar types - A type that defines a variable containing a single value at run-time. A scalar type is either a discrete
type or a real type. The values of a scalar type are ordered.
Signature - The name and parameter types of an operation or method. A signature may include an optional returned
parameter type (depending upon the target language). [16]
Simple dispatch - A restricted form of single dispatch, in which (a) all calls other than method extensions are
dispatching, and (b) dispatch is semantically equivalent to invocation of a dispatch routine containing a case
statement. [2]
Simulator - A device, computer program, or system used during software verification, that accepts the same inputs
and produces the same output as a given system, using object code which is derived from the original object code.
[1]
Single dispatch - Dynamic dispatch based on only the run-time type of the target object. Most OO languages,
including Java, Ada 95 and C++ are single dispatching. Contrast: multiple dispatch. [16]
Single inheritance - A semantic variation of generalization in which a type (a class) may have only one supertype
(superclass). Contrast: multiple inheritance. [16]
Software - Computer programs and, possibly, associated documentation and data pertaining to the operation of a
computer system. [1]
Software architecture - The structure of the software selected to implement the software requirements. [1]
Software change - A modification in source code, object code, executable object code, or its related documentation
from its baseline. [1]
Software integration - The process of combining code components. [1]
Software level - One of the software levels defined by DO-178B, section 2.2.2. Software level is based upon the
contribution of software to potential failure conditions as determined by the safety assessment process. [1]
Software library - A controlled repository containing a collection of software and related data and documents
designed to aid in software development, use or modification. Examples include software development library,
master library, production library, program library and software repository. [1]
Software life cycle - (1) An ordered collection of processes determined by an organization to be sufficient and
adequate to produce a software product. (2) The period of time that begins with the decision to produce or modify a
software product and ends when the product is retired from service. [1]
Software partitioning - The process of separating, usually with the express purpose of isolating one or more
attributes of the software, to prevent specific interactions and cross-coupling interference. [1]
1-21
Volume 1
Software product - The set of computer programs, and associated documentation and data, designated for delivery to
a user. In the context of DO-178B, this term refers to software intended for use in airborne applications and the
associated software life cycle data. [1]
Software requirement - A description of what is to be produced by the software given the inputs and constraints.
Software requirements include both high-level requirements and low-level requirements. [1]
Software tool - A computer program used to help develop, test, analyze, produce or modify another program or its
documentation. Examples are an automated design tool, a compiler, test tools and modification tools. [1]
Source code - Code written in source languages, such as assembly language and/or high level language, in a
machine-readable form for input to an assembler or a compiler. [1]
Stack usage analysis - A form of shared resource analysis that establishes the maximum possible size of the stack
required by the system and whether there is sufficient physical memory to support this stack size. Some compilers
use multiple stacks, and this form of analysis is required for each stack. Potential stack-heap allocation collisions,
when these forms of storage compete for the same space, are also included. [5]
Standard - A rule or basis of comparison used to provide both guidance in and assessment of the performance of a
given activity or the content of a specified data item. [1]
State - A condition or situation during the life of an object during which it satisfies some condition, performs some
activity, or waits for some event. [16]
Statement coverage - Every statement in the program has been invoked at least once. [1]
Static analyzer - A software tool that helps reveal certain properties of a program without executing the program. [1]
Static binding - With regard to calls to operations, the ability to associate a particular method (implementation of an
operation) with a particular call to that operation at compile time.
Static classification - A semantic variation of generalization in which an object may not change [its] classifier.
Contrast: dynamic classification. Using dynamic classification, the class of an object may change during its life
time. Using static classification, it may not. [2], [16]
Strongly typed - A characteristic of a programming language, according to which all expressions are guaranteed to
be type consistent. [8]
Strongly typed language - A strongly typed language associates a type with each data element (variable or
expression), and ensures that only operations appropriate to that type are applied to the data element. Only
meaningful conversions between logically related types are permitted. A subset of a language may be considered
strongly typed, even if the full language is not.
Structural coverage - A software-program method of determining the adequacy of the extent of the verification
accomplished in the composition/decomposition of the software program.
Structural coverage analysis - An analysis that (1) determines which software structures and code structures were
not exercised by the requirements-based test procedures; and (2) provides traceability between the implementation
of the software requirements in the code structure and the verification of those requirements via test cases. [1]
Structure - A specified arrangement or interrelation of parts to form a whole. [1]
Subclass - In a generalization relationship, the specialization of another class; the superclass (parent). See:
generalization, child. Contrast: superclass, parent.
Note: “subclass” and “child” are used interchangeably in object-oriented development. [16]
Subinterface - A subclass/subtype that is an interface (defines no methods, associations, or modifiable attributes).
See: interface.
1-22
Volume 1
Substitutability - With regard to subtyping, the ability to substitute an instance of a given subtype for an instance of
one of its supertypes in any context in which the supertype instance may appear (see also Liskov substitution
principle (LSP), which defines a set of typing rules intended to guarantee substitutability).
Substitution - With regard to subtyping, the replacement of an instance of a subtype with an instance of one of its
supertypes.
Subtype - In a generalization relationship, the specialization of another type; the supertype. See: generalization.
Contrast: supertype. [2], [16]
Superclass - In a generalization relationship, the generalization of another class; the subclass. See: generalization,
parent. Contrast: subclass, child.
Note: “superclass” and “parent” are used interchangeably in object-oriented development. [16]
Superinterface - A superclass/supertype that is an interface (defines no methods, associations, or modifiable
attributes). See: interface.
Supertype - In a generalization relationship, the generalization of another type; the subtype. See: generalization.
Contrast: subtype. [16]
System - A collection of hardware and software components organized to accomplish a specific function or set of
functions. [1]
System architecture - The structure of the hardware and software selected to implement the system requirements. [1]
System safety assessment - An ongoing, systematic, comprehensive evaluation of the proposed system to show that
relevant safety-related requirements are satisfied. [1]
System safety assessment process - Those activities which demonstrate compliance with airworthiness requirements
and associated guidance material, such as, JAA AMJ/FAA AC 25.1309. The major activities within this process
include: functional hazard assessment, preliminary system safety assessment, and system safety assessment. The
rigor of the activities will depend on the criticality, complexity, novelty, and relevant service experience of the
system concerned. [1]
Target computer - The physical processor that will execute the program while airborne. [3]
Target computer environment - The target computer and all its support hardware and systems needed to function in
its actual airborne environment. [3]
Target environment - See: target computer environment. [3]
Target object - The object that is the target of a method call [most often written targetObject.methodName
(argumentList);]. Dynamic dispatch typically involves selection of a method based on the declared types of the
arguments and the run-time type of the target object. [2]
Task - The basic unit of work from the standpoint of a control program. [1]
Template - A parameterized model element with unbound (formal) parameters that must be bound to actual (type)
parameters before it can be used. At a target language level, templates correspond to Ada generics and to C++
templates. [2]
Template class - A parameterized class. Template classes are implemented as generic packages in Ada, and to
template classes in C++. Java does not currently support parameterized class definitions. [2]
Template operation - A parameterized operation or method. Template operations are referred to as generic
subprograms in Ada, and as template member functions in C++. Java does not currently support parameterized class
definitions. [2]
Test case - A set of test inputs, execution conditions, and expected results developed for a particular objective, such
as to exercise a particular program path or to verify compliance with a specific requirement. [1]
1-23
Volume 1
Testing - The process of exercising a system or system component to verify that it satisfies specified requirements
and to detect errors. [1]
Test procedure - Detailed instructions for the set-up and execution of a given set of test cases, and instructions for
the evaluation of results of executing the test cases. [1]
Timing analysis - A form of analysis to establish the temporal properties of the input/output dependencies. A
common and important aspect of this analysis is the worst-case execution time for the correct behavior of the overall
system. Certain languages offer features that make timing analysis difficult, e.g., loops without static upper bounds
and the manipulation of dynamic data structures. [5]
Tool qualification - The process necessary to obtain certification credit for a software tool within the context of a
specific airborne system. [1]
Traceability - The evidence of an association between items, such as between process outputs, between an output
and its originating process, or between a requirement and its implementation. [1]
Transition criteria - The minimum conditions, as defined by the software planning process, to be satisfied to enter a
process. [1]
Type - The concepts of type and class are in general distinguished, with a type representing an abstraction
implemented by one or more classes. In most of the classical object-oriented programming languages this
distinction is not performed. [4] In UML and languages such as Java, however, a distinction is made between
interface types (abstractions) and class types, which implement them.
Type conversion - The act of producing a representation of some value of a target type from a representation of
some value of a source type. Type conversion is used to resolve mismatched types in assignments, expressions, or
when passing parameters. Type conversions may be either implicit or explicit. With implicit type conversion the
compiler is given the responsibility for determining that a conversion is required and how to perform the conversion.
With explicit type conversion the programmer assumes the responsibility. Synonym: conversion.
Unchecked type conversion - Types are unchecked if conversion from one type to the other does not include a
determination either at compiler time or run-time as to whether they are normally convertible.
Unified Modeling Language (UML) - A language for specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business modeling. The UML represents a collection of best engineering
practices that have proven successful in the modeling of large and complex systems. [16]
Use case - The specification of a sequence of actions, including variants, that a system (or other entity) can perform,
interacting with actors of the system. [16]
Validation - The process of determining that the requirements are the correct requirements and that they are
complete. The system life cycle process may use software requirements and derived requirements in system
validation. [1]
Variables - Named memory locations that contain data that may change during software execution.
Verification - The evaluation of the results of a process to ensure correctness and consistency with respect to the
inputs and standards provided to that process. [1]
Virtual - For C++, “virtual” is a keyword that specifies a given method (member function) may be overridden in
subclasses, and that calls to it are dispatching.
Weakly typed - Strict enforcement of type rules but with well-defined exceptions or an explicit type-violation
mechanic, e.g., operations on a data element are not restricted to those defined for its logical type (Booleans can be
added to one another), or automatic conversions between logically unrelated types are permitted with no change in
data representation (integer values are converted to floating point values). Contrast: strongly typed.
Weakly typed language - A programming language or modeling language that is weakly typed. Contrast: strongly
typed language.
1-24
Volume 1
1.6 OOTiA Workshops

NASA and FAA sponsored two OOTiA workshops for the purposes of:
• Identifying safety and certification issues related to using OOT;
• Coordinating and communicating with industry, government, and academia on OOT; and
• Working together to establish positions on the key OOT issues.
The workshops were led and coordinated by a workshop committee and were attended by international
representatives from government, industry, and academia (see section 1.6.1 for a list of workshop committee
members and sections 1.6.2 and 1.6.3 for lists of workshop participants). OOTiA Workshop #1 was held in April
2002 and was followed by Workshop #2 in March 2003.
1.6.1 Workshop Committee

Participant Affiliation
J. Chilenski Boeing Commercial Airplanes
G. Daugherty Rockwell Collins, Inc.
K. Hayhurst NASA Langley Research Center
C. Kilgore FAA Technical Center (AAR-470)
J. Knickerbocker Sunrise Certification & Consulting, Inc.
J. Lewis FAA Headquarters (AIR-120)
B. Lingberg FAA Headquarters (AIR-120)
S. Obeid embeddedPlus Engineering
B. Ocker FAA Chicago Aircraft Certification Office (ACE-117C)
T. Rhoads Goodrich
L. Rierson FAA Chief Scientific and Technical Advisor (AIR-106N)
W. Schultz Honeywell
W. Struck FAA Transport Directorate (ANE-111)
D. Wallace FAA Ft. Worth Aircraft Certification Office (ASW-170)
1.6.2 Participants in Workshop #1
K. Achenbach Rolls-Royce Corporation
M. Almesåker Saab AB Sweden
J. Angermayer MITRE
J. Auld NovAtel Inc.
I. Baxter Semantic Designs
A. Bell The Boeing Company
D. Bernier Rockwell Collins
1-25
Volume 1
B. Bianchi Ametek
B. Bogdan Computer Science Corporation
M. Brennan Applied Microsystems
D. Brown Rolls-Royce plc
V. Brown Honeywell, Inc.
R. Butler NASA Langley Research Center
B. Calloni Lockheed Martin Aeronautics Company
R. Calloway NASA Langley Research Center
S. Chappell Computer Science Corporation
J. Chelini Verocel, Inc.
J. Chilenski Boeing Commercial Airplanes
M. Christie Universal Avionics Systems Corporation
J. Coleman Hamilton Sundstrand
O. Collins Raytheon - IATC
M. Consiglio ICASE
M. Cors Goodrich Avionics Systems
J. Daly TRW (Aeronautical Systems)
G. Daugherty Rockwell Collins, Inc.
R. Deal Honeywell
D. DeHoff Raytheon Technical Services Company
M. DeWalt Certification Services, Inc.
V. Dovydaitis Foliage Software Systems, Inc.
P. Dunn Northrop Grumman Commercial Nav Systems
G. Edmands The MITRE Corporation
E. Edora Solers, Inc.
C. Erwin FAA Wichita Aircraft Certification Office (ACE-115)
T. Ferrell FAA Consulting
U. Ferrell FAA Consulting
G. Finelli NASA Langley Research Center
S. Fischer LITEF GmbH, Germany
L. Framarini BAE Systems
D. Geis Goodrich Avionics Systems
G. Graessle Honeywell, Intl.
S. Grainger Marinvent Corporation
M. Gulick Solers, Inc.
T. Hammer Honeywell
M. Haynes Marinvent Corporation
R. Hirt Raytheon Aircraft Company
1-26
Volume 1
M. Holloway NASA Langley Research Center

G. Horan FAA Engine Directorate (ANE-110)
M. Isaacs FAA Mike Monroney Aeronautical Center (AOS-240)
D. Johnson Astronautics Corporation of America
R. Johnson Bell Helicopter
M. Jones NovAtel Inc.
G. Kelly Honeywell
C. Kilgore FAA Technical Center (AAR-421)
J. Klein Lockheed Martin Air Traffic Management
J. Knickerbocker Sunrise Certification & Consulting, Inc.
J. Knight University of Virginia
T. Lambregts FAA Chief Scientific and Technical Advisor (ANM-113N)
P. Lawrence Boeing
J. Lee Boeing
Y. Lee Arizona State University
S. Leichtnam Computer Science Corporation
J. Lewis FAA Headquarters (AIR-120)
B. Lingberg FAA Headquarters (AIR-120)
J. Masalskis Boeing
J. Mason Boeing
G. Millican Honeywell
J. Monagan Rockwell Collins
J. Monfret BarcoView
B. Moody USAF
B. Newman Astronautics Corporation of America
S. Obeid embeddedPlus Engineering
B. Ocker FAA Chicago Aircraft Certification Office (ACE-117C)
A. Oswald MITRE/CAASD
C. Paganoni SAIC
M. Patel WPAFB
G. Pavlin Brightline Avionics GmbH
L. Peckham NASA Langley Research Center
T. Petroski Boeing
M. J. Peuser Honeywell
C. Pohlman Lockheed Martin Aeronautics Company
G. Putsche Boeing
H. Quach Lockheed Martin Corporation
R. Rader Lockheed Martin
R. Randall Boeing Wichita Modification & Maintenance Center
1-27
Volume 1
T. Reeve Patmos Engineering Services

T. Rhoads Goodrich FUS
W. Rieger Boeing
L. Rierson FAA Chief Scientific and Technical Advisor (AIR-106N)
K. Rigby BAE Systems
B. Rivet Hamilton Sundstrand
D. Robinson FAA Headquarters (AIR-130)
C. Rosay JAA-CEAT
T. Roth Honeywell International Inc.
V. Santhanam Boeing Wichita Development & Modification Center
T. Schavey Smiths Aerospace
S. M. Schedra Wind River Systems, Inc.
W. Schultz Honeywell International
M.l Smith Ametek
F. Sogandares MITRE/CAASD
M. Sonnek Honeywell
R. Souter FAA Wichita Aircraft Certification Office (ACE-116W)
C. Spitzer AvioniCon
E. Startzman Boeing Wichita Development & Modification Center
D. Stephens Boeing
W. Struck FAA Transport Directorate (ANM-111)
D. Sungenis Computer Science Corporation
A. Theodore UNITECH
H. Thomas Honeywell, Inc.
M. Valentin Airbus France
J. Van Leeuwen United Technologies - Sikorsky Aircraft
D. Wallace FAA Ft. Worth Aircraft Certification Office (ASW-170)
D. Woodward BAE Systems
P. Wright Boeing
1.6.3 Participants in Workshop #2
G. Adams Lockheed Martin Aero
J. Angermayer The MITRE Corp.
J. Auld NovAtel
F. Barber Avidyne Corporation
B. Bianchi Ametek
1-28
Volume 1
T. Bihari AMT Systems Engineering, Inc.

R. Bogdan Computer Sciences Corporation
F. Bortkiewicz The Boeing Company
M. Brennan Metrowerks Corporation
E. Brockway Lockheed Martin
B. Brosgol Ada Core Technologies, Inc.
D. Brown Rolls-Royce plc
J. Burck Smiths Aerospace - Electronic Systems
B. Cain METI
J. Carlton Escher Technologies
K. Carroll Lockheed Martin Aero
P. Catlin Goodrich Avionics Systems, Inc.
R. Chapman Praxis Critical Systems Limited
R. Charley The Boeing Company
J. Chelini Verocel, Inc.
J. Chilenski The Boeing Company
E. Chiuchiolo FAA
K. Clegg University of York
D. Coleman MDHI
J. Coleman Hamilton Sundstrand
M. Consiglio NASA Langley Research Center
M. Cors Goodrich Avionics Systems
D. Crocker Escher Technologies
E. Danielson Rockwell Collins
G. Daugherty Rockwell Collins
T. Deaver Northrop Grumman
L. Demeestere BarcoView
M. DeWalt Certification Services, Inc.
B. Dulic Transport Canada
G. Edmands The MITRE Corporation
C. Erwin FAA
D. Fisher Ada Core Technologies, Inc.
G. Frye FAA/AIR-130
R. Fulton Honeywell
E. Galiana CMC Electronics
D. Geis Goodrich Avionics Systems
C. Gibson Honeywell
F. Guay FWGC
M. Gulick Solers, Inc.
1-29
Volume 1
D. Hatfield FAA
R. Hawkins University of York
M. Hawthornthwaite Engenuity Technologies
M. Haynes Marinvent Corporation
B. Hendrix Lockheed Martin Aeronautics Company
R. Hirt FAA
T. Hofmann Diehl Avionik Systeme GmbH
M. Holloway NASA Langley Research Center
S. Hutchesson Rolls-Royce plc
M. Jones NovAtel
R. Key FAA
J. Kilchert Diehl Avionik Systeme GmbH
J. Knickerbocker Sunrise Certification and Consulting
J. Knight University of Virginia
P. La Pietra Honeywell
T. Lambregts FAA
J. D. Lawrence DRPM AAA
J. Lewis FAA
B. Lingberg FAA
J. Liscouski BAE Systems
P. Maneely Honeywell
E. Mannisto Honeywell
S. Matthews Avidyne Corporation
D. Mayerhoefer Green Hills Software
M. Mehlich Semantic Designs, Inc.
B. Mierow Hamilton Sundstrand
G. Millican Honeywell
S. Morton Applied Dynamics International
S. Obeid Embedded Plus Engineering
J. Offutt George Mason University
R. Oracheff Paragon Transportation LLC
L. Peckham NASA Langley Research Center
M. Peuser Honeywell
S. Ray BAE Systems Controls
T. Reeve Patmos Engineering. Services
B. Reynolds Rockwell Collins
T. Rhoads Goodrich
W. Richter Gulfstream
1-30
Volume 1
L. Rierson FAA
B. Rivet Hamilton Sundstrand - UTC
D. Robinson FAA
C. Rosay JAA/CEAT
T. Roth Honeywell
W. Ryan FAA
L. Schad-Alford The Boeing Company
K. Schlatter Jeppesen
E. Schonberg Ada Core Technologies, Inc.
V. Shapiro AMTI
T. Smith Air Traffic Software Architecture
C. Spitzer AvioniCon
R. Stanley Air Traffic Software Architecture
E. Startzman The Boeing Company
J. Steidl Astronautics Corporation of America
E. Strunk University of Virginia
T. Swinehart Goodrich Avionics Systems, Inc.
B. Thedford Hanscom AFB
A. Theodore Unitech
L. Thompson Honeywell
M. Valentin AIRBUS France
J. Van Leeuwen Sikorsky Aircraft
D. Wallace FAA
P. Whiston High Integrity Solutions Ltd
M. Whitehurst The Boeing Company
A. Wils K.U. Leuven
M. Wittman Honeywell
D. Woodward BAE Systems
P. Wright The Boeing Company
1-31
Volume 1
1.7 References
1. RTCA, Inc., Software Considerations in Airborne Systems and Equipment Certification, RTCA/DO-178B,
December 1992, Washington, D.C.
2. Aerospace Vehicle Systems Institute. Guide to the Certification of Systems with Embedded Object-Oriented
Software, version 1.5.
3. FAA AC 20-148, Reusable Software Components, final (unsigned) version dated August 3, 2004.
4. Laplante, Phillip A (editor). Dictionary of Computer Science, CRC Press LLC, 2001.
5. Guidance for the Use of Ada in High Integrity Systems, ISO/IEC TR 15942:2000 see
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm.
6. Dedicated Systems Encyclopedia, available from

http://www.dedicated-systems.com/encyc/techno/terms/defini/def.htm.
7. Object-Oriented Technology in Aviation Program website: http://shemesh.larc.nasa.gov/foot/.
8. Booch, Grady. Object-Oriented Analysis and Design. Addison-Wesley, 2nd edition, 1994.
9. “Glossary of Software Engineering Terminology.” ANSI/IEEE Standard, 1983.
10. Gomaa, Hassan. Software Design Methods for Concurrent and Real-time Systems. Addison-Wesley, 1993.
11. Hathaway, Bob. “Frequently Asked Questions on Object-Oriented.” Web site:

http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/oop/faq-doc-0.html.
12. Meyer, Bertrand. Object-Oriented Software Construction. Prentice Hall, 2nd edition, 1997.
13. Montlick, Terry. “What is Object-Oriented Software?” Web site: http://www.softwaredesign.com/.
14. Pressman, Roger. Software Engineering: A Practitioner’s Approach. McGraw Hill, 4th edition, 1997.
15. Schildt, Herbert. Teach Yourself C++. McGraw Hill, 1998.
16. Object Management Group. OMG Unified Modeling Language Specification, version 1.3, June 1999, available
from http://www.omg.org/technology/documents/vault.htm#modeling.
17. Liskov, Barbara and Jeanette Wing. “A Behavioral Notion of Subtyping,” ACM Transactions on Programming
Languages and Systems, 16(6): 1811-1841, November 1994.
18. FOLDOC: Free Online Dictionary of Computing, http://foldoc.doc.ic.ac.uk.
1-32
Volume 1
1.8 Feedback Form
U.S. Department
of Transportation
Federal Aviation
Administration
Feedback Information
Please submit any written comments or recommendations for improving this Handbook. You may also
suggest new items or subjects to be added. And, if you find an error, please tell us about it. Send to:
FAA, AIR-120, Room 815, 800 Independence Ave., S.W., Washington, DC 20591.
Subject: Handbook for Object-Oriented Technology in Aviation (OOTiA)
To: OOTiA Handbook POC, FAA/AIR-120, Software Program Manager

(Please check all appropriate line items)
An error has been noted in Volume __, section ______, paragraph _______, on page _______ .
Recommend Volume __, section ______, paragraph _______ on page _______ be changed as follows:
(attach separate sheet if necessary)
In a future change to this Handbook, please include coverage on the following subject:
(briefly describe what you want added):
Other comments:
I would like to discuss the above. Please contact me.
Submitted by: ________________________________________ Date: _________________

Phone: ____________________ Address: ________________________________________
Email: ____________________ Routing Symbol (if applicable): ______________________
1-33
DRAFT

Volume 2: Considerations and Issues

Revision 0
October 26, 2004

but, rather,
context.
Volume 2
2-ii
Volume 2
Contents
2.1 INTRODUCTION ........................................................................................................................................ 2-1
2.1.1 Background........................................................................................................................................ 2-2
2.1.2 Purpose and Organization of Volume 2............................................................................................. 2-2
2.2 CONSIDERATIONS BEFORE MAKING THE DECISION TO USE OOT ........................................................... 2-3
2.2.1 Reality of the Benefits ........................................................................................................................ 2-4
2.2.2 Project Characteristics ...................................................................................................................... 2-4
2.2.3 OOT Specific Resources .................................................................................................................... 2-5
2.2.4 Regulatory Guidance ......................................................................................................................... 2-5
2.2.5 Technical Challenges......................................................................................................................... 2-6
2.3 CONSIDERATIONS AFTER MAKING THE DECISION TO USE OOT ............................................................. 2-8
2.3.1 Considerations for the Planning Process .......................................................................................... 2-8
2.3.2 Considerations for Development Processes -- Requirements, Design, Code, and Integration........ 2-10
2.3.3 Considerations for Integral Processes............................................................................................. 2-14
2.3.4 Additional Considerations ............................................................................................................... 2-19
2.4 OPEN ISSUES (SUMMARY OF WORKSHOP #2 BRAINSTORMING SESSION) .............................................. 2-21
2.5 SUMMARY ............................................................................................................................................. 2-22
2.5.1 Summary of Decision-Making Process for Using OOT ................................................................... 2-22
2.5.2 Summary of Key Areas of Concern for OOT When Meeting DO-178B........................................... 2-22
2.6 REFERENCES ......................................................................................................................................... 2-24
APPENDIX A RESULTS OF THE BEYOND THE HANDBOOK SESSION............................................. 2-27
APPENDIX B MAPPING OF ISSUE LIST TO CONSIDERATIONS......................................................... 2-29
APPENDIX C ADDITIONAL CONSIDERATIONS FOR PROJECT PLANNING.................................... 2-42

C.1 CONCEPTUAL PITFALLS ......................................................................................................................... 2-42
C.2 ANALYSIS AND DESIGN PITFALLS ......................................................................................................... 2-42
C.3 CLASS AND OBJECT PITFALLS ............................................................................................................... 2-42
C.4 VERIFICATION PITFALLS ....................................................................................................................... 2-43
C.5 REUSE PITFALLS .................................................................................................................................... 2-43
Figures
Figure 2.2-1 Original Classification Scheme for the “Beyond the Handbook” Questions ....................................... 2-3
rather, as input when considering issues in a project-specific context. 2-iii
Volume 2
2.1 Introduction
The introduction of object-oriented techniques and tools to aviation software development presents challenges to
understanding their effect on safety and certification. As discussed in Volume 1, there is an increasing desire among
aviation software developers to use object-oriented technology (OOT), including object-oriented modeling, analysis,
design, programming, and verification/test in the development of aviation applications. These desires are fueled, at
least in part, by claims of increased efficiency in the development of complex systems through using reusable
components. Object-oriented (OO) design, with the ability to encapsulate design decisions, is considered by some to
be “the most important low-level design technology in modern software engineering” [18].
In response to the aviation industry’s desire to use OOT, the Federal Aviation Administration (FAA) enlisted the
National Aeronautics and Space Administration’s (NASA) support for the Object-Oriented Technology in Aviation
(OOTiA) project. This project sponsored research and conducting workshops designed to identify concerns about
OOT relevant to safety and certification and to develop recommendations for demonstrating compliance to DO-
178B and ensuring safe use in airborne systems.
The OOTiA project was initially based on work by the Aerospace Vehicle Systems Institute (AVSI). AVSI is an
aerospace research consortium whose goals are to reduce the costs and maintain the safety of complex subsystems in
aircraft. As part of this consortium, Boeing, Honeywell, Goodrich, and Rockwell Collins collaborated on an AVSI
project titled Certification Issues for Embedded Object-Oriented Software, the goal of which was to mitigate the risk
that individual projects face when certifying airborne systems with OO software. The AVSI project proposed a
number of guidelines for producing object-oriented software that complies with DO-178B [2].
In 2001, a committee including representatives from the AVSI project, FAA, and NASA Langley Research Center,
was formed to extend the AVSI work for the benefit of the entire aviation software community. This committee
developed the following approach for accomplishing this purpose:
• Establish a web site dedicated to collecting data on OO safety and certification concerns
• Hold public workshops to which the aviation software community would be invited to discuss concerns
• Document each key OO concern raised either through the web site or the workshops
• Adapt the AVSI guidelines to address the OO concerns
• Produce a handbook to document the results
The OOTiA Handbook is comprised of four volumes. This volume focuses expressly on the concerns and questions
about OOT that have been collected through the OOTiA web site and workshops, with the goal of raising awareness
of aspects of OOT that may complicate compliance with DO-178B. Consequently, the tone of this volume may seem
overly negative to some readers, just as the tone of other volumes may seem overly positive to others. Readers of
this volume should carefully note the following:
• Comments recorded through the OOTiA activities are cited throughout the volume. The purpose of citing
recorded comments is not to imply their individual validity, but to account for the data that has been
collected and show the basis for a concise set of key concerns relevant to DO-178B compliance that are
derived from the data as a whole.
• The key concerns documented in this report do not constitute a complete set of safety and certification
concerns.
• Nearly all of the submitted issues used a particular nomenclature for OO concepts and constructs (class,
subclass, superclass, method). For simplicity, the same nomenclature is used in this volume. This usage
does not imply a preference for languages or tools that use these terms over those that do not.
• This volume does not discuss approaches for how to resolve the concerns. Other volumes of the Handbook
(Volume 3, in particular) provide some guidelines for OOT software developers.
It should also be noted that this volume assumes that the reader has a fundamental understanding of OOT concepts
and languages. Further information and references on these can be found in Volume 1. Additionally, it should be
noted that this volume uses the Acronym list and Glossary provided in Volume 1.
Volume 2
2.1.1 Background
On September 14, 2001, the OOTiA web site http://shemesh.larc.nasa.gov/foot/ was launched by NASA Langley
Research Center, and the aviation software community was invited by e-mail to participate in a dialogue about OOT.
The email distribution list comprised over 900 individuals who had expressed an interest in or attended software
related functions sponsored by the FAA. Individuals were invited to participate by submitting comments or concerns
about OOT to an issue list (IL) kept on the OOTiA web site, by attending public workshops organized by the
OOTiA committee, and by reviewing products from the effort.
To date, 103 separate concerns 1 about various aspects of OOT have been collected through the web site. The web
site initially requested that each submission include a topic, a statement of the concern, and a proposed solution (if
known). Neither individual nor company names were recorded with the submittals. No specific guidance was given
regarding what could or could not be submitted. Later updates of the web site simply requested that concerns be
emailed to a point of contact at NASA Langley. The web site continues to accept new submissions.
Each submission to the web site is added to a list titled “Issues and Comments about Object-Oriented Technology in
Aviation.” This issue list is posted on the web site and updated as new issues are submitted. Every entry that is
submitted is added to the list exactly as it is submitted; entries to the list are not edited. As of the date of publication
of this report, the web site is operational. Decisions about how to respond to future submissions or when to close the
web site have not been made.
Considerable overlap and similarities are evident when reviewing the entries in the issue list. The OOTiA committee
originally determined that most of the issues on the issue list related to the following eight topics: single inheritance,
multiple inheritance, reuse and dead/deactivated code, tools, templates, overloading, type conversion, and inlining.
The OOTiA committee drafted papers for each of these topics, drawing heavily from the original AVSI documents.
In April 2002, a public workshop was held to introduce the OOTiA project, to discuss the draft papers, and to
provide an opportunity for people to raise additional concerns about OOT. Workshop attendance included 13 FAA
representatives and more than 100 aviation industry representatives supporting both airborne and ground-based
applications. Volume 1, section 1.6.2, lists workshop attendees. After this workshop, the individual draft papers
were revised and collated into a single document: “Handbook for Object-Oriented Technology in Aviation.” Also, a
ninth topic, traceability, was added, and a paper on the topic was included in the draft Handbook.
The draft Handbook served as the basis for discussion at a second public workshop, held in March 2003. Attendance
at this workshop was similar in number and composition to the first workshop (see Volume 1, section 1.6.3 for list
of attendees at the second workshop). Results of both workshops are available on the OOTiA web site. Most of the
workshop was devoted to individual sessions on specific chapters of the Handbook. The purpose of those sessions
was to review and modify the draft chapters, and to document new issues, if raised. Two other sessions at the
workshop were not directly tied to the Handbook: “Beyond the Handbook” and “Open Issues.” The “Beyond the
Handbook” session provided participants with an opportunity to discuss questions that should be answered before
making a decision to use OOT on a project. The “Open Issues” session provided participants the opportunity to
discuss any concerns they thought had not been adequately covered in the draft Handbook. As a result of the second
workshop, it was determined that structural coverage should be addressed as a separate topic and that the Handbook
should be sub-divided into multiple volumes to target the specific audiences.
2.1.2 Purpose and Organization of Volume 2

“Change in general rarely comes without cost, and change in one area often raises new challenges in other areas”
[16]. The purpose of this document is to report and discuss the challenges collected throughout the OOTiA project.
The discussion is organized as follows. In Section 2.2, results of the “Beyond the Handbook” session are presented
1
There are actually 107 entries to the list, but 4 of them are duplicates.
2-2
Volume 2
as issues to be considered before the decision to use OOT has been made. Section 2.3 presents issues documented
about OOT that should be considered after the decision to use OOT has been made. This discussion focuses on the
entries to the issue list, and identifies key concerns with respect to the life cycle processes specified in DO-178B.
Section 2.4 reports those items that have been proposed as open issues (i.e., issues not currently addressed by this
Handbook). Finally, Section 2.5 summarizes the challenges and discusses their relationship to other volumes of the
Handbook, and Section 2.6 provides references specific to this volume. This volume also contains three appendices.
2.2 Considerations Before Making the Decision to Use OOT

Much of the focus of the OOTiA project has been on how to use OOT, assuming that the decision to use OOT on a
program has already been made. At OOTiA Workshop #2, participants in the “Beyond the Handbook” session were
asked to brainstorm questions that should be answered before a program commits to using OOT. During the session,
participants produced a list of fifty-one questions related to making a decision about whether to use OOT. At the end
of the brainstorming session, these questions were reviewed, grouped according to the scheme shown in Figure
2.2-1, and presented to the plenary session at Workshop #2.
1 Making the Choice for OOT

How to determine whether OOT is the correct approach for producing a solution with the
appropriate level of integrity for the problem
1.1 OOT Metrics
Where is the body of knowledge that shows that OOT allows us to build systems with all
of the benefits that have been claimed for it; e.g., is OOT better, cheaper, faster, safer,
more reusable, more maintainable, more reliable, etc?
1.2 Technical Challenges

How to determine the technical risk involved in applying OOT to ensure the
appropriate level of integrity? Methods for determining and mitigating risk include
research in the academic and corporate communities, corporate experience, and expert
knowledge.
1.3 Available Resources

What resources, specific to adopting OOT, are needed to ensure the appropriate level of
integrity? Examples of resources include skills, training, processes, corporate
experience, tools, standards, computing capacity, time, and money. On the subject of
certification, there are two needed components: guidance and skills.
2 DO-178B Issue
Are all the objectives (Annex A) in DO-178B compatible with OOT? Is there anything specific
to OOT that is not addressed in DO-178B?
3 Handbook Issues
How should the handbook be applied to a practical project? For example, is it a certification
aid or best practice? Is it adequate – that is, what needs to be extended, added, and changed?
Figure 2.2-1 Original Classification Scheme for the “Beyond the Handbook” Questions
Appendix A contains the original questions recorded during the brainstorming session. Since that time, the questions
from the session have been re-examined and placed in one of the following five categories:
1. Reality of the Benefits
2. Project Characteristics
2-3
Volume 2
3. OOT Specific Resources

4. Regulatory Guidance
5. Technical Challenges
The rest of this section briefly discusses each of these five categories and the key questions and associated issues
within each.
2.2.1 Reality of the Benefits

The first question to be addressed is:
(1) What are the benefits of OOT compared with current or alternative approaches? And, what evidence exists to
support claimed benefits of better, cheaper, faster, safer, more reliable, more maintainable, etc.?
In a recent article on object-orientation [12], Robert Glass stated that “[t]he software field has been subjected, over
the years, to excessive claims of benefits for almost every new technology.” OOT is no exception. OOT has become
a popular software development approach within many non-safety-critical industries, due in part to claims related to
reuse and associated benefits of efficient development. Within a group of aviation software engineers, it is not
surprising that questions were raised about evidence to support or deny such claims. Participants in this session were
particularly concerned about finding evidence to support extrapolating advantages claimed for OOT in non-safety-
critical systems to safety-critical systems. Because OOT has been around for a relatively long time, one would think
there would be an abundance of evidence to promote thorough understanding of OOT benefits. There is an
abundance of information, but how much of it qualifies as credible evidence relevant to the aviation software
industry is debatable.
Studies exist that support the claimed benefits, such as Basili’s results showing reduced defect density and rework
with OOT [4], while other studies show potential problems such as inferior understandability, complexity, and
maintenance problems [33, 30, 24]. Most studies, these included, are open to criticism, both about internal validity
(did the experimental treatments really make a difference?) and external validity (to what populations and settings
may the results be generalized?). Understanding whether the results of empirical studies or the anecdotes from
previous projects are relevant to a new project is not easy. On the whole, “there is no simple answer regarding the
use and performance of OO technologies” [6]. Nonetheless, developers should carefully examine the evidence
regarding OOT to better understand potential benefits and risks for their specific project.
2.2.2 Project Characteristics

The second important question is:
(2) What project characteristics are important with respect to OOT?
Various attributes of a project might help determine whether OOT is an appropriate choice. Some of these attributes
are measurable by conventional metrics specific to the software product; for example, the size, criticality, and
complexity of the software. Other product-specific attributes include the maturity of the software requirements, and
the applicability of OOT to the specific problem domain. Concerns were discussed regarding whether OOT is
appropriate for all problem domains.
Other attributes of interest relate to the long-term plans for the product. Important considerations here include
whether the software is a new product or part of a product family. This would impact upgrade and maintenance
requirements. These factors are important when weighing the potential benefits of reuse that OOT might offer.
In addition, Appendix C proposes some pitfalls as identified by Webster in Pitfalls of Object-Oriented Development
[31] as helpful considerations in planning an OO program.
2-4
Volume 2
2.2.3 OOT Specific Resources

Another question to be addressed is:
(3) What project resources, specific to OOT, are needed?
Once the project characteristics are known, it is important to evaluate resources specific for implementing OOT.
Resources include those relevant to personnel who develop and approve the software product, and those relevant to
managing processes and procedures for development and approval.
Personnel resources include OOT-specific training and experience, both at the individual level (such as the software
developers and quality assurance personnel) and the corporate level. This includes training and experience with OO
methods for modeling, design, analysis and testing, and with OO tools. Note that training and experience are
concerns for regulators also, including designees within the company and certification authorities responsible for the
software approval on the project.
Administrative resources include industry standards for OOT, such as those associated with the Object Management
Group (OMG) standard for object-oriented modeling with the Unified Modeling Language (UML) [26] and
standards for OO source code languages (for example, Ada 95, Java, and C++). Other important standards include
internal process standards that define life cycle activities and data associated with OOT and how those map to
activities and data specified in DO-178B. Companies that commit to OOT may also have standards for packaging
OO components for reuse. For example, standards may cover packaging development and verification artifacts from
one project such that they do not conflict with other artifacts when they are brought together to build a larger or
different system.
OO tools are another important resource to consider. Some OO tools introduce new levels of abstraction, such as the
visual model level (for example, graphical rather than textual representations of requirements and architecture), that
might not directly correspond to abstraction levels (high-level, low-level, or derived requirements) in DO-178B.
Factors to consider here include compatibility of new OO tools with existing tools and integrated development
environments, notations, and processes; configuration management; and qualification costs.
The project characteristics together with the OOT specific resources within a company will influence the level of
involvement, or degree of oversight, that the FAA has with a project. This is a non-trivial consideration with respect
to both time and cost. The level of FAA involvement will dictate the number of software reviews, the stages of
involvement, and the nature of the review [15]. This level of regulatory involvement is closely related to the fourth
of the high-level questions raised at the workshop.
2.2.4 Regulatory Guidance

The fourth question is:
(4) How should regulatory guidance (e.g., DO-178B) and the OOTiA Handbook be applied in a practical project?
This question is really an abstraction of two more specific questions:
• Are all of the objectives in DO-178B compatible with OOT?
• How should the Handbook be applied to a practical project, and is the Handbook adequate?
As mentioned previously, the FAA is sponsoring the development of the OOTiA Handbook to provide information
specific to satisfying the DO-178B objectives when using OOT. The Handbook does not eliminate the need for
compliance with DO-178B, but instead provides guidelines for how to use OOT to comply with the DO-178B
objectives. Volume 3 of the Handbook, in particular, identifies some best practices and other information intended to
facilitate this compliance. Although the Handbook is not intended to become official FAA policy or guidance [27], it
will likely influence the approval process for an OO program, and will likely influence FAA’s future software
guidance (e.g., to impact future revisions to DO-178B or supplementary guidance).
Some participants in the brainstorming session argued that the existing guidance in DO-178B is sufficient to
accommodate approval of an OO program. Some questioned the wisdom of generating an OOT-specific handbook,
2-5
Volume 2
and wondered whether doing so implied a need for additional method-specific handbooks. For example, will we
need handbooks for aspect- or goal-oriented programming? Other participants, including some certification
authorities, however, argued in favor of the benefits that additional clarification and guidelines might provide to the
industry in the short term (that is, until DO-178B is revised or supplementary guidance is developed).
Ultimately, certification authorities, applicants, system developers, and software developers should understand the
requirements that an OO system must satisfy for it to be approved, and how the system will be shown to satisfy
these requirements [13]. Misunderstandings can result in substantial cost and schedule problems [29].
2.2.5 Technical Challenges

The final, and perhaps most difficult, question that should be addressed by anyone considering using OOT is:
(5) What are the technical challenges in applying OOT to ensure the appropriate level of integrity required for the
project?
Specific questions raised in the session concerned how well the essential elements of software engineering can be
performed when using OOT to ensure the appropriate level of integrity (design assurance). Most of the questions
within this grouping were about requirements, verification, or safety.
2.2.5.1 Requirements
Several questions were raised as to whether OOT is an adequate approach for requirements development and
implementation. That is, do OO approaches to requirements help with the correct specification and implementation
of intended functionality? At least two points were raised: (1) the difference between approaches to requirements
decomposition (functional versus object), and (2) documentation of requirements.
With functional decomposition, the typical programming unit is some form of subprogram, such as a function,
subroutine, or procedure. Each subprogram typically performs a single specific function, where good programming
practice calls for maximizing functional cohesion within a subprogram and minimizing coupling between
subprograms. Applications are built by sequencing these functional building blocks—“first do this, then do that.”
Verification, in turn, starts with the functionality of an individual subprogram and works its way up by testing
increasing levels of functionality.
In contrast to functional decomposition, OOT focuses on objects and the operations performed by or to those
objects. In an OO program, a class, which is a set of objects that share a common structure and a common behavior,
is the structural element most comparable to a subprogram. Operations related to a given functional requirement
often are distributed among objects associated with different classes.
The concern identified between the approaches is whether the distribution of functionality inherent in OO systems
complicates assurance of the intended functionality. While it is true that program flow may involve calls between
many small methods defined by different classes and, thus, complicate functionality implementation, distribution of
functionality may also provide positive benefits. These benefits include means to encapsulate state, eliminate
references to global data, and more easily ensure synchronized access by concurrent threads.
DO-178B organizes objectives for development and verification around the decomposition of requirements from
system requirements to software high-level requirements to software low-level requirements and architecture to
source code. Although both the functional approach and OOT typically have software requirements data comprised
of text with diagrams maintained by modeling tools, the diagrams offer a different perspective based on what each
approach considers to be most important. With a functional approach, the diagrams, e.g., Visio®, consist largely of
data and control flow diagrams, structure charts, entity-relationship charts, state and sequence diagrams, data stores,
and data schemas. OOT diagrams are mainly comprised of Use Cases, associations, packages, classes, subtypes,
objects, and activity diagrams. Some overlap does occur, however, with the use of sequence diagrams in that Use
Cases typically rely upon them. However, determining how to map the OOT diagrams and their subsequent
refinements to the DO-178B objectives and life cycle data was thought by session participants to be difficult. The
number and diversity of the diagrams used to describe the system can add additional complication.
2-6
Volume 2
Requirements definition by any method is a significant challenge to developing a correct and safe system [17].
While some would argue that the close correspondence between real-world entities and the objects within an OO
requirements model makes it easier to construct, validate, and maintain such models, developers should consider
whether OOT makes this challenge easier or more difficult for their project.
2.2.5.2 Verification
In addition to the questions raised about the suitability of OOT for requirements development, a similar number of
questions were raised about verification. The questions about verification are not unrelated to the concerns raised
about requirements. The following sentiment exemplifies the opinion of many in the brainstorming session:
“Object-oriented programs are generally more complex than their procedural counterparts. This added complexity
results from inheritance, polymorphism, and the complex data interactions tied to their use. Although these features
provide power and flexibility, they increase complexity and require more testing” [1].
Several of the questions discussed in the session sought to explore the extent that OO software can be verified:
• Can we analyze OO software?
• Can we adequately test OO software?
• Can we determine the error cases unique to OOT?
That is, do we have the same level of confidence in our ability to adequately review, analyze, and test OO programs
as we do with traditional functional programs? Some specific analysis issues included source code to object code
traceability, low-level requirements-based test coverage, robustness test coverage, and control and data flow
analysis. Several participants in the session argued for the application of static analysis and logic-based methods.
Most of those participants would likely argue for static analysis and formal methods even in a functional approach.
However, the broader question is whether additional verification methods are needed for OOT to achieve the same
level of assurance that could be obtained under a functional approach.
Lastly, many participants acknowledged the need for additional research to better understand error classes that are
unique to OOT, such as research by Offutt [25], and to better understand the extent to which existing methods are
adequate for verifying OOT. Several error classes introduced by OOT have been submitted as entries to the issue
list, and are discussed in section 3.
2.2.5.3 Safety
The final technical challenge mentioned in the questions concerns the ability to conduct an effective system safety
assessment. Participants discussed whether system safety assessments can be easily and accurately derived from an
OO program. Current safety analysis is often based on determining that a function, as implemented, is both correct
and safe (i.e., will function correctly and contains no design errors that would result in unacceptable, anomalous
behavior). In an OO program, operations related to a function can be widely distributed among objects that interact
with each other by exchanging messages. Assessing these interactions among distributed objects complicates safety
analysis and verification and makes functionality difficult to trace. In [19], Nancy Leveson argues that engineers
find that functional decomposition is a more natural approach to the design of control systems, and “that naturalness
translates into easier to understand and review, easier to design without errors, easier to analyze to determine
whether the system does what the engineer wants and does it safely.” Others, however, for example those who
design communication and switching systems, might argue that it is most natural to model control logic using
objects whose behavior is defined using state machines.
Although the system safety assessment is not one of the software life cycle processes specified in DO-178B,
connections with system development and system safety assessment are mentioned in DO-178B [10] (e.g., DO-
178B sections 5.1.2j and 5.2.2d). Hence, the effect of OO design and implementation on the safety assessment
process should be considered and addressed.
2-7
Volume 2
The data in Appendix A from the “Beyond the Handbook” session represents only a small portion of the data
collected in the OOTiA project. Appendix C also identifies other considerations to be addressed prior to making the
decision to use OO. However, the majority of the data deals with issues specific to OO methods and languages; that
is, the decision to use OOT is assumed. As might be guessed, many of the questions for deciding whether to use
OOT are directly related to issues raised about OO features discussed in the next section.
2.3 Considerations After Making the Decision to Use OOT

In this section, key concerns about using OOT in aviation applications are distilled from the Issues and Comments
about Object-Oriented Technology in Aviation list on the OOTiA web site and from issues documented by
certification authorities [7,21]. Throughout the discussion, entries from the issue list are cited and denoted by their
tracking number on the web site. For example, IL 1 indicates item #1 on the issues list. Mentioning an entry from
the issue list does not imply its validity; some readers likely will dispute the validity of individual entries. The
purpose of citing the entries is to give an account of the data that has been collected, and show the basis for the key
concerns discussed in this section. The key concerns, not the individual issues, are what is most important.
The issue list covers a wide range of topics. In this section, entries expressing similar concerns are grouped together,
and the groups are sorted according to the DO-178B life cycle process that is most influenced 2 by that group. The
software life cycle processes specified in DO-178B are:
• Planning Process
• Development Processes (requirements, design, code, and integration)
• Integral Processes (verification, configuration management, quality assurance, and certification liaison)
In addition to these life cycle processes, DO-178B has a section called Additional Considerations (section 12) that
provides guidance for ancillary topics such as tools, previously developed software, and formal methods.
Each comment recorded on the issue list is mapped into one of the categories (Planning Process, Development
Processes, Integral Processes, Additional Considerations). Comments related to the development processes are not
separated with respect to requirements, design and such, because the distinction is not clear in many cases. The
comments related to integral processes, however, are divided into concerns about verification and concerns about
configuration management. No entries in the issue list dealt specifically with quality assurance or the certification
liaison process. Finally, the additional considerations category deals almost exclusively with tools.
For each category, the key concerns relevant to DO-178B are briefly discussed. Appendix B provides a mapping of
the entries in the issue list to these key concerns. Appendix C lists some of the issues raised in Webster’s Pitfalls of
Object-Oriented Development [31], which may also be important to consider and address.
2.3.1 Considerations for the Planning Process

Planning is typically the first consideration after the decision to use OOT has been made. The planning process in
DO-178B specifies the development and integral process activities, environment, and standards for a project.
Planning decisions about how OOT will be used to satisfy the DO-178B objectives are recorded in software life
cycle data, such as the Plan for Software Aspects of Certification, Software Development Plan, and integral process
plans. Planning objectives are listed in Table A-1 of DO-178B. The following are key planning concerns:
2.3.1.1 Defining Life Cycle Data

A key concern pertains to defining how the software life cycle data from an OO development process maps to the
life cycle data specified in DO-178B section 11. OOT introduces new notations and models, such as behavior and
implementation diagrams (Use Cases, class, sequence, component, deployment, activity, and statechart diagrams),
2
Some concerns span multiple life cycle processes. Determining which process is most influenced is necessarily subjective. Overlap of concerns
is evident throughout the discussion.
2-8
Volume 2
that do not map directly with the data for requirements, design, and code in DO-178B. A description of the software
life cycle data is typically included in the Plan for Software Aspects of Certification, as discussed in section 11.1e of
DO-178B. Some specific questions from the issue list included:
a. How does OO life cycle data map to the DO-178B section 11 life cycle data? e.g., What does “source
code” mean in OO? What are requirements, design, and code in OOT? (IL 87)
b. What are “low level requirements” for OO? (IL 77)
Another fundamental concern for planning relates specifically to requirements. Software requirements standards, as
described in section 11.6 of DO-178B, define the methods, rules, notations, and tools for developing high-level
requirements. The concerns from the issue list covered two aspects of requirements: methods and notations.
2.3.1.2 Requirements Methods And Notations

OOT methods and notations, specifically for requirements, are a concern. The key concern is whether OO
approaches to requirements definition (UML, for example) are adequate for all types of requirements. This includes:
(1) concern about adequately capturing non-functional requirements (IL 75), and (2) concern about the tendency in
OOT to group requirements in a graphical format—making identification of low-level requirements and derived
requirements difficult, and complicating safety assessment (IL 79). Some of the specific issues are listed below:
a. Lower levels of decomposition may not be possible for some requirements (e.g., performance
requirements). Levels of abstraction may be different than traditional. (IL 80)
b. Philosophy of Functional Software Engineering: Most of the training, tools, and principles associated with
software engineering and assurance, including those of DO-178B, have been focused on a software
function perspective, in that there is an emphasis on software requirements and design and verification of
those requirements and the resulting design using reviews, analyses, and requirements-based (functional)
testing (RBT), and RBT coverage and structural coverage analysis. (IL 63)
c. Philosophy of Objects and Operations: Although, generally loosely and inconsistently defined, OOT
focuses on "objects" and the "operations" performed by or to those objects, and may have a philosophy and
perspective that are not very conducive to providing equivalent levels of design assurance as the current
"functional" approach. (IL 63)
d. Addressing derived requirements for OO – how does this happen? How is it different than traditional and
how does it tie up to the safety assessment? (IL 78)
e. Formal specification languages are generally accessible only to those specially trained to use them. To
make formal specifications accessible to developers and the authors of test cases, such formal
specifications must be mapped to natural language and/or other less formal notations (e.g. UML). There,
however, is currently no well defined means of doing so. This issue applies to both preliminary and
detailed design. (IL 73)
2.3.1.3 Restrictions
The final topic relevant to planning deals with restrictions. Section 4.5c of DO-178B states, “the software
development standards should disallow the use of constructs or methods that produce outputs that cannot be verified
or that are not compatible with safety-related requirements” [10]. Some OO languages have features that could make
it extremely difficult or impossible to satisfy the objectives of DO-178B. In many cases, a well-defined subset of the
language may be identified and documented in the coding standards that will allow compliance to objectives for a
given software level. For example, ANSI C++ has some language features, such as multiple inheritance, that may
make it difficult to meet some DO-178B objectives. Two of the entries from the issue list spoke to the potential need
for restrictions or special rules:
a. Multiple inheritance should be avoided in safety critical, certified systems. (IL 38)
b. How can we enforce the rules that restrict the use of specific OO features? (IL 58)
2-9
Volume 2
The key concern is that language features, such as multiple inheritance, should be evaluated carefully in the planning
process and restrictions or rules established, documented, and followed as warranted for a particular project.
2.3.2 Considerations for Development Processes -- Requirements, Design, Code, and

Integration
Over 40 of the issues on the issue list are related to or affect development processes (requirements, design, code, and
integration). Many of these comments describe ways that OO features promote complexity and ambiguity in the
development products (requirements, design, and code), potentially making the two assurance principles (assurance
of intended functionality and assurance of no unintended functionality) difficult to meet. Sections 6.3.1 and 6.3.2 of
DO-178B describe objectives for ensuring that high and low-level requirements are accurate, unambiguous (written
in terms that only allow a single interpretation), and consistent. Table A-2 of DO-178B addresses the production of
requirements, design, and code. The following are the key concerns distilled from the issues in this category:
2.3.2.1 About Subtypes

Inheritance allows different objects to be treated in the same general way. Through inheritance, programmers can
develop types by basing new type definitions on existing ones. In a type hierarchy, supertypes should capture the
behavior that all of the descendent subtypes have in common. A clear understanding of how subtypes and supertypes
are related is essential to having a correct type hierarchy. Two types of problems described in entries from the issue
list are associated with subtyping.
2.3.2.1.1 Type Substitutability

The substitutability issue deals with the suitability of various subtypes that are possible at the point of a call.
Whenever a system expects a value of type T, a value of type T’, where T’ is a subtype of T, can be substituted. The
key concern here is that improper subtyping can result in unintended functionality that is difficult to detect. That is,
how do we know, or provide assurance, that this substitution is always appropriate? (IL 42) The Liskov Substitution
Principle (LSP) proposes a theoretical means to mitigate improper subtyping by constraining the behavior of
subtypes [20]:
Subtype Requirement: Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for
objects y of type S where S is a subtype of T.
In theory, conformance to this principle would satisfy the assurance dilemma. However, in practice, this is difficult
because the semantics of real programming languages differ considerably from the simple model used in [20]. For
example, C++ and Java have semantics that are vastly more complex than the model of computation used in [20].
Showing that the semantics of a real programming language are equivalent to those used in [20] may be a difficult
task. The following entries from the issues list speak to the concern:
a. Use of inheritance (either single or multiple) raises issues of compatibility between classes and subclasses.
(IL 17)
b. A subclass either does not accept all messages that the superclass accepts or leaves the object in a state that
is illegal in the superclass. This situation can occur in a hierarchy that should implement a subtype
relationship that conforms to the Liskov substitution principle. (IL 22)
c. A subclass computes values that are not consistent with the superclass invariant or superclass state
invariants. (IL 23)
d. Fundamental pre-requisite language issues need clarification prior to adopting LSP and Design by Contract
(DBC). How can LSP be implemented using available languages? Strongly consider a language subset that
is amenable to use of LSP and DBC. Concern is how far to take this subset. (IL 90)
e. When a descendent adds an extension method that defines an inherited state variable, an inconsistent state
definition can occur. (IL 95)
2-10
Volume 2
2.3.2.1.2 Inconsistent Type Use

Another subtyping problem is inconsistent type use. When a descendant class does not override any inherited
method (that is, there is no polymorphic behavior), anomalous behavior can occur if the descendant class has
extension methods resulting in an inconsistent inherited state. (IL 91)
2.3.2.2 About Subclasses

Just as with types, hierarchies of classes can be constructed, where subclasses are created from more abstract
superclasses. A subclass automatically inherits all of the visible attributes and operations of the superclass; but can
override inherited operations and add new attributes and operations. A number of different concerns were raised
about subclasses.
2.3.2.2.1 Unclear Intent

Use of inheritance, polymorphism, and linkage can lead to ambiguity. (IL 10) With multiple inheritance, a subclass
may have more than one superclass, so the same operation may be inherited from multiple sources. Consequently,
the intent of the operation at the subclass level might not be clear. Cuthill notes that overuse of inheritance,
particularly multiple inheritance, can lead to unintended connections among classes [9]. The key concern is that the
original intent for a subclass or operation may not be clear. Examples of concerns about unclear intent from the issue
list include:
a. Multiple interface inheritance can introduce cases in which the developer’s intent is ambiguous. (When the
same definition is inherited from more than one source, is it intended to represent the same operation or a
different one?) (IL 15)
b. When the same operation is inherited by an interface via more than one path through the interface
hierarchy (repeated inheritance), it may be unclear whether this should result in a single operation in the
subinterface, or in multiple operations. (IL 27)
c. A subclass may be incorrectly located in a hierarchy because the complete definition/intention of a class
may not be clear. (IL 21)
d. When a subinterface inherits different definitions of the same operation [as result of redefinition along
separate paths], it may be unclear whether/how they should be combined in the resulting subinterface. (IL
28)
e. Multiple inheritance complicates the class hierarchy. (IL 33)
f. Top-heavy multiple inheritance and very deep hierarchies (six or more subclasses) are error-prone, even
when they conform to good design practice. The wrong variable type, variable, or method may be
inherited, for example, due to confusion about a multiple inheritance structure. (IL 24)
g. Overuse of inheritance, particularly multiple inheritance, can lead to unintended connections among
classes, which could lead to difficulty in meeting the DO-178B/ED-12B objective of data and control
coupling. (IL 25) (IL 37)
h. Polymorphic, dynamically bound messages can result in code that is error prone and hard to understand.
(IL 7)
i. Use of multiple inheritance can lead to “name clashes” when more than one parent independently defines
an operation with the same signature. (IL 29)
j. When different parent interfaces define operations with different names but compatible specifications, it is
unclear whether it should be possible to merge them in a subinterface. (IL 30)
2-11
Volume 2
2.3.2.2.2 Overriding
Overriding is the redefinition of an operation or method in a subclass. The key concern here is that unintentionally
overriding an operation is easy in some OO languages because of the lack of restrictions on name overloading (the
use of the same name for different operators or behavioral features, operations or methods, visible within the same
scope). The consequence is that a method of the expected name but of a different type might be called in a program.
a. It is important that the overriding of one operation by another and the joining of operations inherited from
different sources always be intentional rather than accidental. (IL 32)
b. A subclass-specific implementation of a superclass method is [accidentally] omitted. As a result, that
superclass method might be incorrectly bound to a subclass object, and a state could result that was valid
for the superclass but invalid for the subclass owing to a stronger subclass invariant. For example, object-
level methods like isEqual or copy are not overridden with a necessary subclass implementation. (IL
20)
c. It is unclear whether the normal overload resolution rules should apply between operations inherited from
different superinterfaces or whether they should not (as in C++). (IL 31)
d. Offutt has identified the following classes of errors associated with overriding [25]:
1 If a computation performed by an overriding method is not semantically equivalent to the computation
of the overridden method with respect to a variable, a behavior anomaly can result. (IL 94) This is
referred to as a State Defined Incorrectly (SDI) problem.
2 If a descendant class provides an overriding definition of a method which uses variables defined in the
descendant’s state space, a data flow anomaly can occur. (IL 96) This is referred to as an Anomalous
Construction Behavior (ACB1) problem.
3 If a descendant class provides an overriding definition of a method which uses variables defined in the
ancestor’s state space, a data flow anomaly can occur. (IL 97) This is referred to as an Anomalous
Construction Behavior (ACB2) problem.
4 If refining methods do not provide definitions for inherited state variables that are consistent with
definitions in an overridden method or if an indiscriminately-named local state variable is introduced,
data flow anomalies can result. (IL 92, 93) These are referred to as State Definition Anomaly (SDA)
and State Definition Inconsistency (SDIH) problems, respectively.
5 When private state variables exist, if every overriding method in a descendant class doesn’t call the
overridden method in the ancestor class, a data flow anomaly can exist. (IL 99) This is referred to as a
State Visibility Anomaly (SVA) problem.
As mentioned above, overriding is affected by the use of overloading. In theory, overloading enhances readability
when the overloaded operators, operations or methods are semantically consistent. (IL 60) However, overloaded
operators, operations, and methods contribute to confusion and human error when they introduce methods that have
the same name but different semantics.
2.3.2.3 About Memory Management and Initialization

According to DO-178B (section 11.10), the software design data should discuss limitations for memory and the
strategy for managing memory and its limitations. Memory management involves making accessible the memory
needed for a program's objects and data structures from the limited resources available, and recycling that memory
for reuse when it is no longer required. “The basic problem in managing memory is knowing when to keep the data
it contains, and when to throw it away so that the memory can be reused. This sounds easy, but is, in fact, such a
hard problem that it is an entire field of study in its own right” [22].
2-12
Volume 2
2.3.2.3.1 Indeterminate Execution Profiles

One problem with memory allocators is that, regardless of the allocation algorithm used, allocating and deallocating
memory repeatedly leads to fragmentation. Some algorithms, of course, lead to more fragmentation than others. In
any case, periodic reorganization of memory is needed to reduce fragmentation. The key concern is that many
traditional allocation and deallocation algorithms are unpredictable in terms of their worst-case memory use and
execution times, resulting in indeterminate execution profiles (IL 66).
2.3.2.3.2 Initialization
Incorrect initialization of variables and constants is dealt with in sections 6.3.4 and 6.4.3 of DO-178B. In OO
programs, class hierarchies (deep hierarchies in particular) may lead to initialization problems. The key concern is
that a subclass method might be called (via dynamic dispatch) by a higher level constructor before the attributes
associated with the subclass have been initialized. (IL 19) This can lead to the incomplete (failed) construction
problem identified by Offutt [25]. (IL 98) According to Offutt, there are two possible faults, depending on
programming language:
“First, the construction process may have assigned an initial value to a particular state variable, but it is the wrong
value. That is, the computation used to determine the initial value is in error. Second, the initialization of a particular
state variable may have been overlooked. In this case, there is a data flow anomaly between the constructor and each
of the methods that will first use the variable after construction (and any other uses until a definition occurs)” [25].
2.3.2.4 About Dead or Deactivated Code

Reuse is an important design goal for many OO programs. However, the requirements, design, and code of a
reusable component might contain more functionality than required by the system being certified, which raises
concerns about dead and deactivated code. The glossary of DO-178B describes dead and deactivated code as
follows:
“Dead code - Executable object code (or data) which, as a result of a design error cannot be executed (code) or
used (data) in a operational configuration of the target computer environment and is not traceable to a system or
Mis en forme
software requirement. An exception is embedded identifiers” [10].
“Deactivated code - Executable object code (or data) which by design is either (a) not intended to be executed
(code) or used (data), for example, a part of a previously developed software component, or (b) is only executed
(code) or used (data) in certain configurations of the target computer environment, for example, code that is
Mis en forme
enabled by a hardware pin selection or software programmed options” [10].
Section 6.4.4.3 of DO-178B requires that dead code be removed and analysis performed to assess the effect and
need for reverification, and section 5.4.3 of DO-178B requires deactivated code to be verified (analysis and test) to
prove that it cannot be inadvertently activated. Hence, there is a trade-off between the benefit of reuse and the cost
of additional verification of deactivated code or removal of dead code.
2.3.2.4.1 Identifying Dead and Deactivated Code

A specific concern raised in the issue list is the difficulty of identifying dead code and deactivated code in OO
programs. Dead or deactivated code can result when (a) methods of a class are not called in a particular application;
(b) methods of a class are overridden in all subclasses; or (c) attributes of a class are not accessed in a particular
application [8]. For example, no instances of a superclass might be used if all of the subclasses override a particular
method. The following entries from the issue list deal with dead/deactivated code in general:
a. The difference between dead and deactivated code is not always clear when using OOT. Without good
traceability, identifying dead versus deactivated code may be difficult or impossible. (IL 70)
b. When a design contains abstract base classes, portions of the implementations of these classes may be
overridden in more specialized subclasses, resulting [in] deactivated code. (IL 71)
2-13
Volume 2
c. Reusability is one of the objectives of OO development, but reusable components may be hard to trace
because they are designed to support multiple usages of the same component. Reusable components may
also have functionality that may not be used in every application. (IL 106)
2.3.2.4.2 Libraries and Frameworks

Dependence on libraries is a concern for safety-critical systems because it is often unclear what is happening in the
object libraries. Libraries may not have been developed with safety-critical applications in mind and may not have
the integrity required for such applications [7]. The key concern here is that dead or deactivated code can result from
using general-purpose libraries and OO frameworks when all elements of the libraries or frameworks are not used.
This key concern applies equally well to non-OO systems. However, some might argue that dependence on libraries
and frameworks may be more extensive in an OO system. In any case, use of libraries must be carefully considered,
addressed, and verified for proper functionality.
a. Deactivated Code will be found in any application that uses general purposed libraries or object-oriented
frameworks. (Note that this is the case where unused code is NOT removed by smart linkers.) (IL 1)
b. How can deactivated code be removed from an application when general purpose libraries and object-
oriented frameworks are used but not all of the methods and attributes of the classes are needed by a
particular application? (IL 57)
2.3.3 Considerations for Integral Processes

Just as complexity and ambiguity are concerns for the development processes, they are also concerns for the integral
processes. The entries from the issue list dealing with integral processes are partitioned into three categories:
verification, configuration management, and traceability. Although traceability is not called out as an integral
process in DO-178B, it is categorized here under integral processes because traceability data is often collected in
conjunction with verification activities. Tables A-3 through A-10 of DO-178B address the integral processes.
Tables A-3, A-4, and A-5 have objectives related to verifying development traceability.
The key concerns within each of the three categories are discussed below. For each of the concerns, differentiation
between the effects of the OO techniques and OO language constructs are discussed.
2.3.3.1 About Verification - Analysis

Verification, in the DO-178B context, examines the relationship between the software implementation and the
requirements. The goal is to use reviews, analyses, and tests to detect and report errors introduced during the
development processes. OO techniques, especially dynamic dispatch and polymorphism, can complicate various
verification activities of DO-178B (IL 9). Program control flow (execution) can be difficult to predict (if it can be
predicted at all) because polymorphism forces method binding to be delayed until execution time. Execution-time
circumstances can cause a single line of source code to mean many different things depending upon specific data
values that the program encounters during execution. For example, given a function f(x), which f() to call depends on
which class x belongs to, which might be multiple classes depending on the run-time state of the system. This is not
a problem of doubt about a conditional statement—it is doubt about what a specific function call means because of
dynamic dispatch [16]. This particular problem complicates testing and many different types of analyses including
flow and coupling analysis, structural coverage analysis, and source code to object code traceability as discussed
below.
2.3.3.1.1 Flow Analysis

Data and control flow analysis must be performed for software levels A, B, and C to confirm correct data and
control coupling between code components. Some OO features tend to make data and control coupling relationships
more complicated and obscure than in software developed using procedural languages. Dynamic dispatch
complicates flow analysis, as described above, because it might be unclear which method in the inheritance
hierarchy is going to be called. OO design, in general, encourages the development of many small, simple methods
2-14
Volume 2
to perform the services provided by a class. Determining the correctness of control flow decisions requires analysis
of how individual data objects that control the execution flow of the software are produced and maintained: where
and when are the objects created or destroyed, where and when are the values of the objects set, and how are any
potential “shared data” conflicts controlled. The key concern in OO programs is that decision points use data objects
with values that are maintained in other parts of the software that might be remote from the proximate path of
execution, thus making flow analysis difficult [32].
OOT also encourages hiding the details of the data representation (that is, attributes) behind an abstract class
interface. Suggested best practice is that attributes of an object should be private, and access to them only provided
through the methods appropriate to the class of the object. Being able to access attributes only through methods
makes the interaction between two or more objects implicit in the code, complicating analysis.
Many of the relevant entries from the issue list express questions about how to do the analysis, as listed below:
a. How can we meet the control and data flow analysis requirements of DO-178B with respect to dynamic
dispatch? (IL 56)
b. Flow analysis, recommended for Levels A-C, is complicated by dynamic dispatch (just which method in
the inheritance hierarchy is going to be called?). (IL 2)
c. Flow analysis and structural coverage analysis, recommended for Levels A-C, are complicated by multiple
implementation inheritance (just which of the inherited implementations of a method is going to be called
and which of the inherited implementations of an attribute is going to be referenced?). The situation is
complicated by the fact that inherited elements may reference one another and interact in subtle ways
which directly affect the behavior of the resulting system. (IL 16)
OO language features such as inlining can also complicate flow analysis because inlining can cause substantial
differences between the flow apparent in the source code and the actual flow in the object code. The following issue
demonstrates the concern:
a. Flow Analysis, recommended for levels A-C, is impacted by Inlining (just what are the data coupling and
control coupling relationships in the executable code?). The data coupling and control coupling
relationships can transfer from the inlined component to the inlining component. (IL 43)
2.3.3.1.2 Structural Coverage Analysis

Structural coverage analysis is required in DO-178B for software levels A, B, and C. The intent of structural
coverage analysis, in the DO-178B context, is to complement requirements-based testing by: (1) providing evidence
that the code structure was verified to the degree of rigor required for the applicable software level; (2) providing a
means to support demonstration of absence of unintended functions; and, (3) establishing the thoroughness of
requirements-based testing [ 11].
Structural coverage analysis is complicated by dynamic dispatch because structural coverage changes when going
from subclass to superclass. The key concern is that structural coverage in an OO program is not meaningful unless
coverage measurements are context dependent; that is, based on the class of the specific object on which the
methods were executed. “Coverage achieved in the context of one derived class should not be taken as evidence that
the method has been fully tested in the context of another derived class” [14]. The following entries in the issue list
attest to the complications:
a. Structural coverage analysis, recommended for Levels A-C, is complicated by dynamic dispatch (just
which method in the inheritance hierarchy does the execution apply to?). (IL 5)
b. The use of inheritance and polymorphism may cause difficulties in obtaining structural coverage,
particularly decision coverage and MC/DC. (IL 11)
c. The unrestricted use of certain object-oriented features may impact our ability to meet the structural
coverage criteria of DO-178B. (IL 48)
d. Statement coverage when polymorphism, encapsulation or inheritance is used. (IL 49)
2-15
Volume 2
e. How can we meet the structural coverage requirements of DO-178B with respect to dynamic dispatch?
There is cause for concern because many current Structural Coverage Analysis tools do not “understand”
dynamic dispatch, i.e. do not treat it as equivalent to a call to a dispatch routine containing a case statement
that selects between alternative methods based on the run-time type of the object. (IL 55)
The following entries from the issue list refer to the effect that OO language constructs such as inlining and
templates have on structural coverage analysis:
a. With inlining, the “logical” coverage of the inline expansions on the original source code is not clear. This
is generally only a problem when inlined code is optimized. If statements are removed from the inlined
version of a component, then coverage of the inlined component is no longer sufficient to assert coverage
of the original source code. (IL 45)
b. Inlining may affect tool usage and make structural coverage more difficult for levels A, B, and C. (IL 47)
c. Templates can be compiled using code sharing or macro-expansion. Code sharing is highly parametric,
with small changes in actual parameters resulting in dramatic differences in performance. Code coverage,
therefore, is difficult and mappings from a generic unit to object code can be complex when the compiler
uses the "code sharing" approach. (IL 52)
Code sharing involves the sharing of code by more than one class or component, for example, by means of
implementation inheritance or delegation. There are many ways to support code sharing. One risk is that inheritance
can be misused to support only the sharing of code and data structure, without attempting to follow behavioral
subtyping rules.
2.3.3.1.3 Timing and Stack Analysis

Timing analysis, worst-case execution time in particular, and stack usage are both part of review and analysis of
source code in DO-178B section 6.3.4f. Stack overflow errors are listed in section 6.4.3f of DO-178B as errors that
are typically found in requirements-based hardware/software integration testing. Timing and stack analysis are
complicated by certain implementations of dynamic dispatch. With some implementations of dynamic dispatch, it is
difficult to know just how much time will be expended determining which method to call. (IL 3) If polymorphism
and dynamic binding are implemented, stack size can grow, making analysis of the optimal stack size difficult. (IL
107)
Timing and stack analysis are also affected by inlining, templates, and macro-expansion. Inline expansion can
eliminate parameter passing, which can affect the amount of information pushed on the stack as well as the total
amount of code generated. This, in turn, can affect the stack usage and timing analysis.
a. Stack Usage and Timing Analysis, recommended for levels A-D, are impacted by Inlining (just what are
the stack usage and worst-case timing relationships in the executable code?). Since inline expansion can
eliminate parameter passing, this can affect the amount of information pushed on the stack as well as the
total amount of code generated. This, in turn, can affect the stack usage and the timing analysis. (IL 44)
b. Templates are instantiated by substituting a specific type argument for each formal type parameter defined
in the template class or operation. Passing a test suite for some but not all instantiations cannot guarantee
that an untested instantiation is bug free. (IL 50)
c. Macro-expansion can result in memory and timing issues, similar to those identified for inlining. (IL 53)
2.3.3.1.4 Source to Object Code Traceability

Source to object code traceability tends to be a controversial issue; object orientation does not improve the situation.
As discussed in DO-178B, for level A software, it is necessary to establish whether the object code is directly
traceable to the source code. If the object code is not directly traceable to the source code, then additional
verification should be performed [10]. Dynamic dispatch complicates source to object code traceability because it
might be difficult to determine how the dynamically dispatched call is represented in the object code. (IL 6) In
addition, source to object code correspondence will vary between compilers for inheritance and polymorphism,
2-16
Volume 2
along with constructors/destructors and other language helper functions. (IL 12) Additional entries from the issue
list related to source to object code traceability include:
a. Dynamic dispatch presents a problem with regard to the traceability of source code to object code that
requires “additional verification” for level A systems as dictated by DO-178B section 6.4.4.2b. (IL 8)
b. Are there unique challenges for source to object code traceability in non-Level A systems? Where should
this be addressed? Multiple tools and ways of addressing source to object traceability? (IL 81)
Some OO language features, such as inlining and implicit type conversion, can also complicate source to object code
traceability:
a. Conformance to the guidelines in DO-178B concerning traceability from source code to object code for
Level A software is complicated by inlining (is the object code traceable to the source code at all points of
inlining/expansion?). Inline expansion may not be handled identically at different points of expansion.
This can be especially true when inlined code is optimized. (IL 46)
b. Implicit type conversion raises certification issues related to source to object code traceability, the potential
loss of data or precision, and the ability to perform various forms of analysis called for by DO-178B
including structural coverage analysis and data and control flow analysis. It may also introduce significant
hidden overheads that affect the performance and timing of the application (IL 59)
2.3.3.2 About Verification - Testing

Testing in DO-178B has two high-level objectives tied to the two fundamental assurance principles: demonstrating
that the software satisfies its requirements, and demonstrating (with a high degree of confidence) that errors that
could lead to unacceptable failure conditions have been removed (section 6.4 of DO-178B). As mentioned under the
verification concerns from the Beyond the Handbook session, OO features such as inheritance and polymorphism
increase the complexity of OO programs and require more testing. The topic of testing OO programs is huge in
scope with many books 3 and considerable research devoted to the subject.
Issue list entries identify two general challenges with respect to testing: requirements-based testing and test case
reuse.
2.3.3.2.1 Requirements-Based Testing

The first challenge goes back to the difference between the functional and object perspective. Three levels of test are
called out in DO-178B testing activities: low-level tests, software integration tests, and hardware/software
integration tests. The key concern for requirements-based testing is that the mapping of function-oriented test cases
to an object-oriented implementation might not be obvious since the basic unit of testing in an OO program is not a
function or a subroutine, but an object or a class. Also, test coverage of high-level, low-level, and derived
requirements will likely require different testing strategies and tactics from the traditional functional approach
because information hiding and abstraction techniques decrease or complicate the observability of low-level
functions.
a. How do you determine functional coverage of the low level requirements? (IL 62)
b. Software integration testing may be [improperly] avoided because the high level of interaction between a
great number of objects could lead to an excessive number of test cases. (IL 64)
3
Some of the books themselves are huge; for example Binder’s Testing Object-Oriented Systems, Models, Patterns, and Tools [Binder] is over
1000 pages.
2-17
Volume 2
2.3.3.2.2 Test Case Reuse

The second challenge deals with the reuse of test cases or, more specifically, determining the appropriate reuse of
test cases. Requirements-based testing is complicated by inheritance, dynamic dispatch, and overriding because it
might be difficult to determine how much testing at a superclass level can be reused for its subclasses. (IL 4)
Inheritance and overriding raise a number of issues with respect to testing: “Should you retest inherited methods?
Can you reuse superclass tests for inherited and overridden methods? To what extent should you exercise interaction
among methods of all superclasses and of the subclass under test?”(IL 18)
2.3.3.3 About Configuration Management

Although configuration management is addressed in only a few entries from the issue list, the comments are worth
noting here because configuration management is an essential element of achieving certification approval. In DO-
178B, configuration identification and control involve defining what constitutes a configuration item, and defining
processes for controlling (baselining and changing) those items.
2.3.3.3.1 Configuration Identification

Concerns are raised in entries from the issue list regarding what constitutes a configuration item. Section 7.2.1 of
DO-178B discusses the need for unambiguous labeling of each configuration item so that a basis is established for
control. The key concern involves the uniqueness of configuration items:
a. Configuration management may be difficult in OO systems, causing traceability problems. If the objects
and classes are considered configuration items, they can be difficult to trace, when used multiple times in
slightly different manners. (IL 76)
2.3.3.3.2 Configuration Control

The key concern for configuration control is how OO tools and modeling languages such as UML might affect the
way configuration items are managed and changed.
• Configuration management and incremental development of OO projects and tools. When configuration
management comes into play during the development process may be different than our current practices,
when using an UML tool. (IL 88)
• Change impact analysis may be difficult or impossible due to difficulty in tracing functional requirements
through implementation. (IL 74)
• Multiple inheritance complicates configuration control. (IL 34)
2.3.3.4 About Traceability

Although traceability is not called out as a life cycle process in DO-178B, traceability plays a large role in providing
assurance of intended functionality and assurance of the absence of unintended functionality. For that reason,
traceability is included in considerations for integral processes. DO-178B guidelines require traceability between (a)
system requirements and software requirements to enable verification of the complete implementation of the system
requirements and give visibility to derived requirements; (b) low-level and high level requirements to verify the
architectural design decisions, give visibility to derived requirements, and demonstrate complete implementation of
high-level requirements; and (c) source code and low-level requirements to enable verification of the absence of
undocumented source code and verification of the complete implementation of the low-level requirements (section
5.5 of DO-178B).
2.3.3.4.1 Function versus Object Tracing

The key concern is that traceability of functional requirements through implementation might be lost or difficult
with an OO program because of mismatches between function-oriented requirements and an object-oriented
2-18
Volume 2
implementation (IL 61). Providing traceability from a code sequence to a specific requirement might be difficult
because operations related to a function might be widely distributed among objects. Inheritance, polymorphism, and
overloading exacerbate the problem by increasing the complexity of interaction among distributed objects. The issue
is further described as follows:
• The use of OO methods typically leads to the creation of many small methods which are physically
distributed over a large number of classes. This, and the use of dynamic dispatch, can make it difficult for
developers to trace critical paths through the application during design and coding reviews. (IL 69)
2.3.3.4.2 Complexity
Another key concern for traceability is that class hierarchies, especially those constructed through multiple
inheritance, can become overly complex, making traceability difficult. The following issues were identified:
• Polymorphic and overloaded functions may make tracing and verifying the code difficult. (IL 13)
• When inheritance is used in the design, special care must be taken to maintain traceability. This is
particularly a concern if multiple inheritance is used. (IL 35)
• Class hierarchies can become overly complex, which complicates traceability. Generalization, weak
aggregation, strong aggregation, association, and composition are some of the relations that can be used to
create the class diagrams. (IL 104)
2.3.3.4.3 Tracing through OO Views

OO requirements, design, and implementation might have multiple “views”; for example, the class diagram in the
logical view. A key concern is that behavior of the classes and how they interact together to provide the required
function might not be visible in any single view. Dynamic information concerning control flow or data flow might
not be visible [28]. Unfortunately, many current OO tools do not currently provide a mechanism to trace
requirements through multiple views and notations. One issue (IL 72) notes that traceability is made more difficult
because there is often a lack of OO methods or tools for the full software lifecycle.
2.3.3.4.4 Iterative Development

Some OO programs are developed through iteration. The key concern here is that the risk of losing traceability may
increase when using an iterative development process because of increased changes to development artifacts.
Although this is certainly a traceability issue, this could also be considered when planning for the development
process. The following issue was included:
a. Iterative development is often desired in OO implementation. Each iterative cycle has its own requirements
(normally a set of Use Cases), design, implementation, and test. There is a risk of losing traceability when
using iterative development. This can be caused by adding or changing requirements, design, or
implementations. (IL 105)
2.3.4 Additional Considerations

Ten of the 103 issues on the issue list were categorized under “Additional Considerations,” most of these being tool
issues. DO-178B is concerned with identifying the tools that are used through the software life cycle environment
planning process, controlling those tools, and qualifying them (as appropriate). A wide range of OO tools exist to
support development and verification. Some OO tools provide support for developing design and code through
framework libraries of patterns, templates, generics, and classes, and also a framework to automatically generate
source code from models. Three primary areas of concern regarding tools are: (1) capability to satisfy DO-178B
objectives, (2) long-term maintainability and maturity of tools and tool environments, and (3) qualification. The
following issues were submitted:
2-19
Volume 2
2.3.4.1 Tool Capability

A key concern about OO tools is whether the introduction of these tools in the development process contributes to
the integrity of the software products or adds additional burden for verification. Three issues are specifically
relevant:
a. Current visual modeling tools that are used for OO development make use of frameworks for automatic
code generation, replacing tedious programming tasks. Frameworks may include patterns, templates,
generics, and classes in ways requiring new verification approaches. The tool’s framework may or may not
enforce requirements, design, and coding standards. (IL 101)
b. Current visual modeling tools that are used for OO development provide a capability to generate source
code directly from UML models. Most of the existing UML tools today can use visual modeling diagrams
to construct models and generate source code from these models. The level of source code generation
depends on the tool and on the user of the tool. It is unclear how such tools may be used in aviation
projects. (IL 102)
c. The current structural coverage tools available may not “be aware” or have visibility to the internals of
inherited methods and attributes and polymorphic references supported with dynamic binding such that
they can provide a reliable measurement of the structural coverage achieved by the requirements-based
testing. (IL 103)
2.3.4.2 Tool Environments

DO-178B provides guidelines on software life cycle environment control in section 7.2.9 to ensure that tools that are
used are properly identified, controlled, and retrievable. An important concern about OO tools is that the rapid rate
of evolution of these tools may conflict with the needs of aviation software developers to support tools for relatively
long periods of time. Concern was also expressed about anticipating new tool types. Specific entries in the issue list
pertaining to tool environments include:
a. Maturity/long-term support of tools. Tool manufacturers may not realize the long-life need of tools. Is this
a higher risk in the OO environment? Education for both the tool and aviation communities to understand
the specific needs for tool manufacturers and aircraft manufacturers. Not necessarily OO-specific, but
might be more prevalent with OO. (IL 85)
b. Maintaining tool environment, archives, … when licenses are involved is not clear. May need to have
some kind of “permanent license” to support safety and continued airworthiness of the aircraft. OO is more
dependent on tools, but not necessarily an OO-specific issue. (IL 84)
c. Are there other types of OO tools that need to be addressed? Need to anticipate other classes of tools that
may come onto the scene; e.g., traceability tool for OO, transformation tools, configuration management
tools, refactoring tools (tools to restructure source code to meet new requirements). (IL 86)
2.3.4.3 Tool Qualification

According to section 12.2 of DO-178B, tool qualification is needed when processes in DO-178B are eliminated,
reduced, or automated by the use of a software tool without its output being verified. Qualification requirements
differ depending on whether a tool is a development tool (whose output is part of the software) or a verification tool
(that cannot introduce errors, but might fail to detect them). A concern raised in the entries from the issue list is
whether new or different qualification criteria are needed for OO specific tools such as visual modeling tools or OO
frameworks that serve as the basis for multiple data items. The following entries from the issue list deal with these
concerns:
a. Is there another “class” of tool qualification for visual modeling tools to demonstrate the integrity of these
tools? Not necessarily automating a step, but are looking to make sure the tool is doing what you want.
How to ensure consistency of the tools (validating the tool)? How to validate the tool when changes occur?
(IL 82)
2-20
Volume 2
b. Auto-test and code generation tools – what are the concerns when a single tool generates code and test
from the same model? The concern is with the independence – same input and same tool. (IL 83)
c. When using OO tools to develop software requirements, design and implementation, it is beneficial to
work at the visual model level, especially when using UML. When working with OO tools, configuration
management might be done at the modeling level (i.e., diagrams). This may cause a concern when the OO
tools can introduce subtle errors into the diagrams. (IL 100)
2.4 Open Issues (Summary of Workshop #2 Brainstorming Session)

During OOTiA Workshop #2, participants were invited to raise and discuss any issue that they thought had not been
adequately covered so far in the draft OOTiA Handbook. The comments spanned a wide range of topics—some
technical (such as garbage collection and exception handling), and some organizational (such as developer and
auditor capability and future use of formal methods). As noted previously, the listing of a comment from the
brainstorming session does not imply the validity of that particular comment. The comments are reported here in the
spirit of accounting for the data collected through the OOTiA activities. The OOTiA committee has not attempted to
deal with these comments; however, they will be considered in future updates to the Handbook and in other FAA
activities.
The list below is an unedited listing of the comments:
a. Garbage Collection and memory management. Are we “going to fly” garbage collection? There has been a
lot of work done in this area and nearing maturity. Destructors/finalizers are a partial alternative, but raise
issues of predictability and performance.
b. Exception handling. Use of this feature raises issues with control flow, run-time support, real-time
predictability, and deactivated code.
c. Concurrency. Use of this feature raises issues with control flow, run-time support, real-time predictability,
and deactivated code.
d. What characteristics of a program make it OO? What tells you that you are dealing with an OO program?
(dynamic dispatching)
e. Distinction between object-based and object-oriented program.
f. What level of capability should we expect from developers and auditors – and how would we measure
that?
g. Does OOT introduce a level of complexity that is not understandable by humans? (spaghetti data
structures) Does OOT allow you to more easily slip down the path of complexity?
h. Does doing OO change the picture that already exists?
i. Should there be consideration of maintenance of large OO programs? Should the Handbook offer
guidance for long term maintainability?
j. Moving target of language standard (e.g., Java moves every 6 months)
k. Should we be addressing other programming paradigms?
l. What about the consistency of guidelines among ground-based, space-based, and airborne systems?
m. Is it worth looking for other instances of object-oriented use that should be advised against (such as those
given in the multiple inheritance chapter)?
n. Mapping OO life cycle data to DO-178B section 11 life cycle data; e.g., what are requirements, design,
and code in OO?
o. How do you review code that has been generated by a non-qualified code generator?
2-21
Volume 2
p. If you are going to go OO, you may require more processing power and memory for the delivered system
than if you had not used OO.
q. Formal Methods:
• Why aren’t correct-by-construction and static verification recognized as valuable within the aviation
community?
• Ignorance about static verification.
• Documentation of best practices that include formal methods for producing better software.
• Formal methods should be included in DO-178C, acknowledging the maturity of formal methods.
• Determine the gain you get from formal methods by showing how it affects Annex A.
2.5 Summary
Identifying safety and certification concerns is an important step in developing guidelines for safely using OOT in
aviation applications. Because OOT has been around for a while, there is industry experience to help shed light on
possible problems. In this report, we focus specifically on potential pitfalls to using OOT in aviation applications.
These concerns and questions about OOT have been collected through the OOTiA project web site and workshops.
In general, two sets of challenges are summarized below: (1) challenges to consider before making the decision to
use OOT on a program, and (2) challenges to consider once that decision is made.
2.5.1 Summary of Decision-Making Process for Using OOT

During a brainstorming session at OOTiA Workshop #2, participants proposed that questions in the following
subjects should be evaluated as part of the decision-making process for using OOT:
1. Reality of the benefits of using OOT
2. Project characteristics
3. Resources specific to implementing OOT
4. Regulatory guidance
5. Technical challenges in the areas of requirements, verification, and safety.
2.5.2 Summary of Key Areas of Concern for OOT When Meeting DO-178B
Other challenges to safely implementing OOT in compliance with DO-178B were captured through the OOTiA web
site on a list of “Issues and Comments about Object-Oriented Technology in Aviation.” The key areas of concern are
summarized in question format below (with reference to the appropriate section in Volume 2) and are further
addressed in Volume 3. These are the types of questions that developers should consider and address in their OOT
projects.
2.5.2.1 Questions to Consider in the Planning Process

a) How does the life cycle data from an OO development process map to the life cycle data specified in DO-
178B? (section 2.3.1.1)
b) Are OO approaches adequate to define all types of requirements? (section 2.3.1.2) Specifically:
• Can we capture all nonfunctional requirements of interest? (section 2.3.1.2)
• Can we avoid problems associated with graphical grouping? (section 2.3.1.2)
c) Have potentially problematic language features (such as multiple inheritance) been evaluated carefully in
the planning process? (section 2.3.1.3)
2-22
Volume 2
d) Have appropriate language restrictions been established, documented, and followed? (section 2.3.1.3)
2.5.2.2 Questions to Consider in the Development Processes – Requirements, Design, Code,

and Integration
a) Is improper subtyping that can result in unintended functionality addressed? I.e., is subtyping used to
improperly define types that are not substitutable for their parent types? (section 2.3.2.1.1)
b) Has it been ensured that new methods defined by a subclass do not introduce anomalous behavior by
producing a state inconsistent with that defined by the superclass? (section 2.3.2.1.2)
c) Is the intent clear when using OO features (such as multiple inheritance) and when creating very deep
inheritance hierarchies? (section 2.3.2.2.1)
d) Have errors associated with the unintentional/accidental overriding of methods or operations been
avoided? (section 2.3.2.2.2)
e) Has the confusion and human error associated with the definition of overloaded operations that have the
same name but different semantics been avoided? (section 2.3.2.2.2)
f) Do allocation/deallocation algorithms result in deterministic execution profiles? (section 2.3.2.3.1)
g) Has it been ensured that subclass methods are not called by superclass constructors before all the attributes
of the subclass have been initialized? (section 2.3.2.3.2)
h) Have dead and deactivated code in OOT programs and reusable components been identified? (section
2.3.2.4.1)
i) Has deactivated code been properly addressed when working with general purpose libraries and
frameworks? (section 2.3.2.4.2)
2.5.2.3 Questions to Consider for Integral Processes
2.5.2.3.1 Verification
a) Does the approach for data and control flow analysis address complications that may arise with dynamic
dispatch, polymorphism, multiple implementation inheritance, and inlining? (section 2.3.3.1.1)
b) Does the approach account for dynamic dispatch and the run-time classes of objects when measuring the
structural coverage of an object-oriented program? (section 2.3.3.1.2)
c) Does the approach for measuring structural coverage adequately address inlining and templates when they
are used? (section 2.3.3.1.2)
d) Are problems related to timing analysis avoided or addressed when using dynamic dispatch? (section
2.3.3.1.3)
e) Are problems related to timing analysis avoided or addressed when using inlining, templates, and macro
expansion? (section 2.3.3.1.3)
f) Is source to object code traceability provided when using dynamic dispatch, inlining, and/or implicit type
conversion? (section 2.3.3.1.4)
g) Is functional coverage of low-level requirements provided? ((section 2.3.3.2.1)
h) Has adequate requirements coverage at all levels of integration been provided, even if the number of test
cases is large? (section 2.3.3.2.1)
i) If test cases developed for a class will be reused to test its subclasses, has the approach been adequately
assessed? (section 2.3.3.2.2)
2.5.2.3.2 Configuration Management
a) Have unique configuration items been defined in the OO project? (section 2.3.3.3.1)
b) Has the management and change of configuration items been addressed, when using OO tools and
modeling languages? (section 2.3.3.3.2)
2-23
Volume 2
2.5.2.3.3 Traceability
a) Has traceability between functional requirements and object-oriented implementations been ensured?
(section 2.3.3.4.1)
b) Has traceability when constructing inheritance hierarchies been ensured? (section 2.3.3.4.2)
c) Have behavioral requirements that map to multiple graphical views in OOT models been addressed?
(section 2.3.3.4.3)
d) When using an iterative development process that leads to a large number of changes to a large number of
artifacts, has traceability been ensured? (section 2.3.3.4.4)
2.5.2.4 Questions to Consider Related to Additional Considerations

a) If visual modeling tools are used, do they support compliance with DO-178B? (section 2.3.4.1)
b) Do structural coverage analysis tools used for OO projects provide a reliable measurement of the structural
coverage achieved? (section 2.3.4.1)
c) Have the long-term and maintenance needs for OO tools been considered? (section 2.3.4.2)
d) Are OO tools properly controlled and retrievable? (section 2.3.4.2)
e) Are there tools used that have an impact on safety but do not fit the DO-178B definition for development
or verification tools? If so, are they adequately addressed? (section 2.3.4.3)
f) If tool qualification is needed for OO tools, has the tool criteria been appropriately identified and applied?
(section 2.3.4.3)
For each of the above questions, key concerns are identified based on input to the OOTiA program. This list is
certainly incomplete; however, it provides a starting point for developing guidelines for the safe use of OOT in
aviation applications. Volume 3 of the OOTiA Handbook provides some best practices for developing OOT
applications in systems to be certified by the FAA. Volume 4 provides an approach for certification authorities and
designees to ensure that OOT issues have been addressed in the projects they are reviewing or approving.
2.6 References
1. Alexander, Roger T. “Improving the Quality of Object-Oriented Programs,” IEEE Software, September/
October 2001, pp. 90-91.
Software. Version 1.2, 31 October 2001.
Software. Version 1.6.
4. Basili, V., L. Briand and W. Melo. “How Reuse Influences Productivity in Object-Oriented Systems.”
Communications of the ACM, vol. 39, no. 10, 1996, pp. 104-116.
5. Binder, Robert V. Testing Object-Oriented Systems. Addison-Wesley, 2000.
6. Briand, L., E. Arisholm, S. Counsell, F. Houdek, and P. Thévenod-Fosse. “Empirical Studies of Object-
Oriented Artifacts, Methods, and Processes: State of the Art and Future Directions.” Technical Report ISERN-
99-12, 1999.
7. Certification Authorities Software Team (CAST). “Object-Oriented Technology (OOT) in Civil Aviation
Projects: Certification Concerns.” Position Paper CAST-4, January 2000, available at
http://www2.faa.gov/certification/aircraft/av-info/software/CAST_Papers.htm. Visited on 29 July 2003.
8. Certification Authorities Software Team (CAST). “Use of the C++ Programming Language.” Position Paper
CAST-8, January 2002, available at http://www2.faa.gov/certification/aircraft/av-
info/software/CAST_Papers.htm. Visited on 29 July 2003.
2-24
Volume 2
9. Cuthill, Barbara. “Applicability of Object-Oriented Design Methods and C++ to Safety-Critical Systems.”
Proceedings of the Digital Systems Reliability and Safety Workshop, 1993.
10. RTCA, Inc. Software Considerations in Airborne Systems and Equipment Certification. RTCA/DO-178B,
December 1992.
11. RTCA, Inc. Final Report for Clarification of DO-178B “Software Considerations in Airborne Systems and
Equipment Certification.” RTCA/DO-248B, 12 October 2001.
12. Glass, Robert L. “The Naturalness of Object Orientation: Beating a Dead Horse?” IEEE Software, May/June
2002, pp. 103-104.
13. Hayhurst, Kelly J., C. Michael Holloway. “Challenges in Software Aspects of Aviation Systems.” Proceedings
of the 26th Annual NASA Goddard Software Engineering Workshop, 27-29 November 2001, pp. 7-13.
14. Information Processing Ltd. “Advanced Coverage Metrics for Object-Oriented Software.” Available at
http://www.iplbath.com/pdf/p0833.pdf. Visited on 30 October 2003.
15. FAA Aircraft Certification Service. Conducting Software Reviews Prior to Certification. Job Aid, June 1998,
available at http://www2.faa.gov/certification/aircraft/av-info/software/Job_Aids.htm. Visited on 29 July 2003.
16. Knight, J.; Evans, D.; and Offutt, J. “Object Oriented Programming in Safety-Critical Software.” A white paper.
17. Hanks, Kimberly S., John C. Knight, Elisabeth A. Strunk. “Erroneous Requirements: A Linguistic Basis for
Their Occurrence and an Approach to Their Reduction.” Proceedings of the 26th Annual NASA Goddard
Software Engineering Workshop, 27-29 November 2001, pp. 115-119.
18. Knight, John C. “Object-Oriented Techniques and Dependability.” A white paper.
19. Leveson, Nancy. “Re: object-orientation vs. safety-critical” in Safety-Critical Mailing List, 2002, archived at
http://www.cs.york.ac.uk/hise/safety-critical-archive/2002/0203.html. Visited on 28 July 2003.
20. Liskov, Barbara H., Jeanette M. Wing. “A Behavioral Notion of Subtyping,” ACM Transactions on
Programming Languages and Systems, Nov. 1994, vol. 16, no. 6, pp. 1811-1841.
21. Rierson, Leanna. “Object-Oriented Technology (OOT) in Civil Aviation Projects: Certification Concerns.”
Proceedings of the 18th Digital Avionics Systems Conference, St. Louis, MO, Oct. 24-29, 1999.
22. “The Memory Management Reference Beginner's Guide Overview.” Archived at

http://www.memorymanagement.org/articles/begin.html. Visited on 28 August 2003.
23. Meyer, Bertrand. Object-Oriented Software Construction. Prentice Hall, 2nd edition, 1997.
24. Moynihan, Tony. “An Experimental Comparison of Object-Orientation and Functional-Decomposition as

Paradigms for Communicating System Functionality to Users.” The Journal of Systems and Software, vol. 33,
1996, pp. 163-169.
25. Offutt, Jeff, Roger Alexander, Ye Wu, Quansheng Xiao, Chuck Hutchinson. “A Fault Model for Subtype
Inheritance and Polymorphism,” The 12th IEEE International Symposium on Software Reliability Engineering,
Hong Kong, PRC, pp. 84–95, November 2001, available at
http://ieeexplore.ieee.org/iel5/7759/21326/00989461.pdf?tp=&arnumber=989461&isnumber=21326.
26. Object Management Group. OMG Unified Modeling Language Specification. Version 1.5, March 2003.
27. Rierson, Leanna K. “FAA’s Next Steps for OOTiA.” Presented at the Object-Oriented Technology in Aviation
Workshop 2, 27 March 2003, available at http://shemesh.larc.nasa.gov/foot/next-steps-end.ppt. Visited on 29
July 2003.
2-25
Volume 2
28. Rosay, Cyrille. “Is DO-178B still compatible with modern modeling methods?” A white paper from
JAA/CEAT, draft 3-15, 22 February 2002.
29. Hayhurst, Kelly J., Cheryl Dorsey, John Knight, Nancy Leveson, G. Frank McCormick. “Streamlining Software
Aspects of Certification: Report on the SSAC Survey.” NASA/TM-1999-209519, August 1999.
30. Vessey, Iris, and Sue A. Conger. “Requirements Specification: Learning Object, Process, and Data
Methodologies.” Communications of the ACM, vol. 37, no. 5, May 1994, pp. 102-113.
31. Webster, Bruce F. Pitfalls of Object-Oriented Development. M&T Books, 1995. (out of print)
32. Whitford, S. A. “Software Safety Code Analysis of an Embedded C++ Application.” Proceedings of the 20th
International System Safety Conference, August 5-9, 2002, pp. 422-429.
33. Wood, M, J. Daly, J. Miller, and M. Roper. “Multi-Method Research: An Empirical Investigation of Object-
Oriented Technology.” The Journal of Systems and Software, 1999, no. 34, pp. 13-26.
2-26
Volume 2
Appendix A Results of the Beyond the Handbook Session

At OOTiA Workshop #2, a brainstorming session called “Beyond the Handbook” was held where participants were
asked to suggest questions that should be answered before a program commits to using OOT. During the session,
participants produced a list of fifty-one questions related to making a decision about whether to use OOT. The
questions are listed below in the order recorded during the session.
1. What is the impact of the Handbook on choosing to use OOT?

2. What are my alternatives to OOT?
3. What is the maturity of the staff experience in using OO methods?
4. What is the maturity of the standards supporting the process?
5. Is the issue with OOT the source to object code issue? If so, then does the criticality level affect the
decision to use OOT?
6. How do specific languages relate to the guidelines in the Handbook?
7. Is there any evidence to suggest that we can build systems better with OOT?
8. What is the real motivation for considering OOT? Is it to be faster, better, cheaper, or because
programmers want to use Java?
9. Can we teach programmers to build safe OO software? Is it being done anywhere?
10. Can we analyze OO Software?
11. Can we adequately test OO Software?
12. Where’s the data to support or deny OO claims?
13. Is choosing technologies based on available pool of people negligence?
14. What’s the overall size and complexity of our project?
15. What’s the anticipated length of time our project must be maintained for?
16. Is the company planning on having a product line architecture? How frequent will releases be?
17. Does the certification authority have a track record for approval or denial of OO projects?
18. What is the minimum experience a company should have in OOT before embarking on developing a
system with major consequences?
19. If I choose to use OO analysis and design but implement in a procedural language, what implication will
the Handbook have on me?
20. Does the company have a plan for reuse?
21. Is use-case, iterative requirements development good enough for safety critical systems?
22. Is there a set of lessons learned that the group should know?
23. Does the company have established standards and practices for OOT?
24. Where’s the technology argument that we can build safe systems using OOT?
25. To what extent is OOT unique? How do we determine the error cases that are unique to OOT?
26. Whether your DER is OO literate or OO friendly?
27. Is it appropriate to use commercially available processes/products for developing aviation software, or
what steps need to be taken to make it so?
Volume 2
28. Are we subjecting OOT to extra scrutiny because it is new to the aviation community?
29. Does the OO paradigm actually fit your problem domain?
30. How much of current good practice is non-applicable to OOT?
31. Do we need to make a distinction between the design process and the develop/test process? Does OOD <->
OO implementation?
32. Do you have a plan for failure?
33. Where is dynamic dispatch really useful? Would the non-OO alternative be any easier to analyze?
34. How mature are your requirements?
35. Is there an existing tool set to support your effort?
36. Has the company analyzed the benefits & risks of using OOT over their current established approaches to
software engineering?
37. Have you run out of steam in regards to existing techniques for really large systems and if so does OOT
help us manage such systems better?
38. Is there an agreement on what is OOT? What is essential, what is not, etc.?
39. Does OOT help us write the requirements correctly and implement them properly? Can we integrate
Formal Methods into the process?
40. Does OOT help us identify what we really want in the system and document this in requirements?
41. Will our system interface with other systems that are not OOT-based?
42. Do you understand the issues presented in the Handbook and why are they issues? Does anyone?
43. Can your company make a case for using OOT in a system in such a way that you can document and verify
the system?
44. Why is company X using OOT?
45. Can the system & software safety assessments be derived easily from OOT or is it a difficult task to ensure
safety?
46. Why is company Y not using OOT?
47. Is OO the best method from the engineering point of view for reuse?
48. Are the objectives in DO-178B sufficient to define ‘correctly’ for OOT development?
49. Are your requirements implementable using OOT?
50. What measures or metrics will you use to determine success/failure for your project?
51. Is control-flow analysis, data-flow analysis, Z-flow analysis applicable to OO software, or should we be
looking for something else?
2-28
Volume 2
Appendix B Mapping of Issue List to Considerations

The following table contains all of the entries, as of the date of publication of this document, to the “Issues and
Comments about Object-Oriented Technology in Aviation” list on the OOTiA web site. Four of the entries (IL 14,
36, 39, and 41) are duplicates of other entries and are denoted by an *. In the table, most entries are mapped to a
DO-178B life cycle process category, and to one of the subjects of key concern discussed within that category.
Some entries (IL 26, 40, 51, 54, 65, 67, 68) were difficult to classify and were not assigned to subject categories.
Issue statements are included as provided on the web site (i.e., they have not been edited).
IL # Issue Statement DO-178B Life Cycle Volume 2 reference
Process Impacted and Category
1 Deactivated Code will be found in any application that Development 2.3.2.4.2 libraries &
uses general purposed libraries or object-oriented frameworks
frameworks. (Note that this is the case where unused
code is NOT removed by smart linkers.)
2 Flow Analysis, recommended for Levels A-C, is Integral 2.3.3.1.1 flow
complicated by Dynamic Dispatch (just which method in (Verification) analysis
the inheritance hierarchy is going to be called?).
3 Timing Analysis, recommended for Levels A-D is Integral 2.3.3.1.3 timing and
complicated by Dynamic Dispatch (just how much time (Verification) stack analysis
will be expended determining which method to call?).
4 Requirements Testing, recommended for Levels A-D, and Integral 2.3.3.2.2 test case
Structural Coverage Analysis, recommended for Levels (Verification) reuse
A-C, are complicated by Inheritance, Overriding and
Dynamic Dispatch (just how much of the existing
verification of the parent class can be reused in its
subclasses?)
5 Structural Coverage Analysis, recommended for Levels Integral 2.3.3.1.2 structural
A-C, is complicated by Dynamic Dispatch (just which (Verification) coverage analysis
method in the inheritance hierarchy does the execution
apply to?).
6 Conformance to the guidelines in DO-178B concerning Integral 2.3.3.1.4 source to
traceability from source code to object code for Level A (Verification) object trace
software is complicated by Dynamic Dispatch (how is a
dynamically dispatched call represented in the object
code?).
7 Polymorphic, dynamically bound messages can result in Development 2.3.2.2.1 unclear
code that is error prone and hard to understand. intent
8 Dynamic dispatch presents a problem with regard to the Integral 2.3.3.1.4 source to
traceability of source code to object code that requires (Verification) object trace
“additional verification” for level A systems as dictated
by DO-178B section 6.4.4.2b.
9 Dynamic dispatch complicates flow analysis, symbolic Integral 2.3.3.1.1 flow
analysis, and structural coverage analysis. (Verification) analysis
2.3.3.1.2 structural
coverage analysis
10 Inheritance, polymorphism, and linkage can lead to Development 2.3.2.2.1 unclear
ambiguity. intent
11 The use of inheritance and polymorphism may cause Integral 2.3.3.1.2 structural
difficulties in obtaining structural coverage, particularly (Verification) coverage analysis
decision coverage and MC/DC
2-29
Volume 2

12 Source to object code correspondence will vary between Integral 2.3.3.1.4 source to
compilers for inheritance and polymorphism. (Verification) object trace
13 Polymorphic and overloaded functions may make tracing Integral 2.3.3.4.2 complexity
and verifying the code difficult. (Traceability)
14* Requirements Testing, recommended for Levels A-D, and Integral 2.3.3.2.2 test case
Structural Coverage Analysis, recommended for Levels (Verification) reuse
A-C, are complicated by Inheritance, Overriding and
Dynamic Dispatch (just how much of the existing
verification of the parent class can be reused in its
subclasses?). [Note: this is the same issue as IL 4)]
15 Multiple interface inheritance can introduce cases in Development 2.3.2.2.1 unclear
which the developer’s intent is ambiguous. (when the intent
same definition is inherited from more than one source is
it intended to represent the same operation or a different
one?)
16 Flow Analysis and Structural Coverage Analysis, Integral 2.3.3.1.1 flow
recommended for Levels A-C, are complicated by (Verification) analysis
Multiple Implementation Inheritance (just which of the
inherited implementations of a method is going to be
called and which of the inherited implementations of an
attribute is going to be referenced?). The situation is
complicated by the fact that inherited elements may
reference one another and interact in subtle ways which
directly affect the behavior of the resulting system.
17 Use of inheritance (either single or multiple) raises issues Development 2.3.2.1.1 type
of compatibility between classes and subclasses. substitutability
18 Inheritance and overriding raise a number of issues with Integral 2.3.3.2.2 test case
respect to testing: “Should you retest inherited methods? (Verification) reuse
Can you reuse superclass tests for inherited and
overridden methods? To what extent should you exercise
interaction among methods of all superclasses and of the
subclass under test?”
19 Inheritance can introduce problems related to Development 2.3.2.3.2
initialization. “Deep class hierarchies [in particular] can initialization
lead to initialization bugs.” There is also a risk that a
subclass method will be called (via dynamic dispatch) by
a higher level constructor before the attributes associated
with the subclass have been initialized.
20 “A subclass-specific implementation of a superclass Development 2.3.2.2.2 overriding
method is [accidentally] omitted. As a result, that
superclass method might be incorrectly bound to a
subclass object, and a state could result that was valid for
the superclass but invalid for the subclass owing to a
stronger subclass invariant. For example, Object-level
methods like isEqual or copy are not overridden with a
necessary subclass implementation”.
2-30
Volume 2

21 “A subclass [may be] incorrectly located in a hierarchy. Development 2.3.2.2.1 unclear
For example, a developer locates SquareWindow as a intent
subclass of RectangularWindow, reasoning that a square
is a special case of a rectangle ... Suppose that [the
method] resize(x, y) is inherited by SquareWindow. It
allows different lengths for adjacent sides, which causes
SquareWindow to fail after it has been resized. This
situation is a design problem: a square is not a kind of a
rectangle, or vice versa. Instead both are kinds of four-
sided polygons. The corresponding design solution is a
superclass FourSidedWindow, of which
RectangularWindow and SquareWindow are subclasses.”
22 “A subclass either does not accept all messages that the Development 2.3.2.1.1 type
superclass accepts or leaves the object in a state that is substitutability
illegal in the superclass. This situation can occur in a
hierarchy that should implement a subtype relationship
that conforms to the Liskov substitution principle.”
23 “A subclass computes values that are not consistent with Development 2.3.2.1.1 type
the superclass invariant or superclass state invariants.” substitutability
24 “Top-heavy multiple inheritance and very deep Development 2.3.2.2.1 unclear
hierarchies (six or more subclasses) are error-prone, even intent
when they conform to good design practice. The wrong
variable type, variable, or method may be inherited, for
example, due to confusion about a multiple inheritance
structure”
25 The ability of a subclass to directly reference inherited Development 2.3.2.2.1 unclear
attributes tightly couples the definitions of the two intent
classes.
26 Inheritance can be abused by using it as a “kind of code- Development
sharing macro to support hacks without regard to the
resulting semantics”.
27 When the same operation is inherited by an interface via Development 2.3.2.2.1 unclear
more than one path through the interface hierarchy intent
(repeated inheritance), it may be unclear whether this
should result in a single operation in the subinterface, or
in multiple operations.
28 When a subinterface inherits different definitions of the Development 2.3.2.2.1 unclear
same operation [as a result of redefinition along separate intent
paths], it may be unclear whether/how they should be
combined in the resulting subinterface.
29 Use of multiple inheritance can lead to “name clashes” Development 2.3.2.2.1 unclear
when more than one parent independently defines an intent
operation with the same signature.
30 When different parent interfaces define operations with Development 2.3.2.2.1 unclear
different names but compatible specifications, it is intent
unclear whether it should be possible to merge them in a
subinterface.
31 It is unclear whether the normal overload resolution rules Development 2.3.2.2.2 overriding
should apply between operations inherited from different
superinterfaces or whether they should not (as in C++).
2-31
Volume 2

32 It is important that the overriding of one operation by Development 2.3.2.2.2 overriding
another and the joining of operations inherited from
different sources always be intentional rather than
accidental.
33 Multiple inheritance complicates the class hierarchy Development 2.3.2.2.1 unclear
intent
34 Multiple inheritance complicates configuration control Integral 2.3.3.3.2
(Configuration configuration control
Management)
35 When inheritance is used in the design, special care must Integral 2.3.3.4.2 complexity
be taken to maintain traceability. This is particularly a (Traceability)
concern if multiple inheritance is used.
36* Source to object code correspondence will vary between Integral 2.3.3.1.4 source to
compilers for inheritance and polymorphism. [Note: this (Verification) object code
is the same issue as IL 12] traceability
37 Overuse of inheritance, particularly multiple inheritance, Development 2.3.2.2.1 unclear
can lead to unintended connections among classes, which intent
could lead to difficulty in meeting the DO-178B/ED-12B
objective of data and control coupling.
38 Multiple inheritance should be avoided in safety critical, Planning 2.3.1.3 restrictions
certified systems.
39* “Top-heavy multiple inheritance and very deep Development 2.3.2.2.1 unclear
hierarchies (six or more subclasses) are error-prone, even intent
when they conform to good design practice. The wrong
variable type, variable, or method may be inherited, for
example, due to confusion about a multiple inheritance
structure” [Note: this is the same issue as IL 24]
40 Reliance on programmer specified optimizations of the Development
inheritance hierarchy (invasive inheritance) is potentially
error prone and unsuitable for safety critical applications.
41* Inheritance, polymorphism, and linkage can lead to Development 2.3.2.2.1 unclear
ambiguity. [Note: this is the same issue as IL 10] intent
42 Inheritance allows different objects to be treated in the Development 2.3.2.1.1 type
same general way. substitutability
Inheritance as used in Object-Oriented Technology is
combining several like things into a fundamental building
block. The programmer is allowed to take a group of
these like things and refer to them in a general way. One
routine can be used for all types that inherit from the
fundamental building block. The more often a
programmer can use the generic behavior of the parent,
the more productive the programmer is. The problem I
see is that the generic behavior will not always be precise
enough for all the applications, and that critical
judgement is required to determine when the programmer
needs to specialize the behavior of one of the object
rather than use the generic. Who will issue that critical
judgement? Who will find all the instances where the
general case is too far away from the precision required?
2-32
Volume 2

43 Flow Analysis, recommended for levels A-C, is impacted Integral 2.3.3.1.1 flow
by Inlining (just what are the data coupling and control (Verification) analysis
coupling relationships in the executable code?). The data
coupling and control coupling relationships can transfer
from the inlined component to the inlining component.
44 Stack Usage and Timing Analysis, recommended for Integral 2.3.3.1.3 timing and
levels A-D, are impacted by Inlining (just what are the (Verification) stack analysis
stack usage and worst-case timing relationships in the
executable code?). Since inline expansion can eliminate
parameter passing, this can effect the amount of
information pushed on the stack as well as the total
amount of code generated. This, in turn, can effect the
stack usage and the timing analysis.
45 Structural Coverage Analysis, recommended for levels A- Integral 2.3.3.1.2 structural
C, is complicated by Inlining (just what is the “logical” (Verification) coverage analysis
coverage of the inline expansions on the original source
code?). This is generally only a problem when inlined
code is optimized. If statements are removed from the
inlined version of a component, then coverage of the
inlined component is no longer sufficient to assert
coverage of the original source code.
46 Conformance to the guidelines in DO-178B concerning Integral 2.3.3.1.4 source to
traceability from source code to object code for Level A (Verification) object trace
software is complicated by Inlining (is the object code
traceable to the source code at all points of
inlining/expansion?). Inline expansion may not be
handled identically at different points of expansion. This
can be especially true when inlined code is optimized.
47 Inlining may affect tool usage and make structural Integral 2.3.3.1.2 structural
coverage more difficult for levels A, B, and C. (Verification) coverage analysis
48 The unrestricted use of certain object-oriented features Integral 2.3.3.1.2 structural
may impact our ability to meet the structural coverage (Verification) coverage analysis
criteria of DO-178B.
49 Statement coverage when polymorphism, encapsulation Integral 2.3.3.1.2 structural
or inheritance is used. (Verification) coverage analysis
50 Templates are instantiated by substituting a specific type Integral 2.3.3.1.3 timing and
argument for each formal type parameter defined in the (Verification) stack analysis
template class or operation. Passing a test suit for some
but not all instantiations cannot guarantee that an untested
instantiation is bug free.
51 Nested templates, child packages (Ada), and friend Development
classes (C++) can result in complex code and hard to read
error messages on many compilers.
2-33
Volume 2

52 Templates can be compiled using "code sharing" or Integral 2.3.3.1.2 structural
"macro-expansion". Code sharing is highly parametric, (Verification) coverage analysis
with small changes in actual parameters resulting in
dramatic differences in performance. Code coverage,
therefore, is difficult and mappings from a generic unit to
object code can be complex when the compiler uses the
"code sharing" approach.
53 Macro-expansion can result in memory and timing issues, Integral 2.3.3.1.3 timing and
similar to those identified for inlining. (Verification) stack analysis
54 The use of templates can result in code bloat. Many C++ Development
compilers cause object code to be repeated for each
instance of a template of the same type.
55 How can we meet the structural coverage requirements of Integral 2.3.3.1.2 structural
DO-178B with respect to dynamic dispatch? There is (Verification) coverage analysis
cause for concern because many current Structural
Coverage Analysis tools do not “understand” dynamic
dispatch, i.e. do not treat it as equivalent to a call to a
dispatch routine containing a case statement that selects
between alternative methods based on the run-time type
of the object.
56 How can we meet the control and data flow analysis Integral 2.3.3.1.1 flow
requirements of DO-178B with respect to dynamic (Verification) analysis
dispatch?
57 How can deactivated code be removed from an Development 2.3.2.4.2 libraries &
application when general purpose libraries and object- frameworks
oriented frameworks are used but not all of the methods
and attributes of the classes are needed by a particular
application?
58 How can we enforce the rules that restrict the use of Planning 2.3.1.3 restrictions
specific OO features?
59 Implicit type conversion raises certification issues related Integral 2.3.3.1.4 source to
to source to object code traceability, the potential loss of (Verification) object trace
data or precision, and the ability to perform various forms
of analysis called for by [DO-178B] including structural
coverage analysis and data and control flow analysis. It
may also introduce significant hidden overheads that
affect the performance and timing of the application.
60 Overloading can be confusing and contribute to human Development 2.3.2.2.2 overriding
error when it introduces methods that have the same
name but different semantics. Overloading can also
complicate matters for tools (e.g., structural coverage and
control flow analysis tools) if the overloading rules for
the language are overly complex.
61 Loss of traceability due to the translation of functional Integral 2.3.3.4.1 function
requirements to an object-oriented design. (Traceability) vs. object tracing
62 Functional coverage of the low level requirement Integral 2.3.3.2.1
(Verification) requirements-based
testing
2-34
Volume 2

63 Philosophy of Functional Software Engineering - Most of Planning 2.3.1.2 requirements
the training, tools and principles associated with software Development methods and
engineering and assurance, including those of RTCA DO- notations
178B, have been focused on a software function
perspective, in that there is an emphasis on software
requirements and design and verification of those
requirements and the resulting design using reviews,
analyses, and requirements-based (functional) testing, and
RBT coverage and structural coverage analysis.
Philosophy of Objects and Operations - Although
generally loosely and inconsistently defined, OOT
focuses on "objects" and the "operations" performed by
and/or to those objects, and may have a philosophy and
perspective that are not very conducive to providing
equivalent levels of design assurance as the current
"functional" approach.
64 Software/software integration testing is often avoided. Integral 2.3.3.2.1
The position defended by the industry is that the high (Verification) requirements-based
level of interaction between a great number of objects testing
could lead to a combinative explosion of test cases.
65 Could there be security concerns related to the use of Additional
COTS based OOT solutions? Particularly with respect to Considerations
field loadable software, security risks have been mitigated
by the unique architectures of most current systems.
66 Use of dynamic memory allocation/deallocation and use Development 2.3.2.3.1
of exception handling were raised as issues by Leanna indeterminate
Rierson in her paper "Object-Oriented Technology (OOT) execution profiles
in Civil Aviation Projects: Certification Concerns" but are
currently missing from the list of concerns. If the FAA is
concerned about these two items, they should be
discussed at the workshop.
67 Most OO languages use reference semantics for passing Integral
objects (e.g. Java only supports reference semantics; C++ (Verification)
also supports passing by value but this is rarely used and
cannot be used when dynamic binding is required). This
results in variables being aliased to each other. It is
difficult to analyse the effect of this aliasing on program
behaviour because many tools do not allow for the
possible presence of aliasing. It is also easy for a
developer to inadvertantly use a shallow copy or equality
operation where the required semantics can only be
achieved by a deep copy or equality operation.
2-35
Volume 2

68 The selection of the code to implement an operation may Development or
depend upon more than just the run-time type of the Integral
target object. In cases involving binary mathematical (Verification)?
operations, for instance, this choice typically depends on
the run-time types of both arguments. As explained in
[Bruce et al.], [Castagna] and [MultiJava], this (and other
related situations) are not handled well by most current
OO languages. (A.k.a. "Binary methods problem")
References:
[Bruce eta al.] Bruce, Kim, Luca Cardelli, Giuseppe
Castagna, The Hopkins Object Group, Gary T. Leavens
and Benjamin Pierce. On Binary Methods, Iowa State
University, technical report #95-08a, December 1995.
[Castagna] Castagna, Giuseppe. Object-Oriented
Programming: A Unified Foundation, Birkauser, Boston,
ISBN: 0-8176-3905-5, 1997.
[MultiJava] Clifton, Curtis, Gary T. Leavens, Craig
Chambers, and Todd Millstein. "MultiJava: Modular
Open Classes and Symmetric Multiple Dispatch for
Java", OOPSLA 2000 Conference Proceedings: ACM
SIGPLAN Notices, vol. 35, no. 10, October 2000, pp.
130-145.
69 The use of OO methods typically leads to the creation of Integral 2.3.3.2.1
many small methods which are physically distributed (Traceability) requirements-based
over a large number of classes. This, and the use of testing
dynamic dispatch, can make it difficult for developers to
trace critical paths through the application during design
and coding reviews.
70 The difference between dead and deactivated code is not Development 2.3.2.4.1 identifying
always clear when using OOT. Without good Integral dead and deactivated
traceability, identifying dead vs. deactivated code may be (Traceability) code
difficult or impossible.
71 When a design contains abstract base classes, portions of Development 2.3.2.4.1 identifying
the implementations of these classes may be overridden dead and deactivated
in more specialized subclasses, resulting deactivated code
code.
72 Traceability is made more difficult because there is often Integral 2.3.3.4.3 tracing
a lack of OO methods or tools for the full software (Traceability) through OO views
lifecycle.
73 Formal specification languages are generally accessible Planning 2.3.1.2 requirements
only to those specially trained to use them. To make methods and
formal specifications accessible to developers and the notations
authors of test cases, we must map such formal
specifications to natural language and/or other less formal
notations (e.g. UML). There, however, is currently no
well defined means of doing so. This issue applies to both
preliminary and detailed design.
74 Change impact analysis may be difficult or impossible Integral 2.3.3.3.2
due to difficulty in tracing functional requirements (Configuration configuration control
through implementation. Management)
2-36
Volume 2

75 Limitations of UML may limit how non-functional and Planning 2.3.1.2 requirements
cross-cutting requirements of realtime, safety critical, methods and
Development
distributed, fault-tolerant, embedded systems are captured notations
in UML and traced to the design, implementation, and
test cases.
76 Configuration management may be difficult in OO Integral 2.3.3.3.1
systems, causing traceability problems. If the objects and (Configuration configuration
classes are considered configuration items, they can be Management) identification
difficult to trace, when used multiple times in slightly
different manners.
77 What is “low level requirements” for OO? Affects how Planning 2.3.1.1 defining life
we do low-level testing. If we don’t know what low-level cycle data
requirements are, we don’t know the appropriate level of
testing.
* High level = WHAT
* Low level = HOW
Related to issue raised in tools session – relation be
between artifacts.
Should be addressed in the Handbook.
78 Addressing derived requirements for OO – how does this Planning 2.3.1.2 requirements
happen? How is it different than traditional and how does methods and
it tie up to the safety assessment. Not really unique for notations
OO.
Will be addressed when we do the artifact mapping.
79 Difficult to identify individual atomic requirements in Planning 2.3.1.2 requirements
OO. UML tends to group requirements in a graphical methods and
format. Would complicate matters if considered derived. notations
For derived requirements, the entire graph would be
passed to the safety folk for evaluation of safety impact.
80 Lower levels of decomposition may not be possible for Planning 2.3.1.2 requirements
some requirements (e.g., performance requirements). methods and
Development
Levels of abstraction may be different than traditional. notations
81 Are there unique challenges for source to object code Integral 2.3.3.1.4 source to
traceability in non-Level A systems? Where should this (Verification) object code
be addressed? Multiple tools and ways of addressing s- traceability
to-o traceability? (not really new)
Beyond what DO-178B requires. More of a “DO-178C”
issue. Out of scope for the Handbook. Is UML the
“source code” for OO?
2-37
Volume 2

82 Is there another “class” of tool qualification for visual Additional 2.3.4.3 tool
modeling tools to demonstrate the integrity of these tools? Considerations qualification
Not necessarily automating a step, but are looking to
make sure the tool is doing what you want. How to
ensure consistency of the tools (validating the tool)?
How to validate the tool when changes occur?
Typically part of the tool selection process. Concern
seems to be addressed by Handbook mod.
83 Auto-test and code generation tools – what are the Additional 2.3.4.3 tool
concerns when a single tool generates code and test from Considerations qualification
the same model? The concern is with the independence –
same input and same tool.
Already covered by DO-178B. Not necessarily OO-
specific, but may be more prevalent with OO tools. Need
to be addressed in some other document or forum.
84 Maintaining tool environment, archives, … when licenses Additional 2.3.4.2 tool
are involved is not clear. May need to have some kind of Considerations environments
“permanent license” to support safety and continued
airworthiness of the aircraft.
OO more dependent on tools, but not necessarily an OO-
specific issue.
85 Maturity/long-term support of tools. Tool manufacturers Additional 2.3.4.2 tool
may not realize the long-life need of tools. Is this a Considerations environments
higher risk in the OO environment? Education for both
the tool and aviation communities to understand the
specific needs for tool manufacturers and aircraft
manufacturers.
Not necessarily OO-specific, but might be more prevalent
with OO.
86 Are there other types of OO tools that need to be Additional 2.3.4.2 tool
addressed? Need to anticipate other classes of tools that Considerations environments
may come onto the scene. E.g., traceability tool for OO,
transformation tools, CM tools, refactoring tools (tool to
restructure source code to meet new requirements),
87 How does OO life cycle data map to the DO-178B Planning 2.3.1.1 defining life
section 11 life cycle data? E.g., What “source code” cycle data
mean in OO? What is req, design, code? Transition from
text-based to model-based artifacts.
*** May need to clarify this up front in the handbook,
when making the tie between DO-178B and the
handbook.
2-38
Volume 2

88 Configuration management and incremental development Integral 2.3.3.3.2
of OO projects and tools. When CM comes into play (Configuration configuration control
during the development process may be different than our Management)
current practices, when using an UML tool. Doing more
iterations in OO. How to “get credit” on iterations. Not
necessarily OO-specific, but might be more prevalent
with OO because of the multiple iterations.
89 Is dynamic dispatch compatible with DO-178B required Integral 2.3.3.1.1 flow
forms of static analysis? Mention that dynamic dispatch (Verification) analysis
hinders some forms of static analysis including (see DO-
178B section 6.3.4f). Tools can treat this if complete
closure exists. DO-178B requires complete closure. In
cases of incomplete closure, need to define ways to
implement.
90 Fundamental pre-requisite language issues need Development 2.3.2.1.1 type
clarification prior to adopting LSP and DBC. How can substitutability
LSP be implemented using available languages?
Strongly consider a language subset that is amenable to
use of LSP and DBC. Concern is how far to take this
subset.
91 Inconsistent Type Use (ITU): Development 2.3.2.1.2 inconsistent
type use
When a descendant class does not override any inherited
method (i.e., no polymorphic behavior), anomalous
behavior can occur if the descendant class has extension
methods resulting in an inconsistent inherited state.
92 State Definition Anomaly (SDA): Development 2.3.2.2.2 overriding
If refining methods do not provide definitions for
inherited state variables that are consistent with
definitions in an overridden method, a data flow anomaly
can occur.
93 State Definition Inconsistency (SDIH): Development 2.3.2.2.2 overriding
If an indiscriminately-named local state variable is
introduced, a data flow anomaly can result.
94 State Defined Incorrectly (SDI): Development 2.3.2.2.2 overriding
If a computation performed by an overriding method is
not semantically equivalent to the computation of the
overridden method wrt a variable, a behavior anomaly
can result.
95 Indirect Inconsistent State Definition (IISD): Development 2.3.2.1.1 type
When a descendent adds an extension method that defines substitutability
an inherited state variable, an inconsistent state definition
can occur.
96 Anomalous construction behavior (ACB1): Development 2.3.2.2.2 overriding
If a descendant class provides an overriding definition of
a method which uses variables defined in the
descendant’s state space, a data flow anomaly can occur.
2-39
Volume 2

97 Anomalous construction behavior (ACB2): Development 2.3.2.2.2 overriding
If a descendant class provides an overriding definition of
a method which uses variables defined in the ancestor’s
state space, a data flow anomaly can occur.
98 Incomplete construction (IC): Development 2.3.2.3.2
If the constructor does not establish initial state initialization
conditions and the state invariants for new instances of a
class, then a state variable may have in incorrect initial
value or a state variable may not have been initialized.
99 State Visibility Anomaly (SVA): Development 2.3.2.2.2 overriding
When private state variables exist, if every overriding
method in a descendant class doesn’t call the overridden
method in the ancestor class, a data flow anomaly can
exist.
100 When using OO tools to develop software requirements, Additional 2.3.4.3 tool
design and implementation, it is beneficial to work at the Considerations qualification
visual model level, especially when using UML. When
working with OO tools, configuration management might
be done at the modeling level (i.e., diagrams). This may
cause a concern when the OO tools can introduce subtle
errors into the diagrams.
101 Current visual modeling tools that are used for OO Additional 2.3.4.1 tool
development make use of frameworks for automatic code Considerations capability
generation, replacing tedious programming tasks.
Frameworks may include patterns, templates, generics,
and classes in ways requiring new verification
approaches. The tool’s framework may or may not
enforce requirements, design and coding standards.
102 Current visual modeling tools that are used for OO Additional 2.3.4.1 tool
development provide a capability to generate source code Considerations capability
directly from UML models. Most of the existing UML
tools today can use visual modeling diagrams to construct
models and generate source code from these models. The
level of source code generation depends on the tool and
on the user of the tool. It is unclear how such tools may
be used in aviation projects.
103 The current structural coverage tools available may not Additional 2.3.4.1 tool
“be aware” or have visibility to the internals of inherited Considerations capability
methods and attributes and polymorphic references
supported with dynamic binding such that they can
provide a reliable measurement of the structural coverage
achieved by the requirements-based testing.
104 Class hierarchies can become overly complex, which Integral 2.3.3.4.2 complexity
complicates traceability. Generalization, weak (Traceability)
aggregation, strong aggregation, association and
composition are some of the relations that can be used to
create the class diagrams.
2-40
Volume 2

105 Iterative development is often desired in OO Integral 2.3.3.4.4 iterative
implementation. Each iterative cycle has its own (Traceability) development
requirements (normally a set of Use Cases), design,
implementation, and test. There is a risk of losing
traceability when using iterative development. This can
be caused by adding or changing requirements, design, or
implementations.
106 Reusability is one of the objectives of OO development, Development 2.3.2.4.1 identifying
but reusable components may be hard to trace because dead and deactivated
they are designed to support multiple usages of the same code
component. Reusable components may also have
functionality that may not be used in every application.
107 If polymorphism and dynamic binding are implemented, Integral 2.3.3.1.3 timing and
this can cause the stack size to grow, making it difficult to (Verification) stack analysis
analyze the optimal stack size.
2-41
Volume 2
Appendix C Additional Considerations for Project Planning

In an early phase of the OOTiA project, several pitfalls identified by Webster in Pitfalls of Object-Oriented
Development were proposed as helpful considerations in planning an OO program. These pitfalls were not identified
through the data collection process as part of the OOTiA program, but were thought by the FAA to be useful.
Because Webster’s book is out of print, a number of ideas from the book are described below.
C.1 Conceptual Pitfalls

Going object-oriented for the wrong reasons:
There are “many more misunderstood, misguided, or just downright bad reasons for going object-oriented” [31].
These include (but are not limited to): wanting to cut back on development staff, thinking OOT will significantly
reduce the need for testing, thinking that your project can be completed five to ten times faster using OOT, thinking
the use of OOT will reduce project risk, and wanting to be able to build future products simply by plugging software
components together.
Thinking objects will solve all problems: As Fred Brooks has declared, and experience has repeatedly shown, there
is no “silver bullet” to slay the problems associated with software development. A variety of techniques are needed.
OOT can be a significant part of this process, but it will not (in and of itself) resolve most of the problems. Also,
OOT does not come for free (in terms of the need for experience, training, and tools).
Allowing new features to creep (or pour) in: The temptation to add new features certainly isn’t unique to the use of
OOT. The problem is that OOT (by isolating likely future changes) makes it easier to introduce such features. To
avoid related problems, new features should generally be introduced only in new increments, as part of a planning
process that takes into account cost and schedule.
C.2 Analysis and Design Pitfalls

Pouring new wine into old bottles (or vice versa): Problems can arise when OO and non-OO approaches are mixed
with regard to development of the same software. For instance, a classic approach to analysis and design may be
implemented using OOT techniques. Or, an object-oriented analysis and design may be implemented without
support for classes, class hierarchies, etc. In both cases, the result is often objects that resemble “slightly intelligent
data structures, or procedural libraries” [31], and problems representing the relationships between classes. It is far
better to divide an application into subsystems that either use or do not use OOT, then integrate the overall software
system using wrappers to provide the needed subsystem interfaces in the proper style.
C.3 Class and Object Pitfalls

Confusing subtyping with association: There are two basic relationships between classes. The subtyping
relationship (inheritance) indicates that all instances of one class are logically instances of another. For example, an
Airspeed Tape is a subtype of Tape, a GPS Sensor is a subtype of Sensor, etc. This relationship requires that we
follow appropriate rules for subtyping. An association (often implemented using pointers) specifies that an instance
of one class is linked to some number of instances of another class. For example, a car has an engine and is owned
by some person. An engine is not logically a type of car, nor is a person. Relationships between cars, engines, and
owners may also change at run-time. Although the distinction between these two types of relationships seems
obvious, novice OO developers often confuse the two, or misuse implementation inheritance to represent
associations. This leads to problems, typically discovered during testing, that are far easier to avoid than to correct.
Converting non-object code straight into objects: Developers with no object-oriented experience are used to
treating data and functions (processes) separately. Data is organized into records or structures that may be linked via
references or pointers. Functions are decomposed into smaller functions that perform a subset of the steps required
by their parent. OOT combines the data oriented and function oriented approaches, organizing the program around
collections of data (records) and the sets of functions that manipulate them. “Developers new to OO sometimes
2-42
Volume 2
extend their former approaches in a one-sided fashion. For example, they may take a data structure, turn it into a
class, define methods to access (get and set) the data fields, and leave it at that. The resulting class is little more than
a cumbersome version of the original data structure, with no intelligence or behavior built into it. On the process
side, developers may take a set of functions and turn them into methods of a single class, possibly with few no data
members.” [31] Both represent a misuse of OO principles, and lead to poor designs.
C.4 Verification Pitfalls

Neglecting component testing: Although it is possible to take a subsystem or system level testing approach to an
OO system, there are advantages to testing individual components. These components may be individual classes or
larger units (assemblies of classes representing libraries or subsystems). They, however, should correspond to
reusable entities. Testing at this level makes it easier to enforce the principles of Design by Contract [23], makes it
easier to “inherit” test cases, and makes it possible to deliver individual components, their test cases, documentation,
etc. as a single package.
C.5 Reuse Pitfalls

Having or setting unrealistic expectations: OOT is often sold on promises related to reuse. Reuse, however, is not
easy, and is not free. It comes at a cost (in terms of analysis and design) that many organizations are unwilling to
pay. It also may only make economic sense if the organization plans to build three or more additional systems that
are closely related to one another (form a product family), or if an individual component or subsystem can be reused
at least three times.
Being too focused on code reuse: “The most important creation to come from an OOT project is often the
architecture and the design, not the code implementation.” [31] This is true because these artifacts are typically more
general, and more easily applied to new systems and new applications.
2-43
Volume 3: Best Practices

Revision 0
October 26, 2004

technology
NOTE: This(OOT).
Handbook does This Handbook
not constitute isAdministration
Federal Aviation not to be used
(FAA) policyas a standalone
or guidance, nor is it product
but, rather, as input when considering issues in a project-specific context.
3-1
Volume 3
Contents
3.1 INTRODUCTION ........................................................................................................................................ 3-1
3.1.1 Purpose.............................................................................................................................................. 3-1
3.1.2 Organization ...................................................................................................................................... 3-1
3.2 MAPPING OF VOLUME 2 ISSUES TO VOLUME 3 GUIDELINES .................................................................... 3-2
3.2.1 Key Concerns/Issues Addressed by the Guidelines............................................................................ 3-2
3.3 SINGLEINHERITANCEANDDYNAMICDISPATCH....................................................................................................... 3-11
3.3.1 Purpose............................................................................................................................................ 3-11
3.3.2 Background...................................................................................................................................... 3-11
3.3.3 Overall Approach ............................................................................................................................ 3-13
3.3.4 Inheritance with Overriding ............................................................................................................ 3-14
3.3.5 Method Extension ............................................................................................................................ 3-17
3.3.6 Subtyping ......................................................................................................................................... 3-18
3.3.7 Formal Subtyping ............................................................................................................................ 3-19
3.3.8 Unit Level Testing of Substitutability............................................................................................... 3-21
3.3.9 System Level Testing of Substitutability Using Assertions............................................................... 3-22
3.3.10 System Level Testing of Substitutability Using Specialized Test Cases ...................................... 3-24
3.3.11 Class Coupling............................................................................................................................ 3-26
3.3.12 Deep Hierarchy........................................................................................................................... 3-28
3.4 MULTIPLE INHERITANCE ....................................................................................................................... 3-29
3.4.1 Purpose............................................................................................................................................ 3-29
3.4.2 Background...................................................................................................................................... 3-29
3.4.3 Overall approach............................................................................................................................. 3-29
3.4.4 Multiple Interface Inheritance ......................................................................................................... 3-30
3.4.5 Multiple Implementation Inheritance............................................................................................... 3-31
3.4.6 Mixed Multiple Inheritance ............................................................................................................. 3-32
3.4.7 Combination of Distinct Abstractions.............................................................................................. 3-33
3.4.8 Top Heavy Hierarchy....................................................................................................................... 3-34
3.5 TEMPLATES ........................................................................................................................................... 3-36
3.5.1 Purpose............................................................................................................................................ 3-36
3.5.2 Background...................................................................................................................................... 3-36
3.5.3 Source Code Review ........................................................................................................................ 3-36
3.5.4 Requirements-Based Test Development, Review, and Coverage ..................................................... 3-37
3.5.5 Structural Coverage for Templates.................................................................................................. 3-37
3.6 INLINING ............................................................................................................................................... 3-39
3.6.1 Purpose............................................................................................................................................ 3-39
3.6.2 Background...................................................................................................................................... 3-39
3.6.3 Inlining and Structural Coverage .................................................................................................... 3-39
3.6.4 Source Code Review of Inlined Code............................................................................................... 3-40
3.7 TYPE CONVERSION ................................................................................................................................ 3-41
3.7.1 Purpose............................................................................................................................................ 3-41
3.7.2 Background...................................................................................................................................... 3-41
3.7.3 Overall Approach ............................................................................................................................ 3-41
3.7.4 Source Code Review, Checklist, and Coding Standards.................................................................. 3-41
3.7.5 Loss of Precision in Type Conversions ............................................................................................ 3-42
3.7.6 Type Conversions of References and Pointers................................................................................. 3-43
3.7.7 Language Specific Guidelines.......................................................................................................... 3-43
3.8 OVERLOADING AND METHOD RESOLUTION .......................................................................................... 3-44
3.8.1 Purpose............................................................................................................................................ 3-44
3.8.2 Background...................................................................................................................................... 3-44
3.8.3 Code Review Method ....................................................................................................................... 3-44
3-ii
Volume 3
3.8.4 Implicit Conversion ......................................................................................................................... 3-45

3.9 DEAD AND DEACTIVATED CODE, AND REUSE ....................................................................................... 3-46
3.9.1 Purpose............................................................................................................................................ 3-46
3.9.2 Background...................................................................................................................................... 3-46
3.9.3 Reuse of Software Components........................................................................................................ 3-47
3.9.4 Requirements Traceability ............................................................................................................... 3-48
3.9.5 Certification Credit for Reused but Modified Class Hierarchy ....................................................... 3-49
3.9.6 Changes in the Status of Deactivated Code Versus Actively Used Code ......................................... 3-50
3.9.7 Service History Credit and Deactivated Code ................................................................................. 3-50
3.10 OBJECT-ORIENTED TOOLS .................................................................................................................... 3-52
3.10.1 Purpose ....................................................................................................................................... 3-52
3.10.2 Background ................................................................................................................................. 3-52
3.10.3 Traceability When Using OO Tools ............................................................................................ 3-52
3.10.4 Configuration Management When Using Visual Modeling Tools............................................... 3-52
3.10.5 Visual Modeling Tools Frameworks ........................................................................................... 3-53
3.10.6 Automatic Code Generators........................................................................................................ 3-53
3.10.7 Structural Coverage Analysis Tools............................................................................................ 3-55
3.10.8 Structural Coverage Analysis for Inheritance............................................................................. 3-55
3.10.9 Structural Coverage Analysis for Dynamic Dispatch ................................................................. 3-55
3.11 TRACEABILITY ...................................................................................................................................... 3-57
3.11.1 Purpose ....................................................................................................................................... 3-57
3.11.2 Background ................................................................................................................................. 3-57
3.11.3 Overall Approach and Related DO-178B Objectives ................................................................. 3-57
3.11.4 Tracing to Functional Requirements........................................................................................... 3-58
3.11.5 Complex Class Hierarchies and Relationships ........................................................................... 3-59
3.11.6 OO Design Notation and Traceability Ambiguity....................................................................... 3-60
3.11.7 Traceability and Dynamic Binding/Overriding .......................................................................... 3-60
3.11.8 Dead and Deactivated Code ....................................................................................................... 3-60
3.11.9 Many-to-Many Mapping of Requirements to Methods................................................................ 3-61
3.11.10 Iterative Development ................................................................................................................. 3-61
3.11.11 Change Management for Reusable Components ........................................................................ 3-61
3.12 STRUCTURAL COVERAGE ...................................................................................................................... 3-63
3.12.1 Purpose ....................................................................................................................................... 3-63
3.12.2 Background ................................................................................................................................. 3-63
3.12.3 Overall Approach and Related DO-178B Objectives ................................................................. 3-63
3.12.4 Structural Coverage of Inheritance ............................................................................................ 3-63
3.12.5 Polymorphism with Dynamic Dispatch....................................................................................... 3-66
3.12.6 Data Coupling and Control Coupling......................................................................................... 3-68
3.13 REFERENCES ......................................................................................................................................... 3-70
3.14 INDEX OF TERMS ................................................................................................................................... 3-72
APPENDIX A FREQUENTLY ASKED QUESTIONS (FAQS)................................................................... 3-74
APPENDIX B EXTENDED GUIDELINES AND EXAMPLES .................................................................. 3-76

B.1 SINGLE INHERITANCE ............................................................................................................................ 3-76
B.1.1 Extension of the Inheritance with Overriding Guidelines................................................................ 3-76
B.1.2 Extension of the Method Extension Guidelines................................................................................ 3-80
B.2 MULTIPLE INHERITANCE ....................................................................................................................... 3-82
B.2.1 Composition involving multiple inheritance .................................................................................... 3-82
B.2.2 Extended guidelines ......................................................................................................................... 3-88
B.3 DEAD AND DEACTIVATED CODE, AND REUSE ....................................................................................... 3-90
B.3.1 Deactivated Code Example.............................................................................................................. 3-90
B.3.2 Hierarchy Changes and Method Overriding ................................................................................... 3-91
3-iii
Volume 3
Figures
Figure 3.4-1 Combination of Distinct Abstractions ................................................................................................ 3-33
Figure 3.10-1 Code Generation using Visual Modeling Tools................................................................................ 3-54
Figure 3.11-1 Overview of Traceability .................................................................................................................. 3-59
Figure 3.12-1 Inheritance........................................................................................................................................ 3-64
Figure 3.12-2 Concrete Coverage ........................................................................................................................... 3-65
Figure 3.12-3 Context Coverage ............................................................................................................................. 3-66
Figure 3.12-4 Flattened Inheritance ....................................................................................................................... 3-67
Figure 3.12-5 Dynamic Dispatch ............................................................................................................................ 3-67
Tables
Table 3.2-1 Mapping of Key Concerns and Guidelines........................................................................................... 3-11
Table 3.12-1 Hierarchical Incremental Testing Summary ...................................................................................... 3-64
3-iv
Volume 3
3.1 Introduction
Volume 3 identifies some of the currently known best practices for the implementation of object-oriented
technology (OOT) in aviation. These “best practices” are called “guidelines” throughout this volume. Developers of
OOT software are the target audience for this volume, as are certification authorities and designees who evaluate
airborne software. OOT in embedded and safety-critical systems is still an evolving discipline; best practices will
likely be added and modified in the future revisions of this Handbook. In any case, the OOT standards and methods
the developer intends to use should be documented in the project plans and standards, and presented to the
certification authorities as early as possible in the project.
3.1.1 Purpose
The purpose of this volume is to identify best practices to safely implement OOT in aviation by providing some
guidelines to address the key concerns and issues documented in Volume 2. The guidelines presented in this volume
are not necessarily the only way to address these issues. There may also be other means that are effective, and the
Handbook may itself define alternative ways to resolve a given issue. In some areas, this volume does not provide
best practices but, rather, cites areas of ongoing research that should be monitored by prospective OOT developers.
Such areas of research occur most notably in the areas control and data coupling, and structural coverage analysis as
applied to OOT in aviation. In all cases, it should be noted that it is still the developer’s responsibility to
demonstrate that the OOT methods and processes they have selected to utilize can, and will, provide the appropriate
integrity for safe software implementation.
3.1.2 Organization
This volume is organized as follows: Section 3.1 introduces Volume 3 and provides the purpose and layout of the
document. Section 3.2 provides a mapping from the key concerns and issues in Volume 2 to the guidelines (best
practices) in Volume 3. Sections 3.3 through 3.12 provide background and guidelines for each of the following
technical areas:
Single Inheritance and Dynamic Dispatch (section 3.3)
Multiple Inheritance (section 3.4)
Templates (section 3.5)
Inlining (section 3.6)
Type Conversion (section 3.7)
Overloading and Method Resolution (section 3.8)
Dead And Deactivated Code, And Reuse (section 3.9)
Object-Oriented Tools (section 3.10)
Traceability (section 3.11)
Structural Coverage (section 3.12)
Section 3.13 lists the references used in Volume 3. Section 3.14 provides an index of terms to assist users of the
volume. Appendix A provides nine frequently asked questions (FAQs) and their answers regarding the use of OOT
and this Handbook. Appendix B contains some extended guidelines and examples that support the Handbook.
3-1
Volume 3
3.2 Mapping of Volume 2 Issues to Volume 3 Guidelines

3.2.1 Key Concerns/Issues Addressed by the Guidelines
Table 3.2-1 below provides a mapping between the key concerns with associated issues in Volume 2 and the
Volume 3 guidelines that address them. The first column provides the concerns from Volume 2 in a question format,
along with the Volume 2 references that explain the concern. The second column provides a reference to the issues
submitted on the web site (included in Appendix B of Volume 2). This column is provided for completeness; it also
helps those who submitted issues to see the guidelines that address their concerns. The third column provides the
reference to Volume 3 guidelines that address the specific concern. Footnotes are provided when an explanation of
the mapping (the manner in which the guidelines address a particular concern or a specific issue) is required.
When Volume 3 provides alternative ways to address a key concern, more than one row appears in the Guidelines
column opposite the key concern in the table. The key concern can then be addressed by following the guidelines
listed in any one of these rows. That is, only one guideline of those listed (separated by OR) needs to be followed to
address the concern. Most of the concerns raised in Volume 2 have identified best practices, as can be seen from the
mapping table. However, there are some areas where specific guidelines are not provided in Volume 3. There are
three reasons for why a concern may not be addressed: (1) it is not specific to OOT; (2) it is an area of active
research where no guidelines currently exist; or (3) it is a concern not categorized in Volume 2 (in this case, the
issue is listed for completeness, but no reference to Volume 2 is provided).
Key Concern (from Volume 2) Issue List # Guidelines (in Volume 3)

Volume 2, section 2.3.1.1 77, 87 Sections 3.10.3, 3.11.4.1, and 3.11.6.1
How does the life cycle data from an OO
development process map to the life
cycle data specified in DO-178B?
Volume 2, section 2.3.1.2 63, 75, 78, 79, 80 Sections 3.10.3, 3.11.5.1, 3.11.6.1, and 3.11.9.1
Are OO approaches adequate to define IL 78 and IL 80 may not be completely addressed
all types of requirements? in Volume 3.
Specifically, can we capture all
nonfunctional requirements of interest?
And can we avoid problems associated
with graphical grouping?
Volume 2, section 2.3.1.2 73 Not addressed in Volume 3.
A well-defined means to map formal
specifications to natural language and/or
other less formal notations (e.g. UML) is
needed to make formal specifications
generally accessible.
Volume 2, section 2.3.1.3 38, 58 Other issue list entries on multiple interface and
multiple implementation inheritance may
Have language features such as multiple elaborate on the underlying issues that motivate
inheritance been evaluated carefully in IL 38.
the planning process?
IL 38 and IL 58 may not be completely addressed
And have appropriate restrictions been in Volume 3.
established, documented, and followed?
3-2
Volume 3

Volume 2, section 2.3.2.1.1 17, 22, 23, 42, 90, Section 3.3.4.3, Simple overriding rule,
95
Is subtyping used to improperly define Section 3.3.4.3, Complete initialization rule,
types that are not substitutable for their
parent types? Section 3.3.4.3, Initialization dispatch rule,
Section 3.3.4.3, Accidental override rule,
Section 3.3.4.3, Simple dispatch rule,
Section 3.3.6.3,
Section 3.3.7.3 (optional), and
Section 3.3.8.3
OR
Section 3.3.4.3, Simple overriding rule,
Section 3.3.4.3, Complete initialization rule,
Section 3.3.4.3, Initialization dispatch rule,
Section 3.3.6.3,
Section 3.3.7.3, and
Section 3.3.9.3
OR
Section 3.3.6.3,
Section 3.3.10.3
Volume 2, section 2.3.2.1.2 91 Same as guidelines to address Volume 2, section
2.3.2.1.1 concern (above).
How do we ensure that new methods
defined by a subclass do not introduce
anomalous behavior by producing a state
inconsistent with that defined by the
superclass?
Volume 2, section 2.3.2.2.1 7, 10, 15, 21, 24, Section 3.3.12.3,
25, 27, 28, 29, 30,
How do we ensure that the developer’s 33, 37 Section 3.4.4.3,
intent is always clear when using OO
features such as multiple inheritance, Section 3.4.5.3,
and when creating very deep inheritance Section 3.4.6.3, and
hierarchies?
Section 3.4.8.3
3-3
Volume 3

OR
Section 3.3.12.3,
Section 3.4.4.3,
Section 3.4.6.3,
Section 3.4.8.3
Note: In addition, the following section identifies
an area of active research related to the
developer’s understanding of data and control
coupling between inherited methods: Section
3.12.6.1.
Volume 2, section 2.3.2.2.2 20, 31, 92, 93, 94, Section 3.3.4.3, Simple overriding rule,
96, 97, 99
How do we avoid errors associated with Section 3.3.4.3, Accidental override rule,
the unintentional/accidental overriding of
methods? Section 3.3.4.3, Simple dispatch rule,
Section 3.3.5.3,
Section 3.3.6.3,
Section 3.3.8.3
OR
Section 3.3.5.3,
Section 3.3.6.3,
Section 3.3.9.3
3-4
Volume 3

OR
Section 3.3.5.3,
Section 3.3.6.3,
Section 3.3.10.3
Volume 2, section 2.3.2.2.2 60 Sections 3.8.3.2 and 3.8.4.2
How do we avoid the confusion and
human error associated with the
definition of overloaded operations that
have the same name but different
semantics?
Volume 2, section 2.3.2.3.1 66 Issue is not specific to OOT.
Traditional allocation and deallocation Not addressed in Volume 3.
algorithms may be unpredictable in terms
of their worst-case memory use and
execution times, resulting in
indeterminate execution profiles.
Volume 2, section 2.3.2.3.2 19, 98 Section 3.3.4.3, Complete initialization rule,
How do we ensure that subclass Section 3.3.4.3, Initialization dispatch rule,
methods are not called by superclass
constructors before all the attributes of Section 3.3.5.3, and
the subclass have been initialized? Section 3.3.12.3
Volume 2, section 2.3.2.4.1 70, 71, 106 Sections 3.11.8.1, 3.9.4.2, and 3.11.11.1
How do we identify dead and deactivated
code in OOT programs and reusable
components?
Volume 2, section 2.3.2.4.2 1, 57 Sections 3.9.3.2, 3.11.8.1, and 3.11.11.1
How do we ensure that deactivated code
is properly addressed when working with
general purpose libraries and
frameworks?
Volume 2, section 2.3.3.1.1 2, 9, 16, 43, 56, 89 Section 3.3.4.2, assumption 3,
Dynamic dispatch, polymorphism, Section 3.3.4.3, Simple dispatch rule,
multiple implementation inheritance, and
inlining may complicate data and control Section 3.4.5.3,
flow analysis. Section 3.6.3.2, and
Section 3.10.9.2
3-5
Volume 3

OR
Section 3.3.4.2, assumption 3,
Section 3.4.7.3,
Section 3.10.9.2
Note: In addition, the following section identifies
an area of active research: Section 3.12.6.1.
Volume 2, section 2.3.3.1.2 5, 11, 48, 49, 55 Section 3.3.4.2, assumption 3,

How do we account for dynamic dispatch Section 3.3.4.3, Simple dispatch rule,
and the run-time classes of objects when
measuring the structural coverage of Section 3.3.6.3,
object-oriented program? Substitutability compliance rule,
and
Section 3.3.8.
OR
Section 3.3.6.3, Substitutability compliance rule,
and
Section 3.3.9.
OR
Section 3.3.6.3, Substitutability compliance rule,
and
Section 3.3.10.
Volume 2, section 2.3.3.1.2 45, 47, 52 Sections 3.5.5.1.2, 3.5.5.3.2, and 3.6.3.2
How do we measure structural coverage
when inlining and templates are used?
Volume 2, section 2.3.3.1.3 3 , 107 Section 3.3.4.3, Dispatch time rule
How do we avoid problems related to
timing analysis when using dynamic
dispatch?
Volume 2, section 2.3.3.1.3 44, 50, 53 Sections 3.5.3.3, 3.5.4.3, and 3.6.3.2
How do we avoid problems related to
timing analysis when using inlining,
templates, and macro expansion?
Volume 2, section 2.3.3.1.4 6, 8, 12 Section 3.3.4.3, Object code traceability rule
3-6
Volume 3

How do we provide source to object code
traceability when using dynamic
dispatch?
Volume 2, section 2.3.3.1.4 81 Source to object code traceability is not required
by DO-178B for non-level A systems.
traceability in non-level A systems? Not addressed on Volume 3.
Volume 2, section 2.3.3.1.4 46 Section 3.6.3.2
traceability when using inlining?
Volume 2, section 2.3.3.1.4 59 Sections 3.7.4.2, 3.7.5.2, and 3.7.6.2
How do we provide source to object code Note: Above sections focus on type conversion
traceability when using implicit type and do not specifically address performance and
conversion? timing issues (IL 59) nor source to object code
traceability (vol. 2, section 2.3.3.1.4).
Volume 2, section 2.3.3.2.1 62 Sections 3.5.4.3, 3.9.4.2, and 3.11.4.1
How is functional coverage of low level
requirements determined?
How do we ensure adequate
requirements coverage at all levels of
integration when the number of test
cases may be excessively large?
Volume 2, section 2.3.3.2.2 4, 18 Section 3.3.4.3, Simple overriding rule,
To what extent can/should test cases Section 3.3.4.3, Complete initialization rule,
developed for a class be reused to test
its subclasses? Section 3.3.4.3, Initialization dispatch rule,
Section 3.3.4.3, Simple dispatch rule, Section
3.3.6.3,
Section 3.3.7.3 (optional),
Section 3.11.7.1
OR
Section 3.3.6.3,
Section 3.3.7.3,
Section 3.11.7.1
3-7
Volume 3

OR
Section 3.3.6.3,
Section 3.3.7.3 (optional)
Section 3.11.7.1
Volume 2, section 2.3.3.3.1 76 Sections 3.10.4.2 and 3.11.11.1
How do we define unique configuration
items in OOT systems?
Volume 2, section 2.3.3.3.2 34, 74, 88 Sections 3.4.4.3, 3.10.4.2, 3.11.4.1, 3.11.10.1,
and 3.11.11.1
How do OO tools and modeling
languages affect the way configuration OR
items are managed and changed?
Sections 3.4.5.3, 3.10.4.2, 3.11.4.1, 3.11.10.1,
and 3.11.11.1
OR
Sections 3.4.6.3, 3.10.4.2, 3.11.4.1, 3.11.10.1,
and 3.11.11.1
OR
Sections 3.4.7.3, 3.10.4.2, 3.11.4.1, 3.11.10.1,
and 3.11.11.1
Volume 2, section 2.3.3.4.1 61, 69 Section 3.3.4.3, Simple overriding rule,
How do we ensure traceability between Section 3.3.4.3, Complete initialization rule,
functional requirements and object-
oriented implementations? Section 3.3.4.3, Initialization dispatch rule,
Section 3.8.4.2,
Section 3.9.4.2,
Section 3.11.9.1
Volume 2, section 2.3.3.4.2 13, 35, 104 Section 3.3.4.2, assumption 3,
How do we ensure traceability when Section 3.3.4.3, Simple dispatch rule,
constructing inheritance hierarchies?
Section 3.11.5.1,
Section 3.11.7.1
3-8
Volume 3

OR
Section 3.4.4.3,
Section 3.4.5.3,
Section 3.4.6.3
Section 3.11.5.1,
Section 3.11.7.1
OR
Section 3.3.4.3, Simple dispatch rule, Mis en forme
Section 3.4.4.3,
Section 3.4.6.3,
Section 3.4.7.3,
Section 3.11.5.1,
Section 3.11.7.1
Volume 2, section 2.3.3.4.3 72 Sections 3.10.3 and 3.11.6.1
How do we deal with behavioral
requirements that map to multiple
graphical views in OOT models?
How do we maintain traceability when
using an iterative development process
that leads to a large number of changes
to a large number of artifacts?
Volume 2, section 2.3.4.1 101, 102 Sections 3.10.4.2, 3.10.5.2, and 3.10.6.3
How can we ensure that visual modeling
tools support compliance with DO-178B
without introducing additional verification
burden?
Volume 2, section 2.3.4.1 103 Sections 3.10.7, 3.10.8.2, and 3.10.9.2
How can we ensure that structural
coverage tools provide a reliable
measurement of the structural coverage
achieved?
Volume 2, section 2.3.4.2 86 Issue is not specific to OOT.
Considering the rapid rate of tool Not specifically addressed in Volume 3; however,
evolution and new tool types, how will the known type of tools for which best practices
tools be identified and maintained to have been identified were addressed in Section
meet long-term needs for development
3-9
Volume 3

and maintenance? 3.10.
Volume 2, section 2.3.4.2 84, 85 Issues are not specific to OOT.
Considering the rapid rate of tool Not addressed in Volume 3.
evolution and new tool types, how can
we ensure that tools are properly
controlled and retrievable?
Volume 2. section 2.3.4.3 83 Issue is not specific to OOT.
How is tool qualification assured to Not addressed in Volume 3.
address, for example, tool validation,
independence, configuration
management?
Volume 2. section 2.3.4.3 82, 100 Sections 3.10.5.2 and 3.10.4.2
How can we ensure that tool qualification
criteria are appropriately identified and
applied to OO tools?
Not categorized in Volume 2 26 Section 3.3.3
IL 26: Inheritance can be abused by
using it as a “kind of code-sharing macro
to support hacks without regard to the
resulting semantics”.
Not categorized in Volume 2 40 Not addressed in Volume 3.
IL 40: Reliance on programmer specified
optimizations of the inheritance hierarchy
(invasive inheritance) is potentially error
prone and unsuitable for safety critical
applications.
Not categorized in Volume 2 51 Section 3.5.5.1.2
IL 51: Nested templates, child packages
(Ada), and friend classes (C++) can
result in complex code and hard to read
error messages on many compilers.
IL 54: The use of templates can result in
code bloat. Many C++ compilers cause
object code to be repeated for each
instance of a template of the same type.
IL 65: Could there be security concerns
related to the use of COTS based OOT
solutions? Particularly with respect to
field loadable software, security risks
have been mitigated by the unique
architectures of most current systems.
IL 67: Most OO languages use reference
semantics for passing objects (e.g. Java
only supports reference semantics; C++
3-10
Volume 3

also supports passing by value but this is
rarely used and cannot be used when
dynamic binding is required). This results
in variables being aliased to each other.
It is difficult to analyse the effect of this
aliasing on program behaviour because
many tools do not allow for the possible
presence of aliasing. It is also easy for a
developer to inadvertently use a shallow
copy or equality operation where the
required semantics can only be achieved
by a deep copy or equality operation.
Not categorized in Volume 2 68 Due to lack of mainstream languages that support
multiple dispatch, guidelines developed to
IL 68: The selection of the code to address this issue were dropped from the
implement an operation may depend Handbook after OOTiA Workshop #2.
upon more than just the run-time type of
the target object. In cases involving Not addressed in Volume 3.
binary mathematical operations, for
instance, this choice typically depends
on the run-time types of both arguments.
As explained in [Bruce et al.], [Castagna]
and [MultiJava], this (and other related
situations) are not handled well by most
current OO languages. (A.k.a. "Binary
methods problem")
Table 3.2-1 Mapping of Key Concerns and Guidelines
3.3 Single Inheritance and Dynamic Dispatch
3.3.1 Purpose
This section provides guidelines for the safe implementation and use of single inheritance and dynamic dispatch
(also known as dynamic binding) in projects that use object-oriented (OO) technology.
3.3.2 Background
Inheritance. Inheritance supports the organization of object-oriented systems in terms of classes and class
hierarchies. This is a fundamental concept that permits OO systems to directly represent and classify objects
representing real-world entities from the problem domain without introducing redundancy.
Classes. Classes may define a variety of elements, including operations (which specify the services provided by the
class), methods (which provide the code to implement operations), attributes (which represent stored data values),
and associations (representing references to other objects).
Visibility. Class elements may be restricted in terms of their visibility. Unified Modeling Language (UML) [4], for
instance, distinguishes between elements that are visible to all clients that have access to the class itself (public
access), elements that are visible to clients within the same package (package access), and elements that are
accessible only to subclasses (protected access). Elements may also be accessible to both classes in the same
package and to subclasses (e.g., in Java), or to a named set of classes (e.g., in Eiffel).
Operations. Operations accessible to classes other than the defining class and its subclasses are sometimes referred
to as client operations. All operations are identified by their signatures. The signature of an operation consists of its
3-11
Volume 3
name and a list of the types of its parameters – the information needed to match a call to the operation being called.
Consider the UML definition of an operation “m (p: Integer, q: Float)”. The signature of this operation consists of its
name “m” and its parameter types “Integer” and “Float”. In some languages, the return parameter (if any) is
considered a part of the signature, while in others (such as C++) it is not.
Most OO languages support constructors and destructors. A constructor is an operation called by the run-time
environment when a new object is allocated to ensure it is properly initialized. Conversely, a destructor is an
operation called by the run-time environment when an object is deallocated to ensure any resources held by the
object are released. In most OO languages, a class may define more than one constructor, each with its own
signature. The constructor called by the run-time environment is the one that matches the arguments supplied by the
program at the point it requests the allocation of a new object. Destructors typically have no parameters and, as a
result, at most one destructor is associated with a class.
Constraints. Class definitions may also include constraints in the form of pre-conditions, post-conditions, and
invariants. Pre-conditions represent constraints that must hold at the time a given method is called. Post-conditions
represent constraints that are guaranteed to hold once execution of the method completes, provided its pre-
conditions were first met. Invariants represent constraints that are established by the class constructor and are
considered to be a part of the pre-condition and post-condition of every client operation. Additional constraints may
also apply to the relationships between classes. Constraints may be used to specify safety predicates as well as
conditions for correctness, and acceptable use.
Class hierarchies. Class hierarchies consist of classes connected via generalization relationships. In such a
relationship, the more general of the classes is termed the superclass, while the more specialized class is termed the
subclass. The relationship itself is also referred to as subclassing or subtyping.
The class hierarchy may be extended to any depth, although very deep class hierarchies may cause difficulties.
Subclasses inherit the elements of their superclasses. Subclasses may also extend these superclass definitions to
include additional elements they define themselves, or redefine elements by overriding their inherited definitions.
Single inheritance allows each class to have at most one immediate superclass, while multiple inheritance permits a
class to have more than one immediate superclass. Interface inheritance involves the inheritance of only interface
elements (such as operation specifications and constraints), while implementation inheritance involves the
inheritance of implementation elements (such as methods, attributes, and associations).
Polymorphism. In most object-oriented languages, an object is permanently assigned a run-time class at the point at
which it is allocated and initialized. Although the run-time class of the object never changes, the object can be
treated not only as a member of its run-time class, but also as a member of any superclass of this class. This ability
to treat an object as a member of any of its superclasses is referred to as polymorphism. Polymorphism supports the
replacement of general implementations with more specialized ones. It, however, requires strict adherence to
subtyping rules that guarantee that instances of subclasses behave like instances of their superclasses.
Substitutability. The basic subtyping rules are those given by Liskov and Wing [7]. Because they guarantee that we
can substitute an instance of a subclass for an instance of a superclass, they are often collectively referred as the
Liskov Substitution Principle (LSP). Although the term LSP was not used by the authors [7], it has become a
convenient way to refer to the principles required to guarantee substitutability and will be used in such context to
discuss inheritance issues. The subtyping rules have also been popularized by Bertrand Meyer [17][18] in terms of a
contracting metaphor between the clients of a class and its implementation.
In contracting terms, the client is responsible for establishing the pre-condition of an operation before calling it.
Given this pre-condition, the method that implements the operation is then responsible for either delivering on the
post-condition, or reporting an error to the client. The class invariant is established by the constructor when the
object is first created, and must be maintained by all client operations. As a result, it is considered to be a part of the
pre-condition and the post-condition of every client operation. The class invariant, however, need not hold at all
points during the execution of a client operation, only at the beginning and at the end. This is sufficient to ensure
that temporary violations of the invariant are not observable by clients if data is encapsulated and calls to client
operations are properly synchronized.
3-12
Volume 3
Substitutability requires, quite simply, that subclasses not break the contract between client and implementation
established by their superclasses. This applies both to the redefinition of one operation by another operation and the
implementation of an operation by a method. As a result, the pre-condition of an operation in the subclass must be
weaker (demand less) or the same as the pre-condition of the same operation in the superclass. Conversely, the post-
condition must either be stronger (deliver more) or the same. Viewed in this way, substitutability requires that we
not demand more of clients, i.e., the types of input parameters must be either be made more general or left
unchanged, and that we deliver at least as much as promised, i.e., the types of output parameters must either be made
more specific or left unchanged.
With regard to errors, the subclass version of an operation can only report the same types of errors as its superclass
version. Otherwise, clients would be expected to handle error cases that were not part of the original contract.
Substitutability also applies to changes to the signatures of operations introduced in subclasses. In this regard, the
types of an operation’s input parameters are logically a part of its pre-condition. Similarly, the types of an
operation’s output parameters (and any return parameter type) are logically a part of its post-condition. In most OO
languages, dynamic dispatch is used to associate a method with a call based on the run-time type of the target object.
Dynamic dispatch is not related to dynamic linking or dynamic link libraries, nor is it any more dynamic than the
use of a case statement to explicitly select a method based on the run-time type of the target object.
Dynamic dispatch. Method selection based only on the type of the target object is referred to as single dispatch
(since it involves only consideration of the run-time class of the object, i.e., a single parameter). In a few OO
languages, method selection also includes the run-time classes of the remaining parameters. This is referred to as
multiple dispatch [14]. The methods considered for selection are referred to as multi-methods. Languages that
support multiple dispatch are more flexible in terms of the overriding of methods than single dispatch languages and
able to deal more elegantly with issues such as the binary methods problem [12][13]. Analogous to single dispatch,
multiple dispatch is logically equivalent to the use of a series of nested case statements for method selection.
Issues and guidelines. A number of issues arise when using single inheritance and dynamic dispatch that may make
compliance with DO-178B difficult. Volume 2 documents key concerns and related issues and Volume 3 associates
these concerns and issues with some applicable guidelines. Guidelines assume that all source code is available for
software developed to meet DO-178B levels A, B, and C. In general, these “guidelines” do not represent new
“guidance”, but an interpretation of existing guidance (DO-178B) with respect to the use of particular OO features.
The “rules” associated with these guidelines are also rules only in the sense that they must be followed in order to
adopt the given approach. Often there are also alternative approaches that can be followed in order to address the
same issues and still comply with DO-178B.
3.3.3 Overall Approach

This section is intended to provide an approach for addressing DO-178B objectives when using OO features related
to single inheritance and dynamic dispatch. The issues list appearing in Volume 2 specifies potential obstacles to
DO-178B compliance. This list is not intended to address only OO unique issues, but also related issues that are of
particular importance to the use of single inheritance and dynamic dispatch.
Where it appears possible to use a feature or combination of features in a way that complies with DO-178B, we have
provided guidelines that describe an associated approach. The existence of these guidelines, however, does not
constitute a recommendation that the feature(s) be used.
The overall collection of guidelines is also intended to be open-ended. As a result, new approaches and new
guidelines may be added that address the same issues as existing approaches, under different circumstances.
The guidelines on Inheritance with Overriding (see section 3.3.4) address the core issues related to inheritance,
overriding and dynamic dispatch. Because all these features are closely related, they are addressed together, rather
than separately. In addition, the rules apply both to redefinition of one operation by another and the implementation
of an operation by a method where operation and method are defined using UML 1 [4]. The emphasis is on simplicity
1
Use of UML is not a requirement. Users are free to choose their own approach to modeling and OO development.
3-13
Volume 3
through the strict enforcement of a small set of basic principles, an approach similar to that taken by Meyer with
respect to Eiffel [18].
Note that, there may be some situations in which it is entirely reasonable to use inheritance to support code sharing
without intending to achieve type substitutability. The aim is usually to achieve aggregation with export of methods
(and possibly attributes) from the aggregated class(es). The problem is that most OO programming languages do not
distinguish this form of inheritance from subtyping inheritance (or provide a mechanism for aggregation with export
of features). Inheritance should be used for this purpose only when it is documented and the use of polymorphism
and dynamic dispatch in respect of these classes is avoided.
The guidelines on Subtyping (see section 3.3.6) and Formal Subtyping (see section 3.3.7) complement those on
Inheritance with Overriding (see section 3.3.4) by specifying how to test for superclass/subclass compatibility.
Several different approaches are possible. The simplest involves unit level testing and the inheritance of unit level
test cases, as in the guidelines for Unit Level Testing of Substitutability (see section 3.3.8). For organizations that
want to do all testing at a system level, two approaches are provided. The guidelines for System Level Testing of
Substitutability Using Assertionsinvolve instrumentation of the code with assertion checks. The guidelines for
System Level Testing of Substitutability Using Specialized Test Cases (see section 3.3.10) involve the development
of specialized versions of system level test cases for this purpose.
Note that, although the subtyping guidelines address compliance from a behavioral perspective, inheritance involves
both classification and implementation, and the valid use of inheritance need not be limited to subtyping (although it
often is, e.g., by UML).
The remaining guidelines address special cases and individual issues. The guidelines on Method Extension (see
section 3.3.5) deal with the definition of a subclass method as an extension of an inherited version of the same
method. It applies most often to constructors, but can be used to extend the implementation of any method.
The guidelines on Class Coupling (see section 3.3.11) address concerns related to flow analysis between superclass
and subclass definitions. They recommend the definition of an abstract interface between a class and its subclasses
analogous to the client interface for the class.
The guidelines on Deep Hierarchy (see section 3.3.12) provide a rule to help identify class hierarchies that are “too
deep”. Unlike the rules associated with the other guidelines, this is intended only as a rule of thumb. Engineering
judgment is required to balance the tradeoffs associated with any proposed changes.
3.3.4 Inheritance with Overriding

This section provides a set of guidelines on the use of inheritance, overriding, and dynamic dispatch which are
equivalent to the use of hand-coded dispatch using case statements or compound if statements. When these
guidelines are extended to include behavioral subtyping, they provide explicit criteria to verify substitutability.
These guidelines assume the use of languages that support single dispatch on the target object.
3.3.4.1 Motivation
The unrestricted use of dynamic dispatch raises a number of issues with respect to certification, especially with
regard to weakly typed languages, and systems that permit the run-time loading of new classes (that are not a part of
a previously verified system configuration). With suitable language restrictions (i.e., a precisely defined language
subset that permits use of static analysis techniques), dynamic dispatch is semantically equivalent to the use of hand-
coded dispatch methods containing nested case statements or compound if statements. The automation of dynamic
dispatch by the compiler is then equivalent to the auto-generation of these dispatch routines and inlined calls to
them. This treatment as an inlined call, combined with compliance with structural coverage criteria identified in
Sections 3.10 and 3.12 of this volume, provides a means to ensure compliance with DO-178B.
3.3.4.2 Applicability
These guidelines assume:
3-14
Volume 3
1. a strongly typed language,

2. single dispatch,
3. the set of classes associated with the system is statically known,
4. no dynamic classification (i.e., the run-time class of an object never changes), and
5. use of polymorphism.
3.3.4.3 Guidelines
The following rules define a form of inheritance, overriding, and dynamic dispatch which is equivalent to hand-
coded dispatch using case statements or compound if statements:
Simple overriding rule: An operation may redefine an inherited operation, and a method may implement an
operation so long as changes to its signature guarantee substitutability. Specifically, a redefined operation may be
made more visible to clients. And, a redefining operation or implementing method may be made more restrictive
regarding the types of errors it can report to clients (e.g., as exceptions or by setting error return codes). With
regard to parameter types, an operation may override an inherited operation or a method may implement an
operation by supertyping its input parameters, or subtyping its return type or the types of output parameters. The
types of parameters that represent both inputs and outputs must remain unchanged (invariant). No other form of
overriding should be allowed for languages supporting only single dispatch.
Accidental override rule: To ensure that overriding is always intentional rather than accidental, design and code
inspections should consider whether locally defined features are intended to override inherited features with a
2, 3
matching signature .
Simple dispatch rule: When an operation is invoked on an object, a method associated with the operation in its run-
time class should be executed. This rule applies to all calls except explicit calls to superclass methods, which
should be addressed as described by the Method Extension guidelines (see section 3.3.5).
Complete initialization rule: Every attribute must be initialized to a value consistent with the class invariant by the
class constructor.
Initialization dispatch rule: No overridden method should be called during the initialization (construction) of an
object.
Dispatch time rule: All dispatch times should be bounded and deterministic
Object code traceability rule: Everywhere concerns about source code to object code traceability and timing
analysis dictate, the compiler vendor may be asked to provide evidence of deterministic, bounded mapping of the
dispatched call. If the evidence is not available from the compiler vendor, it may be necessary to examine the
structure of the compiler-generated code and data structures (e.g., method tables) at the point of call.
A dispatching method call is considered semantically equivalent to the invocation of a dispatching routine
containing a case statement of the form:
case of <target-object-run-time-class>
case <class>:
<statically-resolved-call-to-method-implemented-by-class>;
...
end
2
When the language itself does not allow the user to make the intent to override an inherited operation/method explicit.
3
As defined in the Glossary, a feature is an attribute, operation, or method. This includes attributes that reference other objects (i.e., association
ends).
3-15
Volume 3
Each case of this case statement handles dispatch to an implementation of the method by the target object’s declared
type or one of its subclasses, i.e., the class corresponding to the object’s run-time type.
With regard to the Simple overriding rule, the inability to subtype the types of input parameters does not preclude
the use of overloading for this purpose. The developer, however, must clearly understand that the selection of an
overloaded method is based on the declared types (rather than the run-time types) of the arguments at the point of
call.
In accordance with the Simple dispatch rule, method calls are expected to be dispatching. 4 Dispatch must account
for the run-time type of the target. Static resolution is regarded as an optimization in those cases where only one
resolution is possible.
Note: The Initialization rule is not intended to be an obstacle to the creation of “reset” operations that can be called
by clients to reinitialize on object after it has been constructed, or to the sharing of initialization code with class
constructors. It suggests only that the client reset operation (which has the class invariant as a part of its pre-
condition) and the constructors (which do not) call a non-overridden, internal operation that performs the
initialization steps common to them all.
The Simple overriding rule ensures substitutability is not violated at the language level, in terms of method
declarations. The Subtyping guidelines (see section 3.3.6) extend this to include testing for substitutability at the
behavioral level. Compliance with substitutability is necessary if instances of subclasses are to be treated as
instances of their superclasses 5. This is not only required by the UML definitions of generalization and inheritance,
but a fundamental assumption underlying the use of polymorphism and dynamic dispatch. Verification of
substitutability for the most critical software can be can be shown in one of two ways: (1) by testing each case at
each call site (when dynamic dispatch is only rarely used) or (2) by conforming to the Subtyping guidelines (see
section 3.3.6) (more practical for software where dynamic dispatch is more widely used).
The Accidental override rule is intended to guard against errors that could occur in languages that assume that a
subclass feature, including attributes, operations and methods [19], can override a superclass feature that has a
matching signature. This rule is unnecessary if the language forces the developer to explicitly state that overriding is
intended (as in C#).
The Simple dispatch rule is intended to support a model of object-oriented behavior in which (1) each class can be
completely understood by looking at it in flattened form, and (2) the behavior of any object can be completely
understood by looking at the flattened definition of its run-time class. The Simple dispatch rule guarantees this even
when the declared type of the object is a superclass of its run-time class (i.e., when polymorphism is used).
The Initialization rule is intended to avoid errors that may arise during the construction of an object when a subclass
version of a method is called before associated subclass attributes have been initialized and the subclass invariant (if
any) has been established. In particular, the class invariant is implicitly a part of the pre-condition and post-condition
of every client operation, and the class invariant is not guaranteed to be true until the constructor completes. As a
result, overridden client operations should not be called during object construction. For similar reasons, special care
should also be taken with respect to calls to client operations in destructors, and at other points where the class
invariant may no longer hold.
4
In OOT languages such as Ada 95, C++, and Java, binding occurs when the application is built, not at execution time. Only in languages such as
Smalltalk and Common Lisp is dynamic binding truly dynamic (execution time). In the other languages mentioned dynamic dispatch is no more
dynamic than a case statement, i.e., all alternatives are statically determined. As a result, the developer should avoid languages such as Smalltalk
and Lisp for avionics applications.
5
State Visibility Anomaly (SVA): Per the example given in [19], B::m() must be compatible with both A::m() and C::m(). When introducing a
method B::m() that both overrides a method A::m() and is overridden by another method C::m(), compatibility must be compatible in both
directions.
3-16
Volume 3
3.3.4.4 Related guidelines

The guidelines on Overloading and Method Resolution (see section 3.8) are closely related to those given in this
section because both overriding and overloading define families of operations whose specifications should be related
by principles guaranteeing substitutability.
The guidelines on Top Heavy Hierarchy (see section 3.4.8) provide metrics to limit the complexity of inheritance
hierarchies.
The Subtyping (see section 3.3.6) guidelines extend those appearing in this section to include the testing of
substitutability at the behavioral level.
The guidelines on Method Extension (see section 3.3.5) provide the sole exception to the Simple dispatch rule in Mis en forme
section 3.3.4.3.
Section B.1.1 of Appendix B provides some language specific examples of the Inheritance with Overriding
guidelines.
3.3.5 Method Extension

Method Extension supports the implementation of an operation as an extension of an inherited method without
introducing redundancy, and with the assurance that the resulting post-condition is stronger than or the same as that
in the superclass. It helps to address issues related to initialization by allowing a subclass constructor to be defined
as an extension of its parent class constructor, without introducing problems related to the use of dynamic dispatch
during initialization.
3.3.5.1 Motivation
Often we want to provide a subclass version of an operation that extends the functionality provided by the operation
in its superclass. This extension in functionality must be consistent with substitutability. As a result, the pre-
condition for the subclass operation must be weaker than or the same as its pre-condition in the superclass, and the
post-condition for the subclass operation must be stronger than or the same as its post-condition in the superclass.
By implementing an extended operation in terms of an explicit call to the superclass method, preceded or followed
by additional code, we are able to:
• avoid repeating the code appearing in the superclass method,
• provide code before the call to handle the additional cases implied by a weaker pre-condition 6, and
• provide code after the call that adds to its effect, as implied by a stronger post-condition.
Such explicit calls to superclass methods are by their nature statically bound, and do not involve dynamic dispatch.
The code that follows the call to the superclass method must not undo its effects in order for the overall post-
condition to be an extension of that for the superclass.
These guidelines are commonly applied to constructors, which begin by calling the constructor for the superclass,
then initialize all the attributes defined by the class itself. It may also be used to select between competing inherited
versions of a method (multiple implementation inheritance).
6
Weakening the pre-condition makes it valid to call an operation with additional inputs or input combinations. Consider the operation f(p:
Integer) pre p > 0. If we weaken the pre-condition to give us f(p: Integer) pre p ≥ 0., then the implementation must handle the additional case in
which p is zero.
3-17
Volume 3
3.3.5.3 Guidelines
The following rule for method extension represents the sole exception to the Simple dispatch rule given in section
3.3.4.3:
Method extension rule: When extending the functionality of an inherited method, the subclass method should
explicitly call the superclass version of the same method.
Note that the terms method and operation are used in accordance with the UML definitions (see Glossary in Volume
1) since some languages blur the distinction. Implementation of method extension in different target languages is
described in Appendix B.1.2.

The guidelines on Method Extension represent the sole exception to the Simple dispatch rule given in section
3.3.4.3.
3.3.6 Subtyping
The Subtyping guidelines extend the Inheritance with Overriding guidelines (see section 3.3.4) (which addresses
substitutability at a language level in terms of operation signatures) in order to verify compliance with
substitutability at a behavioral level.
3.3.6.1 Motivation
DO-178B verification activities may involve testing (at either a unit or system level), the use of formal or informal
proofs, or other techniques. This section does not prescribe a particular approach. That is left to those sections that
extend the basic guidelines given in this section.
Intuition can be misleading when it comes to subtyping relationships. We might, for instance, think (intuitively and
mathematically) that all squares are rectangles, so Square should be a subclass of Rectangle. Whether Square should
be a subclass of Rectangle, however, should not be based on our intuition, or any mathematical definition, but on the
interfaces we define for these classes. If the interface for Square specializes the interface for Rectangle in
accordance with substitutability, then it is appropriate for it to be a subclass of Rectangle. Otherwise, it is not [11].
By assuming that instances of subclasses must always be substitutable for instances of their superclasses, these
guidelines restrict the pre-conditions and post-conditions of redefined operations in addition to their signatures.
Formally, the pre-condition for a redefined operation must be weaker than or the same as the pre-condition of the
operation it redefines. Conversely, the post-condition for a redefined operation must be stronger than or the same as
the post-condition of the operation it redefines.
In terms of the client interface, this means that a subclass is compatible with a superclass if we:
(1) expect no more of clients than we do in the superclass (the pre-conditions of overridden operations are weaker
or the same), and
(2) deliver at least as much (the post-conditions of overridden operations are stronger or the same).
The same rules apply to the relationship between methods and the operations they implement: the pre-condition for
an implementing method must be weaker than or the same as the pre-condition of the operation it implements, and
the post-condition for an implementing method must be stronger than or the same as the post-condition of the
operation it implements.
Note that in real-time systems, the deadline by which a method must complete may be treated as part of the post-
conditions. If it is important to know up-front in system development that timing constraints are met, then every
implementation must be required to meet its respective timing bound. Otherwise, when complete closure exists, the
3-18
Volume 3
system as a whole must be tested to ensure it meets its required bounds. In a broader sense, post-conditions can
address other quality of service (QOS) issues in addition to timing constraints.
These guidelines apply when instances of different subclasses may be assigned (polymorphically) to a given variable
or parameter.
3.3.6.3 Guidelines
The guidelines in this section extend those on Inheritance with Overriding (see section 3.3.4) to include the
following additional rules.
Minimum compatibility rule: At a minimum, superclass/subclass compatibility should be verified with respect to all
classes involved in the polymorphic assignment of different subclass instances to the same variable or parameter
during the execution of the system.
Substitutability compliance rule: Any approach used to verify superclass/subclass compatibility should be
consistent with the principles of behavioral subtyping defined by Liskov and Wing [7].
As specified by UML, the semantics of subclassing implies superclass/subclass compatibility in accordance with
substitutability. In practice we must, at a minimum, ensure that we verify this in all cases where instances of
different subclasses may be associated with the same variable or parameter during the execution of the system under
test.
Additional guidelines are defined by a number of sections that extend these basic guidelines. These guidelines vary
with the approach used to verify superclass/subclass compatibility. The standard for superclass/subclass
compatibility, however, is the same: compliance with the principles of behavioral subtyping defined by [7].

Related guidelines include those for Formal Subtyping (see section 3.3.7).
Mis en forme
The Subtyping guidelines extend the Inheritance with Overriding guidelines (see section 3.3.4), as described above.
3.3.7 Formal Subtyping

The Formal Subtyping guidelines apply the principles of Design by Contract [17] with formally defined pre-
condition/post-conditions and invariants. By requiring formal specification of the classifiers to be checked in a pre-
condition/post-condition/invariant style, these assertions can, then, be used to either generate the needed test cases,
or as the basis for analysis and formal proofs. Providing a complete and precise specification of the interface also
helps prevent errors by making the contract between the clients and implementers of a class explicit, makes it easier
to enforce rules for substitutability, and supports the traceability of high-level requirements to low-level
requirements.
3.3.7.1 Motivation
The signature of an operation, which includes its name, parameter types, result types (if any), and errors (if any),
provides clues to the operation’s behavior but, by itself, is insufficient. Comments that describe the purpose of the
operation and the relationships between inputs, outputs, and errors are also helpful. But most comments are
informal, cannot be processed by tools, and lack the precision to serve as a basis for analysis, proofs, or the
development of test cases.
As a result, it is generally recommended that class interfaces be specified in a pre-condition/post-condition/invariant
style (an approach referred to by Meyer as ‘Design by Contract’). Expressing low-level requirements in this way
3-19
Volume 3
helps prevent errors by making the semantics of the interface clear to developers before client code is written. Such
specifications can also be processed by tools and used as a basis for analysis, formal proofs, and the generation of
test cases. This, in turn, supports reverification and regression testing in response to changes to the class introduced
in order to comply with other guidelines.
It is also useful to specify global data access and information flow relations as part of an operation’s contract. While
these are not as strong as the recommended pre-condition/post-condition/invariant style, they can be efficiently
checked and also used as the basis for analysis, formal proofs, and the generation of test cases.
These guidelines apply when instances of different subclasses may be assigned (polymorphically) to a given variable
or parameter.
3.3.7.3 Guidelines
The guidelines in this section extend those on Subtyping (see section 3.3.6) to include the following rules:
Explicit pre/post-condition/invariant rule: To ensure that all classes define their interfaces as contracts, all pre-/post-
conditions and invariants for operations and methods must be explicitly stated and all errors returned by them must
be specified. Unless the program is to be subjected to automated formal analysis, this includes pre-/post-
conditions, invariants, and lists of reported errors/exceptions that are considered to be trivial (e.g., conditions
whose value is true, and error lists that are empty).
Frame condition rule: Unless the language provides a separate mechanism for indicating which variables may and
may not change, ideally each post-condition should also include a ‘frame condition’ which indicates which variables
are guaranteed not to change as a result of executing the operation/method.
Software developers tend to rely on testing to verify substitutability. While associated test cases may be developed
at either the system or the unit level, the development of test cases alone, however, has its limitations. Test cases are
no substitute for a complete, precise specification of behavior, which is needed by the clients of a class, and by
developers seeking to subclass an existing class.
A complete and precise specification of behavior is also needed in order to develop the test cases for a class and to
provide traceability from high level to low level requirements. As a result, it is generally recommended that class
interfaces be specified in a pre-condition/post-condition/invariant style (an approach referred to by Meyer as
‘Design by Contract’). This style provides the basis to make compliance with substitutability easier and helps avoid
errors by making contracts between clients and classes explicit. In addition, explicit statement of pre/post-condition
and invariants can be used to generate unit level test cases, or can be used as the basis for formal analysis and
proofs.
Realistic implementation of these guidelines requires the use of an unambiguous programming language and
application of static analysis techniques.

Related guidelines include those for Unit Level Testing of Substitutability, System Level Testing of Substitutability
Using Assertions, and System Level Testing of Substitutability Using Specialized Test Cases (see sections 3.3.8,
3.3.9, and 3.3.10, respectively).
Mis en forme
As mentioned above, the Formal Subtyping guidelines extend the guidelines on Subtyping (see section 3.3.6).
3-20
Volume 3
3.3.8 Unit Level Testing of Substitutability

The guidelines in this section check for superclass/subclass compatibility by requiring that all unit level test cases
(i.e., low-level test cases) associated with a class are inherited by its subclasses. These guidelines help address the
same issues as those defined for Subtyping (see section 3.3.6).
3.3.8.1 Motivation
The verification of superclass/subclass compatibility is straightforward if we develop a set of unit level test cases for
Mis en forme
all classes identified by the Minimum compatibility rule (see section 3.3.6.3).
Subtype compatibility then means that all superclass test cases should run successfully against all subclass instances
(superclass test cases are inherited by subclasses) provided that all such tests satisfy the method pre-condition(s)
involved, taking account of any dynamic dispatch involved in evaluating the pre-condition. Subclasses also often
extend this set of superclass test cases to include their own more specialized tests (the subclass test set is a superset
of the superclass test set).
These guidelines apply when concerns exist about compatibility between specific classes, and test cases are written
to directly test these classes. Typically, this applies to low-level requirements. These guidelines should be applied to
situations where instances of different subclasses may be assigned at run-time to a variable or parameter whose
declared type is an associated superclass (polymorphic assignment).
In contrast to other Subtyping guidelines (see section 3.3.6), the guidelines in this section are most effective when
the development organization relies on a combination of system level and class level testing, rather than on system
level testing (i.e., requirements-based testing) alone. Separate sections address System Level Testing for
Substitutability (see the guidelines for System Level Testing of Substitutability Using Assertions and System Level
Testing of Substitutability Using Specialized Test Cases, sections 3.3.9 and 3.3.10, respectively).
3.3.8.3 Guidelines
The guidelines in this section extend those on Subtyping (see section 3.3.6) to include the following rules which
apply to all classes identified by the Minimum compatibility rule in section 3.3.6.3:
Inherited test case rule: Every test case appearing in the set of test cases associated with a class should appear in
the set of test cases associated with each of its subclasses.
Separate context rule: If dynamic dispatch is involved in the execution of a method, the method should be
separately tested in the context of every concrete class in which it appears, irrespective of whether it is defined by
the class or inherited by it, provided that all such tests take account of the method pre-condition(s) involved, taking
account of any dynamic binding involved in evaluating the pre-condition. An exception is made for methods that are
guaranteed not to directly or indirectly invoke a method that is dynamically bound with respect to the current object,
for example, simple get and set methods that only assign a value to, or return the value of an attribute or
association. Such methods need only be tested once, in the context of the defining class.
These rules are intended to imply that all inherited test cases (other than those for simple gets and sets) should be run
against instances of all concrete subclasses. As a result, changes to the code inherited by a class that affect its
flattened form should result in its retest precisely as if the class itself had been edited.
The Inherited test case rule is intended to apply to all test cases, including those introduced solely to meet structural
coverage criteria. It could be argued that such tests should only be inherited when the tested code is also inherited. It,
however, seems simpler and safer to recommend that they be inherited in all cases, since they should pass when run
against the subclass.
3-21
Volume 3
When applying the Inherited test case rule, if the subclass invariant is stronger than that of its superclass, then a
check of this invariant (rather than the weaker superclass invariant) should be a part of the pass/fail check of each
inherited test case. In this way, issues associated with overriding are avoided.
The Separate context rule is intended to ensure that superclass methods are separately tested in the context of each
subclass. This recommendation addresses the fact that even when a given method is inherited without change, the
methods called by it may be overridden in the subclass, leading to a different behavior. An exception is made for
methods that are guaranteed not to directly or indirectly invoke a method that is dynamically bound with respect to
the current object, for example simple get and set methods that reference only data, and do not call other methods. A
more complete impact analysis could be used to determine whether other inherited methods need to be retested in
the context of each subclass. The guidelines in this section, however, assume it is simpler and easier to rerun such
tests than to perform such an analysis.
Note that testing in accordance with these guidelines will ensure that all dispatch table entries are exercised at some
call site, equivalent to providing MC/DC of the case statement assumed to be associated with the dispatch routine.
Although not required to use these guidelines, it is recommended that class interfaces be specified in a pre/post-
condition style prior to writing test cases (an approach referred to by Meyer [17] as ‘Design by Contract’).
Expressing low-level requirements in this way helps prevent errors by making the semantics of the interface clear to
developers before client code is written. Pre- and post- conditions may be specified in a variety of ways (e.g., as
informal comments, as formal annotations, in table form, in terms of a state diagram, or in terms of executable run-
time checks used by a test driver). Such pre- and post- conditions may also be useful as input to test case generation
tools.
Although these guidelines typically apply to the testing of low-level classes and requirements, they can be used at a
high-level if the classes and subclasses to be tested for compatibility represent a software system or a subsystem. For
example, given a class System with subclasses SystemA and SystemB, SystemA and SystemB should inherit the test
cases defined for System (which are based on the high-level requirements common to both of them).

Related guidelines include those for System Level Testing of Substitutability Using Assertions (see section 3.3.9),
System Level Testing of Substitutability Using Specialized Test Cases (see section 3.3.10), and Percolation (see
pages 882-896 of [11]).
As stated above, these guidelines extend the Subtyping guidelines (see section 3.3.6).
3.3.9 System Level Testing of Substitutability Using Assertions

The guidelines for System Level Testing of Substitutability Using Assertions check for superclass/subclass
compatibility by instrumenting a version of the software with assertion checks related to substitutability. Existing
system level test cases (i.e., requirements-based test cases) are then run (without change) against this version (to test
for substitutability violations), then run a second time against the uninstrumented target version of the software.
These guidelines help address the same issues as those for Subtyping (see section 3.3.6).
3.3.9.1 Motivation
Some projects prefer to focus exclusively on system level testing (i.e., requirements-based testing) without
developing any unit level/class level test cases. Use of the Unit Level Testing of Substitutability (see section 3.3.8) is
clearly in conflict with this approach. A number of programming languages and tools, however, support the selective
use of pre- and post- condition and invariant declarations as run-time checks. One particularly simple way to test for
substitutability at a system level is to take advantage of the use of these checks to verify superclass/subclass
compatibility for classes identified by the Minimum compatibility rule (see section 3.3.6.3). This does not involve
any substantial changes to existing system level, requirements based tests. It does, however, require that these tests
be run against both an instrumented and uninstrumented version of the software.
3-22
Volume 3
These guidelines apply when concerns exist about the substitutability of various subclasses for one another at run-
time and requirements-based test cases are written to test these configurations. Typically, the test cases are based on
high-level requirements.
Although these guidelines typically apply to the testing of high-level requirements at a system level, they can also be
applied at a subsystem level, in terms of low-level or derived requirements. These guidelines differ from those for
the Unit Level Testing of Substitutability (see section 3.3.8) in that test cases are written against some entity (e.g.,
system or subsystem) that contains instances of the classes we wish to test for compatibility, and not directly against
these classes.
Use of these guidelines is straightforward if a project already instruments the code to measure structural coverage, or
is already defining interfaces as contracts [17], [18, Design by Contract]. These, though, are not prerequisites.
The guidelines, however, do assume that system level test cases have been developed (or will be developed) to test
for all system configurations in which instances of various subclasses may be substituted for one another at run-
time. (Development of these test cases should be driven by high-level requirements related to substitutability).
Substitutability related assertions require language or tool support.
As with the instrumentation of code for any reason (e.g., measurement of structural coverage), care should be taken
to account for the overhead associated with the run-time checks involved, e.g., timing may be affected. It is also
necessary to consider what should be done if any of the conditions (pre-, post-, and invariant) are violated (i.e.,
handling of exceptions needs to be accounted for).
3.3.9.3 Guidelines
The guidelines in this section extend those for Subtyping (see section 3.3.6). The following rules describe the type
of assertion checks required to test for superclass/subclass compatibility in accordance with substitutability. Such
checks should be performed on all classes identified by the Minimum compatibility rule (see section 3.3.6.3).
Pre-condition assertion rule: An assertion to check the operation’s pre-condition should appear before the body of
all methods that implement a public operation. In accordance with substitutability, this pre-condition may only be
weakened or the same in overridden versions of the operation.
Post-condition assertion rule: An assertion to check the operation’s post-condition should appear after the body of
all methods that implement a public operation. In accordance with substitutability, this post-condition may only be
strengthened or the same in overridden versions of the operation.
Invariant assertion rule: An assertion to check the operation’s invariant should be a part of the pre-condition
check and the post-condition check of all public operations. In accordance with substitutability, the invariant may
only be strengthened or the same in all subclasses of a class.
Instrumented/uninstrumented testing rule: A test case run against an instrumented version of the code should be
considered to pass only if all assertion checks associated with substitutability hold during its execution. A test case
run against an uninstrumented version of the code should be considered to pass only if it produces the same result
that it did when run against an instrumented version of the same code.
The first three rules echo the basic principles of substitutability. Some languages (such as Eiffel [17][18]) enforce
these rules directly and provide facilities for enabling and disabling associated run-time checks, as required for
instrumented/uninstrumented testing. In other languages (such as C++ and Java), it is possible to use language level
assertions to achieve the same effect, although the substitutability relations between pre-conditions, post-conditions
and invariants must be enforced by code reviews. A subset of the language that is amenable to use of substitutability
and that will help static analysis should strongly be considered.
3-23
Volume 3
A simple way in which to ensure that these relations hold is to require that:
• new pre-conditions be of the form ‘overridden_ pre or some _condition’,
• new post-conditions be of the form ‘overridden_post and some_condition’, and
• new subclass invariants be of the form ‘superclass_invariant and some_condition’.
Otherwise the pre-condition, post-condition, or invariant must be the same.

Tool support is also available from a number of sources. Usually this includes enforcement of the first three rules,
and a facility for enabling and disabling the use of assertions as run-time checks (analogous to Eiffel). Assertions
may be written in a number of notations, ranging from simple Boolean expressions in the target language to first
order logic [20], with quantification.
Assertions may also be introduced at an analysis or design level and mapped down to run-time checks in the target
language. Many tools that favor this approach, however, rely on proofs for verification, rather than the introduction
of run-time checks.
Binder discusses the instrumentation of the code with substitutability run-time assertion checks in detail (with
examples and sample code) in his Percolation pattern (see pages 882-896 of [11]).
Not all assertion checks should necessarily be removed in the uninstrumented version of the code. In accordance
with the advice of Liskov and Guttag, “it is usually worthwhile to retain at least the inexpensive checks” [8, p. 251].

Related guidelines include those defined for Percolation (see pages 882-896 of [11]), Unit Level Testing of
Substitutability (see section 3.3.8), and System Level Testing of Substitutability Using Specialized Test Cases (see
section 3.3.10).
As stated above, these guidelines extend the Subtyping guidelines (see section 3.3.6).
3.3.10 System Level Testing of Substitutability Using Specialized Test Cases

The guidelines in this section check for superclass/subclass compatibility by developing system level test cases (i.e.,
requirements-based test cases) in a manner that first ignores compliance with substitutability and then introduces
specialized versions of existing system level test cases to explicitly test for substitutability compliance. These
guidelines help address the same issues as the those for Subtyping (see section 3.3.6).
3.3.10.1 Motivation
Some projects prefer to focus exclusively on system level testing (i.e., requirements-based testing) without
developing any unit level /class level test cases. Use of the Unit Level Testing of Substitutability (see section 3.3.8)
is clearly in conflict with this approach. There are, however, ways to test for substitutability at a system level. One
approach involves the development of specialized system level tests for this purpose. This has the advantage of
avoiding instrumentation (see guidelines for System Level Testing of Substitutability Using Assertions in section
3.3.9) although it typically requires that test cases be developed with this approach in mind.
These guidelines apply when concerns exist about substitutability of various subclasses for one another at run-time
and requirements-based test cases are written to test these configurations. Typically, the test cases are based on high-
level requirements.
Although these guidelines typically apply to the testing of high-level requirements at a system level, they can also be
applied at a subsystem level, in terms of low-level and derived requirements. They differ from the guidelines for
Unit Level Testing of Substitutability (see section 3.3.8) in that test cases are written against some entity (e.g.,
3-24
Volume 3
system or subsystem) that contains instances of the classes we wish to test for compatibility, and not directly against
these classes.
Use of these guidelines is straightforward if test cases have not yet been developed, or if the current set of test cases
ignores substitutability.
3.3.10.3 Guidelines
The guidelines in this section extend those for Subtyping (see section 3.3.6). The following rules relate to the process
used to develop system level test cases to test for substitutability [3, section 5]. They assume that, with suitable
language restrictions, dynamic dispatch is semantically equivalent to the use of hand-coded dispatch methods
containing case statements or compound if statements. The rules begin with conformance to coverage criteria based
on inlined calls to a case statement with MC/DC testing for Level A systems. They culminate in conformance to
coverage criteria that guarantees substitutability between subtypes and supertypes.
Generalized test case rule: First, construct a set of system level test cases to meet the required DO-178B coverage
criteria while considering only the declared classes of objects and object references. The run-time classes of
objects and dynamic dispatch should be ignored other than to mark test cases that include dispatching calls as
polymorphic.
Specialized test case rule: Next, create a set of specialized test cases for each polymorphic test case that are
explicitly designed to test for substitutability. The set of test cases generated from a given polymorphic test case
should be designed to drive dynamic dispatch down different paths with regard to the selection of subclass
methods. The initial state and resulting state associated with each specialized test case should be compatible (in
terms of substitutability) with the more general test case from which it was derived.
It is also possible, by complying with the following rules, to develop a set of test cases that meet any of a number of
different substitutability-related coverage criteria.
Min substitutability coverage rule: By this test case coverage criteria, the full set of specialized test cases must
exercise dynamic dispatch to subclass methods to the extent required to meet the structural coverage criteria of
DO-178B.
Max substitutability coverage rule: By this test case coverage criteria, the set of specialized test cases derived from
each polymorphic test case must exercise all reachable subclass methods at each point of call involving dynamic
dispatch.
Mid substitutability coverage rule: By this test case coverage criteria, the full set of specialized test cases must
meet the criteria set by the Min Substitutability coverage rule. Additional specialized test cases, however, must be
introduced to test specifically for the types of problems raised by issues 20, 21, 22, 26, and 40 identified in Volume
2, Appendix B of this Handbook.
Compliance with DO-178B objectives requires conformance to the Min Substitutability coverage rule. This rule is
designed to rely on DO-178B to set the criteria for test case coverage. Rather than require additional test cases to test
for substitutability, it takes advantage of the process for test case generation to add substitutability-related
compatibility checks to the test cases created (“The initial state and resulting state associated with each specialized
test case should be compatible (in terms of substitutability) with the more general test case from which it was
derived.” [7]). This is not as rigorous as the process of the Unit Level Testing of Substitutability (see section 3.3.8),
but it does make the most of the test cases already required by DO-178B.
The Max substitutability coverage rule matches the degree of rigor offered by the Unit Level Testing of
Substitutability (section 3.3.8), and exceeds it. It is most appropriate when the DO-178B software level is high (e.g.,
level A) and the number of calls involving dynamic dispatch is small. If run-time substitution of different subclass
instances is commonplace (Minimum compatibility rule, section 3.3.6.3), exhaustive testing of all subclass methods
in the context of every system level test case is impractical. Typically, however, the most safety-critical applications
are also the most static, making this level of substitutability test coverage acceptable in many cases.
3-25
Volume 3
The Mid substitutability coverage rule attempts to strike a balance between the previous coverage criteria by
requiring compliance with the Min substitutability coverage rule, but adding rigor through the introduction of
additional test cases targeted specifically to the types of problems raised in issues 20, 21, 22, 26, and 40 identified in
Volume 2, Appendix B of this Handbook. Additionally, explicit robustness test cases may need to be developed, but
this is not unique to substitutability-related testing [19].
Tools are often used to verify structural coverage criteria and should follow the guidelines given in section 3.12 of
this volume. Structural coverage analysis tools for OO languages should measure coverage for each polymorphic
call and each resolution for each set of identical polymorphic calls. When a tool does not have the capability to
measure coverage in this way, then a process will need to be performed to augment the tool’s analysis capabilities to
satisfy structural coverage objectives. The sets of rules in this section may be used to augment a tool’s capability to
meet DO-178B structural coverage objectives. A clarification of the coverage requirements for class structure versus
the coverage of method internals within the class structure is found in sections 3.10.8 and 3.10.9 of this volume.

Related guidelines include those for Unit Level Testing of Substitutability (see section 3.3.8), System Level Testing of
Substitutability Using Assertions (see section 3.3.9), and Percolation (see pages 882-896 of [11]).
As stated above, these guidelines extend the Subtyping guidelines in section 3.3.6.
3.3.11 Class Coupling

The guidelines in this section limit control flow and data flow between clients and classes and between classes and
subclasses to facilitate future changes and to simplify analysis.
3.3.11.1 Motivation
One of the fundamental principles of object-oriented development is data abstraction. The goal is to hide the details
of the data representation behind an abstract class interface. This permits the data representation to change without
affecting other classes. It also simplifies the enforcement of class invariants, and permits control over concurrent
access to shared data. Extending this principle, we can use abstract class interfaces to control access to hardware
resources as well as data.
For example, consider the implementation of a class for a set. The selection of an optimum data representation (list,
tree, hash table, etc.) will vary depending on the mix of operations required by the application. Typical strategies
involve a choice between a sorted and a hashed representation, and a choice between fast insert/delete and fast
lookup. The use of data abstraction makes it easy to change this representation with no significant change to client
code.
The same situation arises with respect to the abstraction of other resources. For example, a number of different
hardware devices may perform a given function, or a number of different caching policies may be associated with
access to a given file system, or a number of different ways may exist to represent the elements of a given display,
with a number of different strategies for drawing/redrawing them. In all these cases, it is desirable to publish a single
interface but support a number of different underlying implementations and data representations.
In terms of DO-178B, data abstraction supports partitioning by permitting the developer to restrict access to the
resources controlled by the class (see section 2.3.1 of [1]. By limiting the degree of control and data coupling
between software components, analysis is simplified and it is easier to verify key system invariants maintained by a
given class (see objective 8 of Table A-7 and objectives 1 and 4 of Table A-3 in DO-178B [1]).
To be effective, the interface should provide a true abstraction of the data and other resources controlled by the
class, rather than simple accessors (get and set operations) for each attribute or hardware register. Any invariants
associated with the class should be established by the class constructor, and maintained by every publicly accessible
operation. Access restrictions associated with the class interface permit a proof of the invariant to be local to the
class, rather than global to the system and different for each system in which the class appears.
3-26
Volume 3
These principles apply not only to interfaces provided by the class to clients but to interfaces between superclasses
and subclasses. In particular, it should be possible for the developer to define the interface between a class and its
subclasses in the same manner as the interface between the class and its clients. Both can be considered ‘contracts’,
only with different parties. The interface between client and class is concerned with how the class will be used. The
interface between superclass and subclass is concerned with how the class definition and implementation can be
extended. Both can be defined formally (in terms of pre- and post- conditions) when desired.
These guidelines apply when control and data coupling between classes is a concern in an object-oriented system.
Access to the attributes of a class is provided by public and protected operations, which can be inlined to avoid the
overhead associated with a call, producing code comparable to that for direct access. When performance is critical,
but the target compiler does not support inlining or does not perform inlining efficiently, use of these guidelines may
not be appropriate.
3.3.11.3 Guidelines
The following rules address the basic issues associated with Class Coupling:
Client data abstraction rule:

- Clients should access the data representation of the class only through its public operations.
- All attributes should be hidden (private or protected), and all strategies associated with the choice of data
representation should be abstracted by its set of public operations.
- All hardware registers should be hidden (private or protected), and all strategies associated with the use of a
particular hardware device should be abstracted by its set of public operations.
Invariant rule: The invariant for the class should be:
- an implicit or explicit part of the post-condition of every class constructor,
- an implicit or explicit part of the pre-condition of the class destructor (if any), and
- an implicit or explicit part of the pre-condition and post-condition of every other publicly accessible operation.
As a result, clients should be able to influence the value of the invariant only through execution of these operations.
Private and protected operations are exempted in the Invariant rule since the invariant need not hold at all times, but
only at points where it is externally observable.
These guidelines may be extended to deal with the coupling between classes and subclasses by also adopting the
following rule:
Subclass data abstraction rule:

- A subclass should access the data representation of its superclass only through the superclass’ public and
protected operations.
- All attributes should be hidden (private), and all strategies associated with the choice of data representation
should be abstracted by its set of public and protected operations.
- All hardware registers should be hidden (private), and all strategies associated with the use of a particular
hardware device should be abstracted by its set of public and protected operations.
- The class invariant should also be an implicit or explicit part of the pre-condition and post-condition of each
protected method of a class, and part of the post-condition of every protected constructor.
Again, these guidelines may be used to reduce coupling issues when coupling is considered to be a problem and
these guidelines are adopted to address this problem. To be most effective, both the client and subclass interfaces
3-27
Volume 3
should provide a true abstraction of the data and other resources controlled by the class, rather than simple accessors
(get and set operations) for each attribute or hardware register.
3.3.12 Deep Hierarchy

The guidelines in this section address issues that can occur when the complexity of class hierarchies is very deep.
3.3.12.1 Motivation
Most class hierarchies have a characteristic depth of between three and six, irrespective of the application. Class
hierarchies that are either too deep or too shallow can cause problems. Dynamic dispatch can introduce problems
related to initialization, especially with regard to deep class hierarchies. Top-heavy multiple inheritance and deep
hierarchies also tend to be error-prone, even when they conform to good design practice. The wrong variable type,
variable, or method may be inherited, for example, due to confusion about a multiple inheritance structure. Binder
refers to this as “spaghetti inheritance” [11].
These guidelines apply when the complexity of the class hierarchy is a concern.
3.3.12.3 Guidelines
The following rule addresses the issues associated with Deep Hierarchies:
Six deep rule: Any class hierarchy with a depth greater than six warrants a careful review that specifically
addresses the above issues and weighs this against the need to isolate various proposed changes. When extending
an existing framework, depth should be measured from the point at which the framework is first subclassed. When
developing an application specific class hierarchy, depth should be measured from the root. In languages in which
all classes implicitly inherit from a common root class, this class should not be included in the count.
A class hierarchy that successfully passes an inspection should be marked so as to avoid repeated review with
respect to the same issue.
A certain amount of variation in the threshold (e.g., plus or minus two) may also be expected based on the results of
reviews using the six deep threshold. Deep hierarchies may also be more of a problem with respect to
implementation inheritance than interface inheritance. The use of multiple inheritance can also be an important
factor in adjusting the threshold.
This rule is based on the metrics for class hierarchy nesting level (discussed on pages 61-64 of [9]). Note that this
rule does not, in anyway, imply that class hierarchies with a depth of six or less do not require careful review.
3.3.12.4 Related Guidelines

Related guidelines include those for Inheritance with Overriding, Multiple Interface Inheritance, and Multiple
Implementation Inheritance (see section 3.3.4, 3.4.4, and 3.4.5, respectively).
3-28
Volume 3
3.4 Multiple Inheritance

3.4.1 Purpose
This section provides guidelines regarding safe implementation and use of multiple inheritance in projects that use
OOT.
3.4.2 Background
Single inheritance, overriding, subtyping, and dynamic dispatch are described in Section 3.3. Multiple inheritance
permits a class to have more than one superclass. It may involve either interface inheritance or implementation
inheritance, or some combination of these. Interface inheritance involves the inheritance of only interface elements
(such as operation specifications and constraints), while implementation inheritance involves the inheritance of
implementation elements (such as methods, attributes, and references to other objects).
Multiple inheritance may lead to name clashes involving elements inherited from different superclasses that have the
same signature. Some languages support renaming as a means of resolving such name clashes. Eiffel is particularly
elegant in dealing with this [18]. Most other languages either require more complicated workarounds [22, section
12.8] or the editing of the superclass definitions to rename inherited elements.
Most issues arise with respect to multiple implementation inheritance because it is difficult to implement well,
because associated errors have run-time consequences, and because the inherited elements reference one another and
may interact in subtle ways, increasing overall complexity and the potential for error.
Because delegation is considered an effective substitute for multiple implementation inheritance, many more recent
languages (such as Java and C#) only support multiple inheritance involving interface specifications. The Aerospace
Vehicle Systems Institute (AVSI) Guide [21] also recommends the use of delegation rather than multiple
implementation inheritance for systems certified to levels A, B, and C.
A number of issues arise when using multiple inheritance that may make compliance with DO-178B difficult.
Volume 2 documents key concerns and related issues and Volume 3 associates these concerns and issues with some
applicable guidelines. Guidelines assume that all source code is available for software developed to meet DO-178B
levels A, B, and C. These “guidelines” provide an approach for addressing DO-178B guidance with respect to the
use of particular OO features. The “rules” associated with these guidelines are also rules only in the sense that they
must be followed in order to adopt the given approach. Often there are also alternative approaches that can be
followed in order to address the same issues and still comply with DO-178B.
3.4.3 Overall approach

This section is intended to provide an approach for addressing DO-178B objectives when using OO features related
to multiple inheritance. In this regard, multiple inheritance is treated as an extension of single inheritance and, as a
result, all guidelines related to the use of single inheritance and dynamic dispatch also apply here. Issues related to
multiple inheritance are listed in Volume 2.
Guidelines that attempt to resolve these issues appear in sections 3.4.4 through 3.4.8. Each of these sections should
be understood to provide one (of possibly many) approaches that assist in compliance to DO-178B objectives.
The overall collection of guidelines is open-ended. As a result, new approaches and new guidelines may be added
that address the same issues as existing approaches, under different circumstances.
A sharp distinction is drawn between the use of interface and implementation inheritance. The guidelines for
Multiple Interface Inheritance (see section 3.4.4) address the simpler case, in which we are concerned only with
inherited operation specifications (that do not reference one another).
The guidelines for Multiple Implementation Inheritance (see section 3.4.5) deal with the more difficult case
involving the inheritance of code and data. Although use of these guidelines helps us deal with the issues raised with
3-29
Volume 3
respect to ambiguity and complexity, delegation is still considered preferable to the use of multiple implementation
inheritance for most systems (as recommended by the AVSI Guide [21]).
The guidelines for the Combination of Distinct Abstractions (see section 3.4.7) provide an alternative to those for
Multiple Implementation Inheritance (see section 3.4.5). They forbid the use of repeated inheritance in order to
eliminate related sources of ambiguity.
The guidelines for Mixed Multiple Inheritance (see section 3.4.6) address the case in which we have a mix of
interface and implementation inheritance.
The Top Heavy Hierarchy guidelines (see section 3.4.8) address issues of complex class hierarchies that contain Mis en forme
many classes and inherited features near the top (root) of the hierarchy.
3.4.4 Multiple Interface Inheritance

Multiple interface inheritance permits the categorization of entities in terms of their interfaces, where each entity
may appear in more than one category. These guidelines extend those for single inheritance and dynamic dispatch to
address multiple interface inheritance. When applying the Subtyping guidelines (see section 3.3.6), this means that a
subclass with more than one superclass inherits the test cases defined by all its superclasses.
3.4.4.1 Motivation
In the real world, objects are often classified in more than one way. Multiple interface inheritance allows us to
model this without introducing redundancy (and without the complications associated with multiple implementation
inheritance).
Multiple interface inheritance involves two or more superinterfaces, each of which contributes features (compile-
time constants and operations) to a single subinterface. Each super-interface may, in turn, itself inherit from other
interfaces, either singly or multiply. The resulting inheritance hierarchy forms a directed acyclic graph that permits
the definition of common ancestors, and the inheritance of the same feature along more than one path (repeated
inheritance). Features may also be redefined, potentially resulting in different definitions of the same feature along
different paths. Section B.2.1of Appendix B illustrates the following issues with multiple interface inheritance:
• Repeated inheritance,
• Redefinition along separate paths, and
• Independently defined operations with same signature.
3.4.4.3 Guidelines
The guidelines in this section extend those for Inheritance with Overriding (see section 3.3.4) to include the
following rules that addresses the three issues listed above:
Repeated interface inheritance rule: When the same operation declaration is inherited by an interface via more than
one path through the interface hierarchy without redeclaration or renaming, this should result in a single operation
in the subinterface.
Interface redefinition rule: When a subinterface inherits different definitions of the same operation (as a result of
redefinition along separate paths), the definitions must be combined by explicitly defining an operation in the
subinterface that follows the Simple overriding rule with respect to each parent interface.
Independent interface definition rule: When more than one parent independently defines an operation with the
same signature, the user must explicitly decide whether they represent the same operation or whether this
represents an error. Such decisions should be recorded as explicit annotations to the source code. If the
3-30
Volume 3
operations are not intended to be the same, one of them should be renamed. If the operations are intended to be
the same, any pre-conditions and post-conditions should also be the same.
Compile time constant rule: All of the above rules apply to compile time constants as well as operations. Constants
whose value involves run-time computation should not be permitted in interfaces.
The rationale for the Repeated interface inheritance rule is that cases involving the sharing of operations are
common while cases that demand replication are not (see section B.2 of Appendix B). Sharing is also supported by
many languages, whereas replication is not. Therefore, sharing is defined to be the normal, expected behavior and
additional work is needed to support replication in those rare cases in which it is required.
The Interface redefinition rule is derived from the guidelines for behavioral subtyping [7] that inspired the Simple
overriding rule (see section 3.3.4.3). The user is required to define the operation representing the combination of the
inherited definitions in order to make its specification explicit even when the language does not require it. The intent
here is that clients of the sub-interface be able to directly see the result of combining the inherited definitions.
The Independent interface definition rule requires the user to always explicitly decide when two independently
defined operations with the same signature are intended to represent the same operation and when they are not. The
intent is to avoid errors resulting from the accidental matching of operation signatures.
The Compile time constant rule specifies that compile time constants be treated in the same manner as operations
with respect to the previous cases. It applies only to constants with an initial value that can be computed at
compilation time. Constants whose value is computed at run-time require the generation of code to perform the
computation and assignment. This, in turn, conflicts with the fundamental definition of an interface, which is not
permitted to define either the code or the data.
Language-specific guidelines are provided in section B.2.2.1 of Appendix B. In general, it is only necessary to
enforce (e.g., by means of design and code inspections) those guidelines that the language does not enforce itself.

The guidelines in this section are related to those for Subtyping (see section 3.3.6).
Mis en forme
As noted above, these guidelines extend those for Inheritance with Overriding (see section 3.3.4).
3.4.5 Multiple Implementation Inheritance

Multiple implementation inheritance supports the construction of a class implementation in terms of the
implementations of other existing classes. These guidelines extend those for single inheritance and dynamic dispatch
to address multiple implementation inheritance. When applying the guidelines for Subtyping (see section 3.3.6), this
means that a subclass with more than one superclass inherits the test cases defined by all its superclasses.
3.4.5.1 Motivation
Multiple implementation inheritance supports maximum reuse of code.
These guidelines apply when a given class is implemented by inheriting the methods and attributes of two or more
superclasses.
3-31
Volume 3
3.4.5.3 Guidelines
The guidelines in this section extend those for Inheritance with Overriding (see section 3.3.4) to address the basic
issues raised by the multiple inheritance of code and data in a manner consistent with the multiple inheritance of
interface specifications:
Repeated implementation inheritance rule: When the same feature (method or attribute) is inherited by a class via
more than one path through the interface hierarchy, this should result in a single feature in the subclass.
Implementation redefinition rule: When a subclass inherits different definitions of the same method (as a result of
redefinition along separate paths), the definitions must be combined by explicitly defining a method in the subclass
that follows the Simple overriding rule (see section 3.3.4.3) with respect to each parent class.
Independent implementation definition rule: When more than one parent independently defines a method with the
same signature, the user must explicitly decide whether they represent the same method or whether this
represents an error. If they are intended to be different, renaming should be used to distinguish them. Otherwise,
the definitions must be combined by explicitly defining a method in the subclass that follows the Simple overriding
rule (see section 3.3.4.3) with respect to each parent class.
As in the guidelines on Inheritance with Overriding (see section 3.3.4), it is recommended that decisions related to
the Independent implementation definition rule be recorded as explicit annotations to the source code.
Languages specific guidelines for C++ are provided in section B.2.2.2 of Appendix B. In general, it is only
necessary to enforce (e.g., by means of design and code inspections) those guidelines that the language does not
enforce itself.

The guidelines in this section are related to those for Subtyping (see section 3.3.6).
As noted above, these guidelines extend those for Inheritance with Overriding (see section 3.3.4).
3.4.6 Mixed Multiple Inheritance

Multiple inheritance may involve only interface specifications, may involve only implementations, or may involve
some combination of these. The guidelines in this section address the issues associated with the combination of
interface and implementation inheritance (i.e., mixed multiple inheritance).
3.4.6.1 Motivation
Often we want to define a class that implements one or more interfaces while building on the implementation
provided by a second class. This can be accomplished in a number of ways. In situations where the resulting class is
logically a subtype of the other classes, inheritance is a natural choice. This typically works well as long as all the
superclasses are interfaces, save one.
In the more general case, involving an arbitrary combination of interfaces, abstract classes, and concrete classes, the
problems associated with multiple implementation inheritance may also arise.
These guidelines apply when a class has at least one parent class that is an interface and at least one parent class that
is not.
3-32
Volume 3
3.4.6.3 Guidelines
Both the guidelines for Inheritance with Overriding (see section 3.3.4) and Multiple Interface Inheritance (see
section 3.4.4) apply here. If more than one superclass provides an implementation, the guidelines on Multiple
Implementation Inheritance (see section 3.4.5) also apply.
Verification in accordance with the guidelines on Subtyping (see section 3.3.6) is also recommended.

Guidelines for Top Heavy Hierarchy (see section 3.4.8) and Deep Hierarchy (see section 3.3.12) provide metrics to
limit the complexity of the inheritance hierarchy.
3.4.7 Combination of Distinct Abstractions

The guidelines in this section extend those for Multiple Implementation Inheritance (see section 3.4.5) by restricting
the use of multiple implementation inheritance to cases that do not involve repeated inheritance or the redefinition of
competing implementations along separate paths.
3.4.7.1 Motivation
The guidelines in this section are intended to maximize the reuse of code while complying with the associated
guidelines for Subtyping (see section 3.3.6). Any use of multiple inheritance, however, can lead to ambiguities
within the class hierarchy. Three potential sources of ambiguity are identified in Appendix B.2.1: (1) repeated
inheritance, (2) redefinition along separate paths, and (3) independently defined operations with the same signature.
The first two are eliminated by the guidelines in this section, which require that superclasses always be distinct
rather than subclasses of a common superclass. As Meyer suggests, “This is the form that you will need most often
in building inheritance structures, …” [18, page 521].
A given class is implemented by inheriting the features of two or more distinct superclasses. The superclasses are
considered distinct because they are not variants of a single abstraction [18, page 521] (i.e., they have no common
ancestors). The following example illustrates the basic structure.
Plane Asset
passenger_count() : int purchase_price() : float
CompanyPlane
Figure 3.4-1 Combination of Distinct Abstractions
As described by Meyer [18, page 521], a class Plane describes the abstraction suggested by its name. Operations are
provided to query the passenger_count, altitude, position, and speed of the airplane. Additional operations include
commands to take_off and set_speed. In a completely different domain, we have a class Asset that represents
something that a company owns. Our concerns here are related to accounting, the manner in which the asset is paid
3-33
Volume 3
for, its depreciation and sale. Operations associated with an asset include queries to determine its purchase_price
and resale_value, and the actions depreciate, resell, and pay_installment.
These classes are then combined by means of inheritance to create a new class CompanyPlane. Because each
superclass is taken from a different domain and because they have no common ancestors, the odds of inheriting two
independently defined operations with the same signature is small.
3.4.7.3 Guidelines
Although the guidelines in this section extend those for Multiple Implementation Inheritance (see section 3.4.5), the
restrictions on inheritance structure eliminate ambiguities arising from repeated inheritance and redefinition along
separate paths. As a result, we do not need the Repeated implementation inheritance rule or the Implementation
redefinition rule defined by the guidelines for Multiple Implementation Inheritance (see section 3.4.5).
Only the Independent implementation definition rule: from the guidelines on Multiple Implementation Inheritance is
required, to handle cases in which superclasses independently define operations with the same signature. Because
the superclasses are distinct, any ambiguity usually represents an error, and should result in a renaming of one of the
inherited operations in order to make them distinct.
In addition to the two rules below, the rules associated with the guidelines on Inheritance with Overriding and
Subtyping (sections 3.3.4 and 3.3.6, respectively ) must also be followed.
No diamond rule: Repeated inheritance is not permitted; i.e., no subclass may inherit from the same superclass via
more than one path.
Independent implementation definition rule: When more than one parent independently defines a method with the
same signature, the user must explicitly decide whether they represent the same method or whether this
represents an error. If they are intended to be different, renaming should be used to distinguish them. Otherwise,
the definitions must be combined by explicitly defining a method in the subclass that follows the Simple overriding
rule with respect to each parent class. Note: This rule is identical to the rule of same name in the section on
Multiple Implementation Inheritance (see section 3.4.5).

The guidelines in this section are related to those for Inheritance with Overriding and Subtyping (see sections
3.3.4and 3.3.6, respectively).
Mis en forme
As noted above, these guidelines extend the Multiple Implementation Inheritance guidelines (see section 3.4.5).
3.4.8 Top Heavy Hierarchy

The guidelines in this section address issues of complex class hierarchies that contain many classes and inherited
features near the top (root) of the hierarchy. The intent is to reduce the number of opportunities for errors related to
composition of competing parent implementations.
3.4.8.1 Motivation
Most class hierarchies have a characteristic shape. They are generally narrow near their top (root) and broad near
their base, with a depth of between three and six. As a result the number of classes increases as a function of their
distance from the root and the number of inherited elements increases in small steps.
Problems can arise when class hierarchies fail to exhibit this shape. A class hierarchy with many classes near the
root, and with many features associated with these top-level classes can be difficult to understand and change. “Top-
heavy multiple inheritance and deep hierarchies are error-prone, even when they conform to good design practice.
The wrong variable type, variable, or method may be inherited, for example, due to confusion about a multiple
inheritance structure.” [11, p. 503, spaghetti inheritance]
3-34
Volume 3
These guidelines apply when the complexity of the class hierarchy is a concern and there are too many classes near
its root. This is a particular concern when multiple inheritance is used and the number of features inherited from
each of these upper level classes is large.
3.4.8.3 Guidelines
The following rules define the basic approach:
Three parents rule: Any class near the top of the hierarchy with three or more parents warrants careful review.
Top heavy composition rule: Any class near the top of the hierarchy that inherits more than 20 features from each
of two or more parent classes warrants careful review.
Top to bottom rule: Any class hierarchy that contains more classes near the top of the hierarchy than near the
bottom warrants careful review.
A class is considered “near the top of the hierarchy” if it appears in one of the top two levels. A class is considered
“near the bottom of the hierarchy” if it appears in one of the bottom two levels. A class hierarchy that successfully
passes an inspection should be marked so as to avoid repeated review with respect to the same issue.

Related guidelines include those for Inheritance with Overriding, Multiple Interface Inheritance, and Multiple
Implementation Inheritance (see sections 3.3.4, 3.4.4, and 3.4.5, respectively).
3-35
Volume 3
3.5 Templates
3.5.1 Purpose
Templates and the guidelines on templates in this section are not unique to OOT. This section addresses issues
raised and considered regarding DO-178B guidelines for development and verification when using templates in an
OOT environment.
3.5.2 Background
Templates provide a means of abstracting common structural and behavioral aspects of a family of classes or
operations in a domain independent way. Template is the UML term for a parameterized model element with
unbound (formal) parameters that must be bound to actual parameters before it can be instantiated.
At a target language level, templates correspond to Ada generics and to C++ templates. A template is a
parameterized code replication feature that provides stronger typing than macros. Templates provide for reusability
in programming languages. Consider a Stack with a generically parameterized base type. Templates allow the Stack
class to provide many class instantiations, such as a Stack of integers, a Stack of any fundamental or user-defined
type, or even a Stack of Stacks.
A template’s behavior results from its implementation, the values of the arguments used to instantiate the template,
and the behavior of any types specified to it as arguments. The use of templates directly impacts: source code
reviews, coding standards, requirements-based test case and procedure development and review, timing analysis,
memory usage analysis, requirements-based test coverage, source code to object code traceability, and structural
coverage, including data coupling analysis and control coupling analysis. Dead code and deactivated code may also
be a concern because unused functionality of a template may be considered either dead or deactivated code.
Template guidelines are provided below in three areas: (1) Source Code Review (section 3.5.3); (2) Requirements-
Based Test Development, Review, and Coverage (section 3.5.4); and Structural Coverage for Templates (section
3.5.5).
3.5.3 Source Code Review
3.5.3.1 Motivation
The use of templates can affect source code reviews. Depending on the parameter types and the scope of the call, a
different instantiation of the template may be invoked by the compiler. Each instantiation may use different sub-
components and features of the template. The template may contain features that are not used at all by a specific
application.
3.5.3.2 Related DO-178B Sections and Objectives

The following DO-178B objectives for verification and coding standards are relevant to the recommendations in
section 3.5.3.3 for using templates: Table A-1 objective 5, Table A-5 objectives 1 and 3, and Table A-9 objective 1.
3.5.3.3 Guidelines
Standards need to address the issues identified in this section. The source code developer and code reviewer should
be aware of the implications and potential effects of using templates. A template must be reviewed with respect to
the actual parameters to determine if the source code is verifiable. Consequently, the following practices are
recommended:
• It may be necessary for types to be defined in low-level requirements to facilitate test coverage.
3-36
Volume 3
• Coding standards should require templates to document all the assumptions about types to be used with that
template.
• Coding standards should be established to ensure that every type used in the instantiation of a template complies
with the assumptions documented for the use of the template.
• Coding standards should be established to determine which features of a template, if any, are not used by the
application. Unused features may be considered dead or deactivated code.
• Each template should be reviewed with respect to the actual parameters.
3.5.4 Requirements-Based Test Development, Review, and Coverage
3.5.4.1 Motivation
Templates are instantiated by substituting zero or more specific arguments for each formal parameter defined in the
template class or operation. Test cases and procedures are developed based on the software high-level, low-level,
and derived requirements. Consequently, test developers and reviewers may not be aware whether a template
contains additional functionality, and may not be aware of or have visibility into all the functionality contained
within a specific operation that is instantiated by a template call. In general, requirements-based test cases and
procedures may not test all functionality of the template, especially that functionality which is not instantiated for a
particular template. All instantiations should be tested to guarantee that the template functions as intended [23] [11].

See DO-178B section 6.4.4.3d, Table A-6 objectives 1 through 4, and Table A-7 objectives 1 through 4 regarding
verification and integration processes.
3.5.4.3 Guidelines
Each instance of a template with a unique set of arguments should be tested for software at Levels A, B, and C. It is
theoretically possible to test the template for all known instances if the types map to the same underlying
representation and object code can be shown to be equivalent. In practice, the complexity of the instantiation
process makes it difficult to verify all instances of a template without testing each instance individually. [23] It also
complicates the requirements to test coverage traceability, as many tests may need to be executed to cover all
possible instantiations that do not trace to specific requirement of the application. Also, the developer may need to
provide protection that ensures that the unused functionality of the template (deactivated code) cannot be
inadvertently activated. Therefore, while templates may lead to coding efficiencies, the use of templates may
actually substantially increase the amount of requirements-based test development, review, and coverage needed.
3.5.5 Structural Coverage for Templates
3.5.5.1 Nested Templates

Nested templates and using templates with other language constructs increases the complexity of the code. For
example, child packages in Ada and friend classes in C++ can result in complex code. Although complex code is not
prohibited by DO-178B, complexity can make structural coverage analysis more difficult.
3.5.5.1.1 Related DO-178B Sections and Objectives

The following DO-178B sections and objectives for integration and test coverage are relevant to recommendations
in section 3.3.5.1.2 for using templates: DO-178B section 6.4.4.2, Table A-6 objectives 1 through 4 and Table A-7
objectives 5 through 7.
3-37
Volume 3
3.5.5.1.2 Guidelines
In general, templates should be analyzed for complexity and complex templates should be avoided. Nesting
templates increases the complexity of the code and therefore warrants careful review. Also, any template class that
inherits from another template class or provides interfaces or operations to be overridden by a subclass warrants
careful review.
3.5.5.2 Templates and Object Code Traceability

Templates can be compiled using "code sharing" or "macro-expansion". Code sharing is highly parametric, with
small changes in actual parameters resulting in dramatic differences in object code. Object code coverage is difficult
and mappings from a template to object code can be complex when the compiler uses the "code sharing" approach.

The following DO-178B sections and objectives for structural coverage are relevant to the recommendation in
section 3.5.5.2.2 for using templates: DO-178B section 6.4.4.2 and Table A-7 objectives 5 through 7.
Code sharing is not widely used, and in general, code sharing should be avoided.
3.5.5.3 Data and Control Coupling Analysis

Use of templates can complicate data coupling analysis and control coupling analysis by not allowing visibility into
the template for the analyst to verify that the correct template functionality is invoked for each instantiation (control
coupling) based on the parameters (data coupling). However, proper adherence to Source Code Review and
Requirements-Based Test Development, Review, and Coverage guidelines (see sections 3.5.3 and 3.5.4, respectively)
is sufficient for validation.

DO-178B section 6.4.4.3 c and Table A-7 objective 8 on data and control coupling are relevant.
Data and control coupling associated with templates should be evaluated with respect to the actual parameters.
3-38
Volume 3
3.6 Inlining
3.6.1 Purpose
Inlining and the guidelines on inlining in this section are not unique to OOT. This section addresses issues raised
and considered regarding DO-178B guidelines for development and verification when inlining in an OOT
environment.
3.6.2 Background
When a compiler chooses to inline, a method body is compiled without the call overhead (i.e., the inlined method
body’s object code is physically placed in the calling method’s object code). This is in contrast to the “usual”
implementation of making a call (and potential context switch) during execution to a separate method with the
associated parameters, if any, being passed to the called method. If the compiler chooses not to inline, a call to the
method is inserted in the caller’s object code, and the called method’s object code remains separate. The inlining of
methods eliminates the overhead associated with a call, and is thus useful for optimization of performance. This
performance optimization results in a space penalty, unless the inlined method is shorter than the sequence of
instructions used to make the call. Simple get and set methods, for example, are commonly used in OO software and
can sometimes be smaller than the calling sequence.
When inlining, it is important to know if the compiler will honor or ignore the inline request, whether the code has
been inlined or not, and what the impact is to the code.
The following analyses are directly impacted by inlining: memory and stack usage analyses, timing (performance)
analysis, structural coverage analysis, and source code to object code traceability. Inlining may affect a number of
verification methods as noted below. The use of inlining, however, is not an obstacle to certification, so long as its
effects on each of these verification activities are understood, documented, and addressed.
Guidelines are provided below in two areas: (1) Inlining and Structural Coverage (see section 3.6.3) and Source
Code Review of Inlined Code (see section 3.6.4).
3.6.3 Inlining and Structural Coverage

Some language constructs in combination with inlining can impact structural coverage analyses, including data and
control coupling and source to object code traceability analysis.

The following DO-178B sections and objectives for structural coverage and data and control coupling are relevant to
the recommendations in section 3.6.3.2 for inlining: Section 6.4.4.2 and Table A-7 objectives 5 through 8.
3.6.3.2 Guidelines
In general, inlining should consist of a simple expression only, which is almost always one or more statements that
do not contain conditional or iterative expressions. Generally, virtual methods and class constructors/destructors
should not be inlined. See page 140 of [16]. This guideline helps to address DO-178B Table A-7 objectives 5
through 8.
Inline expansion may be handled differently at different points of expansion in order to optimize the code for the
caller’s context. Structural coverage should be verified separately for each expansion, if the inline operation contains
elements that may result in structural coverage escapes. This generally implies the inline operation contains
conditional or iterative statements.” This guideline helps to address DO-178B Table A-7 objectives 5 through 7.
3-39
Volume 3
Inline expansion can eliminate parameter passing, which can affect the amount of information pushed on the stack
as well as the total amount of code generated. This, in turn, can affect the stack usage and timing analysis. In
addition, data coupling and control coupling relationships can transfer from the inlined component to the
inlining component. For data coupling and control coupling, the verification approach should address the inlining of
code, including call tree analysis and data set/use analysis. In addition, the verification should include an analysis of
various resources, including worst-case memory usage analysis, stack usage analysis, and timing analysis. This
guideline helps to address objective 8 of DO-178B Table A-7.
3.6.4 Source Code Review of Inlined Code

Inlining can complicate source code reviews. Both the code developer and the source code reviewers must be aware
of the implications and potential effects of inlining. When an inlined method is expanded in the context of the caller
it may be possible for the compiler to simplify it in a number of ways, involving both space and speed. Compiler
optimizations include directly referencing arguments and unrolling loops with known bounds as common examples.
This is generally only a problem when an inlined method is relatively complex and is optimized based on the context
of the caller.

The following DO-178B objectives for verification are relevant to the recommendations in section 3.6.4.2 for
inlining: Table A-5 objectives 1 and 3.
3.6.4.2 Guidelines
The inline method should be reviewed against the low-level requirements. This is sufficient to verify the behavior of
all expansions and should help satisfy objectives 1 and 3 of DO-178B Table A-5.
3-40
Volume 3
3.7 Type Conversion
3.7.1 Purpose
Type conversion and the guidelines on type conversion in this section are not unique to OOT. This section addresses
issues raised and considered regarding DO-178B guidelines for verification and coding standards when types are
converted in strongly typed languages, including when it is appropriate to convert types implicitly and when type
conversion should be explicit. These “guidelines” provide an approach for addressing DO-178B guidance with
respect to type conversion for OO languages that provide for strong typing with abstraction. Guidelines are in the
form of recommended practices which support compliance with DO-178B objectives. An analysis should be
conducted to examine the effects of type conversion for all languages as a part of satisfying the DO-
178B verification objectives. Languages that are not strongly typed are not within the scope of this document.
Examples of strongly typed languages include Ada, C++, and Java. Dynamic dispatch, which uses a form of implicit
type conversion, is discussed in a separate section of this document (see section 3.3).
3.7.2 Background
Strongly typed languages are an improvement over languages that are not strongly typed because they provide
additional control of type conversion. User-defined type conversions are easier to identify and understand. Type
conversion may be implicit or explicit and may be checked (to determine if the type conversion results are valid and
correct) or unchecked. With implicit type conversion, the compiler is given the responsibility for determining that a
conversion is required and how to perform the conversion. With explicit type conversion, the programmer assumes
the responsibilities. Checked types can be checked at compile time (producing a compilation error for an invalid
conversion) or at run-time (usually resulting in a run-time error). Conversion can result in loss of data. Unchecked
type conversions need to be verified by test to ensure the conversion was correct.
The following are directly impacted by implicit type conversion: potential loss of data or precision; performance and
timing analysis; requirements-based test development, review, and execution results; structural coverage analysis;
data flow and control flow analyses; and source code to object code traceability.
3.7.3 Overall Approach

Implicit type conversion raises certification issues related to the ability to perform various forms of analyses and to
satisfy the verification objectives of DO-178B, including requirements-based testing and structural
coverage analysis. Explicit type conversions can cause implicit loops and implicit conditionals. The use of explicitly
checked type conversions are regarded as acceptable, as long as they are properly verified and do not inhibit other
verification methods, such as guaranteeing no loss of information and no unacceptable loss of data accuracy or
precision.
Guidelines for addressing type conversion are provided in four areas: (1) Source Code Review, Checklist, and
Coding Standards (see section 3.7.4); (2) Loss of Precision in Type Conversions (see section 3.7.5); (3) Type
Conversions of References and Pointers (see section 3.7.6); and (4) Language Specific Guidelines (see section
3.7.7).
3.7.4 Source Code Review, Checklist, and Coding Standards

Type conversions that are not checked by the language, either at compile time or at run-time, can potentially result
in code that has unintended behavior.
3-41
Volume 3

For object code traceability, source code review, checklist, and coding standards, see DO-178B Table A-1 objective
5; Table A-5 objectives 1, 3, 4, and 6; Table A-6 objectives 1 through 4; Table A-7 objectives 3 and 4; and Table A-
9 objective 1.
3.7.4.2 Guidelines
Unchecked type conversions are error prone and should be addressed specifically in coding standards and during
verification. Coding standards may address unchecked type conversions, as in the following recommended practice:
Conversion rule: To help ensure intended function and verification, all conversions (both checked and unchecked)
should be justified or should be explicit, use the most restrictive conversion available, be conspicuously marked
(identified) in the program source code, and be permitted only after thorough review and analysis of potential
adverse effects.
Verification of unchecked type conversions may be accomplished through code reviews, checklists, or analyses
(e.g., static code checking), and testing.
3.7.5 Loss of Precision in Type Conversions

Conversions, both implicit and explicit, that result in loss of data, data accuracy, or precision result in code that may
be incorrect. The following type conversions, for example, may result in loss of data or precision in some languages:
• from integer types to the floating point types
• from a floating point type to an integer type
• from a more precise numeric type to a less precise version of the same numeric type (e.g., long to short, double
to float, etc.)
Loss of data, data accuracy, or precision can be especially difficult to analyze and detect for implicit
conversions and can be language dependent.

For source code review, checklist, coding standards, and data coupling analysis, see DO-178B Table A-5 objectives
1, 3, 4 and 6; Table A-6 objectives 1 through 4; and Table A-7 objective 8.
3.7.5.2 Guidelines
Type conversions should be addressed for loss of data, data accuracy, or precision. This may be accomplished
through coding standards and through verification including code reviews, checklists, or analysis. Coding standards
may address type conversions that can result in loss of data, data accuracy, or precision, as in the following
recommended practice:
Loss of information rule: To help ensure correctness, any conversions that may result in loss of data or data
accuracy and precision should be justified or should:
- be explicit,
- use the most restrictive conversion available,
- be conspicuously marked (identified) in the program source code, and
- be permitted only after thorough review and analysis of potential adverse effects.
3-42
Volume 3
A clear understanding of the programming language being used is needed to identify and analyze implicit type
conversions for potential loss of information.
3.7.6 Type Conversions of References and Pointers

Some references and pointers can be implicitly converted. Converting a reference from one type to a dissimilar type
can result in code that has unintended behavior and is difficult to verify.

For source code review, checklist, and coding standards, see DO-178B Table A-5 objectives 1, 3, 4 and 6; and Table
A-6 objectives 1 through 4.
3.7.6.2 Guidelines
The following recommended practice may address implicitly converted references and pointers that result in code
with unintended behavior:
Supertype rule: To help ensure intended function and verification, all implicit type conversions involving
references/pointers to class instances should be justified or should only represent a conversion from a subtype to
one of its supertypes.
3.7.7 Language Specific Guidelines

As a result of the proposed solutions, the following language best practices should be taken into consideration using
source code reviews, checklists, and/or coding standards:
1. All implicit conversions should be checked for potential loss of precision or loss of data. Specifically, the
following should be justified:
• From integer types to the floating point types (potential loss of precision) (JAVA and C++)
• From a floating point type to an integer type (potential loss of data) (C++)
• From a more precise numeric type to a less precise version of the same numeric type (e.g., long to short,
double to float, etc.) (potential loss of data or precision) (C++)
2. Implicit conversions between logically unrelated types should be justified. Types are logically unrelated when
one does not define a set of operations that is a subset of the other. For example, in C++ single argument
constructors, such as a stack class taking a single integer argument, would allow implicit conversion. It is a good
programming practice to use the keyword “explicit” to avoid implicit conversion between logically unrelated
types. Unless the single argument constructor was created with the expressed purpose of permitting implicit
conversion between the argument type and the class type, the constructor should be declared with the explicit
keyword. Not using the explicit keyword should be justified.
3-43
Volume 3
3.8 Overloading and Method Resolution
3.8.1 Purpose
Overloading and the guidelines on overloading in this section are not unique to OOT. This section addresses issues
raised regarding DO-178B guidelines when overloading is used. Guidelines are in the form of recommended
practices, which support compliance with DO-178B objectives. These “guidelines” provide an approach for
addressing DO-178B guidance with respect to overloading and method resolution.
3.8.2 Background
Overloading means: using the same name for different operators or behavioral features (operations or methods)
visible within the same scope. Overloading is a simple but useful form of static polymorphism when used
consistently. Conversely, too much overloading and improper use of overloading can make source code readability
more difficult, and can thus contribute to human error.
Overloading can enhance readability when the overloaded operators, operations, or methods are semantically
consistent. However, overloaded operators, operations, and methods could coincidentally have the same name and
potentially have very different semantic behaviors. Specifically, overloading can be confusing when it introduces
methods that have the same name but different semantics. This may be further complicated when overloading is
combined with other language features (e.g., overriding, templates, etc.). Overloading can also complicate matters
for tool use (e.g., structural coverage and control flow analysis tools) if the overloading rules for the language are
overly complex.
Overloading may affect a number of verification methods as noted below. The use of overloading is not an obstacle
to certification so long as it is verified that the intended operation is, in fact, the operation called.
Guidelines are provided below in two areas: (1) Code Review Method (see section 3.8.3); and (2) Implicit
Conversion (see section 3.8.4).
3.8.3 Code Review Method

Overloaded methods and operators can introduce unintended functionality. Overloading special language constructs,
such as indexing or dereferencing, can make verification difficult. Overloading methods and operators inconsistently
can result in ambiguous code.

Overloading can potentially result in code that is overly complex and difficult to verify. See DO-178B [1] Table A-5
objectives 3 through 4, related to verifiability of source code and conformance to standards.
3.8.3.2 Guidelines
Overloaded methods and operators should be addressed for inconsistencies which can lead to code complexity and
ambiguities. Overloading special language features should be discouraged or justified. This may be accomplished
through code reviews, checklists, or coding standards. Software code standards should include complexity
restrictions that address overloading. For example, the following practices are recommended:
Overloaded method rule: Overloaded operations or methods should form "families" that use the same semantics,
share the same name, have the same purpose, and that are differentiated by the types of their formal parameters.
3-44
Volume 3
Overloaded operator rule: Overloaded operators should obey the "natural" meaning and follow conventions of the
language. For example, a C++ operator "+=" should have the same meaning as "+" and "=". Arithmetic operators
should be overloaded using conventional notation whenever possible.
Overloading in general rule: When calls are overloaded, reviewers should know exactly what is being called.
Overloading of special language constructs must be justified.
When performing code reviews, the pre- and post- conditions for overloaded methods should be examined for
consistent behavior in the context of the code under review.
3.8.4 Implicit Conversion

Object-oriented languages support varying levels of implicit conversion of arguments. That is, arguments can be
implicitly converted to match the arguments of a method with the appropriate signature. The use of overloaded
operators and methods with arguments that are implicitly convertible can potentially result in problems by
associating calls with methods that do not share the same structure of pre-conditions and post-conditions.

Overloading can impact structural coverage analysis, and data and control flow analysis. Overloading can also
inhibit source code to object code traceability. See DO-178B [1] Table A-7 objectives 5 through 8 related to test
coverage.
3.8.4.2 Guidelines
To avoid potential problems involving the association of calls with methods, it is recommended that any family of
overloaded operators and methods whose arguments (signatures) are implicitly convertible to one another or from
one to another be required to have the same semantics. Formally, this means they must have the same structure of
pre-conditions and post-conditions. Informally, this means that they may share the same structure of test cases.
The user of any family of overloaded operators and methods whose arguments (signatures) are implicitly convertible
should: (1) perform the call using arguments that do not need to be converted, and (2) perform structural coverage
analysis applicable to the software level per DO-178B to ensure the proper method is being called.
3-45
Volume 3
3.9 Dead and Deactivated Code, and Reuse
3.9.1 Purpose
This section identifies issues, perspectives, and recommendations for addressing concerns associated with software
reuse, deactivated code, and dead code contained in aviation software applications as a result of using OOT
development processes, environments, and tool libraries. This section provides clarification for certain sections of
DO-178B and contains no new or additional guidance material.
3.9.2 Background
A major objective of OOT is to provide developers with the ability to create new software systems utilizing reusable
software components where a component may be comprised of classes, methods, procedures, packages, modules,
and so on. A reusable component often contains more software functionality than required by the system being
certified. The requirements and design of the reusable component should be more generic and cover more situations
if the component is truly reusable. If this extra functionality results in extra code in the system itself, then there may
be deactivated code with which to deal. Deactivated code will likely be present in any application that uses general
purpose software components and libraries, such as commercial off-the-shelf (COTS) software libraries provided
with a compiler, operating system or run-time environment, or OO development frameworks.
Particular areas of concern for deactivated code when utilizing OO techniques include:
• Compiler generated default methods (e.g., default constructors, destructors, and assignment operators)
• Completely unused classes
• Unused methods within classes
• Unused operations within overloaded methods
• Overridden methods due to use of sub-classes
• Existence of unexecuted paths because the entry conditions for those paths are never satisfied for a given
system
• Unused class attributes
• Unintended functionality or anomalous behavior
RTCA documents DO-178B [1] and DO-248B [2] provide guidance for reuse and modification of previously
developed software (PDS), deactivated code, and dead code. FAA Order 8110.49 [24] and AC 20-148 [34] also
provide additional guidance for the use of reusable software components, including life cycle data. PDS is included
in this discussion as it is one form of a reusable component. DO-178B guidance for upgrading software from a
previous development (such as DO-178A) still applies.
OO components taken from the non-avionics or non-commercial avionics industries and reused may have been
designed to be highly reusable, but, quite often, not all of the necessary software life cycle data is available. Again,
normal guidance from DO-178B applies in these situations. Generally, the product and process assurance artifacts
must be produced as part of a first software approval.
While DO-178B already provides guidance for deactivated and dead code, significantly more software component
reuse is expected through OOT. The following subsections provide elaboration of issues, which may become more
pervasive as more software components are reused through the application of OOT. The major issues for reuse, dead
code, and deactivated code are addressed in the following subsections. References to existing DO-178B guidance
are provided, as appropriate.
3-46
Volume 3
3.9.3 Reuse of Software Components

Reuse of software components may occur in three general ways. One way is through the use of “generic” or non-
application specific software components. Another approach, perhaps within the same system, is through the
creation of multiple, option-selectable, “custom”, or application specific components that implement variants of the
same algorithms. Finally, application specific components may be reused from one system in another similar, but
not identical, system.
Common examples of non-application specific reusable components are operating systems, standard libraries, math
libraries, and so on. Often these reusable components are developed by a third party to be highly reusable. The
components may or may not be written using OOT; this detail may be hidden to the application developer. These
non-application specific components may be provided as object libraries, which are linked into the system or
alternatively may be provided as source libraries in the form of an OO framework.
An example of reusable, option-selectable, application specific software components would be two slightly different
flight control algorithms which correspond to two different airframes. In this case, some of the classes are active in
one installation and deactivated in another.
Application specific reuse occurs frequently and is generally desirable. However, unintended functionality may
result. In one well-publicized case, an inertial reference system was reused from one series of launch vehicle to
another. Unfortunately the reused software was not modified to consider a different launch profile used by the latter
series of launch vehicles. This oversight resulted in the destruction of a launch vehicle early in the launch process.
Two of the previously noted approaches will likely result in some unused functionality, as well as deactivated code.
All of the approaches could potentially lead to unintended functionality. In all cases, the software and the supporting
software life cycle data must satisfy the objectives of DO-178B.

See DO-178B sections 2.4e, 4.2h, 5.4.3a&b, 11.1g, 11.10k, 12.1, 12.1.1, 12.1.2, 12.1.3, 12.1.4, 12.1.5, and 12.1.6.
Additional clarification is contained in DO-248B sections 3.8 and 3.70. Also, refer to AC 20-148 [34] and FAA
Order 8110.49 [24].
3.9.3.2 Guidelines
For standard libraries, the applicant should identify which Application Programming Interfaces (API) of the library
are used and unused in the system. For option-selectable software, the applicant should identify which classes and
methods within classes are used and unused for particular installations.
The use of individual subclasses, each of which represents a different option, is a good way to implement option-
selectable software. Only the appropriate sub-class is actually created in the system. The caller of the desired
algorithm need not know which algorithm is actually in the system – it is hidden from the other parts of the program.
Deactivated code for both forms of reusable components should conform to the Developer’s intent rule and the All
code verified rule (see below). In both cases, unused interfaces, classes, and methods will be tied to either derived
requirements or explicit, option-selectable requirements specified by the integrator. The derived requirements must
be verified and provided to the system safety assessment (SSA) process for consideration by the integrator. One
acceptable means to identify unused functionality to the integrator would be through the use of traceability matrices.
Verification data for derived requirements must satisfy the objectives of DO-178B. In addition, if the deactivated
classes and methods are built into the executable object code for the various installation options, analysis should be
performed to show that the deactivated code in a particular installation cannot be activated.
Developer’s intent rule: All code must be exercised by requirements-based tests (the requirements may be
derived). Code not associated with requirements should be carefully evaluated and either removed (if it is dead
code) or requirements should be developed for the code. Code which exists due to derived requirements needs to
be explicitly identified by the developer and the associated requirements must be noted as “derived” for inclusion in
the SSA process by the integrator.
3-47
Volume 3
All code verified rule: All code executed within any aircraft or engine configuration must be verified per applicable
DO-178B objectives, even if it can be demonstrated that a particular piece of code can never be activated in a
specific system. Note that requirements will be needed for all deactivated code associated with the various aircraft
or engine configurations (either derived requirements or explicit, option-selectable requirements specified by the
integrator).
Reused components must be associated with requirements for the new system. The level of reuse may vary and
include reused requirements data, reused code, and some reuse of verification data. However the reused data must
still satisfy the Developer’s intent rule and be consistent with the SSA. Objective evidence must exist to demonstrate
all reused data satisfies the objectives of DO-178B.
3.9.4 Requirements Traceability

Traceability can be challenging when utilizing OO techniques. Of particular issue is how dead code, deactivated
code, and active code can be differentiated and verified in OO software. Given a method that is not used, or a
method of an abstract class that is overridden in all subclasses, or an attribute that is never referenced, it may not be
clear if this was intentional for possible future use, an accident, or an error. That is, in terms of source code the
developer’s original intent may not be clear. It should be noted that additional traceability concerns are documented
in Section 3.11 of this Handbook volume. This subsection just focuses on traceability as it relates to reuse, dead
code, and deactivated code.

See DO-178B sections 5.4.3a&b, 5.5, 6.3.1a, 6.3.2a, 6.3.4e, 6.4.3, 6.4.4.1, 6.4.4.2, and 6.4.4.3. Also refer to DO-
248B sections 3.8, 3.28, and 3.70.
3.9.4.2 Guidelines
Requirements should be developed to a sufficiently low level of detail so that the traceability between requirements
and corresponding classes, methods and operators is clear. Tools to support OO software design and assist with
traceability relationships are highly recommended.
An applicant must demonstrate that an adequate process is in place to resolve dead code issues. A careful evaluation
of apparently dead code is needed to ensure that code that appears dead is actually dead and that it is not just a
documentation omission that makes it appear to be dead code. The Developer’s intent rule, as discussed in section
3.9.3.2, should provide the documentation to make this task much easier. The process also needs to cover overriding
of methods, including compiler generated default methods, operators, or other OO-specific instances where
confusion might arise due to the OO structure of the code.
The following points should be observed when dealing with deactivated code:
• Deactivated code which is intended to operate in any configuration used within an aircraft or engine requires
associated explicit requirements specified by the integrator or derived requirements created by the developer.
• The design and architecture life cycle data should account for deactivated methods and attributes.
• The documented traceability relationships should exist from the source code to either derived or explicit
requirements (deactivated code will have associated requirements; dead code, on the other hand, could exist due
to a design error and there would be no associated requirements).
• The completeness of requirements-based tests against structural coverage objectives should be confirmed
(derived requirements must be verified and will have associated source code; dead code could exist due to a
design error and there would be no associated requirements).
3-48
Volume 3
• The effect of derived requirements on the SSA process should be evaluated, and the effect of unintended
functionality which could be introduced by the derived requirements should be examined.
• Run-time examination of methods should be invoked when the software component is integrated into the final
target environment (control and data coupling/flow coverage are part of the DO-178B objectives; reusable
software component interfaces will need to be examined by the integrator).
Note that many OO languages provide features that, if fully utilized, will make the above activities much more
difficult (e.g., multiple inheritance). Developers may find it useful to develop standards which create a deterministic,
verifiable subset of a given OO language.
In the case of Level A software, object code not directly traceable to the source code will also be of concern, as
noted in Section 6.4.4.2b of DO-178B. Examples of non-traceable, compiler-generated object code could include
default constructors, default destructors, default copy methods, and default assignment methods. The developer
should provide explicit guidelines in terms of utilization of default methods and the appropriate verification
techniques in the planning and standards documents.
See section B.3.1 of Appendix B for an example of deactivated code that contains both deactivated methods and
attributes.
3.9.5 Certification Credit for Reused but Modified Class Hierarchy

When a previously approved class hierarchy is updated, it can be unclear how much reverification must be
performed. Current guidance requires that a software change impact analysis must be performed to determine the
extent of required reverification activities. The situation is no different for OOT. See section B.3.2 of Appendix B
for an example of how this class hierarchy change can have a subtle effect without any obvious changes to code.

See DO-178B [1], sections 11.3h and 12.1. Also, refer to FAA Order 8110.49 [24] and AC 20-148 [34].
3.9.5.2 Guidelines
This issue applies to a certification project when class hierarchies are not being completely retested. In this case,
applicants must provide a regression analysis of all changes to a class hierarchy in the form of flattened class
hierarchy. More succinctly, the applicant should adhere to the following rule:
Flattened class reverification rule: When a change to an element of a class occurs, reverification of all subclasses
whose flattened form contains the changed element is recommended.
A clear trace of the subclasses that are affected by changes in base classes could be created either manually or with
tools.
If full retesting is performed, an alternative (and recommended) approach is to apply the guidelines described for the
Inherited test case rule (see section 3.3.8.3). This rule states that “every test case appearing in the set of test cases
associated with a class should appear in the set of test cases associated with each of its subclasses.” This conforms to
the Liskov Substitution Principle [7] and will ensure the behaviors of the inherited methods are appropriate for each
subclass.
3.9.6 Changes in the Status of Deactivated Code Versus Actively Used Code
When software components are reused, they are typically used in a slightly different manner than in the original
usage. What was considered “deactivated code” in the original usage may become “active code” in the subsequent
usage. Likewise, active code for the original usage may become deactivated code in the subsequent usage. This
section considers the status change of active and deactivated code.
3-49
Volume 3

See DO-178B [1] sections 5.4.3a, 6.4.4.2c, 11.1g, 11.10k, 12.1.2a, and 12.1.3e. Also, refer to AC 20-148 [34].
3.9.6.2 Guidelines
When previously developed software is submitted by an applicant for a new certification, changes in the status of
deactivated code versus actively used code must be documented. Since the reusable components should follow the
All code verified rule (see section 3.9.3.2) as previously discussed, the components should have already have been
verified to obtain regulatory approval. However, in order to gain regulatory approval for the previously deactivated
code, the integrator will need to document and verify the interfaces associated with the newly activated code. This
may drive requirements, design, code, and verification changes from the previously approved baseline.
3.9.7 Service History Credit and Deactivated Code

Software verification data may be valid for a particular certification basis and installation but not valid for a
different certification basis and installation. Sometimes applicants may apply for service history credit rather than
re-doing the artifacts to comply with the certification basis. However, granting of service history credit is rarely
straightforward.
For example, assume an entire class hierarchy is developed, complies with DO-178B objectives, and has been
approved by certification authorities. A portion of this class hierarchy is approved in a certified system and has 10
years of service history. Ten years later, a new system is developed (and potentially the regulatory guidance or
certification basis has changed) and it is now desired to use portions of the previously unused class hierarchy. It is
not clear that one can use service history at this point or the old certification as a baseline, because of the activation
of previously inactive code.

See DO-178B [1] section 12.3.5. Also, refer to DO-248B [2] sections 3.19 and 4.4 and Order 8110.49 [24].
3.9.7.2 Guidelines
Service history credit may be granted for deactivation mechanisms with appropriate service history data.
The applicant should adhere to the following rule:
Service history rule: Service history credit may only be given for activated code and deactivation mechanisms that
have been actually executed during the service experience period. The target environment, certification basis, and
SSA will need to be considered in this process.
Integrators and regulators need to be aware that deactivated code in a previous certification basis could easily
become active in a newer certification effort. Previously identified derived requirements for deactivated code that
were provided for the previous SSA process may assist in this activity. Integrators and regulators need to review the
documentation for code that has now become active and ensure that, at least for that particular code, proper
certification artifacts and life cycle data exist and any new system hazards have been addressed. Code that becomes
deactivated in a later certification may be left in the executable as long as the guidelines for reuse are followed per
section 3.9.3.2 of this volume. Note that section 4.4 of DO-248B [2] provides additional insight into the issue of
service history.
3-50
Volume 3
3.10 Object-Oriented Tools
3.10.1 Purpose
This section addresses issues impacting compliance with DO-178B objectives for traceability, configuration
management, development, verification, structural coverage analysis (including data coupling and control coupling
analyses), dead code, and deactivated code when object-oriented development and verification tools are used.
Additionally, tool issues related to dynamic dispatch, polymorphism, inheritance, frameworks and automatic code
generation are discussed. Tool qualification with regard to OOT is also discussed. As with most of the sections in
this Handbook, UML terminology and examples are used, since UML is the predominant OO modeling language
currently being considered by the aviation community, and other modeling languages present similar issues.
3.10.2 Background
Current OO tools (either internally developed or commercially procured) may not fully satisfy DO-178B objectives
with regard to configuration management, development, and verification. This section provides guidelines for OO
tools to assist applicants in satisfying DO-178B objectives. OO may present new challenges to tool vendors and
applicants that have not been prevalent with structure-based development. The specific OO tool issues and
guidelines are presented in the following subsections; however, the more general concerns are:
1. Addressing verification coverage for OO software;
2. Using OO frameworks, automatic code generators, dynamic dispatch, polymorphism, and inheritance; and
3. Addressing requirements management and traceability during OO development.
3.10.3 Traceability When Using OO Tools

Specific traceability issues and guidelines are addressed in sections 3.11.4 and 3.11.6 of this Handbook. OO tool
manufacturers should consider the issues presented in these sections and implement the suggested guidelines.
3.10.4 Configuration Management When Using Visual Modeling Tools

When using OO tools to develop software requirements, design, and implementation, it is beneficial to work at the
visual model level, especially when using UML. When working with OO tools, configuration management might be
done at the modeling level (i.e., diagrams). Concerns arise if the OO tools can introduce subtle errors into the
diagrams. Since the model contains the software requirements and design, there must be some checks or assurance
that the raw data files (model files) are not changed by the tool when saving, opening, checking files into the
configuration management (CM) system, or checking files out of the CM system. Some of the OO tools may
introduce errors at the modeling level when opening, saving, or closing files. If the output of the tools is used by a
subsequent process or configuration item, they may require special attention to establish determinism.

Section 7 and Table A-8 of DO-178B [1] provide guidance on the software configuration management process. Files
that are part of the software “type design” (see Section 9.4 of DO-178B) should be controlled to Control Category 1
(CC1) criteria (see Section 7.3, Table 7-1, and Table A-2 of DO-178B). It is likely that the visual models and charts
and their corresponding files should be controlled to CC1, as they represent the Software Requirements Data and the
Software Design Description (see Sections 11.9 and 11.10 of DO-178B). Guidance for tool qualification is in
provided in Section 12.2 of DO-178B.
3-51
Volume 3
3.10.4.2 Guidelines
The developer should control the visual models, charts, intermediate translations of the models, and the code
generated from the model. It is important to understand that there are two parts to UML: (1) a graphical notation,
and (2) an underlying model representation with well-defined semantics. The diagrams are simply views of the
underlying model, and are physically separate from it. Each model element may appear in several diagrams or none
at all. In the extreme, a UML model need not have any graphical representation at all. If the tools used to develop
the models will automatically track the different components of the software requirements and design, then the tool
may need to be qualified, unless the tool can be shown to be deterministic and the output of the tool is verified.
Visual modeling tools should be shown to be deterministic and preserve software life cycle data integrity. Software
visual modeling tools may need to add integrity checks to their raw data files to ensure that when the tool opens or
closes a file, the file’s integrity is maintained. For example, checksums or printed copies of the models can be
compared to the electronic visual models to ensure integrity or electronic copies can implement integrity checks
(e.g., cyclic redundancy checks) of the files computed and compared to ensure the tool does not introduce errors.
As with any software life cycle data, DO-178B configuration management concepts apply to the artifacts of the OO
tools (e.g., frameworks, model files, manual or automatic generated code, and the software environment).
3.10.5 Visual Modeling Tools Frameworks

Current visual modeling tools that are used for OO development make use of frameworks for automatic code
generation, replacing tedious programming tasks. Frameworks may include patterns, templates, generics, and classes
in ways requiring new verification approaches. The tool’s framework may or may not enforce requirements, design,
and coding standards. The tool’s framework may or may not ensure that the relevant objectives for software
requirements, design, and source code are achieved for all software to be included in the final software to be
embedded in the airborne system.
3.10.5.1 Relevant DO-178B Sections and Objectives

Sections 4.4, 4.4.1, and 4.4.2 of DO-178B [1] contain guidance for planning the software development environment
to be used to develop the airborne software, including some language and compiler considerations. The environment
and tools to be used are specified in the Software Life Cycle Configuration Index (see section 11.15 of DO-178B).
Section 12.2 of DO-178B provides tool qualification criteria for software development tools. Since components of
the “framework” may end up embedded in the airborne software, guidance related to previously developed software
should also be considered [24].
3.10.5.2 Guidelines
Some of the OO tools provide a framework to automate and generate the source code from the UML model and
framework “libraries” of patterns, templates, generics, and classes; replacing the tedious coding tasks for the user.
This will add code or objects (i.e., some tools may generate dynamic constructors, destructors, queues, stubs,
skeletons, and other features). Engineers should understand the tools that are used to develop the airborne
application and what components of the framework are ending up embedded in the airborne software. The
framework and the tool may need to be qualified, and components of the framework embedded in the airborne
application should be assured to the same level as the airborne application.
3.10.6 Automatic Code Generators

Current visual modeling tools that are used for OO development provide a capability to generate source code
directly from UML models. Most of the existing UML tools today can use visual modeling diagrams to construct
models and generate source code from these models. Figure 3.10-1 illustrates the generation of code using visual
modeling tools. The level of source code generation depends on the tool and on the user of the tool. Some of the
tools support “full” automatic code generation and some generate only the skeleton of the code. For “full” automatic
3-52
Volume 3
code generation, the user may also need to produce additional information (e.g., state charts, activity diagrams,
and/or UML action semantics) to specify additional detail of their implementations.
Figure 3.10-1 Code Generation using Visual Modeling Tools
When discussing automatic code generation, this section assumes that the tool is an automatic code generator that
generates source code. Then the source code is provided to a compiler that generates the object code. The object
code can then be linked to generate the executable object code, and then loaded (or burned) into computer memory
for execution. The tool may automate this process by providing one “make” file to do all of the steps. Although the
code generated has to comply with the coding standards, the user may or may not have control over the code
generator itself. This may be a problem, if the code generated does not comply with the coding standard.

See DO-178B [1] sections 5.5, 6.4.4, and 12.2.
3.10.6.3 Guidelines
Most of the OO UML-based tools use some type of automatic code generation. Since the UML is a formally defined
language, the tools can take the class diagrams, object model diagrams, state charts, and activity diagrams and
generate the source code, or at least the structure. The code generator is a software development tool that may need
to be qualified to the same level as the airborne software application (see section 12.2.2 of DO-178B [1] and FAA
Order 8110.49 [24]). If qualification is required, it will be of a defined configuration of the tool.
If the automatically generated code will be manually modified, the applicant should define and implement a process
for controlling the automatically generated code, manually modifying the code, and keeping track of all changes.
3-53
Volume 3
3.10.7 Structural Coverage Analysis Tools

Performing structural coverage analysis requires huge resources when performed manually; therefore, developers
have become increasingly reliant on tools that measure the structural coverage and identify “gaps” in that coverage.
The current structural coverage tools available may not “be aware of” or have visibility into the internals of inherited
methods and attributes and polymorphic references supported with dynamic binding. This lack of internal visibility
makes it difficult or impossible to provide a reliable measurement of the structural coverage achieved by the
requirements-based testing. Sections 3.12.4 and 3.12.5 of this Handbook provide guidelines for structural coverage
when using inheritance and dynamic binding, respectively.
3.10.8 Structural Coverage Analysis for Inheritance

Current tools performing structural coverage analysis of inheritance fall into two classes, as identified in section
3.12 of this Handbook:
• Those that perform concrete coverage analysis, and
• Those that perform context coverage analysis.
If a context sensitive structural coverage analysis tool is used, then, where reverification was not performed (i.e.,
reverification was not necessary), an explanation will need to be given for the shortfall in the structural coverage
analysis coverage report. The Hierarchical Incremental Testing (HIT) analysis can be used to document that
reverification was not necessary.
If a context-insensitive (i.e., concrete) structural coverage analysis tool is used, the process will need to be
augmented to ensure the appropriate reverification of inherited features occurs, with the corresponding structural
coverage of the inherited feature in the inherited context. The HIT analysis can be used to identify the necessary
reverification.

See DO-178B [1] Table A-7 objectives 5, 6, 7 and 8, and sections 6.4.4.2 and 6.4.4.3 regarding structural coverage
analysis. Also, reference related DO-178B sections 6.3.6, 11.3c(2), 11.3d, 11.3g, 11.13, and 11.14.
3.10.8.2 Guidelines
Both applicants and certification authorities need to understand which form of analysis for inheritance their
structural coverage analysis tools perform. If the tool performs analysis on concrete methods only, then the
verification process will need to identify where additional verification is needed, and that the appropriate tests are
run and the appropriate structural coverage is obtained. If the tool performs analysis on both concrete and inherited
methods, then the verification process will need to identify where the tool reported that non-coverage was not
needed. Additionally, the structural coverage tool may need to be qualified as a software verification tool.
Guidelines for structural coverage are described in section 3.12 of this Handbook.
3.10.9 Structural Coverage Analysis for Dynamic Dispatch

Two specific issues of concern for structural coverage are related to dynamic dispatch. The first issue exists because
many current structural coverage analysis tools do not “understand” dynamic dispatch; i.e., they do not treat it as
equivalent to a call to a dispatch routine containing a case statement that selects between alternative methods based
on the run-time type of the object. The second issue is that control and data coupling analysis requirements of DO-
178B are more complex when dynamic dispatch is used.
As identified in Section 3.12 of this Handbook, there are multiple approaches to the structural coverage analysis of
dynamic dispatch (polymorphic call). Section 3.12 indicates that the proper verification of polymorphism and
dynamic dispatch is still an active research area. Until a final answer is obtained, a minimal requirement should be
the execution of all polymorphic calls, and the execution of all possible dispatches collectively (i.e., coverage of all
3-54
Volume 3
entries in the dispatch table) [26]. Unfortunately, current tools performing structural coverage of polymorphism with
dynamic dispatch only measure the execution of the polymorphic call. Guidelines for structural coverage are further
described in section 3.12 of this Handbook.

See DO-178B [1] sections 6.4.4.2 and 6.4.4.3. Also, reference related sections 6.3.6, 11.3c(2), 11.3d, 11.3g, 11.13,
and 11.14 of DO-178B.
3.10.9.2 Guidelines
Structural coverage analysis tools for OO languages should measure coverage for each polymorphic call and each
entry in the dispatch tables. Unfortunately, current tools performing structural coverage of polymorphism with
dynamic dispatch only measure the execution of the polymorphic call, and thereby support only the first part of the
recommended coverage analysis. These tools will need to be augmented with other analyses or tools in order to
support the second part of the recommendation (i.e., coverage of every entry in the dispatch tables). For example,
this can be achieved as a result of using the substitutability test guidelines described in sections 3.3.6 through 3.3.10
of this Handbook (i.e., covering every method table entry).
Compliance with the section 3.3.6 through 3.3.10 guidelines should be combined with structural coverage objectives
(e.g., executing every polymorphic call). Additionally, the structural coverage tool may need to be qualified as a
software verification tool. Guidelines for structural coverage are further described in section 3.12 of this Handbook.
3-55
Volume 3
3.11 Traceability
3.11.1 Purpose
This section addresses issues influencing compliance with DO-178B objectives regarding traceability, when OO
development and verification methods and tools are used. As with most of the sections in this Handbook, UML
terminology is used, since UML is the predominant OO modeling language currently being considered by the
aviation community, and other modeling languages present similar issues. In this section, it is assumed that the
software development process starts with a set of system level requirements allocated to software. These
requirements can be functional requirements written in text, a requirement model, a set of Use Cases, or even a
combination of these approaches.
3.11.2 Background
Current OO methods and tools (either internally developed or commercially procured) may not satisfy the DO-178B
objectives related to traceability. This section documents the issues related to traceability when OO methods and
tools are used and defines some guidelines for addressing those issues.
Traceability is an important aspect of meeting DO-178B objectives. Section 3.71 of DO-248B [2] states that
traceability is used to:
1. Enable verification of implemented system requirements, high-level requirements, and low-level requirements;
2. Verify the absence of unintended function and/or undocumented source code;
3. Provide visibility to the derived requirements. Traceability applies to both the verification and configuration
management processes.
In general for OO, traceability is complicated by:

• Functional requirements specified by Use Cases;
• Dynamic dispatch, polymorphism, and inheritance; and
• Overloading and overriding functionality.
3.11.3 Overall Approach and Related DO-178B Objectives

This section focuses on traceability that provides the evidence of a link between a requirement and its
implementation, including the identification of derived requirements. Additionally, the link between UML artifacts
and source code is discussed. DO-178B [1] defines traceability as: “The evidence of an association between items,
such as between process outputs, between an output and its originating process, or between a requirement and its
implementation.”
The verification process provides traceability between the implementation of the software requirements and
verification of those software requirements:
• The traceability between the software requirements and the test cases is accomplished by the requirements-
based coverage analysis.
• The traceability between the code structure and the test cases is accomplished by the structural coverage
analysis.
DO-178B guidelines require traceability between system requirements and software requirements to enable
verification of the complete implementation of the system requirements. The low-level requirements should be
traced to the high-level requirements to ensure full implementation of the high-level requirements and to verify the
architectural design decisions made during the software design process. In addition, traceability between source
3-56
Volume 3
code and low-level requirements should be provided to enable verification of the absence of undocumented source
code and verification of the complete implementation of the low-level requirements. Traceability from system
requirements to high-level requirements to low-level requirements to code also helps identify derived requirements
and ensure they are passed up to the system safety assessment process.
3.11.3.1 Related DO-178B Objectives

The following DO-178B objectives are directly related to traceability:
• Objective 6 of Table A-3;
• Objectives 3 through 8 of Table A-7; and
• Objective 2 of Table A-8.
Other objectives within DO-178B are indirectly related to traceability. The following subsections identify specific
OOT issues that make it difficult to comply with DO-178B’s objectives. Each issue is discussed and recommended
guidelines to address the issue are provided.
3.11.4 Tracing to Functional Requirements

Traceability of functional requirements through implementation may be lost or difficult with an OO design or
supporting life cycle. A mismatch between function-oriented requirements and an object-oriented implementation
may cause traceability problems. For example, providing traceability from a code sequence to a specific requirement
may be difficult. Tracing to a "logical view" may not be sufficient.
3.11.4.1 Guidelines
The software development process usually starts with a set of system level requirements allocated to software.
These requirements can be documented using text, requirements model, or Use Cases. In UML, Use Cases represent
the functional requirements of the system. These functional requirements can be traced to the system level
requirements that can be documented in text. The software functional requirements will be decomposed to create the
low-level requirements and any derived requirements necessary for the implementation of the software. Every
method or a message reception in every object in the software should be traced to its requirement.
Figure 3.11-1 illustrates an example traceability approach for an OO-based system. There are a number of ways to
specify requirements. The user may choose to specify requirements in text, in Use Cases, and/or in a requirements
model. A requirements model may include a combination of requirements-level Use Cases (customer validated) and
a class model of the system. The user may specify the requirements for a class as Statecharts. In this case, the
transition and the states of each Statechart could become the low-level requirements.
Whatever method the user chooses to specify the requirements, they need to be clearly tagged. Figure 3.11-1 shows
that design, implementation, and testing elements are traced to the requirements.
In the design stage, instances are traced to classes. Classes may have relations and should be traced to each other. If
class interfaces are specified as contracts (with pre-/post-conditions for operations and class invariants), then tools
can be used to help trace the relationship between classes and between operations, as well as check them for
consistency and correctness. Each operation or message provided by the instance should be traced to the instance.
The implementation files should also be traced to the instances.
Additionally, the test model should be traced to the requirements. This section assumes that test classes will not have
relations and each test class will have only one instance.
3-57
Volume 3
Figure 3.11-1 Overview of Traceability
3.11.5 Complex Class Hierarchies and Relationships

Class hierarchies can become overly complex, which complicates traceability. Generalization, weak aggregation,
strong aggregation, association, and composition are some of the relations that can be used to create the class
diagrams.
3.11.5.1 Guidelines
The realization of a Use Case may be specified by a set of collaborations. The collaborations define how instances in
the software interact to perform the sequences of the Use Case. Traceability should be done at the instance level.
When the user creates an instance, they must know what that instance is traced to and where its requirements are
coming from. The instances themselves must be traced to their classes. The class and all of its contents and relations
should be traced to a higher-level class or to a Use Case. Since the high level classes are the realization of Use
Cases, which is the functional requirements of the software, the high level classes should be traced to the Use Cases
that they implement. The Use Case must be traced to a system level requirement or a higher-level Use Case. Not all
of the UML diagrams must be traced; tracing all of the objects in the software should be sufficient. Only the
diagrams and UML modeling elements that add some requirements or affect the generation of the executable should
be traced. Class hierarchies and their relations need to be flattened and every class should have clear traceability to
its high level class, Use Case, or text requirements.
The following relations affect traceability in the following ways:
• Association is the semantic relationship between two or more classes that specifies connections among their
instances. In this case, there is no need to trace associations, since they only indicate that one class can talk to the
3-58
Volume 3
other. Each class should have its own traceability to its requirements. Association classes are treated as regular
classes and they will have to be traced to the requirements that caused their existence.
• Aggregation is a special form of association that specifies the whole-part relationship between the aggregate
(whole) and a component (part). Aggregation will affect traceability, because the instance of the aggregate
(whole) will have to be traced to both the whole and the part requirements. The part will only have to be traced to
its own requirements.
• Generalization is the relationship between a more general element and a more specific element. The specific
element is fully consistent with the more general element. An instance of the more specific element may be used
where the more general element is allowed. Generalization will affect traceability, because any instance of the
specific element should be traced to its own requirements. Additionally, it should be traced to the requirements
of the general element from which it is inherited.
Normally, traceability is limited to the UML elements and does not include diagrams.
3.11.6 OO Design Notation and Traceability Ambiguity

When working with UML or OOT in general, the requirements, design, and implementation may have multiple
views. Each view may add or show different information. Unfortunately, many of the UML tools do not currently
provide a traceability mechanism. Additionally, UML is a language that was written to provide the user with
maximum flexibility, which in the safety-critical world might reduce controllability.
3.11.6.1 Guidelines
Each UML element (e.g., class, method, object, Use Case) should have traceability, but not every diagram
containing those elements needs to be traced. For example, an object model diagram may not need to be traced, but
every object in the diagram should be traced to its own requirements. The developer should have a process that
enforces the guidelines for traceability, some of the basic guidelines include:
• Every object in the software should be traced to its class.
• Every class in the software should be traced to its superclass.
• Every operation call should be traced to its class.
• Each overridden or overloaded operation should be traced to some requirement(s) or Use Case (s).
• Every class or superclass should be traced to the Use Case (s) that they realize.
3.11.7 Traceability and Dynamic Binding/Overriding

Establishing functional requirements coverage of a class is difficult to assess when using dynamic binding and
overriding. Specifically, it may be difficult to know if a class has been fully exercised.
3.11.7.1 Guidelines
Traceability should be performed to the object level. Every operation associated with an object should be traced.
This will provide traceability to the implementation of any operations or methods that have been overridden.
“component-based design” or “design by contract” approaches may be used.
3.11.8 Dead and Deactivated Code

The difference between dead and deactivated code is not always clear when using OOT. Without good traceability,
identifying dead versus deactivated code may be difficult or impossible.
3-59
Volume 3
3.11.8.1 Guidelines
If the OOT traceability is done to the operation level, then it will be possible to identify dead code at that level. This
will not cover code within a operation itself. OO concepts encourage building reusable classes. The idea of reuse
means that classes are built with generic functional requirements that can be used in multiple systems. In this case,
the reusable library may include some deactivated or dead code in a specific application. Traceability analysis
should be performed on the reusable library in order to identify dead and deactivated code. Dead and deactivated
code is further addressed in section 3.9 of this Handbook.
3.11.9 Many-to-Many Mapping of Requirements to Methods

The isolation of operations in classes may result in a mapping of requirements to OOT models in which:
a) A given requirement may map to a number of operations spread over several classes;
b) The same operation, in a given class, may contribute to more than one requirement.
This issue applies to the mapping of requirements to operations at all levels of OO modeling (during both analysis
and design).
3.11.9.1 Guidelines
Each operation within an instance should be traced to its requirements. The operation can have more than one
requirement, but it should not have more than one Use Case. This is the normal case for a Use Case driven
development approach; however, it should be noted that it is a good practice to reduce the complexity of traceability
even if another approach is used. In this Use Case approach, we may have one Use Case traced to many operations.
The traceability data for each Use Case should contain the references to all of the operations within the objects that
implement that Use Case.
If it is necessary to trace one operation to multiple Use Cases, then Use Case relationships may be used to help
eliminate redundancy and support traceability.
3.11.10 Iterative Development

Iterative development is often desired in OO implementation. Each iterative cycle has its own requirements
(normally a set of Use Cases), design, implementation, and test. There is a risk of losing traceability when using
iterative development. This can be caused by adding or changing requirements, design, or implementations.
3.11.10.1Guidelines
Iterative development is most effective when each iterative cycle is completed prior to starting the next cycle. The
iteration should have its own requirements, design, implementation, and test. Completing traceability for each
iterative cycle is recommended, and an impact analysis should be done on the current iteration, whenever the
requirements from the previous iterations are changed.
3.11.11 Change Management for Reusable Components

Reusability is one of the objectives of OO development, but reusable components may be hard to trace because they
are designed to support multiple usages of the same component. Reusable components may also have functionality
that may not be used in every application.
3.11.11.1Guidelines
Traceability must be done for each application regardless of its usage of reusable components. When reusable
components are used, the traceability should show implementation and verification mapping for all requirements, or
3-60
Volume 3
as a minimum, provide verification and justification for the unused functionality. See section 3.9 of this Handbook
for further guidelines on reuse.
3-61
Volume 3
3.12 Structural Coverage
3.12.1 Purpose
This section addresses issues concerning compliance with the structural coverage objectives given in DO-178B [1]
and clarified in DO-248B [2] for certain features of OOT.
3.12.2 Background
Structural coverage, as one of the adequacy measures of requirements-based testing, will not be eliminated with
OOT. Most of what has been learned in the testing of traditional (functional) systems still applies within OOT.
However, traditional functional testing with traditional structural coverage metrics based on source code may not be
adequate for OO software [25][33][34]. In particular, inheritance and polymorphism with dynamic dispatch are two
OOT mechanisms that present problems with verification in general, and testing and structural coverage in particular
[25][34][19].
The FAA has already sponsored some research in this area [26]. Not only were issues identified for inheritance and
polymorphism with dynamic dispatch, but the broader issue of data coupling and control coupling was also raised.
Research is ongoing in this area.
3.12.3 Overall Approach and Related DO-178B Objectives

This section is intended to provide an approach for addressing DO-178B objectives for structural coverage when
using the OO features of inheritance and polymorphism with dynamic dispatch. The broader issue of data coupling
and control coupling is also mentioned as a place-holder. The section is related to DO-178B [1] sections 6.4.4.2 and
6.4.4.3; as well as related sections 6.3.6, 11.3c(2), 11.3d, 11.3g, 11.13, and 11.14. In particular, this section will
provide guidelines to assist with compliance to objectives 5, 6, 7 and 8 of DO-178B Table A-7.
3.12.4 Structural Coverage of Inheritance

The issue concerning the adequate verification of inheritance is whether fully verified inherited features, particularly
methods, need reverification in the subclass. It turns out that some, but not all, inherited features require retesting
(and coverage) within the subclass [27][28, pp. 249-267)][29, pp. 164-213]. The Hierarchical Incremental Testing
(HIT) of class structures approach was developed to identify where retesting of inherited features is necessary, and
where it is not [27]. Table 3.12-1 presents a summary of HIT. The first column of Table 3.12-1 identifies the
incremental change made in the subclass. There are three changes made in subclasses that impact the testing
performed on the superclass and are summarized below:
• A method can be inherited. If there are no direct or indirect polymorphic references affecting this method, then it
remains unchanged in the purest sense, and no retesting is needed. If there are polymorphic references affecting
the method, then the method can be considered to have a change in integration, and some retesting will be
necessary.
• A method can be overridden. This is the case when a new method is provided in the subclass for an existing
method in the superclass.
• A new method can be added. This includes either the addition of a new operation and method in the subclass, or
the addition of a method for an abstract operation in the superclass.
In addition, new attributes can be added in the subclass. The impact of these new attributes is through the new or
overridden methods that access those attributes. The second column of Table 3.12-1 identifies the testing impact in
the subclass for the incremental change.
3-62
Volume 3
Incremental Testing Impact

Change
Inherited No retesting is needed if the method interacts, directly or indirectly, only with inherited methods
(unchanged) and attributes.
Method Limited retesting is needed when the method interacts, directly or indirectly, with new or
overridden methods or attributes. Existing tests that deal only with inherited methods and
attributes are still applicable, along with the coverage analysis for those tests. Some existing
tests can be reused, though new coverage analysis will be needed for those tests. Some new tests
will be needed, along with the coverage analysis for those tests.
Overridden Extensive retesting and coverage analysis is needed. Many existing tests can be reused, though
(changed) new coverage analysis will be needed for those tests. For most of these tests, the requirements
Method coverage should still be applicable since only the implementation has changed. Some new tests
will be needed, along with the coverage analysis for those tests.
New Method Complete testing and coverage analysis is needed. All new tests will be needed, along with the
coverage analysis for those tests.
Table 3.12-1 Hierarchical Incremental Testing Summary
One of the techniques introduced for the understanding of inheritance is that of the flattened class. In a flattened
class, all inherited features are represented along with the features explicitly defined within the subclass. Figure
3.12-1 illustrates a normal inheritance hierarchy on the left, and a flattened inheritance hierarchy on the right. In the
flattened form, all inherited attributes and methods appear in italics.
Class_1 Class_1
Attribute_1 Attribute_1
Method_1() Method_1()
Class_2 Class_3 Class_2 Class_3

Attribute_2 Attribute_3 Attribute_1 Attribute_1
Method_3() Method_1() Method_1()
Inheritance Hierarchy Flattened Inheritance Hierarchy
Figure 3.12-1 Inheritance
3-63
Volume 3
3.12.4.1 Guidelines
Requirements-based testing and requirements and structural coverage of the flattened class is a recommended
practice for OO [11]. A number of researchers recommend class flattening, as they believe the savings from trying
to save tests will be negated by the effort of the analysis, plus the circumstances where savings are possible will be
very rare in real systems. Binder states: “Retesting can be safely skipped only when (1) there is no possible data
flow or control flow from or to the superclass and subclass methods, or (2) the subclass is null and simply renames
the superclass” [11, p. 510]. The difference between covering the class, and covering the flattened class for
Method_1 from Figure 3.12-1 is demonstrated in Figure 3.12-2 and Figure 3.12-3.
In Figure 3.12-2, complete coverage is shown for Method_1 as a composite of the coverages obtained within
Class_1, Class_2, and Class_3. This is referred to as coverage of concrete features.
Class_1
Method_1() Structural
Coverage
Report
Class_2 Class_3
Figure 3.12-2 Concrete Coverage
In Figure 3.12-3, only partial coverage is shown for Method_1 in the three different classes. This is referred to as
context coverage.
3-64
Volume 3
Class_1
Method_1() Structural
Coverage
Report
Class_2 Class_3
Figure 3.12-3 Context Coverage
DO-178B does not require the context sensitive verification required by flattened classes. Always flattening the
class hierarchy for verification, recommended in [26], will lead to some over-verification of certain inherited
features (e.g., simple get and set methods for attributes). Fortunately, HIT can be used to prevent the over-
verification by identifying those methods that do not need any reverification. The HIT analysis could be automated,
incorporated into structural coverage analysis tools, and qualified.
3.12.5 Polymorphism with Dynamic Dispatch

Polymorphism with dynamic dispatch is a mechanism within OOT whereby a name can refer to objects of different
classes. The issue concerning the adequate verification of polymorphism with dynamic dispatch is whether the
method with the polymorphic call has been adequately integrated with all of the methods the polymorphic call can
dispatch to. Polymorphism with dynamic dispatch is illustrated in Figure 3.12-4 and Figure 3.12-5. Figure 3.12-4
presents the flattened class from Figure 3.12-1. Recall that in a flattened class, all inherited features are italicized.
3-65
Volume 3
Class_1
Attribute_1
Method_1()
Method_2()
Class_2 Class_3
Figure 3.12-4 Flattened Inheritance
Assume that in our system we have an “Object_X” that can refer to objects of either Class_1, Class_2, or Class_3.
When we see the call to “Object_X.Method_2()” in the source code for our system, different Method_2’s will be
called depending on the run-time class of the object that “Object_X” refers to. This is depicted graphically in Figure
3.12-5.
Figure 3.12-5 shows that the reference “Object_X.Method_2()” can dispatch to either Class_1.Method_2() or
Class_2.Method_2(). Class_1.Method_2() will be called if “Object_X” refers to an object of either Class_1 or
Class_3. This is because Class_1.Method_2() was defined in Class_1 and inherited in Class_3. Class_2.Method_2()
will be called if “Object_X” refers to an object of Class_2. This is because Class_2.Method_2() was defined in
Class_2, where it overrode the definition of Class_1.Method_2(). Polymorphism with dynamic dispatch has made
some of the control flow, and thereby the associated data flow, implicit in the source code rather than explicit.
Object_X
Method_2
Class_1.Method_2() Class_2.Method_2()
Figure 3.12-5 Dynamic Dispatch
3.12.5.1 Guidelines
Numerous approaches have been proposed for the adequate testing of polymorphic calls:
1. The first approach says that execution of the polymorphic call is sufficient. This approach confines testing to the
level of abstraction of the source code (i.e., every statement has been executed). This approach assumes that the
3-66
Volume 3
underlying implementation hides no details requiring verification below the abstraction level of the source code.
This approach treats dynamic dispatch as being equivalent to static dispatch. Watson and McCabe refer to this as
the “optimistic approach” [30, pp. 62-63]. DO-178B currently does not require verification below the level of the
source code for software at Levels C and B. DO-178B does, however, require verification beyond the source
code for software at Level A.
2. The second approach says to treat a polymorphic call as a case/switch statement [31]. This approach assumes that
the underlying implementation is important. This approach can be implemented in two major ways. The first way
is to recognize that the “case/switch statement” is repeated in multiple places. Testing and coverage could be
obtained from the collective executions of all the calls (inlined call to the case/switch statement). The second
way is to exhaustively test and cover the feasible “branches” at each call, which makes this approach equivalent
to the next one.
3. The third approach says that execution of every possible dispatch is required. Binder states “Although a
polymorphic message is a single statement, it is an interface to many different methods. Just as we would not
have high confidence in code for which a only a small fraction of the statements or branches had been exercised,
high confidence is not warranted for a client of a polymorphic server unless all the message dispatches generated
by the client are exercised” [29, p. 438]. Watson and McCabe refer to this as the “pessimistic approach” [30, p.
63]. This approach can also be implemented in two ways. The first way is to look at polymorphic messages only
and ignore polymorphic parameters. The second way is to consider the polymorphic parameters. This brings in a
level of complexity that the next approach attempts to deal with.
4. The fourth approach says that execution of a “mathematically significant” subset of all possible dispatches is
required [32]. This approach attempts to mitigate the enormous number of tests and required effort that can result
from the exhaustive execution of all possible dispatches.
5. The fifth and final approach says that we need to execute every polymorphic call, and for one call site that forms
an equivalence class with all others dispatching on the same base class, require execution of every possible
dispatch. Note that the exhaustive dispatching can be done in a test driver instead of the application. This is
another attempt to mitigate the exhaustive approach. Watson and McCabe refer to this as the “balanced
approach” [30, pp. 63-64].
As the previous discussion has made clear, the proper verification of polymorphism and dynamic dispatch is still an
active research area. Until a final answer is in, a minimal requirement should be the execution of all polymorphic
calls, and the execution of all possible dispatches collectively (i.e., coverage of all entries in the dispatch table)
[21][26].
Current tools performing structural coverage of polymorphism with dynamic dispatch only measure the execution of
the polymorphic call, and thereby support the first approach discussed previously. These tools support the first part
of the recommended approach. These tools will need to be augmented with other analyses or tools in order to
support the second part of the recommendation.
3.12.6 Data Coupling and Control Coupling

Data coupling and control coupling relationships can be far more complicated and obscure in OOT than they are in
traditional (functional) systems/software.
One impact on data coupling and control coupling is in the nature of OOT. OOT encourages the development of
many small, simple methods to perform the services provided by a class. Often the control flow is moved out of the
source code through the use of polymorphism and dynamic dispatch. In essence, the control flow, and thereby the
control coupling, will become implicit in the source code, as opposed to being explicit. There is a similar effect on
the data flow, and thereby the data coupling.
OOT also encourages hiding the details of the data representation (i.e., attributes) behind an abstract class interface.
Suggested “best practice” is that attributes of an object should be private, and access to them only provided through
the methods appropriate to the class of the object. Being able to access attributes only through methods makes the
interaction between two or more objects implicit in the code.
3-67
Volume 3
Some simple examples demonstrating the complexity of coupling are given in [35].
3.12.6.1 Guidelines
This is an active area of research, both within academia and the FAA. Therefore, no OO-specific guidelines can be
provided on data coupling and control coupling at this time.
3-68
Volume 3
3.13 References
1. RTCA, Inc. Software Considerations in Airborne Systems and Equipment Certification. RTCA/DO-178B,
December 1992.
2. RTCA, Inc. Final Report for Clarification of DO-178B “Software Considerations in Airborne Systems and
Equipment Certification.” RTCA/DO-248B, October 2001.
3. Daugherty, Gary. “Application of the Subtyping Pattern to System Level Test.” Rockwell Collins technical
report, April 2002, available from the author (gwdaughe@rockwellcollins.com).
4. Object Management Group. OMG Unified Modeling Language Specification. Version 1.3, June 1999, available
from http://uml.shl.com/artifacts.htm.
5. Gosling, James et al. The Java Language Specification. Addison-Wesley, 1996.
6. Lindholm, Tim and Frank Yellin. The Java Virtual Machine Specification. Second Edition, Addison-Wesley,
1999.
7. Liskov, Barbara and Jeanette Wing. “A Behavioral Notion of Subtyping.” ACM Transactions on Programming
Languages and Systems, 16(6): 1811-1841, November 1994.
8. Liskov, Barbara with John Guttag. Program Development in Java: Abstraction, Specification, and Object-
Oriented Design. Addison-Wesley, 2001.
9. Lorentz, Mark and Jeff Kidd. Object-Oriented Software Metrics. Prentice-Hall, 1994.
10. Barnes, John. Programming in Ada95. 2nd edition, Addison-Wesley, 1998.

Mis en forme
11. Binder, Robert V. Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley, 2000.
12. Bruce, Kim, Luca Cardelli, Giuseppe Castagna, The Hopkins Object Group, Gary T. Leavens and Benjamin
Pierce. “On Binary Methods.” Iowa State University, technical report #95-08a, December 1995.
13. Castagna, Giuseppe. Object-Oriented Programming: A Unified Foundation. Birkauser, 1997.
14. Clifton, Curtis, Gary T. Leavens, Craig Chambers, and Todd Millstein. “MultiJava: Modular Open Classes and
Symmetric Multiple Dispatch for Java.” OOPSLA 2000 Conference Proceedings: ACM SIGPLAN Notices,
vol. 35, no. 10, October 2000, pp. 130-145.
15. Johnston, Simon. Ada95 for C and C++ Programmers. Addison-Wesley, 1997.
Mis en forme
16. Meyers, Scott. Effective C++. 2nd edition, Addison-Wesley, 1998.
17. Meyer, Bertrand. “Applying design by contract.” IEEE Computer 25(10):40-51, October 1992.
18. Meyer, Bertrand. Object-Oriented Software Construction. 2nd edition, Prentice-Hall PTR, 1997.
19. Jeff Offutt, Roger Alexander, Ye Wu, Quansheng Xiao, and Chuck Hutchinson. “A Fault Model for Subtype
Inheritance and Polymorphism.” Twelfth IEEE International Symposium on Software Reliability Engineering
(ISSRE ’01), IEEE Computer Society Press, November 2001, pp. 84-93.
20. FOLDOC: Free Online Dictionary of Computing from http://foldoc.doc.ic.ac.uk/.
21. AVSI. Guide to the Certification of Systems with Embedded Object-Oriented Software. Available from Boeing,
Rockwell Collins, Honeywell, and Goodrich, or directly from the Aerospace Vehicle Systems Institute (AVSI).
3-69
Volume 3
Mis en forme
22. Stroustrup, Bjarne. The Design and Evolution of C++. Addison-Wesley, 1994.
23. Guidance for the Use of Ada in High Integrity Systems, ISO/IEC TR 15942:2000 see
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm.
24. FAA Order 8110.49. Software Approval Guidelines. Chapter 4, June 3, 2003.
25. Perry, Dewayne E. and Gail E. Kaiser. “Adequate Testing and Object-Oriented Programming.” Journal of
Object-Oriented Programming, January/February 1990.
26. Chilenski, John Joseph, Thomas C. Timberlake and John M. Masalskis. Issues Concerning the Structural
Coverage of Object-Oriented Software. Technical Report: DOT/FAA/AR-02/113, November 2002.
27. Harrold, Mary Jean, John D. McGregor and Kevin J. Fitzpatrick. “Incremental Testing of Object-Oriented
Class Structures.” Proceedings of the 14th International Conference on Software Engineering, 1992.
28. McGregor, John D. and David A. Sykes. A Practical Guide to Testing Object-Oriented Software. Addison-
Wesley, 2001.
29. Siegel, Shel. Object Oriented Software Testing : A Hierarchical Approach. John Wiley & Sons, 1996.
30. Watson, Arthur H.,Thomas J. McCabe. Structured Testing: A Testing Methodology Using the Cyclomatic
Complexity Metric. NIST Special Publication 500-235, 1996.
31. Jacobson, Ivar, Magnus Christenerson, Patrik Jonsson and Gunnar Overgaard. Object-Oriented Software
Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
32. McDaniel, Robert and John D. McGregor. Testing the Polymorphic Interactions between Classes. Technical
Report: TR94-103, Clemson University, 1994.
33. Booch, Grady. Object-Oriented Analysis and Design with Applications. 2nd edition, Benjamin/ Cummings,
1994.
34. FAA AC 20-148, Reusable Software Components, final (unsigned) version dated August 3, 2004.
35. Laplante, Phillip A. (editor). Dictionary of Computer Science, CRC Press LLC, 2001.
3-70
Volume 3
3.14 Index of Terms

abstraction, 26, 27, 28, 33 inlining, 27
Ada, 70, 78 Inlining, 39
Aerospace Vehicle Systems Institute, 29 instrumented, 22, 23
Aggregation, 59 interface inheritance, 28, 29, 30, 82, 85, 87
Association, 58 Java, 11, 23, 29, 69, 75, 77, 78, 79, 82, 86, 87
AVSI, 29, 30, 69 LSP, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26
C#, 16, 29
MC/DC, 22
C++, 12, 23, 32, 69, 70, 75, 78, 79, 80, 82, 86, 87, 88
MultiJava, 69
class, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22, 23,
24, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 46, 47, multiple inheritance, 12, 28, 29, 31, 33, 34, 49, 79, 81
48, 49, 50, 53, 75, 76, 77, 78, 80, 81, 88, 89, 90
Multiple inheritance, 29, 32
concrete class, 76
Multiple Inheritance, 29, 32, 81
constructors, 12, 14, 16, 17, 46, 49, 52, 77, 78, 79
Object Management Group, 69
control coupling, 26, 38, 51
OMG, 69
coupling, 14, 27
OOT, 46, 47, 49, 51
data coupling, 26, 27, 49, 51
option-selectable, 47, 48
deactivated code, 46, 47, 48, 49, 50, 51
Overloading, 44
Dead and Deactivated Code, and Reuse, 46, 89
pattern, 14, 19, 22, 23, 24, 33, 79, 88
dead code, 46, 47, 48, 51, 89
polymorphism, 12, 16, 51
derived requirements, 23, 24, 47, 48, 49, 50
postcondition, 12, 13, 16, 17, 18, 19, 20, 23, 24, 27,
destructors, 12, 16, 46, 49, 52, 79 85
DO-178B, 13, 18, 25, 26, 29, 36, 37, 38, 39, 40, 42, precondition, 12, 13, 16, 17, 18, 19, 20, 23, 24, 27, 85
43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 57
rule, 14, 15, 16, 18, 19, 20, 21, 22, 23, 25, 26, 27, 28,
dynamic binding, 11, 54 30, 31, 32, 34, 35, 47, 48, 49, 50, 77, 78, 79, 87, 88
dynamic dispatch, 11, 13, 14, 15, 16, 17, 21, 25, 28, run-time class, 12, 16
29, 30, 31, 51, 54, 77, 78, 79
service history, 50
dynamic linking, 13
single inheritance, 11, 13, 29, 30, 31, 77, 78, 79
Eiffel, 11, 14, 23, 24, 29
Single inheritance, 12, 29
extension, 14, 17, 18, 29, 78
Single Inheritance, 11, 75
flattened form, 16, 21, 49
software change impact analysis, 49
frameworks, 46, 51, 52
spaghetti inheritance, 28, 34
Generalization, 58
structural coverage, 21, 23, 25, 26, 48, 51, 54
hierarchy, 12, 28, 30, 32, 33, 34, 35, 49, 50, 78, 81,
subclass, 12, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24,
85, 90
25, 27, 30, 31, 32, 34, 49, 79, 88
IEEE, 69
subinterface, 30, 81, 82, 85
implementation inheritance, 29
3-71
Volume 3
subtyping, 12, 18, 19, 29, 31, 87, 88 Type Conversion, 41

superclass, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, UML, 11, 12, 16, 19, 51, 52, 53, 87, 88
27, 29, 30, 31, 32, 33, 34, 77, 79, 88
Unified Modeling Language, 11, 69
System Safety Assessment, 47
uninstrumented, 22, 23, 24
Templates, 36
Use Cases, 56, 57, 58, 60
Tools, 48, 51, 52, 54, 69
visual modeling, 52
traceability, 19, 20, 41, 47, 48, 51, 56, 57, 58, 59, 60
visual models, 51, 52. See visual modeling
Traceability, 48, 51, 56
3-72
Volume 3
Appendix A Frequently Asked Questions (FAQs)

This appendix documents some of the FAQs and answers regarding the use of OOT and this Handbook.
1. Does DO-178B require compliance with the subtyping rules for substitutability (LSP)?
No. However, the structural coverage criteria must still be met, and the issues raised in Volume 2 must still be dealt
with in some manner. Compliance with the subtyping rules is just one way to do so, and is compatible with the
definition of the Generalization relationship by UML (below).
2. Does UML require compliance with the subtyping rules for substitutability (LSP)?
UML does not directly mention the Liskov Substitution Principle (LSP) or the rules given in this Handbook. UML,
however, does say that the Generalization (subtyping) relationship implies substitutability, which indirectly implies
compliance with LSP.
3. When is it necessary to verify subtyping relationships?

At a minimum, we want to ensure substitutability when instances of different subclasses may be assigned to a
variable at run-time in a given system (i.e., when polymorphic assignment is actually used).
Technically, we need not worry about cases in which a given variable is assigned instances of different subclasses,
only in different instances of the system (e.g., as a means of parameterizing the system’s behavior).
Still, given that the UML definition of subtyping implies substitutability, it is also technically an error to use this
relationship in UML models where this is not the case.
And it is, in general, a “good idea” to verify subtyping relationships from the outset, not just when we discover
substitution actually occurs within a given system.
4. Is it necessary to use unit level testing to verify subtyping relationships?

No. System level testing, static analysis, and proofs may also be used to ensure (or help ensure) that the subtyping
rules are followed.
5. Is it necessary to use UML in order to follow the guidelines?

No. The use of UML terminology and UML examples is only a convenience. The principles underlying the
guidelines apply to other OO methodologies and modeling notations as well.
6. Is it necessary to use special OO coverage tools to measure structural coverage of dynamic dispatch?
No. By following an appropriate test process , it is possible to ensure that all entries of all dispatch tables are
exercised. The use of tools to measure this type of coverage, however, is still encouraged.
7. What role should static analysis play in the verification of OO systems?

The guidelines have been developed to restrict the use of OO in such a way as to encourage the use of various forms
of static analysis. The AVSI Guide [21], which was a basis for this Handbook, specifically addresses how various
guidelines affect the forms of static analysis recommended by [23] and required by DO-178B.
8. How do the guidelines map to the DO-178B software levels?

The original AVSI Guide [21] provided a mapping of guidelines to DO-178B software levels. This mapping was
based primarily on a consideration of which restrictions on OO features were necessary to enable the use of the
types of analysis techniques required by DO-178B at each software level, and secondarily on the error prone nature
3-73
Volume 3
of certain features (such as multiple implementation inheritance). This table does not appear in this Handbook,
however, a similar mapping based on similar criteria may appear in a future version. This Handbook does provide
reference to DO-178B sections and objectives, which can help users determine the applicable software levels.
9. How about the use of “work arounds” as a substitute for the direct use of OO features?
The guidelines are not intended to give a “free pass” to the use of OO-like work arounds as a substitute for the direct
use of OO features. For example, the intent is not to favor the hand coding of dispatch routines (containing explicit
case statements) over the use of dynamic dispatch. By drawing an analogy between the two, the guidelines impose
the same coverage criteria for both.
Similarly, issues related to substitutability must be addressed by any system that permits the “plugging in”
(substitution) of one piece of software in place of another (either at run-time or in different versions of the system
intended for different customers), whether the system uses OO or not. The OO subtyping guidelines are only a plus
in this regard. If you intend to allow substitution (of either form) in an OO system, following the guidelines provides
a well trod path for doing so. Something comparable, and not addressed by this Handbook, would still be required if
a different approach were taken.
3-74
Volume 3
Appendix B Extended guidelines and examples

B.1 Single Inheritance
B.1.1 Extension of the Inheritance with Overriding Guidelines

The following sections extend the definition of the Inheritance with Overriding guidelines (see section 3.3.4) to
include:
• an avionics related example,
• a description of the general structure of the problem and the roles of the participants, and
• a mapping of the general guidelines it offers to language specific guidelines for Java, Ada 95, and C++.
B.1.1.1 Examples
Consider an avionics display system that defines a class DisplayElement and its subclasses (see Figure B.1-1).
A given display is composed by drawing its associated elements. In order to draw the pilot's attention to critical
information, we highlight specific elements while hiding others. The specifics of drawing an element, hiding it, and
highlighting it vary according to the type of element. To allow variations on the display for specific customers and
aircraft, and to minimize the impact of future changes, the overall application should deal with elements only
abstractly (e.g., in terms of the kind of information they display and not how they display it).
The code to draw the display is then:
for each display element
call the draw method associated with its run-time class
end
The code to highlight a selected set of elements is then:

call the highlight method associated with its run-time class
end
The code to declutter the display is then:

compare the importance of the element to a cutoff value for the importance of elements to be displayed
if the element is not important enough
call the hide method associated with its run-time class
end
end
3-75
Volume 3
Client DisplayElement
importance : int
xOrigin : CoordinateValue
yOrigin : CoordinateValue
draw()
highlight()
hide()
NonTextualElement TextualElement
width : GraphicsDistance
highlight() height : GraphicsDistance
displayedValue : String
draw()
highlight()
getDisplayedValue() : String
setDisplayedValue(string : String)
AltitudeTape AirspeedTape Compass PrimitiveNonTextualElement
width : GraphicsDistance width : GraphicsDistance radius : GraphicsDistance

height : height : colorScheme : ColorScheme draw()
G hi Di t : ColorScheme
colorScheme G hi Di t : ColorScheme
colorScheme displayedValue : Heading highlight()
displayedValue : Altitude displayedValue : Airspeed
draw()
draw() draw() getDisplayedValue() : Heading
getDisplayedValue() : Altitude getDisplayedValue() : Airspeed setDisplayedValue(heading : Heading)
setDisplayedValue(altitude : Altitude) setDisplayedValue(airspeed : Airspeed)
Figure B.1-1 Class Hierarchy
B.1.1.2 Structure
In general, a client method calls an operation associated with a target object. The client method may be associated
with any object, including the target object itself. The run-time class of the target object is a concrete class which
may have superclasses and subclasses. The association of methods with classes is determined at compile time in
accordance with the restrictions imposed by the Simple overriding rule (see section 3.3.4.3) and the rules for
Subtyping (see section 3.3.6).
Polymorphically, the client method may view the target object at run-time as an instance of its run-time class or,
more abstractly, as an instance of any of its superclasses. In all circumstances, however, it is the method associated
with the run-time class of the target object that is executed when the operation is called.
3-76
Volume 3
ta rg e tO bje c t T a rg e tC la ss
0 ..* 1
-ru nT im eC las s
1
clie n tM eth o d ta rg e tO p e ra tio n e x e cu te s m eth o d In T a rg e tC la s
1
ca lls s
+ s p ec if ic ation
+ s p ec if ic ation 1 1 + s p ec if ic ation
S up e rC la ss
1
m eth o d In S u p e rC lass
S ub C la ss
1
m eth o d In S u b cla ss
Figure B.1-2 Class Relationships
B.1.1.3 Participants
The client method calls the target operation on the target object, which executes the method associated with it by the
run-time class of the object.
B.1.1.4 Java guidelines

Java is a strongly typed language. It provides dynamic dispatch based on the target object of a method call. The
dynamic loading of classes is supported but can be restricted (by eliminating the class loader from the run-time
environment). Only single inheritance of implementation is permitted. The run-time type of an object is assigned at
the point at which it is created and cannot be changed during the object’s life time.
The Simple overriding rule (see section 3.3.4.3) is enforced by the language, if the overriding of concrete methods
by abstract methods [5, p. 159] is disallowed, and if all explicitly thrown exceptions are checked exceptions (in the
Java sense). When exception handling is not used, code reviews should be used to enforce the more general
guideline that an overridden version of a method can only report either the same errors, or a more restricted set of
errors than its parent version.
The use of the keyword super in a call expression can be used to violate the Simple dispatch rule (see section
3.3.4.3). As a result, the use of the keyword super should only be permitted as a means of extending a superclass
method (in accordance with the guidelines for Method Extension in Section 3.3.5).
In accordance with the Initialization dispatch rule (see section 3.3.4.3), the body of a constructor should not be
permitted to call any operations on the object under construction except other constructors or private operations.
The bounded and deterministic nature of dynamic dispatch must be demonstrated based on the actual
implementation. Typically dispatch tables are constructed by a static linker, or by the Java Virtual Machine (JVM)
or a Java processor as classes are pre-loaded. This makes dispatch times for invokevirtual [6] both small and
fixed. The dispatch time for invokeinterface [6] potentially involves a search and may introduce a higher
3-77
Volume 3
overhead. Dispatch times, however, should still be both bounded and deterministic. The invokeinterface can
also be implemented using dispatch tables if the implementation takes advantage of the fact that new classes cannot
be loaded dynamically, making it equivalent to invokevirtual.
B.1.1.5 Ada 95 guidelines

Ada is a strongly typed language. To introduce basic OO features, Ada 95 provides tagged types as an extension to
the existing concept of a record. Class wide types provide a means to declare objects that may (polymorphically)
hold any of a number of related tagged type values, or corresponding access type values. The Ada 95 language
requires primitive operations on a tagged type to appear in the same declaration list as the type declaration, and to
have at least one parameter or a return type that is of the tagged type. Operations can also be provided that take a
corresponding class wide parameter. An Ada package that defines a single tagged type and primitive and class wide
operations on that type corresponds to the concept of a class in C++ and Java [15, p. 169] 7. The dynamic loading of
classes is generally not supported, and only single inheritance of either interface or implementation is permitted. For
tagged types, the run-time type (tag) of an object is assigned at the point at which it is created and cannot be changed
during the object’s life time.
With regard to the Simple overriding rule (see section 3.3.4.3) , code reviews should be used to enforce the rule that
an overridden version of a method can only report either the same errors, or a more restricted set of errors than its
parent version. The other restrictions are enforced by the language.
Tagged types provide the run-time type information (tag) required to make dispatching calls to primitive operations
associated with a type. Dynamic dispatch occurs when the argument corresponding to the tagged type parameter is
of a class wide type (polymorphic). With regard to the Simple dispatch rule (see section 3.3.4.3)., the risk is that an
overridden operation might be called with an argument declared to be of a specific tagged type, when the argument
itself has the run-time tag of some derived type 8. This can occur because Ada 95 permits view conversions between
specific tagged types so long as this conversion is toward the root of the hierarchy [10, p. 278]. In such conversions
the underlying object (and its tag) are not changed, only the program’s view of it [10, p. 288]. The easiest way to
enforce the Simple dispatch rule (see section 3.3.4.3) is to forbid view conversions between specific tagged types,
ensuring that all arguments are either of a class wide type or of a specific tagged type with a matching tag.
Conversions between a specific tagged type and a class wide type of an ancestor type, however, are still allowed.
In accordance with the Initialization dispatch rule (see section 3.3.4.3), the body of a constructor should not be
permitted to call any operations on the object under construction except other constructors or private operations. Ada
95 does not provide implicitly called constructors. By convention, however, we can provide initialization procedures
that can be called explicitly.
Such an initialization procedure should call the parent type’s initialization procedure to initialize all inherited fields,
then initialize the fields defined by the type extension. In accordance with Method Extension (see section 3.3.5), this
call to the parent initialization procedure should involve an explicit view conversion of the argument to the specific
parent type, intentionally avoiding the use of dynamic dispatch. To help ensure the initialization procedure is called
when an object is created, we can also provide a create function [15, p. 194] that allocates the object, calls the
initialization procedure, and returns the initialized result.
implementation. Typically, however, dispatch tables are constructed by the compiler or linker, making dispatch
times both small and fixed.
7
Unlike C++ and Java, we cannot control the visibility of individual attributes (record fields). This, however, is of little
consequence if all data is hidden, as in normal practice. The Ada 95 tagged type can be designated as private to ensure this.
8
This would not be a problem if the argument were declared to be of a class wide type because dynamic dispatch would then
occur.
3-78
Volume 3
B.1.1.6 C++ guidelines

C++ is a strongly typed language, if conversions between logically unrelated types are avoided. Since such
avoidance is not possible within the constructs of the language itself, a tool that specifically checks for such
conversions must be used. C++ supports single dispatch based on the target object of the method call. The dynamic
loading of classes is generally not supported. The run-time type of an object is assigned at the point at which it is
created and cannot be changed during the object’s life time.
With regard to multiple inheritance, code reviews should be used to ensure that only single inheritance is permitted
with respect to implementation.
With regard to the Simple overriding rule (see section 3.3.4.3), code reviews should be used to ensure that the
overridden version of a method can only report either the same errors, or a more restricted set of errors than its
parent version. Overriding methods should not declare default parameter values [16, p. 171]. All other restrictions
are enforced by the language.
Dynamic dispatch occurs in C++ when the called method is declared to be virtual and the target object is specified
as a pointer or reference. With regard to the Simple dispatch rule (see section 3.3.4.3), the risk is that an overridden
operation might be called with respect to a target object whose declared type is a superclass of its actual run-time
type, and dynamic dispatch might not occur.
To avoid problems with the declaration of overridden methods, a subclass should never be allowed to redefine an
inherited non-virtual function [16, p. 169]. This requires all public and protected operations to be declared using the
keyword “virtual” if subclasses are allowed to redefine them.
To avoid problems with the specification of the target object, all calls to virtual functions should involve a target
object specified as a pointer or reference.
Since the normal rules for dynamic dispatch do not apply during the execution of constructors and destructors, direct
and indirect calls to overridden methods during their execution should also be avoided. Doing so is also consistent
with the Initialization dispatch rule (see section 3.3.4.3), which forbids calls to overridden methods during object
construction.
implementation. Typically, however, dispatch tables are constructed by the compiler or linker, making dispatch
times both small and fixed.
B.1.2 Extension of the Method Extension Guidelines

The following sections extend the definition of Method Extension (see section 3.3.5) to describe its implementation
in Java, Ada 95, and C++.
B.1.2.1 Java guidelines

In Java, the implementation of these guidelines involves a call to the superclass version of the same method using
the keyword super. Only calls to the superclass version of the same method should be allowed.
B.1.2.2 Ada 95 guidelines

In Ada 95, the implementation of these guidelines involves a view conversion from the derived type to the parent
(superclass) type and then a call to the parent operation that supports this implementation. This has the same effect
as the use of the keyword super in Java. Only calls to superclass versions of the same method should be allowed.
3-79
Volume 3
B.1.2.3 C++ guidelines 9

In C++, the implementation of these guidelines involves qualification of the “::” operator. Only qualified calls to the
immediate base class version of the same member function should be allowed. In addition, the “::” operator may be
used under the following circumstances:
• If class A defines method f() and then class B inherits A and defines method f(int), within class B the method f()
is hidden by the declaration of f(int). The only way to get f() from within B is to use ‘A::f()’. This is considered
to be safe, if f() cannot be overridden (i.e., it is not declared ‘virtual’). Similarly, the “::” operator is needed to
access global functions that are hidden by method declarations (although global methods should generally be
avoided), and to access methods declared in a namespace.
• When code is generated by a tool and a method call is made using an object whose exact type is known, it is
reasonable for the tool to use the ‘::’ qualification to avoid the overhead of dynamic dispatch.
9
In this section, qualification refers to the compiler qualification and is not related to the tool qualification of DO-178B.
3-80
Volume 3
B.2 Multiple Inheritance
B.2.1 Composition involving multiple inheritance

The following three cases illustrate the primary issues to be resolved with respect to composition involving multiple
inheritance. They are based on examples appearing in Meyer [18].
B.2.1.1 Case 1: Repeated inheritance

“As soon as multiple inheritance is allowed into a language, it becomes possible for a class (e.g. FrenchUSDriver) to
inherit from two classes (e.g. FrenchDriver and USDriver), both of which are subclasses of the same class (e.g.
Driver). This situation is called repeated inheritance” [18, p. 543]. It is characterized by the diamond shape of the
inheritance hierarchy (see Figure B.2-1 ).
<<Interface>>
Dri ver
getAge() : i nt
getAddress() : String
getViolationCount()
passBi rthday()
payFee()
<<Interface>> <<Interface>>
FrenchDri ver USDriver
<<Interface>>
FrenchUSDriver
Figure B.2-1 Repeated inheritance: sharing and replication, based on [18, p. 547]
The fundamental question with respect to repeated inheritance is whether inheritance of the same operation along
more than one path should result in a single operation in the subinterface or in multiple operations.
Since we are dealing with this issue with respect to interfaces (and not implementation), we must view this question
from the client’s perspective. In general, a client will be satisfied if all subinterfaces of a given interface inherit a
definition of the expected operation. Since this is guaranteed (we will have at least one definition of the operation),
clients will be satisfied in this regard.
The remaining question is whether repeated inheritance should ever result in more than one definition of the
operation in the subinterface. A case for this can be made by the example appearing in Figure B.2-2. Each driver [of
a motor vehicle] has an age, and a primary residence (and associated address). We are also interested in tracking the
number of traffic violations committed by the driver, leading to a potential revocation of the person’s license.
3-81
Volume 3
Subinterfaces of Driver represent French drivers and US drivers. Drivers who have licenses in both countries are
categorized as both French and US drivers 10.
In terms of this example, it is clear that there should be a single operation to get the driver’s age, which will be the
same in both countries. Address and number of traffic violations, however, are potentially a different matter. The
driver may have different addresses in each country and traffic violations committed in one country may not count
against his/her driving record in the other. Similarly, license fees may have to be paid at different times in each
country and paying the fee in one country will not necessarily satisfy the other (although it may be possible to obtain
an international driving license that can be used in both).
The need to be able to define both shared operations (such as getAge and passBirthday) and replicated operations
(such as getAddress, getViolationCount, and payFee) can be satisfied in a number of ways.
We could require that all replicated operations be specified redundantly. Doing so, we would require that
FrenchDriver define the operation getFrenchAddress, while UsDriver defines an otherwise identical operation
getUsAddress.
Alternately, the language could simply permit the renaming of those operations to be replicated in the subinterface
and assume that repeated inheritance otherwise implies sharing. This is appealing because the situations in which
replication is the right choice are relatively rare. In most cases (especially those involving interfaces), sharing is the
desired result. As Meyer notes, “Cases of repeated inheritance similar to the transcontinental drivers (Figure B.2-2),
with duplicated operations as well as shared ones, do occur in practice, but not frequently” [18]. The case involving
only shared operations is far more common, especially with regard to interface inheritance. For this reason, it is most
important that sharing be supported well at the language level, or in any prescribed guidelines. Additional work (or
the use of work arounds) is probably acceptable in the less common case involving replication.
Sharing is also appropriate when we view multiple interface inheritance as a means of breaking up a large interface
specification into smaller interface specifications (superinterfaces) intended for particular categories of clients. In
Figure B.2-3, for instance, we begin with the definition of a single large interface AvionicsDataServiceInterface.
This interface is large because it contains the operations needed by all clients. This, unfortunately, makes it
unwieldy for them all.
No particular type of client, however, may need the full set of operations. Rather clients of type Producer may need
a given subset of the operations, while clients of type Consumer may need a different (but overlapping) subset, and
so on. To simplify each client’s view, we define a separate interface containing only the operations that it needs (see
Figure B.2-4). Because operations that appear in more than one of these client specific superinterfaces have the same
source (AvionicsDataServiceInterface), it is clear that they are intended to represent the same operation. (The
operation getDataChannel in the producer interface is the same as the operation getDataChannel in the consumer
interface because both are taken from the definition of getDataChannel provided by AvionicsDataServiceInterface.)
As a result, definitions of such operations should always be shared. This view is also consistent with the policies of
Java and C++.
10
Bertrand Meyer, whose wife is French, is a case in point.
3-82
Volume 3
<<Interface>>
Driver
getAge() : i nt
getAddress() : String
getViolationCount()
passBi rthday()
payFee()
FrenchDriver USDriver
<<Interface>>
FrenchUSDriver
getFrenchAddress() : String
getUsAddress() : String
getFrenchViolationCount()
getUsViolationCount()
pay FrenchFee()
pay UsFee()
Figure B.2-2 Shared and replicated operations
3-83
Volume 3
AvionicsDataServiceInterface
init()
addDataChannel(name : String) : DataChan...
deleteDataChaqnnel(name : String)
deleteDataChannel(channel : DataChannel)
getDataChannel(name : String) : DataChan...
getAllProducerDataItems(channel : DataCh...
getAllConsumerDataItems(channel : DataCh...
assignBandwidth(channel : DataChannel, m...
advertise(name : String) : DataItem
subscribe(name : String) : DataItem
setProducerRole(channel : DataChannel, pu...
setConsumerRole(channel : DataChannel, p...
setDataValue(item : DataItem, validity : boo...
setDefaultValue(item : DataItem, validity : b...
sendDefault(item : DataItem )
setRate(item : DataItem, rateInHertz : float)
setPriority(item : DataItem, priority : int)
getDataIValue(tem : DataItem, out validity ...
isStale(item : DataItem ) : boolean
Figure B.2-3 A Single large interface to an avionics data source
ProducerInterface ConsumerInterface AdminInterface
getDataChannel (name : Stri ng) : DataChan... getDataChannel(name : Stri ng) : DataChannel init()
advertise(name : String) : DataItem subscribe(name : String) : DataItem addDataChannel(name : String) : DataChann...
setProducerRole(channel : DataChannel, pu... setConsumerRole(channel : DataChannel, pu... deleteDataChaqnnel(name : String)
setDataValue(item : DataItem, validity : boo... setRate(item : DataItem, rateInHertz : float) deleteDataChannel(channel : DataChannel)
setDefaul tValue(item : DataItem, validity : b... setPriority(item : DataItem, priority : int) getDataChannel (name : String) : DataChannel
sendDefault(item : DataItem) getDataIValue(tem : DataItem, out validity : V... getAllProducerDataItems(channel : DataChan...
isStale(item : DataItem) : boolean getAllConsumerDataItems(channel : DataCha...
assignBandwidth(channel : DataChannel, min...
AvionicsDataServiceInterface
init()
addDataChannel(name : String) : DataChan...
deleteDataChaqnnel(name : String)
deleteDataChannel (channel : DataChannel)
getDataChannel(name : String) : DataChan...
getAllProducerDataItems(channel : DataCh...
getAllConsumerDataItems(channel : DataCh...
assignBandwidth(channel : DataChannel, m...
advertise(name : String) : DataItem
subscribe(name : String) : DataItem
setProducerRole(channel : DataChannel, pu...
setConsumerRole(channel : DataChannel, p...
setDataValue(item : DataItem , validity : boo...
setDefaultValue(item : DataItem, validity : b...
sendDefault(i tem : DataItem)
setRate(item : DataItem, rateInHertz : float)
setPriority(item : DataItem, priority : int)
getDataIValue(tem : DataItem, out validity ...
isStale(item : DataItem) : boolean
Figure B.2-4 Separate interfaces for different types of clients
3-84
Volume 3
B.2.1.2 Case 2: Redefinition along separate paths

The ability to specialize the definition of an operation in a subinterface is fundamental to OO development. The
same operation, however, may be specialized (redefined) in different ways along different paths in the classification
hierarchy. The question then arises as to what the result should be when we inherit more than one
definition/redefinition of the same operation in a given subinterface.
The answer hinges on whether sharing or replication is intended, and (if sharing is intended) whether the
specializations are compatible.
A simple way to guarantee this result is to require the user to define a version of the operation in the subinterface
that obeys the Simple overriding rule (see section 3.3.4.3) with respect to each of its parent interfaces. An example
of this is shown in Figure B.2-5. Another way to guarantee this result is to explicitly define a version of the
operation in the subinterface as shown in Figure B.2-6.
<<Interface>>
A
f() : A
<<Interface>>
<<Interface>>
C
B
f() : B
<<Interface>>
D
Figure B.2-5 Redefinition along separate paths, based on [18, p. 551]
In general, the combined operation has a pre-condition that represents an or’ing of the pre-conditions of all inherited
definitions of the operation, and a post-condition that represents an and’ing of all inherited post-conditions. Type
constraints on in parameters are considered part of the pre-condition. Type constraints on out parameters and the
result, and any restrictions on errors reported/exceptions thrown, are considered part of the post-condition.
These guidelines are simply intended to help the user write the correct signature for the combined operation. The
target language compiler should catch errors associated with the result of doing so, including errors resulting from
attempts to combine conflicting definitions.
Adopting the simple view of interface inheritance as a factoring of a large interface into smaller ones targeted to
specific categories of clients, we could instead forbid refinement of operations along separate paths. This is certainly
consistent with the idea that all refinements of an operation be compatible (in this case, they would have to be
3-85
Volume 3
identical). However, forbidding refinement of operations may be less flexible than we would like in situations such
as that given above, and would certainly be more restrictive than is required to be type safe 11.
<<Interface>>
A
f() : A
<<Interface>>
<<Interface>>
C
B
f() : B
<<Interface>>
D
f() : B
Figure B.2-6 Explicit definition of combined operation in subinterface
11
With respect to the languages of primary interest, the ways in which operations may be refined are limited (C++ permits the
return type to be made more specific, Java permits the elimination of exceptions from the exception list). The ability to make the
return type more specific, however, has been shown to have a large effect upon the number of run-time casts required [22].
3-86
Volume 3
B.2.1.3 Case 3: Independently defined operations with same signature

A different situation arises when two parent interfaces independently define operations with the same signature (see
Figure B.2-7). This is not repeated inheritance since we are not talking about inheriting the same operation via more
than one path, but different operations, independently defined, that have the same signature. The key question is
whether the matching of the signatures is intentional or accidental.
B C
sameSignature(i : int) : f loat sameSignature(i : int) : f loat
<<Interface>>
D
Figure B.2-7 Independently defined operations with same signature, based on [18, p. 550]
If the operations were completely and formally specified, we could compare pre-conditions and post-conditions to
see if the semantics are the same. If they are, then a single operation that does what they both promise to do should
be sufficient in all cases.
Alternately, we could adopt the view that interface inheritance represents only a factoring of a large interface into
smaller ones targeted to specific categories of clients. If we use interface inheritance in only this way, then it is clear
that we intend the separately inherited operations to be the same (i.e., sharing is always the right answer). This view
is also consistent with the policies of Java and C++.
B.2.2 Extended guidelines
B.2.2.1 Extension of the Multiple Interface Inheritance Guidelines

The following sections extend the guidelines for Multiple Interface Inheritance (see section 3.4.4) to include
language specific guidelines for Java and C++. In general, it is only necessary to enforce (e.g., by means of design
and code inspections) those guidelines that the language does not enforce itself.
B.2.2.1.1 Java guidelines

In Java, a UML interface is represented by a Java interface defining only abstract methods and compile time
constants. Constants whose value is computed at run-time should not be permitted, even when this value is
computed once and never again changed.
The Java language enforces the Repeated interface inheritance rule (see section 3.4.4.3). Where operations should Mis en forme
be replicated rather than shared, they must be given distinct names.
Java implicitly combines redefined methods inherited along different paths, enforcing the subtyping guidelines with
respect to method signatures and the use of checked exceptions. It also permits the explicit combination of redefined
methods in the subinterface, as recommended by the Interface redefinition rule (see section 3.4.4.3). Code reviews
must be used to enforce this.
When more than one superinterface independently defines a method with the same signature, Java considers them to
represent the same method. Code reviews must be used to ensure this is the real intent; i.e., that the matching of
3-87
Volume 3
signatures is not simply accidental. As suggested by the guidelines for Multiple Interface Inheritance (see section
3.4.4), a comment annotation should be used to document this intent, thereby ensuring it is properly maintained.
B.2.2.1.2 C++ guidelines

In C++, a UML interface is represented by an abstract class defining only pure virtual member functions and
compile time constants. Constants whose value is computed at run-time should not be permitted, even when the
value is computed once and never again changed.
In accordance with the Repeated interface inheritance rule (see section 3.4.4.3), all base classes of a C++ interface
class must be virtual base classes. Where operations should be replicated rather than shared, they must be given
distinct names.
C++ implicitly combines redefined methods inherited along different paths, enforcing the subtyping guidelines with
respect to method signatures. It also permits the explicit combination of redefined methods in the sub-interface as
recommended by the Independent interface definition rule (see section 3.4.4.3). Code reviews must be used to
enforce this.
When more than one super-interface independently defines a method with the same signature, C++ considers them
to represent the same method. Code reviews must be used to ensure this is the real intent; i.e., that the matching of
signatures is not simply accidental. As suggested by the guidelines for Multiple Interface Inheritance (see section
3.4.4), a comment annotation should be used to document this intent, thereby ensuring it is properly maintained.
B.2.2.2 Extension of the Multiple Implementation Inheritance Guidelines

The following section extends the guidelines for Multiple Implementation Inheritance (see section 3.4.5) to include
language specific guidelines for C++. In general, it is only necessary to enforce (e.g., by means of design and code
inspections) those guidelines that the language does not enforce itself.
B.2.2.2.1 C++ guidelines

In accordance with the Repeated implementation inheritance rule (see section 3.4.5.3), virtual inheritance should be
used by default. Performance considerations should be taken into account only in response to a demonstrated need,
and in accordance with the 80-20 rule (which suggests that some 20% of the code is executed 80% of the time).
Renaming [22, pp. 273-275] should always be used to distinguish inherited methods that are intended to be different
in the subclass. Otherwise, an overriding method should be defined in the subclass that either selects between the
competing implementations or otherwise combines them 12.
The overridden methods must be compatible with one another (in terms of their pre-conditions and post-conditions)
for their overriding by a single overriding subclass method to be valid. This is true both when the competing
implementations have a common definition in a superclass (in accordance with the Implementation redefinition rule
(see section 3.4.5.3)) or when they do not (in accordance with the Independent implementation definition rule (see
section 3.4.5.3)).
12
This explicit form of selection is preferred, even though C++ provides for implicit selection, in some cases, in accordance with
its own dominance rule [22, p. 263].
3-88
Volume 3
B.3 Dead and Deactivated Code, and Reuse

B.3.1 Deactivated Code Example
Figure B.3-1 presents a class (C_x) being used by a client (our system). In this diagram, the methods (M_x) are
annotated with the attributes (A_x) and methods they access in italics, as is the client. From the point of view of the
client, class (C_3), methods (M_3, M_4, M_6) and attributes (A_2, A_4) appear to be dead or deactivated code (i.e.,
not used by this system).
C_1
A_1
A_2
M_1() -- A_1
M_2() -- A_1
M_3() -- A_2
M_4() -- A_2
Client
C_2 C_3
M_1, A_3 A_4
M_2, M_5() -- A_3, M_1, M_2 M_6() -- A_4, M_3, M_4
M_5
Figure B.3-1 Dead or Deactivated Code?
The differentiator between dead and deactivated code is whether requirements exist for the unused portions of code
or not. If requirements exist and usage in another configuration is possible, then the code may be considered
deactivated but it must be verified according to its software level. If requirements exist, but the code is not intended
to be executed in any configuration, then the code may also be considered deactivated with the deactivation means
requiring verification. If, however, the appropriate requirements do not exist, then the code should be considered
dead and it should be removed.
3-89
Volume 3
B.3.2 Hierarchy Changes and Method Overriding

For an example of a subtle effect in OO software, consider the classes shown in Figure B.3-2, displayed in both a
normal and flattened hierarchy. Here, class C_1, which contains methods M_1() and M_2(); and M_1() calls M_2().
Now consider a sub-class, C_2 that inherits C_1, but overrides M_2(). M_1() in class C_2 is effectively also
overridden as it makes a call to a different M_2() than the M_1() in C_1. There are other situations where changes in
the class hierarchy can be subtle and difficult to discover.
Figure B.3-2 Method Overriding
3-90
DRAFT

Volume 4: Certification Practices

Revision 0
October 26, 2004

but, rather,
context.
Volume 4
Contents
4.1 PURPOSE.................................................................................................................................................. 4-1
4.2 BACKGROUND ......................................................................................................................................... 4-1
4.3 ACTIVITIES FOR STAGES OF INVOLVEMENT ............................................................................................. 4-1
4.3.1 Activities for Stage of Involvement #1 (SOI #1) – PLANNING REVIEW ........................................ 4-1
4.3.2 Activities for Stage of Involvement #2 (SOI #2) – DEVELOPMENT REVIEW ............................... 4-3
4.3.3 Activities for Stage of Involvement #3 (SOI #3) – VERIFICATION/TEST REVIEW ......................... 4-7
4.3.4 Activities for Stage of Involvement #4 (SOI #4) – FINAL REVIEW ................................................ 4-9
4.4 REFERENCES ......................................................................................................................................... 4-10
Tables
Table 4.3-1 SOI #1 Activities/Questions.................................................................................................................... 4-3
4-ii
Volume 4
4.1 Purpose
Volumes 1-3 of the OOTiA Handbook have pointed out a number of potential issues and some potential ways to
address the issues, when using object-oriented technology (OOT) in aviation products. Because OOT poses a
number of potential certification issues, it may require additional oversight by certification authorities and their
designees, as well as the applicants. This volume provides an approach for certification authorities and designees to
ensure that OOT issues have been addressed in the projects they are reviewing or approving.
4.2 Background
In 1998, the FAA’s Software Review Job Aid [2] for conducting software reviews prior to certification was released.
The Job Aid provides a standardized approach for certification authorities and designees to perform software
reviews in order to assess compliance to DO-178B objectives. In 2003, the Job Aid was updated to address lessons
learned and to correct some typographical errors. Additionally, Chapter 2 of the FAA Order 8110.49, “Software
Approval Guidelines,” addresses the software review process [1]. The focus of the Job Aid is a series of activities
and questions to be addressed by reviewers to ensure that the project meets DO-178B objectives.
Since the software review (either on-site or desk) is the primary means for certification authorities and designees to
assess compliance to DO-178B objectives, this volume provides a series of activities and questions to be considered
in conjunction with those in the Job Aid during a software review for object-oriented (OO) projects. The activities
and questions are in a format similar to the Job Aid and may eventually be implemented into the Job Aid. The
activities and questions are divided among the four stages of involvement (SOI) that are discussed in the Job Aid
and chapter 2 of Order 8110.49. Each activity has a set of questions designed to help carry out that activity. It is
important to realize that these questions are not all encompassing. Some questions will not be applicable to all OOT
projects and some projects will require additional questions. Each question includes reference(s) to DO-178B and
Volume 2 of this Handbook.
4.3 Activities for Stages of Involvement
4.3.1 Activities for Stage of Involvement #1 (SOI #1) – PLANNING REVIEW

Section 2-4.a of Order 8110.49 states: The software planning process is the initial process in the software life cycle
for any software project. The planning process establishes the various software plans, standards, procedures,
activities, methods, and tools required to develop, verify, control, assure, and produce the software life cycle data.
The intent of the software planning review is to determine if the applicant’s plans and standards provide an
acceptable means for satisfying the objectives of RTCA/DO-l78B. This review can also reduce the risk of an
applicant producing a software product that does not meet RTCA/DO-178B objectives or other certification criteria
[1].
The primary goals of SOI #1 are to:
• Ensure that plans meet objectives in DO-178B Annex A tables A-1, A-8, A-9, A-10;
• Assess that when the applicant follows their plans, they will meet all of the objectives of DO-178B (Tables
A-1 to A-10).
When OOT is used in a project, the Activities/Questions shown in Table 4.3-1 below should be considered, in
conjunction with those in the Job Aid for SOI #1. If the plans and standards indicate that a number of OOT issues
exist in the project and are not being addressed, an issue paper may be needed for the specific project.
Volume 4
Item # Evaluation Activity/Question OOTiA DO-178B

Vol 2 Ref Obj
1.1 Review all software plans and consider the following questions:
1.1.1 Does the additional considerations section (or some other section) of the 2.3.4 A1: 4
Plan for Software Aspects of Certification (PSAC) address that the project
is object-oriented (OO) and identify OO-related issues for the specific
project?
1.1.2 Have the issues raised in Volume 2 of the Handbook (summarized in 2.3.1, 2.5.2 All
section 2.5.2 of Volume 2) been addressed by the applicant’s plans? Note:
Volume 3 provides some approaches for addressing OO issues; however,
applicants may have other means to address the issues.
1.1.3 Do the plans address how the following common OO implementation 2.3.1 A1: 4
features will be addressed to comply with DO-178B objectives?
• Encapsulation
• Overloading
• Inheritance
• Dynamic binding/dispatch
• Polymorphism
• Templates
• Inlining
• Deactivated code
• Reusability
Note: Applicants may not use all of the feature available.

1.1.4 Do the plans define how the OO life cycle data maps to the DO-178B 2.3.1.1 A1: 1-4
Section 11 life cycle data? For example, what are the high-level (Sect
requirements, low-requirements, design, and source code in OO? 11.1e)
1.1.5 What levels of abstraction are used for the OO implementation and how 2.3.1.1 A1: 1
does the abstraction map to the DO-178B objectives (reference 2.3.1.1 of
Volume 2)?
1.1.6 Do plans identify how derived requirements will be addressed and tracked 2.3.1.2 A1: 1
in the OO implementation?
1.1.7 Has the difference between dead and deactivated code for OO been 2.3.2.4 A1: 4
clarified in the planning phases of the program?
1.1.8 If a modeling language is used (e.g., UML), how is the software 2.3.1.2 A1: 1
functionality described and how is the tie to the system safety assessment
established?
1.2 Review the Development Standards (requirements, design, & coding

standards) and consider the following questions:
1.2.1 Do the development standards address limitations for OO implementation 2.3.1.1 and A1: 5
(e.g., identify project rules that restrict use of specific target language 2.3.1.2 (Sect 11.6-
features)? 11.7)
4-2
Volume 4

Vol 2 Ref Obj
1.2.2 Are OO methods and notations documented in the software requirements 2.3.1.1 and A1: 5
and design standards? Specifically, do the standards identify how non- 2.3.1.2 (Sect 11.6-
functional requirements are captured, and how low-level and derived 11.7)
requirements are addressed?
1.2.3 Do the development standards implement the solutions to the OO issues as N/A A1: 5 & 7
the PSAC (or other plans) claim they will?
1.2.4 Do the standards disallow “constructs or methods that produce outputs that 2.3.1.3 A1: 5
cannot be verified or that are not compatible with safety-related (Sect 4.5c)
requirements” (per DO-178B, section 4.5c)?
1.2.5 Are necessary restrictions for the chosen OO language identified in the 2.3.1.3 A1: 5
coding standards? (Sect 11.8)
1.2.6 If constructs or methods were disallowed, do the plans address how proper 2.3.1.3 A1:
implementation will be verified? 1,2,5,&7
1.3 Determine if an Issue Paper (IP) is needed for the project. An IP is 2.5.2 Varies
typically required if the plans do not address the known issues (e.g., the
issues summarized in section 2.5.2 of Volume 2).
Table 4.3-1 SOI #1 Activities/Questions
4.3.2 Activities for Stage of Involvement #2 (SOI #2) – DEVELOPMENT REVIEW

Section 2-5.a of Order 8110.49 states: The software development processes are the software requirements, design,
code, and integration processes. The development processes are supported by the integral processes of software
verification, configuration management, quality assurance, and certification liaison processes. Therefore, the
software development review should assess the effective implementation of the applicant’s plans and standards
through examination of the software life cycle data, particularly the software development data and integral
processes’ data associated with it. During this review, the applicant and FAA may agree on and document changes
to or deviations from plans and standards discovered during the review. Before conducting a software development
review, the software development data should be sufficiently complete and mature[1].
The purpose of SOI #2 is to:
• Assess effective implementation of applicant’s plans and standards through examination of software life
cycle data;
• Assess and agree to any changes in the plans;
• Assure that software life cycle data meets DO-178B objectives from tables A-2, A-3, A-4, A-5, A-8, A-9,
and A-10.
conjunction with those in the Job Aid for SOI #2.
4-3
Volume 4

Vol 2 Ref Obj
2.1 Assess the developer’s traceability approach in the OO implementation

by considering the following questions:
2.1.1 How is traceability between requirements, design, code, and test 2.3.3.4 A3:6
cases/procedures established and maintained?
A4:6
A5:5
2.1.2 Does the traceability approach address common OO traceability problems, 2.3.3.4 A3:6
such as:
A4:6
• traceability of functional requirements through implementation might
be lost or difficult with an OO program because of mismatches A5:5
between function-oriented requirements and an object-oriented
implementation
• complexity of class hierarchies may cause traceability problems
• the behavior of the classes and how they interact together to provide
the required function might not be visible in any single view.
2.1.3 Does the traceability approach provide a way to ensure that: 2.3.3.4 A3:6
• all requirements (both high and low-level) are verified, A4:6
• unintended functions and/or source code are identified, and
• visibility into derived requirements exists? A5:5
2.1.4 Do the OO tools/methods support traceability across the full life cycle and 2.3.3.4 A3:6
across multiple views?
A4:6
A5:5
2.2 Determine if subtype issues have been addressed by considering the

following questions:
2.2.1 How has the applicant addressed type substitutability? For example, has the 2.3.2.1 A2, A3, &
applicant provided assurance that subtype substitution is always A4
appropriate? If the Liskov Substitution Principle (LSP) has been adopted,
have language issues been clarified?
2.2.2 Have inconsistent type uses been addressed? 2.3.2.1.2 A2, A3, &
A4
2.2.3 If a language subset is proposed, does it address the subtype issues? 2.3.2.1 A2, A3, &
A4
2.3 Determine if subclass issues have been addressed by considering the

4-4
Volume 4

Vol 2 Ref Obj
2.3.1 Is the intent of subclass operations clear and unambiguous? Specifically, 2.3.2.2.1 A3: 1-4,
consider: 6,7
• Is the complete definition/intention of a class clear (in order to avoid a A4: 1-4, 6-
subclass being incorrectly located in a hierarchy)? 11
• How is the class hierarchy accuracy assured?
• Do top-heaviness or deep hierarchies exist (six or more subclasses)? If
so, how is it verified that the wrong variable type, variable, or method
are not inherited?
• How are unintended connections among classes (which could lead to
difficulty in meeting the DO-178B/ED-12B objective of data and
control coupling) prohibited?
2.3.2 Have overriding concerns been addressed? Specifically: 2.3.2.2.2 A3: 1-4,
• Can an operation accidentally override another? 6,7
• Can operations inherited from different sources be accidentally joined? A4: 1-4, 6-
• Can a subclass-specific implementation of a superclass be accidentally 11, 13
omitted?
• Have the classes of errors associated with overriding that were
identified in Volume 2 (section 2.3.2.2.2.d) been addressed?
2.4 If objects or design components are being reused, have
dead/deactivated code issues been addressed? Specifically:
2.4.1 Are the issues of dead and deactivated code addressed consistently 2.3.2.4.1 A5 & A7
throughout the project and as the planning documents stated?
(Sect 5.4.3
& 6.4.4.3)
2.4.2 Does overriding result in any dead or deactivated code? 2.3.2.4.1 A5 & A7
(Sect 5.4.3
& 6.4.4.3)
2.4.3 Do libraries and OO frameworks result in dead or deactivated code? 2.3.2.4.2 A5 & A7
(Sect 5.4.3
& 6.4.4.3)
2.5 Does the OO approach address the following configuration

management issues:
2.5.1 Is configuration management maintained when objects and classes are used 2.3.3.3 A8
multiple times in slightly different manners?
2.5.2 If a modeling tool is used, how is the configuration of objects and classes 2.3.3.3 A8
handled?
2.5.3 How is configuration control maintained for inherited classes, association 2.3.3.3 A8
links, and client relationships?
4-5
Volume 4
2.6 If tools are used in the OO implementation or verification, consider the

2.6.1 Does the tool support compliance with the DO-178B objectives? I.e., is the 2.3.4.1 Objs vary
tool compatible with DO-178B? depending
on the tool
(Sect 12.2)
2.6.2 How mature is the tool (e.g., compiler, UML tool, …) that is being used? 2.3.4.2 Objs vary
Unstable configuration may indicate an immature tool. depending
on the tool
(Sect 12.2)
2.6.3 How will the tool be maintained to meet the long-term needs of an aircraft 2.3.4.2 A8: 6 (Sect
project? 7.2.9)
2.6.4 If a tool does not meet the DO-178B definition of development or 2.3.4.3 Objs vary
verification tool, how is it addressed? I.e., are new classes of tools being depending
used? If so, is an issue paper needed? Does the tool need to be qualified? on the tool
(Sect 12.2)
2.6.5 If the tool is being qualified, does it meet DO-178B and applicable 2.3.4.3 Objs vary
guidelines in Order 8110.49? depending
on the tool
(Sect 12.2)
2.7 Consider if the following potential issues have been addressed:

2.7.1 Is garbage collection used? If so, how is determinism established? 2.4 A2, A3,
A4, A5
2.7.2 Is exception handling used? If so, how are control flow, run-time support, 2.4 A2, A3,
determinism, and deactivated code addressed? A4, A5
2.7.3 How is concurrency addressed? Use of this feature may raise issues with 2.4 A2, A3,
control flow, run-time support, real-time predictability, and deactivated A4, A5
code.
2.7.4 How is any additional complexity managed in OO projects? 2.4 All
2.7.5 If libraries are used, do they meet DO-178B objectives? 2.3.2.4.2 All
4-6
Volume 4
4.3.3 Activities for Stage of Involvement #3 (SOI #3) – VERIFICATION/TEST

REVIEW
Section 2-6.a of Order 8110.49 states: The software verification process is typically a combination of inspections,
demonstrations, reviews, analyses, tests, and coverage analysis. As with the other reviews, the software
configuration management and quality assurance processes are also active during these verification activities. The
verification activities confirm that the software product specified is the software product built. Therefore, the
software verification review should ensure that the software verification processes will provide this confirmation
and will result in objective evidence that the product has been sufficiently tested and is the intended product. The
purpose of the software verification review is to: assess the effectiveness and implementation of the applicant’s
verification plans and procedures; ensure the completion of all associated software configuration management and
quality assurance tasks; ensure that the software requirements, design, code, and integration have been verified;
and ensure that the software verification process will achieve the requirements-based test coverage and structural
coverage criteria of RTCA/DO-178B, Annex A, Table A-7. Before conducting a software verification review, the
software verification process should be sufficiently complete and mature[1].
• Assess effective implementation of the applicant’s verification plans and procedures;
• Check the completion of all associated software configuration management and quality assurance tasks;
• Make determination on acceptable deviations from plans and standards found during the review or with the
applicant’s requested deviations;
• Ensure that the selected software requirements have been verified;
• Ensure that the software life cycle data meets DO-178B objectives from Tables A-5, A-6, A-7, A-8, A-9,
and A-10;
• Ensure that the verification activity satisfied the structural coverage requirements found in DO-178B, Table
A-7.
When OO is used in a project, the Activities/Questions shown in Table 4.3-3 below should be considered, in
Item # Evaluation Activity/Question OOTiA Vol DO-178B

2 Ref Obj
3.1 Consider if data and control coupling issues have been addressed by
considering the following questions:
3.1.1 Does the OO approach address data and control coupling analysis? 2.3.3.1.1 A7: 8
3.1.2 If dynamic dispatch is used, how is data and control coupling analysis 2.3.3.1.1 A7: 8
performed?
3.1.3 If inlining is used, how is data and control coupling analysis performed? 2.3.3.1.1 A7: 8
3.2 Determine if memory management and initialization issues have been

addressed by considering the following questions:
3.2.1 Does the memory allocation/deallocation approach result in predictable 2.3.2.3 A6
worst-case memory analysis?
(Sect
6.4.3a)
4-7
Volume 4

2 Ref Obj
3.2.2 Is memory fragmentation and defragmentation handled in a deterministic 2.3.2.3.1 A6

manner?
(Sect
6.4.3a)
3.2.3 Have memory leaks been addressed? 2.3.2.3 A6
(Sect
6.4.3a)
3.2.4 Have initialization problems been identified and addressed? 2.3.2.3.2 A6
(Sect
6.4.3a)
3.3 Consider if structural coverage issues have been addressed by

considering the following questions:
3.3.1 If dynamic dispatch is used, how is structural coverage addressed? 2.3.3.1.2 A7: 5-7
3.3.2 If inheritance is used, how is structural coverage addressed? 2.3.3.1.2 A7: 5-7
3.3.3 If polymorphism is used, how is structural coverage addressed? 2.3.3.1.2 A7: 5-7
3.3.4 If inlining is used, how is structural coverage addressed? 2.3.3.1.2 A7: 5-7
3.3.5 If templates are used, how is structural coverage addressed? 2.3.3.1.2 A7: 5-7
3.3.6 If source to object code traceability is required (per DO-178B, section 2.3.3.1.4 A7: 7
6.4.4.2b), how is it carried out? Specifically, how do dynamic dispatch,
inlining, and type conversion affect source to object code traceability?
3.4 If dynamic dispatch, inlining, and/or polymorphism are used, have 2.3.3.1.3 A5: 6
their effects on stack usage and timing analysis been addressed?
3.5 Consider if the testing issues have been addressed by considering the
3.5.1 Has requirements-based testing, software integration testing, and 2.3.3.2.1 A6
hardware/software integration testing been properly performed? The key
concern for requirements testing is that the mapping of function-oriented
test cases to an object-oriented implementation might not be obvious since
the basic unit of testing in an OO program is not a function or a subroutine,
but an object or a class.
3.5.2 Has test coverage of both high-level and low-level requirements been 2.3.3.2.1 A7: 3, 4
completed? Note: Test coverage of high-level and low-level requirements
typically requires different testing strategies than the traditional functional
approach, because information hiding and abstraction techniques decrease
or complicate the observability of low-level functions.
4-8
Volume 4

2 Ref Obj
3.5.3 Has a retest or reuse of test cases approach been implemented to address 2.3.3.2.2 A6 & A7
inheritance and overriding? The concern to be addressed is: Requirements-
based testing is complicated by inheritance, dynamic dispatch, and
overriding because it might be difficult to determine how much testing at a
superclass level can be reused for its subclasses.
4.3.4 Activities for Stage of Involvement #4 (SOI #4) – FINAL REVIEW

Section 2-7.a of Order 8110.49 states: The final software build establishes the configuration of the software product
considered by the applicant to comply with all objectives of RTCA/DO-178B. It is the version of the software
intended to be used in the certified system or equipment. The purpose of this review is to: determine compliance of
the final software product with the appropriate objectives of RTCA/DO-l78B; ensure that all software development,
verification, quality assurance, configuration management, and certification liaison activities are complete; ensure
a software conformity review has been completed; and review the final Software Configuration Index (SCI) and
Software Accomplishment Summary (SAS). The final certification software review should take place when the
software project is completed[1].
• Determine if final compliance to all of the DO-178B objectives has been achieved and any open items
addressed/dispositioned;
• Assess the Software Configuration Index, Software Life Cycle Configuration Index, Accomplishment
Summary, and any other documents not previously reviewed.

Vol 2 Ref Obj
4.1 Has the approach for addressing OO concerns been summarized in the N/A A10: 3
Software Accomplishment Summary?
4.2 Have all open OO issues from previous reviews been addressed? N/A ALL
4.3 Have all issues identified in the OO Handbook and applicable to the Vol 1-3 ALL
system been assessed and properly addressed?
4.4 Does the Software Configuration Index accurately document the N/A A10:3
configuration items and environment of the OO software?
4-9
Volume 4
4.4 References
1. FAA Order 8110.49, Software Approval Guidelines, June 3, 2003. A copy of this Order is available from the
FAA website at http://www2.faa.gov/certification/aircraft/av-info/software/software.htm.
2. FAA Job Aid, Conducting Software Reviews Prior to Certification, dated January 16, 2004. A copy of this FAA
Job Aid is available from the FAA website at http://www2.faa.gov/certification/aircraft/av-
info/software/software.htm.
4-10

Plete

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Plete

Hochgeladen von

Copyright:

Verfügbare Formate

DRAFT

Handbook for Object-Oriented

Volume 1: Handbook Overview

This Handbook does not constitute Federal Aviation Administration (FAA)

1.1 Handbook Introduction

1.2 Handbook Organization

Volume 3: Best Practices

Volume 2: Considerations and Issues

Volume 1: Handbook Overview

Figure 1.2-1 Handbook Approach

1.2.2.1 Volume 1: Handbook Overview

1.2.2.2 Volume 2: Considerations and Issues

1.2.2.3 Volume 3: Best Practices

1.2.2.4 Volume 4: Certification Practices

1.3 OOT Background

1.3.1 OOT Basics

Figure 1.3-1 Object-Oriented Class Representation

1.3.2 Principles of OOT

1.3.3 OOT Methodology

Figure 1.3-2 OOA Tasks

1.3.4 OOT Languages

1.3.5 Additional Key OO Concepts

1.3.6 Further OOT Reading

1.4 Acronym List

SAS Software Accomplishment Summary

1.6 OOTiA Workshops

1.6.1 Workshop Committee

1.6.2 Participants in Workshop #1

M. Holloway NASA Langley Research Center

T. Reeve Patmos Engineering Services

1.6.3 Participants in Workshop #2

T. Bihari AMT Systems Engineering, Inc.

6. Dedicated Systems Encyclopedia, available from

7. Object-Oriented Technology in Aviation Program website: http://shemesh.larc.nasa.gov/foot/.

9. “Glossary of Software Engineering Terminology.” ANSI/IEEE Standard, 1983.

11. Hathaway, Bob. “Frequently Asked Questions on Object-Oriented.” Web site:

13. Montlick, Terry. “What is Object-Oriented Software?” Web site: http://www.softwaredesign.com/.

15. Schildt, Herbert. Teach Yourself C++. McGraw Hill, 1998.

18. FOLDOC: Free Online Dictionary of Computing, http://foldoc.doc.ic.ac.uk.

1.8 Feedback Form

Subject: Handbook for Object-Oriented Technology in Aviation (OOTiA)

To: OOTiA Handbook POC, FAA/AIR-120, Software Program Manager

I would like to discuss the above. Please contact me.

Submitted by: ________________________________________ Date: _________________

Handbook for Object-Oriented

Volume 2: Considerations and Issues

This Handbook does not constitute Federal Aviation Administration (FAA)

APPENDIX B MAPPING OF ISSUE LIST TO CONSIDERATIONS......................................................... 2-29

APPENDIX C ADDITIONAL CONSIDERATIONS FOR PROJECT PLANNING.................................... 2-42

2.1.2 Purpose and Organization of Volume 2

2.2 Considerations Before Making the Decision to Use OOT

1 Making the Choice for OOT

1.2 Technical Challenges

1.3 Available Resources

3. OOT Specific Resources

2.2.1 Reality of the Benefits

2.2.2 Project Characteristics

2.2.3 OOT Specific Resources

2.2.4 Regulatory Guidance

2.2.5 Technical Challenges

2.3 Considerations After Making the Decision to Use OOT

2.3.1 Considerations for the Planning Process

Submitted by: ________________________ Date: _