High-integrity object-oriented programming with Ada - Part 1

Operation Overriding
Operation Overriding
Inheritance in object-oriented languages makes possible two kinds of programming errors in connection with operation overriding:

• Declaring a new or overloaded operation when overriding was intended

• Overriding an operation when a new one was intended

The first issue typically arises from a misspelling of the name of the operation that is supposed to be overridden. The second issue can arise when an operation is added to a superclass. If a subclass happened to declare an operation with a matching signature, then recompilation of the subclass will cause this declaration to be treated as overriding. In either case, dynamic binding will not give the expected result.

An object-oriented language’s susceptibility to these vulnerabilities depends on whether it provides explicit syntax, to be checked by the compiler, identifying the programmer’s intent as to whether a declaration is to be regarded as overriding.

Multiple Inheritance
Two major vulnerabilities are associated with multiple inheritance. In the case of multiple interface inheritance, if two interfaces contain an identical method signature, a (non-abstract) class that inherits from these interfaces will need to provide a single implementation for both. However, the intent (contracts) of the methods in the two interfaces may be completely unrelated, raising the issue of how one implementation can work for two different purposes. Similarly, and depending on the language’s rules for operation overloading, two interfaces may contain operation signatures such that it is impossible to inherit from both.

In the case of multiple implementation inheritance, several semantic issues complicate traceability analysis and software verification:

• Name clashes, in which operations with the same signature or fields with the same name are inherited from multiple superclasses.
• “Diamond inheritance,” in which a root class RC has subclasses C1 and C2 which are in turn superclasses of C3, raising the issue of what C3 inherits indirectly from RC.

These are not necessarily fatal flaws — languages supporting multiple inheritance will define the semantics for these features — but they do add complexity in terms of both human understanding and formal certification.

Other issues
A number of additional language features are often used in conjunction with OOP, so their vulnerabilities and certification-related issues are relevant. These features include parametric polymorphism (generic templates), overloading (using the same name for different program entities, in particular for different operations), type conversion, exception management, and virtualization (use of an intermediate execution platform such as a JVM). These aspects fall outside the scope of this article. For more information, see reference 3.

OOP clearly brings expressive power and flexibility, but can also introduce a range of vulnerabilities. Their impact on the development of high-integrity software depends on the programming language used and the language’s semantics for specific OOP features. Ada offers a distinctive approach, simplifying compliance with the new guidance in DO-178C. The language’s underlying support for reliable, safe, and secure programming fits in smoothly with OOP. Ada’s OOP features are being used in software certified at the highest level of safety criticality, and the upcoming Ada 2012 standard further enhances the language’s OOP support.

Look for Part 2 and Part 3 of this article in coming weeks, discussing Ada semantics and how the language addresses the various OOP vulnerabilities described above.

References
1. RTCA SC-167 / EUROCAE WG-12. DO-178B – Software Considerations in Airborne Systems and Equipment Certification; December 1992.
2. RTCA SC-205. DO-178C – Software Considerations in Airborne Systems and Equipment Certification. Draft IP 50, Rev X; 2011.
3. RTCA SC-205. Object-Oriented Technology Supplement to DO-178C and DO-278A. Draft IP0060_O; 2011.
4. B. Liskov and J. Wing. "A behavorial notion of subtyping," ACM Transactions on Programming Languages and Systems (TOPLAS), Vol. 16, Issue 6 (November 1994), pp. 1811-1841.

Related articles
Automating rule sets for safety-critical HDL coding
Cut the cost of code development with traceability tools
Developing secure code using SPARK
MILS architecture simplifies design of high-assurance systems
Case study: Threat simulation for multi-port radar and electronic warfare systems
HiRel for space
Addressing obsolescence with hardware abstraction layers
Leakage-resistant protocols protect high-security applications
Designing automatic test systems for extended duty
Choosing test equipment for high-speed digital I/O in mil/aero applications
ATML standard simplifies test equipment data exchange
Modular platforms support automated test for mil/aero applications
EMI and transient protection for MIL-compliant systems

About the Author
Benjamin Brosgol is a senior member of the technical staff of AdaCore. He has been involved with programming language design and implementation for more than thirty years, concentrating on languages and technologies for high-integrity systems. He was a distinguished reviewer of the original Ada language specification and a member of the design team for the Ada 95 revision.


Did you find this article of interest? Then visit Military & Aerospace Designline, where we update daily with design, technology, product, and news articles tailored to fit your world. Too busy to go every day? Sign up for our newsletter to get the week's best items delivered to your inbox. Just click here and choose the "Manage Newsletters" tab.