1/10/00 4:36PM
Updated:1/27/00 4:31PM
These are the six SA Data diagrams that comprise the ICODE Object Model -- intended to be the generic model for any physical object, i.e. any object subject to physical laws (from plasmas to manufactured parts to living things). With careful change of terminology, it can model any rule-obeying object, as well -- with some features naturally degenerating, perhaps to nothing (as may be the case for work-hardening stress, frozen into a material, etc.).
The Object Model is a good example of a specific kind of SADT model, that, with its SA text, for guidance, is superior to ordinary Glossaries or technical dictionaries. All the box names and arrow labels are single words (or almost so) that are chosen for the subject at hand and are defined by their roles in the overall model -- which effectively is a concise theory of the subject. All of the terms used adjust in meaning to conform to the semantic constraints of the arrow structure, so that the whole collection yields a self-consistent viewpoint.
It is recommended that a reader start with a direct examination of the SA Diagrams, first, letting the flow of the arrows tell the story. Notice particularly their feedback Control loops (up and over to the tops of boxes) and feedback memory loops (down and back to the Input sides of boxes) -- sometimes shown as "dotted arrowheads" on two-way SA arrows which indicate cooperative interface action between boxes. Those are the paths that actually add structural constraints to the modeling. "Under Control, Input is transformed into Output by the Mechanism, which augments the inherited means." That is the key to SA semantics.
The Object also is a good example of "mixed parentage" SA multi-modeling. The first diagram shown is node number OBJ/D-1: COUPLINGS, in which each of five upper boxes is an SA Caller that seeks its detailing from the same SA Called box, named "OBJECT" at the bottom of the diagram. The arrows of the Caller are mapped as call arguments onto the arrows of the Called box (those that are not thus overridden remain as call parameters, but here many are unused). The Called box (#6) also is the supplied Support (#0, by definition) that allows the calls to be made. The D0:OBJECT Child Diagram provides all the details. Its #5 box REALIZATION Supports the four detailed siblings, but since their offspring all are Atomic (themselves having no more children) those further possible call prospects are not explored.
Three texts accompany the Object Model, referring to the following SA Diagrams by node number. If you call up six cascaded windows of your browser, sized to fit one diagram, and scroll to one diagram in each, in turn, you can follow the SA Reference Language traces up and down the hierarchy, to confirm the story of the texts. In the future, when up-to-date SA Support on the Web has been built, those traces will show as color highlighting, and the text may be oral, with animation -- but for now trace them visually yourself as you read.
The texts and the Object Model, itself, originated in the ICODE '79: A Progress Report on Foundations for ICODE by D. T. Ross, in Part II of the ICAM Project. "ICODE is the name given to a general scheme for the universal characterization, classification, an decoding of things. ... Objects have properties; things have characteristics. An... ICODE code is an information code, because of the generic Object Model, whereas classification codes are mere [uninterpreted] data codes." Here are the Sections of the ICODE report.
Section 5: PARTS, OBJECTS, AND THINGS
Section 6: FORMATION OF AN OBJECT
Section
7: A MANUFACTURING EXAMPLE (partial)
1/27/00 4:19PM
1/10/00 4:36PM