|
|||||||||
|
|||||||||
|
|
|
|
|
|
|
|
|
|
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.
A new term for the engineering discipline
that underlies the Technology for Understanding
that is the province of AUT, when applied.
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.
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.
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.
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.