SADT-модели и потоковые модели

 

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

• диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - для этой цели чаще всего используются DFD или SADT (IDEF0);

• диаграммы, моделирующие данные и их взаимосвязи (ERD);

• диаграммы, моделирующие поведение системы (STD).

Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного системного анализа могут быть разбиты на две группы - применяющие методы и технологию DFD (в различных нотациях) и использующие SADT-методологию. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет по материалам CASE Consulting Group 90% для DFD и 10% для SADT. По данным автора, основанным на анализе 127 существующих CASE-пакетов, это соотношение выглядит как 94% к 3%, соответственно. Оставшиеся 3% CASE-средств используют методологии, не относящиеся ни к одной из перечисленных разновидностей. Представляется очевидным, что соотношение такого же порядка справедливо и для цифр распространенности рассматриваемых методологий на практике.

Сравнительный анализ этих двух разновидностей методологий проводится по следующим параметрам:

• адекватность средств рассматриваемой проблеме;

• согласованность с другими средствами структурного анализа;

• интеграция с последующими этапами разработки (и прежде всего, с этапом проектирования).

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

1. Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. Предметом бизнес-консалтинга являются организационные системы (точнее, функционирование или деятельность таких систем). Для моделирования таких систем традиционно используется методология SADT (точнее, ее подмножество IDEF0). Однако статическая SADT-модель не обеспечивает полного решения задач бизнес-консалтинга, необходимо иметь возможность исследования динамических характеристик бизнес-процессов. Одним из решений является использование методологии и средств динамического моделирования, основанной, например, на цветных (раскрашенных) сетях Петри CPN (Color Petri Nets). Фактически SADT и CPN служат компонентами интегрированной методологии бизнес-консалтинга: SADT-диаграммы автоматически преобразуются в прообраз CPN-модели, которая затем дорабатывается и исполняется в различных режимах, чтобы получить соответствующие оценки.

Следует отметить, что не существует принципиальных ограничений в использовании DFD в качестве средства построения статических моделей деятельностей. Более того, в настоящий момент доступен ряд методологий и продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи бизнес-консалтинга.

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

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

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

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

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

2. Согласованность. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моделирования. Согласование SADT-модели с ERD и/или STD практически невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели. В таблице 2.1 отражена возможность такой интеграции для DFD и SADT-моделей.

Таблица 2.1

Возможность интеграции между моделями различных типов

 

Название	ERD	STD	Структурные карты
DFD	+	+	+
SADT	+	-	-

 

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

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

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

 

 

Методология SSADM

 

Примером еще одной методологии, ориентированной на диаграммы потоков данных, является методология SSADM (Structured Systems Analysis and Design Method). Она создана в начале 1980-х годов и принята в 1993 году в качестве национального стандарта Великобритании для разработки информационных систем. Ее несомненным достоинством является наличие взаимосогласованных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. В то же время SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы, отсылая разработчика к другим общедоступным методологиям, рекомендуемым британским государственным агентством по информатике и вычислительной технике.

В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELH (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.

Согласно SSADM определение системных требований включает следующие шесть основных этапов.

1. Оценка реализуемости. Данный этап предваряет инициацию работ по созданию системы.

Его основными процессами являются следующие:

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

• предварительную экономическую оценку проекта;

• построение план-графика выполнения основных работ;

• подготовку документов по оценке возможности создания системы.

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

• определение границ будущей системы;

• выявление основных требований;

• выявление процессов обработки информации;

• выявление обрабатываемых данных;

• построение информационно-логической модели требований;

• обобщение результатов и подготовка отчетов.

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

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

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

6. Физическое проектирование. Этап состоит из:

• разработки физической информационной модели;

• разработки спецификаций к программным компонентам;

• оптимизации информационной модели;

• уточнения спецификаций к программным компонентам;

• оформления документации.

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

• среднее время наработки на отказ;

• время отклика;

• ограничения доступа;

• требования безопасности и т.п.