Методология структурного анализа и проектирования SADT. Глава 17

Дэвид А. Марка, Клемент МакГоуэн, Предисловие Дугласа Т. Росса

Часть IV Завершение моделирования. Руководство моделированием

В этой части книги обсуждаются методы, позволяющие определить, когда следует закончить моделирование, а также вопросы, связанные с подготовкой дополнительных материалов и управлением моделированием. Эти темы завершают изложение процесса построения функциональных SADT-моделей. Чтобы проиллюстрировать эти приемы, здесь приведены некоторые известные нам из личного опыта примеры координации работы группы SADT-аналитиков и рассмотрены такие понятия, как размер модели, размер папки, количество циклов рецензирования одной папки. Кроме того, в этой части книги обсуждаются средства компьютерной поддержки SADT, которые вселяют уверенность, что в будущем моделирование станет более производительным. Мы объединили всю эту информацию об управлении моделированием в одном месте, чтобы сделать ее более доступной для руководителей проектов прикладных систем.

В главе 17 приведен набор эвристик, которыми пользуются опытные SADT-авторы для определения достижения полноты модели и момента окончания моделирования. В главе 18 показано, как можно дополнить модель определением технических терминов, письменными материалами и рисунками. В главе 19 рассматривается техника сопровождения SADT-диаграмм примечаниями, которые позволяют уточнить количественные и качественные характеристики описываемой системы. В главе 20 дается обзор типичного процесса выполнения SADT-проекта. В главе 21 обсуждаются возможности доступных в настоящее время средств автоматизации проектирования в SADT и приводятся примеры их применения.

При изложении материала в этих главах мы обсуждаем оценки и критерии "хорошего" SADT-моделирования, т.е. критерии управления процессом. Мы не считаем эти характеристиками исчерпывающими. Скорее, это просто факты, взятые из проектов по моделированию в открытых областях или из нашего личного опыта и наблюдений. Они приводятся здесь для завершения обзора практических понятий, связанных с построением функциональной SADT-модели, и для перехода к детальному рассмотрению того, как на практике создается SADT-модель, что является предметом обсуждения в части V.

Глава 17. Завершение моделирования

Одна из наиболее частых проблем, возникающих в процессе реализации SADT-проектов, - когда же следует завершить построение конкретной модели? На этот вопрос не всегда легко ответить, хотя существуют некоторые эвристики для определения разумной степени полноты. В этой главе представлены правила, которыми пользуются опытные SADT-авторы для определения момента завершения моделирования. (Правила, относящиеся к нескольким взаимосвязанным SADT-моделям, не приведены здесь, потому что эта тема выходит за рамки данной книги.) Однако мы хотим предупредить, что приведенные здесь правила носят характер рекомендаций. Иногда даже опытные SADT-авторы, применив эти правила, обнаруживают впоследствии, что приняли неверное решение. Только длительная практика позволит вам приобрести знания, необходимые для принятия правильного решения об окончании моделирования.

17.1. Размер SADT-моделей

Прежде чем обсуждать критерии для определения завершения процесса моделирования, посмотрим, как увеличивается размер SADT-МОдели. С точки зрения математики размер иерархических моделей типа SADT-моделей увеличиваются со скоростью геометрической прогрессии. В табл. 17-1 показаны размеры полной четырехуровневой SADT-модели, каждая диаграмма которой состоит из четырех блоков, причем каждый из этих блоков декомпозируется аналогичной диаграммой.

В такой модели общее число блоков составляет 1365, а в четырехуровневой модели, содержащей по шесть блоков на диаграмме, общее число их - 9331.

Хотя с математической точки зрения все верно, SADT-модели такого размера никогда не создаются по целому ряду причин. Во-первых, ни одна SADT-модель не будет иметь одинаковую глубину. Обычно модель строится слоями, большинство из которых не

Таблица 17-1. Размер иерархических моделей увеличивается со скоростью геометрической прогрессии

являются глубокими. Чаще всего ограничиваются тремя уровнями. Опыт показывает, что, как правило, создаются несколько диаграмм второго и третьего уровней только для того, чтобы убедиться, что для достижения цели уже первый уровень содержит достаточно информации.

Однако типичной также является декомпозиция части SADT-модели на глубину 5-6 уровней. В этом случае на такую глубину декомпозируется обычно один из блоков диаграммы АО. Функции, которые требуют такого уровня детализации, часто очень важны, и их детальное описание дает ключ к секретам работы всей системы. Но хотя важные функции могут нуждаться в глубокой детализации, таких функций при создании одной модели насчитывается, как правило, немного. Модели, обладающие такими функциями, имеют обычно форму зонтика с широким тонким куполом и длинной ручкой, на которой происходит детализация. Поэтому вторая причина, по которой размер SADT-моделей не растет в геометрической прогрессии, заключается в том, что, хотя нередко модель имеет глубину 5-6 уровней, она почти никогда не декомпозируется вся до такой степени детализации.

Большие аналитические проекты обычно разбиваются на несколько отдельных более мелких проектов, каждый из которых создает модель одного конкретного аспекта всей проблемы. Поэтому вместо одной гигантской модели создаётся сеть из нескольких небольших моделей. Например, один аналитический проект, в котором принимали участие авторы этой книги, заключался в описании системы защитного оружия для подводной лодки. Вместо создания одной большой модели защищающей себя лодки мы использовали отдельные модели для описания каждого вида оружия (например, торпеды), защитного средства (например, ловушки), средства доставки (например, пускового орудия) и консоли оператора. Таким образом, вместо огромной, неуправляемой модели, которую было бы трудно прочесть и понять, была создана серия небольших, управляемых и понятных моделей. Однако последние замечания не должны вас обмануть. Исключительно большие проекты могут привести к созданию высококачественной модели, состоящей из тысяч блоков. Но это случается редко. К счастью, большинство систем не требует для адекватного описания моделей такой величины.

17.2. Прекращение декомпозиции

Мы рекомендуем прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Другими словами, вы должны закончить моделирование, когда почувствуете, что дальнейшее продвижение не будет удовлетворять информационные потребности проекта или вступит с ними в противоречие. Хотя интуитивно это правило понятно, ему трудно следовать, не оценив модель. В первое десятилетие использования SADT для создания моделей в различных прикладных областях были разработаны некоторые критерии для определения момента завершения моделирования. Этот опыт показал, что для отдельной модели, которая создается независимо от какой-либо другой модели, декомпозиция одного из ее блоков должна прекращаться, если:

  1. блок содержит достаточно деталей;
  2. необходимо изменить уровень абстракции, чтобы достичь большей детализации, блока;
  3. необходимо изменить точку зрения, чтобы детализировать блок;
  4. блок очень похож на другой блок той же модели;
  5. блок очень похож на блок другой модели;
  6. блок представляет тривиальную функцию.

Эти правила подчеркивают практические аспекты применения SADT для описания систем реального мира с конкретной целью (например, понять работу телефонной станции, чтобы определить требования к ее программному обеспечению). Предполагая, что большинство наших читателей будут применять SADT именно так, мы далее обсудим более подробно каждый из этих пунктов для иллюстрации приведенных правил и их важных моментов. Мы будем использовать диаграмму рис. 17-1, поскольку эта диаграмма находится на самом "дне" модели экспериментального механического цеха.

17.3. Достаточная детализированность

Одна из типичных ситуаций, встречающихся в конце моделирования, - это блок, который описывает систему с нужным уровнем подробности. Проверить достаточность деталей обычно совсем легко. Просто спросите себя, отвечает ли блок на все или на часть вопросов, составляющих цель модели. Если блок помогает ответить на один или более вопросов, то дальнейшая декомпозиция может не понадобиться.

Например, целью модели экспериментального механического цеха было достаточно полное описание работы механического цеха с представлением набора обязанностей, выполняемых его персоналом. В этой модели блок содержит достаточно деталей, если он описывает один из аспектов функции изготовить нестандартную деталь на таком уровне, что записанная процедура этого блока может быть понята и выполнена. Хорошей иллюстрацией сказанного служит блок разложить ручные инструменты , потому что его функция и связанные с ней объекты просты и достаточно определены, чтобы составить следующее описание.

Чтобы разложить ручные инструменты вначале просмотрите детали технических операций, чтобы определить, какие именно операции будут выполнены. Разложите ручные инструменты в порядке, соответствующем порядку выполнения операций. Учтите местоположение станка в цехе, чтобы инструменты оказались под рукой во время каждой операции.

Поскольку это описание, по-видимому, вполне удовлетворяет цели модели экспериментального механического цеха, мы не будем дальше декомпозировать блок разложить ручные инструменты. Текст является прекрасной заменой дальнейшей декомпозиции.

Рис. 17-1. Блоки, для которых нет необходимости в дальнейшей декомпозиции.

Если бы это была наша первая попытка закончить модель экспериментального механического цеха, мы бы использовали блок разложить ручные инструменты , его дуги и их метки как образец достаточной детализации. Затем мы бы оценили другие блоки на этой или будущих диаграммах, чтобы узнать, соответствуют ли они этому образцу. Если да, то они сразу рассматривались бы как кандидаты для параграфа текста, а не для декомпозиции. Например, блоки выбрать станок и наладить станок , по-видимому, имеют тот же уровень простоты, что и блок разложить ручные инструменты . Таким образом, SADT-автор создает набор критериев, позволяющих определить момент завершения конкретной модели, по мере того, как блоки нижних уровней начинают удовлетворять цели модели.

17.4. Изменение уровня абстракции

Блоки подвергаются декомпозиции, если они недостаточно детализированы для удовлетворения цели модели. Но иногда при декомпозиции блока выясняется, что диаграмма начинает описывать, как функционирует блок, вместо описания того, что блок делает. В этом случае мы говорим, что произошло изменение уровня абстракции. Таким образом, изменение уровня абстракции можно представить себе как изменения сути того, что должна представлять модель (т.е. изменение способа описания системы). В SADT изменение уровня абстракции часто означает выход за пределы цели модели и, следовательно, это указывает на прекращение декомпозиции.

Например, при попытке декомпозировать блок наладить станок возникают представления о таких действиях, как вращать, двигать, закреплять, поворачивать. Эти действия говорят о том, как наладить станок. Поэтому они лежат вне цели модели, являясь фактически частью описания обязанностей. Цель модели - понять работу механического цеха так, чтобы можно было дать описание всех обязанностей. В модели экспериментального механического цеха, если декомпозиция представляет собой описание обязанностей, блок не нужно декомпозировать. Декомпозицию заменяет абзац текста, описывающий обязанности одного из работников цеха:

Посмотрите на текущее расположение и высоту выбранного вами станка. Теперь опустите или поднимите его, чтобы вам было удобно работать. Затем измените его расположение, чтобы вы могли безопасно вставить, обработать и вынуть деталь. Может быть, для этого вам придется двигать, поворачивать или наклонять станок. Изучите устройство станка, прежде чем пытаться его налаживать.

Изменение уровня абстракции обычно происходит, когда модель уже имеет 2-3 уровня глубины, и их легко заметить. Небольшие изменения, однако, могут остаться незамеченными для автора. Обычно ошибки обнаруживаются в процессе рецензирования диаграмм. Свежий взгляд читательской аудитории определяет замену "что" на "как". Если изменение уровня абстракции не обнаружено во время цикла автор/читатель, то при следующей декомпозиции диаграммы оно обычно становится очевидным.

17.5. Изменение точки зрения

Изменение точки зрения происходит примерно так же, как изменение уровня абстракции. Это чаще всего характерно для ситуаций, когда точку зрения модели нельзя использовать для декомпозиции конкретного блока, т.е. этот блок можно декомпозировать, только если посмотреть на него с другой позиции. 06 этом может свидетельствовать заметное изменение терминологии.

Обратитесь к диаграмме ПС/А23 из приложения С и рассмотрите функцию прибыть в магази н - действие в рамках общей задачи покупки продуктов с целью накормить семью. Попытки разложить этот блок приведут к функциям типа сесть в автобус и поехать на такси , а также к объектам типа переход и автобусная остановка . Неожиданно в модель проникает новый набор терминов. Для того чтобы \ декомпозировать блок прибыть в магазин , мы должны рассматривать человека как нечто, подвергающееся перемещению посредством сложной системы транспорта, а не как кормильца семьи. Поскольку точка зрения изменилась, мы решаем не декомпозировать эту функцию. Это хороший пример, потому что он указывает на часто встречающиеся ситуации, которые сигнализируют о возможной замене точки зрения:

  • Вы находите трудным дальнейшую декомпозицию "хорошо понятого" блока без изменения точки зрения модели.
  • Для декомпозиции блока требуется совершенно новая терминология.
  • Декомпозиция описывает систему, не входящую в рассмотрение.

В каждом из таких случаев проверьте, входит ли ваша декомпозиция в модель. Если вы в этом не уверены, пошлите ее на рецензию с конкретной просьбой проследить за изменением точки зрения. Поскольку читательская аудитория обычно анализирует модель в разных аспектах, она - самый лучший источник информации при разрешении подобных проблем, возникающих в процессе моделирования.

17.6. Сходные функции

Иногда встречается блок, чрезвычайно похожий на другой блок модели. Два блока похожи, если они выполняют примерно одну и ту же функцию и имеют почти одинаковые по типу и количеству входы, управления и выходы. Если второй блок уже декомпозирован, то разумно отложить декомпозицию и тщательно сравнить два блока. Если нужны ничтожные изменения для совпадения первого блока со вторым, то внесение этих изменений сократит усилия на декомпозицию и улучшит модульность модели (т.е. сходные функции уточняются согласованным образом).

Рассмотрите блок выбрать станок на рис. 17-1 и блок выбрать инструменты на рис. 16-3. Оба они связаны с некоторым выбором из заданного множества устройств. Блок выбрать инструменты делает это, подчиняясь следующему шагу задания, а блок выбрать станок - подчиняясь чертежу. Более подробное изучение этих двух функций может открыть сходство между использованием информации о следующем шаге задания и чертежа. Если это произойдет, эти две функции могут быть далее декомпозированы как диаграмма выбрать инструменты .

Иногда такое изучение и модификация приводят к созданию функции более общего назначения (именно так происходит при введении подпрограмм, создаваемых для улучшения модульности программною обеспечения). Однако функции общего назначения часто трудно выделить, а модификации, необходимые для введения их в модель, требуют много времени. Поэтому мы, рекомендуя использовать при моделировании функции общего назначения, предупреждаем, что слишком высокая степень общности достигается с трудом и с большими затратами времени. Впрочем, мы надеемся, что в будущем автоматизированные средства SADT помогут аналитикам в решении этого и других важных вопросов, существенно улучшив качество моделей и сократив время их создания.

17.7. Тривиальные функции

Тривиальная функция - это такая функция понимание которой не требует никаких объяснений. В этом случае нам очевидна целесообразность отказа от декомпозиции, потому что роль SADT заключается в превращении сложного вопроса в понятный, а не в педантичной разработке очевидных деталей. Рассмотрим блок выбрать стано к на рис. 17-1. Его свободно можно считать тривиальной функцией, потому что рабочие прекрасно знают, какой станок больше подходит для определенного рода обработки металла. Поэтому этот "тривиальный" блок не следует декомпозировать, чтобы не обидеть рабочих. Разумно избегать декомпозиции тривиальных блоков, особенно в организациях, имеющих доступ к государственным секретам. В таких случаях декомпозиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста.

Следует заметить, что "тривиальный" не означает "бесполезный". Тривиальные функции выполняют очень важную роль, поясняя работу более сложных функций, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать тривиальные функции. Наоборот, их существование должно быть зафиксировано и они должны быть детализированы, как и любые другие функции. Однако мы хотим предостеречь читателя от больших затрат времени на анализ тривиальных функций системы. Усиленное внимание к мелочам может привести к созданию модели, которой будет недоставать абстракции, что сделает ее трудной для понимания и использования.

17.8. Принятие решения о завершении моделирования

Вероятность принятия неправильного решения о завершении моделирования может быть уменьшена, если вы оцените каждый блок, который хотите детализировать, в соответствии с приведенными выше правилами. Поскольку большинство SADT-моделей обычно содержат от 10 до 320 диаграмм, лучшее время для начала оценки блоков, когда модель достигает этих размеров. Если какая-то часть модели достигла уровня, не требующего дальнейшей декомпозиции, обращайтесь к своему собственному критерию для определения момента завершения моделирования, прежде чем декомпозировать блок, который еще не был детализирован.

Помните, что критерии, приведенные в этой главе, носят характер рекомендаций, следовательно, их нельзя применять механически. Иногда может случиться так, что в какой-то конкретной ситуации два правила будут противоречить друг Другу. Разрешение таких конфликтов требует рассудительности и осмотрительности. А это результат накопленного опыта. Если сложилась подобная ситуация и вы не знаете, что делать дальше, направьте на рецензирование специальную папку. Используйте цикл автор/читатель для привлечения наиболее опытных SADT-аналитиков, тех, кто с большей вероятностью даст вам дополнительную информацию для принятия обоснованного решения. Кроме того, мы советуем вести записи по сложным вопросам, по тому, как они были решены и что этому способствовало. Такие записи помогут вам впоследствии, если окажется, что моделирование следовало закончить раньше. Они помогут также при определении и выборе объектов будущего моделирования.

17.9. Резюме

SADT-модели иерархичны, и поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие SADT-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм и редко превосходят предел в 100 диаграмм. Декомпозиция модели или ее части немедленно прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Это происходит, когда модель достаточно подробна, чтобы ответить на все вопросы, которые включает цель модели, а также при изменении уровня абстракции или точки зрения. Кроме того, декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями, которые применяют SADT-аналитики для определения момента прекращения декомпозиции.

Дополнительная литература

  1. Alexander, С.: Notes on the Synthesis of Form, Harvard University Press, Cambridge, Mass., 1964.
  2. Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.
  3. Doczi, G.: "The Power of Limits", Shambhala Press, 1981.
  4. Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.
  5. Nishio, Т., and Nogi, K.: "A Stepwise Composition Technique for User Requirements Definition", International Workshop on Models and Languages for Software Specification and Design, University of Laval, Laval, Canada, March 1984.
  6. Ross, D.: "Principles of Structuring", SofTech Technical Paper no. 082, November 1978.
  7. Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.
  8. SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.
  9. SofTech, Inc.: "The DWS/CS Emergency Preset Structured Specification", Technical Paper no. 1083-1, August 1981.

Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=4466