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

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. 27-42

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

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.

Unified Object Topology

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

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

Processes - paths in the topology Figure 3

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

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

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

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