I've added some potential definitions and other senses of these terms
which I found in the Programmer's Apprentice book and WCRE-93
("Challenges" paper proposes some definitions). All my suggestions
and additions are preceded by "L>".
Linda
========================
1. Architectural style: "defines a family of architectures constrained by
component/connector vocabulary, topology, semantic constraints. (Source:
Garland and Shaw tutorial)
2. Architecture: a system description, including system components and how
they interact.
3a. Cliche (as far as cliche recognition is concerned):
L> repeatedly used, standard, stereotypical computational pattern
L> (e.g., common algorithms and data structures) that has well-known
L> behaviors and properties.
L> -- may be a standard implementation for a well-known concept
L> -- may be a standard software behavior (like associative retrieval)
L> -- see 3c below for other examples
L> combinations of primitive mechanisms which engineers use frequently
L> because the combinations have been found useful in practice. From
L> experience, the engineers have come to expect these standard forms to
L> exhibit certain known behaviors.
L> WCRE: "a common pattern that is used over and over again."
L> -- emphasizes repeated use.
L> -- "embody standard, well understood, practice.
3b. Cliche (French): a pattern describing salient features of a concept that
supports recognition of that concept in some specified context by
application of some specified comparison algorithm.
3c. Cliche (as far as the Programmer's Apprentice is concerned): a collection
of related features or characteristics that provide a shared technical
vocabulary, including inter-feature relationships.
L> PA book, p. 4:
L> "... common software-engineering terms and concepts ... [which]
L> range from high-level requirement and design ideas, such as
L> *information system* and *command processor*, to low-level
L> implementation techniques, such as *balanced binary tree* and
L> *linear search*."
L> other examples:
L> associative retrieval -- standard software behavior
L> hashing, discrimination nets, association lists
L> -- standard implementation techniques
L> linear search
L> PA book, p. 6:
L> w/in general engineering context: "Inspection methods are based on
L> knowledge of commonly used combinations of components, called cliches.
L> These cliches form the bulk of the knowledge shared by expert
L> engineers in any domain."
L> examples: two-stage audio amplifier,
L> high-gain low-impedance amplifier,
L> multiplexing,
L> voltage divider
L> PA book, p. 11: "standard forms" recognized and used in inspection
L> methods are called cliches. The idea is to be able to recognize the
L> standard form and then reason about its well-known properties
L> directly, rather than from first principles.
4. Concept hierarchy: a hierarchically organized collection of domain
concepts. The organizing relationship is "part-of".
5. Conceptual purpose token: a domain concept identifier
6. Delocalized plan: "pieces of code that are conceptually related [that] are
physically located in non-contiguous parts of a program." (Source:
Soloway, et al. CACM 11/88)
7. Design recovery: "a subject of reverse engineering in which domain
knowledge, external information, and deduction or fuzzy reasoning are
added to the observations of the subject system to identify meaningful
higher level abstractions beyond those obtained directly by examining the
system itself." (Source: Chikofsky and Cross)
8. Domain: a recognized problem area characterized by a vocabulary, typical
solution strategy (architecture), and literature.
L> WCRE: "domain model -- a compendium of information about a
L> particular application domain, rather than about programming."
L> -- contains domain-specific cliches
9. Domain Specific Software Architecture: an architecture that denotes how
problems in a specific domain are typically solved.
10. Interleaving:
L> the merging two or more [logically/functionally] distinct,
L> computational fragments in such a way that some resource is shared.
L> Characteristics:
L> - resource sharing
L> - multiple distinct functions/roles/purposes are being performed
L> - delocalization (usually each component that is interleaved is delocalized)
L> 10a. Accidental interleaving:
11. Model: a cognitive abstraction of a software system
L> This could have a variety of definitions. Are we talking
L> specifically about domain models?
12. Plan: "Knowledge structures that are schematic representation of
stereotypical behavior patterns. ... Correspondingly, plans in programs
are stereotypic action structures." (Source: Soloway, et al. CACM 11/88)
L> From WCRE:
L> "An abstract representation for one or more aspects of the design of
L> a program (or anything else), analogous to the plan for a building.
L> The key intuition is that a plan highlights some pieces of
L> information while discarding others."
L> - abstract nature
L> - not necessarily stereotypical
L> - not necessarily used repeatedly. (cliches are frequently
L> occuring plans)
L> - a plan is an abstract representation of a program, while a
L> cliche is a commonly occuring plan that can be recognized in the
L> plan representing a given program.
13. Program Comprehension: the process of acquiring knowledge about a computer
program. (Source: Rugaber, Encyclopedia article)
L> Sounds good. However, it seems like you need to say something about
L> the kind of knowledge that is recovered and how it is used.
L> Not all processes of acquiring knowledge would be considered program
L> comprehension (e.g., collecting test results, finding out who wrote
L> some part of the program).
14. Reengineering: "the examination and alteration of a subject system to
reconstitute it in a new form and the subsequent implementation of the new
form." (Source: Chikofsky and Cross)
15. Representation: tangible (non-cognitive) abstraction of a software system.
L> WCRE's definition of "plan"? (See # 12)
L> What's "cognitive/non-cognitive"?
16. Restructuring: the transformation of one representation form to another
at the same relative abstraction level, while preserving the subject
system's external behaviour (functionality and semantics)." (Source:
Chikofsky and Cross)
17. Reverse Engineering: "the process of analyzing a subject system to identify
the system's components and their interrelationships and create
representations of the system in another form or at a higher level of
abstraction." (Source: Chikofsky and Cross)
18. Role: a relatively self contained subarchitecture (in the sense that a
subsequence is related to a sequence).
19. Signature: The set of features (e.g., syntax, semantic, graphical) that
together signal the occurrence of a specific concept. (Source:
Biggerstaff, CACM)
-- -Linda Wills (linda@cc.gatech.edu)