This page is
updated to provide a summary for the CET
AUT
The aim of AUT’s technology for understanding is
to achieve rigorous development, documentation, and
communication
of understanding of any chosen subject matter
to the degree of completeness and precision required for any
stated purpose.
The understanding is to be acquired and judged by those skilled in the art of the subject matter (so that the investment in the costs of acquisition and use of that understanding are moderated and appropriate). To the extent allowed by information technology, the understanding also is to be delegated to man-machine systems
(a machine’s "understanding"
is evidenced by its function and behavior).
In particular, the resulting technological system for understanding is to be applied to its own development, documentation, and communication to result in a systematic technology for understanding that can and will be applied to its own evolutionary refinement, as well as to societal needs of all kinds.
New items here, and below.
The medium of expression used to develop and convey the documented understanding is the SADT Model of the Structured Analysis and Design Technique created by D.T.Ross with colleagues at SofTech, Inc. "SA" is the graphical language and DT is the Design Technique pragmatics of that language in use. Multiple SADT models, each one being of a subjective partial view of one and the same objective object (the system being studied) viewed from a different perspective and often for a different purpose. Here is an example of the box-and-arrow graphical language. The subject is Maintain Mount Rushmore (courtesy Triune Software). Click here to skip over all the pictures and their descriptions (But please scroll through them, as necessary, the first time.)
This example shows the full Publication format. Read the big diagram first, because that is where the definitive information is captured. The small figure, bottom right, will show the Parent Box of the larger Child Diagram which provides first-level detailing of the meaning of that parent. In this case those arrows are the boundary conditions for the entire model. The SA Text should "never describe" what already is better conveyed by the Picture Language Model (PLM) but should "tell a story" naturally highlighting items that might be overlooked. (This one gives background.)
The bounding arrows on each of the four sides of the parent box are imagined to be numbered from the top or left -- for (clockwise from the left side of the SA Box --) the Input, Control, Output, and Mechanism sides and the corresponding <letter+digit> ICOM codes then tag the free ends of the detail-diagram's boundary arrows to specify the interface connections of the child parts to make the whole. This is an SA Activity Model example, where the box-names are verb forms, and the arrow-labels are noun forms, modeling the Happenings and Things, respectively of the subject. In SA Data Modeling, the roles are exactly the reverse (noun boxes and verb arrows) with the syntax, semantics, and pragmatics of the two forms of modeling, "A" or "D" , below, being exactly the same.
The SA Text is to be read after independent reading of the diagram language, itself, with the Semantics being supplied by this Formal Saying that matches each SA Box:
Under ¯ ControlInput ® is transformed into ® Output
by the Ý Mechanism
-- where the inheritance comes from Parent to Children, of course. The augmenting of inheritance is via SA's Supported Calls, which are the graphical equivalent of specified-scope subroutine calls (with argument passing to a parameterized body) in modern programming languages. That is the means whereby the non-overlapping multiple viewpoints are interconnected, nonetheless -- but subatomically. [The viewpoint of a model always is the collection of the non-parent boxes (the atoms). This necessarily is true, starting with the topmost box (#0, notice) -- so by definition, two models only can interrelate subatomically and through this unique mating system of SA, they do -- sharing some ICOM arrow meanings from each of two parents, Caller and Called, deep within two different Subjective Views. SA Support is the branching distribution of M arrows to limit the calls to specified sub-locations.]
Here is one more level of detailing -- of Node A1: Maintain Sculpture to show more of how it works. This time apply the Formal Saying formally to understand a bit more deeply than your untutored (but mostly successful) first experience. Click here to skip over it in the future.
Unfortunately, this text does describe, in some parts. The SA Reference Language combines node numbers with ICOM codes to touch and trace relationships, see the Repair Plan, A1.2o1 to 2o1, for example. (The dot means "q.v." i.e. "which see" to have the A1 diagram in view.)
There is a further extension of the SA Language, called RSA Design Language (for Rigorous or Ross's SA). It allows the scheming aspects of design to be dealt with through Roadmaps of strategy and intent. Here (see below) arrow labels are individual subjects; gatherings of subjects are open circles; triangles denote structured documents such as manuals or SADT models, etc. Various operators can interconnect them with two kinds of connection: synaptic-gap/semantic connection in which meaning is mapped, but form may be different (and usually is) versus syntactic/structural connection in which both form and meaning correspond. All synaptic connection takes place through the SA Tie Process, in which the top-down node numbering of an SA model is contour mapped onto the structure of the tied document. The Tie Process depends upon the fact that Everything in the one-box Top of an SA model has been passed down to the atomic level, by definition. Hence, the meaning of any feature, arrow segment, or connection to a box (or sentence, paragraph, section, etc.) will penetrate as deeply down the inheritance tree as possible, either reaching an atom or stopping short, because it can't split to fit into more than one child box. The final success provides its proper node number, as that bit of the tie is completed, ready to consider another piece of meaning.
An Example of RSA Design Language use. Notice the use of synaptic/semantic gap connections and syntactic/structural connections. Circles are gatherings, with little structure, while triangles have Table, Outline, or SADT Model structure. As the arrow flows indicate, SA's
|
|
|
|
|
|
|
|
|
|
|
|
Quiz: Explain the exotic derived semantic constraint on both the Abstract Language Specification and the Language Specification, itself -- it derives from the mapping of the User Requirements onto the Functional Architecture of the system being designed.
"Concept Engineering"
A new term for the engineering discipline
that underlies the Technology for Understanding
that is the province of AUT, when applied.
Plex
The old name (1958?) for the scientific philosophy that underlies the RSA/SADT/IDEF0 modeling that is the subject of the "new look" at the Picture Language Modeling methodology that gives expression to Concept Engineering.
Everybody can participate in the benefits of Team
Understanding with SADT
There is a fully developed methodology for the use of SADT, but none of the existing toolsets or course offerings in the field really come close to the originally-intended rigor and completeness. Repeatedly, commercial or customer interests held sway. Although SADT originally was practiced by SofTech and a few clients, with both D and A Modeling in use (even though today's Call Syntax was not then known and SA's true semantics eluded all of us until recently), the ICAM Integrated Computer Aided Manufacturing contract-monitor customer of SofTech insisted that Data Modeling was too difficult for Industry use and banned it, placing the IDEF name ("ICAM Definition", originally, but politically "Integration Definition" in the Federal Information Processing Standard version IDEF0 -- even though Integration is not subject to Definition, for it can only be achieved, perhaps, through hard work! The correct name, voted down through ignorance and ignoring of the rump group still present, should have been "Integrated Definition" as an adjective construct for IDEF0 FIPS#183, IDEF1X FIPS#184, etc.) Those running the standardization efforts were latecomers, active when IDEF0 was being applied to DoD's Business Process Reengineering, in an effort to save many $Billions.
Nonetheless the following features derived from SofTech's extensive commercial experiences in the 1970s and 1980s and were incorporated into the IDEF0 documentation, along with most features of the language and many of the "Topic Sheets" of the original Author Guide of D.T.Ross.
For all my pains and complaints, a great many good people have done a lot of unequaled work on really important problems with this powerful expressive medium, over the years. Check out IDEF0 in Google or Altavista on the World Wide Web. It's just that, with the mathematical rigor finally provided by the Plex formalism, where everything is done by definitions, with no axioms or assumptions, and PLMs exhibit the interwoven details -- "it's ready for Prime Time," and could have saved MIT much grief in the Reengineering and introduction of SAP, in addition to its prospects for pedagogy.
Please do check out every link in the studentAUT website. There is very little about RSADT/AUT that is not covered -- including this example of a challenge in the field of Biology that I'd really like to see tried at MIT. (The challenge is in the multi-modeling and the first application of the modeling for a clear explanation of real before-to-after change of understanding of a natural phenomenon.)
And while it's not Shakespeare, for years I have said "I'd love to see a good SA model of the 19th Century American Novel." with the villain to hiss when he threatens the fair maiden. MIT's HASS and writing requirement can be fertile ground for all this.
All the definitive, prescriptive information in an SADT model is in the arrow labels. Box names are derivative and descriptive (and inordinately helpful to gaining good understanding) -- but they correspond to standard topic outlining! Mathematically (semantically) the box names even for the atoms can totally be omitted, which gives an appreciation for the severity of the way meaning of the terms used is interlocked and mutually constrained.
SADT/IDEF0 provides an integrated approach to
· Performing systems analysis and design at all levels for systems comprising people, machines, materials, computers, and information of all varieties — the entire enterprise· Producing documentation concurrent with development· Communicating by analysts, designers, users, managers
· Allowing coalition consensus to be achieved not by agreeing to disagree, but by common shared understanding
· Ensuring quality and configuration control via continuous review and approval
· Managing large and complex projects using quantitative and qualitative measures of progress
For teams to work effectively there must be
· Clear divisions of the problem· Well-defined interfaces· A way to integrate and interrelate their work
· A common language for communication
· Precise records of decisions
· Visibility
People fulfill various roles in the process:
· Experts with deep domain knowledge in technical, management, marketing, and business areas.· Authors who are trained to interview experts and express the results in well-structured models of the subject matter.
· Readers, who are trained in the reading rules for the models, including how to make terse comments on their correctness and effectiveness in communicating the subject matter. (Readers may be other authors, or experts, managers, and executives.)
· Technical and Management Review Committees spanning the full range of required expertise and responsibility to monitor (as Readers) and approve project progress and results.
· Project Librarian who circulates Reader Kits in the Reader/ Author Cycle, and maintains the project archives of all results and decisions.
Often a Project Model is used to specify and manage the project itself, making the roles and rules explicit, in the same way that SADT is used for the project work.
___________[Widen your view so centers align.]_______________________
SA is completely rigorous, and can be completely understood.
The whole networked structure of interlocked multiple models can be imagined to be projected down onto a plane, with all intermediate box boundaries missing, now they have done their job of well-strucuring all the details of the Structured Analysis, proper. Then blow up each interface arrow connection to make it hollow, exposing all the atom to atom connections that are the exclusive POSSIBILITIES OF REALIZABLE EVENTS. As with Petri Nets, assign markers to those that are real, rather than potential at an instant, and animate or simulate, as the case may be the result.
This observation also shows that every SA modeling has a defined meaning. If it is not what is desired, then the only recourse is to modify the modeling -- just like debugging software, or checking out equations.
In fact --
Just three Formal Sayings and a few picture fragments
fully define the semantics of the SA Language:
There is nothing hidden in the whole scheme. Every aspect is in the open.
The Model
Definition:
M models A to the extent that M correctly answers questions about A.The most basic model is a proper name for A.
By definition it includes All, but also it reveals Nothing, about A.
The Structured
Analysis Maxim:
Everything worth saying
About anything worth saying something about
Must be expressed in six-or-fewer pieces.
The pieces are the Structured Analysis Box:
with the Formal Saying: (for its semantics)
Under ¯ ControlInput ® is transformed into ® Output
by the Ý Mechanism— which augments the inherited means
Notice that of these three sayings, only this one has graphics, but the following purely-graphical Formal Showings [TBD] complete the job!
The missing pictures show a straight-through Stick of meaning-possibility passing, from the left, through the top of a hollow SA Arrow Shank while another stick below it departs bent and forking down -- to be replaced by its mirror image joining up and to the right, from below. That specifies the complete semantics of the branching (i.e. forking or joining) SA Arrows and how they bundle non-branching, primitive Sticks (of SA's "sticky blob semantics", that you see here). ICOM coding handles everything else.
For other graphic notations such as SA Tunneling of arrows down and up to and from "Rabbit Holes" in the diagram page, see the Background details.