In general, the Architectural Development pattern can be considered as a start out idea for the definition of the software architecture of a program or software system, aiming for maintainability as an important design attribute.

Problem

The problem is to develop software programs, which are able to evolve through time. In general, software programs are not built specifically to support certain evolution, in the form of change, adaptation, or modification to the original design and implementation. "Time is the essence of the real design problem" [Brand94].

Forces

Maintainability is a complex attribute. It is composed by several other attributes that act as forces to consider during the design:

• Change implies an internal ability to acquire new features or delete unwanted ones. It is related with adding a new functionality, enhancing an existing one, or repairing errors. It is important to answer how our program deals with improvement changes.


• Adaptation means the ability to cope with external changes. The software program should be capable to adapt to external changes in hardware and software technology, in order to remain competitive against other products in the market. The question here is what changes can be expected to happen in the technology environment.


• Modification is the ability to make changes quickly and cost effectively. It is important that a program is able not only to change and to adapt, but also to do it in a certain amount of time. The question here is how long does it take to change or to adapt an original version to an improved one.

Solution

First, it is important to notice that software programs are not static entities. They are the result of the activities performed by designers and programmers, in the form of layers of programmed components. Different parts of software programs change at different rates. Understanding this, the design, construction, maintenance and modification of software can be performed in a safer and more predictable way. However, a first difficulty seems to arise in how to recognise what parts of a software program represent each layer. In a software program, elements that compose a layer are not defined as clearly as in a building. Software Patterns can help to identify the layers of change in software, and also, to design and construct each one of the different layers needed to compose a software program.

Structure

The solution is presented as a layer-like structure. The use of this description is unfortunate because the term "layer" has a special meaning into the programming community. Layered software is composed of a number of different levels of abstraction. Each layer is allowed to communicate with the previous and next two ones [POSA96]. In contrast, the layer concept exposed here does not present precisely that behaviour. The layers are defined from a more natural point of view as stages of design and construction of software. Each layer is expected provide a base for the following one, but there is not explicit communication between them. Their relation is more approximate like a slippage between components. Even though it may cause some confusion, we decided to keep the description of layers to be consistent with the original idea. Figure 1 shows a brief of a notation used in [Benn97] for an architectural representation, relating components with the layers of change in software architecture. Their description is presented as the participants of this pattern.

Notice that Software Space Plan and Software Stuff do not form part of this architectural representation because both of them represent other levels of design detail.

Jorge Luis Ortega Arjona