5Разработка средств моделирования NETSENSOR
5.1Разработка логической модели NETSENSOR
Разработка диаграммы прецедентов использования
Прецедент – это инструкция, позволяющая описать систему с точки зрения потенциальных пользователей. Прецеденты служат для документирования функциональных требований к программным системам, описывают некоторые целостные фрагменты поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта [13].
Роль прецедентов в разработке системы возрастает с использованием UML для их визуализации. В этом случае появляется возможность получения дополнительной информации от пользователей, которые, как правило, не могут четко изложить все свои знания о предметной области [14].
Рассмотрим процесс измерения температуры стали в установках непрерывного литья при помощи системы диспетчеризации. Во время процесса литья заготовок температура жидкой стали воздействует на измерительный преобразователь, меняя его электрические свойства. Благодаря этому измерительный преобразователь генерирует аналоговый сигнал. Аналоговый сигнал поступает на вход аналого-цифрового преобразователя, где подвергается дискретизации и кодированию. Полученный цифровой сигнал подается на вход контроллера измерительного устройства, где хранится до следующего измерения. По запросу от сервера контроллер упаковывает цифровое значение измеренной температуры в IP пакет и отправляет серверу по сети Ethernet. Сервер распаковывает полученный пакет, формирует запрос к базе данных и добавляет полученное от контроллера значение температуры и точное время измерения в базу данных. Оператор запрашивает у системы архив измерений путем заполнения формы запроса. ПК оператора формирует запрос и отправляет его серверу диспетчеризации. Сервер обрабатывает запрос, извлекает необходимые данные из базы данных и отправляет их на ПК оператора. ПК оператора отображает полученные данные в специальной форме.
Указанные действия системы диспетчеризации могут быть документированы с помощью UML-технологии[14] в виде диаграммы прецедентов, показанной на рисунке 1.9, где в качестве актера выступают «Оператор» и «Сервер диспетчеризации»
Рисунок 1.9 – Диаграмма прецедентов NETSENSOR
Серверная часть программы запускается автоматически. С заданной периодичностью серверная часть опрашивает подключенные контроллеры и заносит данные о результатах измерений в базу данных.
Оператор запускает клиентскую часть программы и выбирает необходимое действие. Оператор имеет возможность подключить новые контроллеры или удалить существующие, просмотреть результат последнего измерения для выбранного контроллера, запросить архив измерений за указанный период.
Описание прецедента «Выбрать контроллер» в виде таблицы представлено в таблице 1.13.
Таблица 1.13 – Описание прецедента «Выбрать контроллер»
Основной исполнитель – система
Заинтересованные лица – оператор
|
Предусловия:
– Наличия правильной программы
|
Входные данные:
– Список контроллеров
|
Основной успешный сценарий (основной процесс):
– Оператор выбрал необходимый контроллер;
– Оператор видит последнее измеренное значение температуры
|
Частота выполнения:
– по требованию оператора
|
Постусловия (результаты):
– Отображение последнего измеренного значения температуры на экране
|
Выходные данные:
– Последнее измеренное значение температуры
|
Выполним описание прецедента «Опросить контроллеры».
Серверная часть ПТК (сервер диспетчеризации) запрашивает из БД адреса подключенных к сети контроллеров и опрашивает их по очереди. Контроллеры передают данные об измеренной величине. Сервер диспетчеризации получает эти данные и заносит их в БД вместе с информацией о времени измерения. Табличное описание прецедента «Просмотр статистических данных» представлено в таблице 1.14.
Таблица 1.14 – Описание прецедента «Опросить контроллеры».
Основной исполнитель – система
|
Предусловия:
– Наличия правильной программы;
– Наличие подключенных к сети контроллеров
|
Входные данные:
– Сигнал от таймера
|
Основной успешный сценарий (основной процесс):
– Данные об измерениях заносятся в БД
|
Частота выполнения:
– С заданной периодичностью
|
Постусловия (результаты):
– Измененная БД
|
Выходные данные:
– Информация об измеряемой величине и дата/время измерения
|
В рассмотренной на рисунке 1.7 диаграмме прецедентов были показаны и проанализированы все основные прецеденты работы проектируемого ПТК. Показанные на диаграмме прецеденты соответствуют требованиям, предъявляемым к проектируемому ПТК ИИС с организацией доступа к измерительному устройству по его IP-адресу.
1.5.1.2 Разработка диаграммы классов предметной области «Тиражирование документации»
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования [15]. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.
Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами.
В соответствии с диаграммой прецедентов использования можно построить диаграмму классов, которая отображает связи между объектами системы.
Диаграмма классов предметной области «Система диспетчеризации» представлена на рисунке 1.8.
Рисунок 1.8 – Диаграмма классов предметной области «Тиражирование документации»
Пользователь получает задание по формированию твердых копий конструкторских документов, задание состоит из одного или более конструкторских документов различных форматов. Далее пользователь выбирает список оборудования, на котором будет происходить распечатка, список может состоять из одной или нескольких единиц оборудования, использующих различные технологии печати. Затем пользователь распределяет документы среди оборудования, для чего использует оптимизатор. Оптимизатор содержит пакет заданий по формированию твердых копий конструкторских документов, список оборудования, на котором будет происходить распечатка. Получив задание на распределение документов, Оптимизатор получает информацию о формате и размерах документов из пакета заданий, затем он получает информацию о формате бумаги, поддерживаемой оборудованием, а также о его текущей загрузке. После этого на основании полученных данных распределяет документы для печати на имеющемся в рабочем состоянии оборудовании. После окончания распределения Оптимизатор передает получившийся список для печати в очередь печати оборудования. Описание классов диаграммы классов предметной области «Тиражирование документации» представлено в таблице 1.15.
Таблица 1.15 – Описание классов
Название класса
|
Описание
|
Optimizer
|
Содержит классы, описывающие список оборудования (Record) и список документов (Quest), на основании данных, полученных от них, распределяет пакет заданий среди оборудования
|
Quest
|
Содержит список документов для распечатки
|
Document
|
Содержит информацию о конкретном документе для распечатки
|
Record
|
Содержит список подключенного оборудования
|
Equipment
|
Родительский класс для классов Plotter, Stylus_printer, Laser_printer, Inkjet_printer.
|
Plotter
|
Класс наследник класса Equipment . Хранит информацию о подключенном устройстве и выполняет распечатку документов после их сортировки.
|
Stylus_printer
|
Класс наследник класса Equipment. Хранит информацию о подключенном устройстве и выполняет распечатку документов после их сортировки.
|
Laser_printer
|
Класс наследник класса Equipment . Хранит информацию о подключенном устройстве и выполняет распечатку документов после их сортировки.
|
Продолжение таблицы 1.15
Название класса
|
Описание
|
Inkjet_printer
|
Класс наследник класса Equipment . Хранит информацию о подключенном устройстве и выполняет распечатку документов после их сортировки.
|
С помощью диаграммы классов мы наглядно и доступно представили программно-методический комплекс для оптимизации распределения заданий по формированию твердых копий конструкторских документов.
Разработка диаграммы последовательностей МАССПРИНТ
Одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов, из которых образованы эти системы. Так как различные составные элементы систем не существуют изолированно, а оказывают определенное влияние друг на друга, что и отличает систему как целостное образование от простой совокупности элементов. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду аспект взаимодействия, который можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности [16].
Получив пакет заданий, сотрудник отдела тиражирования должен распределить его среди имеющегося оборудования. Для этого сначала он узнает характеристики документов (формат, объем, срочность) в пакете заданий. Затем сотруднику необходимо определить свойства задействованного оборудования (формат, скорость печати, объем текущей загрузки). На основании полученных данных на следующем шаге сотрудник распределяет документы среди задействованного оборудования. Далее формируется очередь печати и начинается непосредственно сама печать. Сотрудник получает сообщение об отправке документов на печать. Указанные действия сотрудников могут быть документированы с помощью диаграммы последовательностей.
Диаграмма последовательностей для МАССПРИНТ представлена на рисунке 1.9.
Рисунок 1.9 – Диаграмма последовательности для прецедента «Печатать документ»
Опишем представленное на рисунке 1.9 взаимодействие между объектами МАССПРИНТ во время выполнения прецедента «Печатать документ». Пользователь запускает программу, жмет кнопку печать, чем формирует задание для объекта класса Optimizer, который создает объект класса Quest. Затем Optimizer запрашивает у Quest список документов для печати. Quest получает пакет документов и создает объект класса Document, после чего передает ему адреса документов и получает их свойства. Затем возвращает пакет документов и их свойства объекту класса Optimizer. После этого объект класса Optimizer создает объект класса Record и запрашивает список оборудования. Объект класса Record создает объект класса Equipment, передает в него данные по устройствам и получает от него их свойства. Затем объект класса Record возвращает свойства устройств объекту класса Optimizer. Затем объект класса Optimizer с помощью, разработанной в пункте 1.2 математической модели, производит распределение документов среди оборудования и отправляет данные для печати объекту класса Record а тот передает их объекту класса Equipment, который добавляет документы в очередь печати и возвращает результаты выполнения.
Разработка структуры информационного обеспечения МАССПРИНТ
Для удобства хранения и дальнейшего использования результатов работы в приложении разработана база данных, в которую автоматически, по мере выполнения работы, будет заноситься информация о подключенных принтерах и распечатанных на этих принтерах документах. В дальнейшем использование базы данных для хранения информации во многом облегчит поиск необходимых сведений, а, следовательно, уменьшит временные затраты пользователя.
Разработка модели «сущность-связь» (ER-диаграммы)
В настоящее время большинство проектов информационных систем (ИС) разрабатывается в соответствии с какой-либо методологией разработки ПО. Как следствие, разработчикам требуется инструмент для моделирования данных на этапах анализа и проектирования. Таким инструментом являются ER-диаграммы (Entity-Relationship, «Сущность-Связь») [17]. Фактически их использование является обязательным при разработке ИС, систем принятия решений, систем электронной торговли и B2B – большинства бизнес ориентированных систем.
ER-диаграммы позволяют строить модели логической структуры данных предметной области, а также производить моделирование физической структуры систем хранения данных. Составим список сущностей для проектируемой ER-диаграммы. Исходя из диаграммы классов предметной области, можно выделить две сущности: «Документ», «Принтер. Сущность «Документ» характеризуется свойствами: номером документа, путем к нему, объемом документа и его форматом. Сущность «Принтер» характеризуется свойствами: скоростью, загрузкой, портом, драйвером и названием. Исходя из всего перечисленного построим ER-диаграмму. ER-диаграмма проектируемой базы данных представлена на рисунке 1.10.
Рисунок 1.10 – ER-диаграмма базы данных для хранения информации по распечатываемым документам, и используемому оборудованию
Представленная на рисунке 1.10 ER-диаграмма моделирует структуру проектируемой в дипломном проекте, базы данных. Проектируемая база данных предназначена для удобства хранения и дальнейшего использования результатов работы в приложении.
|
