Map
Index
Random
Help
Group
th

Group: program module

topics > computer science > Group: programming



Topic:
deployable module or assembly
Topic:
program module as encapsulation
Topic:
families of programs
Topic:
identifying program modules
Topic:
import/export lists for defining an interface
Topic:
interface between program modules
Topic:
information hiding
Topic:
representation data type
Topic:
separate a module's interface specification from its implementation
Topic:
the 'uses' hierarchy for organizing systems
Group:
data type
Group:
object-oriented programming
Group:
requirement specification

Topic:
abstract data type
Topic:
CADES structural modeling with holons
Topic:
data type as a set of values and a set of operations
Topic:
decomposition of a system into levels
Topic:
incremental development
Topic:
local declaration of data
Topic:
localized understanding
Topic:
notation for program clusters
Topic:
object-defined names
Topic:
object-oriented classes
Topic:
object-oriented modelling language
Topic:
object-oriented packages
Topic:
programming with a database of modules
Topic:
security by access functions
Topic:
system builds

Summary

The original name for a module or class was "cluster". A cluster is a collection of operations and data representations used for abstracting a data type. Outside the cluster, the data type's representation is accessed only through the cluster's operations. Operations may be defined in terms of a base language, in terms of message processing, or in terms of other clusters. Cluster design and integration requires skilled programmers. Clusters may be a data type for defining a class of objects or they may be a data object with local variables and multiple instances.

A cluster has an external definition which defines its public aspects and an internal definition which defines its implementation. The external definition defines a set of compound names for accessing the cluster. The internal definition includes initialization routines, internal variables, object representations, and the implementation of public and private operations. (cbb 5/80)

The idea of a program cluster may be artificial because there is no clearly defined way to decompose a program into clusters or modules. The goal is certainly right but the variability is too great. The only real units appear to be instructions and data objects. But then interface and implementation become intertwined. Anything in the abstract data type 'list' aught to be sorted. But this is only true if sort has been implemented. i.e., specifying a type by its operations is really an argument for consistent naming of those operations. (cbb 1/90)

Subtopic: module composition up

Quote: data abstraction leads to programs as a collection of types, composing modules instead of individual procedures [»guttJV_2002]

Subtopic: module guide document up

Quote: a module guide defines how work will be divided into work assignments
Quote: a module guide states the design decisions that will be encapsulated by each module [»parnDL2_1986]
Quote: a module design document records the major design decisions for design reviews and documentation [»parnDL2_1986]

Subtopic: program cluster up

Quote: a Russell capsule defines a type as a collection of operations, types, schemes, and fields [»demeA3_1979]
Quote: a CLU cluster consists of operation interfaces, internal representation of objects, and definition of operations [»liskBH2_1976, OK]
Quote: ESL uses clusters for user extensions and to implement its set language using its base language [»katzJ5_1979, OK]
QuoteRef: ichbJD_1973 ;;167 in LIS, have SCHEMA... which is a cluster

Subtopic: abstraction for naming up

Quote: a type module is an abstraction of naming; its execution introduces new names [»hehnEC7_1975]


Group: program module up

Topic: deployable module or assembly (12 items)
Topic: program module as encapsulation (28 items)
Topic: families of programs (11 items)
Topic: identifying program modules (26 items)
Topic: import/export lists for defining an interface (20 items)
Topic: interface between program modules (55 items)
Topic: information hiding (50 items)
Topic: representation data type (21 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: the 'uses' hierarchy for organizing systems
(18 items)

Related Topics up

Group: data type   (34 topics, 730 quotes)
Group: object-oriented programming   (26 topics, 822 quotes)
Group: requirement specification   (11 topics, 307 quotes)

Topic: abstract data type (64 items)
Topic: CADES structural modeling with holons (24 items)
Topic: data type as a set of values and a set of operations (16 items)
Topic: decomposition of a system into levels (49 items)
Topic: incremental development (74 items)
Topic: local declaration of data (11 items)
Topic: localized understanding (43 items)
Topic: notation for program clusters (4 items)
Topic: object-defined names (15 items)
Topic: object-oriented classes (67 items)
Topic: object-oriented modelling language (6 items)
Topic: object-oriented packages (6 items)
Topic: programming with a database of modules (94 items)
Topic: security by access functions (10 items)
Topic: system builds
(43 items)


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