1 / 36

DO-178C Object Oriented and Related Technologies Supplement

DO-178C Object Oriented and Related Technologies Supplement. August 2009. Topics. Core OOT Concepts including Related Technologies (type conversion, exception management, reuse) Type Consistency (class hierarchy), Liskov substitution principle (LSP) Dynamic Dispatch Virtualization

tyler
Download Presentation

DO-178C Object Oriented and Related Technologies Supplement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related