Код
|
Основной
актер
|
Наименование
|
Формулировка
|
О1
|
Оператор
ССП
|
Отправка
запроса
|
О2
|
Оператор
ССП
|
Получение
измерений
|
Этот
вариант использования позволяет оператору ССП получать данные с объекта
исследования в реальном времени.
|
О3
|
Оператор
ССП
|
Визуализация
данных
|
Этот
вариант использования позволяет оператору ССП приставлять показания с
анализатора качества электроэнергии РМ175 в виде графиков.
|
.3 Конкретизация вариантов использования
.3.1 О1. Отправка запроса
Этот вариант использования позволяет оператору
ССП отправить запрос на сервер для получения данных с анализатора качества
электроэнергии PM175.
Основное действующее лицо: Оператор ССП.
Другие участники прецедента: отсутствуют
Связи с другими вариантами использования:
отсутствуют
Краткое описание: данный вариант использования
позволяет оператору ССП отправлять запросы на сервер. В случае возникновения
сбоя, программа выдает сообщение об ошибке. Запрос можно отправлять
неограниченное число раз.
.3.2 О2. Получение измерений
Этот вариант использования позволяет оператору
ССП получать данные с объекта исследования в реальном времени.
Основное действующее лицо: Оператор ССП.
Другие участники прецедента: отсутствуют
Связи с другими вариантами использования:
отсутствуют
Краткое описание: данный вариант использования
позволяет оператору ССП получать измерения с объекта исследования в реальном
времени.
Возможно получение всех показаний,
предусмотренных характеристиками прибора PM175. В данном случае это - сила
тока, напряжение и мощность.
3.3.3 О3. Визуализация данных
Этот вариант использования позволяет оператору
ССП приставлять показания с анализатора качества электроэнергии РМ175 в виде
графиков.
Основное действующее лицо: Оператор ССП.
Другие участники прецедента: отсутствуют
Связи с другими вариантами использования:
отсутствуют
Краткое описании:. данный вариант использования
позволяет оператору ССП преобразовывать полученные данные в визуальный вид
(графики).
При необходимости программа может отобразить
сразу несколько графиков для более полного представления ситуации на
исследуемом объекте.
4. Описание ключевых прецедентов
.1 Поиск ключевых вариантов использования
Анализ сформулированных вариантов использования
показал, что с точки зрения потенциальных рисков и архитектурной значимости
наиболее существенными являются прецеденты, связанные с работой оператора ССП.
Для дальнейшей детализации выбраны три
прецедента:
- О1: Отправка запроса;
- О2: Получение измерений;
- О3: Визуализация данных.
.2 Прецедент О1: Отправка запроса
Оператор ССП отправляет запрос на снятие данных
с прибора РМ175.
Действующее лицо этого прецедента - Оператор
ССП.
.2.1 Базовый поток
Прецедент начинается, когда Оператор ССП
запускает программу-клиент.
1) Оператор ССП запускает программу-клиент;
) Оператор ССП вводит IP-адрес компьютера-сервера
в окно «IP-адрес»;
) Оператор ССП выбирает характеристики,
которые он хочет получить от прибора;
) Оператор ССП нажимает кнопку «Запрос».
.2.2 Альтернативный поток
Если при выполнении пункте 4.1.1.1
программа-клиент выдала ошибку соединения с сервером, то необходимо выполнить
следующие действия:
1) Проверить правильность введенного IP-адреса;
2) Перейти к выполнению п. 1 основного
потока событий.
.2.3 Специальные требования
Время ответа сервера не должно превышать 1
минуты.
.2.4 Предусловия
Перед тем, как начать работать с данным
прецедентом, Оператор ССП должен убедиться в том, что компьютер-клиент
подключен к сети Интернет.
.2.5 Постусловия
При успешном окончании прецедента, оператор ССП
имеет возможность перейти к исполнению дальнейших прецедентов.
.2.6 Точки расширения
Если при выполнении пункта 1 основного потока
событий, выясняется, что в программе-клиенте уже записан необходимый IP-адрес
и выбраны необходимые на данный момент характеристики, то Оператор ССП может
непосредственно приступить к выполнению пункта 4 основного потока событий (см.
рисунок 5).
Рисунок 5 - Отправка запроса
.3 Прецедент О2: Получение измерений
Оператор ССП сохраняет данные, полученные от
сервера. Действующие лица этого прецедента - Оператор ССП.
.3.1 Базовый поток событий
Прецедент начинается, когда Оператор ССП
выполнит прецедент «Отправка запроса».
1) Оператор
ССП выполняет прецедент «Отправка запроса»;
2) Нажать
кнопку «Сохранить».
.3.2 Альтернативные потоки
Если при выполнении п. 2 основного потока
событий программа-клиент выдала ошибку «Недостаточно свободного места на
диске», то необходимо выполнить следующие действия:
1) Освободить необходимое место на жестком
диске компьютера.
.3.3 Специальные требования
На жестком диске должно быть достаточно
свободного места для сохранения данных с прибора учета PM175.
Перед тем, как начать работы с данным
прецедентом Оператор ССП должен выполнить прецедент «Отправка запроса». Так же
на компьютере-клиенте должно быть установлено специализированное ПО - MicroSoft
Exele, необходимое для
открытия файла с полученными данными.
.3.5 Постусловия
При успешном окончании прецедента Оператор ССП
имеет произвести необходимые для дальнейшего развития вычисления.
.3.6 Точки расширения
На рисунке 6 показана схема потока событий
прецедента О2: Получение измерений.
Рисунок 6 - Получение измерений
4.4 Прецедент О3: Визуализация данных
Оператор ССП визуализирует данные полученные от
сервера.
Действующие лица этого прецедента - Оператор
ССП.
.4.1 Базовый поток событий
Прецедент начинается, когда Оператор ССП
выполняет прецедент «Отправка запроса».
1) Оператор
ССП выполняет прецедент «Отправка запроса»;
2) Оператор
ССП нажимает кнопку «Построить график».
.4.2 Альтернативные потоки
Если при выполнении пункта 2 основного потока
событий программа-клиент выдала ошибку «Недостаточно данных», то необходимо
выполнить следующие действия:
1) Перейти к выполнению п. 1 основного потока
событий.
2) Выбрать только 2 характеристики, которые
будут отображать зависимость на графике.
.4.3 Предусловия
Перед тем, как начать работы с данным
прецедентом Оператор ССП должен выполнить прецедент «Отправка запроса».
.4.4 Постусловия
При успешном окончании прецедента Оператор ССП
имеет возможность исследовать построенный график.
.4.5 Точки расширения
На рисунке 7 показана схема потока события для
прецедента О3: Визуализация данных
Рисунок 7 - Визуализация данных
5. Классы
Класс - описание множества объектов, которые
разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс
реализует один или несколько интерфейсов.
Класс состоит из множества атрибутов,
определяющих структуру объектов, и методов, которые определяют поведение
объекта. Как правило, атрибуты объекта недоступны для других классов.
В нашей системе мы реализуем такие классы:
- VISA
- предоставляет возможность для открытия COM-порта
для передачи данных;
- ModBus
- класс предоставляющий работу по протоколу ModBus
RTU для сопряжения АРМ
и прибора;
- Array
- массив данных имеющий такие атрибуты как: size,
index, new
element;
- TCP
- класс предоставляющий работу по протоколу TCP
IP для передачи
массива данных по среде Internet;
- PolarPlot
- класс визуализации данных, обрабатывающий Array
и представляя все для пользователя в виде векторной диаграммы и осциллограммы;
- FileIO
- класс создания документов, предоставляющий возможность для преобразования Array
в файл текстового формата для длительного хранения и дальнейшего изучения.
На рисунке 8 представлена диаграмма классов
Рисунок 8 - Диаграмма классов
6. Моделирование взаимодействия
Диаграммы взаимодействия (interaction
diagram) являются
моделями, описывающими поведение взаимодействующих групп объектов. Как правило,
диаграмма взаимодействия охватывает поведение только одного варианта
использования. На такой диаграмме отображается ряд объектов и те сообщения,
которыми они обмениваются между собой в рамках данного варианта
использованиях[2]. В языке UML
есть две диаграммы взаимодействия:
- Диаграмма последовательности
(рисунок 9);
- Диаграмма кооперации (рисунок 10).
Диаграммы последовательности (sequence
diagrams) предназначены для
представления динамики поведения объектов, отображая передачу сообщений между
соответствующими классами.
Диаграммы кооперации (Collaboration
diagram) похожи на
диаграммы последовательности. Данный тип диаграмм также отображает
взаимодействие между классами, через набор объектов и сообщений между ними.
Отличие состоит в том, что диаграмма последовательности акцентирует внимание на
временном упорядочивании взаимодействия объектов, а диаграмма кооперации на
общую организацию взаимодействующих объектов в соответствии с их
пространственным расположением.
Рисунок 9 - Диаграмма последовательности
Рисунок 10 - Диаграмма кооперации
7. Моделирование конечных автоматов
Для описания большинства физических систем, не
достаточно бывает их статических моделей таких, к примеру, как диаграмма
классов, так как такие системы характеризуются не только структурой
составляющих ее элементов, но и некоторым поведением или функциональностью. Для
понимания этого поведения или динамического взаимодействия подсистем и всей
динамики системы в целом, необходимо моделирование всех состояний
разрабатываемой системы и отдельных её частей.
В языке UML для моделирования поведения может
использоваться наряду с диаграммами состояний, деятельности, последовательности
и кооперации так же и диаграмма состояний. В отличие от других диаграмм
диаграмма состояний описывает процесс изменения состояний только одного класса,
а точнее - одного экземпляра определенного класса, или другими словами,
моделирует все возможные изменения в состоянии конкретного объекта. При этом
изменение состояния объекта может быть вызвано внешними воздействиями со
стороны других объектов или извне.
Главное предназначение этой диаграммы - описать
возможные последовательности состояний и переходов, которые в совокупности
характеризуют поведение элемента модели в течение его жизненного цикла. [3]
Автомат в языке UML
может описывать поведение как отдельного объекта так и целого класса, в форме
последовательности состояний, которые охватывают все этапы его жизненного
цикла, начиная от создания объекта и заканчивая его уничтожением. Диаграмма
состояний представляет некоторый автомат.
На рисунке 11 изображена диаграмма состояний
класса FileIO. После
получения запроса (состояние Get
Request) система начинает
снятие показаний с прибора PM175.
Во время снятия показаний система делает измерения качества электроэнергии
сети. Для дальнейшего действия принятия решения служит аргумент ‘View’,
не нулевое значение которого указывает, что необходима дальнейшая отправка
полученных данных в PolarPlot.
Рисунок 11 - Диаграмма состояний для FileIO
На рисунке 12 представлена диаграмма состояний
для класса Modbus. После
создания запроса на получение доступа (состояние Allow
Request) следует стадия
получение доступа. На этом этапе система должна получить разрешение на доступ (Access==1),
только после этого она имеет право отправить запрос. В случает отказа в доступе
(Access==0), система
возвращается на предыдущий этап для проверки посланных данных.
Рисунок 12 - Диаграмма состояний Modbus
8. Физические диаграммы
Любая программная система может считаться
реализованной лишь в том случае, если она выполняет необходимый функционал. Для
этого необходимо преобразовать программный код системы в исполняемые модули,
библиотеки, файлы баз данных, и.т.д. Таким образом, полный проект программной
системы представляет собой совокупность логической и физической моделей. В UML
для физического представления моделей систем существует два вида диаграмм:
- диаграммы компонентов;
- диаграммы развертывания.
Диаграмма компонентов (Component
diagram) - диаграмма,
которая отображает компоненты системы и связи между ними. Компонент
представляет собой законченный элемент, который реализует определенный набор интерфейсов.
Главным преимуществом компонента является его повторное использование в других
системах. Диаграмма развертывания отображает способ взаимодействия компонентов
с аппаратными средствами в физической системе, а также соединение аппаратных
средств между собой. Основным элементом системы является узел. Узел -
представление любого вычислительного ресурса. На рисунке 13 представлена
физическая диаграмма, отображающая в себе диаграмму компонентов и диаграмму
развертывания.
Рисунок 13 - Физическая диаграмма
Заключение
При запуске серверной части появляется окно,
изображенное на рисунке 14. Как видно из рисунка интерфейс весьма прост,
имеется два поля одно для отображения номера сетевого порта который вшит в
программу, а так же поле скорости передачи по протоколу RS232
которое мы может изменять. И кнопка остановки сервера.
Интерфейс клиента представлен на рисунке 15, он
интуитивно понятен и прост в освоении. После запуска клиентской части,
появляется окно с пустыми полями «IP-адрес
сервера» и «№ порта», которые клиенту необходимо заполнить.
Рисунок 15 - Интерфейс клиента
После ввода необходимых данных клиенту остается
только нажать на кнопку запроса и дождаться ответа от сервера.
Когда сервер обработает запрос от клиента,
получит данные от прибора и перешлет клиенту, то в программе клиента появятся
графики, основанные на полученных данных. Пример визуализации данных можно
увидеть на рисунке 16.
Система сбора данных должна визуализировать
данные в виде трех диаграмм. Это гистограмма гармоник сети (рисунок 17),
векторная диаграмма токов и напряжений (рисунок 16), а также диаграмма
амплитудно-частотная характеристика (далее - АЧХ) (рисунок 16). Каждая
диаграмма несет определенную смысловую нагрузку для пользователя и отображает
разные данные, поэтому необходимо именно такое количество диаграмм.
Гистограмма гармоник отображает величины
гармоник сети, по оси х должна быть шкала нумерации гармоник от 1-50, а по оси
у - величина гармоник от 0-100.
Векторная диаграмма токов и напряжений
показывает угловой сдвиг токов относительно напряжений по каждой фазе и их
величину. Изображаются эти вектора в окружности с градусными рисками от 0 до
360, каждый вектор должен быть отличного цвета от других векторов. При
построении диаграммы используются угловые сдвиги и величины данных
характеристик. АЧХ отображает зависимость изменения значений амплитуды и
частоты во времени. С анализатора КЭ возможно получить всю таблицу данных, а
для построения АЧХ необходимо только визуализировать диаграмму. Каждую
характеристику необходимо отобразить в своем окне что возможно сделать путем
использования Mixed Waveform Plot.
Рисунок 16 - Слева - АЧХ, справа - векторная
диаграмма
Рисунок 17 - Гистограмма гармоник
Список использованных источников
1 Википедия. Свободная
энциклопедия: электрон. статья Диаграмма прецедентов. URL:
http://ru.wikipedia.org
(дата обращения 27.03.2013)
Леоненков, А.В. Самоучитель
UML / А.В. Леоненков .- 2-е изд., перераб. и доп.- СПб : БХВ-Петербург, 2004
Леоненков, А.В. Самоучитель
UML / А.В. Леоненков .- 2-е изд., перераб. и доп.- СПб : БХВ-Петербург, 2004
4 Прибор для измерений
показателей качества и учета электрической энергии PM175
-Руководство по установке и эксплуатации BG0440
Rev. A6.
5 LabVIEW: стиль
программирования. Пер. с англ. под ред. Михеева П.- М.: ДМК Пресс, 2008 - 400
с. : ил.
6 Modbus:
электрон. статья Оригинальная спецификация протокола Modbus.
URL:
http://www.modbus.org (дата обращения 15.10.2012).
7 Компьютерные сети. 4-е изд.
/ Э. Таненбаум. - СПб.: Питер, 2011. - 992 с.: ил.
8 Применение
UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ,
проектирование и итеративную разработку. / Крэг Ларман.: Вильямс, 2013. -
736с.: ил.