Средства структурного анализа и их взаимоотношения

 

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

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

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

• функции, которые система должна выполнять;

• отношения между данными;

• зависящее от времени поведение системы (аспекты реального времени).

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

DFD (Data FlowDiagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями.

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".

STD (State Transition Diagrams) - диаграммы переходов состояний.

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

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

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

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

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

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

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