Examples
A Non-programming Example
The idea of layers of change in a building architecture arises from the form in which a building is planned and created, following the actual and future needs of its occupants. Based on an original description, Steward Brand proposes a general purpose "six S's" for the Layers of Change in building architecture [Brand94]:
- Site. "This is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context out lasts generations of ephemeral buildings".
- Structure. "The foundation and load--bearing elements are perilous and expensive to change, so people don't. These are the building. Structural life ranges from 30 to 300 years (but few buildings make it past 60, for other reasons)".
- Skin. "Exterior surfaces now change every 20 years or so, to keep up with fashion or technology, or for wholesale repair. Recent focus on energy costs has lead to re--engineered Skins that are air--tight and better--insulated".
- Services. "These are the working guts of a building: communications wiring, electrical wiring, plumbing, sprinkler system, HVAC (heat, ventilating, and air conditioning), and moving parts like elevators and escalators. They wear out or obsolesce every 7 to 15 years. Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily".
- Space Plan. "The interior layout -- where walls, ceilings, floors, and doors go. Turbulent commercial space can change every 3 years or so; exceptionally quiet homes might wait 30 years".
- Stuff. "Chairs, desks, phones, pictures; kitchen appliances, lamps, hair brushes; all the things that twitch around daily to monthly. Furniture is called mobilia in Italian for a good reason".
A Programming Example
Let us consider the case study exposed in the chapter 2 in [GoF94]: "Designing a Document Editor", based on the design of Lexi, a text editing application developed by Calder. In this example the whole problem of designing such document editor is partitioned into seven subproblems [GoF94]:
- Document Structure. "The choice of internal representation for the document affects nearly every aspect of Lexi's design. All editing, formatting, displaying, and textual analysis will require traversing the representation. The way we organize this information will impact the design of the rest of the application".
- Formatting. "How does Lexi actually arrange text and graphics into lines and columns? What objects are responsible for carrying out different formatting policies? How do these policies interact with the document's internal representation?"
- Embellishing the user interface. "Lexi's user interface includes scroll bars, borders, and drop shadows that embellish the WYSIWYG document interface. Such embellishments are likely to change as Lexi's user interface evolves. Hence it's important to be able to add and remove embellishments easily without affecting the rest of the application".
- Supporting multiple look-and-feel standards. "Lexi should adapt easily to different look-and-feel standards such as Motif and Presentation Manager (PM) without major modification".
- Supporting multiple windows system. "Different look-and-feel standards are usually implemented in different window systems. Lexi's design should be as independent of the window system as possible".
- User operations. "Users control Lexi through various user interfaces, including buttons and pull-down menus. The functionality behind these interfaces is scattered throughout the objects in the application. The challenge here is to provide a uniform mechanism both for accessing this scattered functionality and for undoing its effects".
- Spelling checking and hyphenation. "How does Lexi support analytical operations such as checking for misspelled words and determining hyphenation points? How can we minimize the number of classes we have to modify to add a new analytical operation?
It can be noticed that these subproblems are related with the development order proposed for the design, as well as to the rate of change that each one may expose during the lifetime of the document editor. Certainly, there is a sense of logical order during their discussion. Furthermore, there seems to be a constant concern about the change, modification and adaptation capabilities that the document editor should reflect during its lifetime.
Contact Information
Jorge Luis Ortega Arjona
E-mail jortega-arjona@acm.org