Привет студент

4 Моделирование компонентов экспертной системы

4.1 Формирование функциональной составляющей

Одной из важных задач в ходе анализа предметной области является определение масштаба проекта АС, выделение функций системы, объединение их в задачи, задач — в функциональные подсистемы. Состав функциональных подсистем разрабатываемой автоматизированной системы, во многом, определяется характером деятельности предприятия, формой собственности, размером.

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

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

Удобно представлять перечень выявленных в составе задачи автоматизации функции в виде иерархии их взаимодействия. Иерархия функций позволяет отобразить функциональные зависимости автоматизируемых процессов.

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

Иерархия функций АС представлена в приложении А.

4.2 Проектирование информационного обеспечения ЭС

4.2.1 Внешний уровень архитектуры БД

4.2.1.1 Формализованное описание предметной области

Описание внешнего уровня архитектуры базы данных формируют на основе состав пользователей АС и их уровни доступа.

Классы объектов предметной области, их свойства представлены в таблицах. Формализованное описание предметной области представлено в Приложении Б.

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

В столбце «Уникальный идентификатор» указывается признак вхождения свойства в состав уникального идентификатора (УИ) класса объектов, а также признак главного уникального идентификатора — кандидата для первичного ключа.

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

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

В столбце «Опциональность значения» указывается обязательность значения свойства при сохранении информации об объекте в базе данных. Рекомендуется использовать следующие обозначения:

— для обязательного значения «д.б.» (должно быть);

— для необязательного значения: «м.б.» (может быть).

В столбце «Логические ограничения» описываются выявленные в предметной области ограничения на значение свойства — вхождение значения в диапазон, список, перечень используемых в значении свойства символов и т.п. При этом необходимо помнить правила написания русского языка (имя собственное пишется с заглавной буквы и др.).

В столбце «Процессы» описываются действия, которые могут происходить со значением свойства. Для базы данных присущи следующие операции над значениями: добавление (генерация значения), обновление, удаление, просмотр (чтение). Необходимо отметить, что операция «удаление» является запрещенной для базы данных, входящей в состав ЭС[5].

Отношения между классами объектов описаны в таблице 3. При этом необходимо помнить, что каждая связь является двусторонней, выявляются главный и подчиненный классы объектов, характеристики связи для каждой стороны. Главным для каждой связи является тот класс объектов, информация о котором первой появляется в предметной области. В таблице использованы сокращения: 1 — тип (мощность) связи «один», М — тип связи «много», «д.б.» — связь обязательная, «м.б.» — связь необязательная.

Таблица 3 — Связи между классами объектов

Продолжение таблицы 3

4.2.1.2 Пользователи ЭС

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

— Администратор. Обладает всеми правами, может осуществлять все действия с базой данных, её объектами и их поколениями (версиями, копиями);

— Прикладной программист. Обладает всеми правами на все действия с объектами БД и системы, и их поколениями;

— Эксперт. Выполняет операции добавления, обновления, поиска и просмотра справочных и статистических данных. Рекомендуемые должности: врач-педиатр высшей категории, врач-статистик;

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

Определение уровней доступа пользователей может быть формализовано уже на этапе анализа предметной области. На дальнейших этапах проектирования БД уровни доступа уточняются и затем реализуются администратором БД средствами СУБД. В таблице 4 приведены примеры доступа пользователей системы «быстрая диагностика» на уровне классов объектов.

Таблица 4 — Доступ пользователей

В таблице 4 введены обозначения: R — чтение данных, I — добавление, U — обновление, D — удаление данных.

4.3.2 Концептуальный уровень архитектуры БД

4.3.2.1 Информационно-логическая модель

Исходными данными для построения информационно-логической модель предметной области являются результаты анализа предметной области, представленные в виде описания классов объектов и связей между ними. Чаще всего информационно-логическая модель предметной области представляют в терминах семантической модели данных — ER модели (Рисунок 5).

Необходимо отметить, что выявление в предметной области классов объектов, связей, описание и отображение их в диаграмме происходит параллельно.

Рисунок 5 — Информационно-логическая модель предметной области

Приведем результаты проверки соответствия полученной модели предметной области заявленному составу функций ЭС. Проверка приводится в формализованном виде, результаты представлены в таблице 5.

Таблица 5 — Перекрестная проверка модели предметной области и основных функций ЭС

В таблице 5 введены обозначения: R — чтение данных, I — добавление, U — обновление данных.

4.2.3 Внутренний уровень архитектуры БД

Проектирование внутреннего уровня БД заключается в преобразовании логической модели данных в такую форму, которая позволит реализовать данный проект в среде выбранной СУБД.

Каждое отношение схемы реляционной базы данных, полученное на этапе даталогического проектирования, должно быть описано на языке ЯОД СУБД и содержать следующие конструкции:

— имя отношения (таблицы);

— имена атрибутов (полей);

— определение первичных ключей;

— определение уникальных (потенциальных) ключей;

— определение физических характеристик атрибута (тип и длину);

— определение обязательности значения атрибута;

— определение логических ограничений на значение атрибута.

В начале физического проектирования реляционных таблиц удобно создать техническое описание этих таблиц, что затем позволит более эффективно создавать текстовое описание их структур на языке SQL [5].

Техническое описание можно представить в виде таблиц, представленных в приложении В.

SQL-скрипты объектов базы данных, содержащие комментарии, приведены в приложении Г.