Overview

2. Overview • Issues list • Pattern catalog • Tool support • OCP results • Plans

3. Issues list • Identifies 83 issues related to software for high assurance systems based on: • Handbook for Object-Oriented Technology in Aviation (OOTiA), Proceedings of FAA/NASA Workshops 1 & 2 on Object-Oriented Technology in Aviation, 2003 • Guide to the Certification of Systems with Embedded Object-Oriented Software, Aerospace Vehicle Systems Institute (AVSI), 2001 • Gary Daugherty, Certifiability of CORBA, Rockwell Collins Technical Report, 2001 • “Object-Oriented Technology (OOT) In Civil Aviation Projects: Certification Concerns”, CAST-4, January 2000, http://av-info.faa.gov/software • Leanna K. Rierson. Object-Oriented Technology (OOT) in Civil Aviation Projects: Certification Concerns, Federal Aviation Administration, Washington, D.C. • Ye Wu and Jeff Offutt. Maintaining Evolving Component-Based Software with UML, George Mason University Technical Report, 2002 • Barbara Liskov and Jeanette Wing. “A Behavioral Notion of Subtyping”, ACM Transactions on Programming Languages and Systems, 16(6): 1811-1841, November 1994.

4. Issues list • Includes both design level and language level issues: • Bertrand Meyer. “Applying design by contract.” IEEE Computer 25(10):40-51, October 1992. • Guide to the use of the Ada Programming Language in high integrity systems, ISO/IEC TR 15942, 2000 • John Barnes. High Integrity Ada: The SPARK Approach, Addison-Wesley, Harlow, England, ISBN 0-201-17517-7, 1997 • Use of the C++ Programming Language, Certification Authorities Software Team (CAST), position paper, CAST-8, January, 2002 • David W. Binkley. C++ in Safety Critical Systems, NIST, November 1995 • Boeing, BCA Technical Standard for the Use of C++ in Airborne Software, D6-82801, 2002 • Scott Meyers. Effective C++, 2nd edition, Addison-Wesley, Reading, MA, 1998 • Scott Meyers. More Effective C++, Addison-Wesley, Reading, MA, 1996 • Ian Joyner. C++??: A critique of C++ and Programming Language Trends of the 1990s, 1996 • Marshall P. Cline and Greg A. Lamow. C++ FAQs, Addison-Wesley, Reading, MA, 1995.

5. Issues list • And issues related to verification and testing: • Jeff Offutt, et al. A Fault Model for Subtype Inheritance and Polymorphism, Twelfth IEEE International Symposium on Software Reliability Engineering (ISSEE ’01), 2001 • Robert T. Alexander et al. Fault Detection Capabilities of Coupling-based OO Testing, Colorado State University Technical Report, 2001 • Robert V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, Reading, MA, 2000. • Robert T. Alexander and Jeff Offutt. Analysis Techniques for Testing Polymorphic Relationships, In Thirteenth International Conference on Technology of Object-Oriented Languages and Systems (TOOLS30), 1999.

6. Pattern catalog • Forty two design patterns intended to address the most significant issues • Ten of these are abstract (define the problem) • Thirty two are concrete (provide specific/alternative solutions) • Specified in “Gang of Four” format • With formal specifications (to support automation) in XPSL/XML • And well defined relationships between patterns (extends, requires, excludes, etc.) • Developed incrementally

7. Pattern catalog • Increment one • Development of eXtensible Pattern Specification Language (XPSL/XML) • Development of patterns for: Control flow, Data integrity, Pointer integrity, Unintended side effects, Multiple inheritance

8. Pattern catalog • Increment two • Extension of XPSL (in terms of specific queries/views/transformations) • Development of patterns for: Contracts and subtyping, Coupling and cohesion, OO metrics, Dynamic resource allocation, Safety critical language subsets

9. Tool support • For 8 patterns addressing 10 issues • Implementation based on ISU’s KCS toolset • Programs represented in eXtensible Common Intermediate Language (XCIL/XML) • Framework to support XPSL queries, views and transformations • Developed incrementally

10. Tool support • Increment one • Development of XCIL • Translation of C++ to XCIL, • Verification of translation, • Analysis framework (queries and views), • Analysis support for selected increment one patterns, • Focus on “local” patterns, affecting individual OCP components

11. Tool support • Increment two • Adaptation framework (transformations), • Adaptation support for selected increment one patterns, • Analysis support for selected increment two patterns, • Focus on “global” patterns, requiring an analysis of the entire OCP

12. Technical issues • Size of the OCP • Manual nature of the review process • Lack of tool support for HA analysis and transformation • Lack of user control (user defined patterns) • Regression testing (first do no harm) • Need to integrate with other tools

13. Technical Approach Modeling tools (GME, Rose, etc.) HA Models Models KCS toolset (for translation, analysis, and adaptation) Adapted XML/XMI models XML/XMI models HA SW SW Adapted OCP, and other software source (in C++, Java, other languages.) OCP and other software source (in C++, Java, other languages) Patterns in XML/XMI Developer Review/edit T-VEC formal specs T-VEC Regression testing Issues List Catalog of patterns for high assurance software

14. OCP results • OCP 2.2 • http://dirac.ee.iastate.edu/ocp/ • Issues • Patterns • Matches • Adaptations

15. Classification of problems • Hard run time error • An error appears in the current code. A fault may occur when the erroneous code is executed. • Lurking run time error • A hard run time error may result if additional correct code is introduced. • Potential run time error • A problem that may fall into one of the run time error categories – although we don’t know which. • Obstacle to analysis • The code cannot be analyzed in some manner typically required for “certification” (potentially masking/hiding run time errors). • Maintenance risk • The code is correct, but subsequent changes are likely to introduce errors.

16. Increment one • Addresses issues related to • Implicit type conversion • Violations of strong typing • Control flow • Compiler generated constructors, operators • Pointer integrity

17. Issue 4: Implicit type conversion • Implicit type conversion may involve a potential loss of data or precision • “Type conversions shall not be made from a longer to a shorter (number of bits) type” “Type conversion shall not be made from an unsigned type to a signed type of the same size” “Type casting shall be explicitly coded with use of the keywords const_cast, static_cast and reinterpret cast, and shall not be left as an operation only implied by the code (e.g., an assignment statement)” Boeing. BCA Technical Standard for the Use of C++ in Airborne Software, D6-82801 • “Loss of information rule.To help ensure correctness, any conversions that may result in loss of data or data accuracy and precision should be explicit, should be conspicuously marked (identified) in the program source code, and should only be permitted after thorough review and analysis of potential adverse effects.” [OOTiA Position Paper on Type Conversion]

18. Issue 4: Implicit type conversion • Implicit type conversion between logically unrelated types (e.g., integer and boolean, character and integer) may violate the principles of strong typing • “Unchecked conversion rule. To help ensure type safety and verification, all unchecked conversions should be explicit, be conspicuously marked (identified) in the program source code, and be permitted only after thorough review and analysis of potential adverse effects.” [OOTiA Position Paper on Type Conversion] • “Scalar type rule. Implicit conversions between scalar types should only be permitted when the new type defines a set of operations that is logically a subset of those defined by the old type.” [OOTiA Position Paper on Type Conversion] • “Supertype rule.To help ensure type safety and verification, all implicit type conversions involving references to class instances should only represent a conversion from a subtype to one of its supertypes.” [OOTiA Position Paper on Type Conversion]

19. Issue 4: Implicit type conversion • Implicit type conversion may incur a significant, hidden overhead (e.g., due to implicit constructor calls) • “Low overhead rule.To ensure that the developer does not introduce significant hidden overhead and performance issues, implicit type conversions should only be used for predefined scalar types and references to structured types.” [OOTiA Position Paper on Type Conversion] • Very hot to Hot, rank = 3

20. Pattern: Safe Type Conversion • Restricts implicit conversions to those that are type safe, low overhead, and guarantee no loss of data or precision, i.e. • Conversion of a smaller integer type to larger integer type whose range subsumes the original, with sign extension of two’s complement values • Conversion from a smaller IEEE 754 floating point type to a larger IEEE 754 floating point type • Conversion from a reference type S to a reference type T, provided S is a subtype (subclass or subinterface) of T • Conversion from an Array/Vector whose element type is a reference type SC to an Array/Vector whose element type is a reference type TC, provided that SC is a subtype of TC • Conversion from a general collection type whose element type is a reference type to a collection of the same type whose element type is a reference type TC, provided that SC is a subtype of TC

21. Pattern: Safe Type Conversion • Specifies that type conversions between logically unrelated types (e.g., integer and boolean, character and integer) must be explicit • Specifies that type conversions that may incur a significant overhead (e.g., that use constructors or conversion operators to perform type conversion) must be explicit • Specifies that supertype to subtype conversions (down casts) must either be proven to be correct (by means of analysis) or must be guarded by a run time check

22. Matches • No implicit conversions between integer and float • 58,675 implicit conversions of a larger value to a smaller value • 352 implicit conversions of a signed value to an unsigned value • 87 implicit conversions of an unsigned value to a signed value • Matches represent potential run time errors

23. Adaptations • Subject to review • Need to consider which implicit conversions are “high overhead” • Need report on types converted from/to • Need report on all writes to variables involved in conversions • Need to consider whether the actual range of values of the source type fits within the range of values permitted by the destination type • Need to consider whether the converted values are treated as numeric values (whether signed/unsigned matters) • Introduce user defined types or typedefs • Use bool instead of integer type • Use single size, avoid conversions • Use explicit conversions • Introduce run-time range checks (when not performed by C++)

24. To do • Identify “low overhead” vs. ”high overhead” implicit conversions • Provide the suggested reports as an aid to the review process • Provide for feedback (annotations) to feed the toolset information derived from reviews • Look for all conversions between logically unrelated types (not just integer/float) • Look for explicit conversions that involve a potential loss of data or precision • Look for down casts (supertype to subtype conversions) • Look for definitions of implicit conversion operations • See pattern for details

25. Issue 17: Break in switch • Error prone, especially when cases are later added or removed • “Each case in a switch, which contains any executable code, shall be terminated with a break.” “This eliminates the dubious practice of falling through a case to use code in a succeeding case for common processing. It is too easy to lose track of the correct program flow in code maintenance.” Mandatory for DO-178B software levels A through D Boeing. BCA Technical Standard for the Use of C++ in Airborne Software, D6-82801 • Hot, Rank = 4

26. Pattern: Fall through switch case • Multiple cases may be associated with the same code • However, each block of code associated with a case must end in a ‘break’ • This includes the last case of the switch statement (in case other cases are later added after it)

27. Matches • 461 fall through cases • Matches represent maintenance risks

28. Adaptations • Refactor code to either: • introduce a method called by both cases (when the shared code is cohesive) • introduce an inlined call (when the shared code is short and cohesive) • introduce a conditional (if statement or nested case) when the shared code is not cohesive • introduce replicated code (when the shared code is short but not cohesive)

29. To do • Support one or more of the suggested adaptations • Support user selection of the adaptation to be applied

30. Issue 19: Use of goto’s • Complicates analysis • The use of goto should be excluded because it complicates flow analysis (FA), symbolic analysis (SA), timing analysis (TA), and structural testing (ST). The use of goto is regarded as both unnecessary, and undesirable compared to the use of other control structures. It should not appear in well written code. Guide for the Use of the Ada Programming Language in High Integrity Systems, ISO/IEC TR 15942 R. Chapman. SPARK – A state-of-the-practice approach to the Common Criteria implementation requirements, Praxis Critical Systems • Hot, Rank = 4

31. Pattern: Goto-free execution • The pattern forbids all explicit goto’s • But does not forbid implicit goto’s (such as those implied by the use of if statements, switch statements, loops, or exception throws)

32. Matches • 1,744 explicit gotos • Matches represent false positives if the goto’s are generated by macros as a substitute for exception throws (as many apparently are) • These should be OK, assuming exception handling/error handling jumps are themselves allowed • Otherwise matches represent maintenance risks, obstacles to analysis, and potential run time errors

33. Adaptations • Subject to review • Unless used as a substitute for exceptions, refactor code to: • replace goto with structured control flow (conditional, loop, break, continue, error return, other common forms) • If used as a substitute for exceptions, apply exception/error handling patterns: • Enforcing the disciplined use of exceptions (per Bertrand Meyer) • Ensuring all reported errors (thrown exceptions) have handlers – as in Java • Eliminate macros in favor of pattern substitution, allowing a variety of error reporting/error handling strategies

34. To do • Provide support to for “macro recognition” • Develop/apply error handling patterns, replacing the use of macros for this purpose

35. Other related patterns from the catalog • Jump-free execution • No user thrown exceptions • Top level handler for predefined exceptions

36. Issue 25: Compiler generated operations • Compiler generated operations have default meanings that may be inappropriate for a given class. • Since the default constructor, copy constructor, destructor, and the operators operator=, operator&, and operator, (i.e., operator<comma>) all have default meanings; they should be explicitly defined in every class. To avoid unwanted implicit calls to these constructors and operators, declare them private. – [Binkley, C++ in Safety Critical Systems] • Law of The Big Three: “If a class needs a destructor, or a copy constructor, or an assignment operator, it needs them all” … “During code reviews and debugging sessions, we have traced many core dumps back to violations of The Law” [Cline and Lomow, C++ FAQs] • “Declare a copy constructor and an assignment operator for classes with dynamically allocated memory” [Scott Meyers, Effective C++, 2nd edition, item 11] • Declare a constructor for all classes with an user defined invariant – Based on the FAA/NASA OOTiA Handbook completeinitialization rule,invariant rule and invariant assertion rule • Hot, Rank = 4

37. Pattern: Compiler generated operations • Constructor rule • If we have a user defined invariant, we need a user defined constructor • All fields without initial values must be set by a user defined constructor • Copy constructor rule • If the class has dynamically allocated components, we need a user defined copy constructor • Assignment rule • If the class has dynamically allocated components, we need a user defined assignment operator • Destructor rule • If the class has dynamically allocated components, we need a user defined destructor • Consistency rule • If the class has a user overrides the default behavior of its destructor, copy constructor, or assignment operator, then it should override the behavior of all three

38. Matches • 1,451 classes with compiler generated default constructors • 2,078 classes with compiler generated copy constructors • 2,100 classes with compiler generated “=” operators • 2,218 classes with compiler generated “&” operators • Matches are subject to application of the previous rules • Violations of the rules represent likely run time errors or lurking run time errors

39. Adaptations • The user is responsible for introducing the necessary operations, while the tool is responsible for checking the user supplied code • In addition the tool may introduce run-times checks of constructor postconditions, to ensure the class invariant is established • Checks of user supplied constructor • Run time check of invariant as postcondition • Check that all fields are initialized • Checks of user supplied copy constructor • Run time check of invariant as postcondition • Check that all dynamically allocated components are replicated (deep copy) • Check of user supplied assignment operator • Check that all dynamically allocated components are replicated (deep copy) • Check of user supplied destructor • Check that all dynamically allocated components are deallocated

40. To do • Provide tool support for associated rules • Support the selective insertion of code to check constructor postconditions (class invariants)

41. Issue 30: Pointer arithmetic • Use of pointer arithmetic • Bounds checks and invalid pointer values • “Operational software shall not include pointer arithmetic.” “In general, there is little justification for going to the effort of designing code to do pointer arithmetic. The performance gained by doing pointer arithmetic is seldom worth the increased risk of error.” Explicit pointer value calculation is prohibited for DO-178B software levels A through D Boeing. BCA Technical Standard for the Use of C++ in Airborne Software, D6-82801 • “Direct manipulation of pointer values (pointer arithmetic) should be prohibited … Java and C# can be used as a guide. What cannot be done is these languages generally should not be allowed. ” [Daugherty, Certifiability of CORBA] • Obstacle to analysis • Hot, Rank = 5

42. Pattern: No pointer arithmetic • A pointer can be used only as a substitute for an opaque reference, i.e., in XCIL: • On the left hand side of an assignment • In a reference to the value of an attribute • In a reference to the value of an array element • In a reference to the length of an array • In reference to the run time type of an object • As the target of a dispatching call • As an argument to a call • As a value returned by a method • As the thrown value of an exception • In a reference to an object to be locked/unlocked

43. Matches • 470 instances of pointer arithmetic • Matches represent potential run time errors and obstacles to analysis

44. Adaptations • Replace each array element pointer with an array base pointer and index, performing all arithmetic on indices rather than pointer values • Selectively introduce run-time bounds checks (typically not performed by C++ compilers) • Restrict other uses of pointers in XCIL to the cases given (in which the use of a pointer is compatible with the use of an opaque reference), requiring the user to make associated changes

45. To do • Complete tools-related work on transformations to eliminate arithmetic involving array pointers • Develop strategy for incremental introduction of changes • For examnple, support a conversion from array pointer types to a type representing an array reference + index (class ArrayReference) • Explicitly apply this conversion to all parameters passed into/out of the portion of the software to be changed • Incrementally adapt the entire OCP and its support libraries

46. Issue 47: Use of union (untagged variant records) • Can lead to errors that cannot be caught by the compiler and violations of strong typing • “The type union should not be used” “union is an untagged type. Its use can lead to data type errors that cannot be trapped by the compiler” Prohibited for DO-178B software levels A through D Boeing. BCA Technical Standard for the Use of C++ in Airborne Software, D6-82801 • “Use a class hierarchy with virtual functions in place of a union as it provides type checking of the data stored in the union” [Binkley, C++ in Safety Critical Systems] • Hot, Rank = 6 17 April 03 / SLIDE 46

47. Pattern: Non-discriminated union • The pattern forbids all untagged (non-discriminated) unions

48. Matches • 9 declarations of untagged union types • Matches represent maintenance risks, obstacles to analysis, and potential run time errors

49. Adaptations • Replace untagged union with • class-subclass • class-state = tagged union (discriminated record)

50. To do • Add abstract pattern and two concrete subpatterns (for conversion to class-subclass and class-state) to catalog • Develop tool support for the associated transformations (giving the user a choice of which to apply)