|
Читайте также: |
Методология структурного анализа и проектирования SADT
Автор: Дэвид Марка, Клемент МакГоуэн 22 Сентября 2009, 17:06
Первая книга, посвящённая методологии SADT. Написана авторами на основе опыта, полученного в ходе преподавания данной дисциплины в течении 10 лет. Содержит в себе как теоретическую, так и практическую часть (уроки).
Методология структурного анализа и проектирования SADT
(Structured Analysis & Design Technique)
Дэвид А. Марка,
Клемент МакГоуэн,
Предисловие Дугласа Т. Росса
Cодержание
· Предисловие
· Введение
· Предпосылки создания SADT
· Часть I. Принципы функционального моделирования
o Глава 1. Системы и модели
§ SADT-модели
§ Модель отвечает на вопросы
§ Модель имеет единственный субъект
§ У модели может быть только одна точка зрения
§ Модели как взаимосвязанные наборы диаграмм
§ Резюме
o Глава 2. Синтаксис и применение диаграмм
§ Диаграммы содержат блоки и дуги
§ Блоки представляют функции
§ Блоки имеют доминирование
§ Дуги изображают объекты
§ Дуги изображают взаимосвязи между блоками
§ Дуги представляют наборы объектов
§ Идентификация версий диаграмм С-номерами
§ Резюме
o Глава 3. Синтаксис моделей и работа с ними
§ Система представляется одним блоком
§ Идентификация декомпозиции номерами узлов
§ Связывание декомпозиции с помощью С-номеров
§ Коды ICOM гарантируют стыковку диаграмм
§ Обозначения для менее распространенных интерфейсов по дугам
§ Резюме
o Глава 4. Процесс моделирования
§ Получение знаний в процессе опроса
§ Документирование полученных знаний
§ Корректность модели проверяется в процессе итеративного рецензирования
§ Координация процесса рецензирования
§ Модели используются после их одобрения
§ Резюме
o Глава 5. Более глубокие концепции диаграмм
§ Дуги имеют различное содержание
§ Дуги могут быть декомпозированы
§ Дуги могут быть "помещены в тоннель"
§ Различие между входными дугами и дугами управления
§ Дуги механизмов определяют способы реализации функций
§ Обратная связь по управлению и по потоку данных
§ Резюме
o Глава 6. Более глубокие концепции моделей
§ Модели SADT структурируют естественный язык
§ Точка зрения модели влияет на расстановку акцентов и терминологию
§ Декомпозиция в ходе моделирования
§ Некоторые стратегии декомпозиции
§ Выбор стратегии декомпозиции
§ Момент прекращения декомпозиции определяется точностью
§ Резюме
· Часть II Создание функциональных моделей и диаграмм
o Глава 7. Сбор информации
§ 7.1. Источники информации
§ 7.2. Типы опроса
§ 7.3. Процесс опроса
§ 7.3.1. Подготовка
§ 7.3.2. Проведение опроса
§ 7.3.3. Завершение
§ 7.4. Что нужно помнить при опросе
§ 7.5. Резюме
§ Дополнительная литература
o Глава 8. Начало моделирования
§ 8.1. Основные этапы
§ 8.2. Выбор цели и точки зрения
§ 8.3. Составление списка данных
§ 8.4. Составление списка функций
§ 8.5. Построение диаграммы АО
§ 8.6. Обобщение диаграммы АО
§ 8.7. Резюме
o Глава 9. Продолжение моделирования
§ 9.1. Декомпозиция ограниченного объекта
§ 9.1.1. Выбор блока
§ 9.1.2. Объект, определяемый блоком
§ 9.1.3. Создание новой диаграммы
§ 9.2. Выявление интерфейсных ошибок
§ 9.3. Принципы и приемы расположения дуг
§ 9.4. Резюме
§ Дополнительная литература
o Глава 10. Проверка диаграммы автором
§ 10.1. Процесс авторской проверки
§ 10.2. Выявление недостатков новой диаграммы
§ 10.2.1. Вопросы о блоках
§ 10.2.2. Вопросы о связи с родительской диаграммой
§ 10.2.3. Вопросы о внутренних дугах
§ 10.3. Создание альтернативных декомпозиций
§ 10.3.1. Альтернативная декомпозиция и объединение функций
§ 10.3.2. Альтернативное объединение и разъединение дуг
§ 10.3.3. Тестирование
§ 10.3.4. Схематичное изображение декомпозиции следующего уровня
§ 10.4. Корректировка новой диаграммы
§ 10.4.1. Переопределение доминирования
§ 10.4.2. Содержательные названия блоков
§ 10.4.3. Дуги, хорошо передающие информацию о себе
§ 10.4.4. Пояснения
§ 10.5. Исправление взаимосвязанных диаграмм
§ 10.6. Резюме
§ Дополнительная литература
o Глава 11. Соглашения по построению диаграмм
§ 11.1. Соглашения по размещению блоков
§ 11.2. Соглашения по размещению дуг
§ 11.3. Соглашения по размещению блоков и дуг
§ 11.4. Резюме
· Часть III. Рецензирование диаграмм и моделей
o Глава 12. Цикл автор/читатель
§ 12.1. Составление исходной документации
§ 12.2. Комментирование работы
§ 12.3. Ответы на комментарии
§ 12.4. Совершенствование моделей
§ 12.5. Цикл автор/читатель
§ 12.6. Резюме
o Глава 13. Подготовка папки
§ 13.1. Обмен информацией с помощью папок
§ 13.2. Титульный лист
§ 13.3. Организация папки
§ 13.4. Размеры папки
§ 13.5. Когда формировать папку
§ 13.6. Резюме
o Глава 14. Чтение диаграмм и моделей
§ 14.1. Процедура чтения
§ 14.2. Изучение деталей диаграммы
§ 14.3. Изучение ближайшего контекста диаграммы
§ 14.4. Уточнение места диаграммы в модели
§ 14.5. Критическая оценка содержания диаграммы
§ 14.6. Резюме
o Глава 15. Конструктивное комментирование
§ 15.1. Запись о продолжительности работы
§ 15.2. Проверка заполнения полей бланка диаграммы
§ 15.3. Обозначения согласия и несогласия с автором
§ 15.4. Замечания
§ 15.5. Язык ссылок SADT
§ 15.6. Повторное чтение папки
§ 15.7. Конструктивная критика
§ 15.8. Резюме
§ Дополнительная литература
o Глава 16. Ответы на комментарии и их обобщение
§ 16.1. Чтение и ответы на замечания
§ 16.2. Беседа автор/читатель
§ 16.3. Обобщение читательских комментариев
§ 16.4. Переделка диаграмм
§ 16.5. Резюме
· Часть IV Завершение моделирования. Руководство моделированием
o Глава 17. Завершение моделирования
§ 17.1. Размер SADT-моделей
§ 17.2. Прекращение декомпозиции
§ 17.3. Достаточная детализированность
§ 17.4. Изменение уровня абстракции
§ 17.5. Изменение точки зрения
§ 17.6. Сходные функции
§ 17.7. Тривиальные функции
§ 17.8. Принятие решения о завершении моделирования
§ 17.9. Резюме
§ Дополнительная литература
o Глава 18. Дополнения к диаграммам и моделям
§ 18.1. Дополнения к диаграммам
§ 18.2. Определение терминологии с помощью глоссария
§ 18.3. Пояснение содержания с помощью текста
§ 18.4. Пояснение с помощью рисунков
§ 18.5. Дополнение моделей
§ 18.6. Резюме
§ Дополнительная литература
o Глава 19. Примечания на диаграммах и моделях
§ 19.1. Информация о свойствах
§ 19.2. Правила действия
§ 19.3. Генерация правил действия
§ 19.4. Резюме
§ Дополнительная литература
o Глава 20. Управление проектом
§ 20.1. Начало проекта
§ 20.2. Создание и рецензирование результатов работы
§ 20.3. Создание модели
§ 20.4. Стратегии дополнения модели
§ 20.5. Резюме
§ Дополнительная литература
o Глава 21. Средства автоматизации
§ 21.1. AUTOIDEFO
§ 21.2. SPECIF_X
§ 21.3. Design/IDEF
§ Представление графики
§ Обеспечение непротиворечивости модели
§ Поддержка Словаря Данных
§ Генерация отчетов
§ Организация коллективной работы
§ Моделирование данных (IDEF1, IDEF1X и E-R — методологии)
§ 21.4. Сводный список для оценки автоматизированной поддержки SADT
§ 21.5. Резюме
· Часть V. Создание функциональной модели и спецификации. Уроки
o Модель "Питание семьи"
o Рекомендации для преподавателей
§ Рекомендации к главе 22. Уроки 1-7
§ Рекомендации к главе 23. Уроки 8-10
§ Рекомендации к главе 24. Уроки 11-14
§ Рекомендации к главе 25. Уроки 15-17
§ Рекомендации к главе 26. Уроки 18-21
§ Рекомендации к главе 27. Уроки 22-25
o Глава 22. Уроки 1-7
§ Урок 1. Очерчивание границ объекта
§ Урок 2. Определение цели и точки зрения модели
§ Урок 3. Построение диаграммы верхнего уровня
§ Урок 4. Обобщение диаграммы верхнего уровня
§ Урок 5. Критическая оценка обобщающей диаграммы
§ Урок 6. Критическая оценка диаграммы верхнего уровня
§ Урок 7. Переделка обобщающей диаграммы и диаграммы верхнего уровня
o Глава 23. Уроки 8-10
§ Урок 8. Групповое построение диаграмм
§ Урок 9. Критическая оценка декомпозиции первого уровня
§ Урок 10. Подготовка папки
o Глава 24. Уроки 11-14
§ Урок 11. Групповое комментирование
§ Урок 12. Реагирование группы
§ Урок 13. Переделка диаграммы верхнего уровня
§ Урок 14. Переделка декомпозиции первого уровня
o Глава 25. Уроки 15-17
o Глава 26. Уроки 18-21
o Глава 27. Уроки 22-25
Предисловие
Замечательно, что эта первая, посвященная 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, либо как только функциональный вариант в правительственной версии (IDEF0). Его применяли тысячи людей при работе над сотнями проектов во многих областях, начиная с 1973 года. Большинство применений было связано с системами "человек-машина-компьютер" в бизнесе, производстве, обороне, связи и организации проектирования. Можно надеяться, что доступность этой книги расширит область его применения за счет гуманитарных и научных сфер. SA применим к любому интересному объекту.
Дуглас Т. Росс, SofTecb и МТИ, ноябрь 1986 г.
Дата добавления: 2015-09-11; просмотров: 20 | Поможем написать вашу работу | Нарушение авторских прав |