Amnon H. Eden • Bio • Research • Publications • Study • Personal • Contact •

The Intension/Locality Hypothesis

Divider

Problems worthy / of attack / prove their worth / by hitting back
-- P. Hein

(*) NOTE: Since the hypothesis was published, I've received evidence that design patterns are not always local (LI). For example, the Proxy and the Facade design patterns [Gamma et al. 1995], in addition to the Singleton design pattern mentioned in the caveat, are Non-Local (they involve some information hiding in some form). As a consequence I concede that the part pf the hypothesis according to which "design patterns are local" is false, or probably false, and that the current formulation of the hypothesis requires some revision. If you have suggestions, please write me.

Amnon Eden, Nov. 2007

Without abstraction and idealization there is no systematization
-- John Searle

This version of the intension/locality hypothesis was published in “Abstraction Classes in Software Design.” Earlier (more restricted and slightly differently formulated) version of the hypothesis appeared in “Architecture, Design, Implementation” (see also: bibliographical list). Below the hypothesis and some of its implications are sketched.

Synopsis. We distinguish three abstraction strata in software design statements:

  1. Strategic statements (‘architectural design’) determine global constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities;
  2. Tactical statements (‘detailed design’) determine constraints, such as design patterns, programming idioms, and refactorings
  3. Implementation statements determine specific properties of the implementation, such as 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:

  1. The class of non-local statements (NL) contains Strategic statements;
  2. The class of local and intensional statements (LI) contains Tactical statements;
  3. The class of ‘local and extensional’ statements (LE) 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.

Keywords: Software design theory, software architecture, model theory.

Table of Contents

Divider

Motivation

The Intension/Locality hypothesis has both conceptual and practical contributions.

Conceptual contributions:

  1. Offer a top-level ontology for software design: the three categories which divide all software design statements.

  2. Distinguish architectural-design from detailed-design (using the Locality criterion).

  3. Explain architectural mismatch (using the Locality criterion).

  4. Capture intuitive notions using concise and well-defined criteria.

  5. Provide a common vocabulary for the discussion in description of programs, spanning a wide range of design statements (including programming paradigms, architectural styles and components) for a literature that is largely fragmented by many idiosyncratic technical jargons.

Practical contributions:

  1. Distinguish the design decisions that must be made earliest in the software development lifecycle (non-local statements such as architectural styles).

  2. Resolve the confusion between Architectural Design document vs. Detailed Design document.

A top-level ontology for software design

We observe three categories of statements in the technical literature on software design:

  1. Strategic statements (“architectural-design”), which determine global design concerns, such as architectural styles ("UNIX is a layered architecture"), programming principles ("Java supports information hiding"), component-based software engineering standards (CORBA, Enterprise JavaBeans), design principles ("all classes inherit possibly indirectly from class Object") and application frameworks, as well as assumptions that may lead to architectural mismatch and law-governed regularities;

  2. Tactical statements (“detailed design”), which determine local concerns of limited scope, such as design patterns ("Smalltalk supports the Observer pattern"), refactorings ("extract common base class") and programming idioms ("counted pointer can be used to manage memory");

  3. Implementation statements, which describe minute details of a specific implementation, such as UML class & collaboration diagrams.

Three Abstraction Classes: The Intension/Locality Hierarchy

We define two criteria which divide all statements in software design (i.e., descriptions of programs) into a hierarchy of three abstraction classes, the intension/locality hierarchy (Figure 2):

Fig. 2: The Intension/Locality Hierarchy

The Intension/Locality Hierarchy

The language of the Intension/Locality criteria is given below.

The locality criterion divide the spectrum of all design statements into two abstraction classes: L ("local") and NL ("non-local"). The Intension criterion further refines L in two classes: LI ("local and Intensional") and LE ("local and extensional"). Jointly, these criteria result divide the space of design statement a hierarchy of three abstraction classes (Figure 2): NL, LI, and LE.

The Hypothesis

We postulate that the three abstraction classes in the Intension/Locality hierarchy (NL, LI, LE) coincide with the top-level ontology observed in the vernacular, namely that—

  1. Strategic statements (“architectural design”) are in NL (“non-local”);
  2. Tactical statements (“detailed design”) are in LI (“local and intensional”);
  3. Implementation statements are in LE (“local and extensional”).

Fig. 1: The Intension/Locality hypothesis

The Criteria

The Locality criterion. A statement is local if and only if it is preserved under expansion.

Less formally, this criterion implies that strategic statements describe properties of the entire software system whereas tactical specifications pertain only to a delimited part of the program.

Examples for non-local statements:

  • "Only methods of class Object can access the private member Object.private" (information hiding)
  • "Every class inherits from class Object" (universal base class)
  • "Every component in the system is either a pipe or a filter" (pipes and filters)

Examples for local statements:

  • "Every class in the set Observers inherits from class Observer" (Observer pattern)
  • "The Body class should have a reference counter, and the Handle class should have a data member pointing to the Body object" (Counted Pointer idiom)

The Intension criterion. A statement is extensional if and only if it is preserved both under expansion and under reduction.

This criterion implies that implementation statements (such as class diagrams) describe a particular implementation ("extensional") whereas strategic and tactical (intensional) statements have an unbounded number of possible implementations.

Examples for extensional statements:

  • Any UML class, package or collaboration diagram
  • "Class Array inherits from class Object"
  • "init is created in method Object.main"

Evidence

Evidence corroborating the Intension/Locality hypothesis are detailed and proven in [Eden, Hirshfeld & Kazman 06], summarised in the following table:

Non-local statements (NL)

Architectural styles
  • Layered architecture
  • Pipes and filters
  • Implicit invocation

CBSE standards
  • Enterprise JavaBeans™
  • Component Object Model (COM)

Application frameworks
  • Microsoft Foundation Classes (MFC)

Design principles
  • Information hiding
  • Universal base class

Other
  • Architectural mismatch
  • Law-governed regularities

Local and intensional statements (LI)

Design patterns
  • Strategy
  • Factory Method
  • Publisher-Subscriber

Refactorings
  • Replace Type Code With Class
  • Replace Conditional With Polymorphism
  • Replace Constructor with Factory Method
  • Tease Apart Inheritance

Programming idioms
  • Counted Pointer

Local and Extensional statements (LE)

Class diagrams

Interaction diagrams
Divider

Bibliography

Aspects of the Intension/Locality Hypothesis were presented in various forms:

Complete description: formal + informal (52 pages) Amnon H. Eden, Yoram Hirshfeld, Rick Kazman. “Abstraction Classes in Software Design.” IEE Software, Vol. 153, No. 4 (Aug. 2006), pp. 163–182. London, UK: The Institution of Technology and Engineering.
Philosophical summary (7 pages) Amnon H. Eden, Raymond Turner. “The ontology of software design: The Intension/Locality Hypothesis.” Presented in: 3rd European Conf. Computing And Philosophy—ECAP (2-4 Jun. 2005), Västerås, Sweden.
Locality criterion: informal (10-pages) Amnon H. Eden. “Strategic Versus Tactical Design.” Proc. 38th Hawaii Int'l Conf. on System Sciences—HICSS (Jan. 3–6, 2005), Honolulu, HI. Los Alamitos: IEEE Computer Society Press.
Early version, informal (10 pages) Amnon H. Eden, Rick Kazman. “Architecture, Design, Implementation.” In: Laurie Dillon, Walter Tichy (eds.), Proc. 25th Int'l Conf. Software Engineering—ICSE (3–10 May 2003), Portland, OR, USA, pp. 149–159. Los Alamitos, USA: IEEE Computer Society Press.

Presentations:
Philosophical summary (20 slides) “Towards an ontology of software design: The Intension/Locality Hypothesis.” European Conf. Computing and Philosophy—ECAP (2–4 Jun. 2005), Västerås, Sweden. [.ppt]
Introduction for students (31 slides) Abstraction strata in software design. Lecture notes from seminar, 21-May-2004. [.ppt]
Disclaimer Top of page