Including non-functional issues in Anna/Ada programs for automatic implementation selection

  • Xavier Franch
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 1251)

Abstract

We present an enrichment of the Anna specification language for Ada aimed at dealing not only with functional specification of packages but also with non-functional information about them. By non-functional information we mean information about efficiency, reliability and, in general, any software attribute measuring somehow the quality of software (perhaps in a subjective manner). We divide this information into three kinds: definition of non-functional properties, statement of non-functional behaviour and statement of non-functional requirements; like Anna annotations, all of this information appears in Ada packages and package bodies and their syntax is close to Ada constructs. Non-functional information may be considered not only as valuable comments, but also as an input for an algorithm capable of selecting the “best” package body for every package definition in a program, the “best” meaning the one that fits the set of non-functional requirements of the package in the program.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. [Ada83]
    U.S. Departament of Defense. Reference Manual for the Ada Programming Language. American National Standards Institute/MIL-STD-1815A-1983, 1983.Google Scholar
  2. [Bra85]
    G. Brassard. “Crusade for a Better Notation”. SIGACT News, 16(4), 1985.Google Scholar
  3. [CGN94]
    D. Cohen, N. Goldman, K. Narayanaswamy. “Adding Performance Information to ADT Interfaces”. In Procs. of Interface Definition Languages Workshop, SIGPLAN Notices 29(8), 1994.Google Scholar
  4. [CZ90]
    S. Cárdenas, M.V. Zelkowitz. “Evaluation Criteria for Functional Specifications”. In Proceedings of 12th ICSE, Nice (France), 1990.Google Scholar
  5. [FB96]
    X. Franch, X. Burgués. “Supporting Incremental Component Programming with Functional and Non-Functional Information”. In Proceedings of XVI Computer Science Chilean Conference (SCCC), Valdivia (Chile), 1996.Google Scholar
  6. [FB97]
    X. Franch, P. Botella. “Supporting Software Maintenance with Non-Functional Information”. In Proceedings of 1st Euromicro Conference on Software Maintencance and Reengineering, Berlin (Germany), 1997.Google Scholar
  7. [Fra94]
    X. Franch. “Combining Different Implementations of Types in a Program”. In Proceedings Joint of Modular Languages Conference, Ulm (Germany), 1994.Google Scholar
  8. [Fra96]
    X. Franch. “Automatic Implementation Selection for Software Components using a Multiparadigm Language to state Non-Functional Issues”. Ph.D. Thesis, Universität Politècnica de Catalunya (Catalonia, Spain), 1996.Google Scholar
  9. [Gut75]
    J.V. Guttag. The Specification and Application to Programming of Abstract Data Types. Ph.D. Thesis, University of Toronto, 1975.Google Scholar
  10. [Hoa72]
    C.A.R. Hoare. “Proof of Correctness of Data Representations”. In Programming Methodology, Springer-Verlag, 1972.Google Scholar
  11. [Jaz95]
    M. Jazayeri. “Component Programming — a Fresh Look at Software Components”. In Proceedings of 5th ESEC, Barcelona (Catalonia, Spain), 1995.Google Scholar
  12. [LH85]
    D.C. Luckham, F.W. von Henke. “An Overview of Anna, a Specification Language for Ada”. Software IEEE, March 1985.Google Scholar
  13. [Luc90]
    D.C. Luckham. Programming with Specifications: an Introduction to ANNA, a Language for Specifying Ada Programs. Texts and Monographs in Computer Science, Springer-Verlag.Google Scholar
  14. [Kan86]
    E. Kant. “On the Efficient Synthesis of Efficient Programs”. In Readings in Artificial Intelligence and Soßware Engineering, Morgan Kaufmann, 1986.Google Scholar
  15. [Knu76]
    D.E. Knuth. “Big Omicron and Big Omega and Big Theta”. SIGACT News, 8(2), 1976.Google Scholar
  16. [LG86]
    B. Liskov, J. Guttag. Abstraction and Specification in Program Development. The MIT Press, 1986.Google Scholar
  17. [Mat84]
    Y. Matsumoto. “Some Experiences in Promoting Reusable Software”. IEEE Transactions on Software Engineering, 10(5), 1984.Google Scholar
  18. [MCN92]
    J. Mylopoulos, L. Chung, B.A. Nixon. “Representing and Using Nonfunctional Requirements: A Process-Oriented Approach”. IEEE Transactions on Software Engineering, 18(6), 1992.Google Scholar
  19. [Sc+86]
    J. Schwartz et al. Programming with Sets: Introduction to SETL. Springer-Verlag, 1986.Google Scholar
  20. [Sha84]
    M. Shaw. “Abstraction Techniques in Modern Programming Languages”. IEEE Software, 1(10), 1984.Google Scholar
  21. [Sit94]
    M. Sitaraman. “On Tight Performance Specification of Object-Oriented Components”. In Proceedings 3rd International Conference on Software Reuse, IEEE Computer Society Press, 1994.Google Scholar
  22. [Sit+94]
    M. Sitaraman (coordinator). “Special Feature: Component-Based Software Using RESOLVE”. ACM Software Engineering Notes, 19(4), Oct. 1994.Google Scholar
  23. [SY94]
    P.C-Y. Sheu, S. Yoo. “A Knowledge-Based Program Transformation System”. In Proceedings 6th CAiSE, Utrecht (The Netherlands), LNCS 811, 1994.Google Scholar
  24. [Win89]
    J.M. Wing. “Specifying Avalon Objects in Larch”. In Proceedings of TAPSOFT'89, Vol. 2, Barcelona (Catalonia, Spain), LNCS 352, 1989.Google Scholar
  25. [Win90]
    J.M. Wing. “A Specifier's Introduction to Formal Methods”. IEEE Computer 23(9), 1990.Google Scholar

Copyright information

© Springer-Verlag 1997

Authors and Affiliations

  • Xavier Franch
    • 1
  1. 1.Department Llenguatges i Sistemes InformaticsUniversität Politècnica de CatalunyaBarcelonaSpain

Personalised recommendations