OOT_Paper_IP508_Rev0A
26 Pages

OOT_Paper_IP508_Rev0A

Course: D 100006, Fall 2009

School: Embry-Riddle FL/AZ

Word Count: 9593

Rating:

Document Preview

WG-71/SC-205 Information Paper Software General Information Information Paper Number: Call to get #: Leave fax # Revision: Date: Comments Due: IP# 508 Author/Fax/Internet: 0A June 9th 2005 Send Comments to (Include Name/Address/Fax/Voice/Internet): Joseph Angelo Joseph.angelo@novatel.ca Fax: (403)- 295-4999 Joseph Angelo GPS Systems Engineer 1120 68th Ave NE Calgary AB T2E 8S5 Canada 403-2954931 Working Paper...

Unformatted Document Excerpt
Coursehero >> Florida >> Embry-Riddle FL/AZ >> D 100006

Course Hero has millions of student submitted documents similar to the one
below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.

Course Hero has millions of student submitted documents similar to the one below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.

Information WG-71/SC-205 Paper Software General Information Information Paper Number: Call to get #: Leave fax # Revision: Date: Comments Due: IP# 508 Author/Fax/Internet: 0A June 9th 2005 Send Comments to (Include Name/Address/Fax/Voice/Internet): Joseph Angelo Joseph.angelo@novatel.ca Fax: (403)- 295-4999 Joseph Angelo GPS Systems Engineer 1120 68th Ave NE Calgary AB T2E 8S5 Canada 403-2954931 Working Paper Title: Object Oriented Technology Abstract: A number of research activities have been conducted to study the certification of Object Oriented Software to DO-178B standards. The FAA co-sponsored the creation of an Object Oriented Technology in Aviation (OOTiA) Handbook. The OOTiA Handbook identifies the key OO Software certification issues and also has guidelines on handling those issues. This paper studies primarily the information in the Handbook and other related studies and research papers to clearly define the OO software issues that are likely to impact safety. The purpose of this paper is to decide the course of action that needs to be taken with regards to the Handbook and the incorporation of its guidelines in DO-178C or its Supplement. The paper concludes by recommending an approach in capturing the OO specific objectives and clarifications. Action taken: Resolution Required By: Key words (Optional): Status Distribution Name Org Internet Fax 1 Introduction.......................................................................................................................3 2 Software Planning Process................................................................................................4 2.1 Mapping OO Software Life Cycle Data to DO-178B Life Cycle Data.....................4 2.2 Software Development Standards..............................................................................4 3 Software Development Process........................................................................................5 3.1 Complex Constructs and Features in OO design and Development..........................5 3.2 Data and Control Coupling........................................................................................6 3.3 Dead/Deactivated Code.............................................................................................6 3.4 Traceability................................................................................................................7 4 Software Verification Process...........................................................................................8 4.1 Software Reviews and Analysis.................................................................................8 4.2 Software Testing Process...........................................................................................8 4.3 Structural Coverage Analysis....................................................................................8 4.3.1 Class Context Sensitive Structural Coverage.....................................................8 4.3.2 Active Objects and Multiply Instantiated Objects.............................................9 4.4 Handling of Visual Modeling Tools..........................................................................9 4.5 Verification of Inheritance Hierarchies...................................................................10 4.6 Source Code to Object Code Traceability...............................................................10 5 Handling of the Issue List Defined in the OOTiA Handbook Volume 2.......................12 6 Future of OOTiA Handbook and Handling of OO Software in DO-178C.....................25 7 Conclusion......................................................................................................................25 8 References.......................................................................................................................26 2 1 Introduction A number of research activities have been conducted to study the certification of Object Oriented (OO) Software to DO-178B standards. The FAA co-sponsored the creation of an Object Oriented Technology in Aviation (OOTiA) Handbook. The OOTiA Handbook identifies the key OO Software certification issues and also has guidelines on handling those issues. This paper studies primarily the information in the Handbook and other related studies and research papers to clearly define the OO software issues that are likely to impact DO-178B certification. The paper also looks at the various options in defining the objectives/clarifications specific to OO software. The paper finally recommends possible actions that can be taken to resolve the OO issues identified. The SC205/WG-71 Object Oriented Technology Sub Group (SG-5) has the mandate to recommend the actions that need to be taken pertaining to the certification of airborne OO software. SG-5 can recommend the modification/addition of existing DO-178B objectives as required by OO and incorporate these as part of DO-178C. The other option would be to add all OO specific objectives to a separate Object Oriented Software Certification Supplement. OO specific clarifications could be incorporated in the next revision of DO-248B that would be DO248C. Alternately there could be an OO Supplement that could as part of its Appendix contain clarification data for some of the new objectives. The general rule of thumb is to keep out all technology specific objectives from DO-178C and to use a separate Supplement to deal with technology specific issues such as OO software. This paper addresses all the OO specific issues raised by the Handbook in detail when appropriate. A table specifying the recommendations for each of the issues raised in the Handbook is also included towards the end of this paper. This paper captures the OO issues for each software life cycle process specified in DO-178B and recommends the action that needs to be taken to resolve the issues. Where relevant the paper also refers to OO issues that are commonly considered to be difficult to certify but for which the current DO-178B objectives are sufficient. Finally the paper talks about the future of the Handbook and the certification documents that may be required to be produced by SG-5 to handle OO certification issues. 3 2 Software Planning Process DO-178B section 4 describes the objectives of the Software Planning Process and also provides guidance for this activity. The primary activity in this phase is summarized by objectives 4.1e "Software development standards consistent with the system safety objectives for the software to be produced are defined (subsection 4.5)" and 4.1f "Software plans that comply with subsection 4.3 and section 11 have been produced." 2.1 Mapping OO Software Life Cycle Data to DO-178B Life Cycle Data A major concern in the planning phase has been the mapping of the DO-178B specified software life cycle data to an OO software development cycle. Specifically mapping low-level requirements to OO design data has been considered to be a problem. DO-178B in its current form does not preclude the use of OO design data such as class diagrams, object model diagrams, state chart diagrams, activity diagrams etc. The planning documents themselves do not require additional clarification or objectives. It would be up to the applicant to provide mapping between the OO design data and the data required as low-level requirements in DO-178B. The applicant would have to show what constitutes high-level and low-level requirements for an OO based design. Further the applicant would have to define a way of indicating derived requirements. The current objectives in DO-178B clearly address this issue and further OO specific objectives or clarifications are not required. 2.2 Software Development Standards DO-178B section 4.5c 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". This objective can lead to ambiguous interpretation for OO software since a number of OO constructs can be construed to be non-verifiable. One way of handling this issue is to clarify this in a clarification document (for e.g. DO-248C or Appendix to OO Supplement) with OO examples that would be construed as non-verifiable. Guidance could also be given in the OO Supplement with regards to the verification of specific complex OO constructs. There could also be an addition of OO specific examples to the Development standards sections (refer Section 11.6, 11.7 and 11.8 of DO-178B). Examples could call out OO specific design constraints such as exclusion of Multiple Inheritance, templates etc, complexity restrictions such as maximum level of single inheritance. The above issue would result in the addition of objectives and possibly clarifications in an OO specific Supplement. This is further discussed in the next section. 4 3 3.1 Software Development Process Complex Constructs and Features in OO design and Development The OOTiA handbook and many other papers related safety critical OO software discourage the use of certain OO constructs and provide guidelines on handling some of these complex features of OO design. Concerns have been raised regarding the use of the following OO features a. Single Inheritance/Dynamic Dispatch with method overriding b. Multiple Inheritance c. Templates d. Inlining e. Type Conversion f. Operator and method overloading. Some of the above features are fundamental to OO design and development and really reflect what sets OO apart from software written using procedural languages. If the applicants were restricted totally from using the above features it would be equivalent to precluding the use of OO software in airborne software. It is however clear that the above features when used have to be addressed carefully with clearly defined rules and restrictions. The OOTiA handbook lists guidelines to help in the safe use of these OO features. The OOTiA guidelines offer one way of dealing with these OO features and should not be part of any OO specific objectives. However in order to ensure that strict rules are enforced with regards to the above features it might be necessary to explicitly require the restricted use of the above features. DO-178B does not explicitly list the features in procedural languages that might be construed to be ambiguous and unsafe. DO-178B does cite constraints (refer to section 11.7e) such as exclusion of recursion as examples for design constraints. DO-178B section 11.8a also recommends limiting the use of some features of a language. But in the case of OO software it might be necessary to add an objective that explicitly refers to specific OO features, which require special constraints and design standards. One of the objectives in the OO Supplement could specifically ask the user to define how the above features are used in the design, what constraints are going to be placed on their use, what are the documentation requirements when using the above features and what are the specific verification requirements imposed when verifying the use of these features. This objective would enforce the careful use and verification of these features. Just providing objectives without specifying detailed guidelines would allow the applicant to define standards that are project specific but at the same time address all the safety concerns associated with the use of these OO features. This would allow for any future technological developments in the safe design and verification of OO software to be incorporated into these applicant defined standards without requiring updates to the OO specific Supplement. As an example in order to comply with this objective the applicant may decide to test every instance of a template when the compiler uses the code sharing approach for implementing templates. Further clarification may be produced as part of a clarification document (for e.g. DO-248C or Appendix to OO Supplement) as to what kind of restrictions may be imposed. For example the clarifications document may recommend restrictions on number of levels in the inheritance hierarchy, exclusion of multiple inheritance, 5 object code tracing of templates and inlined code, exclusion of overloading operators or methods when semantics are different etc. The OOTiA handbook volume 3 provides extensive guidelines that are specific to the development and verification of software that use the above features. A concise version of these guidelines may be provided as part of the clarifications document. The above approach would ensure that objectives exist to enforce restrictions on development and verification and at the same time some clarification is available for those who need it. 3.2 Data and Control Coupling DO-178B Sec 6.4.4.2c requires that the structural coverage analysis "should confirm the data coupling and control coupling between the code components". The intent behind this objective was to ensure that coverage analysis of software integration tests is done to verify that the control and data flow defined in the design are satisfied by the source code. OO features such as dynamic dispatch, multiple inheritance and inlining are expected to exacerbate the problem in verifying data and control coupling of the code. The OOTiA handbook offers some guidelines with regards to class coupling but offers no further guidelines for confirming data and control coupling. Currently this objective could be satisfied by defining interfaces between modules in the design stage and verifying those interfaces as part of the software integration tests during the software integration testing phase. DO-178B also calls for reviews and analysis of the software architecture and source code. Sec 3.1 of this paper recommends, the addition of objectives to define special handling of OO constructs such as multiple inheritance, inlining and dynamic dispatch in the design and verification stage. In addition to this no additional objective should be required to address the data and control coupling issue. FAQ #67 in Sec 3.67 of DO-248B provides some guidelines on confirming data and control coupling. These guidelines could be extrapolated for an OO based design and development. Further study on this topic is being conducted as part of a separate information paper. 3.3 Dead/Deactivated Code DO-178B defines dead/deactivated code as unused/intentionally unused code/data in the executable object code domain and not in the source code domain. Refer to the definitions section of DO-178B. This would imply that unused class methods and abstract base class methods that are overridden in all derived classes will not constitute dead code so long as a smart linker does not link those methods into the executable object code. However unused object attributes would be part of the executable object code. In the case where the only access to these unused attributes is through inlined unused accessor/mutator functions, it would be difficult to identify these unused attributes using traditional source code coverage tools. Most compilers will also not complain about these unused attributes. This may have safety implications in the operational airborne software. DO-178B currently advises that dead code and de-activated code be identified during the structural coverage analysis resolution phase (refer to DO-178B 6.4.4.3c and 6.4.4.5d). Since structural coverage analysis may not detect this dead code, this might warrant additional guidance in the Reviews and Analysis of OO source code. The OOTiA handbook also raises the issue of "unclear intent" with regards to unused class methods and abstract base class methods that are overridden in all derived classes. This issue will be good to handle as good programming practice but does not warrant additional objectives. The recommendation in Sec 3.1 that requires the applicant to clearly define the use of inheritance and 6 overriding would handle this issue. 3.4 Traceability Section 5.5 of DO-178B provides guidance for traceability from system requirements to highlevel requirements to low-level requirements to source code. The OOTiA handbook raises concerns about showing traceability when using visual modeling tools to define the low-level requirements in the form class diagrams, activity diagrams or state charts. Concerns have also been raised regarding the actual tagging of the low-level design data when they are defined in the form of diagrams. It has also been cited that Configuration Control could be challenging. The handbook also raises concerns about tracing functional requirements to operations that may be implemented across multiple objects. Current OO modeling tools all have different features and hence a generalized guideline on demonstrating traceability would not be prudent. A number of different approaches could be taken to show traceability from functional requirements to multiple objects that may implement them. The handbook Volume 3 also provides guidelines in this regard. This issue does not warrant additional objectives or clarifications. 7 4 Software Verification Process The software verification process as described in DO-178B consists of Software Reviews and Analyses (sec 6.3 DO-178B) and Software testing (sec 6.4 DO-178B). 4.1 Software Reviews and Analysis The main addition for OO software would be the direct reference to complex constructs and features referred to in Sec 3.1 of this paper. This is warranted by the fact that genuine safety concerns have been raised regarding the improper use of these constructs. Specific objectives need to be added to the OO Supplement and clarifications may also be provided. 4.2 Software Testing Process DO-178B primarily requires requirements based testing of high level and low-level requirements and structural coverage analysis of those tests to measure the code coverage obtained by executing the requirements based tests. The degree of requirements based testing and structural coverage analysis varies with the safety level assessed for the software. 4.3 Structural Coverage Analysis The handbook and reference 8 show the inadequacy of existing structural coverage objectives for OO software. 4.3.1 Class Context Sensitive Structural Coverage Use of inheritance and method overriding is shown to require class context sensitive structural coverage. When performing the structural coverage analysis on a class method it will also be required to record the type of object in whose context the method is executed. This will ensure that calls from overriding derived class methods to base class methods are tested in addition to testing of calls from the overridden base class methods to base class methods. For e.g. Consider the following code snippet Class Base { void foo() { ... handlemessage(); ...} void bar() { ....handlemessage();...} virtual void handlemessage() {...} } class Derived: public Base { virtual void handlemessage() {...} } void test() { Base b; 8 Derived d; b.foo(); d.bar(); // // b.bar(); // need for complete class context sensitive coverage // d.foo(); // need for complete class context sensitive coverage } A class context sensitive coverage requirement would enforce the testing of the two methods in the context of both the base and derived classes. The traditional structural coverage requirement would be satisfied with just the two uncommented calls in function test() above. In procedural languages a function/procedure can be taken to be a unit so all data interactions are confined to that function. In an OO language the class can be considered to be a unit as any method in the class can update any of the class attributes, which in turn will affect its interactions with other methods in the class. This will be the driving force behind requiring class context sensitive coverage metrics. When traversing an inheritance hierarchy this will require re-testing base class methods in the derived class' context only for those base class methods that call methods redefined in the derived class. A conservative approach would be to test all non-overridden base class methods in the context of all derived classes. Decision Coverage, statement coverage and MC/DC metrics would potentially need to be generated in the context of all relevant classes. A separate information paper is being written to deal with this issue in greater detail. However it is clear at this point that an additional coverage metric is required for OO software. This would warrant the addition of objectives that are specific to OO software. They would definitely have no impact on non-OO software. This testing requirement warrants a set of objectives in an OO specific Supplement. 4.3.2 Active Objects and Multiply Instantiated Objects In OO languages it is common to designate certain objects as Active objects i.e. an instance of an object will be executed in its own thread context. Traditional structural coverage metrics could incorrectly give the impression that a method has been fully tested by aggregating the coverage achieved by all threads. A very simple case would be where a single class is instantiated multiple times as active objects. The interactions that the method under test has with the class attributes will not be fully tested, as the coverage would have been achieved over multiple objects. The same problem also exists when multiple instances of the same class are instantiated in the software. In OO software there is hence a need to show coverage in the context of the active object. This issue would require objectives to be added to the OO Supplement if recommended by the paper on structural coverage. 4.4 Handling of Visual Modeling Tools Code generation tools exist that can take state chart diagrams, activity diagrams, class diagrams and object model diagrams and generate code that can be fully deployed with little or no additional code to be added by the user. Although code generation tools are readily available to generate complete code from visual models, technology hasn't advanced to the extent where structural coverage of requirements based tests can be shown on the visual models. As of today all coverage tools are still source code/object code coverage tools when tests are executed on the target computer. This precludes doing tests on the models and ensuring model to source code traceability. This would mean that the code generated by the tools would still need to be treated as if they were written manually. But the auto-generation of code would be a useful tool to show 9 traceability between source code and low-level design. Complete auto-code generation implies source code to low-level design traceability. When the auto-generated code is modified manually, source to low-level design traceability is no longer implicit but must be done using traditional procedures. Although concerns have been raised regarding the use of auto-code generation tools one can see that as long as the source code generated complies with the objectives there would be no safety or certification concerns. If the source code is not reviewed or analyzed and if structural coverage is not provided on the source code it might require the code-generation tool to be qualified as a development tool. The auto-generated code will include code from the framework, which should also be treated as regular source code that complies with the required certification objectives. In any case this issue does not warrant additional guidance or clarifications. 4.5 Verification of Inheritance Hierarchies The OOTiA handbook and other referenced papers and books do recommend the exclusion of multiple inheritance in safety critical software. It has been recommended in this paper that the design standards should specifically define the restrictions placed on the use of multiple inheritance. It may also be recommended by the sub-group to add guidance that explicitly excludes the use of multiple inheritance. This paper also recommends that design standards should define constraints and restrictions on the use of single inheritance and dynamic dispatch. Reviews and analysis would verify the compliance to the defined design standards. When using single inheritance it has been shown in this paper that class context sensitive structural coverage is required. Reverification of base class methods that are called by overriding derived class methods has been shown to be a requirement. In reference 8 testing of the flattened class is also recommended. Re-using base class test cases for re-testing the inherited methods in the context of the derived class would give the additional benefit of checking compliance with Liskov's substitution principle. Irrespective of the approach to be recommended it is clear that additional guidance is required in the verification of inheritance hierarchies. Clarification on how to satisfy these objectives may be part of a clarifications document. 4.6 Source Code to Object Code Traceability Source code to object code traceability is currently a requirement for Level A software. OO software has a number of constructs that require the compiler to implicitly add object code that cannot be traced to source code. Following are some of the OO features that will result in nontraceable object code. 1. Inlining, 2. Call to constructors, 3. Call to destructors 4. Assignment and copy operators 5. Initialization of constants, 6. Dynamic Dispatch 7. Templates especially when the compiler uses code sharing 8. Implicit type conversion It should be noted that the above constructs add complexity in addition to the usual userselectable optimizations performed by the compiler. In order to enforce the careful use and analysis of the above OO features it might be necessary to add objectives that require analysis to 10 verify the object code traceability of the above OO constructs. The above features will have a safety impact on software levels C through A. For OO software it will be wise to require source code to object code traceability for Level A through C. This issue will warrant addition of objectives to the Supplement. Clarifications could be provided on how to perform the analysis in order to comply with these new objectives. 11 5 Handling of the Issue List Defined in the OOTiA Handbook Volume 2 In the table below recommendations are given for each of the issues from OOTiA Handbook Volume 2 Issue List (IL). There are references to relevant sections in this paper for more detailed clarification. Below are the Recommendations that are referenced in the third column of the Table. R1.Additional objectives/guidance required for Reviews and Analysis of Dead and Deactivated Code should be provided. Refer to section 3.3 of this paper. R2.Additional objectives/guidance required for structural coverage analysis of OO should be provided. Refer to Section 4.3 of this paper. Another Information paper is also being produced by SG-5, which deals with Structural Coverage of OO software. R3.Additional objectives/ guidance for definition of development and verification constraints when using Complex OO constructs and features should be provided. Clarifications could also be provided using the some of the related guidelines from the OOTiA handbook. Refer to Section 3.1 of this paper. Refer to Section 4.5 of this paper for verification of Inheritance hierarchies and handling of multiple inheritance. R4.Additional objectives /guidance to enforce source to object code analysis for certain OO constructs should be provided. Should enforce confirmation of source to object code traceability for software levels C through A. Clarifications could also be provided on doing this traceability. Refer to Section 4.6 of this paper. Notes: When the third column says "No additional guidance", it implies that current DO-178B objectives/guidance and clarifications in DO-248B would be sufficient to handle the issue. For some issues there is a reference to a chapter in this paper that describes why no additional guidance or clarification is required. IL # Issue Statement Reference in OOTiA HandBook Recommendations 1 2 3 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.) Flow Analysis, recommended for Levels A-C, is complicated by Dynamic Dispatch (just which method in the inheritance hierarchy is going to be called?). Timing Analysis, recommended for Levels A-D is complicated by Dynamic Dispatch (just how much time will be expended determining which method to call?). 2.3.2.4.2 libraries & frameworks 2.3.3.1.1 flow analysis 2.3.3.1.3 timing and stack analysis 5 No additional guidance/ clarifications. Refer to Sec 3.2 of this paper. Addressed by another information paper from SG-5. Take actions as per recommendation 12 4 5 6 7 8 9 Requirements Testing, recommended for Levels A-D, and Structural Coverage Analysis, recommended for 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?) [Also, inheritance and overriding raise concern with respect to testing (e.g., it is unclear whether superclass tests and test results for inherited and overridden functions may be reused). [3]] 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?). [A closely related issue is that inheritance and polymorphism may cause difficulty in obtaining structural coverage (both modified condition/decision coverage (MC/DC) and decision coverage) [3]] Conformance to the guidelines in DO-178B concerning traceability from source code to object code for Level A software is complicated by Dynamic Dispatch (how is a dynamically dispatched call represented in the object code?). [inheritance and polymorphism may make source to object code correspondence difficult [3]] Polymorphic, dynamically bound messages can result in code that is error prone and hard to understand. 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. Dynamic dispatch complicates flow analysis, symbolic analysis, and structural coverage analysis. 2.3.3.2.2 test case reuse 5 and 5 2.3.3.1.2 structural coverage analysis 5 and 5 2.3.3.1.4 source to object trace 5 2.3.2.2.1 unclear intent 2.3.3.1.4 source to object trace 2.3.3.1.1 flow analysis, 2.3.3.1.2 structural coverage analysis 2.3.2.2.1 unclear intent 2.3.3.1.2 structural coverage analysis 2.3.3.1.4 source to object trace 2.3.3.4.2 complexity 2.3.3.2.2 test case reuse 5 5 5 10 11 Inheritance, polymorphism, and linkage can lead to ambiguity. The use of inheritance and polymorphism may cause difficulties in obtaining structural coverage, particularly decision coverage and MC/DC Source to object code correspondence will vary between compilers for inheritance and polymorphism. Polymorphic and overloaded functions may make tracing and verifying the code difficult. Requirements Testing, recommended for Levels A-D, and Structural Coverage Analysis, recommended for 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 exactly the same issue as IL 4)] 5 5 and 5 12 13 14* 5 5 5 and 5 13 15 16 17 18 19 20 21 22 23 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?) 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. Use of inheritance (either single or multiple) raises issues of compatibility between classes and subclasses. 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?" Inheritance can introduce problems related to initialization. "Deep class hierarchies [in 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. "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 isEqual necessary implementation". subclass "A subclass [may be] incorrectly located in a hierarchy. For example, a developer locates 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 foursided polygons. The corresponding design solution is a superclass FourSidedWindow, of which RectangularWindow and SquareWindow are subclasses." "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." "A subclass computes values that are not consistent with the superclass invariant or superclass state invariants." 2.3.2.2.1 unclear intent 5 2.3.3.1.1 flow analysis 5 and Refer to Sec 3.2 of this paper. 2.3.2.1.1 type substitutability 2.3.3.2.2 test case reuse 5 5 2.3.2.3.2 initialization 5 2.3.2.2.2 overriding 5 2.3.2.2.1 unclear intent 5 2.3.2.1.1 type substitutability 5 2.3.2.1.1 type substitutability 5 14 24 "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" The ability of a subclass to directly reference inherited attributes tightly couples the definitions of the two classes. [Even when attributes are hidden from client classes, they may not be hidden from subclasses. [3]] Inheritance can be abused by using it as a "kind of codesharing macro to support hacks without regard to the resulting semantics". [Inheritance can be misused to support code sharing without consideration of substitutability and the rules for behavioral subtyping (i.e., substitutability) [3] [26]] 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. When a subinterface inherits different definitions of the same operation [as a result of redefinition along separate paths], it may be unclear whether/how they should be combined in the resulting subinterface. Use of multiple inheritance can lead to "name clashes" when more than one parent independently defines an operation with the same signature. 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. 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++). 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. [This is a concern with respect to both overriding of methods and attributes [26]] Multiple inheritance complicates the class hierarchy Multiple inheritance complicates configuration control 2.3.2.2.1 unclear intent 5 25 2.3.2.2.1 unclear intent 5 26 5 27 2.3.2.2.1 unclear intent 5 28 2.3.2.2.1 unclear intent 5 29 2.3.2.2.1 unclear intent 2.3.2.2.1 unclear intent 5 30 5 31 32 2.3.2.2.2 overriding 2.3.2.2.2 overriding 5 5 33 34 35 36* 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. Source to object code correspondence will vary between compilers for inheritance and polymorphism. [Note: this is exactly the same issue as IL 12] 2.3.2.2.1 unclear intent 2.3.3.3.2 configuration control 2.3.3.4.2 complexity 2.3.3.1.4 source to object trace 5 5 5 5 15 37 38 39* 40 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. Multiple inheritance should be avoided in safety critical, certified systems. "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" [Note: this is exactly the same issue as IL 24] Reliance on programmer specified optimizations of the inheritance hierarchy (invasive inheritance) is potentially error prone and unsuitable for safety critical applications 2.3.2.2.1 unclear intent 5 2.3.1.3 restrictions 2.3.2.2.1 unclear intent 5 5 5 41* Inheritance, polymorphism, and linkage can lead to ambiguity. [Note: this is exactly the same issue as IL 10] 2.3.2.2.1 unclear intent 5 42 43 Inheritance allows different objects to be treated in the same general way. 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? 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. 2.3.2.1.1 type substitutability 5 2.3.3.1.1 flow No additional guidance or clarifications. Refer to Sec 3.2 of this handbook. 16 44 45 46 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 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. Structural Coverage Analysis, recommended for levels AC, is complicated by Inlining (just what is the "logical" coverage of the 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. 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. Inlining may affect tool usage and make structural coverage more difficult for levels A, B, and C. 2.3.3.1.3 timing and stack analysis 5. Another paper from SG-5 will also address this issue 2.3.3.1.2 structural coverage analysis 5 2.3.3.1.4 source to object trace 5 47 2.3.3.1.2 structural coverage analysis 5 48 The unrestricted use of certain object-oriented features may impact our ability to meet the structural coverage criteria of DO-178B. Statement coverage when polymorphism, encapsulation or inheritance is used. Templates are instantiated by substituting a specific type argument for each formal type parameter defined in the template class or operation. Passing a test suit for some but not all instantiations cannot guarantee that an untested instantiation is bug free. Nested templates, child packages (Ada), and friend classes (C++) can result in complex code and hard to read error messages on many compilers. 49 50 2.3.3.1.2 structural coverage analysis 2.3.3.1.2 structural coverage analysis 2.3.3.1.3 timing and stack analysis 2.3.2.2.1 unclear intent 5 and 5. 5 5 51 5 52 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 2.3.3.1.2 structural coverage analysis 5 and 5 17 "code sharing" approach. 53 Macro-expansion can result in memory and timing issues, similar to those identified for inlining. 2.3.3.1.3 timing and stack analysis Addressed by another paper from SG-5. 54 55 56 57 58 59 60 61 The use of templates can result in code bloat. Many C++ compilers cause object code to be repeated for each instance of a template of the same type. 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. How can we meet the control and data flow analysis requirements of DO-178B with respect to dynamic dispatch? 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? How can we enforce the rules that restrict the use of specific OO features? 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. Overloading can be confusing and contribute to human error when it 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. Loss of traceability due to the translation of functional requirements to an object-oriented design. Functional coverage of the low level requirement 5 2.3.3.1.2 structural coverage analysis 5 2.3.3.1.1 flow analysis 2.3.2.4.2 libraries & frameworks No additional guidance or clarifications. Refer to Sec 3.2 of this paper. 5 2.3.1.3 restrictions 2.3.3.1.4 source to object trace 5 5 2.3.2.2.2 overriding 5 2.3.3.4.1 function vs. object tracing 2.3.3.2.1 requirements testing 62 No additional guidance or clarifications required. Refer to Sec 3.4 of this paper. No additional guidance required. Refer to Sec 3.4 of this paper. 18 63 64 Philosophy of Functional Software Engineering - Most of the training, tools and principles associated with software engineering and assurance, including those of RTCA DO178B, 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. Software/software integration testing is often avoided. The position defended by the industry is that the high level of interaction between a great number of objects could lead to a combinative explosion of test cases. 2.3.1.2 requirements methods and notations Not Applicable. 2.3.3.2.1 requirements testing 65 66 67 Could there be security concerns related to the use of COTS based OOT solutions? Particularly with respect to field loadable software, security risks have been mitigated by the unique architectures of most current systems. Use of dynamic memory allocation/deallocation and use of exception handling were raised as issues by Leanna Rierson in her paper "Object-Oriented Technology (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. Most OO languages use reference semantics for passing objects (e.g. Java only supports reference 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. Similar problem could exist in non OO software, Integration testing is required. 5 should enforce careful use and verification of complex OO constructs. Not Applicable 2.3.2.3.1 indeterminate execution profiles No additional guidance required. 5 19 68 The selection of the code to implement an operation may depend upon more than just the run time type of the target object. In 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. 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. The difference between dead and deactivated code is not always clear when using OOT. Without good traceability, identifying dead vs. deactivated code may be difficult or impossible. When a design contains abstract base classes, portions of the implementations of these classes may be overridden in more specialized subclasses, resulting deactivated code. Traceability is made more difficult because there is often a lack of OO methods or tools for the full software lifecycle. 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, 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. Change impact analysis may be difficult or impossible due to difficulty in tracing functional requirements through implementation. 2.3.3.4.1 function vs. object tracing 5 69 5 70 71 72 73 2.3.2.4.1 identifying dead and deactivated code 2.3.2.4.1 identifying dead and deactivated code 2.3.3.4.3 tracing through OO views 2.3.1.2 requirements methods and notations 5 5 No additional guidance. Refer to Sec 3.4 of this paper. No additional guidance. Refer to sections 2.1 and 3.4 of this paper. 74 2.3.3.3.2 configuration control No additional guidance. Refer to Sec 3.4 of this paper. 20 75 76 77 Limitations of UML may limit how non-functional and cross-cutting requirements of realtime, safety critical, distributed, fault-tolerant, embedded systems are captured in UML and traced to the design, implementation, and test cases. 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. What is "low level requirements" for OO? Affects how we do low-level testing. If we don't know what low-level requirements 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. 2.3.1.2 requirements methods and notations 2.3.3.3.1 configuration identification 2.3.1.1 defining life cycle data No additional guidance. Refer to sections 2.1 and 3.4 of this paper. No additional guidance. Refer to sections 2.1 and 3.4 of this paper. No additional guidance. Refer to sections 2.1 and 3.4 of this paper. 78 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. Not really unique for OO. Will be addressed when we do the artifact mapping. Difficult to identify individual atomic requirements in OO. UML tends to group requirements in a graphical format. Would complicate matters if considered derived. For derived requirements, the entire graph would be passed to the safety folk for evaluation of safety impact. Lower levels of decomposition may not be possible for some requirements (e.g., performance requirements). Levels of abstraction may be different than traditional. 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 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? 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? Typically part of the tool selection process. Concern seems to be addressed by handbook mod. 2.3.1.2 requirements methods and notations 2.3.1.2 requirements methods and 2.3.1.2 requirements methods and notations 2.3.3.1.4 source to object trace No additional guidance. Refer to sections 2.1 and 3.4 of this paper. 79 No additional guidance. Refer to section 2.1 of this paper. Not applicable 80 81 For the first part of the question Refer to 5. For the second part refer to sections 2.1 and 4.4 of this paper. 82 2.3.4.3 tool qualification Not applicable to SG-5. Not OO specific. 21 83 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. Already covered by DO-178B. Not necessarily OOspecific, but may be more prevalent with OO tools. Need to be addressed in some other document or forum. 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 more dependent on tools, but not necessarily an OOspecific issue. 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. 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, CM tools, refactoring tools (tool to restructure source code to meet new requirements), How does OO life cycle data map to the DO-178B section 11 life cycle data? E.g., What "source code" mean in OO? What is req, design, 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. Configuration management and incremental development of OO projects and tools. When CM comes into play during the development 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. Is dynamic dispatch compatible with DO-178B required forms of static analysis? Mention that dynamic dispatch hinders some forms of static analysis including (see DO178B 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. 2.3.4.3 tool qualification Not applicable to SG-5. Not OO specific 84 2.3.4.2 tool environments Not applicable to SG-5. Not OO specific 85 2.3.4.2 tool environments Not applicable to SG-5. Not OO specific 86 2.3.4.2 tool environments Not applicable. 87 2.3.1.1 defining life cycle data No additional guidance or clarification. Refer to Sec 2.1 of this paper. 88 2.3.3.3.2 configuration control Not applicable to SG-5. Not OO specific 89 2.3.3.1.1 flow analysis Not an issue. For this particular problem, static analysis can be done after taking into consideration the different scenarios that may occur as a result of dynamic dispatch. 5 should also constrain and completely define the usage of dynamic dispatch in the design. 22 90 Fundamental pre-requisite language issues need clarification prior to adopting LSP and 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. Inconsistent Type Use (ITU): When a descendant class does not 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. 5 State Definition Anomaly (SDA): 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. 6 State Definition Inconsistency (SDIH): If an indiscriminately-named local state variable is introduced, a data flow anomaly can result. State Defined Incorrectly (SDI): 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. 7 Indirect Inconsistent State Definition (IISD): When a descendent adds an extension method that defines an inherited state variable, an inconsistent state definition can occur. 8 Anomalous construction behavior (ACB1): 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 (ACB2): 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. 10 Incomplete construction (IC): If the constructor does not 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. 11 State Visibility Anomaly (SVA): 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. 12 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. 2.3.2.1.1 type substitutability 5 91 2.3.2.1.2 inconsistent type use 5 92 2.3.2.2.2 overriding 5 93 2.3.2.2.2 overriding 2.3.2.2.2 overriding 5 94 5 95 2.3.2.1.1 type substitutability 5 96 2.3.2.2.2 overriding 5 97 2.3.2.2.2 overriding 5 98 2.3.2.3.2 initialization 5 99 2.3.2.2.2 overriding 5 100 2.3.4.3 tool qualification No additional guidance. Refer to Sec 2.1 of this paper. 23 101 102 103 104 105 106 107 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. 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. 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. 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. 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. 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. If polymorphism and dynamic binding are implemented, this can cause the stack size to grow, making it difficult to analyze the optimal stack size. 2.3.4.1 tool capability No additional guidance. Refer to 4.4 of this paper. 2.3.4.1 tool capability No additional guidance. Refer to 4.4 of this paper. 2.3.4.1 tool capability 5 2.3.3.4.2 complexity 5 2.3.3.4.4 iterative development No additional guidance current DO-178B objectives would be sufficient. 2.3.2.4.1 identifying dead and deactivated code 2.3.3.1.3 timing and stack analysis 5 and 5 Addressed by another paper from SG-5 24 6 Future of OOTiA Handbook and Handling of OO Software in DO-178C The four volumes of the OOTiA handbook are an excellent resource on safety critical Object oriented software development. They not only point out the potential pitfalls in OO design but also provide valuable guidelines on how to handle these problem areas. There are issues raised in the handbook, which are not just OO software specific but apply to all software. A number of these issues are already dealt with by existing objectives in DO-178B. The OO handbook is extensive in its treatment and can be viewed more as a "Best Practices" handbook, which is in fact the title of Volume 3 of the OOTiA. The format and content of the handbook does not adhere to the objectives based approach of DO-178B. An objectives based approach gives flexibility to the certification applicant when implementing the means to comply with those objectives. Often organizations can use their own software life-cycle and design/coding standards and still meet the DO-178B objectives by tailoring their processes and process outputs to comply with DO-178B. It has been shown in this paper that certain OO features and issues warrant the addition of specific objectives in order to guarantee their enforcement. Hence it would be prudent to use the handbook only as a reference but not as the means of compliance. This paper has provided justification for the addition of OO specific objectives as well as OO specific clarifications. It has been shown that some of the guidelines especially from Volume 3 of the OOTiA handbook could be used to provide these clarifications. While every attempt should be made to ensure that the new objectives added are unambiguous, the clarifications could still provide guidelines on how some of the objectives could be satisfied. This is indeed the intent of some of the Discussion papers and FAQs in DO-248B. In order to maintain the technology independence of DO-178C it would be best to add the OO specific objectives to a separate Supplement. 7 Conclusion This paper addressed the OOT issues raised by the OOTiA handbook and other referenced research papers. The paper provided a resolution for each of the issues. It has been shown that the OOTiA handbook could only be used as a reference and not as a guidance material. Some of the issues raised by the handbook warrant the addition of objectives. Some might require more clarification and detailed guidelines in a separate clarifications document like the DO-248C. These clarifications could also be provided as an Annex to the OO Supplement. The material for some of these clarifications could come from Volume 3 of the handbook. 25 8 References [1] RTCA, Inc. Software Considerations in Airborne Systems and Equipment Certification. RTCA/DO-178B, December 1992. [2] RTCA, Inc. Final Report for Clarification of DO-178B "Software Considerations in Airborne Systems and Equipment Certification." RTCA/DO-248B, 12 October 2001 [3] Handbook for Object Oriented Technology in Aviation, Volume 1, Rev 0, Oct 26 2004. [4] Handbook for Object Oriented Technology in Aviation, Volume 2, Rev 0, Oct 26 2004. [5] Handbook for Object Oriented Technology in Aviation, Volume 3, Rev 0, Oct 26 2004. [6] Handbook for Object Oriented Technology in Aviation, Volume 4, Rev 0, Oct 26 2004. [7] Pressman, Roger. Software Engineering: A practioner;s Approach. McGraw Hill, 4th edition, 1997. [8] Eckel, Bruce. Thinking in C++. Prentice Hall, 1995. [9] US Dept of Transportations, FAA Office of Aviation Research, "Issues concerning the Structural Coverage of Object Oriented Software". DOT/FAA/AR--02/113, Nov 2002. [10] Information Processing Ltd. "Advanced Coverage Metrics for Object-Oriented Software". Oct 28 1999. [11] Rierson, Leanna. "Object-Oriented Technology (OOT) in Civil Aviation Projects: Certification Concerns." Proceedings of the 18th Digital Avionics Systems Conference, St. Louis, MO, Oct. 24-29, 1999. [12] Certification Authorities Software Team (CAST). "Guidelines for approving Source Code to Object code traceability." Position Paper CAST-12, Dec 2002. [13] Certification Authorities Software Team (CAST). "Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling." Position Paper CAST-19, Jan 2004. [14] Certification Authorities Software Team (CAST). "Automatic code generation tools development assurance." Position Paper CAST-13, June 2002. [15] Certification Authorities Software Team (CAST). "Use of the C++ programming language." Position Paper CAST-8, Jan 2002. . 26

Find millions of documents on Course Hero - Study Guides, Lecture Notes, Reference Materials, Practice Exams and more. Course Hero has millions of course specific materials providing students with the best way to expand their education.

Below is a small sample set of documents:

MN State - LECTOUT - 319
European Society in the 17th and 18th Centuries I. Peasant Life Serfdom vs. Free labor Developments in the East Developments in the West Absolutism and Peasant life The Family o Marriage, Death, and Inheritance Social status and the village II.
Penn State - STAT - 100
Stat 100 Exam 3Spring 2002Form A1. A poll is done to estimate the percent of adult Americans who like their jobs. The poll is based on a random sample of 400 individuals. Which choice is closest to the approximate margin of error of this poll?
Penn State - STAT - 250
SOLUTIONSStat 250.3 - Second Midterm ExamMonday, November 24, 2003 Part I: (100 points) Written Problems: Show ALL work, calculations and formulas used. Partial credit will be awarded for using the correct procedures. Problem 1: Suppose that the a
MN State - LECTOUT - 319
Russia Encounters the West I. Early Modern Russia Czar Nobles o The `Service Nobility' Church o The Church and Russian Intellectual Life Peasants o The Rise of Serfdom II. The Rise of the Romanovs The `Time of Troubles' (1598-1613) Michael (r.
MN State - LECTOUT - 319
The Ottoman Empire I. Background Battle of Manzikert 1071 o Seljuk Turks Osman (r. 1301-1326) Mehmet the Conqueror (r. 1451-1481) o Fall of Constantinople 1453 II. The Ottomans in the Early Modern Period Suleyman the Magnificent (r. 1520-1566) o
University of Texas - GRG - 305
GEOGRAPHY 305 This Human World: An Introduction to GeographyLesson 9Express creatively the unique character of the place in which you live. Read:Douglas Pocock's "Place and the Novelist" in Re-reading Cultural Geography. Write a song, short story,
University of Texas - STA - 309
UNIVERSITY OF TEXAS McCombs School of Business Business Honors Program STA 309H (03860, 03865), Spring 2004 Elem. Business Statistics-Honors Class Times: T/Th 11:00 & 12:30 Professor: Jay Koehler TAs: Adam Cox & Pranj Mehta Classroom: UTC 4.124, UTC
North-West Uni. - ANIMATRON - 4000
LICENSE.txtez_setup.pysetup.cfgsetup.pydocs/class-simplejson.JSONDecoder.htmldocs/class-simplejson.JSONEncoder.htmldocs/class_to_source.jsdocs/index.htmldocs/layout.cssdocs/module-index.htmldocs/module-simplejson-index.htmldocs/module-simp
North-West Uni. - TEST - 4000
layerhashnameformaturltypefingerprintchannelsfirst_framebytesdownloadedframe_sizedurationsampleratebitratesize3bf3d0b0498a5002ebd00f5fd00cdec00bec8012aa6009e5200911900a2fe003420007e3800758c0a23e202356401521f0143f8011a4100d8c100e5f100
North-West Uni. - ANIMATRON - 4000
layerhashnameformaturltypefingerprintchannelsfirst_framebytesdownloadedframe_sizedurationsampleratebitratesize3bd676b04a1240015c8016fd500d1e2009b05019bbe0113290084db001dfd0009c500703500871d07cd7c026fdc01480501716b010ea700e9fc00e96401
North-West Uni. - TEST - 4000
http:/www.jhentschel.com/musicradio/original.mp3c4eec803e4b5ffda3701a3da008a0300563900f862011c7b0012e0000aceffc66600391a00a75b0d71150183ef00cf2f014e5400bfa100a53c00d21700b79600935d008ee60089830080ee007545c716cc04093e0074c6017e660118280072cd009bfa008
North-West Uni. - ANIMATRON - 4000
http:/www.jhentschel.com/musicradio/original.mp3http:/www.jhentschel.com/musicradio/test96.mp3http:/www.jhentschel.com/musicradio/test128.mp3http:/www.jhentschel.com/musicradio/test160.mp3http:/www.jhentschel.com/musicradio/test192.mp3http:/www.
North-West Uni. - TEST - 4000
layerhashnameformaturltypefingerprintchannelsfirst_framebytesdownloadedframe_sizedurationsampleratebitratesize3c2eea00547980162ea016895004dc60080ee006c36ffdbf8ffe757005858004c59004e0d00201319e55902c4bb0110b700fde800c8a700de3200a36f00
North-West Uni. - TEST - 4000
layerhashnameformaturltypefingerprintchannelsfirst_framebytesdownloadedframe_sizedurationsampleratebitratesize3c4eec803e4b5ffda3701a3da008a0300563900f862011c7b0012e0000aceffc66600391a00a75b0d71150183ef00cf2f014e5400bfa100a53c00d21700
North-West Uni. - ANIMATRON - 4000
01234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586
UC Davis - CS - 188
Wired magazine, Issue 8.04, April 2000.Why the future doesn't need us.Our most powerful 21st-century technologies-robotics, genetic engineering, and nanotech-are threatening to make humans an endangered species. By Bill Joy From the moment I becam
UC Davis - ECI - 155
ECI 155, Spring 2006 Assignment #3Assignment 3 Urban Water Management Plan DUE: May 18, 2006Introduction In this assignment you will select, read, summarize, and critically review an existing urban water management plan for a water utility. Use th
Rutgers - IOOS - 020209
Regional Associations (RAs) Building IOOS Partnerships 480 and Growing. Business and Industry (66) Shipping (18) Researchers and Universities (149) State agencies (59) NGOs (58) International Organizations (11) Local and Tribal Governments (8)
Penn State - TRDEV - 533
Distance EducationOvercoming the Fears & Frustrations of Learners @ a DistanceCommon Goalss Increase the learner's comfort level s Enhance communication s Enhance interaction s Enhance the learning processTo Increase Comforts Use "Ice Breakers
Rutgers - MS - 200
PLATE TECTONICS AND CLIMATEObjectives 1. Define plate tectonics and describe the mechanics which drive it, including the dynamics of plate margins 2. Understand the features of oceanic plate tectonics, and how they control seafloor features and
Rutgers - MS - 451
Equatorial currents Typically, the north-south component of the wind, , and its variation with y longitude, x , are negligible compared to the zonal winds. In fact, the very large x-scale compared to y-scale means that x-variations are generally ne
University of Texas - GF - 283
2. S -> NPnom 3sg VP3sg S -> NPnom non3sg VPnon3sg VP3sg -> walks VP3sg -> V3sg NPacc VPnon3sg -> walk VPnon3sg -> Vnon3sg NPacc V3sg -> sees, knows Vnon3sg -> see, know NPnom 3sg -> Det N3sg NPnom 3sg -> PNnom 3sg NPnom non3sg -> Det Nnon3sg NPnom n
UC Davis - SSC - 118
Table 7.-Land Capability Classification-California Land capability is a system of grouping soils primarily on the basis of their capability to produce common cultivated cro
University of Texas - MIS - 374
Exercise 10 In-class Client Project Team work1. Stakeholders list add an asterisk for system users 2. Summary Level use case diagram (e.g. p. 349 for ASTA) 3. Use case script for one use case (e.g. p. 346-348 for ASTA orUC-10 Browse on p. 5 of h
UC Davis - STATS - 108
Some useful information for MIDTERM II.MIDTERM I (in-class part): Wednesday, March 4.1) The midterm exam will be closed book and closed notes. However you may bring two2)3)4)5)sheets (letter size, both sides) with formulas etc. on them. Ple
UC Davis - STATS - 108
64.0 4.0 2.0 73.0 4.0 4.0 61.0 4.0 2.0 76.0 4.0 4.0 72.0 6.0 2.0 80.0 6.0 4.0 71.0 6.0 2.0 83.0 6.0 4.0 83.0 8.0 2.0 89.0 8.0 4.0 86.0 8.0 2.0 93.0
UC Davis - ECS - 110
-789 -10019 -67968 793-477 99531 -963-715 -725829 -45488 -60-883 252-158 -333-42 -386708 -60-834 -459-525 -964-568 394-531 -333-96 501-501 484-242 45-441 -735105 -133-948 -601437 -349362 65927 715755 -139-694 -72824 -10174
Penn State - BPM - 408
Brandon Montemruo Engr 408 December 10, 2007 3 Questions 1) Bono talks about how he did not get much of an education and then he comments on now he is getting an honorary doctorate in Law. He talks about how all his knowledge of the law is about how
Penn State - MKTG - 471
Chapter 1STRATEGIC PLANNING AND THE MARKETING MANAGEMENT PROCESS05/14/09IntroductionMarketing combines economics, psychology, anthropology, sociology, statistics and demographic. s Identifies and provides tools to satisfy need and wants. s It i
University of Texas - CS - 395
Ray TracingTodays s sBasic algorithms Overview of pbrt Ray-surface intersection for single surface Acceleration techniques for ray tracing large numbers of geometric primitivesNext lecturesCS348B Lecture 2Pat Hanrahan, Spring 2005Classic
University of Texas - CS - 327
Chapter 10Fact-finding Techniques Transparencies Pearson Education Limited 1995, 20051Chapter 10 - ObjectivesxWhen fact-finding techniques are used in the database application lifecycle. The types of facts collected in each stage of the dat
University of Texas - CS - 313
Lecture Notes on 25 Feb 2009* Exception Handling* Throwing and Catchingpublic class SomeClass{ public int div (int a, int b) throws ArithmeticException { if ( b = 0 ) throw new ArithmeticException ( "ERROR: Division by Zero" );
UC Davis - DK - 1622
ATF1.02743 "Type=GenePix Results 1.4""DateTime=2005/03/01 16:49:10""Settings=C:\Documents and Settings\Mitch\Desktop\MicroArray Projects\DK1622 vs. pool\0.5hr\myxoE181 settings.gps""GalFile=C:\Documents and Settings\Mitch\Desktop\GODlist an
Penn State - AJK - 5128
Geography 160 Project 3 Using Map Data and Integrating it into GISBy Jerrica, Daniel, and AaronProject 3 OverviewFind, download, and view map data of an area of interest (your hometown) Make 3 map data sets and one map overlay with comment
UC Davis - ECS - 236
ECS-236, Winter 2006, Assignment #1 Due date: 11:59 p.m., January 31, 2006 Total 30% (2% penalty if turned in before the end of February 3rd, 6% penalty by the end of February 6, and 1% per day after that) Starter for SNORT In this homework assignmen
University of Texas - EE - 319
Introduction to Embedded Microcomputer SystemsLecture 19.1ICC12 first input parameter in RegD rest of the input parameters on the stack stack frame using RegX return parameter in RegD GCC12 first input parameter in RegD rest of the input paramete
MN State - ECON - 100
PART ONEIntroductionChapter 1: Limits, Alternatives, and ChoicesCopyright 2007 by The McGrawHill Companies, Inc. All rights reserved.Limits, Alternatives and ChoicesEconomics is about wants and means. Society has the resources to make goods
MN State - ECON - 411
Reexamining the Distribution of Wealth in 1870Joshua L. Rosenbloom University of Kansas and NBERGregory W. Stutes Minnesota State University MoorheadLast Revised: September 2005ABSTRACT This paper uses data on real and personal property owner
University of Texas - CS - 352
Lecture 12: ILPqLast Time: Reducing impact of data hazards Control HazardsqToday Executing instructions in parallel Static scheduling Multiple issueCS352Lecture 12 2/25/991MIPS R10000CS352Lecture 12 2/25/992Can CPI be < 1
Penn State - PHYS - 203
Physics 214 3: Interference, Diffraction and PolarizationYoung's Double-Slit Experiment Intensity Distribution of the Double-Slit Interference Pattern Interference in Thin Films Single Slit Diffraction Diffraction Grating Diffraction by Crystals Pol
North-West Uni. - EARTH - 202
\" Use: groff -U -ms -ep file.txt > out.ps \".LP.AM.EQdelim $gfont Rgsize +1.EN.ls 1.nr LL 6.5i.nh.ce\fB8.5 CONVECTION\fR.spBy convection we mean a motion of material due to buoyancy forces resulting from temperature differences. .PS
Stanford - CS - 121
Mehran Sahami CS121Handout #5 July 19, 2001Problem Set #2 Due: Beginning of class, Thursday, July 26th1. (15 points) Adversarial Search Problem 12.2 in Nilsson textbook, p. 213. For your answer in part 1 of this problem, you should also show wha
UC Davis - PHY - 200
Phys 200B HW8 Due Wed 04-Mar-2009 1. Problem 4.5 in Jackson 2. Determine the electric quadrupole moment of a uniformly charged ellipsoid of semi-major axis b and semi-minor axis a. 3. A charged ring of radius R may be described by: (r) = (q/2R2) (
Stanford - CS - 276
Text Information Retrieval, Mining, and ExploitationCS276ALecture 10 7 Nov 2002 Information Access in ContextInformation Access AnalyzeSynthesize HighLevel Goal Done? Userno yesStopExerciseObserve your own information seeking be
LSU - PHYS - 3000
TeraGrid: A Terascale Distributed Discovery EnvironmentJay BoisseauTeraGrid Executive Steering Committee (ESC) Member and Director, Texas Advanced Computing Center at The University of Texas at AustinJay Boisseau boisseau@tacc.utexas.edu1Outl
Penn State - ASTRO - 130
KERR BLACK HOLES (Roy Kerr 1963) Generalized BH description includes spin Later researchers use it to predict new effects! Two crucial surfaces inner surface = horizon: smaller than nonrot. hole of same mass outer surface = "static limit" "Ker
Penn State - FJB - 138
Request For A New ApplicationDate Submitted: November 1, 2007 Submitted by: Francesca Bordonaro Purpose: The Personnel department often is asked to do a quick computation of a customer's state tax. Employees would save time and provide more accurate
Stanford - POLISCI - 120
DEMOCRATS & SOUTHERN DEMOCRATS IN THE HOUSEDem Seats 1940 44 48 52 56 60 64 68 72 76 80 92 96 2000 * minority Source: Polsby 268 242 263 211* 233 263 295 243 239 292 259 258 207* 211*Southern Dem 100 102 103 103 100 102 95 84 79 78 77 77 56Dixi
University of Texas - CS - 341
CS 341 Homework 10 State Minimization1. (a) Give the equivalence classes under L for these languages: (i) L = (aab ab)* (ii) L = {x : x contains an occurrence of aababa} (iii) L = {xxR : x {a, b}*} (iv) L = {xx : x {a, b}*} (v) Ln = {a, b}a{a, b}
Stanford - E - 163
;x_num y_num x(m) y(m) imag(A) Bhall(T) 1 1 -0.5800 -0.0500 157.8283 -0.023840 2 1 -0.5750 -0.0500 157.8169 -0.027380 3 1 -0.5700 -0.0500 157.8062 -0.031480 4 1 -0.5650 -0.
Stanford - E - 163
;x_num y_num x(m) y(m) imag(A) Bhall(T) 1 1 -0.5800 -0.0500 174.0619 -0.026200 2 1 -0.5750 -0.0500 174.0581 -0.030060 3 1 -0.5700 -0.0500 174.0543 -0.034600 4 1 -0.5650 -0.
LSU - BIOL - 1023
Homework Assignment IV BIOL2153 Principles of Genetics (Sections 9 & 10) Due at the beginning of your Discussion Section on Monday, October 27, 2003 Problem 1 (3 pts.): The Meselsohn-Stahl (M-S) experiment supported semi-conservative replication as t
Stanford - MEETING - 031203
From any TSFX's own perspective: Upper phi boundary send 7 bits 1/SL wire-3 to higher phi TSF receive 21 bist 3/SL wire-0,1,2 from higher phi TSF Lower phi boundary send 21 bits 3/SL wire-3,5,6 to lower p
Acton School of Business - GW - 4314
Chapter 9: hash functionSlides by Daniele MazzocchiDefinitionunrestricted notion of hash function h(x)compression (e.g., h(x) fixed bit length) ease of computationkeyed and unkeyedClassificationMDC (manipulation detection codes) or
Penn State - WEBCONFERE - 1710
<!DOCTYPE html PUBLIC "-/W3C/DTD XHTML 1.0 Strict/EN" "http:/www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http:/www.w3.org/1999/xhtml"> <head> <title> Changeset 1710 for weblion/webConference2007/RobsWebConfNo
Stanford - CS - 242
CS 242Scope, Function Calls and Storage ManagementJohn MitchellAnnouncementsx Homework late policy Three late days: You may turn in your homework by 5PM Thursday three times in the quarter Fri 10/14: Section 5:10 6:05 Wed 10/19: Secti
Stanford - ACTG - 364
PtIDAliasExactDateUnknownDrugOrderUnknownStartDateStopDateAPVIDVLPVNFVRTVSQVATVAZTDDIDDCD4T3TCABCADVTDFNVPDLVEFVUnknownPIRTINRTINNRTI22277ACTG364_1NoNo-283-910000000110000000000000022277ACTG3
University of Texas - ASE - 463
CanSatFinal ReviewMay 3, 2002The Department of Aerospace Engineering and Engineering Mechanics The University of Texas at Austin Austin, Texas 78712Team CanSat ASE 463Q University of Texas at Austin May 3, 2002 Dear Dr. Stearman, The following
University of Texas - EH - 2489
Example Use Cases for Environmental FlowsEric S. Hersh, UT-CRWR, 9/15 /08The following are some example use cases: situations from the perspective of a user (scientist, researcher, stakeholder, general public, etc) making a query on the Hydrologic
University of Texas - ERC - 398
Starfishing I came across the saddest thing the other day, walking along through the park. Usually, I'm not much of an outdoor person, but it was such a glorious day out that only an agoraphobe would remain indoors. Everything was lush and green, the
IUPUI - M - 119
Classroom # _ Grade _ M119 Homework Set No:_ Due Date:_ID (last 4 digits)Last Name (print) First NameNumber of Unsolved Problems** You must show the detailed work for each problem. If you just copied the answer from the book, the problem is coun