78
прецеденты.
Субъекты - может только вводить информацию в систему, только
получать информацию из системы или делать и то, и другое. В роли субъекта
может выступать также и другая система, если она будет взаимодействовать
с разрабатываемой системой, и не будет являться ее неотъемлемой частью.
Прецеденты - предназначены для моделирования диалога между
системой и ее субъектами. Они представляют собой возможности, которые
система может обеспечить конкретному субъекту.
Работа системы осуществляется следующим образом:
1. Заказчик (представитель цеха) заходит в систему и формирует
заявку, выбирая из списка сломанное оборудование, вводя предполагаемую
причину поломки, при этом дата и время заявки устанавливается
автоматически.
2. Заявка попадает к диспетчеру. Диспетчер отправляет заявку
наладчику, может добавить свое примечание.
3. Наладчик рассматривает заявку и может либо принять ее на
исполнение, либо вернуть диспетчеру. В последнем случае диспетчер опять
назначает заявку какому-то другому сотруднику.
4. Если заявка принимается на исполнение, наладчик может выписать
накладную на получение какого-либо оборудования со склада, выбирая его
из списка.
5. Если необходимого оборудования в системе нет, исполнитель может
сформировать аварийную заявку в отдел снабжения для получения этого
оборудования на склад и распечатать ее. Если при следующей
синхронизации оказывается, что это оборудование уже поступило на склад, в
списке заявок в работе должна быть сигнализация о том, что оборудование
поступило на склад и можно приступать к работе по ремонту.
6. По окончании ремонта наладчик закрывает наряд, выбирая из списка
выполненные работы, а также используя список оборудования, которое было
ранее выдано для проведения данного ремонта. Оборудование также можно
79
добавлять в наряд при его закрытии. Время закрытия добавляется
автоматически.
7. Закрытая заявка показывается у заказчика этой заявки, заказчик
должен закрыть ее окончательно или отправить на доработку, добавив
примечание.
В диаграмме прецедентов 4 актера. На рисунке П.Б.1 представлена
диаграмма прецедентов, которая представляет функции администратора по
работе с системой.
Прецедент «Аутентификация пользователя» активизируется всеми
субъектами ИС. Перед тем как пользователь начнет работу с БД, системой
запрашивается его логин и пароль. Когда пользователь не прошел
регистрацию либо допущена ошибка в пароле и/или логине, то ему не
предоставляется доступ к работе в ИС. Если проверка пользовательского
логина и пароля прошла успешно откроется главное окно программы. На
рисунках П.Б.2 и П.Б.3 показаны диаграмма очередности и диаграмма
действий такого прецедента.
Прецедент «Учет заявки» активизируется субъектом ИС заказчик.
Данным прецедентом описывается процедура ввода новых данных в БД. Это
выполняет пользователь в качестве заказчика. В формы ввода вводятся на
основании документов данные, а также вся справочная информация, которая
необходима при работе с системой. На рисунках П.Б.4 и П.Б.5 показаны
диаграмма очередности и диаграмма действий подобного прецедента.
Диаграмма последовательности «Распределение заявок» показывает
порядок распределение заявок и направления наладчику для исполнения.
Диаграмма последовательности «Обработка заявки наладчиком»
показывает порядок обработки заявок при ее получении наладчиком.
Исполнитель может либо отказаться от заявки, либо принять ее для
исполнения. Диаграмма последовательности при отказе от заявки приведена
на рисунке П.Б.6.
Диаграмма последовательности при приеме заявки в работу приведена
80
на рисунке П.Б.7.
По окончании работы по заявке наладчик закрывает ее, формируя
наряд. Диаграмма последовательности данного процесса приведена на
рисунке П.Б.8.
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Входной информацией для разрабатываемой системы являются
ассортимент услуг, данные каждой услуги, данные покупателя, оценка
услуги покупателем. Данные, касающиеся услуг (ассортимент и
наименование) вноясятся в систему ее администратором.
Из ассортимента услуг в систему заносятся следующие реквизиты:
- наименование категории;
- наименование услуги;
О каждой позиции в систему вносятся следующие реквизиты:
- наименование;
- категория;
- описание
Количество поступивших данных зависит от количества
обращающихся клиентов и может колебаться от 10 до 20 за рабочий день.
2.2.3 Характеристика результатной информации
Результатными документами системы являются три формы: отчет о
проведенной операции; сообщение о выполненном платеже и сообщение о
невыполненном платеже (рисунки 13-15).
81
Рисунок 13 Сообщение о выполненном платеже
Рисунок 14 Отчет о проведенной операции
Рисунок 15 Сообщение о невыполненном платеже
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Программное обеспечение задачи предполагает в первую очередь
построение дерева функций (рисунок 16) и сценария диалога (рисунок 17)
между пользователем информационной системы и программным
приложением. В качестве способа описания диалога выбран язык типа
«меню».
82
Рисунок 16 Дерево функций системы
Чтобы взаимодействовать с пользователем программы предполагается
применение меню, полей, подсказок, которые отвечают за введение данных,
а также кнопок, при нажатии на которые будет всплывать тот или иной
запрос к БД.
2.3.2 Характеристика базы данных
Построение информационной модели необходимо для точного и
полного отображения реальной ситуации при формировании структуры БД.
Модель обязана соответствовать таким требованиям:
обеспечивать адекватное отображение предметной области и давать
возможность получить интегрированное представление о предметной
области;
содержать информацию о предметной области, достаточную для
дальнейшего проектирования.
83
Рисунок 17 Графический переход экранных форм
На первом этапе работы по проектированию БД следует создать
корректную структуру БД, которая содержит все необходимые компоненты
предметной области. Следует учитывать разнообразные факторы, которые
могут оказать влияние на успех создания информационной системы. Важно,
чтобы разрабатываемая система отвечала запросам пользователей. Поэтому
от правильного выбора структуры хранения данных юудет зависить успех,
эффективность и качество разработки.
Процесс создания инфологической модели включает в себя следующие
этапы [14, 15]:
определение сущностей;
определение зависимостей между сущностями;
задание альтернативных и первичных ключей;
84
определение атрибутов сущностей;
приведение модели к необходимой степени нормальной формы.
Логическим уровнем представления модели считается теоретический
взгляд на данные, на нем данные представлены точно так же, как и в
реальности. Логическую модель данных принято считать универсальной, и
никак не связанной с определенной реализацией СУБД. Физическая модель
данных, наоборот, находится в зависимости от определенной СУБД,
фактически считаясь отображением системного каталога. В физической
модели имеется информация обо всех объектах БД (базы данных). Так как не
существует стандартов на объекты БД (к примеру, отсутствует стандарт на
типы данных), физическая модель находится в зависимости от определенной
реализации СУБД. Таким образом, одной и той же логической модели могут
отвечать ряд различных физических моделей. Если в логической модели не
имеет значения, каким именно типом данных располагает атрибут, то в
физической модели считается важным описание всей информации об
определенных физических объектах [15].
Инновационные объектно-ориентированные CASE-средства
предоставляют возможность эффективного решения задач проектирования
приложений. Среди подобных пакетов – Rational Rose, Together Control
Center, BPWin, ERWin, Model Mart, Silverrun Business Process Modeller,
Process Analyst.
Для инфологического проектирования БД избрано CASE-средство
Computer Associates ERwin.
В предоставленной работе инфологической модели дано описание в
нотации IDEF1X. Такая методология применяет строго структурированный
набор типов конструкций моделирования. В процессе создания модели
данных применяется 2 уровня представления данных: физический и
логический.
Инфологическая модель в нотации IDEF1X показана на рисунке 18. На
диаграмме показаны сущности и их атрибуты, а также первичные ключи, по
85
которым будут созданы связи в БД.
Рисунок 18 Логическая модель базы данных
Следовательно, в модели приведены сущности и реквизиты,
показанные в приложении В.
На рисунке 19 представлена физическая модель данных. Er-диаграмма
базы данных в среде проектирования показана на рисунке 20.
Характеристика каждой таблицы и описание ее полей представлено в
приложении Г.
2.3.3 Структурная схема пакета (дерево вызова программных модулей)
Интерфейс приложения можно отнести к основному интерфейсу
Microsoft Windows (рисунок 21). Доступ ко всем интерфейсам приложения
выполняется как из основной формы приложения, так и из иных форм и
основного меню программы [3].
86
В процессе проектирования создана двухуровневая структура
пользовательского интерфейса системы. На 1-м уровне содержится “Главная
форма”. На 2-м уровне содержатся другие формы.
Рисунок 19 Физическая модель данных
87
Рисунок 20 Er-диаграмма базы данных в среде проектирования