CASE. Структурный системный анализ.
ГЛАВА 10. ПРИМЕРЫ СТРУКТУРНЫХ МЕТОДОЛОГИЙ
-----------------------------------------
Методологии структурного анализа Йодана/де Марко и Гейна-Сарсона
---------------------------------------------------------------------
Как уже неоднократно отмечалось, структурный анализ - это
систематический пошаговый подход к анализу требований и проектированию
спецификаций системы независимо от того, является ли она существующей или
создается вновь. Методологии Гейна-Сарсона и Йодана/Де Марко, основанные
на идее нисходящей иерархической организации, наиболее ярко демонстрируют
этот подход.
Целью рассматриваемых методологий является преобразование общих,
неясных знаний о требованиях к системе в точные (насколько это возможно)
определения. Обе методологии фокусируют внимание на потоках данных, их
главное назначение - создание базированных на графике документов по
функциональным требованиям. Методологии поддерживаются традиционными
нисходящими методами проектирования спецификаций и обеспечивают один из
лучших способов связи между аналитиками, разработчиками и пользователями
системы за счет интеграции множества следующих средств:
¦ DFD - диаграммы потоков данных. Являются графическими
иерархическими спецификациями, описывающими систему с позиций
потоков данных. В состав DFD могут входить четыре графических
символа, представляющих потоки данных, процессы преобразования
входных потоков данных в выходные, внешние источники и получатели
данных, а также файлы и БД, требуемые процессами для своих
операций.
¦ Словари данных. Являются каталогами всех элементов данных,
присутствующих в DFD, включая групповые и индивидуальные потоки
данных, хранилища и процессы, а также все их атрибуты.
¦ Миниспецификации обработки, описывающие DFD-процессы нижнего уровня
и являющиеся базой для кодогенерации. Фактически миниспецификации
представляют собой алгоритмы описания задач, выполняемых
процессами: множество всех миниспецификации является полной
спецификацией системы. Миниспецификации содержат номер и/или имя
процесса, списки входных и выходных данных и тело (описание)
процесса, являющееся спецификацией алгоритма или операции,
трансформирующей входные потоки данных в выходные. Известно большое
число разнообразных методов, позволяющих задать тело процесса,
соответствующий язык может варьироваться от структурированного
естественного языка или псевдокода до визуальных языков
проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и
формальных компьютерных языков.
DFD-диаграммы являются ключевой частью документа спецификации
требований. Каждый узел-процесс в DFD может развертываться в диаграмму
нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей
(отметим, что структурные методологии, ориентированные на потоки
управления, не обладают этим свойством). Проектные спецификации строятся
по DFD и их миниспецификациям автоматически. Наиболее часто для описания
проектных спецификаций используется методика структурных карт Джексона,
иллюстрирующая иерархию модулей, связи между ними и некоторую информацию
об их исполнении (последовательность вызовов, итерацию). Существует ряд
методов автоматического преобразования DFD в структурные карты: один из
таких методов, а также реализующий его алгоритм приводится Фишером в его
обзорной книге по CASE-технологиям [Fisher 1988].
DFD моделируют функции, которые система должна выполнять, но ничего
(или почти ничего) не сообщают об отношениях между данными, а также о
поведении системы в зависимости от времени - для этих целей методологии
используют диаграммы "сущность-связь" и диаграммы переходов состояний,
соответственно.
Главной отличительной чертой методологии ГейнаСарсона является
наличие этапа моделирования данных, определяющего содержимое хранилищ
данных (БД и файлов) в DFD в Третьей Нормальной Форме. Этот этап включает
построение списка элементов данных, располагающихся в каждом хранилище
данных; анализ отношений между данными и построение соответствующей
диаграммы связей между элементами данных; представление всей информации по
модели в виде связанных нормализованных таблиц. Кроме того, методологии
отличаются чисто синтаксическими аспектами, так, например, различны
графическое символы, представляющие компоненты DFD.
Таким образом методы в рассматриваемых подходах представляют собой
"кулинарную книгу" с рецептами, помогающими от чистого листа бумаги или
экрана перейти к хорошо организованной модели системы. Эти рецепты
основаны на простой концепции нисходящего поэтапного разбиения функций
системы на подфункции. На первом этапе формируется контекстная диаграмма
верхнего уровня, идентифицирующая границы системы и определяющая
интерфейсы между системой и окружением. Затем, после интервьюирования
эксперта предметной области, формируется список внешних событий, на
которые система должна реагировать. Для каждого из таких событий строится
пустой процесс ("bubble") в предположении, что его функция обеспечивает
требуемую реакцию на это событие, которая в большинстве случаев включает
генерацию выходных потоков и событий (но может также включать и занесение
информации в хранилище данных для ее использования другими событиями и
процессами). На следующем уровне детализации аналогичная деятельность
осуществляется для каждого из пустых процессов.
В качестве примера рассмотрим верхний уровень функциональной модели
компании, занимающейся распределением товаров по заказам (рис. 10.1).
Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает
номенклатуре товаров или оформлен неправильно, то он аннулируется с
соответствующим уведомлением заказчика. Если заказ не аннулирован, ТО
определяется, имеется ли на складе соответствующий товар. В случае
положительного ответа выписывается счет к оплате и предъявляется
заказчику, при поступлении платежа товар отправляется заказчику. Если
заказ не обеспечен складскими запасами, то отправляется заявка на товар
производителю. После поступления требуемого товара на склад компании заказ
становится обеспеченным и повторяет вышеописанный маршрут. При построении
данной модели использована нотация Гейна-Сарсона.
Рис. 10.1: Пример диаграммы Гейна-Сарсона.
SADT-технология структурного анализа и проектирования
---------------------------------------------------------------------
SADT (Structured Analysis and Design Technique) - одна из самых
известных методологий анализа и проектирования систем, введенная в 1973 г.
Россом (Ross). SADT успешно использовалась в военных, промышленных и
коммерческих организациях для решения широкого спектра задач, таких как
программное обеспечение телефонных сетей, системная поддержка и
диагностика, долгосрочное и стратегическое планирование,
автоматизированное производство и проектирование, конфигурация
компьютерных систем, обучение персонала, встроенное ПО для оборонных
систем, управление финансами и материально-техническим снабжением и др.
Данная методология широко поддерживается Министерством обороны США,
которое было инициатором разработки стандарта IDEF0 как подмножества SADT.
Это, наряду с растущей автоматизированной поддержкой, сделало ее более
доступной и простой в употреблении.
С точки зрения SADT модель может основываться либо на функциях
системы, либо на ее предметах (планах, данных, оборудовании, информации и
т.д.). Соответствующие модели принято называть активностными моделями и
моделями данных. Активностная модель представляет с нужной степенью
подробности систему активностей, которые в свою очередь отражают свои
взаимоотношения через предметы системы. Модели данных дуальны к
активностным моделям и представляют собой подробное описание предметов
системы, связанных системными активностями. Полная методология SADT
заключается в построении моделей обеих типов для более точного описания
сложной системы. Однако, в настоящее время широкое применение нашли только
активностные модели, их рассмотрению и посвящен данный раздел.
Основным рабочим элементом при моделировании является диаграмма.
Модель SADT объединяет и организует диаграммы в иерархические древовидные
структуры, при этом чем выше уровень диаграммы, тем она менее
детализирована. В состав диаграммы входят блоки, изображающие активности
моделируемой системы, и дуги, связывающие блоки вместе и изображающие
взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в
диаграмме было 3-6 блоков: в этих пределах диаграммы и модели удобны для
чтения, понимания и использования. Вместо одной громоздкой модели
используются несколько небольших взаимосвязанных моделей, значения которых
взаимодополняют друг друга, делая понятной структуризацию сложного
объекта. Однако такое жесткое требование числа блоков на диаграмме
ограничивает применение SADT для ряда предметных областей. Например, в
банковских структурах имеется 15-20 равноправных деятельностей, которые
целесообразно отразить на одной диаграмме. Искусственное их растаскивание
по разным уровням SADT-модели явно не улучшает ее понимаемость.
Блоки на диаграммах изображаются прямоугольниками и сопровождаются
текстами на естественном языке, описывающими активности. В отличие от
других методов структурного анализа в SADT каждая сторона блока имеет
вполне определенное особое назначение: левая сторона блока предназначена
для Входов, верхняя-для Управления, правая - для Выходов, нижняя-для
Исполнителей. Такое обозначение отражает определенные принципы активности:
Входы преобразуются в Выходы, Управления ограничивают или предписывают
условия выполнения, Исполнители описывают, за счет чего выполняются
преобразования.
Дуги в SADT представляют наборы предметов и маркируются текстами на
естественном языке. Предметы могут состоять с активностями в четырех
возможных отношениях: Вход, Выход, Управление, Исполнитель. Каждое из этих
отношений изображается дугой, связанной с определенной стороной блока -
таким образом стороны блока чисто графически сортируют предметы,
изображаемые дугами. Входные дуги изображают предметы, используемые и
преобразуемые активностями. Управляющие дуги обычно изображают информацию,
управляющую действиями активностей. Выходные дуги изображают предметы, в
которые преобразуются входы. Исполнительские дуги отражают (по крайней
мере частично) реализацию активностей (рис. 10.2).
Рис. 10.2: Пример SADT-блока.
Блоки на диаграмме размещаются по "ступенчатой" схеме в соответствии
с их доминированием, которое понимается как влияние, оказываемое одним
блоком на другие. Кроме того, блоки должны быть пронумерованы, например, в
соответствии с их доминированием. Номера блоков служат однозначными
идентификаторами для активностей и автоматически организуют эти активности
в иерархию модели.
Взаимовлияние блоков может выражаться либо в пересылке Выхода к
другой активности для дальнейшего преобразования, либо в выработке
управляющей информации, предписывающей, что именно должна делать другая
активность. Таким образом, диаграммы SADT являются предписывающими
диаграммами, описывающими как преобразования между Входом и Выходом, так и
предписывающие правила этих преобразований.
В SADT требуются только пять типов взаимосвязей между блоками для
описания их отношений: Управление, Вход, Управленческая Обратная Связь,
Входная Обратная Связь, Выход-Исполнитель. Отношения Управления и Входа
являются простейшими, поскольку они отражают интуитивно очевидные прямые
воздействия. Отношение Управления возникает тогда, когда Выход одного
блока непосредственно влияет на блок с меньшим доминированием. Отношение
Входа возникает, когда Выход одного блока становится Входом для блока с
меньшим доминированием. Обратные связи более сложны, поскольку они
отражают итерацию или рекурсию - Выходы из одной активности влияют на
будущее выполнение других функций, что впоследствии влияет на исходную
активность. Управленческая Обратная Связь возникает, когда Выход
некоторого блока влияет на блок с большим доминированием, а отношение
Входной Обратной Связи имеет место, когда Выход одного блока становится
Входом другого блока с большим доминированием. Отношения ВыходИсполнитель
встречаются нечасто и представляют особый интерес. Они отражают ситуацию,
при которой Выход одной активности становится средством достижения цели
Другой активностью (рис. 10.3).
Рис. 10.3: Пример отношения Выход-Исполнитель
Дуги SADT, как правило, изображают наборы предметов, поэтому они
могут разветвляться и соединяться вместе различным образом. Разветвления
дуги означают, что часть ее содержимого (или весь набор предметов) может
появиться в каждом ответвлении дуги. Дуга всегда помечается до
разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь
дуги может быть помечена в соответствии со следующими правилами: считается
что непомеченная ветвь содержит все предметы, указанные в метке перед
разветвлением; каждая метка ветви уточняет что именно содержит эта ветвь.
Слияние дуг указывает,' что содержимое каждой ветви участвует в
формировавании после слияния объединенной дуги. После слияния дуга всегда
помечается для указания нового набора, кроме того, каждая ветвь перед
слиянием может помечаться в соответствии со следующими правилами:
считается, что непомеченные ветви содержат все предметы, указанные в общей
метке после слияния; каждая метка ветви уточняет, что именно содержит эта
ветвь.
При создании модели одна и та же диаграмма чертится несколько раз,
что создает различные ее варианты. Чтобы различать различные версии одной
и той же диаграммы, в SADT используется схема контроля конфигурации
диаграмм, основанная на их номерах. Если диаграмма замещает более старый
вариант, то предыдущий номер помещается в скобках для указания связи с
предыдущей работой.
Пример SADT-диаграммы, моделирующей деятельность компании,
занимающейся распределением товаров по заказам (рис. 10.1), приведен на
рис. 10.4.
Рис. 10.4: Пример SADT-диаграммы
SADT, как и другие методологии проектирования, целесообразно
использовать на ранних этапах ЖЦ: для понимания системы до ее воплощения.
SADT позволяет сократить дорогостоящие ошибки на ранних этапах создания
системы, улучшить контакт между пользователями и разработчиками, сгладить
переход от анализа к проектированию. Несомненное достоинство SADT
заключается в том, что она легко отражает такие характеристики как
управление, обратная связь и исполнители.
Методологии, ориентированные на данные
---------------------------------------------------------------------
С позиций ориентированных на данные методологий вход и выход модели
являются наиболее важными, структуры данных (а не потоки данных)
определяются первыми, а процедурные компоненты строятся как производные от
структур данных. Фактически процесс проектирования заключается в
определении структур данных, слиянии их в некий прообраз иерархической
структуры программы и наполнении этой структуры детальной логикой
обработки данных. Для поддержки такого подхода традиционно используются
сетевые диаграммы для определения потоков, источников и приемников данных,
древовидные структурные диаграммы для представления иерархии как структур
данных, так и программных структур, а также диаграммы детализации логики
процедур (обычно на базе структурированного естественного языка).
Классическим примером рассматриваемого подхода является структурное
проектирование Джексона. Его базовая процедура проектирования
предназначена для "простых" программ ("сложная" программа разбивается на
"простые" традиционными методами) и включает следующие 4 этапа:
1. Этап проектирования данных.
¦ Построение системной сетевой диаграммы, демонстрирующей все
хранилища, источники и стоки данных в программе.
¦ Представление каждой входной и выходной структуры данных
древовидной структурной диаграммой.
2. Этап проектирования программ.
¦ Формирование структуры программы комбинированием структур
данных.
¦ Идентификация всех связей между компонентами структур данных.
¦ Верификация полученной структуры программы.
3. Этап проектирования операций.
¦ Построение списка операций, необходимых для продуцирования
выходных структур данных из входных.
¦ Назначение операций компонентам структуры программы.
4. Этап проектирования текстов.
¦ Трансляция построенной модели программы в текстовый вид с
добавлением ряда логических условий для управления выполнением
циклов и выбором данных.
Другим примером рассматриваемого подхода является DSSD
(Data-Structured Systems Development), предложенная Варнье-Орром и
ориентированная на разработку систем со структурными данными методология,
использующая теорию множеств для описания проекта ПО.
Как и в математике, множество определяется перечислением его
элементов. Так множество отделов компании может быть описано следующим
образом:
компания = {бухгалтерия, маркетинг, производство,распространение}
DSSD использует аналогичную нотацию, а именно множественную скобку
(рис. 10.5).
Рис. 10.5: Множественная скобка
Подобно методологии Джексона, в рассматриваемом подходе структура
программы строится на базе структур данных, а главным отличием является
то, что в методологии Джексона необходимо сливать все входные и выходные
структуры данных для продуцирования структуры программы, а в DSSD входные
данные и структура программы продуцируются из выходных структур. Таким
образом, главная аксиома DSSD утверждает, что выходные структуры данных
полно и точно определяют входные структуры, которые, в свою очередь,
определяют и логику их обработки.
При построении модели в DSSD используются диаграммы сущностей
(диалект DFD) для определения системного контекста и диаграммы Варнье-Орра
(assembly line diagrams) в качестве основного средства моделирования
системы. Вазовым элементом диаграммы Варнье-Орра является множественная
скобка. Детализация элементов данных производится слева-направо,
предполагаемая последовательность действий осуществляется слева-направо и
сверху-вниз. Такая нотация удобна для представления композиции структур,
определения структур данных, спецификации форматов файлов, и может быть
использована для иллюстрирования структуры программы и иерархии модулей
(заменой структур данных на модули или файлы, а на нижних уровнях - на
подпрограммы, DO-циклы, условные и другие операторы), являясь в этом
случае неким аналогом визуального языка проектирования типа FLOW-форм.
Основные этапы методологии изображены на рис. 10.6 с помощью диаграммы
Варнье-Орра.
Рис. 10.6: Диаграмма Варнье-Орра
Основные этапы подхода Мартина
---------------------------------------------------------------------
IE-методология Мартина предоставляет общую стратегию разработки
информационных систем, фокусирующую внимание на стратегическом
планировании и бизнес-процессах. В то же время она является и инженерным
подходом к разработке ПО, т.к. обеспечивает нисходящую пошаговую процедуру
построения информационной системы (позволяя при этом работать с
неиерархическими структурами данных). Основные этапы подхода Мартина
приведены на рис. 10.7.
Рис. 10.7: Основные этапы подхода Мартина
1. Этап стратегического информационного планирования начинается с
построения стратегического плана для бизнес-системы, включающего
цели и стратегии их достижения. Далее строится модель предметной
области, отражающая существующую специфику и определяющая основные
бизнес-процессы и организационную структуру бизнес-системы, а
также определяется порядок разработки информационной системы. При
моделировании используются диаграммы декомпозиции (иерархические
древовидные структурные диаграммы) и диаграммы "сущность-связь"
для представления основных бизнес-процессов и структур данных,
соответственно.
2. На этапе анализа основные бизнес-процессы, разработанные на этапе
1, используются для разбиения общей задачи на частные, при этом
основное внимание уделяется определению информационной и
функциональной моделей для частных задач. При этом диаграммы
"сущность-связь" трансформируются в нормализованную модель данных,
а диаграммы декомпозиции распределяются по подзадачам. Для
представления процессов служат DFD, диаграммы зависимости данных
(диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и
процессов, в которых эти данные используются, применяются матрицы
"сущность/процесс".
3. На этапе логического проектирования 1Е становится аналогична SE
для разработки ПО. Базой для проектирования являются процессы,
разработанные на этапе анализа. Используя методики нисходящей
функциональной декомпозиции, проектируются спецификации обработки
в процессах и их логические структуры данных. При этом
используются диаграммы структуры данных (диалект ERD),
определяющие типы сущностей, их атрибуты и связи, диаграммы
декомпозиции и диаграммы деятельности (вид миниспецификации),
детализирующие логику процессов. Для согласования требований
пользователя создаются прототипы пользовательских интерфейсов с
помощью схем экранов/отчетов.
4. На этапе физического проектирования и реализации производится
преобразование логической модели ИС в физическую и ее реализация.
|
