Group: program design

topics > computer science > Group: programming

CADES structural modeling with holons
decomposition of a system into levels
design languages
data-driven design
decision table
design documentation
design errors
object-oriented design
object-oriented modelling language
pseudocode design
stepwise refinement
top-down vs. bottom-up design
user-centered design
database model
goals for a programming system
program module
requirement specification
software engineering

abstract data type
automated tests of specifications and designs
Cleanroom software development
design for change
program module as encapsulation
executable code from specifications and designs
good requirement specifications
identifying program modules
interface between program modules
information hiding
incremental development
programming environment
programming language design
requirement specification by function
software components
software lifecycle
software models of reality
software review
specification and design of distributed systems
user interface design


Is design necessary, or can a system develop naturally? (cbb 6/05)
Subtopic: importance of design up

Quote: before writing code, it is good to plan the process, its successive stages, and the corresponding relationships [»goldHH_1948]
Quote: the larger the program, the more attention its design requires [»joneTC4_1979]
Quote: even though there is not a rational way to design software, we can fake one; i.e., present a system as if it were designed rationally [»parnDL2_1986]
Quote: while we view natural systems as self-regulating, we think that artificial systems require a designer [»simoHA_1981]

Subtopic: software is not fractal up

Quote: software is not fractal; high-level design is qualitatively different from low-level design; e.g., system architecture, abstract data type, and implementation [»guttJV_2002]

Subtopic: contextual design up

Quote: users must participate in the design of a building, otherwise the building will not fit the users' needs [»alexC_1975]

Subtopic: design as communication up

Quote: the purpose of design is to communicate an idea to others, not to a computer [»cainSH_1975]
Quote: program design is a social activity where designs are developed through presentation and discussions; e.g., discuss design and implementation alternatives [»stroB_1991]
Quote: often, the most important design tool is a blackboard; for developing and sharing embryonic concepts
Quote: in design fields such as architecture, the rough sketch is heavily used; detailed drawings seldom occur before the creative work is finished [»weinGM_1982]
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: good designs up

Quote: a design should be well structured, simple, efficient, adequate, flexible, practical, implementable, and standardized [»parnDL8_1985]

Subtopic: design as re-design, implementation up

Quote: both design and implementation are interleaved in a real project. Design is usually re-design from the previous design, experience, and constraints [»stroB_1991]

Subtopic: design as decision up

Quote: design and development are a series of decisions; effect later decisions [»parnDL8_1971]
Quote: identify questions first to avoid being satisfied with the easy answers [»hoffDM_2001]

Subtopic: data-driven design up

Quote: require data for resolving design issues; establish a data-driven culture; data forces the right questions [»colwRP_2006]

Subtopic: design as decomposition up

Quote: divide a complex task into simpler subtasks; specify purpose of each subtask; define efficient, precise interfaces between the subtasks

Subtopic: design as tradeoffs up

Quote: programming must balance machine time, storage space, programmer's time, and result accuracy; they all cost something [»turiA3_1951]

Subtopic: design diversity up

Quote: despite using a strong, centrally enforced methodology, there was no convergence of design concepts between separate implementations of the same specification [»demaT5_1989]
Quote: because software has few physical restrictions many design decisions resist objective analysis [»fowlM11_2001]

Subtopic: low-level design up

Quote: system designers and programmers need to understand program memory management; vast difference in performance [»hoarCA_1971]
Quote: be careful of functions in low-level subsystems; every application will pay for it; limited information to do job efficiently [»saltJH11_1984]

Subtopic: performance up

Quote: think about performance during design; pervasive architectural flaws can limit performance forever; changing a design later can produce an ill-structured sytsem [»blocJ_2001]

Subtopic: resources up

Quote: all operating system resources must be accounted for [»shapJS1_2002]

Subtopic: program family design up

Quote: SCV analysis -- establish Scope of the objects, exploit Commonalities; bound and accommodate Variability's [»coplJ11_1998]

Subtopic: engineering design up

Quote: each part of a design should serve several functions [»knutDE_1977, OK]

Subtopic: modular design up

Quote: a good design is made of building blocks which are separately testable [»postRM5_1987]
Quote: stage six of CADES structural modeling is formal definitions of each holon
Quote: Cleanroom designs are constructed by decomposing a specified function into control structures and subspecifications; never bottom-up [»lingRC10_1988]
Quote: a Cleanroom objective was simplifying designs; sometimes achieved a five-fold reduction in size [»lingRC10_1988]

Subtopic: design as problem solving up

Quote: problem solving by lexical (continuous->discrete), parsing (atoms->structure), modeling (structure->meaning), analysis (meaning->action) [»rossDT_1967]

Subtopic: design for error up

Quote: should over-design when the answer is unknown; a quarter of all bridges built in the 1870s collapsed within ten years [»bentJ3_1984]
Quote: the Brooklyn bridge is six times stiffer than necessary since aerodynamic lift was not understood [»bentJ3_1984]
Quote: the trade-off in structural engineering is been sufficient safety and economy [»abraP12_1986]
Quote: in designing a system, allow some unreliability to occur; perfection is too expensive [»akscRM5_1984]
Quote: constant tension between improving a design and providing stability and continuity [»lampBW10_1983]
Quote: handle normal and worst case separately; the normal case is fast and the worst case makes progress [»lampBW10_1983]

Subtopic: design tools up

Quote: use iContract for design-by-contract; easy to use [»jazeJM7_2001]

Subtopic: problems with functional design up

Quote: functional design of software leads to brittle systems that can not change easily [»boocG_1999]

Subtopic: problems of design up

Quote: the hardest part of building software is deciding what to build; the client does not know what he wants [»brooFP_1986]
Quote: human judgment in computer program design is invariably and seriously optimistic
Quote: software design is subject to wide interpretation; involve the customer in a formal way before final delivery

Group: program design up

Topic: CADES structural modeling with holons (24 items)
Topic: decomposition of a system into levels (49 items)
Topic: design languages (12 items)
Topic: data-driven design (41 items)
Topic: decision table (29 items)
Topic: design documentation (43 items)
Topic: design errors (15 items)
Topic: object-oriented design (30 items)
Topic: object-oriented modelling language (6 items)
Topic: pseudocode design (43 items)
Topic: stepwise refinement (25 items)
Topic: top-down vs. bottom-up design (30 items)
Topic: user-centered design
(65 items)

Related Topics up

Group: database model   (15 topics, 316 quotes)
Group: goals for a programming system   (21 topics, 983 quotes)
Group: program module   (10 topics, 336 quotes)
Group: requirement specification   (11 topics, 307 quotes)
Group: software engineering   (18 topics, 470 quotes)

Topic: abstract data type (64 items)
Topic: architecture (14 items)
Topic: automated tests of specifications and designs (12 items)
Topic: Cleanroom software development (38 items)
Topic: design for change (76 items)
Topic: program module as encapsulation (28 items)
Topic: executable code from specifications and designs (18 items)
Topic: good requirement specifications (36 items)
Topic: identifying program modules (26 items)
Topic: interface between program modules (55 items)
Topic: information hiding (50 items)
Topic: incremental development (74 items)
Topic: programming environment (46 items)
Topic: programming language design (53 items)
Topic: prototyping (18 items)
Topic: requirement specification by function (20 items)
Topic: software components (11 items)
Topic: software lifecycle (13 items)
Topic: software models of reality (24 items)
Topic: software review (80 items)
Topic: specification and design of distributed systems (14 items)
Topic: user interface design
(36 items)

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