Applications and Extensions of SADT
暂无分享,去创建一个
Embodying an organized discipline of thought and action, the SADT methodology has been successful in many applications previously thought too nebulous for technical treatment. At the time the definitive papers on SADT,* Sofrech's Structured Analysis and Design Technique, were published in 1977,1-3 the methodology had been in extensive development and use for several years. Originally introduced as a "system-blueprinting" method for documenting the architecture of large and complex systems,4 SADT had become a full-scale methodology for coping with complexity through a team-oriented, organized discipline of thought and action, accompanied by concise, complete, and readable word and picture documentation. SADT broke new ground in the areas of problem analysis, requirements definition, and functional specification because it allowed rigorous expression of high-level ideas that previously had seemed too nebulous to treat technically. In the seven years since its introduction, SADT and its derivatives and extensions have been successfully applied to hundreds of major projects in a very broad range of application areas. An overview of this application experience and a look toward the future development of SADT are the subjects of this article. What is SADT? SADT consists of two principal parts: (1) the box-and-arrow diagram-*SADT is a trademark of SofTech, Inc. ming language of structured analysis and (2) the design technique, which is the discipline of thought and action that must be learned and practiced if the language is to be used effectively. Both parts are intimately related. Without the simplicity, generality, readability, and rigor of the SA dia-gramming language, the important ideas of the DT methodology would not be sufficiently visible and tangible to be of any coherent use. But without the DT discipline, those same language features of SA would make it almost useless (so much so that in 1977 Softech laid proprietary claim to its methodology, even while placing all the specifics of the SA language in the public domain). The situation would be much like knowing the rules and notation of algebra (capable of extensive calculation in almost any domain) without having any guidance or experience in translating word problems into properly formulated expressions. Neither SA nor SADT solves problems. Both are tools that allow people to express, understand, manipulate, and check problem elements in ways previously not possible. All of SADT stems from a single premise: The human mind can accommodate any amount of complexity as long as it is presented in easy-to-grasp chunks that together …
[1] Sol Jaffe Greenspan,et al. Requirements modeling: a knowledge representation approach to software requirements definition , 1984 .
[2] Douglas T. Ross,et al. Structured Analysis for Requirements Definition , 1977, IEEE Transactions on Software Engineering.
[3] Douglas T. Ross,et al. Structured Analysis (SA): A Language for Communicating Ideas , 1977, IEEE Transactions on Software Engineering.