> **Volume 2: Considerations and Issues**
>
> **Revision 0**

**October 26, 2004**

![](media/image1.png){width="3.0in" height="1.2673611111111112in"}

Contents

[2.1 Introduction 2-1](#introduction)

[2.1.1 Background 2-2](#background)

[2.1.2 Purpose and Organization of Volume 2
2-2](#purpose-and-organization-of-volume-2)

[2.2 Considerations Before Making the Decision to Use OOT
2-3](#considerations-before-making-the-decision-to-use-oot)

[2.2.1 Reality of the Benefits 2-4](#reality-of-the-benefits)

[2.2.2 Project Characteristics 2-4](#project-characteristics)

[2.2.3 OOT Specific Resources 2-5](#oot-specific-resources)

[2.2.4 Regulatory Guidance 2-5](#regulatory-guidance)

[2.2.5 Technical Challenges 2-6](#technical-challenges)

[2.3 Considerations After Making the Decision to Use OOT
2-8](#considerations-after-making-the-decision-to-use-oot)

[2.3.1 Considerations for the Planning Process
2-8](#considerations-for-the-planning-process)

[2.3.2 Considerations for Development Processes \-- Requirements,
Design, Code, and Integration
2-10](#considerations-for-development-processes----requirements-design-code-and-integration)

[2.3.3 Considerations for Integral Processes
2-14](#considerations-for-integral-processes)

[2.3.4 Additional Considerations 2-19](#additional-considerations)

[2.4 Open Issues (Summary of Workshop #2 Brainstorming Session)
2-21](#open-issues-summary-of-workshop-2-brainstorming-session)

[2.5 Summary 2-22](#summary)

[2.5.1 Summary of Decision-Making Process for Using OOT
2-22](#summary-of-decision-making-process-for-using-oot)

[2.5.2 Summary of Key Areas of Concern for OOT When Meeting DO-178B
2-22](#summary-of-key-areas-of-concern-for-oot-when-meeting-do-178b)

[2.6 References 2-24](#references)

[**Appendix A** **Results of the Beyond the Handbook Session**
2-27](#__RefHeading___Toc86482559)

[**Appendix B** **Mapping of Issue List to Considerations**
2-29](#__RefHeading___Toc86482560)

[**Appendix C** **Additional Considerations for Project Planning**
2-42](#__RefHeading___Toc86482561)

[C.1 Conceptual Pitfalls 2-42](#__RefHeading___Toc86482562)

[C.2 Analysis and Design Pitfalls 2-42](#__RefHeading___Toc86482563)

[C.3 Class and Object Pitfalls 2-42](#__RefHeading___Toc86482564)

[C.4 Verification Pitfalls 2-43](#__RefHeading___Toc86482565)

[C.5 Reuse Pitfalls 2-43](#__RefHeading___Toc86482566)

Figures

[Figure 2.2‑1 Original Classification Scheme for the "Beyond the
Handbook" Questions 2-3](#__RefHeading___Toc86482567)

## 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.

### 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.

### 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 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.

## 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?*

[]{#__RefHeading___Toc86482567 .anchor}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

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.

### 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.

### 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.

### 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.

### 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, 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\].

### 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.

#### 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.

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.

#### 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.

#### 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.

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.

## 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.

### 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:

#### 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), 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.

#### 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)

#### 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)

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.

### 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:

#### 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.

##### 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)

##### 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)

#### 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.

##### 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)

##### 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\]:

```{=html}
<!-- -->
```
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.

#### 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\].

#####  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).

##### 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\].

#### 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]{.underline} - 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"* \[10\].

*"[Deactivated code]{.underline} - 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"* \[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.

#####  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)

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)

##### 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)

### 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.

#### 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.

##### 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 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)

##### 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)

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.

#####  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)

##### 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, 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)

####  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.

##### 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)

##### 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)

####  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.

##### 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)

##### 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)

#### 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).

##### 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
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)

##### 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)

#####  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.

##### 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)

### 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:

#### 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)

#### 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)

#### 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)

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)

## 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?

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.

## 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.

### 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.

### 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.

#### 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)

d)  Have appropriate language restrictions been established, documented,
    and followed? (section 2.3.1.3)

#### 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)

#### Questions to Consider for Integral Processes

##### 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)

##### 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)

##### 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)

#### 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.

## References 

1.  Alexander, Roger T. "Improving the Quality of Object-Oriented
    Programs," *IEEE Software*, September/ October 2001, pp. 90-91.

2.  Aerospace Vehicle Systems Institute. *Guide to the Certification of
    Systems with Embedded Object-Oriented Software*. Version 1.2, 31
    October 2001.

3.  Aerospace Vehicle Systems Institute. *Guide to the Certification of
    Systems with Embedded Object-Oriented 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.

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 18^th^
    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, 2^nd^ 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 12^th^ 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.]{.underline}

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.

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 20^th^ 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.

```{=html}
<!-- -->
```
A.   []{#__RefHeading___Toc86482559 .anchor}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?

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?

```{=html}
<!-- -->
```
B.   []{#__RefHeading___Toc86482560 .anchor}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).

+---+------------------------------------+--------------+--------------+
| * | **Issue Statement**                | **DO-178B    | **Volume 2   |
| * |                                    | Life Cycle   | reference    |
| I |                                    | Process      | and          |
| L |                                    | Impacted**   | Category**   |
| \ |                                    |              |              |
| # |                                    |              |              |
| * |                                    |              |              |
| * |                                    |              |              |
+===+====================================+==============+==============+
| 1 | Deactivated Code will be found in  | Development  | 2.3.2.4.2    |
|   | any application that uses general  |              | libraries &  |
|   | purposed libraries or              |              | frameworks   |
|   | object-oriented frameworks. (Note  |              |              |
|   | that this is the case where unused |              |              |
|   | code is NOT removed by smart       |              |              |
|   | linkers.)                          |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | Flow Analysis, recommended for     | Integral     | 2.3.3.1.1    |
|   | Levels A-C, is complicated by      | (V           | flow         |
|   | Dynamic Dispatch (just which       | erification) | analysis     |
|   | method in the inheritance          |              |              |
|   | hierarchy is going to be called?). |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | Timing Analysis, recommended for   | Integral     | 2.3.3.1.3    |
|   | Levels A-D is complicated by       | (V           | timing and   |
|   | Dynamic Dispatch (just how much    | erification) | stack        |
|   | time will be expended determining  |              | analysis     |
|   | which method to call?).            |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Requirements Testing, recommended  | Integral     | 2.3.3.2.2    |
|   | for Levels A-D, and Structural     | (V           | test case    |
|   | Coverage Analysis, recommended for | erification) | reuse        |
|   | Levels 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,      | Integral     | 2.3.3.1.2    |
|   | recommended for Levels A-C, is     | (V           | structural   |
|   | complicated by Dynamic Dispatch    | erification) | coverage     |
|   | (just which method in the          |              | analysis     |
|   | inheritance hierarchy does the     |              |              |
|   | execution apply to?).              |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Conformance to the guidelines in   | Integral     | 2.3.3.1.4    |
|   | DO-178B concerning traceability    | (V           | source to    |
|   | from source code to object code    | erification) | object trace |
|   | for Level A software is            |              |              |
|   | complicated by Dynamic Dispatch    |              |              |
|   | (how is a dynamically dispatched   |              |              |
|   | call represented in the object     |              |              |
|   | code?).                            |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Polymorphic, dynamically bound     | Development  | 2.3.2.2.1    |
|   | messages can result in code that   |              | unclear      |
|   | is error prone and hard to         |              | intent       |
|   | understand.                        |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Dynamic dispatch presents a        | Integral     | 2.3.3.1.4    |
|   | problem with regard to the         | (V           | source to    |
|   | traceability of source code to     | erification) | object trace |
|   | object code that requires          |              |              |
|   | "additional verification" for      |              |              |
|   | level A systems as dictated by     |              |              |
|   | DO-178B section 6.4.4.2b.          |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Dynamic dispatch complicates flow  | Integral     | 2.3.3.1.1    |
|   | analysis, symbolic analysis, and   | (V           | flow         |
|   | structural coverage analysis.      | erification) | analysis     |
|   |                                    |              |              |
|   |                                    |              | 2.3.3.1.2    |
|   |                                    |              | structural   |
|   |                                    |              | coverage     |
|   |                                    |              | analysis     |
+---+------------------------------------+--------------+--------------+
| 1 | Inheritance, polymorphism, and     | Development  | 2.3.2.2.1    |
| 0 | linkage can lead to ambiguity.     |              | unclear      |
|   |                                    |              | intent       |
+---+------------------------------------+--------------+--------------+
| 1 | The use of inheritance and         | Integral     | 2.3.3.1.2    |
| 1 | polymorphism may cause             | (V           | structural   |
|   | difficulties in obtaining          | erification) | coverage     |
|   | structural coverage, particularly  |              | analysis     |
|   | decision coverage and MC/DC        |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Source to object code              | Integral     | 2.3.3.1.4    |
| 2 | correspondence will vary between   | (V           | source to    |
|   | compilers for inheritance and      | erification) | object trace |
|   | polymorphism.                      |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Polymorphic and overloaded         | Integral     | 2.3.3.4.2    |
| 3 | functions may make tracing and     | (T           | complexity   |
|   | verifying the code difficult.      | raceability) |              |
+---+------------------------------------+--------------+--------------+
| 1 | Requirements Testing, recommended  | Integral     | 2.3.3.2.2    |
| 4 | for Levels A-D, and Structural     | (V           | test case    |
| \ | Coverage Analysis, recommended for | erification) | reuse        |
| * | Levels 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)\]*             |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Multiple interface inheritance can | Development  | 2.3.2.2.1    |
| 5 | introduce cases in which the       |              | unclear      |
|   | developer's intent is ambiguous.   |              | intent       |
|   | (when the same definition is       |              |              |
|   | inherited from more than one       |              |              |
|   | source is it intended to represent |              |              |
|   | the same operation or a different  |              |              |
|   | one?)                              |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Flow Analysis and Structural       | Integral     | 2.3.3.1.1    |
| 6 | Coverage Analysis, recommended for | (V           | flow         |
|   | Levels A-C, are complicated by     | erification) | 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.                  |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Use of inheritance (either single  | Development  | 2.3.2.1.1    |
| 7 | or multiple) raises issues of      |              | type         |
|   | compatibility between classes and  |              | subs         |
|   | subclasses.                        |              | titutability |
+---+------------------------------------+--------------+--------------+
| 1 | Inheritance and overriding raise a | Integral     | 2.3.3.2.2    |
| 8 | number of issues with respect to   | (V           | test case    |
|   | testing: "Should you retest        | erification) | reuse        |
|   | 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?"   |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Inheritance can introduce problems | Development  | 2.3.2.3.2    |
| 9 | related to initialization. "Deep   |              | in           |
|   | class hierarchies \[in             |              | itialization |
|   | particular\] can 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.                  |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | "A subclass-specific               | Development  | 2.3.2.2.2    |
| 0 | implementation of a superclass     |              | 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 | "A subclass \[may be\] incorrectly | Development  | 2.3.2.2.1    |
| 1 | located in a hierarchy. For        |              | unclear      |
|   | example, a developer locates       |              | intent       |
|   | SquareWindow as a 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."      |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | "A subclass either does not accept | Development  | 2.3.2.1.1    |
| 2 | all messages that the superclass   |              | type         |
|   | accepts or leaves the object in a  |              | subs         |
|   | state that is illegal in the       |              | titutability |
|   | superclass. This situation can     |              |              |
|   | occur in a hierarchy that should   |              |              |
|   | implement a subtype relationship   |              |              |
|   | that conforms to the Liskov        |              |              |
|   | substitution principle."           |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | "A subclass computes values that   | Development  | 2.3.2.1.1    |
| 3 | are not consistent with the        |              | type         |
|   | superclass invariant or superclass |              | subs         |
|   | state invariants."                 |              | titutability |
+---+------------------------------------+--------------+--------------+
| 2 | "Top-heavy multiple inheritance    | Development  | 2.3.2.2.1    |
| 4 | and very deep hierarchies (six or  |              | unclear      |
|   | more subclasses) are error-prone,  |              | intent       |
|   | 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"             |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | The ability of a subclass to       | Development  | 2.3.2.2.1    |
| 5 | directly reference inherited       |              | unclear      |
|   | attributes tightly couples the     |              | intent       |
|   | definitions of the two classes.    |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | Inheritance can be abused by using | Development  |              |
| 6 | it as a "kind of code-sharing      |              |              |
|   | macro to support hacks without     |              |              |
|   | regard to the resulting            |              |              |
|   | semantics".                        |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | When the same operation is         | Development  | 2.3.2.2.1    |
| 7 | inherited by an interface via more |              | unclear      |
|   | than one path through the          |              | intent       |
|   | interface hierarchy (repeated      |              |              |
|   | inheritance), it may be unclear    |              |              |
|   | whether this should result in a    |              |              |
|   | single operation in the            |              |              |
|   | subinterface, or in multiple       |              |              |
|   | operations.                        |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | When a subinterface inherits       | Development  | 2.3.2.2.1    |
| 8 | different definitions of the same  |              | unclear      |
|   | operation \[as a result of         |              | intent       |
|   | redefinition along separate        |              |              |
|   | paths\], it may be unclear         |              |              |
|   | whether/how they should be         |              |              |
|   | combined in the resulting          |              |              |
|   | subinterface.                      |              |              |
+---+------------------------------------+--------------+--------------+
| 2 | Use of multiple inheritance can    | Development  | 2.3.2.2.1    |
| 9 | lead to "name clashes" when more   |              | unclear      |
|   | than one parent *independently*    |              | intent       |
|   | defines an operation with the same |              |              |
|   | signature.                         |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | When *different* parent interfaces | Development  | 2.3.2.2.1    |
| 0 | define operations with different   |              | unclear      |
|   | names but compatible               |              | intent       |
|   | specifications, it is unclear      |              |              |
|   | whether it should be possible to   |              |              |
|   | merge them in a subinterface.      |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | It is unclear whether the normal   | Development  | 2.3.2.2.2    |
| 1 | overload resolution rules should   |              | overriding   |
|   | apply between operations inherited |              |              |
|   | from different superinterfaces or  |              |              |
|   | whether they should not (as in     |              |              |
|   | C++).                              |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | It is important that the           | Development  | 2.3.2.2.2    |
| 2 | overriding of one operation by     |              | overriding   |
|   | another and the joining of         |              |              |
|   | operations inherited from          |              |              |
|   | different sources always be        |              |              |
|   | intentional rather than            |              |              |
|   | accidental.                        |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | Multiple inheritance complicates   | Development  | 2.3.2.2.1    |
| 3 | the class hierarchy                |              | unclear      |
|   |                                    |              | intent       |
+---+------------------------------------+--------------+--------------+
| 3 | Multiple inheritance complicates   | Integral     | 2.3.3.3.2    |
| 4 | configuration control              | (C           | c            |
|   |                                    | onfiguration | onfiguration |
|   |                                    | Management)  | control      |
+---+------------------------------------+--------------+--------------+
| 3 | When inheritance is used in the    | Integral     | 2.3.3.4.2    |
| 5 | design, special care must be taken | (T           | complexity   |
|   | to maintain traceability. This is  | raceability) |              |
|   | particularly a concern if multiple |              |              |
|   | inheritance is used.               |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | Source to object code              | Integral     | 2.3.3.1.4    |
| 6 | correspondence will vary between   | (V           | source to    |
| \ | compilers for inheritance and      | erification) | object code  |
| * | polymorphism. *\[Note: this is the |              | traceability |
|   | same issue as IL 12\]*             |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | Overuse of inheritance,            | Development  | 2.3.2.2.1    |
| 7 | particularly multiple inheritance, |              | unclear      |
|   | can lead to unintended connections |              | intent       |
|   | among classes, which could lead to |              |              |
|   | difficulty in meeting the          |              |              |
|   | DO-178B/ED-12B objective of data   |              |              |
|   | and control coupling.              |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | Multiple inheritance should be     | Planning     | 2.3.1.3      |
| 8 | avoided in safety critical,        |              | restrictions |
|   | certified systems.                 |              |              |
+---+------------------------------------+--------------+--------------+
| 3 | "Top-heavy multiple inheritance    | Development  | 2.3.2.2.1    |
| 9 | and very deep hierarchies (six or  |              | unclear      |
| \ | more subclasses) are error-prone,  |              | intent       |
| * | 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" *\[Note:    |              |              |
|   | this is the same issue as IL 24\]* |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Reliance on programmer specified   | Development  |              |
| 0 | optimizations of the inheritance   |              |              |
|   | hierarchy (invasive inheritance)   |              |              |
|   | is potentially error prone and     |              |              |
|   | unsuitable for safety critical     |              |              |
|   | applications.                      |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Inheritance, polymorphism, and     | Development  | 2.3.2.2.1    |
| 1 | linkage can lead to ambiguity.     |              | unclear      |
| \ | *\[Note: this is the same issue as |              | intent       |
| * | IL 10\]*                           |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Inheritance allows different       | Development  | 2.3.2.1.1    |
| 2 | objects to be treated in the same  |              | type         |
|   | general way.                       |              | subs         |
|   |                                    |              | titutability |
|   | 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?            |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Flow Analysis, recommended for     | Integral     | 2.3.3.1.1    |
| 3 | levels A-C, is impacted by         | (V           | flow         |
|   | Inlining (just what are the data   | erification) | analysis     |
|   | 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.                         |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Stack Usage and Timing Analysis,   | Integral     | 2.3.3.1.3    |
| 4 | recommended for levels A-D, are    | (V           | timing and   |
|   | impacted by Inlining (just what    | erification) | stack        |
|   | are the stack usage and worst-case |              | analysis     |
|   | 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.           |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Structural Coverage Analysis,      | Integral     | 2.3.3.1.2    |
| 5 | recommended for levels A-C, is     | (V           | structural   |
|   | complicated by Inlining (just what | erification) | coverage     |
|   | is the "logical" coverage of the   |              | analysis     |
|   | 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.          |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Conformance to the guidelines in   | Integral     | 2.3.3.1.4    |
| 6 | DO-178B concerning traceability    | (V           | source to    |
|   | from source code to object code    | erification) | object trace |
|   | 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.                         |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Inlining may affect tool usage and | Integral     | 2.3.3.1.2    |
| 7 | make structural coverage more      | (V           | structural   |
|   | difficult for levels A, B, and C.  | erification) | coverage     |
|   |                                    |              | analysis     |
+---+------------------------------------+--------------+--------------+
| 4 | The unrestricted use of certain    | Integral     | 2.3.3.1.2    |
| 8 | object-oriented features may       | (V           | structural   |
|   | impact our ability to meet the     | erification) | coverage     |
|   | structural coverage criteria of    |              | analysis     |
|   | DO-178B.                           |              |              |
+---+------------------------------------+--------------+--------------+
| 4 | Statement coverage when            | Integral     | 2.3.3.1.2    |
| 9 | polymorphism, encapsulation or     | (V           | structural   |
|   | inheritance is used.               | erification) | coverage     |
|   |                                    |              | analysis     |
+---+------------------------------------+--------------+--------------+
| 5 | Templates are instantiated by      | Integral     | 2.3.3.1.3    |
| 0 | substituting a specific type       | (V           | timing and   |
|   | argument for each formal type      | erification) | stack        |
|   | parameter defined in the template  |              | analysis     |
|   | class or operation. Passing a test |              |              |
|   | suit for some but not all          |              |              |
|   | instantiations cannot guarantee    |              |              |
|   | that an untested instantiation is  |              |              |
|   | bug free.                          |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | Nested templates, child packages   | Development  |              |
| 1 | (Ada), and friend classes (C++)    |              |              |
|   | can result in complex code and     |              |              |
|   | hard to read error messages on     |              |              |
|   | many compilers.                    |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | Templates can be compiled using    | Integral     | 2.3.3.1.2    |
| 2 | \"code sharing\" or                | (V           | structural   |
|   | \"macro-expansion\". Code sharing  | erification) | coverage     |
|   | is highly parametric, with small   |              | analysis     |
|   | 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.                |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | Macro-expansion can result in      | Integral     | 2.3.3.1.3    |
| 3 | memory and timing issues, similar  | (V           | timing and   |
|   | to those identified for inlining.  | erification) | stack        |
|   |                                    |              | analysis     |
+---+------------------------------------+--------------+--------------+
| 5 | The use of templates can result in | Development  |              |
| 4 | code bloat. Many C++ compilers     |              |              |
|   | cause object code to be repeated   |              |              |
|   | for each instance of a template of |              |              |
|   | the same type.                     |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | How can we meet the structural     | Integral     | 2.3.3.1.2    |
| 5 | coverage requirements of DO-178B   | (V           | structural   |
|   | with respect to dynamic dispatch?  | erification) | coverage     |
|   | There is cause for concern because |              | analysis     |
|   | 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.                            |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | How can we meet the control and    | Integral     | 2.3.3.1.1    |
| 6 | data flow analysis requirements of | (V           | flow         |
|   | DO-178B with respect to dynamic    | erification) | analysis     |
|   | dispatch?                          |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | How can deactivated code be        | Development  | 2.3.2.4.2    |
| 7 | removed from an application when   |              | libraries &  |
|   | general purpose libraries and      |              | frameworks   |
|   | object-oriented frameworks are     |              |              |
|   | used but not all of the methods    |              |              |
|   | and attributes of the classes are  |              |              |
|   | needed by a particular             |              |              |
|   | application?                       |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | How can we enforce the rules that  | Planning     | 2.3.1.3      |
| 8 | restrict the use of specific OO    |              | restrictions |
|   | features?                          |              |              |
+---+------------------------------------+--------------+--------------+
| 5 | Implicit type conversion raises    | Integral     | 2.3.3.1.4    |
| 9 | certification issues related to    | (V           | source to    |
|   | source to object code              | erification) | object trace |
|   | 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.                       |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Overloading can be confusing and   | Development  | 2.3.2.2.2    |
| 0 | contribute to human error when it  |              | overriding   |
|   | 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.                |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Loss of traceability due to the    | Integral     | 2.3.3.4.1    |
| 1 | translation of functional          | (T           | function vs. |
|   | requirements to an object-oriented | raceability) | object       |
|   | design.                            |              | tracing      |
+---+------------------------------------+--------------+--------------+
| 6 | Functional coverage of the low     | Integral     | 2.3.3.2.1    |
| 2 | level requirement                  | (V           | requir       |
|   |                                    | erification) | ements-based |
|   |                                    |              | testing      |
+---+------------------------------------+--------------+--------------+
| 6 | Philosophy of Functional Software  | Planning     | 2.3.1.2      |
| 3 | Engineering - Most of the          |              | requirements |
|   | training, tools and principles     | Development  | methods and  |
|   | associated with software           |              | notations    |
|   | engineering and assurance,         |              |              |
|   | including those of RTCA 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, 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.   |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Software/software integration      | Integral     | 2.3.3.2.1    |
| 4 | testing is often avoided. The      | (V           | requir       |
|   | position defended by the industry  | erification) | ements-based |
|   | is that the high level of          |              | testing      |
|   | interaction between a great number |              |              |
|   | of objects could lead to a         |              |              |
|   | combinative explosion of test      |              |              |
|   | cases.                             |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Could there be security concerns   | Additional   |              |
| 5 | related to the use of COTS based   | Co           |              |
|   | OOT solutions? Particularly with   | nsiderations |              |
|   | respect to field loadable          |              |              |
|   | software, security risks have been |              |              |
|   | mitigated by the unique            |              |              |
|   | architectures of most current      |              |              |
|   | systems.                           |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Use of dynamic memory              | Development  | 2.3.2.3.1    |
| 6 | allocation/deallocation and use of |              | i            |
|   | exception handling were raised as  |              | ndeterminate |
|   | issues by Leanna Rierson in her    |              | execution    |
|   | paper \"Object-Oriented Technology |              | profiles     |
|   | (OOT) 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.      |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | Most OO languages use reference    | Integral     |              |
| 7 | semantics for passing objects      | (V           |              |
|   | (e.g. Java only supports reference | erification) |              |
|   | semantics; C++ 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.                |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | The selection of the code to       | Development  |              |
| 8 | implement an operation may depend  | or Integral  |              |
|   | upon more than just the run-time   | (Ve          |              |
|   | type of the target object. In      | rification)? |              |
|   | cases involving 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\")                 |              |              |
|   |                                    |              |              |
|   | 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.                           |              |              |
+---+------------------------------------+--------------+--------------+
| 6 | The use of OO methods typically    | Integral     | 2.3.3.2.1    |
| 9 | leads to the creation of many      | (T           | requir       |
|   | small methods which are physically | raceability) | ements-based |
|   | distributed over a large number of |              | testing      |
|   | 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.                    |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | The difference between dead and    | Development  | 2.3.2.4.1    |
| 0 | deactivated code is not always     |              | identifying  |
|   | clear when using OOT. Without good | Integral     | dead and     |
|   | traceability, identifying dead vs. | (T           | deactivated  |
|   | deactivated code may be difficult  | raceability) | code         |
|   | or impossible.                     |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | When a design contains abstract    | Development  | 2.3.2.4.1    |
| 1 | base classes, portions of the      |              | identifying  |
|   | implementations of these classes   |              | dead and     |
|   | may be overridden in more          |              | deactivated  |
|   | specialized subclasses, resulting  |              | code         |
|   | deactivated code.                  |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Traceability is made more          | Integral     | 2.3.3.4.3    |
| 2 | difficult because there is often a | (T           | tracing      |
|   | lack of OO methods or tools for    | raceability) | through OO   |
|   | the full software lifecycle.       |              | views        |
+---+------------------------------------+--------------+--------------+
| 7 | Formal specification languages are | Planning     | 2.3.1.2      |
| 3 | generally accessible only to those |              | requirements |
|   | specially trained to use them. To  |              | methods and  |
|   | make formal specifications         |              | notations    |
|   | accessible to developers and the   |              |              |
|   | 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.   |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Change impact analysis may be      | Integral     | 2.3.3.3.2    |
| 4 | difficult or impossible due to     | (C           | c            |
|   | difficulty in tracing functional   | onfiguration | onfiguration |
|   | requirements through               | Management)  | control      |
|   | implementation.                    |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Limitations of UML may limit how   | Planning     | 2.3.1.2      |
| 5 | non-functional and cross-cutting   |              | requirements |
|   | requirements of realtime, safety   | Development  | methods and  |
|   | critical, distributed,             |              | notations    |
|   | fault-tolerant, embedded systems   |              |              |
|   | are captured in UML and traced to  |              |              |
|   | the design, implementation, and    |              |              |
|   | test cases.                        |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Configuration management may be    | Integral     | 2.3.3.3.1    |
| 6 | difficult in OO systems, causing   | (C           | c            |
|   | traceability problems. If the      | onfiguration | onfiguration |
|   | objects and classes are considered | Management)  | id           |
|   | configuration items, they can be   |              | entification |
|   | difficult to trace, when used      |              |              |
|   | multiple times in slightly         |              |              |
|   | different manners.                 |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | What is "low level requirements"   | Planning     | 2.3.1.1      |
| 7 | for OO? Affects how we do          |              | defining     |
|   | low-level testing. If we don't     |              | life cycle   |
|   | know what low-level requirements   |              | data         |
|   | 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.                          |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Addressing derived requirements    | Planning     | 2.3.1.2      |
| 8 | for OO -- how does this happen?    |              | requirements |
|   | How is it different than           |              | methods and  |
|   | traditional and how does it tie up |              | notations    |
|   | to the safety assessment. Not      |              |              |
|   | really unique for OO.              |              |              |
|   |                                    |              |              |
|   | Will be addressed when we do the   |              |              |
|   | artifact mapping.                  |              |              |
+---+------------------------------------+--------------+--------------+
| 7 | Difficult to identify individual   | Planning     | 2.3.1.2      |
| 9 | atomic requirements in OO. UML     |              | requirements |
|   | tends to group requirements in a   |              | methods and  |
|   | graphical format. Would complicate |              | notations    |
|   | matters if considered derived.     |              |              |
|   |                                    |              |              |
|   | For derived requirements, the      |              |              |
|   | entire graph would be passed to    |              |              |
|   | the safety folk for evaluation of  |              |              |
|   | safety impact.                     |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Lower levels of decomposition may  | Planning     | 2.3.1.2      |
| 0 | not be possible for some           |              | requirements |
|   | requirements (e.g., performance    | Development  | methods and  |
|   | requirements). Levels of           |              | notations    |
|   | abstraction may be different than  |              |              |
|   | traditional.                       |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Are there unique challenges for    | Integral     | 2.3.3.1.4    |
| 1 | source to object code traceability | (V           | source to    |
|   | in non-Level A systems? Where      | erification) | object code  |
|   | should this be addressed? Multiple |              | traceability |
|   | tools and ways of addressing       |              |              |
|   | s-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?              |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Is there another "class" of tool   | Additional   | 2.3.4.3 tool |
| 2 | qualification for visual modeling  | Co           | q            |
|   | tools to demonstrate the integrity | nsiderations | ualification |
|   | 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?                             |              |              |
|   |                                    |              |              |
|   | Typically part of the tool         |              |              |
|   | selection process. Concern seems   |              |              |
|   | to be addressed by Handbook mod.   |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Auto-test and code generation      | Additional   | 2.3.4.3 tool |
| 3 | tools -- what are the concerns     | Co           | q            |
|   | when a single tool generates code  | nsiderations | ualification |
|   | and test from 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.                 |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Maintaining tool environment,      | Additional   | 2.3.4.2 tool |
| 4 | archives, ... when licenses are    | Co           | environments |
|   | involved is not clear. May need to | nsiderations |              |
|   | have some kind of "permanent       |              |              |
|   | license" to support safety and     |              |              |
|   | continued airworthiness of the     |              |              |
|   | aircraft.                          |              |              |
|   |                                    |              |              |
|   | OO more dependent on tools, but    |              |              |
|   | not necessarily an OO-specific     |              |              |
|   | issue.                             |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Maturity/long-term support of      | Additional   | 2.3.4.2 tool |
| 5 | tools. Tool manufacturers may not  | Co           | environments |
|   | realize the long-life need of      | nsiderations |              |
|   | 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.   |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Are there other types of OO tools  | Additional   | 2.3.4.2 tool |
| 6 | that need to be addressed? Need to | Co           | environments |
|   | anticipate other classes of tools  | nsiderations |              |
|   | that 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),                 |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | How does OO life cycle data map to | Planning     | 2.3.1.1      |
| 7 | the DO-178B section 11 life cycle  |              | defining     |
|   | data? E.g., What "source code"     |              | life cycle   |
|   | mean in OO? What is req, design,   |              | data         |
|   | 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.                          |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Configuration management and       | Integral     | 2.3.3.3.2    |
| 8 | incremental development of OO      | (C           | c            |
|   | projects and tools. When CM comes  | onfiguration | onfiguration |
|   | into play during the development   | Management)  | control      |
|   | process may be different than our  |              |              |
|   | 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.               |              |              |
+---+------------------------------------+--------------+--------------+
| 8 | Is dynamic dispatch compatible     | Integral     | 2.3.3.1.1    |
| 9 | with DO-178B required forms of     | (V           | flow         |
|   | static analysis? Mention that      | erification) | analysis     |
|   | dynamic dispatch 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.                 |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Fundamental pre-requisite language | Development  | 2.3.2.1.1    |
| 0 | issues need clarification prior to |              | type         |
|   | adopting LSP and DBC. How can LSP  |              | subs         |
|   | be implemented using available     |              | titutability |
|   | languages?                         |              |              |
|   |                                    |              |              |
|   | Strongly consider a language       |              |              |
|   | subset that is amenable to use of  |              |              |
|   | LSP and DBC. Concern is how far to |              |              |
|   | take this subset.                  |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Inconsistent Type Use (ITU):       | Development  | 2.3.2.1.2    |
| 1 |                                    |              | inconsistent |
|   | When a descendant class does not   |              | type use     |
|   | 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.      |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | State Definition Anomaly (SDA):    | Development  | 2.3.2.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.                             |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | State Definition Inconsistency     | Development  | 2.3.2.2.2    |
| 3 | (SDIH):                            |              | overriding   |
|   |                                    |              |              |
|   | If an indiscriminately-named local |              |              |
|   | state variable is introduced, a    |              |              |
|   | data flow anomaly can result.      |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | State Defined Incorrectly (SDI):   | Development  | 2.3.2.2.2    |
| 4 |                                    |              | 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.                |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Indirect Inconsistent State        | Development  | 2.3.2.1.1    |
| 5 | Definition (IISD):                 |              | type         |
|   |                                    |              | subs         |
|   | When a descendent adds an          |              | titutability |
|   | extension method that defines an   |              |              |
|   | inherited state variable, an       |              |              |
|   | inconsistent state definition can  |              |              |
|   | occur.                             |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Anomalous construction behavior    | Development  | 2.3.2.2.2    |
| 6 | (ACB1):                            |              | 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.       |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Anomalous construction behavior    | Development  | 2.3.2.2.2    |
| 7 | (ACB2):                            |              | 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.            |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | Incomplete construction (IC):      | Development  | 2.3.2.3.2    |
| 8 |                                    |              | in           |
|   | If the constructor does not        |              | itialization |
|   | establish initial state 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.     |              |              |
+---+------------------------------------+--------------+--------------+
| 9 | State Visibility Anomaly (SVA):    | Development  | 2.3.2.2.2    |
| 9 |                                    |              | 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.                 |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | When using OO tools to develop     | Additional   | 2.3.4.3 tool |
| 0 | software requirements, design and  | Co           | q            |
| 0 | implementation, it is beneficial   | nsiderations | ualification |
|   | 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.                          |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Current visual modeling tools that | Additional   | 2.3.4.1 tool |
| 0 | are used for OO development make   | Co           | capability   |
| 1 | use of frameworks for automatic    | nsiderations |              |
|   | 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.                         |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Current visual modeling tools that | Additional   | 2.3.4.1 tool |
| 0 | are used for OO development        | Co           | capability   |
| 2 | provide a capability to generate   | nsiderations |              |
|   | 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.  |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | The current structural coverage    | Additional   | 2.3.4.1 tool |
| 0 | tools available may not "be aware" | Co           | capability   |
| 3 | or have visibility to the          | nsiderations |              |
|   | 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.    |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Class hierarchies can become       | Integral     | 2.3.3.4.2    |
| 0 | overly complex, which complicates  | (T           | complexity   |
| 4 | traceability. Generalization, weak | raceability) |              |
|   | aggregation, strong aggregation,   |              |              |
|   | association and composition are    |              |              |
|   | some of the relations that can be  |              |              |
|   | used to create the class diagrams. |              |              |
|   | []{.mark}                          |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Iterative development is often     | Integral     | 2.3.3.4.4    |
| 0 | desired in OO implementation. Each | (T           | iterative    |
| 5 | iterative cycle has its own        | raceability) | 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.                   |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | Reusability is one of the          | Development  | 2.3.2.4.1    |
| 0 | objectives of OO development, but  |              | identifying  |
| 6 | reusable components may be hard to |              | dead and     |
|   | trace because they are designed to |              | deactivated  |
|   | support multiple usages of the     |              | code         |
|   | same component. Reusable           |              |              |
|   | components may also have           |              |              |
|   | functionality that may not be used |              |              |
|   | in every application.              |              |              |
+---+------------------------------------+--------------+--------------+
| 1 | If polymorphism and dynamic        | Integral     | 2.3.3.1.3    |
| 0 | binding are implemented, this can  | (V           | timing and   |
| 7 | cause the stack size to grow,      | erification) | stack        |
|   | making it difficult to analyze the |              | analysis     |
|   | optimal stack size.                |              |              |
+---+------------------------------------+--------------+--------------+

C.   []{#__RefHeading___Toc86482561 .anchor}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.

1.  []{#__RefHeading___Toc86482562 .anchor}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.

2.  []{#__RefHeading___Toc86482563 .anchor}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.

3.  []{#__RefHeading___Toc86482564 .anchor}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 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.

4.  []{#__RefHeading___Toc86482565 .anchor}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.

5.  []{#__RefHeading___Toc86482566 .anchor}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.

[^1]: There are actually 107 entries to the list, but 4 of them are
    duplicates.

[^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.

[^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.