Patterns for Architectural Praxis

 

Alan O’Callaghan

Software Technology Research Laboratory

De Montfort University

The Gateway

LEICESTER LE2 7NL

 

aoc@dmu.ac.uk

 

 

 

Introduction

The patterns below are patterns which extend the ADAPTOR (Architectural and Patterns-based Techniques for Object Re-engineering) patterns to encompass the architecting of Greenfield developments also. These patterns selected for review because they each are examples of different categories of patterns that make up the language. ‘Keeper of the Flame’ is an organizational/role pattern; ‘Mile-Wide,Inch-Deep’ is a philosophical pattern (of the kind of  which Alexander’s “Gradual Stiffening” is an example) while ‘Archetype’ is a pattern which reveals a technique for modeling software architectures.

 

The pattern template used below is one which has evolved with ADAPTOR. Its first patterns evolved from a legacy systems migration project in the telecommunications industry in 1996-7. Other patterns were discovered in subsequent projects, but initially had the character of ‘standalone’ patterns. Through subsequent revisions, and subsequent projects (eight to date in three different industrial sectors) the possibility of  a pattern language emerged. A pattern language is characterized by its generative character. Any pattern is an abstract solution to a general recurring problem in a particular context. The problem itself is often characterized by a number of forces which often compete and conflict. The application of the pattern to the emerging design mediates and resolves the tension caused by the contradictions in the situation, but in doing so creates a new context with a new set of forces; a new set of contradictions to be resolved. This dialectical movement from problem to solution through the resolution of contradictions is strongly reflected in the template.

 

The generative character of a pattern language is what gives it the ability to capture and disseminate ‘architectural knowledge’. The approach to legacy systems represented by ADAPTOR  has always stood closer to ‘forward engineering’ than traditional reverse engineering. It was therefore a natural step to widen the scope of ADAPTOR to include Greenfield approaches and seek a unified architectural praxis covering both forward engineering and the re-engineering of legacy systems. This project has the working name ‘Janus’.

 

 

 

 

Name:                   Mile-Wide, Inch-Deep

 

Problem:               How do you deliver a software architecture that remains flexible to changes in requirements, maximizes the room for creative design, yet at the same times maintains continuity through the lifecycle of a software development?

 

Context:                 A system is to be constructed which meets a business need, reflected in a set of functional and non-functional requirements that may change. The conceptual integrity of the system must be maintained throughout development, hence the need for a software architecture that is the product of the mind of a single person, or a small group of individuals.

 

Forces:                                 

·         Conceptual integrity is usually the product of a single vision, or the shared vision of a small group of like-minded individuals

·         Software development is a social process, involving the creative talents of many individuals.

·         The maintenance of conceptual integrity requires that all design choices, down to the smallest details, conform to and reflect the original concept.

·         Any significant software development is confronted with requirements’ changes over its lifecycle.

·         A given architecture can be realized in a number of different, yet conforming designs.

·         Specific designs, rather than conceptual architectures, lie on the critical path of  software development projects.

·          Software design, even at the fine levels of detail, is a creative process which can be damaged if over-constrained.

·         “Form liberates art” – an overall architectures provides an enabling platform for subsequent design decisions

·         Sometimes detailed design decisions are proposed that require a change in the “high-level” architecture

 

 

Solution:               Develop the software  as a growing, living structure. Give the maximum scope for creative design through successive iterations by delivering an architecture complete in its vision but leaving maximum freedom for later design decisions. Build in “slippage” in each iteration so that mistakes, imperfections can be corrected in the next iteration. While the architecture should always dominate over  individual design decisions, there will be times when so-called “lower-level” design decisions will require the architecture to be flexed in order to incorporate them. Only an architecture which is allowed to grow piece-meal can accommodate such changes gracefully.

 

Resulting Context:

A software architecture results that creates a framework  for ongoing negotiation between the architecture and detailed design   decisions in an iterative, incremental development process.

 

Rationale:

Christopher Alexander’s “Gradual Stiffening”[Alexander 1977] pattern prescribes structures that are “globally complete, but flimsy” as the basis for piece-meal growth in building. In his description of the pattern he contrasts the smooth, apparently effortless work of a master craftsman with the “panic-stricken attention to detail” of the novice. Coplien [1999] also contrasts piece-meal growth versus ‘masterplan’ approaches to software architecture.  Charles C. Brett [Brett 200] has described a number of successful software architectures that have grown ‘piece-meal’, notably  the St. Alphonsus Regional Medical Center project and the Telekurs Paynet system.

 

Name:                     Keeper of the Flame

 

Problem:               How do you maintain the conceptual integrity of a system, especially a long-lived one, in the face of  potentially many change requirements over time?

 

Context:                 A software system is being, or has been, constructed according to the architectural vision of a single person or a group of like-minded individuals. Architect Controls Product has been applied. The system is optimised for piece-meal growth through the application of  Mile-Wide,Inch Deep[1]. The pattern also has applicability for migrating legacy systems, provided that in the reverse engineering phase the above two patterns have been utilised.

 

Forces:  

·                     Conceptual Integrity is usually the product of a single vision, or the shared vision of a small group of like-minded individuals

·                     Software development is a social process, involving the creative talents of many individuals

·                     The maintenance of conceptual integrity requires that all design choices, down to the smallest details, conform to and reflect the original concept.

·                     Software design, even at the fine levels of detail, is a creative process which can be damaged if over-constrained

·                     Architecture needs to be very slow-moving, as detailed design decisions depend upon it, and "globally complete" at the outset of a project

·                     Software architecture and its detailed design are "thought-stuff" and therefore highly malleable and subject to change

·                     Architects as well as architectures can change over time

 

Solution:               Create a role whose function is to ensure that all subsequently proposed changes are in accordance with, or are at least continuous with, the original vision of the architect(s).  This role can be played by an individual, or in a large-scale development by a small team.  The personnel playing the role will probably change over time, especially in a long-lived system, and so care must be taken to ensure continuity through mentoring before hand-over etc.  Any person playing this role, or participating in it, should have other "hands-on" roles in the software development itself. The "Keeper" is a human point of reference for all developers who have ideas that potentially might cause changes to the software architecture. Through discussion with the Keeper they can resolve whether such changes are continuous with the architecture, and would thus enhance it, or  whether it might "break" the architecture and violate its integrity. It is the job of the Keeper to help a development team determine its design choices in a way that takes full account of the existing Software Architecture. However, the Keeper has no right of veto.

 

Resulting Context:

The development team is made fully conscious of the architectural vision  when making design choices. The Keeper of the Flame ensures a constant and continuous interaction between architecture and detailed design in which the architectural vision, in the last analysis, is predominant. As a result, the chances of systems being built which are flexible to change requirements but at the same time maintain a design harmony is increased. More usable, easily maintainable systems should result.

 

Rationale:

Software Architecture is configurational knowledge: it includes the answers to "why?" a particular set of design choices is made, as well as "what?". As such it is most often not on the critical path of project development at all, almost never so after the initial phases of development. As a result, some subsequent design decisions are likely to violate the original architecture.  Creating a role whose job it is to maintain consciousness of the conceptual integrity of the system under development is the best, and most human, way of making sure the vision is not lost in the process

 

Name:                    Archetype

 

Problem:               What are the building blocks of a first-cut software architecture?

 

Context:                 A software system is to be built that meets a business need. The architecture is to be developed “Mile-High, Inch-Deep”.

 

Forces:                 

§                The architect is the client’s agent

§                The client owns and maintains a conceptual model of the problem shaped by ‘real world’ forces.

§                The development team owns and maintain a conceptual model of the solution shaped by design trade-offs in the world of the machine.

§                The mapping between the conceptual model of the problem and that of the solution is rarely straightforward.

§                Many possible alternative specifications may suffice to meet the business need.

§                Many possible designs can implement a given specification

§                Traceability between an implemented solution and the business need is a requirement of a “good” solution

§                Specifications and implementations alike can change over the lifetime of a development project

§                Specifications and implementations alike can change over the lifetime of a system, even after implementation

 

 

Solution:               Build a model of the problem space based on the vocabulary of the client(s) by capturing the key abstractions as Object Types. An archetype is an Object Type which represents a core concept in the problem domain . Object Types are implementation-free classifiers of objects (as opposed to Object Classes which are cookie cutters for run-time object instances).  In a problem space model  it is important that behaviour be represented abstractly. As a rule operation protocols are a poor way of modeling such behaviour (because point-to-messaging to invoke algorithmic methods is implied). Rather describe archetypes in terms of their high-level responsibilities, or those logical attributes which reflect state-changing behaviour through their different values. Get the Model from the People can be used to identify the archetypes.

 

Resulting Context:

An abstraction which captures the behaviour of concepts perceived in the real world, and provides a reference point for  representation of that behaviour in the solution space. (Incidentally that representation need not be an object-oriented implementation).

                               

 

Rationale

Fred Brooks Jr., consciously using the metaphor of architecture in the built environment , first wrote of the software architect as the user’s agent as far back as 1975 [Brooks 1975]. More recently Ian Graham has described objects as a general  mechanism for knowledge representation in requirements engineering [Graham 1999].


[1] This is another pattern in the ADAPTOR language, one which is close to Alexander's Gradual Stiffening. It mandates the creation of a "globally complete" vision of the system which is structurally "flimsy" at the beginning of a project..