CC BY
8Technosphere Safety Техносферная безопасность
EDN: URIEGW УДК 629.124: 681.883
Designing an Environmental
and Hydroacoustic Monitoring System Using UML
and Rational Rose
Grigorij V. Dorofeev*, Pavel A. Starodubtsev, Evgenij A. Storozhok and Andrej S. Sheshukov
Pacific Higher Naval School named after S. O. Makarov
Vladivostok, Russian Federation
Received 22.10.2022, received in revised form 03.11.2022, accepted 19.12.2022
Abstract. The process of oil production in the offshore zones of the world ocean is associated with the risk of environmental pollution, the exclusion of such a possibility requires regular environmental monitoring. In addition, the threat of sabotage at hydraulic engineering facilities has increased recently, which requires the creation of hydroacoustic monitoring systems. In this regard, the creation of new and improvement of existing monitoring systems is an urgent task.
The article analyzes the possibility of using the UML language during the design of a monitoring system using the UML language and the IBM Rational Rose CASE tool.
Keywords: monitoring, unified modeling language, UML, diagram, class, object, use case.
Citation: Dorofeev, G.V., Starodubtsev, P. A., Storozhok, E.A., Sheshukov, A. S. Designing an environmental and hydroacoustic monitoring system using UML and Rational Rose. J. Sib. Fed. Univ. Eng. & Technol., 2023, 16(1), 29-35. EDN: URIEGW
© Siberian Federal University. All rights reserved
This work is licensed under a Creative Commons Attribution-Non Commercial 4.0 International License (CC BY-NC 4.0). Corresponding author E-mail address: grigory_artem_007@mail.ru
Проектирование системы экологического и гидроакустического мониторинга с использованием языка UML и Rational Rose
Г. В. Дорофеев, П. А. Стародубцев, Е. А. Сторожок, А. С. Шешуков
Тихоокеанское высшее военно-морское училище им. С. О. Макарова
Российская Федерация, Владивосток
Аннотация. Процесс нефтедобычи в шельфовых зонах мирового океана сопряжен с риском загрязнения окружающей среды, исключение такой возможности требует проведения регулярного экологического мониторинга. Кроме того, в последнее время возросла угроза диверсий на гидротехнических объектах, что требует создания систем гидроакустического мониторинга. В связи с этим создание новых и совершенствование существующих систем мониторинга является актуальной задачей. В статье проанализирована возможность применения языка UML в ходе проектирования системы мониторинга с использованием языка UML и CASE-средства IBM Rational Rose.
Ключевые слова: мониторинг, унифицированный язык моделирования, UML, диаграмма, класс, объект, вариант использования.
Цитирование: Дорофеев Г. В. Проектирование системы экологического и гидроакустического мониторинга с использованием языка UML и Rational Rose / Г. В. Дорофеев, П. А. Стародубцев, Е. А. Сторожок, А. С. Шешуков // Журн. Сиб. федер. ун-та. Техника и технологии, 2023, 16(1). С. 29-35. EDN: URIEGW
Введение
Основной проблемой устойчивого и надежного функционирования системы экологического и гидроакустического мониторинга морских акваторий является недостаточность ее информационного наполнения. Два основных недостатка существующих систем мониторинга - эпизодичность и локальность. Решение этой важной задачи может лежать в плоскости создания автоматизированной информационной системы экологического и гидроакустического мониторинга морских акваторий, где в качестве ее основных элементов могут выступать автономные технические средства и подводные стационарные комплексы.
Язык унифицированного моделирования UML является эффективным средством общения между заказчиком и разработчиком, а также между членами команды разработчиков [1]. Язык UML и какое-либо CASE-средство, например IBM Rational Rose, используются для построения модели проектируемой системы. Модель представляет собой набор диаграмм, описывающих различные аспекты системы. Конечной целью моделирования является генерация кода на языке С++ или Java.
Постановка задачи
Перед командой разработчиков ставится задача разработки системы экологического и гидроакустического мониторинга. Такая система является совокупностью взаимосвязанных, взаимодействующих, технически совместимых, разнородных и разновидовых систем экологического мониторинга и средств гидроакустики, автоматизации и связи, размещенных в пространстве
по единому замыслу и плану и интегрированных в единую систему с целью сбора, обработки и автоматизированной выдачи потребителям данных об экологической и подводной обстановке в реальном масштабе времени. Система экологического и гидроакустического мониторинга относится к классу информационных систем и включает:
- стационарный барьер донных или якорных радиогидроакустических буёв (РГБ);
- надводный ретранслятор;
- спутниковый канал связи;
- береговой центр обработки данных.
Система мониторинга состоит из подсистем экологического и гидроакустического мониторинга. Использование языка UML для моделирования подсистемы экологического мониторинга описано в [2]. Рассмотрим процесс моделирования подсистемы гидроакустического мониторинга.
Подсистема гидроакустического мониторинга должна обеспечивать дальнее обнаружение шумящих подводных объектов, классификацию, определение координат и параметров движения и их сопровождение. Ядром системы является стационарный барьер РГБ [3, 4], который должен обнаружить подводную цель, выполнить первичную классификацию и передать на береговой центр сообщение о факте обнаружения подводного объекта и его вероятное местонахождение. В функции берегового центра входит вторичная классификация шумящего объекта, уточнение его координат и параметров движения. Далее осуществляется сопровождение цели.
Между элементами системы освещения обеспечивается беспроводная связь. Для обеспечения такой возможности элементы системы объединены в беспроводную корпоративную сеть. Связь этой сети с береговым центром осуществляется через спутниковый канал связи с использованием надёжного транспортного протокола TCP. Информационное обеспечение системы освещения представляет собой распределённую базу данных реляционного типа.
Буи ядра системы строятся на основе микроконтроллеров и объединены в локальную сеть Ethernet при помощи волоконно-оптического кабеля. В случае обрыва кабеля есть возможность обмена информацией при помощи звукоподводного модема, наличие которого предусматривается в составе каждого буя. Объединение буёв барьера в сеть позволяет реализовать адаптивные алгоритмы фильтрации для подавления шума, а также упрощает определение координат и параметров движения цели (КПДЦ) непосредственно самим барьером. Каждый буй имеет несколько радиопередающих устройств всплывающего типа с возможностью передачи сообщений на береговой центр через спутниковый канал связи.
Создание модели вариантов использования
На рис. 1 приведена модель вариантов использования [5].
Действующие лица (business actors) и их варианты использования:
- Стационарный барьер РГБ - обнаруживает цель, выполняет первичную классификацию цели, передаёт сообщение на береговой центр [6, 7, 8];
- Береговой центр - выполняет вторичную классификацию цели и осуществляет целеуказание;
- Надводный ретранслятор - является буферным звеном между звукоподводным и спутниковым каналами связи;
- Распределённая база данных (БД) - содержит шумовые портреты целей;
Жлонение Прорыв
Рис. 1. Модель вариантов использования Fig. 1. Model of use cases
- Цель - уклонение и прорыв.
Идентификация классов, участвующих в реализации потоков событий варианта использования
В потоках событий варианта использования выявляются классы трех типов:
Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо - вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).
2. Классы-сущности (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования.
3. Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.
Распределение поведения, реализуемого вариантом использования, между классами осуществляется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм). Диаграмма взаимодействия - это диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются [1]. В первую очередь строится диаграмма (одна или более), описывающая основной поток событий и его подчиненные потоки. Для каждого альтернативного потока событий строится отдельная диаграмма. Нецелесообразно описывать тривиальные потоки событий (например, в потоке участвует только один объект). На рис. 2 представлена диаграмма последовательности.
Рис. 2. Диаграмма последовательности Fig. 2. Sequence diagram
Проектирование архитектуры системы
Целью объектно-ориентированного проектирования является адаптация предварительного системного проекта (набора классов «анализа»), составляющего стабильную основу архитектуры системы, к среде реализации с учетом всех нефункциональных требований. Объектно-ориентированное проектирование включает два вида деятельности:
• проектирование архитектуры системы;
• проектирование элементов системы.
Проектирование архитектуры системы выполняется архитектором системы и включает в себя:
• идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;
• анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;
• формирование архитектурных уровней;
• проектирование структуры потоков управления;
• проектирование конфигурации системы.
Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные классы (design classes). По каждому классу анализа принимается одно из двух решений:
• класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;
• сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.
Объединение классов в подсистемы осуществляется исходя из следующих соображений:
• функциональная связь: объединяются классы, участвующие в реализации варианта использования и взаимодействующие только друг с другом;
• обязательность: совокупность классов, реализующая функциональность, которая может быть удалена из системы или заменена на альтернативную;
• связанность: объединение в подсистемы сильно связанных классов;
• распределение: объединение классов, размещенных на конкретном узле сети.
Примеры возможных подсистем:
• совокупность классов, обеспечивающих сложный комплекс функций (например, обеспечение безопасности и защиты данных);
• граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами;
• различные продукты: коммуникационное ПО, доступ к базам данных, общие утилиты (библиотеки), различные прикладные пакеты.
При создании подсистем в модели выполняются следующие преобразования:
• объединяемые классы помещаются в специальный пакет с именем подсистемы и стереотипом «subsystem»;
• спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы - класс со стереотипом «Interface»;
• описание интерфейса должно включать:
- имя интерфейса, отражающее его роль в системе;
- текстовое описание интерфейса размером с небольшой абзац, отражающее его обязанности;
- описание операций интерфейса (имя, отражающее результат операции, алгоритм выполнения операции, возвращаемое значение, параметры с их типами);
- характер использования операций интерфейса и порядок их выполнения документируются с помощью диаграмм взаимодействия, описывающих взаимодействие классов подсистемы при реализации операций интерфейса, которые вместе с диаграммой классов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом «interface realization»;
• в подсистеме создается класс-посредник со стереотипом «subsystem proxy», управляющий реализацией операций интерфейса.
Все интерфейсы подсистем должны быть полностью определены в процессе проектирования архитектуры, поскольку они будут служить в качестве точек синхронизации при параллельной разработке системы.
Выводы
1. Проектирование системы экологического и гидроакустического мониторинга может проводиться с использованием языка UML, который упрощает коммуникацию заказчика с разработчиком.
2. Конечная цель моделирования на языке UML - генерация исходного кода на языке С++ или Java.
Список литературы / References
[1] Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. М., ДМК, 2006. 496 с. [Butch G., Rambo D., Jacobson A. The UML language. User Manual. M., DMK, 2006. 496 p. (in Rus.)].
[2] Сторожок Е. А. Агрегирование системы морского экологического мониторинга с использованием языка UML и CASE-средства IBM RATIONAL ROSE. Автоматизация и информатизация ТЭК, 2022, 6(587). 48-51 [Storozhok E. A. Aggregation of the marine environmental monitoring system using the UML language and IBM RATIONAL ROSE CASE-tools. Automation and Informatization of the Fuel and Energy Complex, 2022, 6(587). 48-51 (in Rus.)].
[3] Сторожок Е. А. Подводная беспроводная локальная вычислительная сеть как элемент системы морского экологического мониторинга. Автоматизация, телемеханизация и связь в нефтяной промышленности. 2016, 8, 30-34 [Storzhok E. A. Underwater wireless local area network as an element of the marine environmental monitoring system. Automation, telemechanization and communication in the oil industry. 2016, 8, 30-34 (in Rus.)].
[4] Стародубцев П.А., Сторожок Е. А., Алифанов Р. Н. Агрегирование системы гидроакустического мониторинга. Техника и технологии. Научно-технический журнал Сибирского федерального университета, 2020, 13(2), 206-212 [Starodubtsev P. A., Storozhok E. A., Alifanov R. N. Aggregation of the hydroacoustic monitoring system. Engineering & Technologies. Scientific and Technical Journal of Siberian Federal University, 2020, 13(2), 206-212 (in Rus.)].
[5] Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования, СПб., Питер, 2002. 368 с. [Gamma E. Methods of object-oriented design. Design patterns, St. Petersburg, Peter, 2002. 368 p. (in Rus.)].
[6] Сторожок Е.А., Дорофеев Г. В., Стародубцев П. А. Классификация сигналов с использованием технологии нейронных сетей. Техника и технологии. Научно-технический журнал Сибирского федерального университета, 2022, 15(3), 318-324 [Storozhok E. A., Dorofeev G. V., Staro dubtsev P. A. Classification of signals using neural network technology. Engineering & Technologies. Scientific and Technical Journal of Siberian Federal University, 2022, 15(3), 318-324 (in Rus.)].
[7] Стародубцев П.А., Сторожок Е. А. Идентификация источника сигнала в измерительном узле системы морского и гидроакустического мониторинга. Морские интеллектуальные технологии. Научно-технический журнал, 2020, 1-2(47), 212-214 [Starodubtsev P. A., Storozhok E. A. Identification of the signal source in the measuring node of the marine and hydroacoustic monitoring system. Marine intelligent technologies. Scientific and Technical Journal, 2020, 1-2(47), 212-214 (in Rus.)].
[8] Сторожок Е. А. Радиогидроакустический буй на микроконтроллерах с базой данных эталонных сигналов. Изобретение: пат. 2723914 Рос. Федерация: МПК B 63B 22/00(2006.01), G01S 15/00(2006.01); заявитель и патентообладатель Федеральное государственное казённое военное образовательное учреждение высшего образования «Тихоокеанское высшее военно-морское училище им. С. О. Макарова»; заявл. 18.07.2019; опубл. 18.06.2020, Бюл. № 17. 13: ил. [Storozhok E. A. Radio hydroacoustic buoy on microcontrollers with a database of reference signals. Invention: pat. 2723914 Ros. Federation: IPC B 63B 22/00(2006.01), G01S 15/00(2006.01); applicant and patent holder Federal State State Military Educational Institution of Higher Education "Pacific Higher Naval School named after S. O. Makarov"; application. 18.07.2019; publ. 18.06.2020, Bul. No. 17. 13: ill. (in Rus.)].
