РАЗДЕЛ 2
Построение и анализ многокритериальных моделей принятия решений при
проектировании баз данных ИНФОРМАЦИОННЫХ СИСТЕМ
2.1 Разработка метода формализации предметной области
На основании проведенного анализа в разделе 1 было установлено, что разработка
ИС подчиняется определенному жизненному циклу. На детализированном уровне
жизненный цикл можно разделить на следующие семь этапов: установление
требований, спецификация требований, проектирование архитектуры,
детализированное проектирование, реализация, интеграция, сопровождение (и
окончательное сворачивание). Жизненный цикл определяет данные этапы таким
образом, что программный продукт, реализующий функции ИС, переходит с одного
этапа на другой.
В настоящей диссертационной работе основное внимание уделено первым пяти этапам
жизненного цикла ИС, на которых происходит формирование структуры ИО будущей
ИС.
Задачей этапа установления требований является определение, анализ и обсуждение
требований с заказчиком. На этом этапе применяются различные методы сбора
информации от заказчиков: это исследование концепции с помощью
структурированных и неструктурированных интервью пользователей, анкеты,
изучение документов и форм, видеозаписи и т.д. Результатом этапа установления
требований является документ, содержащий изложение требований. Это большей
частью текстовый документ с некоторыми неформальными диаграммами и таблицами.
Этап спецификации требований начинается с того момента, когда разработчики
приступают к моделированию требований с использованием определенного метода
(например, такого как UML). CASE-средства используются для ввода, анализа и
документирования модели. В результате документ описания требований дополняется
графическими моделями и отчетами, сгенерированными с помощью CASE-средств. По
существу, документ, излагающий требования, заменяется документами, содержащим
спецификацию требований.
В данном разделе предложен усовершенствованный метод формализованного описания
ПрО, спецификации информационных требований пользователей, а также анализа
информационных структур пользователей и построения канонических структур ЛБД и
СБД. Для описания предложенного метода введем ряд понятий и определений.
Под ПрО пользователей будем понимать информацию о совокупности объектов
автоматизации и их характеристиках, которая представляется в виде специальных
структур данных и используется пользователями для решения различных
функциональных задач ИС [29, 66]. Описание ПрО пользователей включает следующие
основные компоненты [21]: автоматизируемые функции и задачи (процедуры)
обработки данных и их характеристики, пользователи, информационные элементы и
отношения между ними, характеристики информационных элементов и процедур
обработки данных, отношения между информационными элементами и процедурами.
Модель ПрО может быть представлена в виде семерки
, (2.1)
где – множество автоматизируемых функций;
– множество задач (процедур) обработки данных;
– множество пользователей;
– множество объектов автоматизации;
– множество входных данных;
– множество выходных данных;
– полное множество информационных элементов ПрО;
– множество отношений (взаимосвязей) между компонентами .
Формализовано модель ПрО описывается с помощью множеств и булевых матриц
смежности , , , , , , , , которые описывают соответствующие отношения между
компонентами ПрО. Элементы данных матриц равны 1, если между соответствующими
компонентами имеется отношение (взаимосвязь), и равны 0 в противном случае.
Исходными данными для формирования модели ПрО пользователей являются результаты
предпроектных исследований и анализа объектов информатизации и соответствующих
бизнес-процессов, которые представляются в соответствующих стандартных формах
материалов обследования (документ) либо с использованием языков визуального
моделирования (IDEF, ARIS, UML и т.д.).
Для информационного наполнения модели ПрО и построения отношений между
элементами ПрО необходимо разработать диалоговую процедуру, которая позволит
ЛПР (разработчику БД) полно и непротиворечиво ввести необходимые данные.
Предложенная процедура состоит из следующих шагов:
Шаг 1. На основании предварительно проведенного предпроектного анализа объекта
автоматизации в режиме диалога с ЭВМ вводится перечень автоматизируемых функций
и входящих в них задач , .
Шаг 2. Для каждой задачи выделяется множество пользователей данной задачи , ,
которое вводится в таблицу в режиме диалога с ЭВМ.
Шаг 3. На основании анализа входных и выходных документов по всем
автоматизируемым функциям и задачам заполняется таблица информационных
элементов , которая содержит наименование информационного элемента, его кодовое
название (латиницей) и тип.
Шаг 4. На основании результатов анализа перечня информационных элементов
заполняется таблица объектов . Данная таблица содержит наименование объекта,
его кодовое название (латиницей) и принадлежащий ему информационные элементы.
Шаг 5. Заполняется таблица соответствия задач и объектов , информация о которых
используется в этих задачах: .
Шаг 6. Орграф информационной структуры строится на основании парных отношений
между объектами, а также между объектами и информационными элементами.
Разработчик БД, используя знания о ПрО, в ручном режиме вводит пары отношений
«объект-объект».
Необходимо отметить, что шаги 3, 4 и 6 являются обязательными, а шаги 1, 2 и 5
предназначены для более четкой структуризации ПрО, проверки на целостность и
непротиворечивость исходных данных и являются вспомогательными
(необязательными). В случае разработки распределенной БД все шаги являются
обязательными, так как соста
- Київ+380960830922