The Architectural Development pattern, based on the concept of the Layers of Change in Software Architecture [OR99], can be used as an approach to the study, design and construction of maintainable software systems in general. It provides a base to understand how software systems change or evolve, by expressing and organising it as different subsystems as "layers of change". These layers are defined according with the specific order in which generally they are designed and implemented. They also reflect the different rates of change that parts of a software program experience during its lifetime.
Patterns were originally developed for building architecture [APL77, TWoB79], and adopted later for software development [POSA96, PLoP94, Gab96, GoF94, PLoP95]. Their use is spreading in the software community to the benefit of those undertaking design and implementation tasks. However, other design practices can also be useful for software development. This can be probably the case with the layers of change. In fact, the layers of change, in the context explained by the architectural-based development, can be analysed as a pattern, or perhaps a meta-pattern, for the use of software patterns when constructing any complex software system.
Trying to apply this concept to software architecture though an analogy, it is necessary to make some basic assumptions, like what would be a "building" in software terms, who are its occupants or inhabitants, and how they are able to change and modify their "software buildings". Richard Gabriel proposes an interesting analogy when introducing the concept of habitability in software:
"Habitability is the characteristic of source code that enables programmers, coders, bug fixers, and people coming to the code later in its life to understand its construction and intentions, and to change it comfortably and confidently" [Gab96]
Originally, the word habitability is related to issues about buildings and the quality of living in them. Nevertheless, Gabriel applies this word to explain an important characteristic of software, which enables programmers and developers to "live" comfortably in and repair or modify code and design. Gabriel applies the concept of habitability as an analogy between software and building, comparing a program to a New England farmhouse, which slowly grows and is modified according to the needs and desires of the people who live and work on the farm.
"Programs live and grow, and their inhabitants -- the programmers -- need to work with that program the way the farmer works with the homestead" [Gab96]
Similarly, considering any software program as an analogy of a building, and programmers representing the occupants of software, the layer of change can be described in order to describe the activity of refining and reshaping software as the process of testing, debugging, extending, adapting and maintaining it through time.
The Architectural Development Pattern
Brief. The Architectural Development Pattern allows to consider a software program or system as a whole, to be designed and composed by different kinds of elements, which make it capable to be safely changed, adapted, and modified during its lifetime.
Why is it often simpler to understand architectural properties in building architecture than in software architecture? It is probably because a building is the most commonly human constructed system that we know. A building is a stage for human life. We usually spend all our lives in buildings, and know about their advantages and liabilities, whereas only recently the idea of "inhabiting" software has been considered by the Pattern Community.
Surely, this is not the only description analogy that can be obtained between building and software architecture. Our interpretation of the Layers of Change is not unique. Interpretations depending on other paradigms, techniques and applications can also be proposed. However, as our work is closely related to the area of Software Architecture, Software Patterns, and Object-Oriented Programming, this analogy seems to fulfil our requirements and expectations. Our aim is that the way we use analogy to obtain this interpretation for software design and construction would be useful for others to propose their own interpretations [OR99].
Jorge Luis Ortega Arjona