42
2.2 Описание внедряемой ИС
Ключевые требования заключаются в формировании требований к
содержанию и форме входных и выходных документов.
Формы входных документов для задачи следующие:
1) «Клиенты» - информация о фирмах клиентах, данные для нее берутся
из регистрационной анкеты, заполняемой клиентом при заключении договора.
2) «Пользователи» - информация о сотрудниках отдела. Информация
заполняется из приказа о приеме на работу.
3) «Рабочее время» - информация о количестве рабочего времени
сотрудника. Заполняется каждым сотрудником, по умолчанию составляет
пятидневный, восьмичасовой график.
4) «Договора» - информация о договоре, заключенном с клиентом.
Информация берется из договора на обслуживание, при этом поле поле «срок
договора» может принимать значения: 3месяца, 6месяцев, 1год.
5) «Заявки» - информация о заявках на разовые работы. Информация
берется из бланка заявки.
6) «Присвоение квалификации» - информация о квалификации
сотрудника. По умолчанию квалификация «1». Квалификация присваивается
сотруднику после прохождения соответствующего обучения
Формы входных документов для задачи следующие:
1) «Опись» - опись работ на месяц (для каждого сотрудника своя), в
описи только работы по договору обслуживания. Таблица получена путем
распределения клиентов между сотрудниками, исходя из минимального
расстояние от сотрудника до фирмы-клиента.
2) «График работы» - график работ на месяц (для каждого сотрудника
свой) в графике указаны и работы по договору обслуживания и по разовым
заявкам. С указанием даты и времени на которые они запланированы.
43
В результате анализа предметной области были выделены следующие
сущности:
Задачи –перечень заявок на обслуживание ККТ;
Сообщения по задачам – перечень сообщений для выполняющих
задачи сотрудников;
Приоритет – перечень степеней приоритета выполнения задачи;
Статус – перечень статусов задач;
Статус задачи – сведения о б изменениях статусов каждой задачи;
Пользователь – сведения о сотрудниках и пользователях
системы;
Тип пользователя – перечень типов пользователей.
Логическая схема базы данных приведена на рисунке 12.
Рисунок 12– Логическая схема данных
В информационной модели приведены следующие связи:
Между Приоритет и Задача «Один ко многим», так как один приоритет
может принадлежать нескольким задачам;
44
Между Статус и Статус задачи «Один ко многим», так как один статус
может принадлежать нескольким задачам;
Между Пользователь и Статус задачи «Один ко многим», так как один
пользователь может менять статус задачи несколько раз;
Между Задача и Сообщения по задаче «Один ко многим», так как по
одной задаче может быть несколько сообщений;
Между Пользователь и Задача «Один ко многим», так как один
пользователь может иметь несколько задач;
Между Тип пользователя и Пользователь «Один ко многим», так как
один тип пользователей может принадлежать многим пользователям;
Между Пользователь и Сообщения по задаче «Один ко многим», так как
сообщение может принадлежать многим пользователям;
Между Статус и Статус задачи «Один ко многим», так как один статус
может принадлежать нескольким задачам.
Рассмотрим наиболее важные вопросы проектирования ИС и выбора
СУБД, от правильного решения которых зависит успех всего проекта в целом.
Разработка БД. Ключевым этапом создания ИС является этап разработка
БД, целями которой становятся:
указание данных и связей между ними, нужных для всех основных
областей применения рассматриваемой системы и любых групп ее
пользователей;
проектирование модели данных, способной поддерживать
реализацию любых требуемых транзакций, связанных с обработкой
информации;
создание предварительного варианта проекта, структура которого
удовлетворит все основные требования, предъявляемые к скорости работы
системы.
45
Есть два основных подхода к разработке систем БД: снизу-вверх или
сверху вниз. Первый подходит для создания небольших БД с ограниченным
числом атрибутов. Использование такого подхода усложняется при создании
БД с огромным числом атрибутов, описать среди которых все доступные
функциональные зависимости проблематично. При создании сложных систем
БД лучше всего применять нисходящий подход, хорошо зарекомендовавший
себя в рамках модели «сущность-связь». Тут работа связана с определением
сущностей и процессом их взаимодействия, которые очень важны для
подобной разработки.
Весь путь создания БД включает 3 фазы: концепция, логическая модель
и проектирование прототипа. Любая фаза состоит из необходимой модели
данных, которая становится источником данных для другой фазы. Основное
значение тут возложено на концепцию, реализуемую в ракмкх параметров,
указанных в спецификации пользовательских требований. Подготовка
концепции БД никак не пересекается в такие подробности ее реализации, как
тип применяемой целевой СУБД, тип используемой вычислительной
платформы и т.п., но качество концепции тут уже имеет решающее значение,
позволяющее отразить трудозатраты на создание системы, ее скорость работы
и текущий успех. Опыт создания и использования ИС говорит о том, что
ошибки, возможные в процессе этого этапа, очень трудно выявить и
устранить, поскольку они встречаются обычно уже на последующих этапах
создания системы – при реализации и поддержке.
На этапе проектирования логической модели концепция данных
переходит в логическую модель, создаваемую в рамках указанной модели
хранения информации основной СУБД. По итогу, этот этап отражает, какая
СУБД используется в качестве целевой - иерархическая, сетевая, реляционная
или объектно-ориентированная. Тут проходят все остальные аспекты
начальной СУБД – к примеру, некие особенности физической реализации
46
хранения данных. Логическая модель, отражающая особенности отображения
о создаваемой системе больше одного типа пользователей, считается
глобальной логической моделью данных. Есть пара базовых подходов для
создания совокупной логической модели: метод внедрения представлений и
централизованный способ. Если создается крупная ИС, лучше и эффективнее
использовать второй подход, когда общая логическая модель реализуется
методом слияния отдельных моделей, показывающих представления
отдельных групп пользователей.
В процессе создания прототипа принимаются решения о вариантах
реализации текущей БД. Поэтому физическое проектирование очень сильно
завязано на конкретной СУБД. Между разработкой логической модели и
подготовкой прототипа есть постоянная обратная связь, т.к. все решения,
принимаемые на этапе создания прототипа для повышения
производительности системы, очень влияют и на структуру логической
модели. Цель создания прототипа БД заключается в описании варианта
итоговой реализации проекта всей БД.
На основании ранее составленной логической схемы данных с учетом
особенностей СУБД подготовлена физическая схема данных (Рисунок13).
Рисунок 13 – Логическая схема данных
47
Схема данных в среде СУБД MS Access показана на рисунке 14.
Рисунок 14– Схема базы данных
Описание назначения таблиц базы данных приведен в таблице 6.
Таблица 6
Описание назначения таблиц базы данных
Название таблицы
Описание
Task
Задача
TaskStatus
История статусов задачи
TaskMessage
История сообщений задачи
Priority
Приоритет
Status
Статус
User
Пользователь
UserType
Тип пользователя
Разработка проект начинается с проектирования базы данных. База
данных имеет формат MicrosoftAccess (MDB). После создания базы данных,
создается проект «WindowsForms» в среде «VisualStudio 2010» на языке «C#».
К проекту добавляется подключение и модуль данных «baseDataSet» (модуль
проекта, файл BaseDataSet.xsd). Данный компонент реализует механизмы для
48
работы за базой данных из приложения C#. В данном модуле для каждой
таблицы из БД создается таблица (наследник класса «System.Data.DataTable»)
и отдельный компонент-адаптер (TableAdapter). Компонент-адаптер
реализует возможность выполнения четырех видов sql-запросов (select, insert,
update, delete) к конкретной таблице базы данных, а результаты этих операций
отражаются в экземпляре класса «System.Data.DataTable». После реализации
модуля «baseDataSet» создаем формы приложения и размещаем на формах
поля ввода данных, привязанные к полям таблиц БД. Для привязки полей из
таблиц БД (компонента «DataTable») к полям ввода данных нашего
приложения используются объекты, наследуемые от класса «BindingSource».
Модуль данных проекта представлен на рисунке 15.
Рисунок 15 – Модуль данных проекта
Объединяет в себе классы для обращения к таблицам базе данных. Для
каждой интересующей нас таблицы в этом классе создаются компоненты
«TableAdapter» и «DataTable». Компонент «DataTable» определяет список
полей набора данных, а компонент «TableAdapter» определяет четыре базовых
sql-запроса (select, insert, update, delete) для работы с конкретной таблицей БД.
49
Диаграмма классов для модуля данных показана на рисунке 16.
Рисунок 16 – Диаграмма классов для модуля данных
BaseDataSet
Объединяет в себе наборы данных. Для каждой интересующей нас
таблицы базы данных в этом классе создается компонент «DataTable».
Компонент «DataTable» определяет структуру набора данных.
TableAdapterManager
Объединяет в себе компоненты-адаптеры, созданные разработчиком
внутри модуля данных.
PriorityTableAdapter
Класс-адаптер для таблицы базы данных «Priority» (приоритеты
задания). Реализует в себе четыре sql-запроса (select, insert, update, delete) к
50
целевой таблице. Позволяет выгружать данные из таблицы базы данных в
компоненты, наследуемые от класса «System.Data.DataTable», через которые
программист может редактировать таблицу базы данных. Метод «Fill»
адаптера заполняет «DataTable». Метод «Update» адаптера заносит данные из
«DataTable» в базу данных.
StatusTableAdapter
Класс-адаптер для таблицы базы данных «Status» (статус задания).
Реализует в себе четыре sql-запроса (select, insert, update, delete) к целевой
таблице. Позволяет выгружать данные из таблицы базы данных в компоненты,
наследуемые от класса «System.Data.DataTable», через которые программист
может редактировать таблицу базы данных. Метод «Fill» адаптера заполняет
«DataTable». Метод «Update» адаптера заносит данные из «DataTable» в базу
данных.
UserTableAdapter
Класс-адаптер для таблицы базы данных «User» (пользователи
системы). Реализует в себе четыре sql-запроса (select, insert, update, delete) к
целевой таблице. Позволяет выгружать данные из таблицы базы данных в
компоненты, наследуемые от класса «System.Data.DataTable», через которые
программист может редактировать таблицу базы данных. Метод «Fill»
адаптера заполняет «DataTable». Метод «Update» адаптера заносит данные из
«DataTable» в базу данных.
UserTypeTableAdapter
Класс-адаптер для таблицы базы данных «UserType» (типы
пользователей системы). Реализует в себе четыре sql-запроса (select, insert,
update, delete) к целевой таблице. Позволяет выгружать данные из таблицы
базы данных в компоненты, наследуемые от класса «System.Data.DataTable»,
через которые программист может редактировать таблицу базы данных.
51
Метод «Fill» адаптера заполняет «DataTable». Метод «Update» адаптера
заносит данные из «DataTable» в базу данных.
TaskTableAdapter
Класс-адаптер для таблицы базы данных «Task» (задачи/задания для
сотрудников). Реализует в себе четыре sql-запроса (select, insert, update, delete)
к целевой таблице. Позволяет выгружать данные из таблицы базы данных в
компоненты, наследуемые от класса «System.Data.DataTable», через которые
программист может редактировать таблицу базы данных. Метод «Fill»
адаптера заполняет «DataTable». Метод «Update» адаптера заносит данные из
«DataTable» в базу данных.
TaskMessageTableAdapter
Класс-адаптер для таблицы базы данных «TaskMessage» (сообщения
сотрудников по конкретной задаче). Реализует в себе четыре sql-запроса
(select, insert, update, delete) к целевой таблице. Позволяет выгружать данные
из таблицы базы данных в компоненты, наследуемые от класса
«System.Data.DataTable», через которые программист может редактировать
таблицу базы данных. Метод «Fill» адаптера заполняет «DataTable». Метод
«Update» адаптера заносит данные из «DataTable» в базу данных.
TaskStatusTableAdapter
Класс-адаптер для таблицы базы данных «TaskStatus» (история статусов
задачи). Реализует в себе четыре sql-запроса (select, insert, update, delete) к
целевой таблице. Позволяет выгружать данные из таблицы базы данных в
компоненты, наследуемые от класса «System.Data.DataTable», через которые
программист может редактировать таблицу базы данных. Метод «Fill»
адаптера заполняет «DataTable». Метод «Update» адаптера заносит данные из
«DataTable» в базу данных.
Классы интерфейса (Рисунок17).