1. Objects, Patterns, Idioms, and Architecture
CSC 3380
Lecture 22

2. Sources
“Why Explore Object Methods, Patterns, And Architectures?” by Stephen Mellor and Ralph Johnson
“A Unified Object Topology” by William Tepfenhart and James Cusick
“Idioms and Patterns as Architectural Literature” by James Coplien
all from IEEE Software, v. 14, n. 1, pp

3. What do the words Objects, Patterns, Idioms, and Architecture Mean?
Little agreement, but some common concepts: domain analysis, modeling, processes, reuse, tools
O-O methods:
unify domain and design modeling
based on conceptual models of application and solution domain entities
O-O style is one of many architectural styles
Architectural Style
vocabulary, system structure, patterns of organization and interaction
domain‑specific architectures and reference models
basis for domain analysis and software specification

4. Meaning, continued Patterns:
repeated named solution patterns;
described as reference models in a literary form;
uninterested in domains or implementation techniques
often spurn classification systems and tools
look at patterns in a larger scope;
talk of social, organizational, process patterns
Distinguish who is who by asking how they deal with generic and specific information
O-O: both in objects;
Architecture: generic in DSLs, specific in special‑purpose languages;
Patterns - ignore specific information.

5. Unified Object Topology

6. Meaning of the topology
Each region represents a design technique:
Domain taxonomies: categorize applications within a family of related problems;
Domain models: abstract models, especially reference models, incorporate domain specific information;
Architectural styles: entire software architecture families with common operational characteristics;
object‑oriented
state‑machine based
real‑time
on‑line transaction processing
data‑streaming
decision support

7. Meaning of the topology continued
Object design patterns: spans a large spectrum, from abstract frameworks through design patterns to idioms;
Frameworks: sets of implementation‑specific infrastructure and control classes
e.g. GUI development systems
tend to be implementation images of architectural styles and high‑level patterns;
Kits: implementation images of low‑level patterns and domain models. They often provide the application specific classes which are fit into a framework to produce a system.
Application are built using all the others

8. Processes - paths in the topology
Figure 3

9. How to use the topology Help in several tasks:
Software system construction;
Identification & development of reusable components;
Organization and management of object repositories, using the topology as a basis of classification
Frameworks are based on a specific architectural style, which is fleshed out with design patterns, and then implemented as a framework
Kits are based on a specific domain model identified by domain taxonomy, then fleshed out with design patterns, then implemented as a kit
System development path - little actual coding

10. The Patterns Subculture
The Timeless Way of Building and A Pattern Language by Christopher Alexander are their foundational “scriptures”
They see patterns as transcending tools, methods, and even architecture
They fault O-O methods for concentrating too much on components, or modules, and not enough on relationships between objects and classes; we should use patterns to capture these relationships
They believe “today’s problems are larger than one person”, so it is necessary to use abstraction in order to comprehend software applications

11. Object Systems and Idioms
Improve the abstraction of functional design by introducing two hierarchies, inheritance and aggregation.
Inheritance is a denser hierarchy because it bundles many functions together at a single level
Through polymorphism, each of these functions may be only an abstraction of several different implementations in derived classes
Early object‑oriented methods tended to focus on “finding the objects” instead of relationships
Idioms focus on design rules which express patterns of relationships

12. O-O and Patterns Patterns don’t have to be object‑oriented
Coplien is “mining” classical embedded systems patterns, to preserve their wisdom for the ages. None of these classical patterns is truly object‑oriented
In that sense, patterns are microarchitectures
In fact, patterns go beyond architecture, to look at skills, patterns of behavior, social organizations
In the largest sense, patterns are seen as reintroducing humanism, creativity, and esthetics into software development