1. Multi-Paradigm Design
James O. Coplien
Ph.D. Student, VUB
18 May 2000

2. Thesis statement
Building on basic primitives of classic category theory and human cognition—commonality and variation—multi-paradigm design provides a uniform and formal basis for the definition of common programming paradigms, and a common basis for analysis of the application and solution domains, and the translation between them.

3. Thesis Claims
Abstraction and Intentionality: First Principles of Abstraction
Meta-Design: Paradigm selection as a design activity
A formal, domain-based model for paradigm
Commonality Categories
Application Domain and Solution Domain Analyses
Multiple paradigms within a domain
Dependencies between domains: Limits to Modularity
Theory of Negative Variability: Generalizing cancellation
Regularization of Ad-Hoc Design Patterns

4. The Purpose of Design To solve a problem Partitioning the Work
Design for change and all else follows
Partitioning the Work
Domains that follow business structure
Shaping modular structure
Choose a paradigm according to a basis
Attentiveness to Aesthetics
Solution domain analysis

5. Commonality and Variability Analysis
The basis of abstraction (classic model)
Families: commonalities and regularity in variabilities
Claim: Abstraction and Intentionality

6. Commonality Analysis The essence of abstraction
Commonalities define families from family members
We allow partitioning criteria to arise from the abstractions, not vice versa!
Many axes of commonality:
Behavior
Data structure
Name
Code structure
We define these as commonality categories
Claims: Meta-design
We deal with complexity by abstracting. Abstraction is the de-emphasis of detail and emphasis of what is common. Good analysis explores the commonalities we find in the domain of interest.
We follow our intuition, or use exhaustive techniques, or do something in between, to elicit patterns of commonality from the domain of interest. We use these commonalities to shape appropriate abstractions. For example, we might notice that all commands exhibit similar behavior in their interaction with the user and with the system as a whole: this kind of commonality makes commands a candidate domain. We don’t know whether messages will be states, or methods, or data structures—but we do know that they form a family, because we have found the common properties that hold them together.
It is useful to regularize several kinds of commonality, particularly if we know our implementation technology supports them. What are the kinds of commonality we can express in C++? C++ can express commonality in structure and behavior—we call those classes. But that’s not all: overloading, templates, and many other C++ facilities also express interesting axes of commonality. We strive to uncover analysis commonalities and variabilities well-suited to these solution domain abstractions.
We can think of structure, behavior, and name as being the dimensions of commonality in a multi-dimensional commonality space. Let’s give these axes a name and call them commonality categories. (Yeah, I’d like to find a better name, too, and am looking for suggestions.)

7. Variability Analysis Same dimensions as commonality
A commonality dimension + a variability dimension form a paradigm
Objects: common structure and behavior, variable structure and algorithm
Overloading: common semantics, variable interface and semantics …
Claims: A basis for paradigm

8. The place of paradigm A way of organizing things
We organize by abstracting
Abstracting focuses on what is common
We treat variations separately

9. A “Universal Paradigm”
Define a software family (by grouping according to commonalities)
Find the commonalities
Establish the parameters of variation
Design is the process of giving structure to a system, both at the conceptual level and in implementation. How do we go about design? Contrary to sometimes popular belief, the abstractions aren’t just there for the picking. It is sometimes hard work to find good abstractions.
Finding good abstractions depends on our familiarity with our business. If we have written many text editors, we are likely to know what the right abstractions should be for a new text editor. We certainly know the general areas we’ll need to look at: files, windows, command processing, crash recovery, etc. Some of these may become architectural abstractions, but for the time being we treat them just as areas of interest. We will later introduce these more formally as domains.
Having divided a system into domains, we can find the abstractions within those domains. We do this by grouping the “things” according to the properties, behaviors, and elements they hold in common. We can call a group of related things a family. A family is a set of related things (abstractions, functions, modules, use cases, etc.). We can even regularize the differences between individual set members by establishing parameters of variability. For example, we can describe the bounds on the character set types that a text buffer might handle; we may be able to enumerate the types we’re interested in. Think of this as mapping out the genetic structure of the family.

10. OO As a Special Case Arrange by commonalities
Collect similar objects into classes
Organize classes together using inheritance
Establishes a base class interface
Establish parameters of variation
Each family member has its own internal data structure
Each family member may implement a behavior with a different algorithm
Objects, widely thought to be a universal paradigm, actually cover only one or two interesting kinds of commonality and one or two interesting kinds of variability. They are very interesting kinds of commonality and variability, indeed: from infancy, we tend to think of the world as being made of independently manipulable things. However, software rarely deals with manipulable artifacts. Many software abstractions are conceptual, not tangible.
We can think of the object paradigm as a “degenerate” form of our “universal” paradigm. We group “things”, called objects or classes, by their commonalities. What commonalities? By state and behavior (classes from objects) or by common interface (class hierarchies from classes). The base class interface documents much of the commonality. We also establish parameters of variation: that’s what derived class data and virtual functions are all about.
The object paradigm works more often than not. Rather than presume on OO to work all the time, we’d rather come by the right structure honestly. Multi-paradigm design will degenerate into OO design if and when that’s the right choice.

11. Domain Analysis
Traditional domain analysis: study of a subject area, the building of families
Frequently based on commonality and variability analysis
There are many domains:
Many application domains
Solution domain

12. A problem: Negative Variation
In OO, inheritance with cancellation
BUT: it is more general
Template specialization: cancels structure
Argument defaulting and overriding
Many design patterns
Negative variation formalises these exceptions

13. Solution Domain CV Table
This is the domain analysis for C++ commonality and variability. It is the same form of table we will use when seeking commonalities and variabilities in the application domain.
The table builds on commonality categories. When we find a particular commonality category and variability category in the application domain, we can look up that pair in this table and choose the corresponding implementation technique for the implementation technology being used. This table applies to C++ users; we can build other tables for other programming languages. I believe the tables work best for highly expressive languages; for example (but not exclusively) those with a strong type system. We can also build tables for implementation technologies other than programming languages, like finite-state machines, databases, etc.

14. Negative Variability Table
For negative variability, we use this transformational analysis table instead of the one presented earlier for positive variability.

15. Most GOF patterns… aren’t...
Most design patterns from the GOF book are stylized mechanisms to capture microarchitectures that represent particular commonalities and variabilities. Others are techniques to capture negative variability.

16. Patterns of Negative Variability

17. TextBuffer Transformational Analysis
TextBuffer: Common Structure and Algorithm
Parameters of
Variability
Default /
Technique
Meaning
Domain
Binding
Output Type
The formatting of
text lines is sensi-
tive to the output
medium
Database,
RCS, TTY,
UNIX file
Run
UNIX File
Different buffer
types support
different character
sets
Character Set
ASCII,
EBCDIC,
FIELDATA
Compile
ASCII
We annotate the first column of the table with the commonality categories for the respective parameters of variability. Looking at the background of commonality (Common Structure and Algorithm) and the commonality categories in the Parameters of Variability column, we can choose a C++ feature to express the commonality/variability pair by looking up the pair in the Transformational Analysis Table and Negative Variability Table.
In the TextBuffer design, we see that a combination of virtual functions, templates, inheritance, and #ifdef is called for.
Working Set
Management
Different applications
need to cache dif-
ferent amounts of
memory
Whole file,
whole page,
LRU fixed
Compile
Whole file
Debugging Code
Debug in-house
only, but keep tests
in source code
Debug,
production
None
Compile

18. TextBuffer Transformational Analysis
TextBuffer: Common Structure and Algorithm
Parameters of
Variability
Default /
Technique
Meaning
Domain
Binding
Output Type
Structure,
Algorithm
The formatting of
text lines is sensi-
tive to the output
medium
Database,
RCS, TTY,
UNIX file
Run
UNIX File
Virtual
Functions
Different buffer
types support
different character
sets
Character Set
Type
ASCII,
EBCDIC,
FIELDATA
Compile
ASCII
Templates
We annotate the first column of the table with the commonality categories for the respective parameters of variability. Looking at the background of commonality (Common Structure and Algorithm) and the commonality categories in the Parameters of Variability column, we can choose a C++ feature to express the commonality/variability pair by looking up the pair in the Transformational Analysis Table and Negative Variability Table.
In the TextBuffer design, we see that a combination of virtual functions, templates, inheritance, and #ifdef is called for.
Working Set
Management
Algorithm
Different applications
need to cache dif-
ferent amounts of
memory
Whole file,
whole page,
LRU fixed
Compile
Whole file
Inheritance
Debugging Code
Code
Fragments
Debug in-house
only, but keep tests
in source code
Debug,
production
None
#ifdef (from
Negative variability
Table)
Compile

19. Text Buffer Dependency Graph
Character Set:
Type
Output Type:
Structure and
Algorithm
Text Buffer:
Common Structure
And Algorithm
Here we encode the parameters of variation in graphical form. The commonality domain (Text Buffer) is at the center; we draw arrows to circles representing the parameters of variation. Why? This may look like a hobby horse that is done for its own sake, but we this notation will serve us well later. If you think about it, parameters of variation—which we describe as commonality categories—may be interesting domains in their own right. In a complex system, what is a parameter of variation in one domain may be the core commonality in another. That implies an interaction between domains. The best domains minimize these interactions, as we emphasized earlier in this seminar; however, some interaction is inevitable. These interactions can introduce strange loops into design, and it pays to understand them.
Debugging
Code: Fine
Algorithm
Working Set
Management:
Algorithm

20. The File Domain Character Set: Encryption: Parametric Algorithm
Output Media
Debugging
Record
Type
Code: Fine
Structure and
Here is a dependency chart for the File or Output Media domain. The parameters of variation include the Buffer Type—our Text Buffer domain. Remember that the Text Buffer domain also took OutputMedia as a parameter of variation. Each domain depends on the other! Furthermore, both domains take Character Set as a parameter of variation.
We should merge these graphs to understand the overall design of the text editor
Algorithm
Algorithm
Buffer
Type:
Structure and
Algorithm

21. The unified design Claim: domain dependencies
Encryption:
Algorithm
Output Media
Character Set:
Type
When we collapse the graph, the circular dependency between Output Media and Text Buffer is apparent. Other parameters of variation, like Character Set type, factor out nicely.
We can deal with circular dependencies either by 1) adding levels of indirection; 2) using unconventional abstracting techniques for one of the reciprocal arrows (delegation instead of inheritance; templates instead of inheritance), or 3) re-factoring the circularity out of the design.
Let’s look at the implementation of this design, for the case where the Buffer Type depends on Output Type at run time, and the Output Type depends on Buffer Type at compile time.
Debugging Code:
Algorithmic Frags
Text Buffer
Working Set
Debugging
management:
Common Structure
Code: Fine
Algorithm
Algorithm
and
Algorithm

22. Recap of Claims Abstraction and Intentionality: The code is the design
Meta-Design: Doing objects honestly, or using other techniques when they apply
A formal, domain-based model for paradigm
Commonality Categories
Application Domain and Solution Domain Analyses
Multiple paradigms within a domain
Dependencies between domains: Limits to Modularity
Theory of Negative Variability: Generalizing cancellation
Regularization of Ad-Hoc Design Patterns

23. Thanks! David J. Weiss Theo D’Hondt Martine Devos Debbie Lafferty
Carine Lucas
Tim Budd
The Committee

24. Bijstelling: Symmetry and Patterns in Organizations
James O. Coplien
Ph.D. Student, VUB
25 April 2000

25. Aposition
Pattern theory can be used as a formal basis for organizational models based on social network theory. In particular, current role-based models can be extended to build on the hypothesis that human organizational structures follow the same symmetries and patterns of symmetry-breaking observed in other biological populations, a phenomenon that has deeper roots in more general laws of natural systems in the domains of crystallography, astrophysics, mathematics, subatomic particle physics, and other domains.

26. Two Architectures The thesis is about architecture
Per Conway, architecture is about organization
Here we talk of software patterns…
… but there are organizational patterns, too [Kroeber]

27. A curious pattern Patterns in anthropology…
Patterns in other natural sciences...
Software organizational patterns...
Patterns as symmetry breaking…
Alexander’s theory of patterns based on geometry…
…it’s all related

28. Aposition
Seek organizational formalisms based on symmetric relationships
Individials
Instrumental organizations
Establish common patterns
Tie to cultural invariants and breaking of those invariants in symmetric configurations
Seek drivers for symmetry-breaking

29. Building Blocks Organizational Patterns [Coplien et al.]
Group theory and symmetry theory
Prior art in ethnography and social network theory and research
Diadic psychology (family therapy, distance relationships literature, etc.)