66
Требования к сценарию диалога пользователей с системой.
На данном этапе разработки проекта информационной системы требуется
выбрать язык общения системы с конечным пользователем.
Диалог - это процесс обмена сообщениями между пользователем и
информационной системой, при котором выполняется постоянная смена ролей
информатора и реципиента (принимающего информацию пользователя), при
этом смена ролей является достаточно оперативной.
При применении для общения языка «меню» в диалоговой системе
должна присутствовать система планирования и управления диалогом. На
рисунке 20 представлены функции данной системы.
Рис. 20. Функции системы планирования и управления диалогом
Функции системы
планирования и управления
диалогом
Обеспечение реализации
справочных и сервисных
функций
Обеспечение интерфейса
пользователя
Вызов обрабатывающих
программ
Анализ и обработка
ошибочных ситуаций
Управление
процессом диалога
67
В процессе диалога возможно следующее:
двустороннее управление на базе языка типа «запрос-ответ»;
одностороннее управление со стороны информационной системы с
языком общения типа «меню», «заполнения шаблона»;
одностороннее управление со стороны пользователя с использованием
языка команд.
При создании программного продукта система общения с пользователем
должна быть организована так, что основная часть диалога ведется на языке типа
«меню», а заполнение форм входных документов - по «шаблону». Таким
образом, выполняется одностороннее управление процессом обработки данных
со стороны информационной системы.
Структура сценария диалога вкупе с деревом функций, отражающим
состав и иерархию функций системы, позволяет определить состав кадров
диалога и их содержание.
На рисунке 21 представлен сценарий диалога.
Рис.21. Сценарий диалога
Основное меню
Файл
Штатное
расписание
О программе
Справочники
Сотрудники
Приказы
Отчеты
Выход
Помощь
68
Сценарий диалога предусматривает возможность обеспечения следующих
функций управления ходом решения намеченных задач:
возможность работы с экранными формами входных документов;
формирование выходных документов;
корректировка и просмотр вводимых данных;
протоколирование действий пользователя.
Сценарий диалога включает две логически связанные части:
1) Основные меню, которые относятся к головному, то есть те экраны
меню, которые видит пользователь, прежде чем приступить к реализации
основных функций, согласно дереву функций.
2) Сервисные меню - становятся доступны конечному пользователю после
выдачи на экран соответствующей формы документа. Данные меню
предполагают возможные действия, некоторые из которых выполнять
необязательно [20].
2.3.2 Характеристика базы данных
Для создания оптимальной структуры реляционной БД требуется
выполнить анализ составляющих ее элементов и отношений между ними, а
затем нормализовать базу данных.
Благодаря анализу элементов БД и отношений между ними можно
построить структуру реляционной БД на основе идентификации объектов
данных и связей между ними.
При анализе необходимо выявить следующее:
- элементы БД;
- первичные ключи;
- элементы данных или атрибуты каждого элемента или объекта;
- соотношения между элементами для создания отношений между
первичными и внешними ключами;
Результатом анализа является модель "элементы-отношения", которая
логически представляет данные и связи между ними и является основой
физической реализации БД.
69
В процессе работы была создана база данных. В базе содержится вся
информация о сотрудниках предприятия. В таблице содержатся все введенные
пользователем посредством заполнением формы данные: ФИО сотрудника, дата
принятия на работу, должность, гражданство, пол, семейное положение и т.д.
Для функционирования программного обеспечения «Отдел кадров» в БД
необходимо хранить следующие данные: информацию о сотрудниках
предприятия, о приказах, о штатном расписании, справочную информацию.
В данной работе база данных является реляционной. В процессе ее
разработки были созданы следующие основные таблицы:
- сотрудник;
- диплом;
- стаж;
- должность;
- приказ.
Инфологический уровень – это информационно-логическая модель
предметной области, из которой исключена избыточность данных и отображены
информационные особенности объекта управление без учета особенностей и
специфики конкретной СУБД.
Иными словами, инфологическое представление данных направлено
главным образом на человека, разрабатывающего или использующегт базу
данных.
Инфологическая модель Таблицы-связи базы данных «Отдел кадров»
представлена на рисунке 22.
Логический уровень построен с учетом специфики и особенностей
конкретной СУБД.
На этом уровне формируется концептуальная модель данных, которая
отвечает выбранной СУБД.
Проанализировав характер данных, составляется даталогическая модель
(таблицы 3-7).
Построение даталогической модели позволяет представить каждую из
полученных сущностей (стержень, характеристика или ассоциация) базовой
таблицей.
70
Здесь происходит определение первичных ключей, спецификация
ограничений на внешние ключи, присвоение полям таблиц типа данных и
описание ограничений, соблюдение которых не допускает ошибочного
заполнения таблиц.
Рис.22. Инфологическая модель базы данных «Отдел кадров»
В качестве даталогической модели БД была выбрана реляционная модель,
так как именно эта модель является результатом более развитых представлений
о формировании и ведении баз данных.
Реляционные модели наиболее логично и наглядно отражают структуру
хранимой информации и внутренних связей, благодаря чему можно выполнить
более полный анализ структуры БД при разработке.
Именно поэтому сегодня такие модели являются самыми популярными и
неким стандартом, на который переводятся все существовавшие ранее базы
данных с иерархической и сетевой моделью.
Должность
Код
Организация
Группа
Должность
Оклад
Вакансия
Место
Наименов. отдела
Наименов. группы
Приказ
Код
Табельный номер
Номер приказа
Вид приказа
Дата составления
ФИО
Код организации
Отдел
Группа
Должность
Оклад
Дата начала работы
Дата окончания работы
Дата составл. договора
Номер договора
Условия принятия
Характеристика работы
Стаж
Код
Табельный номер
Дата начала
Дата окончания
Должность
Предприятие
Причина
Сотрудники
Код
ФИО
Табельный номер
Дата рождения
Возраст
Страна
Область
Район
Национальность
Гражданство
Серия паспорта
Номер паспорта
Кем выдан
Сем. положение
Образование
Телефон
Адрес
Должность
Вид работы
Категория
Оклад
Стаж
Диплом
Код
Табельный номер
Место обучения
Год окончания
Серийный номер
Квалификация
Специальность
71
Инфологическая модель базы данных без труда отображается в
реляционную даталогическую модель, используя описанные ранее правила по
переводу. В результате получаются таблицы реляционной базы данных, в
которых каждая сущность напрямую отражается в отдельную таблицу, атрибуты
каждой сущности становятся полями этой таблицы, а первичные ключи
сущности становятся первичными ключами таблицы.
На данном этапе необходимо также провести нормализацию полученных
таблиц с целью устранения избыточности данных.
Эта процедура в дальнейшем значительно облегчит усилия, которые будут
затрачиваться на поддержании таблиц базы данных в целостном состоянии.
Таблица 3
Даталогическая модель таблицы «Сотрудники»
Название поля
Тип данных
Ключевое/неключевое
Код сотрудника
Числовой, счетчик
Первичный ключ
ФИО
Текстовый
Неключевое
Табельный номер
Текстовый
Неключевое
Дата рождения
Дата/время
Неключевое
Возраст
Текстовый
Неключевое
Страна
Текстовый
Неключевое
Область
Текстовый
Неключевое
Район
Текстовый
Неключевое
Национальность
Текстовый
Неключевое
Гражданство
Текстовый
Неключевое
Серия паспорта
Текстовый
Неключевое
Номер паспорта
Текстовый
Неключевое
Кем выдан
Текстовый
Неключевое
72
Семейное положение
Текстовый
Неключевое
Образование
Текстовый
Неключевое
Телефон
Текстовый
Неключевое
Адрес
Текстовый
Неключевое
Должность
Текстовый
Неключевое
Вид работы
Текстовый
Неключевое
Категория
Текстовый
Неключевое
Оклад
Числовой
Неключевое
Стаж
Числовой
Неключевое
Таблица 4
Даталогическая модель таблицы «Диплом»
Название поля
Тип данных
Ключевое/неключевое
Код
Числовой, счетчик
Первичный ключ
Табельный номер
Числовой
Неключевое
Место обучения
Текстовый
Неключевое
Год окончания
Текстовый
Неключевое
Серийный номер
Текстовый
Неключевое
Квалификация
Текстовый
Неключевое
Специальность
Текстовый
Неключевое
Таблица 5
Даталогическая модель таблицы «Стаж»
Название поля
Тип данных
Ключевое/неключевое
Код
Числовой, счетчик
Первичный ключ
Табельный номер
Текстовый
Неключевое
Дата начала
Дата/время
Внешний ключ
Дата окончания
Дата/время
Неключевое
Должность
Текстовый
Неключевое
73
Предприятие
Текстовый
Неключевое
Причина
Текстовый
Неключевое
Таблица 6
Даталогическая модель таблицы «Должность»
Название поля
Тип данных
Ключевое/неключевое
Код
Числовой, счетчик
Первичный ключ
Организация
Числовой
Внешний ключ
Группа
Числовой
Внешний ключ
Должность
Текстовый
Неключевое
Оклад
Числовой
Неключевое
Вакансия
Числовой
Неключевое
Место
Числовой
Неключевое
Наименование отдела
Текстовый
Неключевое
Наименование группы
Текстовый
Неключевое
Таблица 7
Даталогическая модель таблицы «Приказ»
Название поля
Тип данных
Ключевое/неключевое
Код
Числовой, счетчик
Первичный ключ
Табельный номер
Текстовый
Неключевое
Номер
Текстовый
Неключевое
Вид приказа
Текстовый
Неключевое
Дата составления
Дата/время
Неключевое
ФИО
Текстовый
Неключевое
Код организации
Числовой
Внешний ключ
Отдел
Текстовый
Неключевое
Группа
Текстовый
Неключевое
Должность
Текстовый
Неключевое
Оклад
Числовой
Неключевое
Дата начала работы
Дата/время
Неключевое
74
Дата окончания работы
Дата/время
Неключевое
Дата составления
договора
Дата/время
Неключевое
Номер договора
Числовой
Неключевое
Условия принятия
Текстовый
Неключевое
Характеристика работы
Текстовый
Неключевое
Инфологическая и даталогическая модели, которые отображают модель
одной предметной области, зависимы между собой. Инфологическая модель
может легко трансформироваться в даталогическую модель.
2.3.3. Структурная схема пакета (дерево вызова программных
модулей)
Разрабатываемый программный продукт будет автоматизировать функции
обработки данных и подготовки документов в рамках работы отдела кадров.
Выделяется два подмножества функций программы:
- служебные функции (проверка пароля, управление окнами и др.)
- основные функции обработки данных (ввода первичных данных,
обработки, ведения справочников, подготовки и распечатки документов и др.).
При запуске программы должна открываться главная форма с помощью
которой возможна реализация всех функций программного продукта. Для того,
чтобы пространство главной формы не было не задействованным в процессе
работы информационной системы, на ней нужно выполнять функции, которые
связаны с учетом кадров.
В программе должна быть предусмотрена возможность перехода на все
остальные формы информационной системы, обеспечивая тем самым
возможность заполнения всех таблиц программы, то есть полную
функциональность разработанного программного приложения.
Созданная программа должна быть компактной и не занимать много
пространства на рабочем месте, в связи с этим небходимо максимально
75
использовать отводимое под форму место, а также использовать множество
вкладок на одной форме для того, чтобы не вызывать множество форм.
Размещение таблиц со справочной информацией желательно разместить
на отдельной форме, так как ее вызов не будет часто выполняться, лишь при
внедрении программы.
Также требуется предусмотреть возможность оперативного перехода на
формирование отчетов с основной формы разрабатываемой программы.
Редактирование данных включает в себя изменение и добавление данных,
которые содержатся в таблицах. Для каждой из таблиц имеется возможность
редактирования содержащихся в ней данных.
Использование СУБД MS SQL для разработки базы данных даст
возможность автоматически настроить вывод предупредительных сообщений
при удалении связанных записей либо нарушении целостности базы данных.
Благодаря этому можно будет создать дополнительные условия для контроля
правильности заносимых данных [21].
На рисунке 23 приведена структурная схема пакета.
Рис.23. Структурная схема пакета