1.4.3. Пользователь, функция и моделирование данных.

В процессе анализа собирается информация о ролях пользователя и целях этих ролей.

Она заносится в "Каталог пользователя" и "Каталог требований" и впоследствии

уточняется характеристиками ролей пользователя.

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

• традиционные процедуры, применяемые различными пользователями;

• обычные процедуры-реакции на различные события.

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

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

• реляционного анализа и логического моделирования данных при определении

требований к данным;

• моделированием потоков данных при уточнении требований к функционированию системы;

• объектно-событийным моделированием при формализации путей доступа

процессов обработки данных к данным:

• логическим моделированием данных для путей доступа запросов к данным;

• прототипированием для дальнейшего исследования и проверки правильности требований.

Схема реализации метода "Определение функций" показывается на рис. 1.5.

Рис 1.5. Схема определения функций

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

Теоретические предпосылки SSADM берут свое начало от:

• представления объектов и связей по Бахману [3,8];

• представления отношений по Кодду [5];

• подхода Джексона [4] к рассмотрению связей структур функционирования со структурами данных с использованием терминологии последовательностей, принятия решений и итераций.

Поначалу собранная информация и приобретенные знания о функциональных и информационных потоках определяются и представляются через элементарные, простые понятия. Системные требования представляются в виде схем потоков данных, с помощью которых на одном рисунке показываются:

• данные;

• процессы;

• зависимости по данным;

• внешние объекты (пользователи и другие системы).

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

Рис. 1.6. Разработка существенных деталей схемы потоков данных

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