DO-178C Object Oriented and Related Technologies Supplement

1. DO-178CObject Oriented and Related Technologies Supplement August 2009

2. Topics • Core OOT Concepts including • Related Technologies (type conversion, exception management, reuse) • Type Consistency (class hierarchy), Liskov substitution principle (LSP) • Dynamic Dispatch • Virtualization • Dynamic Memory Management • Supplement • Overview of changes in sections 4 through 6 • Appendix OO.E Vulnerabilities and Guidelines for OOT 2009 FAA SW & CEH

3. Related Technologies • There are a number of topics that are not pure OO issues – we refer to them as “Related Technologies”. They include: • (data) Type Conversion (coercion) • Exception Management • Reuse 2009 FAA SW & CEH

4. Related Technologies - Type Conversion • Type conversions that change the view of the underlying data representation are more prevalent in OO technology. • The change can either be from a subtype to a supertype (upcast), or from a supertype to a subtype (downcast). • The change from a subtype to a supertype is allowed by the type system and usually implicit. 2009 FAA SW & CEH

5. Related Technologies – Type Conversion • The change from a supertype to a subtype must be performed with care and is generally unsafe without sufficient precautions. • OO.E.1.3.1 Vulnerabilities • The vulnerabilities are dependent on the nature of the type conversion. With a narrowing type conversion, data may be lost.With a downcast, the vulnerability depends on the implementation in a particular language. It may result in data corruption of the object itself or its neighbors in memory, incorrect behavior, or a runtime exception being thrown. 2009 FAA SW & CEH

6. Related Technologies - Exception Management • Exceptions signal abnormal (error) conditions detected within a method. • The ability to throw exceptions within a method and to handle exceptions in the calling method is a common feature of most object-oriented languages. 2009 FAA SW & CEH

7. Related Technologies - Exception Management • The exception management strategy should define if exceptions are used and if so: • in which cases exceptions should be thrown, • where they should be caught, and • how they should be handled. • Exceptions should be considered as part of the class requirements and for verifying substitutability. 2009 FAA SW & CEH

8. Related Technologies - Reuse • More emphasis on “Component” and life cycle artifacts. • Reuse is at the CLASS level. • Greater opportunity for deactivated features. 2009 FAA SW & CEH

9. Related Technologies - Reuse • Need to consider the class hierarchy and inheritance rules. • The component architecture needs to be well defined, including its requirements and its error management and resource management policies. • Compatibility with the global system architecture needs to be addressed. • Ensure verification is complete for deactivated elements of a component 2009 FAA SW & CEH

10. Type Consistency (class hierarchy), Liskov substitution principle (LSP) • Types and Type Safety • Subclass, subtype equivalence • A subclass is a subtype • Liskov's substitution principle • Method and class specification: • Preconditions: acceptable input values • Postconditions: return values, including exceptions and errors, and side effects • Invariants: unchanging relationships on data 2009 FAA SW & CEH

11. Type Consistency (class hierarchy), Liskov substitution principle (LSP) • Liskov's Substitution Principle • Formally defines a subtype. • Important aspect of type consistency. • Necessary because users can define new subtypes through subclassing • Evaluated where type substitution can occur. • Substitutability is essential for a subclass to be used in the place of one of its superclasses. • Assurance is enhanced when one can depend on the type system to reduce errors. 2009 FAA SW & CEH

12. Type Consistency (class hierarchy), Liskov substitution principle (LSP) • What is substitutability? • Is a square the same as a rectangle? • Can I use a square everywhere I can use a rectangle? Example from www.as3dp.com Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle 2009 FAA SW & CEH

13. Type Consistency (class hierarchy), Liskov substitution principle (LSP) • Liskov and Requirements • A subclass must fulfill the requirements of all its superclasses. • Each method in the subclass that is also declared in a superclass should have • preconditions that are the same or weaker than the method in the superclass, • postconditions that are the same or stronger than the method in the superclass, and • Invariants that are not weaker. 2009 FAA SW & CEH

14. Type Consistency (class hierarchy), Liskov substitution principle (LSP) • Here we can use square or rectangle anywhere we use Boxes. • The Base Class is abstract. Each subclass provides the unique properties and methods. • Pre and postconditions are maintained. Example from www.as3dp.com Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle 2009 FAA SW & CEH

15. Dynamic Dispatch • Method Dispatch is the mapping of a method call to its associated implementation. • It can be done statically or dynamically 2009 FAA SW & CEH

16. Dynamic Dispatch • Static dispatch is normally implemented as a procedure call. • It can be done safely only when the method is not redefined in a subclass of the static type. • When a subtype of the static type redefines the method being called, the method of the static type (an ancestor type of the actual type) is still called. • Since this can lead to unintended or erroneous behavior, some languages provide a means to ensure that statically dispatched methods can not be overridden. 2009 FAA SW & CEH

17. Dynamic Dispatch • When a method call is dynamic dispatched, the mapping to a specific implementation is performed at runtime. • Dynamic dispatching ensures that the method of the actual class is called even though the actual type cannot be determined statically (during compilation). • Dynamic dispatch is only used for code invocation. 2009 FAA SW & CEH

18. Dynamic Dispatch • Example: • A Reader is an input stream that produces characters • subclasses of Reader get their characters from different sources. • a file (a file reader) or • a character array in memory (an array reader) • Method to get the characters (getChar) 2009 FAA SW & CEH

19. Dynamic Dispatch • The getChar method returns the integer value of the Reader’s characters, • When a Reader’s supply of characters is empty, getChar returns -1. • The getChar method will be dynamically dispatched based on the subclass hierarchy of Readers. 2009 FAA SW & CEH

20. Dynamic Dispatch class Test { public static void DoPrint( Reader r ) { r.Print(); } public static void main(String[] args) { Reader x = new Reader(); Reader y = new FileReader(); MemReader z = new MemReader() DoPrint(x); DoPrint(y); DoPrint(z); } 2009 FAA SW & CEH

21. Why do care? • What does type consistency do for us ? • It can be shown by Formal Analysis or Test • Based on preconditions, postconditions, & invariants • If demonstrated • Reduces verification burden (optimistic testing) • Verifies that all objects of a subclass are supported. • Makes control coupling easier 2009 FAA SW & CEH

22. Why do care? • If NOT demonstrated • Increases verification burden (pessimistic testing) • Must verify that each object of a subclass is supported. • Makes control coupling analysis more difficult 2009 FAA SW & CEH

23. Virtualization • Virtualization defines an intermediate execution platform (YES its part of your target environment). • When verifying this execution platform, the data for that layer is the executable code for the layer above. • When using an execution platform, the data executed on the platform is executable code 2009 FAA SW & CEH

24. Virtualization • The main vulnerability is that the code of a given virtualization layer may be considered to be data, consequently, tracing may be neglected, and verification may be insufficient. • Examples include • microcode, • operating systems, • virtual machines, and • Interpreters (i.e.; XML, state machines). 2009 FAA SW & CEH

25. Dynamic Memory Management • Not just garbage collection. • Memory is typically allocated at startup and not released. • How to allow dynamic memory allocation and deallocation deterministic. 2009 FAA SW & CEH

26. Dynamic Memory Management • Dynamic memory management must be robust with regards to the vulnerabilities. • reference ambiguity, • fragmentation starvation, • deallocation starvation, • memory exhaustion, • premature deallocation, • lost updates and stale references, and • unbound allocation or deallocation time 2009 FAA SW & CEH

27. Supplement – Sections 4 through 6 • Section 4 Software Planning Process • 2 new activities • Use of Virtualization • Expanded information on reuse • Life cycle data changes • PSAC • Design standard • Code standard • SAS 2009 FAA SW & CEH

28. Supplement – Sections 4 through 6 • Section 5 Software Development Process • 5 new activities • Class hierarchy • Ensure type consistency • Memory management strategy • Exception management strategy • Deactivated functionality through reuse • Life cycle data changes • No changes to OO.11.9, OO.11.10, OO.11.11, OO.11.12 2009 FAA SW & CEH

29. Supplement – Sections 4 through 6 • Traceability (section 5.5) • In an OO design, all functionality is implemented in methods. • Traceability is from requirements to the methods that implement the requirements. • Classes are an artifact of the architecture for organizing the requirements. • Due to subclassing, a requirement which traces to a method implemented in some class should also trace to the method in its subclasses when the method is overridden in the subclass. 2009 FAA SW & CEH

30. Supplement – Sections 4 through 6 • Section 6 Software Verification Process • 4 new/modified activities against current objectives • Class hierarchy • Verify type consistency (new analysis) • Verify Memory management against requirements • Verify Exception management against requirements 2009 FAA SW & CEH

31. Supplement – Sections 4 through 6 • Section 6 Software Verification Process • 2 new objectives • Local Type Consistency Verification • Dynamic Memory Management • 7 new activities • Life cycle data changes • Software Verification Results 2009 FAA SW & CEH

32. Appendix OO.E Vulnerabilities and Guidelines for OOT • OO.E.1 Key Features • OO.E.1.1 Inheritance • OO.E.1.2 Parametric Polymorphism • OO.E.1.3 Type Conversion • OO.E.1.4 Overloading • OO.E.1.5 Exception Management • OO.E.1.6 Dynamic Memory Management • OO.E.1.7 Virtualization 2009 FAA SW & CEH

33. Appendix OO.E Vulnerabilities and Guidelines for OOT • OO.E.2 General Issues • OO.E.2.1 Traceability • OO.E.2.2 Structural Coverage • OO.E.2.3 Component Based Development • OO.E.2.4 Resource Analysis 2009 FAA SW & CEH

34. Appendix OO.E Vulnerabilities and Guidelines for OOT • Each Topic provides • Vulnerabilities related to the topic. • Reference to guidance in the body of the Supplement. • Guidelines on meeting the guidance. 2009 FAA SW & CEH

35. Have we covered all the Issues • IP 508 – Traceability to all OOTiA issues, CRIs, FAA IPs, CAST Paper 4 • Use IP 508 to show: • Where valid issues are addressed in the Supplement. • Why some issues are not addressed. 2009 FAA SW & CEH

36. Contact Information Jim Chelini Verocel, Inc 234 Littleton Road, Suite 2A Westford, MA 01886 chelini@verocel.com Jan-Hendrik Boelens Eurocopter Deutschland GmbH ETZNM - System Engineering & Integration 81663 Munich, Germany e-mail: jan-hendrik.boelens@eurocopter.com 2009 FAA SW & CEH