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

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

Cодержание

Предисловие

Замечательно, что эта первая, посвященная 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 г.

Введение

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