Group:
database model
Group:
distributed systems
Group:
program design
Group:
software maintenance
Topic:
change
Topic:
change notification
Topic:
data-driven design
Topic:
database change management
Topic:
declarative vs. procedural representation
Topic:
decomposition of a system into levels
Topic:
dynamic vs. static data type
Topic:
program module as encapsulation
Topic:
evolutionary systems
Topic:
extensible languages
Topic:
families of programs
Topic:
general purpose computer systems
Topic:
global declarations and variables
Topic:
identifying program modules
Topic:
incremental development
Topic:
information hiding
Topic:
language flexibility
Topic:
loosely structured data
Topic:
managing a Thesa database
Topic:
object-oriented design
Topic:
non-constraining system
Topic:
open systems
Topic:
relational database
Topic:
renaming
Topic:
resourceful, redundant systems for reliability
Topic:
reusable programming
Topic:
scripting language
Topic:
sensitivity of software to change
Topic:
separate a module's interface specification from its implementation
Topic:
software maintenance by patching
Topic:
software portability
Topic:
specification and design of distributed systems
Topic:
user-centered design
Topic:
user interface design
| |
Summary
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 
| 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
| 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
| 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
| 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
| Quote: constant tension between improving a design and providing stability and continuity [»lampBW10_1983]
|
Subtopic: general vs. flexible
| 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
| 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
| Quote: categorize methods/functions as command or query; freely use queries while commands hide information [»huntA1_2003]
|
Subtopic: conceptual change
| 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
| 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
| 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
| Quote: a Jini network allows membership changes and communication changes between components; long-running [»waldJ7_1999]
|
Subtopic: version management
| 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
| 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
| Quote: user-interface requirements change more rapidly than other types of requirements
|
Subtopic: information hiding
| 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
| 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
| 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
| Quote: permanent document links by disallowing change; e.g. legislative and judicial document collections [»ashmH9_2000]
|
Subtopic: difficulty of change
| 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
| 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
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)
|
