http://iet.metastore.ingenta.com
1887

Abstraction classes in software design

Abstraction classes in software design

For access to this article, please select a purchase option:

Buy article PDF
£12.50
(plus tax if applicable)
Buy Knowledge Pack
10 articles for £75.00
(plus taxes if applicable)

IET members benefit from discounts to all IET publications and free access to E&T Magazine. If you are an IET member, log in to your account and the discounts will automatically be applied.

Learn more about IET membership 

Recommend to library

You must fill out fields marked with: *

Librarian details
Name:*
Email:*
Your details
Name:*
Email:*
Department:*
Why are you recommending this title?
Select reason:
 
 
 
 
 
IEE Proceedings - Software — Recommend this title to your library

Thank you

Your recommendation has been sent to your librarian.

We distinguish three abstraction strata in software design statements: (i) Strategic design statements (‘architectural design’) determine global constraints, such as programming paradigms, architectural styles, component-based software enginering standards, design principles, and law-governed regularities; (ii) Tactical design statements (‘detailed design’) determine local constraints, such as design patterns, programming idioms, and refactorings; (iii) Implementation statements determine specific properties of the implementation, such as a class diagrams and program documentation. Seeking to ground this intuition in a well-defined vocabulary, we define two criteria of distinction in mathematical logic. We present the Intension/Locality hypothesis, postulating that the spectrum of software design statements is divided into three well-defined ‘abstraction classes’ as follows: (i) the class of non-local statements (N L) contains Strategic statements; (ii) the class of local and intensional statements (L I) contains Tactical statements; and (iii) the class of local and extensional statements (L E) contains Implementation statements. We demonstrate a broad range of software design statements that corroborate our hypothesis. We conclude with a proof of the architectural mismatch theorem, according to which architectural mismatch arises from attempting to combine components that assume conflicting non-local statements.

References

    1. 1)
      • Eden, A.H.: `Strategic versus tactical design', Proc. 38th Hawaii Int. Conf. System Sciences — HICSS, 3–6 Jan. 2005, Honolulu, HI, USA.
    2. 2)
      • R.W. Sebesta . (1999) Concepts of programming languages.
    3. 3)
      • D. Garlan , M. Shaw , V. Ambriola , G. Tortora . (1993) An introduction to software architecture, Advances in software engineering and knowledge engineering.
    4. 4)
      • R. Johnson , B. Foote . Designing reusable classes. J. Object-Oriented Program. , 5 , 22 - 35
    5. 5)
      • C. Szyperski . (2003) Component software: beyond object-oriented programming.
    6. 6)
      • D. Garlan , R. Allen , J. Ockerbloom . Architectural mismatch or, why it's hard to build systems out of existing parts. IEEE Softw. , 6 , 17 - 26
    7. 7)
      • N. Minsky . Law-governed regularities in object systems. Part 1: principles. Theor. Pract. Object Syst. , 4 , 283 - 301
    8. 8)
      • E. Gamma , R. Helm , R. Johnson , J. Vlissides . (1995) Design patterns: elements of reusable object oriented software.
    9. 9)
      • M. Fowler . (1999) Refactoring: improving the design of existing code.
    10. 10)
      • F. Buschmann , R. Meunier , H. Rohnert , P. Sommerlad , M. Stal . (1996) Pattern-oriented software architecture – a system of patterns.
    11. 11)
      • D.E. Perry , A.L. Wolf . (1992) Foundation for the study of software architecture’. ACM SIGSOFT Softw. Eng. Notes.
    12. 12)
    13. 13)
      • Kazman, R.: `A new approach to designing and analyzing object-oriented software architecture', Conf. Object-Oriented Programming Systems, Languages and Applications – OOPSLA, 1–5 Nov. 1999, Denver, CO, USA.
    14. 14)
      • L. Bass , P. Clements , R. Kazman . (2003) Software architecture in practice.
    15. 15)
      • Software Engineering Institute, Carnegie Mellon University, 2002. http://www.sei.cmu.edu.
    16. 16)
      • J. Rumbaugh , I. Jacobson , G. Booch . (1998) The unified modeling language reference manual.
    17. 17)
      • T. Quatrani . (1999) Visual modelling with Rational Rose 2000 and UML, revised.
    18. 18)
      • Eden, A.H., Kazman, R.: `Architecture, design, implementation', Proc. 25th Int. Conf. Software Engineering – ICSE, 3–10 May 2003, Portland, OR, USA.
    19. 19)
      • Eden, A.H., Turner, R.: `Towards an ontology of software design: The Intension/Locality hypothesis', 3rdEuropean Conf. Computing and Philosophy – ECAP, 2–4 Jan. 2005, Västerås, Sweden.
    20. 20)
      • J. Derrick , E. Boiten . (2001) Refinement in Z and Object-Z: foundations and advanced applications.
    21. 21)
      • Eden, A.H.: `Formal specification of object-oriented design', Int. Conf. Multidisciplinary Design in Engineering CSME-MDE, 21–22 Nov. 2001, Montreal, Canada.
    22. 22)
      • M.L. Scott . (2000) Programming languages pragmatics.
    23. 23)
      • I. Craig . (2000) The interpretation of object-oriented programming languages.
    24. 24)
    25. 25)
      • Lieberherr, K.J., Holland, I., Riel, A.: `Object-oriented programming: an objective sense of style', Proc. Conf. Object-Oriented Programming Systems, Languages and Applications – OOPSLA, 25–30 Sep. 1988, San Diego, CA, p. 323–334.
    26. 26)
      • R. Monson-Haefel . (2000) Enterprise JavaBeans.
    27. 27)
      • J. van Gurp , J. Bosch . Design, implementation and evolution of object oriented frameworks: concepts and guidelines. Softw. Pract. Exp. , 3 , 277 - 300
    28. 28)
      • Hou, D., Hoover, H.J.: `Towards specifying constraints for object-oriented frameworks', Proc. 2001 Conf. Centre for Advanced Studies on Collaborative Research – CASCON, 5–8 Nov. 2001, Toronto, Canada.
    29. 29)
      • W. Pree . (1995) Design patterns for object-oriented software development.
    30. 30)
      • Helm, R., Holland, I.M., Gangopadhyay, D.: `Contracts: specifying behavioural compositions in object-oriented systems', Proc. Conf. Object-Oriented Programming Systems, Languages and Applications—OPPSLA, 21–25 Oct. 1990, Ottawa, Canada.
    31. 31)
      • B. Stroustrup . (1986) The C++ programming language.
    32. 32)
      • J. Rumbaugh , M. Blaha , W. Premerlani , F. Eddy , W. Lorenson . (1991) Object oriented modeling and design.
    33. 33)
      • (1999) Java Naming and Directory Interface.
    34. 34)
      • Eden, A.H., Hirshfeld, Y.: `Principles in formal specification of object oriented architectures', Proc. Conf. Centre for Advanced Studies on Collaborative Research–CASCON, 5–8 Nov. 2001, Toronto, Canada.
    35. 35)
      • J. Barwise . (1977) Handbook of mathematical logic.
    36. 36)
      • E.N. Zalta . (2003) Frege's logic, theorem, and foundations for arithmetic, The Stanford encyclopedia of philosophy.
    37. 37)
      • R. Turner . The foundations of specification. J. Log. Comput. , 5 , 623 - 663
    38. 38)
      • (2004) Object Management Group: Unified Modeling Language (UML), version 2.0.
    39. 39)
      • S.A. Cook , R.A. Reckhow . Time-bounded random access machines. J. Comput. Syst. Sci. , 354 - 475
    40. 40)
      • Y. Gurevich . Sequential abstract state machines capture sequential algorithms. ACM Trans. Comput. Log. , 1 , 77 - 111
    41. 41)
      • M. Abadi , L. Cardelli . (1996) A theory of objects.
    42. 42)
      • C.A.R. Hoare . (1985) Communicating sequential processes.
http://iet.metastore.ingenta.com/content/journals/10.1049/ip-sen_20050075
Loading

Related content

content/journals/10.1049/ip-sen_20050075
pub_keyword,iet_inspecKeyword,pub_concept
6
6
Loading
This is a required field
Please enter a valid email address