47613

МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ SADT

Книга

Информатика, кибернетика и программирование

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

Русский

2013-12-01

1.17 MB

41 чел.

Дэвид А. Марка и Клемент МакГоуэн

Предисловие Дугласа Т. Росса

МЕТОДОЛОГИЯ

СТРУКТУРНОГО

АНАЛИЗА И ПРОЕКТИРОВАНИЯ

SADT

Structured Analysis & Design Technique

[1]
Введение

[2]
Предпосылки создания SADT

[3]
Часть I Принципы функционального моделирования

[4]
Глава 1. Системы и модели

[4.1] 1.1. SADT-модели

[4.2] 1.2. Модель отвечает на вопросы

[4.3] 1.3. Модель имеет единственный субъект

[4.4] 1.4. У модели может быть только одна точка зрения

[4.5] 1.5. Модели как взаимосвязанные наборы диаграмм

[4.6] 1.6. Резюме

[5]
Глава 2. Синтаксис и применение диаграмм

[5.1] 2.1. Диаграммы содержат блоки и дуги

[5.2] 2.2. Блоки представляют функции

[5.3] 2.3. Блоки имеют доминирование

[5.4] 2.4. Дуги изображают объекты

[5.5] 2.5. Дуги изображают взаимосвязи между блоками

[5.6] 2.6. Дуги представляют наборы объектов

[5.7] 2.7. Идентификация версий диаграмм С-номерами

[5.8] 2.8. Резюме

[6]
Глава 3. Синтаксис моделей и работа с ними

[6.1] 3.1. Система представляется одним блоком

[6.2] 3.2. Идентификация декомпозиции номерами узлов

[6.3] 3.3. Связывание декомпозиции с помощью С-номеров

[6.4] 3.4. Коды ICOM гарантируют стыковку диаграмм

[6.5] 3.5. Обозначения для менее распространенных интерфейсов по дугам

[6.6] 3.6. Резюме

[7] Глава 4. Процесс моделирования

[7.1] 4.1. Получение знаний в процессе опроса

[7.2] 4.2. Документирование полученных знаний

[7.3] 4.3. Корректность модели проверяется в процессе итеративного рецензирования

[7.4] 4.4. Координация процесса рецензирования

[7.5] 4.5. Модели используются после их одобрения

[7.6] 4.6. Резюме

[8] Глава 5. Более глубокие концепции диаграмм

[8.1] 5.1. Дуги имеют различное содержание

[8.2] 5.2. Дуги могут быть декомпозированы

[8.3] 5.3. Дуги могут быть "помещены в тоннель"

[8.4] 5.4. Различие между входными дугами и дугами управления

[8.5] 5.5. Дуги механизмов определяют способы реализации функций

[8.6] 5.6. Обратная связь по управлению и по потоку данных

[8.7] 5.7. Резюме

[9]
Глава 6. Более глубокие концепции моделей

[9.1] 6.1. Модели SADT структурируют естественный язык

[9.2] 6.2. Точка зрения модели влияет на расстановку акцентов и терминологию

[9.3] 6.3. Декомпозиция в ходе моделирования

[9.4] 6.4. Некоторые стратегии декомпозиции

[9.5] 6.5. Выбор стратегии декомпозиции

[9.6] 6.6. Момент прекращения декомпозиции определяется точностью

[9.7] 6.7. Резюме

[10]
Часть II Создание функциональных моделей и диаграмм

[11]
Глава 7. Сбор информации

[11.1] 7.1. Источники информации

[11.2] 7.2. Типы опроса

[11.3] 7.3. Процесс опроса

[11.4] 7.4. Что нужно помнить при опросе

[11.5] 7.5. Резюме

[12]
Глава 8. Начало моделирования

[12.1] 8.1. Основные этапы

[12.2] 8.2. Выбор цели и точки зрения

[12.3] 8.3. Составление списка данных

[12.4] 8.4. Составление списка функций

[12.5] 8.5. Построение диаграммы АО

[12.6] 8.6. Обобщение диаграммы АО

[12.7] 8.7. Резюме

[13]
Глава 9. Продолжение моделирования

[13.1] 9.1. Декомпозиция ограниченного объекта

[13.2] 9.2. Выявление интерфейсных ошибок

[13.3] 9.3. Принципы и приемы расположения дуг

[13.4] 9.4. Резюме

[14] Глава 10. Проверка диаграммы автором

[14.1] 10.1. Процесс авторской проверки

[14.2] 10.2. Выявление недостатков новой диаграммы

[14.3] 10.3. Создание альтернативных декомпозиций

[14.4] 10.4. Корректировка новой диаграммы

[14.5] 10.5. Исправление взаимосвязанных диаграмм

[14.6] 10.6. Резюме

[15]
Глава 11. Соглашения по построению диаграмм

[15.1] 11.1. Соглашения по размещению блоков

[15.2] 11.2. Соглашения по размещению дуг

[15.3] 11.3. Соглашения по размещению блоков и дуг

[15.4]
11.4. Резюме

[16]
Часть III Рецензирование диаграмм и моделей

[17]
Глава 12. Цикл автор/читатель

[17.1] 12.1. Составление исходной документации

[17.2] 12.2. Комментирование работы

[17.3] 12.3. Ответы на комментарии

[17.4] 12.4. Совершенствование моделей

[17.5]
12.5. Цикл автор/читатель

[17.6] 12.6. Резюме

[18]
Глава 13. Подготовка папки

[18.1] 13.1. Обмен информацией с помощью папок

[18.2] 13.2. Титульный лист

[18.3] 13.3. Организация папки

[18.4] 13.4. Размеры папки

[18.5] 13.5. Когда формировать папку

[18.6] 13.6. Резюме

[19] Глава 14.Чтение диаграмм и моделей

[19.1] 14.1. Процедура чтения

[19.2] 14.2. Изучение деталей диаграммы

[19.3] 14.3. Изучение ближайшего контекста диаграммы

[19.4] 14.4. Уточнение места диаграммы в модели

[19.5] 14.5. Критическая оценка содержания диаграммы

[19.6] 14.6. Резюме

[20]
Глава 15. Конструктивное комментирование

[20.1] 15.1. Запись о продолжительности работы

[20.2] 15.2. Проверка заполнения полей бланка диаграммы

[20.3] 15.3. Обозначения согласия и несогласия с автором

[20.4] 15.4. Замечания

[20.5] 15.5. Язык ссылок SADT

[20.6] 15.6. Повторное чтение папки

[20.7] 15.7. Конструктивная критика

[20.8] 15.8. Резюме

[21] Глава 16. Ответы на комментарии и их обобщение

[21.1] 16.1. Чтение и ответы на замечания

[21.2]
16.2. Беседа автор/читатель

[21.3] 16.3. Обобщение читательских комментариев

[21.4] 16.4. Переделка диаграмм

[21.5] 16.5. Резюме

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

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

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

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

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

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

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

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

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

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

[23.9] 17.9. Резюме

[24]
Глава 18. Дополнения к диаграммам и моделям

[24.1] 18.1. Дополнения к диаграммам

[24.2] 18.2. Определение терминологии с помощью глоссария

[24.3] 18.3. Пояснение содержания с помощью текста

[24.4] 18.4. Пояснение с помощью рисунков

[24.5] 18.5. Дополнение моделей

[24.6] 18.6. Резюме

[25] Глава 19. Примечания на диаграммах и моделях

[25.1] 19.1. Информация о свойствах

[25.2]
19.2. Правила действия

[25.3] 19.3. Генерация правил действия

[25.4] 19.4. Резюме

[26] Глава 20. Управление проектом

[26.1] 20.1. Начало проекта

[26.2] 20.2. Создание и рецензирование результатов работы

[26.3] 20.3. Создание модели

[26.4] 20.4. Стратегии дополнения модели

[26.5] 20.5. Резюме

[27] Глава 21. Средства автоматизации

[27.1] 21.1. AUTOIDEFO

[27.2] 21.2. SPECIF_X

[27.3] 21.3. Design/IDEF

[27.4] 21.4. Сводный список для оценки автоматизированной поддержки SADT

[27.5] 21.5. Резюме

[28] Часть V Создание функциональной модели и спецификации. Уроки

[28.1] Модель "Питание семьи"

[28.2] Рекомендации для преподавателей

[29]
Глава 22. Начало моделирования

[29.1]
урок 1. Очерчивание границ объекта

[29.2]
урок 2. Определение цели и точки зрения модели

[29.3]
урок 3. Построение диаграммы верхнего уровня

[29.4]
урок 4. Обобщение диаграммы верхнего уровня

[29.5]
Урок 5. Критическая оценка обобщающей диаграммы

[29.6]
урок 6. Критическая оценка диаграммы верхнего уровня

[29.7]
урок 7. Переделка обобщающей диаграммы и диаграммы верхнего уровня

[30] Глава 23. Построение декомпозиции первого уровня

[30.1]
урок 8. Групповое построение диаграмм

[30.2]
урок 9. Критическая оценка декомпозиции первого уровня

[30.3]
урок 10. Подготовка папки

[31] Глава 24. Разделение интерфейсов верхнего уровня

[31.1]
урок 11. Групповое комментирование

[31.2]
урок 12. Реагирование группы

[31.3]
урок 13. Переделка диаграммы верхнего уровня

[31.4]
урок 14. Переделка декомпозиции первого уровня

[32] Глава 25. Создание декомпозиции второго уровня

[32.1]
урок 15. Индивидуальное построение диаграмм

[32.2]
урок 16. Критическая оценка декомпозиции второго уровня

[32.3]
урок 17. Индивидуальная подготовка папки

[33] Глава 26. Решение проблем интерфейса первого уровня

[33.1]
урок 18. Индивидуальное комментирование

[33.2]
урок 19. Индивидуальное реагирование

[33.3]
урок 20. Переделка декомпозиции первого уровня

[33.4]
урок 21. Переделка декомпозиции второго уровня

[34] Глава 27. Написание спецификации

[34.1]
урок 22. Запись требований для обобщенной диаграммы и диаграммы верхнего уровня

[34.2]
урок 23. Аннотирование декомпозиции первого уровня

[34.3]
урок 24. Запись требований для декомпозиции второго уровня

[34.4]
урок 25. Написание спецификации

[34.5] Спецификации модели "Питание семьи"

[34.6] А-0 Питание семьи (контекст)

[34.7] АО Питание семьи (обзор)

[34.8] А2. Поддержание запасов

[34.9]
А21. Использование кладовой


Предисловие

Замечательно, что эта первая, посвященная SADT книга, наконец, вышла в свет, и мне очень приятно предложение написать к ней предисловие. Авторы книги, мои коллеги и добрые друзья, прекрасно подготовлены для того, чтобы вести вас, читатель, по пути, который они и другие исследователи считают успешным для разностороннего использования и преподавания этой методологии. Как все хорошие преподаватели, они накладывают собственный отпечаток и по-своему расставляют акценты в излагаемом материале, но вы увидите, что все, что я упомяну здесь в общем обзоре проблемы, полностью относится и к самой книге. С моей стороны, SADT - это не столько изобретение, сколько открытие. Впервые я использовал обозначение "SA-блок", лежащее в основе того, что я гораздо позже стал называть структурным анализом (Structured Analysis, SA), в промежуточном отчете по созданию алгоритмического языка АРТв Массачусетском технологическом институте (МТИ) 30 лет назад. Это обозначение четко выражало одну важную идею, связанную с тем, что сегодня называется иерархической многоуровневой модульной системой. Каждый уровень представлял собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней (APT является стандартным языком типа фортрана, Кобола или Лиспа, но используется для автоматизированного проектирования сервисных программ, причем исходная архитектура системы APT применяется до сих пор). Однако концепция "декомпозиции", вторая центральная идея SADT, в то время еще не была явно сформулирована. Прежде чем она явилась на сцену, SA-блок еще раз был использован мною подобным образом в ключевом рисунке моей статьи "AED-подход к системам автоматизированного проектирования", отмеченной премией в 1967 г. Создание AED в МТИ последовало за созданием APT и предшествовало большинству технических средств и разработок как в той области, которая теперь называется разработкой программного обеспечения, так и в области собственно систем автоматизированного проектирования (САПР). На этом рисунке изображалась "система систем для построения систем", т. е. предназначенная для того, что теперь называется технологией "компилятора компиляторов" для создания специальных языков, ориентированных на пользователя. Таблично контролируемые процессоры (для проверки правописания, грамматического анализа, генерации кодов, выполнения), каждый из которых представлял законченную систему (блок), были не столько разбиты на уровни, сколько сцеплены друг с другом (выход со входом), образуя компилятор. Аналогичным образом порождались и таблицы. Итак, SA-блок был полностью осознан и использован, хотя еще и не назван.

Показательно, что именно между этими двумя случаями использования графических SA-блоков важность того, что теперь называется "иерархической декомпозицией сверху вниз", была подчеркнута "неграфически" в моем завершающем отчете I960 года по созданию AED, названном "Постановка целей". Я подчеркнул, что САПР должна быть объектно-ориентированна и что объекты, включая те системы, которые мы создаем для работы с ними, должны определяться и описываться сверху-вниз до нужного уровня детализации.

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

В азарте я свел годами апробируемые идеи и опыт в соответствующую методологию проектирования, выделяя интерфейсы  между  модульными системами и их использование в качестве защитного барьера для требуемой сверх надежности. Таким образом, я завершил проект в срок. Эта работа и результаты последующих бесед с С.Хори, который ввел почти такие же обозначения SA-блоков в своем "клеточном моделировании" (cell modeling) человеко-ориентированных функций, послужили основой для создания в 1973 году первого "Руководства автора". Оно предназначалось для обучения аналитиков методу, использующему понятие "архитектура" (Architecture Method) и примененному в работах по проекту военно-воздушных сил по разработке систем автоматизированного производства (AFCAM). В следующем году я придумал название "Структурный анализ" для методологии, объединяющей SA-блоки и SA-декомпозицию в единый графический "язык проектирования систем". Остальное принадлежит истории.

Как видится мне SADT теперь, спустя годы? Для меня представляет все больший интерес объяснять, почему методология так хорошо работает. Беглое изложение моей последней попытки сделать это послужит подходящим финалом для настоящего предисловия. Я советую вам возвращаться к время от времени к изложенному далее материалу по мере дальнейшего чтения книги. Вы увидите, что с каждым разом вам будут открываться новые грани. Мир и все в нем, включая наши мысли о нем, можно рассматривать как систему взаимодействующих систем. У системы есть граница, поведение и сущность. Каждое из этих понятий определяется взаимодействием этой системы с другими системами, с которыми она соединяется еще и в новые системы. Так, например, грузовик имеет электрическую, механическую и гидравлическую системы. Конкретно - у него есть системы управления движением, расписания доставки и расценок. Другая, более абстрактная область - наука имеет предмет, теории, лаборатории, учебный курс, эксперименты, бюджет, студентов. У романа есть изложение, персонажи, сюжет и стиль. История (прошлое, настоящее, будущее - возможное или испытанное в жизни) может включать все это.

Как такое разнообразие систем можно строго исследовать? Приспосабливая и используя именно тот язык, который является наиболее естественным для данного объекта. Это может быть "естественный" язык, такой, как английский, технический жаргон искусственного формального языка, математические формулы или далее изображения форм и очертаний. Как можно избежать неточностей и двусмысленности такого разнообразия выражений? Так же, как это происходит в любом естественном языке: к этим выражениям следует применять правила пунктуации, которые не несут самостоятельного смысла, но служат для ограничения, структурирования и интерпретации этих выражений так, чтобы сохранить только то значение, которое имелось в виду.

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

моделирует А, если М отвечает на вопросы относительно А".

Одна и та же схема моделирования может быть использована для моделирования любого выбранного объекта. Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль. Итак, что же является универсальной единицей универсальной пунктуации для неограниченного строго структурного анализа? SA-блок:

Вход при наличии управления преобразуется в выход с помощью "механизма" (исполнителя).

Выходы одного блока могут быть входами или управлениями (или исполнителями) для других блоков. (Блоки именуются, а дуги помечаются с использованием естественного языка.) Дуги могут разветвляться и соединяться, а каждый блок может быть подвергнут декомпозиции, т. е. разделен как целое на свои составляющие на более детальной диаграмме. Входы, управления и выходы определяют интерфейсы между блоками, а исполнители позволяют при необходимости в определенной степени объединять объекты. Границы блоков и диаграмм должны  быть согласованы, а возникающая иерархическая, взаимосвязанная совокупность диаграмм является моделью. Благодаря объяснению термина "декомпозиции" каждая грамматическая форма имеет свое строго определенное значение.

Как регулируется сложность, чтобы была понятна суть ? Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта. Как обеспечивается понятность? Насколько практичен подход? Только достаточно дисциплинированный ум позволяет создавать хорошо структурированные модели. SA-авторов (разработчиков) учат точным методам организации процесса создания хороших моделей с помощью наглядной структуризации, которую обеспечивает графический язык SA-блоков и дуг и которая дает возможность реализовывать обратную связь. Затем для подтверждения того, что модели действительно отражают задуманное, SA-читателей учат точным методам правильной интерпретации моделей. Применяемый в SA цикл автор/читатель позволяет регулярно доводить до сведения автора замечания к модели. Тем самым обеспечивается непрерывная проверка ее качества специально отобранными для этого читателями. Хорошо определенные и достаточно простые обязанности SA-библиотекаря поддерживают как коллективную деятельность, так и индивидуальную работу автора. Простота методики, начиная от дисциплины мышления до организации движения бумаг обеспечивает наиболее продуктивный и эффективный обмен информацией без искусственных усложнений. Если читатели достаточно активны, то опыт накапливается быстро.

Предназначены ли языковые средства методологии SA для полной замены всех других форм передачи информации читателю? Вовсе нет - они хорошо дополняются ими. Общая граница блока и диаграммы называется узлом. Указатель узлов с названиями диаграмм модели в точности совпадает со стандартным структурированным оглавлением обычной документации. Основное правило чтения моделей заключается в следующем: вначале прочтите диаграмму и только потом сопутствующий ей SA-текст. Компактный язык ссылок в SA позволяет обратиться к любому компоненту диаграммы, что дает возможность выделить потоки объектов между блоками и общие взаимосвязи для обеспечения передачи содержания диаграммы. Этот краткий, хорошо организованный текст, сопровождающий диаграмму, может служить основой для создания стандартного описания. Ограничение, наложенное для лучшего восприятия правилом "от трех до шести блоков", может оказаться неудобным для более общего обзора. Существуют строгие методы сжатия отдельных частей модели в большие многоблочные схематические диаграммы, которые затем могут быть преобразованы в стандартные иллюстрации. При этом, однако, важно знать, что они полностью подтверждаются и поддерживаются полным анализом модели и соответствуют заключительному сжатому изложению как оглавление к стандартному описанию.

Во одних случаях важно рассмотрение динамики системы, а в других требуется получить распределенную базу знаний. Как соотносится SA с имитационным моделированием и базами данных? Ориентация модели (ее контекст, точка зрения и цель) может быть направлена так, что результирующие структурные описания дадут исходные данные для методологий имитационного моделирования, проектирования баз данных или структурного программного проектирования. Существует два основных направления в SA-моделировании: функциональные модели выделяют события в системе, модели данных выделяют объекты системы, которые связывают функции между собой и с их окружением. В обоих случаях используется один и тот же графический язык блоков и дуг (хотя это использование двойственно: блоки и дуги меняются ролями). При наиболее полном моделировании взаимодополняющие модели обоих типов и одного и того же объекта рассмотрения связываются между собой с помощью процесса SA-связывания. Правила действия могут связываться с непрерывными или дискретными потоками данных в моделях, а ограничения на типы словаря данных могут применяться к объектам и событиям. Принципиальное определение функциональной модели может быть сформулировано алгоритмически как структурированная программа типа "цикл с выходами" с дополнительными метками, указывающими, когда используются входные и управляющие данные.

Каков "послужной список" SA? За очень немногими исключениями SA успешно применялся либо в виде методологии структурного анализа и проектирования (SADT) компании SofTech, либо как только функциональный вариант в правительственной версии (IDEFO). Его применяли тысячи людей при работе над сотнями проектов во многих областях, начиная с 1973 года. Большинство применений было связано с системами "человек-машина-компьютер" в бизнесе, производстве, обороне, связи и организации проектирования. Можно надеяться, что доступность этой книги расширит область его применения за счет гуманитарных и научных сфер. SA применим к любому интересному объекту.

Дуглас Т. Росс,

SofTecb и МТИ, ноябрь 1986 г.


Введение

Использование экспертных систем, языков четвертого поколения и систем автоматизированного производства постоянно расширяется. Успех этих систем непосредственно зависит от нашей способности предварить их разработку и внедрение описанием всего комплекса проблем, которые необходимо разрешить, указанием того, какие функции системы должны быть автоматизированы, определением точек интерфейса человек-машина и того, как взаимодействует система со своим окружением. Иными словами, этап проектирования системы является критическим для создания высококачественных систем. Системное проектирование - это дисциплина, определяющая подсистемы, компоненты и способы их соединения, задающая ограничения, при которых система должна функционировать, выбирающая наиболее эффективное сочетание людей, машин и программного обеспечения для реализации системы. SADT - одна из самых известных и широко используемых систем проектирования. SADT - аббревиатура слов Structured Analysis and Design Technique (Технология структурного анализа и проектирования) - это графические обозначения и подход к описанию систем. Дуглас Т. Росс ввел их почти 20 лет назад. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное программное обеспечение для оборонных систем, управление финансами и материально-техническим снабжением - вот некоторые из областей эффективного применение SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе интегрированной компьютеризации производства (ICAM) Министерства обороны США была признана полезность SADT, что привело к стандартизации и публикации ее части, называемой IDEFO. Такая стандартизация вкупе с растущей автоматизированной поддержкой и этой книгой означает, что SADT теперь более доступна и проста в использовании. Под названием IDEFO SADT применялась тысячами специалистов в военных и промышленных организациях. В коммерческом мире SADT используется для определения требований. В этом качестве она конкурирует с методами, ориентированными на потоки данных, - структурного проектирования Е.Иордана, структурного анализа Т.ДеМарко, структурного системного анализа С. Гейна и Т. Сарсона, а также с методами структуризации данных -методами М.Джексона, Лж.Д. Варнира и К. Орра. В отличие от этих методов структурного анализа, истоки которых нужно искать в проектировании программного обеспечения, SADT создана для описания системы и ее среды до определения требований к программному обеспечению или к чему-либо другому. Иными словами, поставив своей целью описание системы в общем, создатели SADT изобрели графический языки набор процедур анализа для понимания системы прежде, чем можно представить себе ее воплощение. Таким образом, SADT, как правило, применяется на ранних этапах процесса создания системы, который часто называют "жизненным циклом системы", и иногда за этим следует применение упомянутых выше методов.

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

Основное внимание в книге уделено изложению основных концепций SADT, объяснению ее реализации, описанию процесса моделирования, обсуждению современной автоматизированной поддержки SADT и анализу примеров, взятых из реальной жизни. В части I "Основные понятия функционального моделирования" излагаются фундаментальные понятия SADT-моделирования систем. В части II "Создание функциональных моделей и диаграмм" показано, как графический язык SADT используется для декомпозиции описания системы с помощью иерархического набора диаграмм. В части III "Рецензирование диаграмм и моделей"- рассматривается цикл автор/читатель, специальным образом организованный процесс рецензирования для повышения качества моделей. По мнению многих пользователей SADT, этот процесс - лучший способом удостовериться в правильности и плодотворности своей работы. Поэтому мы описали цикл автор/читатель как самостоятельную процедуру, которая может использоваться в ходе любой работы. В части IV "Завершение моделирования. Руководство моделированием" - обсуждаются проблемы управления и организации работы группы SADT-аналитиков и приводится набор критериев, которые могут помочь определить, когда следует завершить процесс моделирования.

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

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


Предпосылки создания SADT

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

  •  анализ - определение того, что система будет делать,
  •  проектирование - определение подсистем и их взаимодействие,
  •  реализация - разработка подсистем по отдельности, объединение - соединение подсистем в единое целое,
  •  тестирование - проверка работы системы,
  •  установка - введение системы в действие,
  •  функционирование - использование системы.

Эта последовательность всегда выполнялась итерационно, потому что система полностью никогда не удовлетворяла требованиям пользователей, поскольку их требования часто менялись. И, тем не менее, с этой моделью создания системы, ориентированной на управление, постоянно возникали сложности. Эксплуатационные расходы, возникавшие после сдачи системы, стали существенно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. Некоторые считали, что рост эксплуатационных расходов обусловлен характером ошибок, допущенных в процессе создания системы. Исследования показали, что большой процент ошибок в системе возник в процессе анализа и проектирования, гораздо меньше их было допущено при реализации и тестировании, а цена (временная и денежная) обнаружения и исправления ошибок становилась выше на более поздних стадиях проекта. Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования - в 10 раз, а на стадии эксплуатации системы - в 100 раз дороже, чем на стадии анализа. На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление - примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях. Кроме того, ошибки анализа и проектирования обнаруживались часто самими пользователями, что вызывало их недовольство.

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

Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал "Методология структурного анализа и проектирования" (SADT). Исходная работа над SADT началась в 1969 г. Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была несколько пересмотрена сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний. Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта. К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими дюжину проблемных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных. Ее широкое распространение в настоящее время в европейской, дальневосточной и американской аэрокосмической промышленности (под названием IDEFO) позволяет эти цифры существенно увеличить. Таким образом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широкое применение? Во-первых, SADT является единственной методологией, легко отражающей такие системные характеристики, как управление, обратная связь и исполнители. Это объясняется тем, что SADT изначально возникла на базе проектирования систем более общего вида в отличие от других структурных методов, "выросших" из проектирования программного обеспечения. Во-вторых, SADT в дополнение к существовавшим в то время концепциям и стандартам для создания систем имела развитые процедуры поддержки коллективной работы и обладала преимуществом, связанным с ее применением на ранних стадиях создания системы. Кроме того, широкое использование SADT показало, что ее можно сочетать с другими структурными методами. Это достигается использованием графических SADT-описаний в качестве схем, связывающих воедино различные методы, примененные для описания определенных частей системы с различным уровнем детализации. Таким образом, неадекватные спецификации систем того времени вызвали создание графического языка SADT, а его усиленное использование преобразовало SADT в законченную методологию, способную повысить качество продуктов, создаваемых на ранних стадиях развития проекта. Итак, SADT началась как язык описания функционирования систем общего вида, а по мере применения ее процедуры описания систем были улучшены и дополнены. В первых главах этой книги обсуждаются концепции описания систем, лежащие в основе SADT, ее графический язык и процедуры описания систем. В последующих главах мы как бы заглядываем через плечо человека, использующего SADT, чтобы увидеть, как с помощью этой методологии можно описать систему, и как из этого описания получаются спецификации.


Часть I Принципы функционального моделирования

В этой части книги кратко излагается методология SADT, описываются основные понятия, на которых она базируется, и объясняется, почему графический язык и процесс SADT -моделирования могут быть использованы для создания содержательных описаний систем. Книга посвящена подмножеству полной методологии SADT , ориентированному на функции системы и называемому "функциональным моделированием". В части I сконцентрированы главные аспекты функционального SADT-моделирования, чтобы облегчить поиск нужного материала при возникновении вопросов теоретического плана. В главе 1 дано общее определение системы, показано место SADT в спектре методов описания систем и введены основные понятия, на которых базируется SADT. В главе 2 обсуждаются синтаксические правила и правила применения методов, необходимые для создания одной SADT-диаграммы. В главе 3 приведены правила, соединения нескольких SADT-диаграмм в одну модель, даже если эта модель быстро развивается. В главе 4 показано, как процесс SADT-моделирования, важнейшая часть методологии SADT, обеспечивает достоверность моделей. В главе 5 более подробно рассмотрены SADT-диаграммы и характеристики системы, которые они отражают. Глава 6 посвящена отдельным аспектам создания SADT-моделей. Теория и практика SADT поясняются с помощью задачи экспериментального механического цеха, которая последовательно рассматривается в частях I - IV книги. Фрагменты модели экспериментального механического цеха иллюстрируют основные понятия SADT и типичное использование этой методологии. Хотя в части I и определяются основные понятия SADT, сами по себе они недостаточны для построения точной, понятной и полезной SADT-модели. Дополнительные процессы анализа, синтеза, рецензирования и управления проектированием (которые обсуждаются в других частях книги) также являются важными компонентами методологии SADT.


Глава 1. Системы и модели

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

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

SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT была создана и опробована на практике в период с 1969 по 1973 г. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и даже кибернетики. С 1973 г. сфера ее использования существенно расширяется для решения задач, связанных с большими системами, такими, как проектирование телефонных коммуникаций реального времени, автоматизация производства (САМ), создание программного обеспечения для командных и управляющих систем, поддержка боеготовности. Она с успехом применялась для описания большого количества сложных искусственных систем из широкого спектра областей (банковское дело, очистка нефти, планирование промышленного производства, системы наведения ракет, организация материально-технического снабжения, методология планирования, технология программирования). Причина такого успеха заключается в том, что SADT является полной методологией для создания описания систем, основанной на концепциях системного моделирования.

1.1. SADT-модели

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

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

Эта книга посвящена тому, как строить функциональные модели. Построение с помощью SADT моделей данных, а также множества моделей выходит за рамки этой книги.

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

1.2. Модель отвечает на вопросы

SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT:

М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Определяя модель таким образом, SADT закладывает основы практического моделирования.

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

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

Рис 1-1. Определение цели и точки зрения модели ЭМЦ

когда процесс моделирования можно считать завершенным (т.е. когда модель будет соответствовать поставленной цели).

1.3. Модель имеет единственный субъект

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

1.4. У модели может быть только одна точка зрения

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

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

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

1.5. Модели как взаимосвязанные наборы диаграмм

После того как определены субъект, цель и точка зрения модели, начинается первая интеграция процесса моделирования по методологии SADT. Субъект определяет, что включить в модель, а что исключить из нее. Точка зрения диктует автору модели выбор нужной информации о субъекте и форму ее подачи. Цель становится критерием окончания моделирования. Конечным результатом этого процесса является набор тщательно взаимоувязанных описаний, начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы.

Каждое из таких тщательно взаимосогласованных описаний называется диаграммой. SADT-модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы наверху модели менее детализированы, чем диаграммы нижних уровней. Другими словами, модель SADT можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы. На рис. 1-2 представлены две диаграммы из модели экспериментального механического цеха. Верхняя диаграмма (на вершине модели) описывает механический цех как функцию, в основе которой лежит преобразование входящих рабочих комплектов (заготовок, сырья, документации) в детали при определенном контроле качества. Нижняя диаграмма детализирует верхнюю, указывая на три главные функции механического цеха: управление выполнением заданий, выполнение задания и контроль качества выполнения. Таким образом, общая функция, указанная на верхней диаграмме, детализируется с помощью трех функций на нижней диаграмме. Это пример того, как SADT организует описание системы, создавая иерархию добавляющихся на каждом уровне деталей.

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

1.6. Резюме

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


Рис 1-2 Две взаимосвязанных
SADT-модели

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

Brackett, J., and C. McGowan: "Applying SADT to Large System Problems", SofTech Technical Paper TP059,January 1977.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Freeman, P.: "Requirements Analysis and Specification: The First Step", Advances in Computer Technology - 1980, August 1980.

Hori, S.: "Human-Directed Activity Cell Model", CAM-1 Long Range Planning Final Report, CAM-1, Inc., 1972.

Miller, J.: Living Systems, McGraw-Hill, New York, 1978.

Ross, D.: "PLEX1: Sameness and the Need for Rigor", SofTech Deliverable no. 9031-1.1, December 1975.

Ross, D.: "PLEX2: Sameness and Type", SofTech Deliverable no. 9031-2.0, December 1975.

Ross, D.: "Reflections on Requirements", IEEE Transactions on Software Engineering, vol. SE-3, no. 1,January 1977.

Ross, D.: "Doug Ross Talks about Structured Analysis", IEEE Computer, July 1985.

Ross, D. and K. Schoman: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

Weinberg, G.: An Introduction to General Systems Thinking, John Wiley, New York, 1975.


Глава 2. Синтаксис и применение диаграмм

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

2.1. Диаграммы содержат блоки и дуги

Каждая SADT-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними (рис.2-1). Диаграмме дается название, которое располагается в центре нижней части ее бланка. На каждой диаграмме написана стандартно идентифицирующая ее информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, статус диаграммы. Вся идентифицирующая информация располагается в верхней части бланка диаграммы.

2.2. Блоки представляют функции

Функциональные блоки на диаграммах изображаются прямоугольниками. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Например, названиями блоков диаграммы выполнить задание являются: определить степень выполнения задания, выбрать инструменты, подготовить рабочее место, обработать на станке и собрать, как показано на рис. 2-1.

Кроме того, SADT требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования. Другими словами, SADT-диаграммы и SADT-модели наглядны.

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

2.3. Блоки имеют доминирование

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

Рис 2-1 Типичная SADT-диаграмма

другие функции (такая, как определить степень выполнения задания на рис. 2-1).

Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом нижнем углу. В результате получается "ступенчатая" схема, подобная представленной на рис. 2-1 для блоков 1, 2, 3.

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, SADT-аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее после наибольшего, и т.д. На рис. 2-1 показано, что блок определить степень выполнения задания влияет на все остальные шаги по обработке детали через следующий шаг задания и поэтому этот блок пронумерован единицей. Поскольку блок подготовить рабочее место должен быть перед блоком обработать на станке и собрать, этим блокам присвоены номера 3 и 4.

Блоки в SADT должны быть перенумерованы. Номера блоков служат однозначными идентификаторами для системных функций и автоматически организуют эти функции в иерархию модели. Используя номера блоков и оценивая влияние, которое один блок оказывает на другой;

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

2.4. Дуги изображают объекты

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

Так как в SADT дуги изображают объекты, они описываются (помечаются) существительными или существительными с определениями, располагающимися достаточно близко к линии дуги. Мы настоятельно рекомендуем размещать описания дуг, называемые метками, как можно ближе к линиям дуг, не нарушая, однако, читабельность диаграмм. Это устраняет неопределенность в том, к какой дуге относится метка, и исключается необходимость в дополнительных графических связях (например, в "зигзагах", см. главу 19). Обратите внимание на то, что все метки дуг на диаграмме выполнить задание расположены вплотную к соответствующим дугам. Мы рекомендуем принять этот стиль описания дуг для того, чтобы ваши диаграммы были упорядоченными и простыми для чтения.

2.5. Дуги изображают взаимосвязи между блоками

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

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

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

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

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

Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку они представляют итерацию или рекурсию. А именно выходы из одной функции влияют на будущее выполнение других функций, что впоследствии влияет на исходную функцию. Обратная связь по управлению возникает тогда, когда выход некоторого блока влияет на блок с большим доминированием. Рассмотрим для примера диаграмму изготовить нестандартную деталь на рис. 2-2. Функция управлять выполнением. задания ограничивает действие функции контролировать качество выполнения с помощью чертежа, в котором указаны разрешенные допуски. Кроме того, дуга штамп "принято", являющаяся выходом блока контролировать качество выполнения, организует работу блока управлять выполнением задания, поскольку именно штамп "принято" указывает, что задание завершено. Таким образом, штамп "принято" влияет на будущую деятельность блока управлять выполнением задания, поэтому соответствующая дуга направлена назад. Связь по входной обратной связи имеет место тогда, когда выход одного блока становится входом другого блока с большим доминированием. Например, задания, отвергнутые функцией контролировать качество выполнения, отсылаются на вход блока выполнить задание в качестве брака. (Это хороший пример, показывающий, что системы часто имеют внутренние обратные связи для эффективного использования бракованных деталей.)

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

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

2.6. Дуги представляют наборы объектов

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

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

2.6.1. Разветвление дуг

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

  •  


  •  непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. все объекты принадлежат этим ветвям);
  •  ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке дуги перед разветвлением (т.е. каждая метка ветви уточняет, что именно содержит ветвь).

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

2.6.2. Слияние дуг

Слияние дуг в SADT, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:

  •  непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей);
  •  помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния (т.е. метка ветви ясно указывает, что содержит ветвь).

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

2.7. Идентификация версий диаграмм С-номерами

При создании SADT-модели одну и ту же диаграмму вместе с ее блоками и дугами перечерчивают несколько раз, что приводит к появлению различных ее вариантов. Чтобы различать разные версии одной и той же диаграммы, в SADT используется схема контроля конфигурации диаграмм, основанная на хронологических номерах, или С-номерах. С-номерные коды образуются из инициалов автора и последовательных номеров. Эти коды ставятся в нижнем правом углу SADT-бланка. Например, DAM010 -это С-номер для диаграммы выполнить задание на рис. 2-1. Если диаграмма заменяет более старый вариант, то автор помещает предыдущий С-номер в скобках, чтобы указать на связь с предыдущей работой. Например, диаграмма DAM010 заменяет предыдущую версию DAM009. Каждый автор проекта SADT ведет реестр всех созданных им диаграмм, нумеруя их последовательными целыми числами. Для этого используется бланк реестра С-номеров SADT. На рис. 2-3 приведен реестр С-номеров рассматриваемой в этой книге модели экспериментального механического цеха. Обратите внимание на то, как бланк указывает следующие номера, которые нужно использовать. Автору остается только записать номер узла и его название для каждой новой диаграммы.

2.8. Резюме

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

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

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Ross, D., and Bracket, J.: "An Approach to Structured Analysis", Computer Decisons, September 1976.

Ross, D.: "Structured Analysis (SA): A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977. Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

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.


Глава 3. Синтаксис моделей и работа с ними

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

3.1. Система представляется одним блоком

SADT-модель является иерархически организованной совокупностью диаграмм. Диаграммы обычно состоят из трех-шести блоков, каждый из которых потенциально может быть детализирован на другой диаграмме. Каждый блок может пониматься как отдельный тщательно определенный объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.

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

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

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

3.2. Идентификация декомпозиции номерами узлов

SADT-модели развиваются в процессе структурной декомпозиции сверху вниз. Сначала декомпозируется один блок, являющийся границей модели, на одной диаграмме, которая имеет

Рис 3-1. Контекстная диаграмма модели

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

Таким образом, каждая диаграмма представляет собой некоторую законченную часть всей модели. В методологии SADT идентифицируется каждая диаграмма данной модели посредством того, что называется "номер узла". Номер узла для контекстной диаграммы имеет следующий вид: название модели или аббревиатура, косая черта, заглавная буква A (Activity в функциональных диаграммах), дефис и ноль. Например, номером узла для контекстной диаграммы модели экспериментального механического цеха является ЭМЦ/А-0. Номером узла диаграммы, декомпозирующей контекстную диаграмму, является тот же номер узла, но без дефиса (например, ЭМЦ/АО). Все другие номера узлов образуются посредством добавления к номеру узла родительской диаграммы номера декомпозируемого блока. На рис. 3-2 показаны две диаграммы модели экспериментального механического цеха. Номер узла на первой диаграмме - ЭМЦ/АО, а номер узла на второй диаграмме - ЭМЦ/А1. Диаграмма ЭМЦ/А1 декомпозирует блок 1 диаграммы ЭМЦ/АО. (Первый ноль при образовании номера узла принято опускать, поэтому вместо ЭМЦ/А01 пишется ЭМЦ/А1.)

3.3. Связывание декомпозиции с помощью С-номеров

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

Рис 3-2. Связь между родительской диаграммой и диаграммой потомком

Как только образуется направленная вниз связь, на диаграмме-потомке формируется ссылка на родительскую диаграмму. В области контекста SADT-бланка (правый верхний угол) автор изображает каждый блок родительской диаграммы маленькими квадратиками, заштриховывает квадратик декомпозируемого блока и размещает С-номер родительской диаграммы возле заштрихованного квадратика. Это образует "направленную вверх" (к родительской диаграмме) связь. Метод соединения диаграмм посредством однозначно определенных номеров гарантирует, что именно нужная версия диаграммы станет частью модели. Другими словами, при использовании С-номеров осуществляется тщательный контроль за введением новых диаграмм в иерархию модели. На рис. 3-2 область контекста бланка диаграммы управлять выполнением задания содержит три квадратика - по одному для каждого блока диаграммы изготовить нестандартную деталь. Первый блок заштрихован. Это указывает на то, что данная диаграмма декомпозирует первый блок диаграммы DAM008.

3.4. Коды ICOM гарантируют стыковку диаграмм

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

В SADT принята система обозначений, позволяющая аналитику точно идентифицировать и проверять связи по дугам между диаграммами. Эта схема кодирования дуг -"ICOM" - получила название по первым буквам английских эквивалентов слов вход (Input), управление (Control), выход (Output), механизм (Mechanism). Коды ICOM чрезвычайно эффективны, поскольку они позволяют аналитику быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего блока родительской диаграммы. Они также обеспечивают согласованность декомпозиции, поскольку все дуги, входящие в диаграмму и выходящие из нее, должны быть учтены. На рис. 3-2 дуга требования по срокам выполнения задания может быть отслежена от ее начала (С1 блока 0 диаграммы ЭМЦ/ А-0) на границе модели через верхнюю часть диаграммы ЭМЦ/АО к блоку управлять выполнением задания (СЗ блока 4 диаграммы ЭМЦ/ А1). (Мы детально обсудим некоторые исключения из этого правила в главе 5.)

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

  •  представьте себе рисунок новой диаграммы внутри разлагаемого блока. Продлите внешние дуги почти до края диаграммы. Зрительно соедините каждую внешнюю дугу диаграммы с соответствующей граничной дугой декомпозируемого блока (на рис. 3-3 в некоторых местах мы используем пунктирные линии для изображения процесса зрительного соединения).
  •  присвойте код каждой зрительной связи. Используйте I для входных дуг, С - для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма.
  •  добавьте после каждой буквы цифру, соответствующую положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причем входные и выходные дуги пересчитываются сверху вниз, а дуги управлений и механизмов пересчитываются слева направо (см. рис. 3-3). Теперь запишите каждый код около окончания каждой внешней дуги.

На рис. 3-3 приведены субъект и его границы (блок и прилегающие дуги) и декомпозирующая его диаграмма. Обратите внимание, что граница субъекта изображена жирной линией для того, чтобы подчеркнуть, как внешние дуги связаны с соответствующими граничными дугами. В этом примере мы изобразили на диаграмме пунктирными линиями зрительные связи только между выходными дугами и соответствующими им граничными дугами. (Другие связи легко определить зрительно.) В соответствии со схемой кодирования для рис. 3-3 были получены коды ICOM: II, 12, Cl, C2, 01, 02, Ml. Кодирование дуг ICOM-метками произведено в зависимости от того, к какой стороне родительского блока примыкает данная дуга.

При следовании схеме кодирования ICOM создается совокупность неявных связующих звеньев между страницами, которые можно быстро изменить при изменении границ. (Сравните схему кодирования ICOM/SADT с альтернативной схемой, в которой внешние дуги просто помечаются определенным образом, скажем, буквами от А до Я.) Эти неявные межстраничные связующие звенья облегчают процесс чтения и рецензирования SADT-диаграмм, а также проверку, насколько согласованно произведена декомпозиция. Коды ICOM упрощают также работу, связанную с внесением вручную локальных изменений в диаграмму, и объединяют различные варианты диаграмм так, что они хорошо стыкуются в модели. По нашему мнению, коды ICOM являются одним из наиболее важных вкладов SADT в технологию графического моделирования. Они обеспечивают требуемую строгость, позволяя в то же время авторам работать независимо, чертить разборчиво и выбирать без ущерба для предыдущей работы подходящую терминологию на последующих уровнях детализации.

3.5. Обозначения для менее распространенных интерфейсов по дугам

Номера узлов, С-номера и коды ICOM управляют подавляющим большинством ситуаций внутренних связей в модели. Однако между родительскими диаграммами и диаграммами-потомками могут возникать некоторые специфические ситуации, в которых разумное использование синтаксиса модели улучшает описание модели, а именно: (1) при разветвлении и соединении внешних дуг; (2) при изменении входных дуг на управляющие и наоборот; (3) когда дуги "входят в тоннель". Мы приведем примеры каждой из этих ситуаций, так чтобы вы могли распознать их и понять их значение. Однако необходимо предупредить, что такие средства изображения следует использовать только в особых ситуациях для прояснения и упрощения описания системы. Их следует применять для удобства, а не как прикрытие плохого анализа систем. Во всех этих случаях данные при пересечении границ диаграмм сохраняются, т. е. все входные данные некоторым образом используются для образования всех выходных данных. Ключом для понимания таких ситуаций является то, что дуги SADT изображают иерархические наборы данных (в главе 5 приведены дополнительные пояснения относительно иерархии дуг и дуг вообще).

Одна из особых ситуаций заключается в разветвлении или соединении внешних дуг между диаграммами. Например, две внешние выходные дуги на диаграмме могут быть частями общей выходной дуги на границе блока. Это может произойти, если аналитик вместо того, чтобы обычным способом соединить их на диаграмме, оставляет это соединение неявным. Узнать об этом непоказанном соединении или разветвлении можно только, заметив, что коды ICOM для двух разных дуг совпадают. (Такая ситуация показана в уроке 7, где дуга бюджет и деньги, Cl на диаграмме ПС/А-0, разделена на диаграмме ПС/АО на дугу бюджет и дугу деньги.) Мы настоятельно рекомендуем почти во всех случаях делать явным факт соединения или разветвления внешних дуг, вычерчивая это на декомпозируемой диаграмме. Это позволит избежать использования ICOM-меток для указания соединения или разветвления дуг.

Особая ситуация возникает также тогда, когда входная дуга превращается в дугу управления и наоборот. Это происходит, если дуга управления (или входная), касающаяся границы блока, используется при декомпозиции диаграммы как входная (или соответственно управленческая) дуга. В уроке 7 обратите внимание на то, что дуга деньги как часть дуги деньги и бюджет является дугой управления на диаграмме ПС/А-0, однако используется как входная дуга на диаграмме ПС/ АО. Аналитик связал их для того, чтобы подчеркнуть, что на верхнем уровне модели бюджет и деньги управляют процессом питания семьи. Бюджет управляет планированием, а деньги - это нечто, превращаемое в процессе хождения по магазинам в продукты. Нам редко встречались ситуации, в которых требуется подобная техника. Мы советуем хорошо подумать об альтернативных способах построения диаграммы, прежде чем применять эту технику.

Две другие особые ситуации возникают, когда дуги "входят в тоннель" между диаграммами. Дуга "входит в тоннель", либо (1) если она


Рис 3-3. Кодирование связей между SADT-диаграммами

является внешней дугой, которая отсутствует на родительской диаграмме (имеет скрытый источник), либо (2) если она касается блока, но не появляется на диаграмме, которая его декомпозирует (имеет скрытый приемник). Тоннельные дуги от скрытого источника начинаются скобками, чтобы указать, что эти дуги идут из какой-то другой части модели или прямо извне модели. На рис. 3-2 дуга незанятый рабочий С1 блока получить задание и назначить исполнителя на диаграмме ЭМЦ/А1 входит в тоннель и поэтому она не касается блока управлять выполнением задания на родительской диаграмме ЭМЦ/АО. Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели или выходит из нее или что она не будет более в этой модели рассматриваться. На рис. 3-2 все дуги механизмов диаграммы изготовить нестандартную деталь являются тоннельными и указывают на то, что они не будут показаны при декомпозиции соответствующих блоков.

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

3.6. Резюме

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

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

Ross, D.: "Removing the Limitations of Natural Language (with Principles behind the RSA Language)", SofTech Deliverable no. 9061-25, July 1979.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech,Inc., 1981.

Глава 4. Процесс моделирования

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

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

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

SADT-проектов: эксперты являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а Комитет технического контроля принимает и утверждает модель. В данной главе представлен общий обзор процесса моделирования. Более детально его отдельные шаги обсуждаются в главах 5 и 6, а также в частях II и III.

4.1. Получение знаний в процессе опроса

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


4.2. Документирование полученных знаний

Создание модели (блок 2 на рис. 4-1) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной проблемной области, представляя их в виде одной или нескольких SADT-диаграмм. Процесс создания модели осуществля-

Рис. 4-1. Процесс создания SADT-модели

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

4.3. Корректность модели проверяется в процессе итеративного рецензирования

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

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

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

4.4. Координация процесса рецензирования

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

4.5. Модели используются после их одобрения

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

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

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

4.6. Резюме

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

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

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

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981


Глава 5. Более глубокие концепции диаграмм

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

5.1. Дуги имеют различное содержание

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

5.2. Дуги могут быть декомпозированы

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

Рассмотрим дуги план выполнения задания и принятое задание на диаграмме рис. 5-1. Из диаграммы видно, что эти дуги представляют совокупности объектов, поскольку каждая из них разветвляется на две отдельные дуги с различными метками. Следуя структуре дуг, можно сказать, что чертеж - часть плана выполнения задания, а принятое задание либо формируется из детали с биркой и штампа "принято", либо является принятым, но незаконченным заданием. Это все, что можно узнать об этих дугах из диаграммы изготовить нестандартную деталь. Однако мы всегда можем посмотреть на декомпозицию блоков этой диаграммы для выяснения дополнительных подробностей содержания этих дуг. Например, на диаграмме выполнить задание (рис. 5-4) мы видим, что станки и инструмен-

Рис 5-1. SADT-диаграмма, содержащая разветвления и дополнения дуг

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

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

Иногда функция разделяет дугу на ее компоненты точно так же, как призма разлагает свет на цвета. В этом случае для получения дополнительных сведений о содержании компонент и взаимосвязях между ними важно изучить, что выполняет эта функция. На рис. 5-4 дуга план выполнения заданий является дугой управления

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

5.3. Дуги могут быть "помещены в тоннель"

Потенциально все дуги на диаграмме, независимо от их содержания, могут быть "помещены в тоннель". Как указано в главе 3, помещение дуги в тоннель является способом скрытия ее источника или приемника. Эти два вида проходящих через тоннель дуг (со скрытыми источниками и приемниками) не проходят "сквозь" границу, определяемую блоком и его дугами. Начало проходящих через тоннель дуг, появляющихся из неизвестного источника, заключено в скобки, что указывает на появление этих дуг из некоторой

Рис. 5-2. Туннельные дуги позволяют “спрятать” некоторые подробности и показать необходимые детали


другой части модели или непосредственно извне. На диаграмме ЭМЦ/А1 (рис. 5-2) дуга
незанятый рабочий имеет начало, выходящее из тоннеля. Поэтому эта дуга не появляется на диаграмме ЭМЦ/АО. Конец входящих в тоннель дуг с неизвестным приемником заключается в скобки для указания, что эти дуги либо идут в другую часть модели, либо непосредственно выходят из модели, либо не рассматриваются более. Например, дуга механизма для блока 2 на диаграмме ЭМЦ/АО имеет входящий в тоннель конец и поэтому не появляется на диаграмме ЭМЦ/А1. Термин "тоннель" является здесь вполне подходящим, поскольку можно представлять себе входящую в тоннель дугу как бы "уходящей под землю".

"Тоннельные" обозначения были введены в SADT после нескольких лет интенсивного использования этой методологии в ряде областей. Опыт показал, что при описании сложных систем требуется большое число дуг для корректного и подробного представления системы. Часто эти дуги могут быть объединены, но иногда важные объекты системы, не показанные ранее на более высоких уровнях иерархии модели, появляются при описании новых деталей. Кроме того, эти детали обычно не столь важны, чтобы их показывать на более высоких уровнях модели. "Тоннельные" обозначения используются для того, чтобы избежать хаотического заполнения нежелательными подробностями диаграмм высокого уровня. Эти обозначения дают возможность управлять появлением необходимых деталей, не запутывая более общие описания родительских диаграмм. Рис. 5-2 дает хороший пример использования тоннельных дуг, позволяющих избежать появления нежелательных деталей на верхних уровнях модели. Дуга незанятый рабочий диаграммы ЭМЦ/А1 требуется на уровне блока управлять выполнением задания, но прохождение этой дуги по верхним диаграммам, включая диаграмму изготовить нестандартную деталь, могло бы только запутать их содержание. Так как дуга незанятый рабочий неуместна на диаграмме АО, она помещена в тоннель. Кроме того, "тоннельные" обозначения помогают скрывать сведения, необходимые только для верхних уровней модели. Это минимизирует вероятность загромождения диаграмм-декомпозиций необязательной информацией. Дуги с заключенными в скобки концами выполняют эти задачи, поскольку они не рассматриваются как часть границы при касании ими блока и, следовательно, не переносятся на диаграмму, декомпозирующую этот блок. На рис. 5-2 показано, как за счет помещения дуг механизмов в тоннель удается избежать загромождения декомпозиции диаграммы изготовить нестандартную деталь неинформативными или очевидными дугами механизмов, касающимися всех блоков. Они запутали бы декомпозиции, не добавив никакой новой информации. Это очень сильно тормозило бы дело, поэтому неинформативные дуги скрывают у границы блока.

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

5.4. Различие между входными дугами и дугами управления

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

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

Рис. 5-3 Отделение входов от управлений

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

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

5.5. Дуги механизмов определяют способы реализации функций

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

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

Механизмы (на диаграмме) определяют кто будет выполнять конкретные функции. Как указано на рис. 5-2, дуги механизмов на диаграмме изготовить нестандартную деталь уточняют, что главные функции экспериментального механического цеха будут выполняться представителями трех типов персонала: мастером, оператором, контролером. Это свидетельствует о совместном выполнении функции различными специалистами. Другими словами, несколько дуг механизмов, касающихся блока, могут представлять скоординированную деятельность.

Механизмы могут также указывать, что одни функции поддерживают выполнение других функций, поэтому они должны выполняться в требуемой последовательности. На рис. 5-4 показано, что блок подготовить рабочее место должен выполняться до блока обработать на станке и собрать, поскольку оборудованное рабочее место должно быть приготовлено до начала работы. В этом случае система требует определенной последовательности операций. На рис. 5-2 в диаграмме управлять выполнением задания исполнительская дуга механизма для блока 1 с меткой стеллаж входных заданий определяет, где искать вновь полученный рабочий комплект. В этом случае аналитик хотел подчеркнуть, что в экспериментальном механическом цехе стеллаж входных заданий важен для выполнения функции получить задание и назначить исполнителя. Все эти примеры свидетельствует о том, что при описании различных аспектов функционирования и реализации систем дуги механизмов имеют важное значение.

Рис. 5-4. Одни функции модели поддерживают выполнение других функций

5.6. Обратная связь по управлению и по потоку данных

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

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

Обратная связь по управлению появляется тогда, когда выходы двух функций воздействуют друг на друга. Классический сценарий "цыпленок и яйцо" иллюстрирует обратную связь по управлению. Диаграмма изготовить нестандартную деталь (рис. 5-2) показывает обратную связь по управлению между блоками управлять заданием, и выполнить задание через статус задания. В этом случае статус задания отражает пошаговое продвижение процесса выполнения задания в соответствии с графиком, определенным в плане выполнения задания. Опираясь на статус задания, управляющий пересматривает план выполнения задания, которые, в свою очередь, воздействуют на будущую деятельность рабочего, связанную с этим заданием. Это пример эффективной реализации системой функций по планированию и обработке с помощью обратной связи по управлению.

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

5.7. Резюме

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

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

Miller, J.: Living Systems, McGraw-HiIl, New York, 1978.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

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-73-C-5158, SofTech, Inc., 1981.


Глава 6. Более глубокие концепции моделей

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

6.1. Модели SADT структурируют естественный язык

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

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

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

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

Рис. 6-1. Описание границ SADT-модели

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

6.2. Точка зрения модели влияет на расстановку акцентов и терминологию

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

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

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

Рис. 6-2. Все обязанности сотрудников цеха имеют одинаковые степени важности

Рис. 6-3. Некоторые функции более важны для контролера

частью системы. Поскольку каждой роли, как правило, соответствует особый жаргон, выбор определенной точки зрения означает также использование соответствующего набора терминов. Обратите внимание на терминологию рис. 6-3, с помощью которой описана работа контролера с точки зрения начальника. Здесь используются термины типа стандарты допусков и принятое задание. Теперь сравните их с теми терминами на рис. 6-4, которые описывают обработку деталей с точки зрения начальника. В этом случае используются термины типа чертеж, сырье и набор инструментов. Читая эти две диаграммы, можно представить себе двух совершенно различных людей, беседующих о своей работе. Таким образом, автор будет оперировать той терминологией, которую он почерпнет, опрашивая соответственно контролера и оператора.

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

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

6.3. Декомпозиция в ходе моделирования

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

Следуя правилам SADT, автор производит вначале анализ и синтез системных объектов, записывая, как именно подверглись разбиению объекты, входящие в ограниченный объект. На рис. 6-5 показано, что список данных начинается со всех граничных дуг и их ICOM-кодов, а заканчивается их составляющими. Затем автор просматривает список данных и, возможно, объединяет эти составляющие, чтобы выделить те объекты, которые будут выступать в качестве управляющих.

Затем автор выполняет подобный анализ и синтез функций системы, но делает это в соответствии со списком данных. В процессе свободного объединения и введения новых управляющих дуг создается список функций для дальнейшей детализации. Например, указания и чертеж заставляют автора подумать о функциях выбрать инструменты и подготовить рабочее место. Функции вносятся в список до тех пор, пока поток идей не иссякнет. Затем эти функциональные части объединяются в разумные (сбалансированные) наборы из 3-6 блоков. (Важно заметить, что применение правила "от трех до шести блоков" вынуждает автора использовать абстракцию и декомпозицию для постепенного представления деталей системы.) После определения функциональных частей список данных и список функций используются для чернового варианта диаграммы. Снова выполняются анализ и синтез, в результате чего формируются наборы объектов, которые представляются дугами, соединяющими блоки.

Такая последовательность выполнения декомпозиции имеет большое значение, поскольку

Рис. 6-4. Терминология, связанная с изготовлением нестандартных деталей

Рис. 6-5. Пример анализа и синтеза в процессе декомпозиции


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

Правило "от трех до шести" блоков на одной диаграмме - тоже уникальная особенность SADT. Хорошо известно, что мощность краткосрочной памяти человека ограничена восприятием примерно семи категорий, каждая из которых может содержать около семи отдельных единиц информации. SADT придерживается консервативной точки зрения, разрешая в качестве верхнего предела шесть блоков - по одному на категорию. Имя блока и его граничные дуги представляют собой единицы информации, помещаемые в категории в процессе чтения диаграммы. Таким образом, SADT-диаграммы создаются так, чтобы не подвергать испытанию пределы краткосрочной памяти человека. Однако способности к запоминанию у различных людей различны. Наш опыт показывает, что диаграммы из 4-5 блоков с не более чем пятью дугами, касающимися каждого блока, приближаются к оптимальным по объему информации, которые можно быстро донести до широкой аудитории.

6.4. Некоторые стратегии декомпозиции

В процессе создания диаграммы авторы часто не уделяют достаточного внимания стратегии декомпозиции. Опытный SADT-автор в отличие от начинающих постоянно следит за стратегией декомпозиции и ее влиянием на качество модели. Ему доступно множество стратегий декомпозиции. (Этой проблеме посвящены целые книги, а в списке дополнительной литературы к данной главе приведены некоторые важные работы.) Рассмотрим в кратком обзоре некоторые наиболее часто применяемые стратегии, которым вы можете следовать, создавая модель.

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

Декомпозиция в соответствии с функциями, которые люди или организации выполняют, может оказаться полезной стратегией для создания системы описаний, фиксирующей взаимодействие между людьми в процессе их работы. Декомпозиция, приведенная на рис. 6-2, описывает взаимодействие персонала механического цеха и функции, выполняемые каждым отдельным лицом. Таким образом, эта диаграмма представляет общую картину работы механического цеха, а каждый из ее потомков дает более концентрированное описание определенного рода работы (управления заданием, обработки и контроля). Иногда взаимодействие между функциями невелико, как в механическом цехе. Очень часто, однако, взаимосвязи между функциями весьма многочисленны и сложны. Вот почему мы рекомендуем использовать эту стратегию только в начале работы над моделью системы из разряда, который часто называют РЗ - первые буквы английских слов people (люди), paper (бумаги), procedures (процедуры). Это поможет собрать исходную информацию о системе, с помощью которой можно создать более обоснованную функциональную декомпозицию системы в целом.

Эффективной стратегией для систем команд и управления может оказаться декомпозиция в соответствии с уже известными стабильными подсистемами. Это приводит к созданию набора моделей, по одной модели на каждую подсистему или важную компоненту. Затем для описания всей системы должна быть построена составная модель, объединяющая все отдельные модели. Авторы этой книги работали над проектом создания моделей отдельно для торпеды, отдельно для защиты от торпед и отдельно для движения подводной лодки, а потом объединили эти модели вместе для описания способов защиты подводной лодки. Мы рекомендуем использовать разложение на подсистемы, только когда разделение на основные части системы не меняется (например, ходовая часть и двигатель в автомобиле). Нестабильность границ подсистем быстро обесценит как отдельные модели, так и их объединение.

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

Если ничто другое не подходит, всегда можно применить декомпозицию по физическому процессу. Результатом такого сорта декомпозиции будет выделение функциональных стадий, этапов завершения или шагов выполнения. На диаграммах низкого уровня (А311, А312, А313) модели обучения из главы 13 подробно описана последовательность шагов, которую нужно выполнить, чтобы подготовить материал для обучения военных. Хотя эта стратегия полезна при описании существующих процессов (таких, например, как работа промышленного предприятия), результатом ее часто может стать слишком последовательное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг другу. При этом может оказаться скрытой последовательность управления. Мы рекомендуем эту стратегию, только если целью модели является описание физического процесса как такового или только в крайнем случае, когда вы не понимаете, как действовать.

6.5. Выбор стратегии декомпозиции

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

6.6. Момент прекращения декомпозиции определяется точностью

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

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

6.7. Резюме

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

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

Alexander, С.: Notes on the Synthesis of form, Harvard University Press, Cambridge, Mass., 1964.

Jackson, M.: System Development, Prentice-Hall, Englewood Cliffs, N.J., 1983.

Orr, K.: Structured Systems Development, Yourdon Press, New York, 1977.

Miller, G.: "The magical Number Seven, Plus Or Minus Two: Some Limits on Our Capacity for Information Processing", The Psychology Review, vol. 63, no. 2, March 1956.

Marca, D., and McGowan, C.: "Static and Dynamic Data Modeling for Information System Design", 6th International Conference on Software engineering Proceedings, September 1982.

Parnas, D.: "On the Criteria to be Used in Decomposing Systems into Modules", CACM, December 1972.

Pirsig, R.: Zen and the Art of Motorcycle Maintenance, Bantam Books, New York, 1974.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

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.


Часть II Создание функциональных моделей и диаграмм

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

В главе 7 обсуждаются навыки, которыми надо обладать, чтобы получить у экспертов информацию, необходимую для создания модели. В главе 8 описан этап анализа, на котором делают первую попытку создать модель. Глава 9 посвящена второму этапу анализа, на котором декомпозируется часть модели, созданной в главе 8. В главе 10 показано, как оценить собственную работу, прежде чем послать ее на рецензирование. В главе 11 приведен основной набор стандартных графических обозначений для упрощения SADT-диаграмм. В процессе изложения материала в этих главах обсуждаются способы опроса и методы анализа и синтеза. Модель экспериментального механического цеха используется для иллюстрации синтаксических правил диаграмм и моделей, процесса создания диаграмм и построения моделей. Таким образом, последовательно изучив материал этих глав, вы получите представление о том, как мыслит системный аналитик в процессе создания модели системы по методологии SADT.


Глава 7. Сбор информации

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

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

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

7.1. Источники информации

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

  •  чтение документов;
  •  наблюдение за выполняемыми операциями;
  •  анкетирование;
  •  использование собственных знаний;
  •  составление описания.

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

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

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

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

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

7.2. Типы опроса

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

  •  опросы для сбора фактов;
  •  опросы для определения проблем;
  •  совещания для принятия решений;
  •  диалоги автор/читатель.

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

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

7.3. Процесс опроса

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

7.3.1. Подготовка

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

Мы рекомендуем следующие шаги:

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

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

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

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

7.3.2. Проведение опроса

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

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

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

  •  Можете ли Вы привести пример?
  •  Когда это произошло?
  •  Есть ли у этого правила исключения?
  •  Можете ли Вы привести какие-нибудь цифры в подтверждение Ваших слов?

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

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

Любая из этих причин - достаточное основание для завершения беседы.

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

7.3.3. Завершение

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

7.4. Что нужно помнить при опросе

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

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

  •  уточняйте источники и назначение данных, их формат, сроки сохранения, предполагаемое использование, требуемые изменения, и т.д. Эти пояснения могут помочь определить, что представляют собой данные.

Следующие рекомендации, помогают поддерживать непрерывность потока и достоверность информации, поступающей от эксперта:

  •  делайте паузы, пока эксперт думает. Дайте эксперту возможность решать, что сказать дальше. Никогда не перебивайте, подсказывая ответ или задавая другой вопрос;

  •  старайтесь не задавать наводящих вопросов, вопросов-подсказок, вопросов, содержащих ответ, потому что это не позволяет эксперту делиться своими знаниями. Старайтесь не задавать контрольных вопросов, так как это прерывает поток информации;

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

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

7.5. Резюме

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

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

Bravoco, R.: "Supplementary Information Concerning Interview Standards and Techniques", SofTech, June 1976.

FitzGerald, J., and A. Fitz Gerald: Fundamentals of Systems Analysis, John Wiley, New York, 1973.

Freeman, P.: "Why Johnny Can't Analyze", Systems Analysis and Design: A Foundation for the 1980s Workshop Proceedings, September 1980.

Gorden, R.: Interviewing: Strategy, Techniques and Tactics, Dorsey Press, 1980.

Hartman, Matthes, and Proeme: Management Information Systems Handbook, McGraw-Hill, New York, 1968.

Kahn and Cannel: The Dynamics of Interviewing Theory, Techniques and Cases, John Wiley, New York, 1966.

Mumford, E.: Designing Human Systems for New Technology, Manchester Business School, Manchester, England, 1983.

Parkin, A.: Systems Analysis, Little Brown, Boston, 1980.

SofTech, Inc.: "Practical Aspects Of Data Collection, IDEFO Architects Guide", SofTech Deliverable no. 7500-10, September 1979.

Weinberg, G.: Rethinking Systems Analysis and Design. Little Brown, Boston, 1982.


Глава 8. Начало моделирования

Начало моделирования в SADT означает создание диаграмм АО и А-0, которые затем могут быть отрецензированы. Эти две диаграммы полностью рассказывают все об изучаемой системе с минимальной степенью детализации. Создавая их, аналитик предпринимает начальную попытку декомпозировать систему и затем обобщить полученную декомпозицию. Декомпозиция (диаграмма АО) освещает наиболее важные функции и объекты системы. Объединение (диаграмма А-0) трактует систему как "черный ящик", дает ей название и определяет наиболее важные входы, управления, выходы и, возможно, механизмы.

8.1. Основные этапы

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

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

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

8.2. Выбор цели и точки зрения

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

Рис. 8-1. Определение целей и точки зрения

Рис. 8-2. Подготовка списка функций и списка данных


Рис. 8-3. Диаграмма АО

Рис. 8-4. Диаграмма А-О


Иногда оказывается, что определить цель и точку зрения в самом начале моделирования чрезвычайно трудно. В таком случае мы советуем составить списки данных и функций и, может быть, нарисовать диаграмму АО. Сделав это, вы начнете чувствовать систему и установите, описывает ли ее диаграмма АО с нужной точки зрения. Может быть, вам придется нарисовать несколько альтернативных АО-диаграмм, прежде чем появится достаточная уверенность для того, чтобы осуществить выбор правильной цели и точки зрения. Мы настоятельно рекомендуем именно такую последовательность действий, если вы не убеждены в правильности цели и направленности своей работы. Уроки к I и II частям демонстрируют, как составление списков начальных данных и функций служит ценной преамбулой для определения цели и точки зрения модели.

8.3. Составление списка данных

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

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

SADT-диаграммы представляют границы функций и ограничения, накладываемые на них, причем ограничения должны присутствовать во всех системах. Указывая вначале ограничения, мы выявляем естественную структуру системы. Без ограничений функциональная SADT-диаграмма представляет собой не более чем схему потоков данных. Без ограничительных дуг диаграммы не смогут рассказать читателю, почему аналитик выбрал именно данную декомпозицию. Благодаря тому, что в SADT различаются входные дуги и дуги управления (информация, необходимая для пояснения декомпозиции), SADT-диаграммы ясно объясняют изучаемую систему и причину такой декомпозиции.

8.4. Составление списка функций

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

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

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

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

8.5. Построение диаграммы АО

Исходное содержание диаграммы АО обеспечивают списки данных и функций. Для правильного описания системы содержанию надо придать форму. В SADT это делается посредством построения диаграммы. Начинающим авторам мы советуем придерживаться определенного порядка: (1) расположите блоки на странице, (2) нарисуйте основные дуги, представляющие ограничения, (3) нарисуйте внешние дуги и (4) нарисуйте все оставшиеся дуги. Со временем накопленный опыт позволит вам отойти от этой процедуры и изображать блоки и дуги в соответствии с той идеей, которую вы хотите воплотить в диаграмме.

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

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

Основными дугами, представляющими ограничения, всегда являются внешние дуги, т.е. дуги, представляющие данные, поступающие из непосредственного окружения диаграммы.

Следующим шагом в построении диаграммы является размещение остальных внешних дуг и назначение им соответствующих ICOM-кодов. Таким образом, все данные, входящие в систему или выходящие из нее, оказываются учтенными на рисунке. Потеря внешней дуги - это ошибка интерфейса, одна из самых распространенных в системном анализе. Занимаясь декомпозицией объекта, можно забыть об интерфейсных данных, потому что очень легко сосредоточиться на деталях. Начиная с изображения всех внешних дуг, вы повысите точность диаграммы, включив все интерфейсные данные. И наконец, нарисуйте все остальные дуги, отражающие детали работы системы в целом. Во-первых, нарисуйте оставшиеся ограничения, действующие между блоками. Например, рассматриваемый чертеж влияет на проверку детали. Во-вторых, нарисуйте основной поток данных. На рис. 8-3 показана обработка сырья и заготовок в соответствии с планом. выполнения задания и контроль качества выполнения задания (иногда неоднократный) и в соответствии с чертежом. В-третьих, рассмотрите все "патологические" потоки данных (случаи возникновения ошибок). В-четвертых, уточните обратные связи в потоках данных. Например, забракованное задание снова попадает в цикл в качестве брака. В заключение изобразите все обратные связи, вызываемые ошибочными ситуациями.

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

8.6. Обобщение диаграммы АО

Обобщение является последним важным шагом начального этапа моделирования. Вспомните, что для любой SADT-диаграммы есть родительская диаграмма, содержащая ее контекст, где под контекстом понимается блок с набором входных дуг, дуг управления и выходных дуг. Верхняя диаграмма модели (т.е. диаграмма АО) не составляет исключения. Контекстом для нее служит диаграмма А-0, представляющая собой обобщение всей модели. Диаграмма А-0 имеет несколько предназначений. Во-первых, она объявляет общую функцию всей системы. Например, блок на рис. 8-4 с названием изготовить нестандартную деталь ясно указывает, что делает цех. Во-вторых, она дает множество основных типов или наборов данных, которые использует или производит система. Например, справочник стандартов качества позволяет осуществлять контроль качества при выполнении задания. В-третьих, А-0-диаграмма указывает взаимоотношения между основными типами данных, проводя их разграничение. Например, рабочий комплект рассматривается как входное данное, нечто, изменяемое процессом, в то время как справочник стандартов качества контролирует выполнение цехом заданий. Таким образом, А-0-диаграмма представляет собой общий вид изучаемой системы.

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

В процессе обобщения вы убедитесь в том, что он помогает прояснить описание системы, потому что при обобщении вы просматриваете метки дуг для более точного наименования данных, которыми обмениваются система и ее среда. Кроме того, во время обобщения дуги часто объединяются для упрощения изображения модели. В этом случае дуги разветвляются на свои составляющие на диаграмме АО. Например, на диаграмме АО, приведенной на рис. 8-3, указано, что сырье и заготовки входят в состав рабочего комплекта.

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

8.7. Резюме

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

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

DeMarco, Т.: Structured Analysis and System Specification, Yourdon Press, New York, 1978.

DeMarco, Т.: "Specification modeling", Guide50 Proceedings, 1980.

Greenspan, S., and J. Mylopoulos: "Capturing More World Knowledge in the Requirements Specification", 6th International Conference on Software Engineering Proceedings, September 1982

Jackson, M.: System Development, Prentice-Hall, Englewood Cliffs, N.J., 1983.

Marca, D.: Applying Software Engineering Principles, Little Brown, Boston, 1984.

Orr, K.: Structured Systems Development, Yourdon Press, New York, 1977.

Ross D.: "Some Further Observations about Structured Analysis", SofTech Technical Report no. 9031-6, January 1976

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

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) Final Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.


Глава 9. Продолжение моделирования

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

9.1. Декомпозиция ограниченного объекта

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

  1.  выбор блока диаграммы;
  2.  рассмотрение объекта, определенного этим блоком;
  3.  создание новой диаграммы;
  4.  выявление недостатков новой диаграммы;
  5.  создание альтернативных декомпозиции;
  6.  корректировка новой диаграммы;
  7.  корректировка всех связанных с ней диаграмм.

Шаги 1-3 представляют созидательную часть процесса. Выполняя их, аналитик концентрирует свои усилия, связанные с выявлением новой информации об объекте, на более высоком уровне детализации, чтобы достичь ясности изложения. Шаги 4-7 составляют этап саморецензирования, в ходе которого аналитик, создав новую диаграмму, проверяет, какую она несет информацию и в каком она находится отношении с родительской диаграммой. Затем в созданную диаграмму и соответственно в связанные с ней диаграммы вносятся изменения, чтобы достичь ясности для других. В этой главе мы подробнее рассмотрим шаги 1-3. Шаги, связанные с саморецензированием и последующими изменениями, обсуждаются в главе 10.

9.1.1. Выбор блока

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

Рассмотрим диаграмму АО для модели экспериментального механического цеха ( рис. 9-1). На ней три блока: управлять выполнением задания, выполнить задание и контролировать качество выполнения. На первый взгляд кажется, что управлять выполнением, задания является самым сложным блоком, потому что он самый доминантный и с ним связано самое большое количество дуг. Но при внимательном рассмотрении можно заметить, что многие из его дуг являются просто обратными связями или выходами. Контролировать качество выполнения, видимо, является простейшей функцией, так что ее декомпозиция не даст нам много новой информации. Поэтому эти два блока - плохие кандидаты для первой декомпозиции. Выполнить задание выглядит более интересным, потому что этот блок участвует во многих циклах и имеет широкий спектр входов, управлений и выходов. Поняв, как рабочий выполняет задание, мы, видимо, окажемся в лучшем положении для дальнейшей декомпозиции остальной части модели.

9.1.2. Объект, определяемый блоком

Блок 2, выполнить задание, становится теперь самостоятельным объектом декомпозиции. Для выполнения этой декомпозиции вначале бегло осмотрим обобщающую диаграмму (посмотрите, пожалуйста, диаграмму А-0 на рис. 8-4) и вспомним цель и точку зрения модели. Сделав это, мы увидим, что должны описать блок выполнить задание с точки зрения начальника цеха, чтобы можно было разработать инструкции для обучения нового персонала цеха. Кроме того, мы изучим блок 2 диаграммы АО и соединенные с ним дуги, чтобы выявить его особенности. Например, дуга механизма с названием рабочий указывает, что мы можем, декомпозировав этот блок, выявить, чем занимаются рабочие.

Затем мы составляем список данных со всех дуг, касающихся блока, используя ICOM-ко-дирование для того, чтобы не потерять какие-либо интерфейсные данные. Например, план выполнения задания, станки и инструменты, а также брак входят в начальный список данных (см. верхнюю левую колонку на рис. 9-2). Этот список теперь улучшается благодаря декомпозиции первоначальных данных или введению новых, тесно связанных данных. Например, при дальнейшем рассмотрении плана выполнения задания возникла мысль об указаниях. Далее, мы составляем на основе списка данных список функций, придерживаясь функции, соответствующей блоку верхней диаграммы. Обратите внимание на то, что выбрать инструменты, подготовить рабочее место, обработать на станке и собрать и определить степень выполнения задания, по-видимому, действительно являются функциями, выполняемыми рабочим при выполнении задания.

Стремитесь ограничиваться разумным уровнем сложности при объединении функций и данных: четыре-пять функциональных блоков, как правило, лучше всего. Слишком много данных и функций часто содержат слишком много информации. Это приводит к запутанным диаграммам. Наоборот, небольшое число блоков дает слишком мало, и диаграмма становится почти бесполезной. Если вы уверены, что достигли баланса, проверьте, во всех ли отношениях написанные вами слова адекватны объекту, определенному блоком и его граничными дугами на родительской диаграмме. Теперь у вас есть все необходимое для построения диаграммы.

9.1.3. Создание новой диаграммы

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

На рис. 9-2 показан результат работы SADT-автора, который сделал набросок диаграммы ограниченного объекта. Вот некоторые важные моменты этой диаграммы: дуга следующий шаг задания является носителем очень существенной информации - она определяет, что нужно сделать на следующем шаге задания. Следовательно, поскольку она ограничивает все остальные функции, блок определить степень выполнения, порождающий дугу следующий шаг задания, является самым доминантным на этой диаграмме. План выполнения задания (С1), очевидно, требуется прежде, чем что-нибудь может произойти, потому что содержимое этой внешней дуги определяет последовательность шагов обработки. Поэтому управляющая дуга очень важна. Кроме того, автор стремился отразить на диаграмме потоки информации, в особенности потоки информации обратной связи. Обратите внимание на то, что результаты обработки есть обратный вход от блока обработать на станке и собрать к блоку определить степень выполнения задания. Это означает: результат обработки есть незаконченное задание, получаемое на каждом шаге выполнения задания, что в полной мере соответствует действительности.

Рис. 9-1. Диаграмма АО готова к декомпозиции


Рис. 9-2. Предварительные наброски для декомпозиции функционального блока

9.2. Выявление интерфейсных ошибок

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

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

9.3. Принципы и приемы расположения дуг

Дуги выражают связи между блоками. Их вычерчивают не для показа последовательности действий. Они отражают отношения между блоками, независящие от потенциального следования. Например, диаграмма на рис. 9-2 не указывает возможной последовательности действий. В частности, функции выбрать инструменты может как встретиться, так и не встретиться перед функцией подготовить рабочее место. Это зависит от того, каким является следующий шаг задания. Если же оборудованное рабочее место уже создано, блок обработать на станке и собрать может выполняться неоднократно, пока не возникнет потребность в выполнении следующего шага задания. Такой механизм приводит к реализации различных сценариев, активизируя блоки в различные моменты времени в зависимости от ситуации.

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

9.4. Резюме

Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы. В процессе декомпозиции целесообразно проверять 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.


Глава 10. Проверка диаграммы автором

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

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

10.1. Процесс авторской проверки

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

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

  1.  выявление недостатков новой диаграммы;
  2.  создание альтернативных декомпозиции;
  3.  корректировка новой диаграммы;
  4.  корректировка всех связанных с ней диаграмм.

Часто в ходе критической оценки выполняют альтернативные декомпозиции, чтобы проверить, является ли исходный набросок лучшим для передачи желаемой информации. Кроме того, проверяют взаимосвязи с родительской и другими диаграммами. После этого во все диаграммы вносятся необходимые изменения. Действия автора во время критической оценки весьма сходны с действиями читателей при рецензировании. Поэтому всегда учитывайте приведенные в главе 14 рекомендации, связанные с чтением диаграмм, моделей и замечаний.

10.2. Выявление недостатков новой диаграммы

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

Рис. 10-1. Диаграмма после критики рецензента

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

10.2.1. Вопросы о блоках

Вначале следует критически оценить блоки диаграммы. Определим функциональные аспекты диаграммы, задавая вопросы типа:

  •  Представляют ли блоки содержательную декомпозицию функции?
  •  Не выглядит ли диаграмма запутанной?
  •  Все ли блоки соответствуют точке зрения модели ?
  •  Несут ли блоки достаточный объем новой информации ?
  •  Все ли блоки имеют одинаковый уровень детализации ?
  •  Соразмерна ли сложность всех блоков?
  •  Отражает ли каждый блок какой-либо аспект блока родительской диаграммы?

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

10.2.2. Вопросы о связи с родительской диаграммой

Теперь зададим вопросы о связи диаграммы с ее родителем. При этом мы проверим, как диаграмма вписывается в модель.

  •  Все ли внешние дуги имеют ICOM-коды?

Рис. 10-2. Примеры расположения дуг

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

Замечания 3 и 4 на рис. 10-1 исправляют ошибку в названии дуги (12) станки и инструменты, а замечания 7 и 8 отражают развитие спора автора с самим собой относительно природы отходов и сырья - проблема, которая нередко возникает в связи с производственными процессами.

10.2.3. Вопросы о внутренних дугах

Вопросами о внутренних дугах обычно заканчивают поиск ошибок в диаграмме. Теперь, после разрешения основных вопросов, следует проанализировать детали диаграммы. Мы можем задать вопросы типа:

  •  Не слишком ли много внутренних дуг?
  •  Нет ли блоков без дуг управления?
  •  Нет ли блоков без выходных дуг?
  •  Правильно ли отражают дуги, представляющие ограничения, доминирование блоков?
  •  Верно ли решение диаграммы?
  •  Все ли важные обратные связи отражены?
  •  Все ли ошибочные ситуации учтены?

Замечания 1 и 2 на рис. 10-1 показывают, что автор изменил свое мнение относительно взаимоотношения дуги результаты обработки и внешнего входа сырье и заготовки. Окончательное решение заключается в том, что они не очень близки и должны быть разделены. Метка следующий шаг задания уточняет, что именно управляет функцией обработать на станке и собрать.

10.3. Создание альтернативных декомпозиций

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

10.3.1. Альтернативная декомпозиция и объединение функций

Иногда у аналитика возникают сомнения относительно блоков диаграммы. На хорошей SADT-диаграмме блоки должны обладать некоторыми важными качествами:

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

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

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

10.3.2. Альтернативное объединение и разъединение дуг

Иногда можно обнаружить две дуги, которые начинаются и кончаются в одних и тех же местах диаграммы. То есть обе дуги начинаются и кончаются у одних и тех же блоков (см. рис. 10-2). В этом случае посмотрите на эти две дуги внимательно. Может оказаться, что их следует объединить в одну. Если вы можете придумать хорошее наименование, объединяющее названия этих дуг, объедините их. Если наличие двух дуг имеет определенный смысл, не объединяйте их. Объединение скрывает детали, поэтому не делайте это механически. Исчезновение деталей повредит диаграмме. Например, замечания 7 и 8 на рис. 10-1 отражают попытку объединить брак и сырье, отвергнутую из-за того, что они оказались различными вещами.

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

Рис. 10-3. Пересмотренная диаграмма

10.3.3. Тестирование

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

Рассмотрим, что описывает диаграмма выполнить задание, начиная обрабатывать новое задание: изучается план выполнения задания и выбирается следующий шаг задания. Это определяет, какие выбрать инструменты и как подготовить рабочее место. Затем сырье и брак обрабатываются на станке и собираются и выдаются результаты обработки. Далее по этим результатам определяется степень выполнения задания и выбирается следующий шаг задания.

10.3.4. Схематичное изображение декомпозиции следующего уровня

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

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

10.4. Корректировка новой диаграммы

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

10.4.1. Переопределение доминирования

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

10.4.2. Содержательные названия блоков

Для блоков обычно стараются выбрать содержательные название. Однако в SADT нет необходимости выражать все с помощью названий блоков, потому что о работе блока многое сообщают метки окружающих его дуг. Например, детали, сырье и брак превращаются в результаты обработки, в соответствии со следующим шагом задания. Читая дуги блока 4 на рис. 10-3, можно довольно хорошо разобраться в работе блока обработать на станке и собрать. Таким образом, более подробное название блоку не требуется. Оно может только затруднить понимание.

10.4.3. Дуги, хорошо передающие информацию о себе

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

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

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

10.4.4. Пояснения

Закончив построение диаграммы, поясните ее важные аспекты с помощью замечаний или дополнительного материала. Однако будьте осторожны с пояснениями: не используйте их как прикрытие плохого построения диаграмм. Проясняйте только те понятия, которые нельзя изобразить в виде блоков и дуг. Например, пометить дугу 11 на рис. 10-3 словом материалы и сделать замечание, что материалы - это сырье, заготовки, хуже, чем просто пометить дугу этими двумя этими словами. С другой стороны, описание типичных незаконченных заданий существенно облегчит объяснение того, как они должны быть завершены.

10.5. Исправление взаимосвязанных диаграмм

Создание диаграммы, ответы на связанные с ней вопросы и переделка ее обеспечивают более глубокое понимание родительской диаграммы и диаграмм - потомков вновь построенной диаграммы. Зафиксируйте свое понимание во время исправления диаграммы. (Это как раз тот случай, когда перенесение информации снизу-вверх естественным образом вписывается в технику декомпозиции.) Автор вынужден переносить информацию на другие диаграммы в трех ситуациях: при изменении меток внешних дуг, при появлении новых внешних дуг и при перераспределении функций.

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

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

10.6. Резюме

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

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

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and G. Weinberg: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and G. Weinberg: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19-5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July 1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.


Глава 11. Соглашения по построению диаграмм

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

11.1. Соглашения по размещению блоков

1. Располагайте блоки по диагонали - от левого верхнего угла диаграммы до правого нижнего, и пронумеруйте их в том же порядке.

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

2. Разместите номер каждого блока в его нижнем правом углу. Стандартное расположение номеров позволяет их быстро находить.

3. Запишите С-номер диаграммы, декомпозирующей блок, под правым нижним углом блока. При таком расположении его легко найти. Кроме того, номер блока наглядно связывается с детализирующей его диаграммой.

11.2. Соглашения по размещению дуг

1. Чертите дуги только по вертикали и горизонтали. Таким образом блоки будут визуально выделяться как точки сбора дуг, которыми блоки и являются. Это помогает также проследить за направлением дуг.

2. Блоки всегда имеют дуги управления, но могут не иметь входных дуг. Дуги управления накладывают ограничения и включают или выключают функции системы. Без них система не может работать.

3. Если данные служат и для управления, и для входа, вычерчивайте только дугу управления. Этим вы уменьшаете сложность общей картины и делаете очевидным управляющий характер данных.

4. Максимально увеличьте расстояние между параллельными дугами, оставляя больше места для меток. Это помогает зрительно определять количество дуг и прослеживать их пути.

5. Максимально увеличьте расстояние между блоками и поворотами дуг, а также между блоками и пересечениями дуг, чтобы облегчить процесс чтения и уменьшить вероятность перепутать две разные дуги.

6. Объедините дуги, источники которых не указаны на диаграмме, если они представляют одни и те же данные. Этим вы графически покажете единый источник сходных данных.

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

11.3. Соглашения по размещению блоков и дуг

1. Объединяйте дуги с общим источником или с общим приемником, если они представляют связанные данные. Общее название лучше описывает суть данных.

2. Минимизируйте число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна.

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

4. Обратные связи по входу рисуйте "вниз и под". Это позволит показать обратные потоки данных при минимальном числе линий и пересечений, а также собрать все входные дуги в нижней левой части диаграммы.

5. Если возможно, присоединяйте дуги к блокам в одной и той же ICOM-позиции. Соединения дуг конкретного типа с блоками будут согласованными, и тем самым вы упростите чтение диаграммы.

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

7. Минимизируйте число петель и поворотов каждой дуги. Это также упростит диаграмму.


11.4. Резюме

Соглашения по размещению элементов SADT-диаграмм строго следуют схеме вычерчивания сверху вниз и слева направо. Блоки обычно располагают по ступенчатой схеме; дуги подходят к блокам под прямым углом. Расстояния между дугами сохраняются максимальными, и они всегда одинаковы. Когда несколько дуг однородной природы идут из одного блока в другой, они часто объединяются в единую дугу- Обратные связи по управлению всегда чертят "вверх и над". Циклические обратные связи изображаются редко.

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

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19-5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July 1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.


Часть III Рецензирование диаграмм и моделей

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

Основные этапы цикла автор/читатель изложены в пяти главах. В главе 12 дан общий обзор процесса рецензирования. В главе 13 приведено определение SADT-папки и описаны методы ее формирования. В главе 14 показано как нужно читать папки, что необходимо делать всем, кто работает над SADT-проектом. В главе 15 показано, как должен читатель записывать свои замечания, пожелания и сообщения, возникающие в процессе чтения материалов папки. В главе 16 обсуждаются ответы автора на замечания рецензентов и их обобщения. На протяжении этих глав полностью прослеживается цикл автор/читатель на примере папки, содержащей некоторую часть материалов модели экспериментального механического цеха. В процессе изложения иллюстрируется: (1) как на титульном листе папки отмечается ее продвижение по циклу автор/читатель, (2) как читатель изучает папку, (3) как читатель записывает в ней комментарии, (4) как автор письменно отвечает на комментарии читателей. Проследив этот цикл, вы получите четкое представление о том, какие нужны специалисты для участия в нем, а также о методах и процедурах для быстрого получения полезных рецензий на документы папки.


Глава 12. Цикл автор/читатель

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

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

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

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

12.1. Составление исходной документации

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

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

Рис. 12-1. Процесс проверки модели в SADT

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

12.2. Комментирование работы

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

Как только у читателя возникает какой-либо вопрос или предложение, он записывает его красным цветом (в книге записи показаны светло-серыми) в форме замечания. С этих записей начинается письменный диалог между читателем и автором, в ходе которого немедленно фиксируются все сомнения читателя. Этот прием немедленной записи сомнений очень важен. Он служит гарантией, что ни одна идея, возникшая в ходе проектирования, не пропадет. Детали беседы часто забываются, а к диалогу в письменной форме всегда можно обратиться при решении проблем или повторном просмотре материалов. Обратите внимание на рис. 12-3: читатель согласился помочь автору, сделав соответствующую пометку на титульном листе, поместив комментарии на диаграмме, проставив дату комментирования и указав срок ответа для автора.

Рис. 12-2. Титульный лист папки и диаграмма, подготовленная автором

12.3. Ответы на комментарии

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

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

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

12.4. Совершенствование моделей

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

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

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

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

Рис. 12-3. Титульный лист папки и диаграмма после рецензирования


Рис. 12-4. Диаграмма и титульный лист с ответами автора


12.5. Цикл автор/читатель

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

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

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

12.6. Резюме

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

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

Curtis, В. (ed): "Human Factors in Software Development", IEEE Catalog no. EHO 185-9, IEEE Computer Society, 1981.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Kemmer, R.: "Testing Formal Specifications to Detect Design Errors", IEEE Transactions on Software Engineering, vol. 11, no. 1, January, 1985.

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

Mumford, E.: Designing Human Systems for New Technology, Manchester Business School, Manchester, England, 1983.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.

Weinberg, G.: The Psychology of Computer Programming, Van Nostrand Reinhold, New York, 1971.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1978.


Глава 13. Подготовка папки

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

13.1. Обмен информацией с помощью папок

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

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

Взаимодействие между автором и читательской аудиторией изображено на рис. 13-1 в виде цикла, в ходе которого созданные автором папки изучаются читателями и возвращаются к автору, который читает их и снова отсылает читателям.

13.2. Титульный лист

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

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

Рис. 13-1. Папки циклически перемещаются между автором и читателями


Рис. 13-2. Зоны и области титульного листа
SADT-папки

статус материалов и С-номера. В области 2, предназначенной для информации о содержании папки, авторы записывают номер узла и название папки, а также номер узла, название и С-номер для каждой страницы папки. В области 3 записываются фамилии тех, кому папка должна быть послана. Замечания о папке в целом автор помещает в область 4, а в области 5 он размещает специальные инструкции для библиотекаря.

13.3. Организация папки

SADT-папка состоит из титульного листа, одной или более диаграмм и, возможно, дополнительного материала. Титульный лист содержит название и краткое содержание рабочих материалов и служит для сопровождения папки в цикле общения автора с читателями. Диаграммы располагаются после титульного листа в порядке возрастания номеров узлов. Листы иллюстраций и глоссария, которые дополняют диаграммы, располагаются сразу же после тех диаграмм, к которым они относятся (дополнения к диаграммам подробно рассматриваются в главе 18).

На рис. 13-3 показана SADT-папка, содержащая результаты анализа, проведенного в части I, где обсуждались начало разработки и частичная декомпозиция модели экспериментального механического цеха. На титульном листе указано, что эта папка относится к декомпозиции объекта выполнить задание, на диаграмме ЭМЦ/А2. Кроме того, на титульном листе помещено замечание автора, в котором он просит объяснить понятие деталь. Диаграмма ЭМЦ/АО изготовить нестандартную деталь расположена перед диаграммой выполнить задание для того, чтобы обеспечить читателей контекстом. Лист глоссария ЭМЦ/А2Г1 определяет терминологию, введенную на диаграмме выполнить задание. Он расположен после диаграммы.

13.4. Размеры папки

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

Рис. 13-3. Заполненный титульный SADT-папки

Рис. 13-4. Подготовка страницы глоссария

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

13.5. Когда формировать папку

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

13.6. Резюме

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

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

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

King, L: "Guidelines for an SADT Chief Author", SofTech Deliverable no. 9595-2, 1980.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

Глава 14.Чтение диаграмм и моделей

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

14.1. Процедура чтения

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

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

14.2. Изучение деталей диаграммы

Для понимания деталей отдельной диаграммы необходимо: (1) прочитать название и номер узла, (2) изучить каждый блок, (3) изучить внутренние дуги; (4) прочитать все замечания автора; (5) просмотреть весь связанный с диаграммой дополнительный материал. Чтение осуществляется наиболее эффективно, если все эти элементы диаграммы читаются последовательно. По мере обсуждения этой части процесса обращайтесь к рис. 14-1 и 14-2.

14.2.1. Прочитайте название и номер узла

Начните читать диаграмму с просмотра бланка, обратив особое внимание на название и номер узла диаграммы. Например, диаграмма выполнить задание (рис. 14-2) имеет номер узла ЭМЦ/А2 и является диаграммой второго уровня модели экспериментального механического цеха. Следовательно, на ней начинается описание некоторых деталей работы механического цеха. Используйте название и номер узла для того, чтобы сосредоточиться на обсуждаемом объекте и уровне его детализации в модели.

14.2.2. Изучите каждый блок

Теперь изучите каждый блок в отдельности. Постарайтесь понять его во всей полноте, т.е. что он делает (его функции), что он преобразует


Рис. 14-1. Титульный лист папки и родительская диаграмма

Рис. 14-2. Диаграмма с дополнительным материалом


(его входы и выходы) и что ограничивает его выполнение (его управления). Сосредоточившись на конкретном блоке, вы сможете установить, как связаны все касающиеся его дуги. Например, блок 3 на рис. 14-2 описывает шаг
подготовить рабочее место, во время которого выбранные инструменты и один из станков в цехе используются для организации оборудованного рабочего места в соответствии с чертежом и указаниями.

14.2.3. Изучите внутренние дуги

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

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

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

14.2.4. Прочитайте авторские замечания

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

14.2.5. Прочитайте приложения к диаграмме

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

14.3. Изучение ближайшего контекста диаграммы

Изучив все внутренние детали диаграммы, сосредоточьтесь на их контексте, определив связи между диаграммой и ее родителем. Вы получите более глубокое понимание диаграммы, потому что граница объекта определяет, как диаграмма входит в остальную часть модели. Понять контекст диаграммы позволяет чтение: (1) блока и дуг, появляющихся на родительской диаграмме, представляющих ограничения для изучаемой диаграммы (2) ICOM-меток диаграммы, (3) связей этой диаграммы с другими блоками родительской диаграммы, (4) дополнительного к родительской диаграмме материала. Элементы этой диаграммы также читаются последовательно.

14.3.1. Чтение родительского блока и его дуг

Начните с чтения блока родительской диаграммы. Это освежит в памяти представление об общей функции диаграммы и ее взаимосвязей с остальными частями модели. Например, диаграмма ЭМЦ/АО (рис.14-1) обобщает функцию выполнить задание как процесс, который преобразует сырье и заготовки и брак в законченное или незаконченное задание в соответствии с планом выполнения задания. При этом используются станки и инструменты и иногда докладывается о статусе задания.

14.3.2. Чтение ICOM-кодов

Теперь прочтите внешние дуги диаграммы и определите их ICOM-коды. Проверьте соответствие каждого ICOM-кода одной из граничных дуг родительской диаграммы. Отметьте все несоответствия или пропуски. Таким образом вы удостоверитесь в том, что автор в процессе анализа ничего не пропустил из необходимых данных. На диаграмме ЭМЦ/А2 брак имеет ICOM-код 13, что соответствует (счет ведется сверху вниз) третьей входной дуге блока 2 на диаграмме ЭМЦ/АО.

14.3.3. Изучение связей диаграммы с ее родителем

Изучив соответствующий блок родительской диаграммы, перейдите к просмотру других блоков. Проследите каждую внешнюю дугу диаграммы до ее соприкосновения с другим блоком родительской диаграммы и разберитесь в причине соединения. Это поможет понять источники и приемники данных для рассматриваемой диаграммы. Например, брак получается из забракованного задания, а статус задания докладывается мастеру.

14.3.4. Чтение дополнительного материала родительской диаграммы

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

14.4. Уточнение места диаграммы в модели

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

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

Рассмотрим диаграммы А-0, АО и А2 модели экспериментального механического цеха, представленные на рис. 6-1, 14-1 и 14-2. Читая эти диаграммы в указанном порядке, мы заметим, что: (1) станки и инструменты оказываются основным входом цеха с точки зрения начальника, (2) рабочий комплект, по-видимому, является единственным источником плана выполнения задания, (3) справочник стандартов качества, похоже не оказывает никакого воздействия на процессы обработки. Страницы глоссария для диаграмм А-0 и АО объяснят природу этих объектов более подробно и, следовательно, помогут прояснить, почему диаграммы именно так описывают ситуацию.

14.5. Критическая оценка содержания диаграммы

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

1. Верен ли синтаксис диаграммы?

2. Понимаю ли я, что хотел сказать автор ?

3. Согласен ли я с тем, что выразил автор?

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

14.5.1. Вопросы о синтаксисе

Анализируя детали диаграммы, задавайте себе вначале следующие вопросы, особенно если вы только начинаете читать SADT-диаграммы или если автор только начинает работать с применением SADT:

  •  Все ли блоки правильно пронумерованы?
  •  Все ли блоки имеют названия в глагольной форме?
  •  Все ли дуги на месте?
  •  Все ли дуги имеют названия в форме существительного ?
  •  Все ли метки ясно привязаны к своим дугам?
  •  Есть ли на длинных дугах дополнительные метки?
  •  Нет ли дуг без меток?

Изучая непосредственный контекст диаграммы, задавайте следующие вопросы:

  •  У всех ли внешних дуг есть ICOM-код?
  •  Верно ли связывает ICOM-код внешние дуги с граничными дугами родителя?
  •  Все ли метки внешних дуг совместимы с метками граничных дуг родителя?
  •  Не используется ли помещение дуг в тоннель (скобки рядом с их концами) избыточно или неверно?

14.5.2. Вопросы о понимании диаграммы

Чтобы понять содержание диаграммы, нужно проследить ход событий, изложенных на ней, последовательно проверяя, как работают блоки, как и почему они влияют друг на друга и почему данные преобразуются указанным образом. Делая это, вы начинаете проверять декомпозицию. Анализируя каждый блок, спрашивайте себя:

  •  Какова роль этот блока в диаграмме?
  •  Как активизируется этот блок?
  •  Ясна ли роль каждой дуги?
  •  Как данный блок преобразует свои входы в выходы?
  •  Ясно ли, как исправить серьезные ошибки ?

При чтении внутренних дуг для определения основного пути потока данных, спрашивайте себя:

  •  Ясна ли основная линия изложения?
  •  Понятны ли побочные потоки данных?
  •  Соответствует ли терминология изложению?

Разбирая ближайший контекст диаграммы, отвечайте на вопросы:

  •  Как декомпозируют блоки родительский блок?
  •  Каковы источники и приемники всех внешних дуг?
  •  Ясны ли основные входы, управления и выходы?

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

 

  •  Не слишком ли много (или мало) блоков ?
  •  Не нужно ли блоки переопределить?
  •  Не перегружена ли (или достаточно ли заполнена) часть диаграммы?
  •  Не слишком ли много дуг?
  •  Не запутаны ли пересечения дуг?
  •  Нет ли нескольких дуг с одним и тем же ICOM-кодом?
  •  Не слишком ли длинны или многословны метки?
  •  Не слишком ли много жаргона?
  •  Соответствует ли терминология точке зрения аудитории, для которой диаграмма предназначена?

14.5.3. Вопросы о согласии с автором

Согласие с автором основывается на сравнении с: (1) вашим пониманием содержания диаграммы, (2) вашим пониманием того, что должна содержать диаграмма. Поэтому для решения вопроса о согласии с автором нужно провести оценку декомпозиции, цели и точки зрения диаграммы, адекватности описания, точности изображения, активизации блоков.

Чтобы оценить декомпозицию диаграммы, спросите себя:

  •  Достаточна ли полная декомпозиция?
  •  Не отсутствует ли какой-нибудь блок?
  •  Нет ли блока, не относящегося к делу?
  •  Нет ли в декомпозиции каких-либо неожиданностей ?
  •  Не сделал бы я совершенно другую декомпозицию ?
  •  Чтобы определить цель и точку зрения диаграммы, уточните:
  •  На какие вопросы отвечает эта диаграмма?
  •  Соответствует ли это цели модели?
  •  С чьей точки зрения описана модель?
  •  Совпадает ли это с точкой зрения модели ?

Чтобы оценить непротиворечивость диаграммы, спросите себя:

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

Чтобы оценить адекватность описания, спросите:

  •  Отражает ли модель реальность?
  •  Соответствует ли порядок расположения блоков убыванию их доминантности?
  •  Нет ли лишних или отсутствующих дуг между блоками?

Чтобы оценить точность представления, задайте вопросы:

  •  Не вводят ли в заблуждение названия блоков и дуг?
  •  Содержит ли ветви дуг только те данные, которые действительно нужны блоку?
  •  Не перекрываются ли функции двух блоков ?
  •  Нет ли ненужных дуг, касающихся блока?

Для оценки правильности активизации блоков (т.е. какова возможная последовательность их функционирования в ходе реальной работы системы) спросите себя:

  •  Работает ли "нормальный" путь потока данных?
  •  Как ошибочные данные будут влиять на блок?
  •  Объясняются ли чем-либо ошибочные пути?
  •  Не должна ли функция выполнять больше, чем это определяется касающимися ее дугами?

И наконец, один из самых полезных вопросов: "что нового я узнал, читая диаграмму?" Он ведет к последнему вопросу: "стоило ли читать диаграмму?". При положительном ответе, возможно, диаграмму стоит включить в модель.

14.6. Резюме

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

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

Freedman, D., and Weinberg, G/ : "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

MacKay, D.: Information, Mecanism and Meaning, MIT Press, Cambridge, Mass., 1969.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

0 Rourke, J.: "Writing for the Reader", DEC, 1976.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.


Глава 15. Конструктивное комментирование

По мере чтения SADT-диаграмм следует фиксировать возникающие проблемы. В SADT принят следующий порядок для записи этих проблем, который называется комментированием: (1) сделать запись о продолжительности времени работы, (2) проверить правильность заполнения полей бланка, (3) использовать по мере необходимости простые обозначения согласия или несогласия с автором, (4) использовать поля "Замечания" для записи существенных и конструктивных комментариев, (5) использовать по возможности язык ссылок SADT, (6) еще раз прочитать папку перед возвращением ее автору. Теперь мы обсудим технику SADT-комментирования и как сделать комментарии эффективными и конструктивными.

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

15.1. Запись о продолжительности работы

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

15.2. Проверка заполнения полей бланка диаграммы

Проверка заполнения полей бланка диаграммы не занимает много времени. Вначале проверьте фамилию автора, название проекта, дату создания и исправления, а также С-номер, чтобы отличить эту диаграмму от других. Например, диаграмма ЭМЦ/А2 на рис. 15-2 построена для проекта экспериментального механического цеха (ЭМЦ) 25.03.93 и ее С-номер -DAM010. Затем проверьте контекстный блок, название и номер узла, чтобы определить место диаграммы в модели. Диаграмма выполнить задание является декомпозицией второго блока своего родителя и находится на уровне А2 модели экспериментального механического цеха. Далее проверьте поле статуса, чтобы определить уровень полученной диаграммы. Например, диаграмма выполнить задание является просто диаграммой "Рабочая версия" и, следовательно, она почти или совсем не подвергалась рецензированию. В заключение поместите свои инициалы и дату рецензирования в поле "Читатель". Если вы всегда будете с этого начинать, то скоро станете делать это автоматически.


Рис. 15-1. Титульный лист и родительская с комментариями рецензента

Рис. 15-2. Диаграмма и дополнительный материал с комментарием рецензента

15.3. Обозначения согласия и несогласия с автором

Свое согласие с автором показывайте красной галочкой, несогласие - красным крестом. Обычно эти пометки используются для краткого комментирования конкретной части диаграммы или авторского замечания. Например, управляющая дуга блока 2 диаграммы ЭМЦ/А2 отмечена галочкой, потому что читатель согласился с тем, что только указания определяют выбор инструмента. А метка входа блока 2 была зачеркнута в знак несогласия читателя с выбором имени для этой дуги. Каждая диаграмма и страница дополнительного материала должны быть отмечены по крайней мере галочкой или крестом. Эти пометки говорят автору о том, что они были прочитаны и что читатель либо согласен, либо не согласен с изложенным. Однако мы рекомендуем давать на каждой диаграмме или странице папки более содержательные комментарии.

15.4. Замечания

В SADT существенные комментарии записываются в виде замечаний "с кружком". Чтобы сделать такое замечание, нужно: (1) жирно перечеркнуть очередной номер замечаний, (2) записать этот номер и обвести его кружком, (3) около обведенного номера записать содержание замечания и (4) при необходимости соединить зигзагом свое замечание с соответствующей частью диаграммы. Присваивая замечаниям номера, вы даете каждому из них уникальный идентификатор. Обводя номера кружком, вы отличаете свои замечания от замечаний автора, которые тоже могут быть на этой странице. Соединяя зигзагом замечания с соответствующей частью диаграммы, вы точно указываете, к чему они относятся. Например, диаграмма выполнить задание (рис. 15-2) получила шесть замечаний читателя. Обратите внимание, что зигзаг замечания б обводит две дуги, указывая, что это замечание относится к обеим дугам. Замечания 4 и 5 относятся к одному вопросу. Одно является поправкой, а другое - объяснением.

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

15.5. Язык ссылок SADT

Избыток текста затрудняет чтение диаграммы и понимание ее смысла. То же самое справедливо и для замечаний. Поэтому в методологии SADT для упрощения замечаний существует язык ссылок. Язык ссылок помогает идентифицировать конкретный блок, дугу или замечание. Код ссылки составляется из номера узла диаграммы или буквенного обозначения страницы папки и ICOM-кода или номера замечаний. ICOM-коды используются для ссылок на определенные дуги конкретного блока. В табл. 15-1 приведены некоторые примеры.

Язык ссылок полезен также при написании текста к диаграмме. Например, описание основного пути потока данных на диаграмме выполнить задание, сделанное в разделе 14.2.3 обычным языком, могло бы быть записано с использованием языка ссылок SADT так: С1 к 1С1 к 102 к 2С1 и ЗС1 и 4С1, и т. д. до тех пор, пока не будет 401 к 112.

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

15.6. Повторное чтение папки

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

показывает, что качество рецензии резко повышается, если потратить пару минут на повторный просмотр всей папки

Таблица 15-1. Примеры языка ссылок SADT

Код

Формат

Значение

3

Блок

Блок 3

5

Замечание

Замечание 5

01

Вершина дуги

Граничная дуга

312

Блок+вершина дуг

Вторая входная

.

дуга блока 3

Смотри

Е.2

Страница+блок

На стр.Е см. блок 2

A.I

Страница+ замечание

На диаграмме А

см. замечание 1

А42.3

Диаграмма+блок

На диаграмме А42

см. блок 3

В.401

Страница+вершина дуги

На стр. В см.

первую выходную

дугу блока 4

15.7. Конструктивная критика

Никто не любит, когда его работу критикуют, не предлагая ничего взамен. SADT настоятельно рекомендует позитивный и конструктивный стиль комментирования. Конструктивные комментарии коротки, ясны, позитивны и конкретны. Например, замечания 4 и 5 на рис. 15-2 не только позволяют исправить ошибку автора, но и поясняют, почему исходная метка дуги неверна.

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

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

Квалифицированные SADT-читатели вкладывают максимально возможное в свои комментарии. Лучше всего для комментариев использовать графический язык SADT. С его помощью читатель может быстро исправить синтаксис, предложить другие метки, направить дуги к другим блокам и рекомендовать другие декомпозиции. Используйте графику всегда, когда это возможно, потому что "меньше слов" часто означает "больше информации". На рис. 16-3 приведен пример графического замечания.

15.8. Резюме

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

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

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

0 Rourke, J.: "Writing for the Reader", DEC, 1976.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.


Глава 16. Ответы на комментарии и их обобщение

Процесс ответов на комментарии читателей называется реагированием. В этом процессе автор участвует после получения от библиотекаря папки с комментариями. В SADT упорядоченный процесс реагирования обеспечивает высокий уровень согласованности и компетентности для обратной связи автора с читательской аудиторией. Чтобы отреагировать на откомментированную папку, автор : (1) изучает каждое замечание читателя и отвечает на него, (2) принимает решение о необходимости диалога автор/читатель для обсуждения основных вопросов, (3) обобщает все комментарии на авторской копии папки, (4) переделывает диаграмму в соответствии с набором обобщенных замечаний.

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

16.1. Чтение и ответы на замечания

Вначале бегло просмотрите папку, отмечая замечания и фиксируя их количество. Вы получите представление о тех частях папки, которые в общем не вызывают сомнения, и о тех, к которым много претензий. Кроме того, посмотрите, сколько времени затратил читатель. Это позволит вам оценить, насколько трудно было комментировать папку. Продолжительность своей работы тоже отметьте на титульном листе. Просмотрев все замечания, вернитесь назад и ответьте на каждое из них. Старайтесь понять, что хотел сказать читатель. Сделайте вывод. Если вы согласны, поставьте галочку, если нет, поставьте крестик. Например, на диаграмме ЭМЦ/А2 (рис. 16-2) автор обозначил согласие с замечаниями 1-5 и несогласие - с замечанием 6.

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

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

Рис. 16-1. Титульный лист и родительская диаграмма с ответами автора

Рис. 16-2. Диаграмма и дополнительный материал с ответами автора


16.2. Беседа автор/читатель

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

Во время встречи придерживайтесь запланированной тематики и старайтесь уложиться в один час. Может оказаться, что встреча затянется из-за того, что вопросы потребуют дополнительного обдумывания или возникнут новые проблемы. Запишите новые проблемы и быстро вернитесь к исходной теме. Если потребуются дополнительные размышления, мы не советуем вам продолжать встречу намного дольше часа. Наш опыт показывает, что после часа интенсивных размышлений над сложной проблемой начинает падать продуктивность беседы. Лучше договоритесь о новой встрече и составьте к ней новый список вопросов. Такой стиль концентрированного взаимодействия очень эффективен, потому что: (1) цикл автор/читатель позволяет разрешать небольшие проблемы без дополнительных обсуждений, (2) ваша беседа будет короткой и насыщенной благодаря заранее подготовленному перечню вопросов.

16.3. Обобщение читательских комментариев

Каждое замечание, с которым вы согласились, приводит к изменениям в исходной диаграмме. Зафиксируйте эти изменения с помощью замечания "с кружком" на своем экземпляре папки. Используйте всю мощь графического языка и языка ссылок SADT для того, чтобы быстро делать примечания и легко и аккуратно вносить изменения в диаграмму. На рис. 16-3 показаны примечания, сделанные к диаграмме выполнить задание после обработки читательских комментариев. Обратите внимание, что изменения терминологии привели к изменению метки дуг. А это в свою очередь заставило автора сделать более тесной связь между результатами обработки и законченным и незаконченным заданием.

Часто в процессе реагирования на несколько откомментированных папок два читателя могут дать автору ценные, но противоречивые указания. Когда это случается, автор должен выбрать то из них, которое больше согласуется с целью и точкой зрения модели. Если это вызывает затруднения, автор должен провести беседу автор/ читатель с обоими читателями одновременно для разрешения противоречия. Окончательное решение, которое, как правило, является компромиссом, записывается в авторском экземпляре папки. Даже если конфликта нет, автор может не полностью следовать предложению читателя. Это относится к ситуациям, когда комментарий поднимает очень большую проблему, предлагает большие изменения в модели или когда указанный недостаток может быть устранен не так, как предлагает читатель.

Помните, что внесение записей в свой экземпляр папки - не напрасная работа. Часто в процессе нее авторы вносят новые качественные изменения в диаграммы в дополнение к тем, что предлагают читатели. Это происходит потому, что авторам в ходе обобщения комментариев представляется возможность увязать и объединить идеи сразу всех читателей, что часто приводит к новым плодотворным идеям, реализация которых ведет к новым качественным изменениям исходной диаграммы. Например, на рис. 16-3, усилив связь между результатами обработки и законченным и незаконченным заданием, автор проанализировал возможность обратной связи между изготовить на станке и собрать и определить степень выполнения задания.. Это привело к добавлению новой дуги изменение плана, которое отмечено замечанием 7.

16.4. Переделка диаграмм

Принято или непринято какое-либо замечания читателя отметьте в вашем экземпляре папки. После этого вы готовы к переделке рассматриваемой диаграммы и всех других диаграмм, которые были затронуты. При серьезных изменениях мы рекомендуем начертить диаграмму заново. На рис. 16-4 показан результат перечерчивания в соответствии с примечаниями к диаграмме выполнить задание, приведенными на рис. 16-3. Обратите внимание, что замечание 7

Рис. 16-3. Диаграмма с комментариями


Рис. 16-4. Перерисованная диаграмма

заставило автора ввести обратную связь по управлению от блока 4 к блоку 1 и что автор поменял ее метку при переделке диаграммы.

Если вы чертите диаграмму заново, не забудьте отметить заменяемую диаграмму, указав ее С-номер в скобках сразу же после С-номера новой диаграммы, как показано на рис. 16-4. Обратите внимание, что С-номер исходной диаграммы (DAM010) заключен в скобки и помещен рядом с С-номером переделанной диаграммы (DAM015). Таким образом с помощью набора указателей, направленных назад, метод SADT связывает между собой различные версии одной и той же диаграммы, чтобы всегда можно было проследить изменения в ходе аналитического проекта.

При переделке диаграммы старайтесь избежать потерь и не вносить ошибок. Это часто происходит в случае полной переделки. Если требуются незначительные изменения, получите от библиотекаря исходную диаграмму, проставьте в служебном поле дату пересмотра, внесите необходимые изменения и вставьте ее в новую папку. Библиотекарь перенесет все изменения в архивную папку модели для поддержания в порядке версий диаграммы. Мы настоятельно рекомендуем отложить окончательную переделку исходной диаграммы до того момента, когда вы ответите всем читателям. Таким образом, вы избежите пустой траты времени, времени читателей и времени библиотекаря, выпустив диаграмму с непринципиальными изменениями. Прежде чем чертить заново исходную диаграмму, подождите, пока не рассмотрите все комментарии, не ответите на них, не устраните все разногласия, не уточните противоречивые рекомендации. Закончив переделку, подготовьте новую папку для рецензирования с переделанной диаграммой.

16.5. Резюме

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

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

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

Minsky, M.: "Form and Content in Computer Science", CACM, vol. 17, no. 2, April 1970.

O'Rourke, J.: "Writing for the Reader", DEC, 1976.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.

Weinberg, G.: Understanding the Professional Programmer, Little Brown, Boston, 1982.

Weizenbaum, J.: Computer Power and Human Rreason, W.H. Freeman, 1976.


Часть 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-модель не будет иметь одинаковую

Уровень в

Модели

Общее число блоков в модели

4 блока/1 диаграмма

6 блоков/1 диаграмма

Тор

0

1

2

3

4

1

5

21

85

341

1365

1

7

43

259

1555

9331

Таблица 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 из приложения С и рассмотрите функцию прибыть 6 магазин - действие в рамках общей задачи покупки продуктов с целью накормить семью. Попытки разложить этот блок приведут к функциям типа сесть в автобус и поехать на такси, а также к объектам типа переход и автобусная остановка. Неожиданно в модель проникает новый набор терминов. Для того чтобы \ декомпозировать блок прибыть в магазин, мы должны рассматривать человека как нечто, подвергающееся перемещению посредством сложной системы транспорта, а не как кормильца семьи. Поскольку точка зрения изменилась, мы решаем не декомпозировать эту функцию. Это хороший пример, потому что он указывает на часто встречающиеся ситуации, которые сигнализируют о возможной замене точки зрения:

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

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

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-аналитики для определения момента прекращения декомпозиции.

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

Alexander, С.: Notes on the Synthesis of Form, Harvard University Press, Cambridge, Mass., 1964.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Doczi, G.: "The Power of Limits", Shambhala Press, 1981.

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

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.

Ross, D.: "Principles of Structuring", SofTech Technical Paper no. 082, November 1978.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "The DWS/CS Emergency Preset Structured Specification", Technical Paper no. 1083-1, August 1981.


Глава 18. Дополнения к диаграммам и моделям

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

18.1. Дополнения к диаграммам

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

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

Дополнительная информация записывается или представляется на стандартных SADT-бланках. Поскольку дополнения уточняют конкретную диаграмму модели, для идентификации и связывания дополнительной страницы с диаграммой, к которой она относится, используется принятая в SADT схема нумерации узлов. К номеру узла диаграммы добавляется буква и целое число. Буква определяет тип дополнения (Т - текст, Р -рисунок и Г - глоссарий), а число означает порядковый номер этой текстовой страницы среди других дополнительных страниц данной диаграммы. Обратите внимание, как номера узлов привязывают страницы с дополнениями на рис. 18-2, 18-3 и 18-4 к диаграмме подготовить рабочее место.

18.2. Определение терминологии с помощью глоссария

Глоссарий используется для того, чтобы собрать вместе и определить новые понятия, которые вводятся диаграммой, декомпозирующей блок, особенно если это первая декомпозиция родительского блока. Для функциональных SADT-диаграмм такими понятиями могут быть либо новые функции, либо новые объекты, представляемые дугами, либо декомпозиция внешних дуг. На рис. 18-2 представлена страница глоссария, который определяет некоторые из новых объектов, введенных на диаграмме подготовить


Рис. 18-1. Диаграмма, которую необходимо дополнить глоссарием, текстом и рисунками

Рис. 18-2 Глоссарий новых терминов


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

18.3. Пояснение содержания с помощью текста

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

Подготовка хорошего текста требует времени, даже если текст относится к одному блоку. Поэтому обычно текст пишется, когда диаграмма перестает подвергаться изменениям. Иногда текст используется для уточнения важных моментов в процессе создания диаграммы. Мы настоятельно рекомендуем по мере возможности использовать графику и цикл автор/читатель, чтобы избавиться от неясностей и построить диаграмму точно описывающую реальность. После этого вы сможете без труда обобщить или уточнить диаграмму при помощи хорошо организованного и насыщенного фактами текста. Например, если бы мы написали текст сразу после первого наброска диаграммы выполнить задание, представленного на рис. 9-2, нам пришлось бы его несколько раз переписывать, потому что, как показано в части III, диаграмма подверглась существенным изменениям в результате рецензирования.

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

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

Рис. 18-3. Подготовка рабочего места

18.4. Пояснение с помощью рисунков

Хотя для определения терминологии и изложения содержания используются текстовые описания, слова следует употреблять экономно. Мы советуем для пояснения тонких моментов и того, что трудно выразить словами, использовать, где это возможно, и рисунки. В SADT любое изображение, которое не является строго диаграммой, считается дополнительным рисунком. SADT-рисунки - это обычно либо картинки, либо диаграммы с дополнительными изображениями, связанные с конкретной диаграммой модели. Связь указывается с помощью добавления к номеру узла поясняемой диаграммы буквы Р и порядкового номера, как показано на рис. 18-4.

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

Рис. 18-4. Рисунок, показывающий, что представляет собой дуга СТАНОК,  ГОТОВЫЙ К РАБОТЕ

мени (например, график поступления заданий). На рис. 18-4 показано, как выглядит типичное готовое рабочее место.

Хорошие картинки незаменимы, но их нужно долго рисовать. Автор всегда должен иметь под рукой достаточный запас картинок, готовых к использованию - диаграммы самой SADT-модели. SADT-авторы обычно выделяют некоторые фрагменты изображения на нескольких диаграммах модели, чтобы подчеркнуть отдельные важные моменты. Диаграмма с дополнительной графикой может уточнить какие-либо детали, показывая различные группы дуг, описывая варианты действия блока или функционирование системы при изменяющейся окружающей среде, показывая основной поток данных, детализируя роли обратных связей, описывая принципиально неверные ситуации и случаи ошибочной трактовки или просто документируя важные изменения в диаграмме. На рис. 18-5 выделены преобразования, которые происходят с оборудованием (т.е. станками и инструментами), при превращении их в оборудованное рабочее место. Сравните это с текстовым описанием подготовки рабочего места, приведенным на рис. 18-3.

Для выделения каких-либо частей диаграммы чаще всего используют жирные линии. Мы, однако, при любой возможности пользуемся цветом. Цвет может отразить в диаграмме еще одну важную характеристику информации - разделение ее по типам. Попробуйте раскрасить дуги диаграммы подготовить рабочее место следующим образом: планы изобразите красным, оборудование - синим, остальную информацию -зеленым. Обратите внимание, как цвет по-новому осветил диаграмму, разбив представленные дугами объекты на типы. Раскрасив таким образом всю модель, можно описать влияние определенных данных на функции системы (например, на каких этапах нужен чертеж), а также указать те функции, которым необходим определенный тип данных (например, на каких этапах обрабатываются заготовки). Цвет - не универсальное, но очень эффективное средство, когда имеется не более 10 категорий.

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

18.5. Дополнение моделей

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

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

Рис. 18-5. На диаграмме показан основной путь

18.6. Резюме

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

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

Berlin, J.: Semiology of Graphics, University of Wisconsin Press, Madison, 1983.

DeMarco, Т.: Structured Analysis and System Specification, Yourdon Press, New York, 1978.

Hurley, R.: Decision Tables in Software Engineering, Van Nostrand Reinhold, New York, 1983.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Marca, D.: Applying Software Engineering Principles, Little Brown, Boston, 1984.

Martin, J., and McClure, C.: Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.


Глава 19. Примечания на диаграммах и моделях

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

19.1. Информация о свойствах

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

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

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

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


Рис. 19-1. Добавление меток, описывающих свойства моделируемой системы


19.2. Правила действия

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

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

[Модель/] блок * действие : предусловия--> постусловия

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

Рис. 19-2. Функция, имеющая единственное правило действия

Для функции блок правило действия действие определяется так: если истинны предусловия, выполняется функция блок и делает истинными постусловия.

Как предусловия, так и постусловия представляют собой логические выражения, построенные с помощью ICOM-кодов, где каждый ICOM-код идентифицирует единичную дугу управления, входную или выходную дугу конкретного блока. Логические операторы AND, OR и NOT вместе со скобками представляют средства для записи различных сложных логических выражений. Например, на рис. 19-2 показан блок диаграммы ЭМЦ/А2, у которого только одно правило действия. Это правило утверждает, что функции. подготовить рабочее место необходимы выбранное инструменты, станки в цехе, чертеж и указания, чтобы рабочий подготовил оборудованное рабочее место. Это пример правила действия, которое утверждает необходимость участия всех входных дуг, дуг управления и выходных дуг в действии конкретного блока.

Часто возникают ситуации, в которых для правильного действия блока необходимо отсутствие одной или нескольких дуг. Дуги, не участвующие в конкретном действии, отмечаются горизонтальным штрихом (символизирующим NOT) над ICOM-кодом, если они входят в предусловие. Это означает, что объекты, представляемые этой дугой, должны отсутствовать для того, чтобы действие было выполнено. Например, действие 3 на рис. 19-3 утверждает, что план выполнения заданий не должен быть представлен в момент оценки задания, который предшествует приемке.

Рис. 19-3. Функция, имеющая несколько правил действия

Встречаются также ситуации, когда только некоторые из дуг используются в процессе действия для производства выходов. Если входная дуга или дуга управления не участвуют в действии, они просто опускаются в предусловии. Аналогично если только часть выходов блока производится во время действии, то ICOM-коды для этих не создаваемых выходов опускаются в постусловиях. Например, отсутствие 02 и 03 в действии 4 означает, что в процессе этого действия вырабатывается только статус задания.

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

19.3. Генерация правил действия

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

Действие каждого блока описывается таблицей истинности, представляющей собой декартово произведение всех возможных сочетаний присутствия (отмечаемого с помощью "true" или Т) и обязательного отсутствия (отмечаемого с помощью "false" или F) входных дуг, дуг управления и выходных дуг. Каждый столбец такой таблицы становится тогда потенциальным правилом действия. (Иногда не имеет значения, принимает ли конкретная дуга участие в действии. В этих случаях представляется разумным использование буквы D. Однако запомните, что для полного отражения декартова произведения потребуется существенное увеличение размера таблиц.)

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

Условия

Варианты   действий

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Выбранные инструменты

Станки в цехе

Чертежи и указания

Оборудованное рабочее место

T F T F T F T F T F  T  F   T  F  T  F

T T F F T T F F T T  F  F   T  T  F  F

T T T T F F F F T T  T  T   F  F  F  F

T T T T T T T T T F  F  F   F  F  F  F

Таблица 19-1. Все возможные действия блока "Подготовить рабочее место"

прием, когда вы точно не знаете, как выполняется конкретная функция моделируемой вами системы.

19.4. Резюме

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

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

Dickover, M., and С. McGowan: "Software Design Using SADT", SofTech Technical paper TP061, August 1977.

Mendelson, E.: Introduction to Mathematical Logic, Van Nostrand Reinhold, New York, 1964.

Martin, J., and C. McClure: Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.

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.: "Structured Analysis (SA): A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977.

Schoman, K.: "SADT and PERT", SofTech Deliverable no. CLIN#0-02AG, November 1977.

SofTech, Inc.: "The DWS/CS Emergency Preset Structured Specification", Technical Paper no. 1083-1, August 1981.

Savith, W.: Abstract Machines and Grammars, Little, Brown, Boston, 1982.

Weinberg, G.: An Introduction to General Systems Theory, John Wiley, New York, 1975.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.


Глава 20. Управление проектом

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

20.1. Начало проекта

Успешный проект всегда имеет хороший старт, который обычно включает формирование технического задания на проектирование, исходный выбор создаваемых моделей, организацию группы аналитиков, выбор Комитета технического контроля и составление графика работ. Такое начало приводит к созданию плана проекта, который координирует усилия многих людей и делает проект управляемым.

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

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

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

Рис. 20-1. Типичная структура SADT-проекта

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

20.2. Создание и рецензирование результатов работы

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

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

Размер папки - это один из аспектов проектирования. Не менее важно количество

Рис. 20-2. Уровни консенсуса

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

20.3. Создание модели

Создание эффективных SADT-моделей не сводится просто к вычерчиванию правильных диаграмм. Оно требует использования совместной деятельности специалистов для получения утвержденных диаграмм А-0 и АО, назначение авторов для декомпозиции конкретных блоков диаграммы АО, формирования основных задач декомпозиции и кропотливого доведения модели до конца. Мы обычно начинаем работу по моделированию с технического совещания, в котором принимают участие эксперты и разработчики. Совещание длится в течение недели. Руководитель группы управляет этой совместной работой, организуя поток информации от экспертов к авторам и поощряя обмен мнениями между ними. Обсуждение продолжается до тех пор, пока не будут выработаны схемы диаграмм АО и А-0, а также уточнены цель и точка зрения модели (см. уроки в главе 22, где приведено подробное описание такой работы).

Начальные диаграммы и связанный с ними глоссарий составляют первую папку, которая проходит несколько циклов автор/читатель, пока не будут созданы стабильные диаграммы АО и А-0. После этого группа аналитиков определяет цели декомпозиции каждого блока диаграммы АО и назначает для каждого блока по одному автору. Автор детализирует свою часть модели и согласовывает интерфейсы на диаграмме АО с другими авторами. Таким образом коллектив авторов может быстро создать модель, не мешая друг другу (см. уроки в главах 23 и 24).

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

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

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

Таблица 20-1. Сроки создания SADT-диаграмм.

Задание

Совершенно заново

Новая

версия

Черчение

15-60 минут

10-30 минут

Критика

10-30 минут

10-30 минут

Комментирование

10-40 минут

5-20 минут

Количество диаграмм в день

2-5

5-10

С точки зрения соблюдения графика для успеха проекта важной является скорость качественного выполнения работы. Следите за тем, чтобы папки и модели не превышали критических размеров, приведенных в табл. 20-2.

Таблица 20-2. Критические размеры SADT-продуктов

Результаты работы

Количество

Папка

Папка

Модель

2-6 диаграмм

3-6 циклов рецензирования

10-30 диаграмм

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

20.4. Стратегии дополнения модели

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

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

  •  Функции системы, с которыми имеет дело пользователь, как и все функции системы, определяются SADT-моделью. Выделите в модели эти функции, свяжите их с вопросами, относящимися к человеческому фактору.
  •  Проектные ограничения, выявленные в процессе анализа    (смета, график работ, лимиты памяти и обработки данных, предварительно определенное техническое и программное обеспечение, ресурсы персонала), должны иметь вид примечаний, приведенных рядом с функцией, на которую они действуют.
  •  Указания по проектированию (например, какие функции автономны, какие формируют основу, какие функции можно отложить до создания соответствующего программного обеспечения) должны быть изложены и привязаны к примечаниям на модели (т.е. выделенным основным функциям).
  •  Атрибуты приемлемости (т.е. независимые испытатели, тесты, место и длительность тестирования) должны быть организованы вокруг структуры SADT-модели, если нельзя придумать лучшей организации. Для документирования этой информации используйте исполнителей.
  •  Хороший справочный материал (исходные документы, глоссарий терминов, описания специальных обозначений) очень важен для правильного понимания и использования спецификацией. Введите эту информацию в соответствующие разделы спецификации. Материал большого объема (например, чертеж самолета) или материал общего характера (например, словарь данных) поместите в одно или в несколько приложений.

20.5. Резюме

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

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

Brackett, J.: "Structuring the Analysis and Design Process", GUIDE Productivity Symposium, 1976

Burack, E., and Torda, F.: "The Manager's Guide to Change", Lifetime Learning Publications, 1979.

DeMarco, Т.: "Breaking the Language Barrier", Computerworld, August 1978.

DeMarco, Т.: "Controlling Software Projects, Yourdon Press, New York, 1982.

Parkin, A.: Data Processing Managment, Little, Brown, Boston, 1980.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January

1977.

Schoman, K.: "SADT and PERT", SofTech Deliverable no. CLIN#0-02AG, November 1977.

Weinberg, G.: "Understanding the Professional Programmer, Little, Brown, Boston, 1982.

Yourdon, E.: "How to Manage Structured Programming", Yourdon Press, New York, 1976.


Глава 21. Средства автоматизации

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

В конце 70-х появились компьютеры достаточной мощности и диапазона с приемлемой скоростью создания графических изображений. Это дало возможность автоматизировать те структурные методы, которые, подобно SADT, существенно опирались на графику. Хотя такие технологии в то время только начинали развиваться, ВВС США финансировали разработку первой системы автоматизации SADT (и, кстати говоря, первого автоматизированного средства для структурного анализа, делающего упор на графику), названного AUTOIDEFO.

В начале 80-х годов появился умещающийся на письменном столе персональный компьютер с графическими возможностями. Это привело к созданию автоматизированных рабочих мест для нескольких графических методов структурного анализа. В это же время первые попытки реализации SADT на мини- и микрокомпьютерах были предприняты в США, Европе и Скандинавии. Одним из результатов таких попыток стало создание автоматизированного рабочего места SADT во Франции, названное SPECIF_X. В этой главе описываются как AUTOIDEFO, так и SPECIF_X. Мы дадим обзор их возможностей, опишем интерфейс с пользователем, обсудим требуемые технические средства.

21.1. AUTOIDEFO

В программе ВВС США, связанной с интегрированной компьютеризацией производства ICAM (Integrated Computer Aided Manufacturing), было взято подмножество полной методологии SADT, названное IDEFO. (На самом деле, SADT описана в этой книге в том объеме, который почти полностью соответствует ее IDEFO подмножеству). Одна из задач программы ICAM заключалась в стандартизации описаний аэрокосмического производства для государственных подрядчиков. Выбор языка IDEF был значительным шагом на пути к такой стандартизации.

Средство AUTOIDEFO предназначено для облегчения процесса создания и рецензирования IDEFO-диаграмм и моделей для географически разобщенных аэрокосмических подрядчиков. Поскольку модели IDEFO часто рецензировались подрядчиками, рассеянными по всей территории Соединенных Штатов, ВВС потребовали, чтобы AUTOIDEFO функционировало на диалоговых устройствах и сетях связи, которые имели широкое распространение или были легко доступны в то время. Исходная конфигурация системы включала дисплеи с векторной графикой и графопостроители, соединенные с большой ЭВМ, которая могла быть подключена к обычной сети связи.

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

К несомненным достоинствам AUTOIDEFO следует отнести поддержку им управления SADT-проектированием и цикла автор/читатель. Например, руководитель проекта мог при организации нового проекта задать списки рассылки папок. Это обеспечивало распространение папок среди множества различных подрядчиков, расположенных в самых разных местах, предоставляя возможность специалистам комментировать диаграммы и отвечать на комментарии. Распространение папок осуществлялось автоматически после создания папки, ее комментирования или после получения ответов.

Таким образом, AUTOIDEFO являлось не просто средством для автоматизированного построения диаграмм. Оно поддерживало также процесс создания модели. Выбрав определенные команды, аналитик мог построить SADT-модель, начав ее с создания диаграммы А-0 и добавляя к ней последующие диаграммы в порядке номеров узлов. Таким образом, одновременно могло создаваться, храниться, обрабатываться, публиковаться и архивироваться множество различных моделей. Это позволяло соединять несколько взаимосвязанных моделей. Например, модель крыла самолета могла быть соединена с моделью фюзеляжа именно в тех точках, где они должны соединяться.

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

21.2. SPECIF_X

Возникнув первоначально в Соединенных Штатах, методология SADT прошла первые крупные "полевые испытания" в большой европейской телекоммуникационной компании в начале 70-х годов. В проекте определялись требования к большой телефонной управляющей системе. После этого SADT стала чрезвычайно популярной в Европе методологией спецификации требований. Совсем недавно использование SADT для спецификации требований было поддержано программой ESPRIT - рассчитанных на 10 лет инициативных работ в области программного обеспечения, принятых в Европейском Экономическом Сообществе. Не удивительно, что в Европе в начале 80-х годов было начато несколько разработок автоматизированного обеспечения SADT, что привело к созданию таких средств, как SPECIF_X. Целью SPECIF_X является поддержка широкого применения SADT-методов для более быстрого получения высококачественных спецификаций, чем это возможно с помощью карандаша и бумаги.

SPECIF_X было разработано французской компанией Institut de Genie Logiciel (IGL) для использования на автоматизированных рабочих местах с растровыми дисплеями и графопостроителями или лазерными принтерами. Менее эргономичная версия средства, выполняющая те же функции, может работать на компьютерах, имеющих отдельные терминалы с расширенными графическими возможностями и построчно печатающими устройствами. Версия SPECIF_X, работающая на графическом автоматизированном рабочем месте, предлагает пользователю меню, из которого курсором выбираются базовые строительные элементы SADT (блоки, дуги, метки) и создает из них диаграмму. Пользовательский интерфейс имеет высокие интерактивные характеристики, позволяя автоматически и вручную заворачивать дуги вокруг блоков и двигать блоки вместе с присоединенными к ним дугами. Диаграммы получаются достаточно хорошего качества, особенно если использовать вывод на лазерный принтер.

В дополнение к графической редактированию диаграмм SPECIF_X поддерживает управление диаграммами и моделями. Варианты диаграмм отслеживаются с помощью С-номеров, а диаграммы объединяются в модели с использованием номеров узлов. Проводится проверка согласованности модели, как во время построения диаграммы, так и во время ввода ее в модель. Обеспечивается также поддержка модификации диаграммы. Например, SPECIF_X может определить, как повлияет на на всю модель удаление конкретной дуги. Можно также создать глоссарий, связав его термины с соответствующей диаграммой и поместить термины в словарь данных. Полный словарь данных может быть создан и распечатан отдельно от диаграмм, что дает возможность составления словаря технических терминов для каждой модели. И наконец, SPECIF_X поддерживает цикл автор/читатель, позволяя организовывать диаграммы в папки, которые затем могут читать другие пользователи программного средства.

21.3. Design/IDEF

Пакет Design/IDEF (Meta Software Corp.) -графическая среда для проектирования и моделирования сложных систем широкого назначения, поддерживающая методологии описания и моделирования системных функций (IDEFO/ SADT), структур и потоков данных в системе (IDEF1, IDEF1X, E-R) и поведения системы (IDEF/CPN). Пакет Design/IDEF был использован для создания проектов сложнейших систем, связанных с автоматизацией и компьютеризацией производства, управлением и контролем, телекоммуникациями и аэрокосмонавтикой. Design/IDEF используется как составная часть в некоторых известных пакетах типа CIM (Computer Integrated Manufacturing) и САЕ (Computer Aided Engineering) и принят в качестве стандарта для проектов, финансируемых американскими и европейскими спонсорами. Рассмотрим более подробно основные возможности пакета Design/IDEF.

Представление графики

Design/IDEF имеет быструю и высококачественную графику, включающую создание стандартных и пользовательских объектов, выравнивание и манипулирование объектами, выбор атрибутов графических объектов и текста. Дополнительно в Design/IDEF реализованы возможности, требуемые для редактирования и моделирования данных: построение связывающих линий типа "резинка", маршрутизация и сглаживание дуг т.д.

Обеспечение непротиворечивости модели

Design/IDEF имеет встроенные возможности, дающие уверенность разработчику, что IDEF-модель будет точной, целостной и непротиворечивой на протяжении всего цикла ее создания. Например, при модификации текста, принадлежащему функциональному блоку или дуге в какой-то одной части модели, текст будет динамически скорректирован на всех страницах модели.

Поддержка Словаря Данных

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

Генерация отчетов

Design/IDEF предоставляет возможность использовать пять видов отчетов для поддержки и анализа моделей:

  •  Отчет о контроле полноты модели
  •  Отчет о функциях
  •  Отчет о дугах
  •  Отчет о ссылках
  •  IDEF-отчет

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

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

Организация коллективной работы

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

Моделирование данных (IDEF1, IDEF1X и E-R - методологии)

Design/IDEF дает также возможность создавать информационные модели, которые представляют как собственно данные, так и связи между ними в системе..

Информация, содержащаяся в IDEF-моделях, экспортируется в любую базу данных, а сами модели могут быть экспортированы в Design/CPN - пакет динамического моделирования и анализа сложных систем.

Как CASE-пакет по разработке программного обеспечения Design/IDEF поддерживает первые стадии создания программного продукта:

  •  Формулировка требований и целей проекта - определение того, что проектируемая система будет делать.
  •  Разработка спецификаций - формализованное описание требований.
  •  Создание проекта - определение подсистем и взаимодействий между ними.
  •  Документирование проекта - создание базы данных проекта, текстуальное описание составных частей проекта.
  •  Анализ проекта - проверка проекта на полноту и непротиворечивость.

Результатом работы пакета Design/IDEF является проект программной системы, состоящий из двух частей:

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

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

Design/IDEF работает в различных операционных средах: можно строить модели на IBM PC под MS-Windows, Macintosh или под Unix X Window System и переносить диаграммы из одной операционной среды в другую.

21.4. Сводный список для оценки автоматизированной поддержки SADT

Создание автоматизированных средств поддержки системного анализа, подобных AUTOIDEF, SPECIF_X или Design/IDEF, - не простая задача. Для SADT она не сводится просто к созданию графического редактора. Хотя семантика графики SADT и сама по себе достаточно сложна, есть еще много других аспектов SADT, которые должны быть учтены в автоматизированном средстве, чтобы обеспечить полную поддержку всей методологии. Поэтому мы считаем, что хорошая автоматизированная поддержка методологии SADT должна быть построена на основе центральной базы данных основных понятий SADT (мы употребляем здесь термин "база данных" для обозначения хранилища независимо от его расположения в основной или вспомогательной памяти, центральной или распределенной). Построение базы данных основных понятий SADT требует сжатого описания методологии. В табл. 21-1 приведен сводный список основных понятий SADT, рассмотренных в данной книге, с их реализацией в этой методологии. Сводный список кратко отображает методологию SADT, выстраивая ее по основным категориям конечного продукта (т.е. того, что создается в результате), языка (т.е. того, как выражаются идеи) и процесса (т.е. того, как создаются продукты). Для того чтобы выделить в категориях тесно связанные группы понятий категорий введены подкатегории.

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

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



Категория

Понятие

Реализация в SADT

Продукты:

Модели

Объект

Набор вопросов

Точка зрения

Иерархия

Ограниченный объект

Цель модели

Точка зрения модели

Номера узлов, номера блоков

Диаграммы

Декомпозиция

Версии, варианты

Сложность

Ясность

Диаграмма, списки данных и функций

С-номера

Правило от трех-до-шести

Правила построения диаграмм

Дополнения

Объяснения

Акценты

Терминология

Резюме

Листы текста

Листы рисунков

Листы глоссария, Словарь данных

Список узлов

Язык:

Функции

Функция

Вход

Выход

Управление

Исполнитель

Имена

Блок

Левая сторона блока

Правая сторона блока

Верхняя сторона блока

Нижняя сторона блока

Метки

Данные

Данные

Управление

Поток

Конвейер

Имена

Дуга

Дуга

Дуга

Соединение и разветвление дуг

Метки

Интерфейсы

Ограниченный объект

Связка интерфейса

Подавление

Блок и его дуги

ICOM-коды

Начало или конец дуги, помещенной в тоннель

Аннотации

Комментарии

Ответы

Решения

Свойства

Последовательность

Примечание

Примечания с "кружком"

-“ “-

-“ “-

Метки свойств

Правила действий

Примечание Квадратные "с квадратом"

Процесс:

Объяснение

Опрос

Описание

Критика

Распространение

Одобрение

Публикация

Эксперты

Авторы

Авторы

Рецензенты, цикл автор/читатель

Папки, Библиотекарь

Комитет технического контроля

Библиотекарь, формат публикации модели

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

21.5. Резюме

Современный уровень информационной технологии предоставляет богатый выбор методов для создания автоматизированной поддержки SADT. Наиболее доступным на сегодняшний день SADT-средством является Design/I DEF (Meta Software Corp.)- изначально построенный в рамках программы интегрированной компьютеризации производства и широко используемый ныне в различных областях деятельности. Автоматизированная поддержка SADT видится нам в развитии от просто графического средства до программного обеспечения, функционирующего на базе знаний более общих понятий моделирования. Такие развитые средства должны обладать способностью понимать семантику взаимосвязанной сети диаграмм SADT и множества моделей, а также объединять это множество сведений и правил с другими технологиями.


Часть V Создание функциональной модели и спецификации. Уроки

В этой части книги собрана серия из 25 уроков, которые проведут вас через основные этапы создания функциональной SADT-модели и составления спецификаций, базирующихся на ней. (Модель, рассматриваемая в этих уроках, приведена на следующей странице.) Уроки предназначены как для самостоятельных, так и для групповых занятий. Каждый урок разбит на четыре раздела: "Цель", "Действия", "Примечания" и "Образец". В разделе "Цель" указано то, что вы должны выполнить. В разделе "Действия" перечислены шаги, которые надо сделать для достижения цели. В разделе "Примечания" выделены некоторые важные моменты, связанные с применением SADT в процессе выполнения урока. В разделе "Образец" приведен пример выполнения урока учебной группой. Если вы занимаетесь самостоятельно, то прежде чем выполнить уроки, прочитайте главу, в которую они включены. В каждом уроке прочтите сначала разделы "Цель", Действия" и "Примечания", а затем попытайтесь выполнить все этапы раздела "Действия". После окончания каждого урока сверьте полученный результат с приведенным в разделе "Образец". Переделывайте работу только в случае, если вы не выполнили того, что требуется в уроке. Не пересматривайте ваши результаты, если они естественно вытекают из анализа, хотя и не полностью согласуются с образцом. Продолжайте анализ, выполняя другие уроки, и письменно фиксируйте результаты. По выполнении всех заданий у вас будет очень хороший конспект, отражающий ваш первый опыт в SADT-моделировании. Если изучение методов SADT-моделирования проходит в условиях класса, то преподаватель должен познакомиться с нашими рекомендациями, приведенными ниже. В них содержатся необходимые указания, как лучше всего дать пояснения для выполнения этих уроков. Перед началом работы обучающиеся должны прочитать только разделы "Цель" и "Действия". При выполнении тех уроков, где требуется, чтобы преподаватель руководил классом, следует обсудить пункты раздела "Примечания". В других случаях преподаватель кратко излагает эти пункты в конце урока. Кроме того, преподаватель должен использовать раздел "Образец" как ориентир для того, что должен сделать класс. Мы говорим "ориентир", поскольку не хотим, чтобы преподаватели ограничивали аналитические возможности учеников, заставляя их создавать точную копию образца модели.

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

Модель "Питание семьи"

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

Составить описание того, как реализовать питание семьи, состоящей из двоих взрослых, двоих маленьких детей и двоих подростков, так чтобы подростки могли понять это описание и следовать ему без посторонней помощи.

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

Рекомендации для преподавателей

Изложенный ниже материал предназначен для преподавателей, желающих примерно за 5 дней обучить SADT класс, состоящий не более чем из 20 учащихся. Каждый подраздел рекомендаций относится к одной главе из части V. Уроки следует выполнять последовательно, с перерывами в конце каждой главы. Первые уроки нужно выполнять всем классом, следующие -разбившись на группы, а последние - индивидуально. Читая наши рекомендации, имейте это в виду.

глава 22. уроки 1-7

Все семь уроков проработайте со всем классом. Ходите по аудитории и настойчиво добивайтесь по возможности участия в работе каждого учащегося. Записывайте примечания, составляйте списки и делайте наброски диаграмм у всех на виду, чтобы класс мог следить за развитием идей. Вы, как главный автор, разрешайте все конфликты, касающиеся содержания диаграмм и интерпретации терминологии. Потратьте время на очень аккуратное построение диаграмм А-0 и АО из урока 7, поскольку они де-факто станут образцом до конца курса обучения. При построении диаграмм используйте самую простую графику и наиболее нужные, но краткие названия. Избегайте соединительных линий между дугами и их метками,

глава 23. уроки 8-10

Эти уроки выполняются группами. Разделите класс на 3-6 групп, по одной на каждый блок диаграммы АО. Попытайтесь сбалансировать состав каждой группы по уровню подготовке учащихся. Постарайтесь, чтобы в каждый группе был хотя бы один опытный участник и один начинающий. Затем выделите каждой группе по одному блоку диаграммы. Учащиеся сами должны решать проблемы организации работы и распределения обязанностей (например, кто будет записывать, а кто - руководить). Постарайтесь привлечь к участию каждого. Напомните, что целью каждой группы, являются построение диаграммы, затем ее критическая оценка, и, наконец, создание папки. Во время занятий не надо обмениваться информацией с другими группами. Время обмена результатами наступит позже.

глава 24. уроки 11-14

Эти уроки выполняют те 3-6 групп, которые создавали декомпозицию первого уровня. Напомните, что наступило время обмена информацией. Ограничьте диалоги между группами. Для для усиления дискуссии в некоторый момент вы можете обсудить с классом диаграмму АО. Укажите, что группы должны совместно улучшать диаграммы АО. Следите, чтобы ни одна из групп не давала ненужных заданий другой группе. Будьте главным арбитром при решении интерфейсных проблем.

глава 25. уроки 15-17

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

глава 26. уроки 18-21

Эти уроки выполняются отдельными членами тех же 3-6 групп. Сообщите группам, что предыдущий шаг в решении интерфейсных проблем был на уровне класса (т.е. весь класс решал проблемы), а этот шаг будет на уровне групп (т.е. интерфейсные проблемы будут решаться внутри каждой группы). Поддерживайте диалоги, ведущиеся внутри групп. При необходимости проработайте диаграмму АО. Укажите, что группы должны совместно улучшать свои декомпозиции. Проследите, чтобы никого не заставляли делать лишнюю работу в диаграмме. Будьте арбитром при решении проблем, касающихся интерфейса между учащимися.

глава 27. уроки 22-25

Проработайте урок 22 всем классом. Урок 23 группы выполнят самостоятельно. Урок 24 учащиеся должны выполнить индивидуально. Текст к уроку 25 учащиеся пишут индивидуально на основе своих диаграмм Ахх. Если будет время, группы могут составить текст для своих диаграмм Ах, а преподаватель написать текст для диаграмм А-0 и АО, а также оформить титульный лист спецификации. Напомните классу, что его целью является составление единого спецификационного документа, отражающего коллективные усилия на протяжении курса обучения. После завершения курса размножьте этот документ и разошлите его всем. Это поможет каждому запомнить изученное, в особенности соотношение между индивидуальной работой и работой в группе.


Глава 22. Начало моделирования

Вспомним, что SADT-модель начинается с очерчивания границ системы, определения цели и точки зрения модели и создания диаграмм верхнего уровня. Эта глава, состоящая из семи уроков, рассчитана на то, чтобы провести вас через те этапы, которые чаще всего выполняют SADT-аналитики в начале создания функциональной модели: в уроке 1 очерчивается контекст задачи, в уроке 2 определяется цель и точка зрения модели, в уроке 3 создается диаграмма АО , в уроке 4 - диаграмма А-0, в уроке 5 дается критическая оценка диаграммы А-0, в уроке б критически оценивается диаграмма АО, в уроке 7 обе диаграммы переделываются.

В идеале вы должны выполнить все семь уроков без перерыва. Это даст вам верное представление об объеме работы, необходимой для начала моделирования. В крайнем случае мы рекомендуем выполнить уроки 1-4, затем сделать перерыв, и далее приступить к выполнению уроков 5-7. Исходите из следующего расчета: полчаса на чтение, понимание и выполнение каждого урока. Не огорчайтесь, если вы не укладываетесь в полчаса. Ваша задача - научиться методологии, а не устраивать гонки на скорость. По мере приобретения опыта в SADT ваша производительность будет возрастать, потому что, как при изучении любого языка, чем больше вы пользуетесь языком SADT, тем лучше вы им овладеваете.


урок 1. Очерчивание границ объекта

Цель

Создать очерченный контекст для модели "Питание семьи".

Действия

1. Прежде чем начать, вспомните основные понятия SADT-моделирования. Посмотрите, как они применяются к очерчиванию объекта моделирования.

2. Начните составлять список всех основных предметов, которые, по вашему мнению, являются частью системы. Дайте свободу ассоциациям. На этом этапе не беспокойтесь о точности.

3. Теперь оцените исходный список критически. Вычеркните названия, не относящихся к системе объектов. Если есть возможность, объединяйте названия в группы, проводя соединительные линии или обводя слова кружками. Добавляйте новые названия по мере развития ваших идей.

4. Остановитесь, когда поток идей иссякнет.

5. Теперь проделайте то же самое для функций системы. Для перечисления функций пользуйтесь списком данных, затем оцените новый список. Вычеркните те названия, которые не входят в систему. Группируйте сходные функции, соединяя их названия линиями или обводя кружками. Меняйте список данных по мере постижения работы системы.

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

Примечания

1. Это процесс, в ходе которого достигается общее согласие относительно границ "системы".

2. Ясность относительно входящих в систему объектов начнет появляться только после составления исходного списка, исключения из него каких-либо объектов и включения новых.

3. Иногда объекты, которые вначале были исключены, возвращаются снова в очерченный контекст.

4. Список данных изменится в ходе составления списка функций. Возможно, по мере возникновения новых идей вы начнете "метаться" между списками.

Образец

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


урок 2. Определение цели и точки зрения модели

Цель

Сформулировать цель модели "Питание семьи" и определить, с чьей точки зрения будет описан этот процесс.

Действия

1. Составьте множество вопросов, на которые должна отвечать модель. Уточните это множество, определив, кто задает вопросы. Запишите по крайней мере 5-10 вопросов. Затем задайте степень точности ответа на каждый из них.

2. С помощью этого набора вопросов определите, как будет использоваться модель. Если вы не можете сформулировать, как она будет использоваться, попробуйте записать еще вопросы или попытайтесь вообразить, кто будет применять модель. В одном предложении сформулируйте, как она будет использоваться. Это станет целью модели.

3. Теперь решите, кто рассказывает о "Питании семьи". Составьте список кандидатов, чтобы убедиться, что вы выбрали самую подходящую точку зрения. Выберите из всех того, кто сможет ответить на большинство вопросов. Его ( ее ) точка зрения станет точкой зрения модели.

Примечания.

1. Составление хорошего списка вопросов приводит к пониманию того, как будет использоваться модель. Чем больше вопросов, тем лучше вы поймете, о чем должна рассказать модель.

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

Образец

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

2. Цель модели включает такое подробное описание для того, чтобы подростки могли реализовать питание семью даже при невозможности проконсультироваться с родителями.

3. В образце приведено несколько вариантов точки зрения (например, точка зрения соседей). Однако была выбрана точка зрения родителей, потому что они "главные специалисты" в своем домашнем хозяйстве.



урок 3. Построение диаграммы верхнего уровня

Цель

Описать процесс питания семьи в виде одной диаграммы, состоящей из 3-6 важнейших функций, взаимосвязанных через информацию управления (например, меню) и материальные объекты (например, посуду).

Действия

1. Объедините 3-6 функций из списка функций очерченного контекста и расположите их по порядку доминантности. Нарисуйте и назовите блоки по одному для каждой функции в соответствии с порядком доминирования.

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

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

3. Теперь нарисуйте и пометьте дуги, представляющие ограничения "извне" системы, используя составленный список данных. Подумайте, какого рода объекты влияют на питание семьи

4. Наконец, изобразите основной поток данных, прокладывая путь от блока к блоку. Используйте список данных и представьте себе, что вы рассказываете подросткам о том, как реализуется процесс питания.

Примечание

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

Образец

1. Все планирование собрано в первом блоке. Его можно было бы распределить по всем блокам, но показалось, что на необходимость планирования следует указать подросткам сразу.

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

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

4. Дуги "механизмов" сознательно опущены, потому что они не помогают достижению цели модели.



урок 4. Обобщение диаграммы верхнего уровня

Цель

Нарисовать единственный блок со его входами, управлениями и выходами, который обобщает всю только что нарисованную диаграмму АО.

Действия

1. Нарисуйте единственный большой блок в середине страницы и пометьте его названием диаграммы АО. Это обобщает все функции системы.

2. Теперь нарисуйте и пометьте все входные дуги, дуги управления и выходные дуги - по одной для каждой внешней дуги диаграммы АО. Это обеспечивает согласованность двух рисунков.

3. Наконец, напишите под большим блоком цель и точку зрения модели. Это сразу же определит смысл и направленность модели каждому, кто начнет ее читать.

Примечание

Этот единственный блок со своими дугами обобщает внешние связи системы "Питание семьи".

Образец

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

2. Обратите также внимание, что внизу справа от большого блока приведен С-номер диаграммы АО. Этот номер определяет, какая именно версия диаграммы АО детализирует этот блок.



Урок 5. Критическая оценка обобщающей диаграммы

Цель

Документировать все вопросы, возникшие с диаграммой А-0.

Действия

1. Прочтите диаграмму вслух, пользуясь для изложения шаблоном типа: "функция (имя блока) преобразует (имена входных дуг) в (имена выходных дуг) в соответствии с (имена дуг управления).

2. Оцените изложенное с точки зрения здравого смысла. Определите неувязки, запишите, в чем они заключаются, и проведите соответствующую переделку (например, поменяйте метки, объедините дуги).

3. Критически оценив чертеж, оцените также цель и точку зрения. Запишите неувязки и пересмотрите цель и точку зрения.

Примечание

Проговаривая содержание диаграммы, предпочтительно вслух, вы яснее увидите ее недостатки.

Образец

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

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

3. Нумерация замечаний указывает на последовательность выявления и исправления недостатков.



урок 6. Критическая оценка диаграммы верхнего уровня

Цель

Документировать все вопросы, возникшие с диаграммой АО.

Действия

1. Внесите в эту диаграмму все исправления, соответствующие исправлениям на диаграмме А-0. Например, если на дуге управления диаграммы А-0 изменилась метка, то измените соответствующую внешнюю дугу на данной диаграмме.

2. Определите смысл данной диаграммы после исправления всех связанных с диаграммой А-0 недостатков. Оцените его адекватность. Определите недостатки нового варианта, запишите их и внесите соответствующие изменения (например, измените метки, объедините дуги).

Примечания

1. Вы сделаете меньше ошибок, если для начала перенесете на диаграмму АО все изменения, сделанные в диаграмме А-0.

2. Проговорив содержание исправленной диаграммы АО, вы скорее увидите ее недостатки.

Образец

1. Обратите внимание, что внешние дуги рецепты, общепринятые и семейные правила и режим дня объединены в новую внешнюю дугу семейные правила.

2. Объединение вкусов и диетических требований в некормленных людей привело к появлению новой внешней входной дуги как к блоку спланировать меню, так и к блоку обслуживать за столом.

3. Нумерация замечаний указывает на последовательность выявления и исправления недостатков.



урок 7. Переделка обобщающей диаграммы и диаграммы верхнего уровня

Цель

Переделать в соответствии с критической оценкой, выполненной в уроке 6, и начертить заново диаграммы А-0 и АО.

Действия

1. Вначале перечертите диаграмму А-0. По ходу дела обдумывайте изложенное в диаграмме и проверяйте, сохранился ли в ней смысл. Перепишите, если нужно, цель и точку зрения модели. Затем отложите диаграмму А-0 в сторону, но держите ее под рукой, чтобы можно было сверять с ней при переделке диаграмму АО.

2. Перечерчивая диаграмму АО, обдумайте изложенное в ней. Обращайтесь время от времени к диаграмме А-0, чтобы удостовериться, что детали диаграммы АО согласованы с ее контекстом.

3. Свяжите все внешние дуги диаграммы АО с родительской диаграммой А-0, используя ICOM-коды. Это позволит вам избежать потери внешних дуг. Проверьте соответствие меток внешних дуг диаграммы АО меткам дуг диаграммы А-0.

Примечания

1. Сказать много с помощью немногих слов - ключ к хорошему моделированию. При переделке старайтесь сохранить точность, сокращая количество слов и упрощая графику.

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

Образец

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

2. Две дуги управления внешние факторы и семейные правила разбивают пять функций на две группы. Первая дуга влияет на подготовительные функции планировать меню и пополнить запасы. Вторая дуга влияет на функции, связанные с собственно питанием:

приготовить, обслужить за столом и убирать со стола. Это пример влияния дуг управления на декомпозицию, т. е. управления объясняют, почему выбрана данная декомпозиция.



Глава 23. Построение декомпозиции первого уровня

Вспомните, что SADT-аналитик делает набросок декомпозиция, подвергает его критической оценке, перечерчивает и затем выпускает соответствующую папку. Эта глава состоит из трех уроков, связанных с созданием декомпозиции первого уровня - т.е. декомпозиции блоков диаграммы АО. В уроке 8 создается диаграмма, декомпозирующая один блок диаграммы АО. Урок 9 - авторская критика и пересмотр диаграммы. В уроке 10 рассматривается процесс создания папки для рецензирования.

Выполните все три урока без перерыва. Это даст вам точное представление об объеме работы, необходимой для декомпозиции ограниченного объекта. (Сравните усилия, потребовавшиеся для начала работы над моделью, с усилиями, потребовавшимися для декомпозиции одного блока.) Отведите около получаса на каждый урок, но не беспокойтесь, если затратите времени больше. Закончите работу, связанную с выполнением этих уроков, даже если вы испытываете трудности в следовании точному описанию системы на диаграмме АО.


урок 8. Групповое построение диаграмм

Цель

Выбрать и декомпозировать один из блоков диаграммы АО.

Действия

1. Выберите блок диаграммы АО. Этот блок является контекстным на протяжении всего этого урока. Не выходите за его границы.

2. Мысленно проверьте этапы построения диаграммы: составить список объектов, составить список функций, сгруппировать функции в 3-6 блоков, начертить блоки в порядке убывания доминантности; начертить внешние дуги, начертить дуги управления, начертить входные и выходные дуги.

3. Прочтите диаграмму АО снова, сосредоточившись на том, как ваш блок согласуется с другими блоками. Используйте граничные дуги выбранного вами блока для начала составления списка данных.

4. Выполните остальные этапы создания диаграммы. Старайтесь разместить списки данных и функций в левой части бланка, а чертить диаграмму - в правой части (это не более чем совет).

5. При вычерчивании делайте для себя примечания и определяйте терминологию.

6. После окончания работы проверьте ICOM-коды. Удостоверьтесь, что вы не забыли использовать граничные данные.

Примечания

1. Не выходите за пределы содержания, определенного выбранным вами блоком диаграммы АО. Вы можете встретиться с трудностями в построении диаграммы, поскольку первые декомпозиции часто выявляют недостатки родительской диаграммы. Записывайте возникшие затруднения, делая заметки на диаграмме АО.

2. На данном этапе не беспокойтесь о корректности этой диаграммы. Декомпозиции данного уровня редко удаются с первого раза.

Образец

1. Обратите внимание на то, что сначала перечислены внешние входные дуги, дуги управления и выходные дуги, а затем -последующие данные, составляющие компоненты этих дуг. Так вы будете уверены, что не забыли контекст, в котором работаете.

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



урок 9. Критическая оценка декомпозиции первого уровня

Цель

Критически исследовать построенную в уроке 8 диаграмму, чтобы определить, как она детализирует родительский блок диаграммы АО.

Действия

1. Просмотрите построенную диаграмму и попытайтесь изложить то, как она отражает свою часть задачи питания семьи. Начните с логического начала: с поступления одного или более объектов из блока диаграммы АО. Обращайтесь непрерывно к диаграмме АО и делайте примечания, когда находите изложение неверным или неполным.

2. Оцените, как вы разделяете внешние дуги и группируете функции в блоки. Посмотрите, нельзя ли по-другому декомпозировать данные или объединить функции в другой набор блоков.

3. Не забывайте отмечать нужные изменения как на вашей диаграмме, так и на диаграмме АО. Изменяйте или уточняйте вашу терминологию в процессе критического анализа.

4. Постройте видоизмененную в соответствии с вашими замечаниями диаграмму и перечертите, если необходимо, диаграмму АО. Не забывайте проверять ICOM-связи между рассматриваемой диаграммой и диаграммой АО.

Примечания

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

Образец

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

2. Блок составить список покупок сделан более общим.

Это означает, и что теперь функция Спланировать покупки управляет еще и выбором магазинов.

3. Замечание 4 напоминает, что необходимо уточнить вместе с автором, который ввел в диаграмму функцию

планировать, значение термина реальная доступность продуктов. Такие случаи

часто бывают, когда модель строится несколькими авторами.



урок 10. Подготовка папки

Цель

Собрать в SADT-папке проверенную вами диаграмму первого уровня и связанный с ней глоссарий.

Действия

1. Подготовьте как вашу диаграмму, так и глоссарий и проверьте согласованность информации.

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

3. Добавьте в поле комментариев титульного листа другие специальные комментарии или замечания для читателей.

4. Скрепите страницы - сначала титульный лист, затем диаграмму АО, потом вашу диаграмму и, наконец, глоссарий. После этого пошлите папку библиотекарю проекта.

Примечания

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

2. Волнистая линия под датой на обложке папки означает, что дата возврата относится ко всем читателям. Мы будем на протяжении всех уроков последовательно использовать это обозначение на титульных листах.

Образец

1. В помещенном на титульном листе примечании содержится просьба к читателям определить термин информация о реальном к