2015-05-18
174
Дуги выражают связи между блоками. Их вычерчивают не для показа последовательности действий. Они отражают отношения между блоками, независящие от потенциального следования. Например, диаграмма на рис. 9-2 не указывает возможной последовательности действий. В частности, функции выбрать инструменты может как встретиться, так и не встретиться перед функцией подготовить рабочее место. Это зависит от того, каким является следующий шаг задания. Если же оборудованное рабочее место уже создано, блок обработать на станке и собрать может выполняться неоднократно, пока не возникнет потребность в выполнении следующего шага задания. Такой механизм приводит к реализации различных сценариев, активизируя блоки в различные моменты времени в зависимости от ситуации.
Может случиться, что, начав рисовать дугу, вы засомневаетесь в том, что она нужна на диаграмме. Не изобразив дугу при первом наброске диаграммы, вы рискуете совершить ошибочный пропуск. Поскольку SADT-диаграммы всегда проверяются другими специалистами и поскольку отсутствующую дугу никто не сможет обнаружить, изъятие сомнительной дуги с диаграммы — прямая дорога к возникновению ошибок и отсечению дополнительных возможностей. Мы рекомендуем включать сомнительные дуги в диаграмму с вопросом об их необходимости адресованным читателям. Полученные в ответ комментарии скорее всего помогут разрешить ваши сомнения. SADT-дуги представляют собой наборы объектов и поэтому они потенциально могут нести много данных. Например, сырье может быть просто стальным бруском, а может быть листами, рулонами, кусками дерева, пластика или различных металлов. Опытные SADT-анали-тики не изображают каждый объект отдельной дугой. В крайнем случае мы советуем давать определение новой дуги в глоссарии и, возможно, уточнять ее содержимое при декомпозиции тех блоков, которых она касается. Таким образом, вы предоставите читателям достаточно информации для понимания вашей диаграммы и не потратите много времени на избыточно подробное описание модели на слишком ранней стадии, что неизбежно привело бы в дальнейшем к большим переделкам.
|
|
|
Резюме
Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы. В процессе декомпозиции целесообразно проверять ICOM-коды, потому что при моделировании весьма распространены ошибки интерфейса. Старайтесь включать сомнительные блоки или дуги в диаграммы, фиксируя свои сомнения посредством записей. Это укажет читателям, что вам нужна помощь в решении данной проблемы.
|
|
|
Дополнительная литература:
· Alexander, С.: Notes on the Synthesis of form, Harvard University Press, Cambridge, Mass., 1964.
· Miller, G.: "The magical Number Seven, Plus Or Minus Two: Some Limits on Our Capacity for Information Processing", Tbe Psychology Review, vol. 63, no. 2, March 1956.
· Parnas, D.: "On the Criteria to be Used in Decomposing Systems into Modules", CACM, December 1972.
· Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.
· Ross, D.: "Principles of Structuring", SofTech Technical Paper no. 082, November 1978.
· Rubinsteine, M.: Patterns of Problem Solving, Prentice-Hall, Englewood Cliffs, N.J., 1975.
· SofTech, Inc.: "IDEFO Author’s Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.
· SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech,Inc., 1981.
· Thomas, M.: Functional Decomposition: SADT", InfoTech State of the Art Report on Structured Analysis and Design, 1978.
