1.5Разработка средств моделирования МИНЗАТР
Разработка логической модели МИНЗАТР
Разработка диаграммы прецедентов использования
Прецедент – это инструкция, позволяющая описать систему с точки зрения потенциальных пользователей. Прецеденты служат для документирования функциональных требований к программным системам, описывают некоторые целостные фрагменты поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта[9].
Роль прецедентов в разработке системы возрастает с использованием UML для их визуализации. В этом случае появляется возможность получения дополнительной информации от пользователей, которые, как правило, не могут четко изложить все свои знания о предметной области [10].
Рассмотрим реальные действия сотрудника отдела планирования, получившего заявку на материально-техническое обеспечение.
Получив заявку на материально-техническое обеспечение сотрудник берет данные о состоянии рынка и список возможных поставщиков и производит расчет возможных затрат по каждому из поставщиков. После проведения расчета сотрудник производит анализ полученных данных и выбирает того поставщика - заключение контракта с которым повлечет за собой наименьшие планируемые затраты. После принятия решения сотрудник по произведенным расчетам формирует отчет о проделанной работе. Также сотрудник может просмотреть отчеты о предыдущих расчетах.
Указанные действия сотрудников отдела могут быть документированы с помощью UML-технологии [14] в виде диаграммы прецедентов, показанной на рисунке 1.6, где в качестве сотрудника отдела планирования выступает актер – «Сотрудник отдела планирования».
Рисунок 1.6 – Диаграмма прецедентов МИНЗАТР
Сотрудник отдела планирования запускает программу и вводит данные о поставщиках и вероятных ценах на поставляемый ресурс, затраты на закупку которого нужно. После запускается расчет с использованием критерия ожидаемого значения, рассчитывается средняя ожидаемая стоимость по каждому из поставщиков и из полученных результатов выбирается поставщик заключение контракта поставки, с которым повлечет за собой наименьшие затраты. Создаётся отчет о произведенном расчете, расчет добавляется в БД, а также выводится на экран.
Программа с помощью, разработанной в пункте 1.2 математической модели, производит расчет с использованием критерия ожидаемого значения. После этого программа выводит на экран пользователю отчет о произведенном расчете. Описание прецедента «Формировать расчет» в виде таблицы представлено в таблице 1.12.
Таблица 1.12 – Описание прецедента «Формировать расчет»
Основной исполнитель – система
Заинтересованные лица – Сотрудник отдела планирования
|
Предусловия:
– Наличия правильной программы
|
Входные данные:
– Платежная матрица
|
Основной успешный сценарий (основной процесс):
– Сотрудник отдела планирования вводит данные о поставщиках;
– Сотрудник отдела планирования вводит данные о вероятных ценах на поставляемый ресурс;
– Сотрудник отдела планирования запускает процесс расчета;
– Программа возвращает пользователю отчет о произведенном расчете;
– В случае, если операция не выполнена программа возвращает причины отказа и предлагает повторить ввод исходных данных;
|
Частота выполнения:
– для каждой заявки на материально-техническое обеспечение
|
Постусловия (результаты):
– В базу данных добавлены данные о произведенном расчете
|
Выходные данные:
– Отчет о расчете
|
Регистрация событий и обработка ошибок:
– При вводе неверных данных выдается сообщение об ошибке
|
Выполним описание прецедента «Просмотреть предыдущие расчеты». Сотрудник отдела планирования запускает программу. Выбирает пункт «предыдущие расчеты», программа считывает из базы данных информацию о своей работе и выдает ее пользователю.
Табличное описание прецедента «Просмотреть предыдущие расчеты» представлено в таблице 1.13.
Таблица 1.13 – Описание прецедента «Просмотреть предыдущие расчеты»
Основной исполнитель – система
Заинтересованные лица – Сотрудник отдела планирования
|
Предусловия:
– Наличия правильной программы
|
Входные данные:
Нет
|
Основной успешный сценарий (основной процесс):
– Сотрудник отдела планирования выбирает просмотреть предыдущие расчеты;
– Программа выводит отчет о предыдущих расчетах на экран;
|
Частота выполнения:
– по запросу пользователя
|
Постусловия (результаты):
Нет
|
Выходные данные:
Нет
|
В рассмотренной на рисунке 1.6 диаграмме прецедентов были показаны и проанализированы все основные прецеденты работы проектируемого ПМК. Показанные на диаграмме прецеденты соответствуют требованиям, предъявляемым к проектируемому ПМК автоматизации обработки данных с использованием моделей теории игр для принятия решений на машиностроительном предприятии.
Разработка диаграммы классов предметной области «Обработка данных и решение задач с использованием моделей теории игр»
В соответствии с диаграммой прецедентов использования можно построить диаграмму классов, которая отображает связи между объектами системы. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования [11].
Опишем диаграмму классов предметной области «Обработка данных и решение задач с использованием моделей теории игр». Получив заявку на материально-техническое обеспечение сотрудник берет данные о состоянии рынка и список возможных поставщиков и производит расчет возможных затрат по каждому из поставщиков. После проведения расчета сотрудник производит анализ полученных данных и выбирает того поставщика - заключение контракта с которым повлечет за собой наименьшие планируемые затраты. После принятия решения сотрудник по произведенным расчетам формирует отчет о проделанной работе. Также сотрудник может просмотреть отчеты о предыдущих расчетах.
Диаграмма классов предметной области «Обработка данных и решение задач с использованием моделей теории игр» представлена на рисунке 1.7.
Рисунок 1.7 – Диаграмма классов предметной области «Обработка данных и решение задач с использованием моделей теории игр»
Из рисунка 1.7 видно, что выделено 3 главных класса. Класс Выбор получает запрос и список поставщиков с вероятными ценами. Использует класс Метод.
Описание классов диаграммы классов предметной области «Обработка данных и решение задач с использованием моделей теории игр» представлено в таблице 1.14.
Таблица 1.14 – Описание классов
Название класса
|
Описание
|
Выбор
|
Содержит классы, описывающие список поставщиков (Поставщик) и список цен (Прогнозируемые цены), на основании данных, полученных от них, производит принятие решения
|
Метод
|
Класс Метод является абстрактным классом и имеет наследников
|
Документ
|
Класс Документ является абстрактным классом и имеет наследников. Содержит классы для формирования документированных отчетов.
|
Поставщик
|
Содержит классы, описывающие заданные параметры выбранных поставщиков и список запросов, на основании данных, полученных от них, выполняется принятие решения
|
Отчет
|
Класс Отчет наследник класса Документ. Хранит форму решения
|
Решение
|
Класс Решение наследник класса Документ. Хранит данные о проведенной операции
|
Прогнозируемые цены
|
Класс Прогнозируемые цены хранит информацию о прогнозируемой цене на ресурс
|
Критерий ожидаемого значения
|
Класс Критерий ожидаемого значения наследник класса Метод. Реализует метод ожидаемого значения
|
С помощью диаграммы классов мы наглядно и доступно представили программно-методический комплекс автоматизации обработки данных с использованием моделей теории игр для принятия решений на машиностроительном предприятии.
Разработка диаграммы последовательностей МИНЗАТР
Одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов, из которых образованы эти системы. Так как различные составные элементы систем не существуют изолированно, а оказывают определенное влияние друг на друга, что и отличает систему как целостное образование от простой совокупности элементов.
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду аспект взаимодействия, который можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности [12].
Получив заявку на материально-техническое обеспечение сотрудник должен на основе данных о состоянии рынка и списка возможных поставщиков и произвести расчет возможных затрат по каждому из поставщиков. После проведения расчета сотрудник должен произвести анализ полученных данных и выбрать того поставщика - заключение контракта с которым повлечет за собой наименьшие планируемые затраты. После принятия решения сотрудник по произведенным расчетам формирует отчет о проделанной работе.
Указанные действия сотрудников могут быть документированы с помощью диаграммы последовательностей. Диаграмма последовательностей для МИНЗАТР представлена на рисунке 1.8.
Рисунок 1.8 – Диаграмма последовательности для прецедента «Формировать расчет»
Опишем представленное на рисунке 1.8 взаимодействие между объектами МИНЗАТР во время выполнения прецедента «Формировать расчет».
Сотрудник отдела планирования запускает программу, вводит данные и жмет кнопку расчет, чем формирует задание для объекта класса Выбор. Объект класса выбор запрашивает данные у объекта класса Поставщик. Класс Поставщик возвращает данные объекту класса Выбор. Затем объект класса Выбор с помощью, разработанной в пункте 1.2 математической модели, производит расчет с использованием критерия ожидаемого значения и возвращает результаты выполнения.
Разработка структуры информационного обеспечения МИНЗАТР
Для удобства хранения и дальнейшего использования результатов работы в приложении разработана база данных, в которую автоматически, по мере выполнения работы, будет заноситься информация о произведенных расчетах. В дальнейшем использование базы данных для хранения информации во многом облегчит поиск необходимых сведений, а, следовательно, уменьшит временные затраты пользователя.
Разработка модели «сущность-связь» (ER-диаграммы)
В настоящее время большинство проектов Программно-методических комплексов разрабатывается в соответствии с какой-либо методологией разработки ПО. Как следствие, разработчикам требуется инструмент для моделирования данных на этапах анализа и проектирования. Таким инструментом являются ER-диаграммы (Entity-Relationship, «Сущность-Связь») [13]. Фактически их использование является обязательным при разработке систем принятия решений и большинства бизнес ориентированных систем.
ER-диаграммы позволяют строить модели логической структуры данных предметной области, а также производить моделирование физической структуры систем хранения данных. Составим список сущностей для проектируемой ER-диаграммы. Исходя из диаграммы классов предметной области, можно выделить три сущности: «Расчет», «Поставщик» и «Прогнозируемая цена». Сущность «Расчет» характеризуется свойствами: комментарий, дата, лучший поставщик. Сущность «Поставщик» характеризуется свойством: имя. Сущность «Прогнозируемая цена» характеризуется свойствами: значение и вероятность. Исходя из всего перечисленного построим ER-диаграмму. ER-диаграмма проектируемой базы данных представлена на рисунке 1.9.
Рисунок 1.9 – ER-диаграмма базы данных для хранения информации по производимым расчетам
Представленная на рисунке 1.9 ER-диаграмма моделирует структуру проектируемой в дипломном проекте, базы данных. Проектируемая база данных предназначена для удобства хранения и дальнейшего использования результатов работы приложения.
Разработка физической модели базы данных ПМК автоматизации обработки данных с использованием моделей теории игр для принятия решений на машиностроительном предприятии
Организация информационной базы
Самым первым заданием на этапе физического проектирования баз данных является преобразование отношений, созданных на основе логической модели данных, в форму, которая может быть реализована в среде написания БД. Также на этапе написания и заполнения таблиц окончательно были определены поля, по которым необходимо проводить поиск в БД. Это необходимо для правильного индексирования таблицы, что позволит предотвратить увеличение затрат времени на работу с таблицей.
При разработке физической структуры БД были получены таблицы для хранения данных (таблица 1.15, таблица 1.16 , таблица 1.17).
Таблица 1.15– Характеристика полей таблицы базы данных «Расчет»
Поле
|
Тип
|
Ноль
|
По
умолчанию
|
Дополнительно
|
Назначение
|
*Номер
|
Int
|
да
|
NULL
|
auto_increment
|
Номер документа
|
комментарий
|
varchar(64)
|
нет
|
|
-
|
Комментарий к расчету
|
Дата
|
date
|
нет
|
|
-
|
Дата создания
|
Лучший поставщик
|
Int
|
да
|
|
-
|
Номер поставщика
|
Таблица 1.16 – Характеристика полей таблицы базы данных «Поставщик»
Поле
|
Тип
|
Ноль
|
По
умолчанию
|
Дополнительно
|
Назначение
|
*Номер
|
Int
|
да
|
NULL
|
auto_increment
|
Номер поставщика
|
Номер расчета
|
Int
|
да
|
-
|
-
|
Номер расчета
|
имя
|
varchar(64)
|
нет
|
-
|
-
|
Имя поставщика
|
Таблица 1.17 – Характеристика полей таблицы базы данных «Цена»
Поле
|
Тип
|
Ноль
|
По
умолчанию
|
Дополнительно
|
Назначение
|
*Номер
|
Int
|
да
|
NULL
|
auto_increment
|
Номер цены
|
значение
|
float
|
нет
|
-
|
-
|
Значение цены
|
вероятность
|
float
|
нет
|
-
|
-
|
Вероятность цены
|
Руководствуясь, составленной в пункте 1.5.1.5 ER-диаграммой, составим принципиальную схему связей между таблицами базы данных. Принципиальная схема связей представлена на рисунке 1.10.
Рисунок 1.10 – Принципиальная схема связей между таблицами
Исходя из представленной схемы видно, что на каждый расчет может приходиться множество поставщиков, и поставщик может иметь множество вероятных цен.
Виды обеспечения функционирования МИНЗАТР
Обоснование выбора средств разработки МИНЗАТР
В настоящее время существует множество средств разработки автоматизированных систем. Одними из самых популярных RAD – средств разработки являются Java, Lazarus, Visual C++. Проведем сравнительный анализ вышеуказанных средств и выберем наиболее подходящее для разработки автоматизированного рабочего места эксперта по измерениям показаний работы разрывной машины.
Анализ проводился по следующей методике. Во внимание принимались различные критерии для оценки качества средства разработки, такие как: производительность компилятора, графический интерфейс пользователя, язык программирования, лежащий в основе среды, возможность разработки приложений баз данных, требования среды разработчика к аппаратным средствам.
Каждому критерию назначался весовой коэффициент таким образом, чтобы сумма весовых коэффициентов всех критериев равнялась единице.
Экспертные оценки (по десятибалльной шкале) выставлены на основания анализа материалов, опубликованных в периодических изданиях и специализированной литературе.
Результаты сравнительного анализа средств разработки приведены в таблице 1.18.
Таблица 1.18 – Сравнительная характеристика средств разработки автоматизированных систем
Характеристики
|
Вес
|
Lazarus
|
Java
|
Visual C++
|
Производительность компилятора
|
0.15
|
9
|
7
|
7
|
Графический интерфейс пользователя
|
0.05
|
8
|
6
|
7
|
Знание языка программирования
|
0.15
|
9
|
8
|
8
|
Поддержка ООП
|
0.1
|
8
|
10
|
10
|
Работа с базами данных
|
0.15
|
10
|
7
|
6
|
Требования к аппаратным средствам
|
0.1
|
6
|
7
|
8
|
Поддержка СОМ
|
0.05
|
8
|
10
|
10
|
Поддержка технологии OLE
|
0.1
|
10
|
10
|
10
|
Обработка исключительных ситуаций
|
0.05
|
8
|
9
|
9
|
Доступность литературы по данным средствам разработки
|
0.1
|
10
|
7
|
7
|
Общая оценка
|
1
|
86
|
81
|
82
|
Сравнительная характеристика СУБД представлена в таблице 1.19.
Таблица 1.19 – Сравнительная характеристика СУБД
Характеристики
|
Вес
|
MS Access
|
Oracle
|
MySQL
|
Целостность данных
|
0,15
|
8
|
8
|
7
|
Хранимые процедуры
|
0,15
|
9
|
9
|
4
|
Репликация
|
0,1
|
9
|
10
|
6
|
Методы интерфейса БД
|
0,1
|
9
|
7
|
9
|
Резервное копирование
|
0,15
|
9
|
8
|
9
|
Перенос данных
|
0,15
|
5
|
9
|
9
|
Обучение и поддержка
|
0,2
|
8
|
5
|
9
|
Общая оценка
|
1
|
8,05
|
7,8
|
7.65
|
Общая оценка программных средств определяется по формуле :
, (1.11)
где Oi – общая оценка программного средства;
Kj – весовой коэффициент критерия;
aij – оценка i-того программного средства по j-тому критерию.
Следовательно, общая оценка средств разработки приложений равна:
O1=(9+9+10)·0.15 + (8+8+8)·0.05 + (6+8+10+10)·0.1 =8.8;
O2=(7+8+7)·0.15 + (6+10+9)·0.05 + (7+10+10+7)·0.1 =7.95;
O3=(7+8+6)·0.15 + (7+10+9)·0.05 + (8+10+10+7)·0.1 =7.95;
где O1, O2, O3 соответственно общие оценки программных средств Lazarus, Java, Visual C++.
Определим общую оценку средств разработки базы данных:
O1=(8+9+9+5)·0.15 + (9+9)·0.1 + 8·0.2 =8.05;
O2=(8+9+8+9)·0.15 + (10+7)·0.1 + 5·0.2 =7.8;
O3=(7+4+9+9)·0.15 + (6+9)·0.1 + 9·0.2 =7.65;
Таким образом, видно, что наиболее мощным и удобным средством разработки ПМК является Lazarus, а наиболее подходящей СУБД MS Access.
Визуальный язык программирования Lazarus позволяет быстро и эффективно разрабатывать самые разные приложения, включая и приложения для работы с базами данных. Она имеет развитые возможности по созданию пользовательского интерфейса, широкий набор функций, методов и свойств, для решения прикладных расчетно-вычислительных задач. В систему также включены удобные средства отладки [14].
Lazarus позволяет создавать приложения с помощью широкого набора инструментальных программных средств, визуально подготавливать запросы к базам данных, а также непосредственно писать запросы на языке SQL. С помощью Lazarus можно разрабатывать приложения для работы как с локальными, так и с удаленными базами данных. Он поддерживает большинство современных технологий информационных систем. Lazarus уменьшает время цикла разработки и увеличивает продуктивность программиста за счет следующих новых возможностей.
Улучшение интегрированной среды разработки (IDE), включающая:
– дизайнер DataModule с древовидным представлением и представлением в виде диаграммы данных для исчерпывающего обзора данных в приложениях;
– браузер проекта (Project-Wide) для просмотра кода в пределах проекта и для навигации в библиотеке компонент VCL (Visual Component Library);
– контроль соответствия хода разработки временному графику с использованием и списков "что сделать" (To Do lists);
– средства визуального программирования в технологии "drag-and-drop";
обеспечивает полную поддержку и создание объектов ActiveX, OLE и COM (компоненты для Word, Excel, PowerPoint, and Outlook);
новые мастера для создания консольных приложений и апплетов;
– панели управления Windows.
Расширенный инструментарий отладки, включает:
удалённую отладку для распределённой разработки (COM и CORBA);
– отладку нескольких процессов одновременно;
– быструю навигацию по точкам останова (всплывающие подсказки, задание действий и группировка).
Также для проектирования была выбрана СУБД MSAccess. Среди преимуществ MSAccess следует отметить следующие:
– высокую степень универсальности и продуманности интерфейса, который рассчитан на работу с пользователями самой различной квалификации;
– реализована система управления объектами базы данных, позволяющая гибко и оперативно переходить из режима конструирования в режим их непосредственной эксплуатации;
– реализована система автоматической генерации SQL запросов, а также их тестирования на работоспособность;
– богатый набор визуальных средств разработки;
– вся информация, относящаяся к одной базе данных, хранится в едином файле, что обеспечивает простоту при переносе данных с одного рабочего места на другое;
– глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE.
Программное и техническое обеспечение МИНЗАТР
Техническое обеспечение МИНЗАТР – это средства вычислительной техники, входящие в системный блок и являющиеся составными частями персонального компьютера, на базе которого реализуется ПМК, а также внешние устройства. Эти средства и устройства обеспечивают автоматизацию выполнения задач исполнителя по хранению и обработке данных в различных форматах представления, при этом документация представляется на различных носителях и в виде твердых копий.
В состав средств вычислительной техники и внешних устройств должны входить, как показано в таблице 1.20, кроме процессора, оперативной и долговременной памяти, монитора, соответствующих техническому заданию на проектирование МИНЗАТР.
Таблица 1.20 - Состав технического обеспечения МИНЗАТР
№
п/п
|
Компонент
|
Техническая характеристика, описание
|
1
|
Процессор
|
AMD Athlon X2 6000+ AM2 3.1GHz, 89W, Tray
|
2
|
ОЗУ
|
TRANSCEND JETRAM DDR2-800 2048MB PC2-6400 (JM800QLU-2G)
|
3
|
ПЗУ
|
Жесткий диск Seagate Momentus Thin 160GB 5400rpm 16MB ST160LT015 2.5 SATA II
|
4
|
Монитор
|
Монитор Acer X163W (ET.ZX3WE.A01)
|
5
|
Клавиатура
|
Устройство для ввода информации. Тип Win, 104-клавишиная, нанесены символы кириллицы
|
6
|
Мышь
|
Устройство ввода с кнопками, передающее информацию о своем перемещении и нажатии кнопок
|
7
|
Сетевая карта
|
Обмен информацией с другими компьютерами через витую пару или оптоволокно
|
Программное обеспечение МИНЗАТР, кроме разработанного и реализованного в специальной части данного проекта приложения баз данных и самой базы данных, должно включать: операционную систему с графическим интерфейсом типа Windows 7, офисный пакет Microsoft Office, обеспечивающий работу с СУБД MSAccess для организации баз данных.
|
