Материал: Оптимизация и моделирование в автоматизированных системах

Преимуществами предлагаемой разработки являются следующие [9, 10. 11]:

1)возможность регулирования периодичности анализа технологической среды на предмет наличия дефектов;

2)возможность обнаружения точного обнаружения конкретной дефектной области технологической системы [9];

3)универсальность использования в различных технологических средах, благодаря возможности задания эталонных параметров;

4)относительно невысокая стоимость оборудования;

5)простота и интуитивная понятность в эксплуатации.

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

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

Рис. 3. Декомпозиция контекстной диаграммы

85

Литература

1.Жумаев, К.К. Выявление внутренних и наружных дефектов трубопроводов ультразвуковыми дефектоскопами [Текст] / К.К. Жумаев, Н.О. Каландаров // Молодой ученый. 2014. № 16. С. 67–68.

2.Щербинский, В.Г. Методы дефектоскопии сварных соединений [Текст] / В.Г. Щербинский. – 1987. – С. 57–64.

3.Гурвич, А.К. Ультразвуковой контроль сварных швов [Текст] / А.К. Гурвич, И.Н. Ермолов. – Киев: Техшка, 1972.

4.Филинов, М.В. Капиллярный контроль [Текст] / М.В. Филинов. – М.: Машиностроение, 2004. – 736 с.

5.Сергиенко, А.Б. Цифровая обработка сигналов [Текст] / А.Б. Сергиенко. – СПб.: Питер, 2002. – 608 с.

6.Марпл, С.Л. мл. Цифровой спектральный анализ и его приложения [Текст] / С. Л. Марпл мл. – Москва: «Мир», 1990. – 571 с.

7.Абрамов, Г.В. Проектирование информационных систем / Г.В. Абрамов, И.Е. Медведкова, Л.А. Коробова // Учебное пособие : Воронеж, 2012.

8.Abramov, G.V. Information system for diagnosis of respiratory system diseases / G. V. Abramov, L. A. Korobova, A. L. Ivashin, I. A. Matytsina I.A. // Journal of Physics: Conference Series (см. в книгах). 2018. Т. 1015. С. 042036.

9.Коробова, Л.А. Программная реализация нечеткой модели распознавания звуковых сигналов / Л.А. Коробова, Т.В. Курченкова, И.А. Матыцина // Научные ведомости Белгородского государственного университета. Серия: Математика. Физика. 2016. № 13 (234). С. 174-178.

10.Абрамов, Г.В. Анализ и использование математических методов для распознавания звуковых сигналов / Г.В. Абрамов, Л.А. Коробова, А.Л. Ивашин, И.А. Матыцина // Вестник Воронежского государственного университета инженерных технологий. 2015. № 2 (64). С. 61-65.

11.Калугин, В.А. Обнаружение дефектов в технологических трубопроводах / В.А. Калугин, Л.А. Коробова // В сборнике: Моделирование энергоинформационных процессов. Сборник материалов VII национальной научнопрактической конференции с международным участием. 2019. С. 242-250.

12.Bukharin, S.V. The method of immersion the problem of comparing technical objects in an expert shell in the class of artificial intelligence algorithms / S.V Bukharin, A.V. Melnikov, S.N. Chernyaeva, L.A. Korobova // В сборнике: IOP Conference Series: Materials Science and Engineering International Conference on Materials. 2017. С. 012208.

АНОО ВО «Воронежский институт высоких технологий», Россия

86

УДК 004.415.2

Е.О. Долгих, О.В. Минакова

КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ СВОБОДНО РАСШИРЯЕМЫХ ПРОГРАММ ОБРАБОТКИ БИОМЕДИЦИНСКИХ ДАННЫХ

Не подлежит сомнению, что в настоящее время любое программное приложение, предназначенное для решений прикладной задачи, должно быть расширяемо. Так при разработке сначала реализуются основные функции систем, а потом дорабатываются остальные. Пользователь сначала осваивает базовый функционал приложения, а потом уже у него возникает потребность в дополнительных настройках и сервисах. Следует также отметить, что специалисты, не работающие в ИТ, консервативны по природе, они освоили одну программу и ее интерфейс им понятен и удобен, они не хотят обучатся работе с другой более совершенной программой, отрывая время от основной профессиональной деятельности. А время и технологии развиваются и «удобной» программе уже не хватает нового функционала.

В связи с этим была поставлена цель – проектирование программного комплекса для обработки экспериментальных данных в прикладной задаче, в частности обработки биомедицинский данных.

Прототипом разрабатываемого комплекса является BioStat [AnalystSoft Inc., www.analystsoft.com ]. Пакет BioStat – специализированный статистический пакет компании AnalystSoft. Основан на базе известного пакета StatPlus и включает в себя почти весь его функционал, в том числе регрессионный анализ, анализ выживаемости, дисперсионный анализ. Программа использует электронную таблицу, совместимую с Microsoft Excel как по формату данных, так и по интерфейсу, что делает процесс изучения программы легким и быстрым.

Достоинства BioStat:

–экспорт/импорт данных в MS Excel;

–требуемая память на жестком диске компьютера 32 MB;

–проверка правописания;

–совместимость с операционными системами Windows и Mac.

Несмотря на наличие больших программных систем таких как Statistica, BioStat, Statistical Analysis System, AtteStat, StatBase и тому подобные, в про-

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

При создании прототипа был решено ограничится следующими программными модулями: загрузки данных, расчета описательной статистики, по-

87

строения блоковых графиков и дисперсионного анализа. Другие методы анализа будут добавляться по запросу.

Для того, чтобы система была расширяема, эта возможность должна быть заложена в архитектуру приложения. К ним относятся – микроядерная [1] и микросервисная архитектура [2].

Микроядерная архитектура состоит из двух основных компонентов: основной системы (ядра) и модулей расширения (плагинов). Структура на рис. 1.

Рис. 1. Микроядерная архитектура программной системы

Ядро содержит минимум бизнес-логики, но управляет загрузкой, выгрузкой и запуском необходимых модулей дополнительного функционала. То есть плагины не связны друг с другом. Разные плагины для одного и того же приложения могут разрабатываться разными программистами, не зависимо друг от друга, что обеспечивает системе высокую гибкость и простоту в тестирующих испытаниях. Высокая степень переносимости обусловлена тем, что весь ма- шинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше изменений и все они логически сгруппированы вместе. Несмотря на выше перечисленные плюсы, у данной архитектуры есть и минусы. Такие как:

–большой объем оперативной памяти для работоспособности системы;

–большое количество программного кода для реализации сопряжения; зависимость производительности приложения от количества подключен-

ных и активных плагинов;

–временные затраты на поиск и исправление ошибок ввиду сложности механизма обмена данными между основной системой и дополнительными модулями;

–усложнение сопровождения по причине управления множеством различных процессов.

Микросервисная архитектура или архитектура микрослужб — это архитектура, при котором единое приложение строится как набор небольших серви-

88

сов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Структура микросервисной архитектуры представлена на рис. 2. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.

Поскольку каждый микросервис является отдельным проектом, то может быть разработан отдельной командой разработчиков, то есть над системой могут одновременно трудиться несколько десятков программистов. Микросервисная архитектура позволяет с легкостью масштабировать приложение для внедрения новой функции (развертывание каждого микросервиса происходит по отдельности), создается новый сервис, а если какой-то функцией никто не пользуется, то сервис просто отключается.

Очевидным недостатком этой архитектуры является необходимость передачи большого количества данных между микросервисами, а, как следствие, повышенная сложность разработки и тестирование таких систем.

На практике микросервисы часто используют в распределенных системах (Amazon, Netflix, Twitter), а микроядерную в настольных системах (операцион-

ная система Windows, Eclipse IDE).

Сравнив выше изложенные архитектуры, было решено использовать архитектуру микроядра в виду более простой, по сравнению с микросервисной архитектурой, разработкой, а также возможностью более быстрой тестируемостью программного продукта.

Рис. 2. Микросервисная архитектура

89