Topic: design for change

topics > computer science > programming > Group: goals for a programming system

database model
distributed systems
program design
software maintenance

change notification
data-driven design
database change management
declarative vs. procedural representation
decomposition of a system into levels
dynamic vs. static data type
program module as encapsulation
evolutionary systems
extensible languages
families of programs
general purpose computer systems
global declarations and variables
identifying program modules
incremental development
information hiding
language flexibility
loosely structured data
managing a Thesa database
object-oriented design
non-constraining system
open systems
relational database
resourceful, redundant systems for reliability
reusable programming
scripting language
sensitivity of software to change
separate a module's interface specification from its implementation
software maintenance by patching
software portability
specification and design of distributed systems
user-centered design
user interface design


Maintaining a program requires program changes long after the program was designed. If flexibility is not built into the program these changes will be expensive. No design can accurately predict how a system will behave under use. Parnas' approach is to decide where flexibility is needed and then define independent modules as these points. The modules have limited interconnections which help prevent module modifications from having adverse effects on other modules. A simply approach is building a preliminary system for experimentation and later building a final version. This removes the initial flood of modification requests but it doesn't stop the modification process. In Thesa, the modification process and the design process are the same. In a way each modified system is a preliminary system for experimentation. (cbb 5/80)

Thesa will hopefully avoid the general vs. flexible dichotomy. Systems are inherently general since they can be used wherever they approximate reality. But a general system is rigid because a change for one situation can effect the usefulness of the system for other situations; and a general system is expensive because it must execute code which is needed for other situations. Generality may be the cause of Brook's dictum: "Plan to throw one away." The pre-emptive nature of program language design may be the cause of enforced generality. (cbb 12/89)

Subtopic: a sea of change up

Quote: all large and widely used systems are subject to an endless stream of changes
Quote: a system must be designed to remain as simple as possible under a sequence of changes that cannot all be foreseen [»stroB_1991]
Quote: in designing a system should be committed to living in a sea of changes [»goulJD8_1987]
Quote: a programming language usually undergoes constant growth and revision [»rossDT3_1957]
Quote: large systems should be constructed for evolutionary change; may require greater overhead during development [»wegnP_1979a]
Quote: a program is a complex combination of diverse materials that must undergo continuous modification; how can they be supple [»smitDR11_1985]
Quote: law of continuing change: if a program must reflect some other reality [»lehmMM9_1980]
Quote: a system must remain correct under an unending sequence of changes [»belaLA_1979]
Quote: when Disney made a carton, it was never too late to make a change [»heckP_1984]
Quote: complicated ideas evolve slowly with lots of change [»nelsTH_1987]
Quote: a program that reflects some other reality must change continuously or become less useful; eventually need to rewrite [»lehmMM3_1981]
Quote: distributed systems undergo continuous change [»hewiC4_1985]
Quote: knowledge base of a distributed system is perpetually inconsistent [»hewiC4_1985]
Quote: in a distributed system, information is incomplete; no closed-world assumption [»hewiC4_1985]
Quote: business is the specific organ of growth, expansion, and change in an economy; it needs change [»drucPF_1974]

Subtopic: design for change up

Quote: programs are complex systems that should be reliable and infinitely malleable; they should manage complexity and facilitate change [»guttJV_2002]
Quote: in design for change, must anticipate change before beginning a design [»parnDL5_1978]
Quote: design for change by making a system flexible, extensible, and portable. Encapsulate the areas that are likely to change [»stroB_1991]
Quote: change a module's implementation without knowledge of the implementation of other modules and without affecting the behavior of other modules [»parnDL3_1985]
Quote: except for interface changes, allow independent changes to individual modules; mix and match combinations of old and new versions [»parnDL3_1985]
Quote: flexibility can not be added to a software design; choice of usable subsets must be a preliminary step [»parnDL5_1978]
Quote: should make global decisions first; should postpone decisions that are likely to change
Quote: by basing software development on a model of the subject matter, can allow for continual change in the specifications [»jackMA2_1984]
Quote: define macros for anything that may change; allows delayed binding for implementation of the macros [»browPJ_1974]

Subtopic: abandoned plans up

Quote: record abandoned plans and designs; helps transfer the project plan to the design team; helps avoid misdirected, low-level design decisions [»colwRP_2006]

Subtopic: maintain consistency up

Quote: DRY--don't repeat yourself; every piece of knowledge must have a single representation in a system; knowledge changes too fast to keep multiple copies consistent [»huntA_2000]
Quote: keep design documents consistent with a system; if multiple versions are required, confine the differences to small modules [»parnDL2_1986]
Quote: a UML dependency occurs when a change in one thing affects the semantics of another [»boocG_1999]
Quote: problem of traceability--how does change in one software artifact (requirement, design, code) affect other artifacts [»clarS11_1999]

Subtopic: stability vs. improvement up

Quote: constant tension between improving a design and providing stability and continuity [»lampBW10_1983]

Subtopic: general vs. flexible up

Quote: software is general if it can be used without change; it is flexible if it can be easily changed [»parnDL5_1978]
Quote: generalized software is less efficient than flexible software

Subtopic: indirect vs. concrete up

Quote: inheritance hides the effect of change through a complicated, inheritance model; non-inheritance is more direct [»perrDE1_1990]
Quote: design software for ease of change; be explicit; e.g., an explicit field for number of dependents instead of a keyword-value pair [»fowlM11_2001]

Subtopic: query vs. command up

Quote: categorize methods/functions as command or query; freely use queries while commands hide information [»huntA1_2003]

Subtopic: conceptual change up

Quote: a Smalltalk user should be able to rapidly change the conceptual model of a system without strong technical skills; needed for simulation [»goldA10_1995]
Quote: ideally, each class is responsible for the maintenance of all information relating to a single concept. If so, a change in a concept effects one class only

Subtopic: database change up

Quote: be careful of over-constraining database types; allow new unforeseen uses; object-orientation is too restrictive [»coddEF_1990]
Quote: over time databases expand and some information may be dropped; applications easily adjusted [»coddEF_1990]
Quote: the results of a database command must be independent of the database organization and access methods [»coddEF_1990]
Quote: no "nextness" for rows or columns of a relation; both are position-independent [»coddEF_1990]
Quote: avoid representational dependencies in data; e.g., ordering, indexing, and access path

Subtopic: data change up

Quote: data independence means maintaining data/file structures separately from programs; e.g., the size of the ZIP code field [»morgH_1980]
Quote: in FQL, can incrementally define data; no pre-defined schema [»buneP1_1981]
Quote: example of design for change in processing street addresses [»parnDL5_1978]
Quote: a personal information system must allow free format text, dynamically defined structure, and arbitrary report formats [»kaplSJ7_1990]
Quote: without a fixed field/value orientation, Agenda can present data in any format
Quote: Lisa List can add or change fields at any time; allows any amount of text [»willG2_1983]

Subtopic: network change up

Quote: a Jini network allows membership changes and communication changes between components; long-running [»waldJ7_1999]

Subtopic: version management up

Quote: every successful major piece of software will be worked on by a succession of programmers and designers, ported to new platforms, adapted to new uses, and reorganized. Must plan for multiple versions [»stroB_1991]
Quote: hot swap modules need to change types while preserving type safety; use reflective mechanism with programmer-defined version adapters [»duggD9_2001]
Quote: Web components are deployed independently; old and new implementations co-exist; identify and encapsulate old versions; incremental deployment [»fielRT5_2002]

Subtopic: configuration up

Quote: use metadata to configure an application at runtime; e.g., tuning, preferences, installed directory [»huntA_2000]
Quote: put details in the metadata, abstractions into code; think declaratively for ease of change at the last moment [»huntA_2000]

Subtopic: user interface change up

Quote: user-interface requirements change more rapidly than other types of requirements

Subtopic: information hiding up

Quote: tell objects what needs to be done, keep decisions inside objects (object-oriented, encapsulated)
Quote: avoid talking to more objects than necessary; protects against change; e.g., Law of Demeter [»huntA1_2003]
Quote: Law of Demeter prohibits calls to returned objects; leads to many small wrapper functions
Quote: law of Demeter--an object only calls itself, its parameters, or objects it creates; needs a large number of wrapper methods for forwarding requests [»huntA_2000]

Subtopic: framework up

Quote: quickly develop a framework for the final system; provides an integration platform, a structure to expand, something to demonstrate, and better work estimates [»huntA_2000]

Subtopic: retain change history, alternatives up

Quote: include all design alternatives in the documentation along with why they were considered and why they were rejected [»parnDL2_1986]
Quote: a modifiable program must retain the structure of its development [»wulfWA6_1976]
Quote: because of repeated modifications, a program text must contain everything that makes it understandable [»wulfWA_1977]
Quote: hypertext for specialist access and muster of information; enhance existing material with commentary, surveys, connections; maintains relevance [»nelsTH_1967]

Subtopic: permanent links up

Quote: permanent document links by disallowing change; e.g. legislative and judicial document collections [»ashmH9_2000]

Subtopic: difficulty of change up

Quote: pre-emptive language design makes many trivial decisions before a program is even written [»shawM3_1980]
Quote: prescribing the number of digits in a date field is a trivial design decision; it is a scandal only because it is expensive to change [»creeC11_1997]
Quote: measure language effectiveness by counting the modifications needed to satisfy a user's needs and to effect change during evolution [»blumBI_1985]
Quote: the software life cycle rigidifies thinking and reduces a system's responsive to change [»mccrDD4_1982]
Quote: with the software life cycle, changes occur reluctantly and in large packets [»mccrDD4_1982]
Quote: multilevel security and mandatory access control concentrate on confidentiality; it assumes that classifications are fixed and well known; it may deny legitimate access [»schnB_2000]

Subtopic: brittle, functional design up

Quote: functional design of software leads to brittle systems that can not change easily [»boocG_1999]
Quote: with a functional design it is difficult to determine the cost of making a change [»jackMA5_1976]
Quote: a functional design may have no function corresponding to an individual session; makes it difficult to modify [»jackMA5_1976]
Quote: with conventional programming, every new fact requires a change in the program; e.g., the post office changing the ZIP code length [»sowaJF_1984]
Quote: do not query an object, make a decision, and perform an action (procedural, bug prone) [»huntA1_2003]

Related Topics up

Group: database model   (15 topics, 316 quotes)
Group: distributed systems   (14 topics, 348 quotes)
Group: program design   (13 topics, 454 quotes)
Group: software maintenance   (14 topics, 368 quotes)

Topic: change (28 items)
Topic: change notification (19 items)
Topic: data-driven design (41 items)
Topic: database change management (12 items)
Topic: declarative vs. procedural representation (54 items)
Topic: decomposition of a system into levels (49 items)
Topic: dynamic vs. static data type (24 items)
Topic: program module as encapsulation (28 items)
Topic: evolutionary systems (47 items)
Topic: extensible languages (71 items)
Topic: families of programs (11 items)
Topic: general purpose computer systems (9 items)
Topic: global declarations and variables (33 items)
Topic: identifying program modules (26 items)
Topic: incremental development (74 items)
Topic: information hiding (50 items)
Topic: language flexibility (34 items)
Topic: loosely structured data (20 items)
Topic: managing a Thesa database (34 items)
Topic: object-oriented design (30 items)
Topic: non-constraining system (25 items)
Topic: open systems (33 items)
Topic: relational database (35 items)
Topic: renaming (10 items)
Topic: resourceful, redundant systems for reliability (38 items)
Topic: reusable programming (77 items)
Topic: scripting language (27 items)
Topic: sensitivity of software to change (44 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software maintenance by patching (27 items)
Topic: software portability (43 items)
Topic: specification and design of distributed systems (14 items)
Topic: user-centered design (65 items)
Topic: user interface design
(36 items)

Updated barberCB 3/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.