Topic: decomposition of a system into levels

topics > computer science > programming > Group: program design

operating system
program module

abstract data type
abstraction in programming
program module as encapsulation
communication protocols
design for change
families of programs
handling complexity
hierarchical structures
identifying program modules
interface between program modules
information hiding
localized understanding
non-hierarchical classification and multiple classification
semantics by an abstract machine
software portability
stepwise refinement
top-down vs. bottom-up design
understanding systems
the 'uses' hierarchy for organizing systems
virtual machine

Subtopic: levels of abstraction up

Quote: successful, large systems tend to be organized in layers or levels of abstraction
Quote: a good design models some aspect of reality. Concepts are classes with inheritance to show relationships. Multiple levels of abstraction [»stroB_1991]
Quote: resource allocation should be organized in levels of abstraction with minimal dependencies between levels
Quote: lowest robot level avoids objects, next layer makes robot wander about, third level encourages exploration [»brooRA1_1991]
Quote: with a structured flow chart can fold the paper to show an abstraction level

Subtopic: layers as abstraction up

Quote: structure an operating system as layers of insensitive, abstract machines
Quote: each operating system level manages a particular type of abstract object [»robiL9_1975]
Quote: CADES design is a series of levels; each level an abstract machine [»pearDJ7_1973]

Subtopic: specification vs. implementation up

Quote: a design level tells what must be done by the lower level and how to implement the higher level [»neugW_1982]
Quote: every specification is an implementation of a higher level specification
Quote: good interfaces allow low-level details to change without effecting the higher levels [»rossDT_1970]
Quote: digital computers allow many representational layers; a variable may represent a satellite and in turn be represented by a voltage [»winoT_1986]
Quote: 2-level van Wijngaarden grammars define meta rules that generate BNF rules [»kostCH_1974a, OK]

Subtopic: data vs. code up

Quote: level principle--active entities at one level are data structures at a lower level; e.g., process vs. context block [»finkRA_1986]

Subtopic: reduce dependencies up

Quote: Cedar uses system layering to reduce compilation dependencies and increase use of system components [»swinDC7_1985]
Quote: separate the presentation code from domain code; the UI should only display information [»fowlM3_2001]

Subtopic: design levels up

Quote: stage three of CADES structural modeling is defining the system's levels and functions [»pearDJ7_1973]
Quote: the 'context' layer in Conniver's database shows differences from previous layers [»mcdeDV9_1975]
Quote: an electronic test system may have many levels of specification, e.g., run smoothly, rpms, voltage [»cheaTE_1976]
Quote: the top-down designer creates tree structures; at a level with no shared components [»jackMA_1975]

Subtopic: portability up

Quote: portability may measure the representation level of a program; e.g., octal code is not portable [»cbb_1973, OK]
Quote: using MacApp for Intermedia, guarantees common functionality
Quote: one programs for a virtual machine defined by hardware and other software [»parnDL8_1971]

Subtopic: execution hierarchy up

Quote: have ten orders of magnitude between program execution in hours and instruction execution in a microsecond; must have intermediate levels [»dijkEW10_1972]
Quote: hierarchy allows large and complex programs out of simple components; complexity only through number of components and levels [»jackMA_1975]
Quote: need intermediate levels between a program's execution and an instruction's execution; about a 10^10 ratio; bricks to walls is maybe 10^3
Quote: a programmer must bridge a 10^9 ratio in time and space with a single technology; much deeper conceptual hierarchy than ever before [»dijkEW12_1989]
Quote: each level of a hierarchy represents a doubling or more in size; small and medium systems have few levels [»dijkEW10_1972]
Quote: the minimum number of layers in a system is a high-level programming language and hardware; the operating system can be eliminated [»ingaDH9_1982]
Quote: a vast amount of code is required to realize a programmer's intent, often concisely stated [»laruJR5_2004]
Quote: use correctness tools to close the immense gap between code and intent

Subtopic: communication stack up

Quote: end-to-end argument--implement functions at the endpoints of a communication system; do not implement within the communication system unless needed for efficiency [»saltJH11_1984]
Quote: be careful of functions in low-level subsystems; every application will pay for it; limited information to do job efficiently [»saltJH11_1984]

Subtopic: user programs, tasks up

Quote: assign user programs to reserved processes; do not charge time spent in critical sections [»dijkEW2_1971]
Quote: organize a layer as tasks made of subroutines; all interfaces are subroutine calls instead of intertask communication [»clarDD12_1995]

Subtopic: communication between levels up

Quote: subsumption architecture for intelligent robots: fixed-topology layers of finite state machines; higher layers can replace or inhibit messages of lower layers [»brooRA1_1991]
Quote: collision control where higher levels restrict free parameters of lower levels [»freuE_1984]
QuoteRef: robiL9_1975 ;;2 levels of abstract machines which only access one level away. Level either transparent to feature or hides feature

Subtopic: exception processing from higher-level up

Quote: lower levels can't use knowledge about higher levels; but undesired events need higher level information to determine the appropriate action [»parnDL10_1976b]
Quote: a reported undesired event indicates a failure of the previous level's abstract machine
Quote: an undesired event may be propagating downward (i.e., violating virtual machine restrictions) or upward (i.e., reported by lower level) [»parnDL10_1976b]

Subtopic: up-call up

Quote: use up-calls to transfer incoming network data, user input, or status changes to higher level processes; avoids context switches; used for high-performance networks [»birrAD_1991]
Quote: an upcall calls a higher level function across protection boundaries; an alternative to asynchronous signals [»clarDD12_1995]
Quote: upcalls usually call a higher level function through a procedure variable
Quote: rewriting a downcall protocol as upcalls improved performance and code size by 5-10x [»clarDD12_1995]
Quote: an upcall may asks questions about its service; e.g., ask for further data to append to an outgoing packet [»clarDD12_1995]
Quote: with upcalls, need to separate client data from the level's data; the later must be consistent and unlocked before an upcall occurs [»clarDD12_1995]
Quote: with upcalls, need to either disallow recursive downcalls, restrict downcalls to simple actions/queuing, or restrict downcalls to setting flags [»clarDD12_1995]

Subtopic: problems with layers up

Quote: layered abstractions increase the stack data cache footprint, TLB misses, and function call overhead; too many arguments; spectacularly deep call stacks

Related Topics up

Group: operating system   (27 topics, 924 quotes)
Group: program module   (10 topics, 336 quotes)
Group: systems   (17 topics, 530 quotes)

Topic: abstract data type (64 items)
Topic: abstraction (62 items)
Topic: abstraction in programming (67 items)
Topic: program module as encapsulation (28 items)
Topic: classification (65 items)
Topic: communication protocols (62 items)
Topic: design for change (76 items)
Topic: families of programs (11 items)
Topic: handling complexity (60 items)
Topic: hierarchical structures (46 items)
Topic: identifying program modules (26 items)
Topic: interface between program modules (55 items)
Topic: information hiding (50 items)
Topic: localized understanding (43 items)
Topic: non-hierarchical classification and multiple classification (16 items)
Topic: outlines (16 items)
Topic: semantics by an abstract machine (38 items)
Topic: software portability (43 items)
Topic: stepwise refinement (25 items)
Topic: taxonomy (16 items)
Topic: top-down vs. bottom-up design (30 items)
Topic: understanding systems (48 items)
Topic: the 'uses' hierarchy for organizing systems (18 items)
Topic: virtual machine
(13 items)

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