Source Code as the Key Artifact in Requirement-Based Development: The Case of Ada 2012

  • José F. Ruiz
  • Cyrille Comar
  • Yannick Moy
Part of the Lecture Notes in Computer Science book series (LNCS, volume 7308)


Developing high-integrity software requires the production of many interrelated collections of artifacts which must be kept up-to-date and in synchrony; traceability in particular must be captured to ensure coherence across the various development and verification phases.

This paper proposes a new approach to the development of high-integrity systems, in which various artifacts (low-level requirements, modules, relationships among modules, test case obligations, etc.) are represented directly in the source code.

Package specs in general, and Ada 2012 aspects in particular, are very well suited for expressing some of these artifacts, facilitating reuse and maintainability, and obtaining traceability automatically. Review activities are made more effective and efficient because the context of the reviewed artifact is in full view, and when something is modified it is easy to know which other artifacts need to be re-verified.

The software architecture derived from the design activity consists in the definition of software components, their interfaces and their relationships. All those elements are well represented by Ada package specs and the “with” clauses between packages. Low-level requirements, which define the detailed functionality, can in part be formally expressed through Ada 2012 contracts. Test cases associated with low-level requirements can then be described using Test_Case aspects. Test procedure skeletons can be automatically generated from the test cases.


Source Code Software Architecture Call Graph Package Body Traceability Information 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
  2. 2.
    ARINC: ARINC Specification 653, Avionics Application Software Standard Interface. Aeronautical Radio, Inc. (2005)Google Scholar
  3. 3.
    Barnes, J.: High Integrity Software. In: The SPARK Approach to Safety and Security. Addison Wesley (2003)Google Scholar
  4. 4.
    Comar, C., Kanig, J., Moy, Y.: Integrating formal program verification with testing. In: Proceedings of the Embedded Real Time Software and Systems Conference, ERTS2 2012 (February 2012)Google Scholar
  5. 5.
    Delmas, D., Cuoq, P., Lamiel, V.M., Duprat, S.: Fan-C, a Frama-C plug-in for data flow verification. In: Proceedings of the Embedded Real Time Software and Systems Conference, ERTS2 2012 (February 2012)Google Scholar
  6. 6.
    Hall, A., Chapman, R.: Correctness by construction: Developing a commercial secure system. IEEE Software 19(1), 18–25 (2002)CrossRefGoogle Scholar
  7. 7.
  8. 8.
    Martin, R.C.: Agile Software Development: Principles, Patterns, and Practices. Prentice Hall (2003)Google Scholar
  9. 9.
    Meyer, B.: Object-Oriented Software Construction, 1st edn. Prentice-Hall, Inc., Upper Saddle River (1988)Google Scholar
  10. 10.
    RTCA SC-167/EUROCAE WG-12: DO-178B – Software Considerations in Airborne Systems and Equipment Certification (December 1992)Google Scholar
  11. 11.
    RTCA SC-205/EUROCAE WG-71: DO-178C – Software Considerations in Airborne Systems and Equipment Certification, Draft IP 50 (2011)Google Scholar
  12. 12.
    Souyris, J., Wiels, V., Delmas, D., Delseny, H.: Formal Verification of Avionics Software Products. In: Cavalcanti, A., Dams, D.R. (eds.) FM 2009. LNCS, vol. 5850, pp. 532–546. Springer, Heidelberg (2009), CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2012

Authors and Affiliations

  • José F. Ruiz
    • 1
  • Cyrille Comar
    • 1
  • Yannick Moy
    • 1
  1. 1.AdaCoreParisFrance

Personalised recommendations