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 Title Publication 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)
      • Concepts of programming languages
    3. 3)
      • An introduction to software architecture, Advances in software engineering and knowledge engineering
    4. 4)
      • Designing reusable classes
    5. 5)
      • Component software: beyond object-oriented programming
    6. 6)
      • Architectural mismatch or, why it's hard to build systems out of existing parts
    7. 7)
      • Law-governed regularities in object systems. Part 1: principles
    8. 8)
      • Design patterns: elements of reusable object oriented software
    9. 9)
      • Refactoring: improving the design of existing code
    10. 10)
      • Pattern-oriented software architecture – a system of patterns
    11. 11)
      • 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)
      • Software architecture in practice
    15. 15)
      • Software Engineering Institute, Carnegie Mellon University, 2002. http://www.sei.cmu.edu
    16. 16)
      • The unified modeling language reference manual
    17. 17)
      • 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)
      • 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)
      • Programming languages pragmatics
    23. 23)
      • 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)
      • Enterprise JavaBeans
    27. 27)
      • Design, implementation and evolution of object oriented frameworks: concepts and guidelines
    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)
      • 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)
      • The C++ programming language
    32. 32)
      • Object oriented modeling and design
    33. 33)
      • 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)
      • Handbook of mathematical logic
    36. 36)
      • Frege's logic, theorem, and foundations for arithmetic, The Stanford encyclopedia of philosophy
    37. 37)
      • The foundations of specification
    38. 38)
      • Object Management Group: Unified Modeling Language (UML), version 2.0
    39. 39)
      • Time-bounded random access machines
    40. 40)
      • Sequential abstract state machines capture sequential algorithms
    41. 41)
      • A theory of objects
    42. 42)
      • 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