66
2.3.3. Структурная схема пакета (дерево вызова программных
модулей)
Структура базы данных Applications представлена на рисунке 14 из
которого видно, что база данных состоит из 8 таблиц (Clients, Deffects,
Users, Components, Orders, DefStatement, DeffectsList, ComponentsList).
Рисунок 14. Структура базы данных
На рисунке 15 представлена структура таблицы Clients, которая
состоит из полей ID (уникальный идентификатор), Name (ФИО клиента),
Fone (телефон), City (город), Adress (адрес). Данная таблица содержит
список клиентов компании, которые подали заявку на обслуживание или
ремонт.
Рисунок 15. Таблица Clients
На рисунке 16 представлена структура таблицы Components, которая
состоит из полей ID (уникальный идентификатор), Description
(Наименование), SerialNum (серийный номер). В данной таблице
содержится вся номенклатура комплектации, которая заказывается под
определенный заказ клиента.
67
Рисунок 16. Таблица Components
На рисунке 17 представлена структура таблицы Deffects, которая
состоит из полей ID (уникальный идентификатор), Description (Описание
дефекта). Даная таблица содержит данные о дефектах.
Рисунок 17. Таблица Deffects
На рисунке 18 представлена структура таблицы Users, которая
состоит из полей ID (уникальный идентификатор), Name (имя
пользователя), Password (пароль), isActual (актуальность пользователя).
Данная таблица содержит пользователей, которые будут авторизовываться
для входа в информационную систему и работать в ней.
Рисунок 18. Таблица Users
На рисунке 19 представлена структура таблицы Orders, которая
состоит из полей ID (уникальный идентификатор), ClientID (ссылка на
клиента), Num (номер заявки), Date (дата заявки), UserID (ссылка на
пользователя), Description (описание причины заявки). Данная таблица
содержит заявки клиента на обслуживание или ремонт автомобиля.
Рисунок 19. Таблица Orders
68
На рисунке 20 представлена структура таблицы DefStatement,
которая состоит из полей ID (уникальный идентификатор), OrderID
(ссылка на заявку клиента), UserID (ссылка на пользователя), Num (номер
дефектовочной ведомости), Date (дата дефектовочной ведомости). Данная
таблица содержит дефектные ведомости составленные по заявке клиента
на обслуживание или ремонт автомобиля.
Рисунок 20. Таблица DefStatement
На рисунке 21 представлена структура таблицы DeffectsList, которая
состоит из полей ID (уникальный идентификатор), DefStatementID (ссылка
на дефектовочную ведомость), DeffectID (ссылка на дефект), Price
(стоимость работ). Данная таблица содержит данные о выявленных
дефектах по заявке клиента и стоимости работ.
Рисунок 21. Таблица DeffectsList
На рисунке 22 представлена структура таблицы ComponentsList,
которая состоит из полей ID (уникальный идентификатор), DefStatementID
(ссылка на дефектовочную ведомость), ComponentID (ссылка на
комплектующие), Price (цена), Count (количество). Данная таблица
содержит данные о необходимых комплектующих по заявке клиента, их
количестве и стоимости).
69
Рисунок 22. Таблица ComponentsList
2.3.4. Описание программных модулей
Описание программных модулей включает блок-схемы
программных модулей и описание блок-схем алгоритмов основных
расчетных модулей. В качестве примера рассмотрим программный модуль
rpMoneyReport «Платежная накладная».
При вызове модуля производится формирование и вывод на экран
отчета по платежным накладным клиентам, которым были предоставлены
услуги по ремонту, за определенный промежуток времени. Руководитель
или бухгалтер, ознакомившись с документом, может его распечатать или
сохранить на жесткий диск в формате Microsoft Word (Текст RTF).
Развернутая блок-схема работы данного модуля представлена на Рисунке
24.
70
Рисунок 24. Блок-схема работы с заявками клиента
Начало
Установка соединения с
сервером БД
Открытие таблиц Clients,
Deffects, Orders, Components,
DefStatement, DeffectsList,
ComponentsList
Создание представления для
списка клиентов ALLCLIENTS
Сортировка по FIO и NumZak
Цикл по клиентам
j =1;
j<COUNT(AllClients);
j++
Sum = 0
Sum = Sum + AllClients[j].sum
Внесение Sum в макет отчета
Sum = 0
Конец цикла по
клиентам
Закрытие таблиц и
представления AllClients
Конец
71
Структура представления (VIEW) ALLCLIENTS, предназначенного
для временного хранения и обработки сумм оплаты клиентами за
выполненные работы, представлена в таблице 21.
Таблица 21
Структура записи представления ALLCLIENTS («Денежные
выплаты клиентами за выполненные работы»)
Наименование показателя
Идентификатор
Тип
Код строки
id
Int
Код клиента
Clients_id
Int
ФИО клиента. Формируется из поля
Name справочника Clients
Name
Nvarchar(600)
Заказ клиента, по которому были
оплачены выполненные работы (берется
из поля «Num» таблицы Orders
NumZak
Int
Сумма оплаты по заказу (берется как
сумма полей «Price» из таблиц
DeffectsList и ComponentsList)
Sum
Money
Переменная Sum в блок-схеме данного модуля представляют собой
результатные показатели «Денежные выплаты клиентом за выполненные
работы».
2.4. Контрольный пример реализации проекта и его описание
Взаимодействие пользователя с системой осуществляется в
диалоговом режиме. Основным связующим элементом разрабатываемой
АИС является система меню, состоящего из главной формы и
вспомогательных. Разработанная система является меню -
ориентированной. Опишем интерфейс работы с программой. При запуске
программы необходимо ввести имя и пароль для авторизации в данной
программе (см. рис. 25).
Рисунок 25. Вход в систему обработки заявок
В результате удачной авторизации появляется главное меню.
72
При нажатии меню «?» – «О программе» появляется форма с
информацией о данной программе в которой указано наименование
дипломной работы и год создания.
При нажатии меню «Служебные» – «Выход» программа закрывается,
а «Служебные» - «Смена пользователя» программа закрывается и
появляется форма авторизации.
При нажатии меню «Журнал» - «Заявки от клиента» появляется
форма с заявками.
При нажатии меню «Журнал» - «Дефектная ведомость» появляется
одноименная форма.
Для того чтобы ограничить количество выводимых документов
используется кнопка при нажатии на которую появляется форма
выбора периода
При нажатии периода с 01.04.2017 получаем документы за данный
период (см. рис. 26).
Рисунок 26. Форма «Заявки от клиента»
В случае использования фильтра по описанию (см. рис. 27) остаются
только те документы, у которых в описании содержится «Ремонт».
Рисунок 27. Форма с распорядительными документами по
фильтру
73
На рисунке 28 представлена форма на которой производится ввод
нового документа.
Рисунок 28. Ввод новой заявки на ремонт кузова
Как видно на рисунке выбран клиент из справочника клиента,
менеджер, который принял заявку из справочника пользователей, введен
номер 33, выбрана дата 06.12.2017. В описании сказано что данная заявка
на ремонт кузова.
Для того чтобы просмотреть историю по документу необходимо
нажать кнопку . В результате появляется форма с историей изменения
документа (см. рис. 28).
Рисунок 28. История ведения заявок
Для того чтобы просмотреть документы определенного менеджера
компании, например Иванова нажимаем кнопку (см. рис. 29).
74
Рисунок 29. Настройка отображаемых документов
После выбора определенного менеджера на форме заявок клиента
отображаются только те документы, у которых создатель Иванов.
Рисунок 30. Вывод заявок Иванова
В результате можно сделать вывод, что программа работает и
соответствует целям и задачам дипломной работы.
Выводы по главе 2
Для проектирования системы более всего подходит стандарт
ISO/IEC 12207:2010, который задает более 40 процессов и охватывает
различные работы и задачи, которые связаны с разработкой и построением
программных средств, начиная с анализа предметной области и заканчивая
изготовлением конечного продукта. Из существующих на сегодняшний
день каскадной, спиральной и итерационной моделей жизненного цикла
проекта автоматизации в данном проекте мы выберем итерационную
75
модель, при которой происходит способ быстрой разработки приложений
– RAD (Rapid Application Development). Так как компания ИП
«БАЙБЕКОВ» не может приостанавливать работу из-за внедрения
информационной системы мы будем использовать метод «скачок».
Использование метода «скачка» предусматривает полный отказ от уже
существующей и работающей системы и моментальный переход на новую
информационную систему. Для данного дипломного проекта разработка
ИС производится внутренними силами, то есть теми специалистами-
разработчиками проекта, а также персоналом IT-cлужбы, без привлечения
сторонних специалистов. Согласно безопасности пользователи должны
иметь учетные записи, защищенные паролем, который состоит из
латинских букв и цифр и имеет длину более 7 символов. Все сервера
компании должны быть защищены от возможности несанкционированного
доступа к ним. Базу данных ИС можно зашифровать при помощи
встроенных средств Microsoft SQL Server 2008, который обеспечивает
прозрачное шифрование данных (Transparent Data Encryption или TDE), а
так же целиком всей базы данных. Разрабатываемый программный
продукт автоматизирует функции обработки заявок компанией ИП
«БАЙБЕКОВ». Выделяется два подмножества функций системы
обработки заявок это- служебные функции и основные функции обработки
данных.
Разработаем ER-модель (Entity-Relationship model, модель
«сущность-связь») базы данных. ER модель (рисунок 13) отображает
состав и взаимосвязи таблиц, отражающих содержание информационной
модели в терминах конкретной СУБД. В качестве СУБД для клиент-
серверного самописного приложения оптимальным решением будет SQL
Server, в связи с этим база данных Applications будет являться реляционной
базой данных с составе разрабатываемой информационной системы.
Описание программных модулей включает блок-схемы программных
модулей и описание блок-схем алгоритмов основных расчетных модулей.