Проектирование системы экологического и гидроакустического мониторинга с использованием языка UML и Rational Rose

Цитирование: Дорофеев Г. В. Проектирование системы экологического и гидроакустического мониторинга с использованием языка UML и Rational Rose / Г. В. Дорофеев, П. А. Стародубцев, Е. А. Сторожок, А. С. Шешуков // Журн. Сиб. федер. ун-та. Техника и технологии, 2023, 16(1). С. 29–35. EDN: URIEGW по единому замыслу и плану и интегрированных в единую систему с целью сбора, обработки и автоматизированной выдачи потребителям данных об экологической и подводной обстановке в реальном масштабе времени. Система экологического и гидроакустического мониторинга относится к классу информационных систем и включает:

• –    стационарный барьер донных или якорных радиогидроакустических буёв (РГБ);

• –    надводный ретранслятор;

• –    спутниковый канал связи;

• –    береговой центр обработки данных.

Система мониторинга состоит из подсистем экологического и гидроакустического мониторинга. Использование языка UML для моделирования подсистемы экологического мониторинга описано в [2]. Рассмотрим процесс моделирования подсистемы гидроакустического мониторинга.

Подсистема гидроакустического мониторинга должна обеспечивать дальнее обнаружение шумящих подводных объектов, классификацию, определение координат и параметров движения и их сопровождение. Ядром системы является стационарный барьер РГБ [3, 4], который должен обнаружить подводную цель, выполнить первичную классификацию и передать на береговой центр сообщение о факте обнаружения подводного объекта и его вероятное местонахождение. В функции берегового центра входит вторичная классификация шумящего объекта, уточнение его координат и параметров движения. Далее осуществляется сопровождение цели.

Между элементами системы освещения обеспечивается беспроводная связь. Для обеспечения такой возможности элементы системы объединены в беспроводную корпоративную сеть. Связь этой сети с береговым центром осуществляется через спутниковый канал связи с использованием надёжного транспортного протокола TCP. Информационное обеспечение системы освещения представляет собой распределённую базу данных реляционного типа.

Буи ядра системы строятся на основе микроконтроллеров и объединены в локальную сеть Ethernet при помощи волоконно-оптического кабеля. В случае обрыва кабеля есть возможность обмена информацией при помощи звукоподводного модема, наличие которого предусматривается в составе каждого буя. Объединение буёв барьера в сеть позволяет реализовать адаптивные алгоритмы фильтрации для подавления шума, а также упрощает определение координат и параметров движения цели (КПДЦ) непосредственно самим барьером. Каждый буй имеет несколько радиопередающих устройств всплывающего типа с возможностью передачи сообщений на береговой центр через спутниковый канал связи.

Создание модели вариантов использования

На рис. 1 приведена модель вариантов использования [5].

Действующие лица (business actors) и их варианты использования:

• –    Стационарный барьер РГБ – обнаруживает цель, выполняет первичную классификацию цели, передаёт сообщение на береговой центр [6, 7, 8];

• –    Береговой центр – выполняет вторичную классификацию цели и осуществляет целеуказание;

• –    Надводный ретранслятор – является буферным звеном между звукоподводным и спутниковым каналами связи;

• –    Распределённая база данных (БД) – содержит шумовые портреты целей;

Рис. 1. Модель вариантов использования

Fig. 1. Model of use cases

• –    Цель – уклонение и прорыв.

• 2.    Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования.

• 3.    Управляющие классы (Control) – обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

Идентификация классов, участвующих в реализации потоков событий варианта использования

В потоках событий варианта использования выявляются классы трех типов:

Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо – вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса – кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

Распределение поведения, реализуемого вариантом использования, между классами осуществляется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм). Диаграмма взаимодействия – это диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются [1]. В первую очередь строится диаграмма (одна или более), описывающая основной поток событий и его подчиненные потоки. Для каждого альтернативного потока событий строится отдельная диаграмма. Нецелесообразно описывать тривиальные потоки событий (например, в потоке участвует только один объект). На рис. 2 представлена диаграмма последовательности.

Рис. 2. Диаграмма последовательности

Fig. 2. Sequence diagram

Проектирование архитектуры системы

Целью объектно-ориентированного проектирования является адаптация предварительного системного проекта (набора классов «анализа»), составляющего стабильную основу архитектуры системы, к среде реализации с учетом всех нефункциональных требований. Объектноориентированное проектирование включает два вида деятельности:

• •    проектирование архитектуры системы;

• •    проектирование элементов системы.

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

• •    идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;

• •    анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

• •    формирование архитектурных уровней;

• •    проектирование структуры потоков управления;

• •    проектирование конфигурации системы.

Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные классы (design classes). По каждому классу анализа принимается одно из двух решений:

• •    класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;

• •    сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.

Объединение классов в подсистемы осуществляется исходя из следующих соображений:

• •    функциональная связь: объединяются классы, участвующие в реализации варианта использования и взаимодействующие только друг с другом;

• •    обязательность: совокупность классов, реализующая функциональность, которая может быть удалена из системы или заменена на альтернативную;

• •    связанность: объединение в подсистемы сильно связанных классов;

• •    распределение: объединение классов, размещенных на конкретном узле сети.

Примеры возможных подсистем:

• •    совокупность классов, обеспечивающих сложный комплекс функций (например, обеспечение безопасности и защиты данных);

• •    граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами;

• •    различные продукты: коммуникационное ПО, доступ к базам данных, общие утилиты (библиотеки), различные прикладные пакеты.

При создании подсистем в модели выполняются следующие преобразования:

• •    объединяемые классы помещаются в специальный пакет с именем подсистемы и стереотипом <>;

• •    спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы – класс со стереотипом <>;

• •    описание интерфейса должно включать:

• –    имя интерфейса, отражающее его роль в системе;

• –    текстовое описание интерфейса размером с небольшой абзац, отражающее его обязанности;

• –    описание операций интерфейса (имя, отражающее результат операции, алгоритм выполнения операции, возвращаемое значение, параметры с их типами);

• –    характер использования операций интерфейса и порядок их выполнения документируются с помощью диаграмм взаимодействия, описывающих взаимодействие классов подсистемы при реализации операций интерфейса, которые вместе с диаграммой классов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом <>;

• •    в подсистеме создается класс-посредник со стереотипом <>, управляющий реализацией операций интерфейса.

Все интерфейсы подсистем должны быть полностью определены в процессе проектирования архитектуры, поскольку они будут служить в качестве точек синхронизации при параллельной разработке системы.

Выводы

• 1.    Проектирование системы экологического и гидроакустического мониторинга может проводиться с использованием языка UML, который упрощает коммуникацию заказчика с разработчиком.

• 2.    Конечная цель моделирования на языке UML – генерация исходного кода на языке С++ или Java.