67
Рисунок 2.3 - Дерево функций программных модулей
Сценарий диалога - программа некоторой виртуальной машины, т.е.
совокупность команд, организованная таким образом, что в каждый момент
68
работы виртуальной машины известно, какая из них должна выполняться
следующей.
Сценарий диалога включает шаги диалога и состояния диалога. Шаг
диалога - процесс достижения элементарной подцели диалога: действие
одного участника - реакция другого. Шаг диалога состоит из некоторого
числа состояний диалога. Состояние диалога - это характеристика состояния
ППП в произвольной точке шага диалога.
На основании дерева функций разработан сценарий диалога,
схематически представленный на рис. 2.4. Рассмотрим подробно процедуру
«Пользователи».
69
Рисунок 2.4 – Сценарий диалога работы с пунктом «Пользователи»
2.3.2 Характеристика базы данных
В основе современных проектов БД заложены объектные и
реляционные модели данных. В основу объектных модели положена
концепция представления предметной области виде классов объектов и
отношений между ними. Автором реляционной модели считается Э. Кодд,
который первым предложил использовать для обработки данных аппарат
70
теории множеств (объединение, пересечение, разность, декартово
произведение множеств и др.) и показал, что любое представление данных
сводится к совокупности двумерных таблиц особого вида, известного в
математике как отношение. Таким образом, реляционная база данных
представляет собой совокупность связанных между собой реляционных
отношений.
Существует два основных метода проектирования реляционных баз
данных: нисходящий и восходящий.
Разработка снизу-вверх (восходящее проектирование) – это получение
целого (описания предметной области) на основе составляющих его частей.
Восходящее проектирование начинается с определения атрибутов, которые
на основе анализа существующих между ними в предметной области
зависимостей группируются в реляционные отношения. Полученные схемы
реляционных отношений подвергаются процессу нормализации, основанного
на анализе функциональных, транзитивных, множественных и других видах
зависимостей между атрибутами. Восходящий метод проектирования
подходит для баз данных с относительно небольшим количеством атрибутов.
Проектирование БД сверху-вниз (нисходящее проектирование)
основано на декомпозиции – разделение целого на составные части с
последующим их исследованием. Использование нисходящего подхода
применимо при разработке БД с большим количеством атрибутов, поскольку
установить среди этих атрибутов все существующие в предметной области
зависимости затруднительно, гораздо проще выявить значимые для
предметной области существительные и связи между ними. Метод
нисходящего проектирования базы данных основан на разработке моделей
предметной области, которые содержат высокоуровневые сущности (классы
объектов) и связи (отношения) между ними.
При разработке модели данных необходимо учитывать:
исключение или сведение к минимуму повторяющихся данных
путем задания нормализованных структур;
71
обеспечение всем пользователям быстрого доступа к данным;
возможность расширения структуры модели данных;
обеспечение целостности данных;
предотвращение несанкционированного доступа к данным;
предоставление делегированного доступа к данным отдельному
пользователю или группе пользователей;
снижение сложности создания приложений, предназначенных для
ввода, редактирования, обработки данных, а также анализа скрытых
закономерностей в структурах данных.
Иерархия функций автоматизированной системы представлена в табл.
2.4.
Таблица 2.4 - Иерархия функций автоматизированной системы
Соединение с БД
Ведение справочных
данных
Фамилия, имя,
отчество
сотрудника
Добавление/Обновление
Ф1
Поиск/Просмотр
Ф2
Должность
Добавление/Обновление
Ф3
Поиск/Просмотр
Ф4
Отдел
Добавление/Обновление
Ф5
Поиск/Просмотр
Ф6
Производитель
Добавление/Обновление
Ф7
Поиск/Просмотр
Ф8
Название, модель,
серийный номер
техники
Добавление/Обновление
Ф9
Поиск/Просмотр
Ф10
Ведение учетных данных
Движение техники
Добавление/Обновление
Ф11
Поиск/Просмотр
Ф12
Ремонт техники
Добавление/Обновление
Ф13
Поиск/Просмотр
Ф14
Продолжение таблицы 2.4
Ведение документации
по движению техники
Распоряжения
Добавление/Обновление
Ф15
Поиск/Просмотр
Ф16
Приказы
Добавление/Обновление
Ф17
Поиск/Просмотр
Ф18
Формирование листа на
списание техники
Выполнение/Просмотр
Ф19
72
Информационно-логическая модель (ИЛМ) предметной области
является проблемно-ориентированной и системно-независимой, она не
зависит от конкретной СУБД, операционной системы и аппаратного
обеспечения АС. Назначение ИЛМ предметной области – адекватное, единое,
интегрированное и непротиворечивое отображение реального мира в рамках
решаемой задачи автоматизации; отражение потребностей всех
пользователей разрабатываемой АС.
ИЛМ предметной области представляет классы объектов предметной
области и связи (отношения) между ними. Связи относятся к одному из
следующих типов: «один-к-одному» (1:1) и «один-ко-многим» (1:М).
ER-диаграмма предметной области представлена на рис. 2.5.
Рисунок 2.5 – ER-диаграмма предметной области
73
2.3.3 Структурная схема пакета
Идентификатор - это уникальный код модуля по списку метаданных.
Разработанный модуль включает в себя серверную и клиентскую часть
Серверная часть является приложением для взаимодействия с базой данных,
клиентская –интерфейсом для ввода данных и получения отчетной
информации. Структурная схема пакета представлена на рис. 2.6.
Рисунок 2.6 – Структурная схема пакета
На Рисунке 2.7 представлено дерево программных модулей,
отражающее структурную схему пакета.
Рисунок 2.7 – Дерево программных модулей
74
2.3.4 Описание программных модулей
При использовании технологии структурного программирования
реализация компонентов автоматизированной системы может быть
представлена в виде иерархии модулей. Иерархическая структура программы
демонстрирует порядок взаимодействия основных модулей программной
системы. На рис. 2.8 представлена иерархия модулей автоматизированной
системы.
Рисунок 2.8 – Иерархия модулей автоматизированной системы
Спецификация модулей автоматизированной системы представлена в
табл. 2.5.
Таблица 2.5 - Спецификация модулей автоматизированной системы
Название
Назначение
Вызываю-
щий модуль
Входные
данные
Выходные
данные
frmMain
Активация главного
меню программы
frmIdent
frmIdent
Аутентификация
Логин и пароль
пользователя
Проверка
авторизации
Global
Переменные
frmUsers
Ведение справочника
пользователей
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
75
Продолжение таблицы 2.5
frmPost
Ведение справочника
должностей
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmDepart
Ведение справочника
отделов
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmManuf
Ведение справочника
производителей
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmEquipment
Ведение справочника
техники
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmComplit
Состав техники
frmEquipment
Изменения,
вносимые
пользователем
Обновленный
справочник
frmReestr
Реестр документов
frmMain
Данные о
документах
Список
документов
frmOrder
Документ
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmRepair
Ремонт техники
frmMain
Изменения,
вносимые
пользователем
Обновленный
справочник
frmSpisanie
Формирование листа на
списание
frmMain
Данные на
списание
Сформированн
ый список
frmAbout
О программе
frmMain
Взаимодействие модулей автоматизированной системы отображает
обобщенная схема алгоритма, которая представлена на рис. 2.9.
При работе со справочником Пользователь выбирает нужный
справочник на панели навигации, или меню системы, загружает его,
производит нужные действия и сохраняет данные в базе данных.
Алгоритм работы со справочником представлен на рис. 2.10.
При передаче техники Пользователь открывает форму формирования
документа, вводит нужные данные о сопутствующем документе, вводит
перечень техники, подлежащей передаче, и формирует документ.
76
Рисунок 2.9 - Обобщенная схема алгоритма взаимодействия модулей
автоматизированной системы