Паттерное проектирование применительно к разработке технологического программного обеспечения Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.414.28

ПАТТЕРНОЕ ПРОЕКТИРОВАНИЕ ПРИМЕНИТЕЛЬНО К РАЗРАБОТКЕ ТЕХНОЛОГИЧЕСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

© Е.Ю. Андиева1, А.Ю. Воробьёв2

Омский государственный технический университет, 644050, Россия, г. Омск, пр. Мира, 11.

Рассматривается практика реализации паттернов проектирования как эффективного архитектурного решения для упрощения и унификации разработки технологического программного обеспечения, предназначенного для тестирования радиоприемных устройств и комплексов. Найденные архитектурные решения могут использоваться при разработке программного обеспечения для автоматизированного контроля параметров изделий, в котором необходимо организовать структуру испытаний и их выполнение, а также управлять устройствами. Ил. 5. Библиогр. 9 назв.

Ключевые слова: эффективность разработки программного обеспечения; объектно -ориентированный анализ и проектирование; архитектурные решения; паттерны проектирования; технологическое программное обеспечение; радиоприемные устройства и комплексы.

DESIGN PATTERNS AS APPLIED TO TECHNOLOGICAL SOFTWARE DEVELOPMENT E.Yu. Andieva, A.Yu. Vorobiev

Omsk State Technical University, 11 Mira pr., Omsk, 644050, Russia.

The article deals with the implementation practice of design patterns as an efficient architectural solution to simplify and unify the development of technological software designed for testing radio receiving equipment and complexes. The proposed architectural solutions can be used when developing software for the automated control of product parameters, which requires the organization of the structure of tests and their implementation, as well as equipment control. 5 figures. 9 sources.

Keywords: efficiency of software development; object-oriented analysis and design; architectural solutions; design patterns; technological software; radio receiving equipment and complexes.

Введение

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

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

Для осуществления контроля качества выпускаемой продукции на предприятии разработана система контроля качества. Контроль проходят все комплекту-

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

Таким образом, в связи с активной разработкой новых изделий и модификацией существующих остро стоит задача существенного повышения эффективности разработки технологического ПО технической диагностики радиоприемных устройств и комплексов. Актуальности тематики работы подтверждается разработчиками аналогичного ПО [7].

Постановка задачи

Понятие паттернов на сегодняшний день широко обсуждается [8], тем более применительно к разработке ПО в ключе повышения ее эффективности [4-6]. Поэтому логично было рассмотреть повторное использование выделенных конструктивных элементов архитектуры применительно к типу разрабатываемого ПО.

Объектом технической диагностики на предприятии ОАО «ОНИИП» являются многоканальные радиоприемные устройства (МРПУ) и комплексы с открытой

1Андиева Елена Юрьевна, кандидат технических наук, доцент кафедры математических методов и информационных технологий в экономике, тел.: 89059223333, e-mail: 55_elena@mail.ru

Andieva Elena, Candidate of technical sciences, Associate Professor of the Department of Mathematical Methods and Information Technologies in Economy, tel.: 89059223333, e-mail: 55_elena@mail.ru

2Воробьёв Алексей Юрьевич, инженер-программист 2-й категории, аспирант, тел.: 89236850940, e-mail: flyenj@gmail.com Vorobiev Aleksei, Second Category Software Engineer, Postgraduate, tel.: 89236850940, e-mail: flyenj@gmail.com

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

Испытания изделий делятся на несколько типов: приемосдаточные, предъявительские, отбраковочные и периодические. Основными требованиями являются скорость разработки, надежность и достоверность получаемых результатов. Следует учитывать, что сигнал поступает в реальном времени при скорости 1500 пакетов с секунду с одного канала и технологическое ПО «обязано проводить» большое количество вычислений в реальном времени.

Каждое такое изделие состоит из принимающих блоков (преселекторов) и блока, отвечающего за цифровую обработку сигнала (ЦОСа). У каждого ЦОСа имеется цифровой выход (как правило, Ethernet) для соединения МРПУ с компьютером. ЦОС внутри себя имеет базу управляющую информацией (базу MIB), которая управляется через простой протокол сетевого управления (SNMP1). В данной базе существует возможность изменять параметры МРПУ, а также считывать некоторые показатели. Выход сигналов в цифровой форме происходит через сетевой протокол RTP. Частота дискретизации МРПУ может быть как 48 кГц, так и 96 кГц.

Таким образом, особенностью является тот факт, что изделия бывают составлены из самых разных конфигураций. У них могут присутствовать аналоговые, а также цифровые выходы. Изделие может представлять собой комплекс, состоящий из нескольких таких изделий. В состав рабочего места помимо генераторов сигнала могут входить анализаторы спектра, цепей, аналоговые коммутаторы, осциллографы, демодуляторы, в том числе программные, и другие устройства. Так как управление изделиями осуществляется, как правило, по SNMP, что сводится к манипуляции переменными, представляющими собой цифровые последовательности с разделителем в виде точки, для таких устройств невозможно однозначно определить количество каналов, аттенюаторов и других характеристик. В связи с этим отсутствует возможность автоматически генерировать интерфейс, подстраивать ПО и алгоритмы проверок под конфигурацию конкретного рабочего места.

Следовательно, архитектурные конструкции должны представлять собой решение, не зависящее от вышеуказанных факторов. Таким образом, предметом исследования являются архитектурные решения, которые позволят существенно повысить эффективность разработки технологического ПО для проведения предъявительских, приемосдаточных, отбраковочных и периодических испытаний МРПУ.

Решение

Для проектирования архитектуры использован ООD , а если быть точнее, - технология прецедентно-

ориентированного проектирования [2; 4]. Прецедентно-ориентированное проектирование вписывается в современную концепцию SOA3 [2]. Интегрально, учитывая рекомендации перечисленных подходов, была разработана UCM4, на основании анализа которой и были определены основные функциональные с выделением пользовательских требования, которые в терминах проектирования далее следует транслировать на архитектурные решения. Разработка программ согласно SOA позволяет осуществлять унификацию требований и по возможности выделять конструктивные элементы для их эффективного повторного использования. В рамках OOD наиболее естественным является в качестве нотации проектирования, иначе моделирования ПО, выбор UML [4; 9]. Этот же аспект определил выбор CASE-средства IBM Rational Rose Enterprise Edition 7.0, которое реализует стандарт UML® 2.1. В данной предметной области уже были рассмотрены варианты похожих подходов, но в более общем виде и в отличном приложении [1; 3]. Далее изложена практика адаптации и реализации обозначенных аспектов, что позволит непосредственно использовать предложенное решение.

На первом этапе выявления и формализации высокоуровневых функциональных требований разработана концептуальная диаграмма бизнес-прецедентов (рис. 1). Диаграмма отражает следующее представление в нотации UML: актеру-оператору для осуществления автоматизированного контроля параметров необходимо дистанционно управлять изделием и обрабатывать принимаемые сигналы; для более точного контроля, а также исследования необходим ручной режим; актерами также являются изделия и вспомогательные устройства - генераторы, анализаторы, демодуляторы и т.д. Выход сигналов в цифровой форме осуществляется через RTP-протокол, а в аналоговой -через модуль аналоговых выходов. Вспомогательные устройства могут управляться через TCP или по USB.

На основании диаграммы на концептуальном уровне выявлены следующие минимальные функциональные требования:

- обеспечение работы в нескольких режимах: ручном, автоматическом и полуавтоматическом;

- выдача протокола измерений в виде PDF-документа после завершения проверок, форма которого уточняется.

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

- в ручном режиме должна быть предусмотрена возможность управления приборами, проведения измерения и управления изделием;

- должна быть предусмотрена возможность занесения измеренных параметров в таблицу результатов

1 SNMP (англ.Simple Network Management Protocol - простой протокол сетевого управления) - стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур UDP/TCP.

2 OOD (англ. Object-Oriented Design) - объектно-ориентированный^одход^^^^^^^^^^^^^^^^^^^

SOA (англ. Service-oriented Architecture) - сервисно-ориентированная архитектура.

4 UCM (англ. Use Case View Model) - модель с точки зрения прецедентов.

5 UML (англ. Unified Modeling Language) - унифицированный ^зык^оделирования^^^^^^^^^^^^^^^^^^^^^

Рис. 1. Концептуальная диаграмма бизнес-прецедентов с отражением в системных прецедентах

и в протокол;

- производить проверку параметров необходимо по заранее определенному алгоритму;

- при автоматической проверке параметров происходит автоматическое управление изделием, смена режима работы приборов, проведение измерений;

- результаты проверки заносятся в протокол автоматически;

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

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

При более детальном проектировании архитектуры следует выделить конструкции, которые можно использовать повторно для реализации заявленных требований в приложениях для испытаний нескольких аналогичных изделий. Нетрудно заметить целесообразность такого выделения бизнес-логики приложения в отдельную модель данных предметной области в соответствии с общим представлением. Тем более «отделение представления от модели - один из основополагающих принципов, на котором держится все проектирование программного обеспечения, и пренебрегать им можно только тогда, когда речь идет о совсем простых системах, в которых модель вообще не имеет какого-либо реального поведения. Как только в приложении появляется невизуализированная логика, разделение становится крайне необходимым» [6].

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

Использованный в качестве организации архитектуры испытаний программы паттерн Model-View-СоМгоНег (рус. модель-представление-контроллер)

предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер таким образом, что модификация каждого компонента может осуществляться независимо [5; 6]. Модель предоставляет данные предметной области представлению и реагирует на команды контроллера, изменяя свое состояние. Представление отвечает за отображение данных предметной области (модели) пользователю, реагируя на изменения модели. Контроллер интерпретирует действия пользователя, оповещая модель о необходимости изменений. Таким образом, представление и контроллер зависят от модели, причем модель не зависит ни от представления, ни от контроллера.

Для обозначения классов, относящихся к испытаниям, было выбрано слово Challenge, чтобы не занимать Test, используемое в названии классов для модульного тестирования. Классы, относящиеся к Challenge, имеют следующие значения:

- ChallengeBean - контроллер, а также готовый компонент испытания, включающий в себя представление, модель, протокол и информацию об испытании. Основное назначение - предоставлять полное управление испытанием и скрывать особенности реализации;

- ChallengeProtocol - генерирует протокол с результатами испытания;

- ChallengeInfo - хранит информацию об испытании, которая записывается при разработке или запрашивается из БД;

- ChallengeView - представление испытания, содержащее в себе таблицу результатов;

- ChallengeModel - модель испытания, которая содержит в себе данные, необходимые для выполнения испытания, алгоритм и результаты испытания. Следует отметить, что модель также используется для инициализации представления.

Пример диаграммы классов, отражающей реализацию, представлен на рис. 2.

Рис. 2. Реализация паттерна MVC

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

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

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

Другими словами, необходимо выделить паттерн проектирования, определяющий алгоритмы и способы реализации взаимодействия различных объектов и классов - поведенческий паттерн (англ. Behavioral pattern). Основным требованием к паттерну является наличие возможности проводить испытания независимо друг от друга. Данное требование выполняется для паттерна Mediator (рус. посредник). Mediator определяет объект, инкапсулирующий взаимодействие множества объектов. Паттерн делает систему слабо

связанной, избавляя объекты от необходимости ссылаться друг на друга, что позволяет изменять взаимодействие между ними независимо [5; 6]. Пример реализации паттерна представлен на рис. 3.

Ввиду необходимости обработки возникающих ошибок и оповещения о ходе выполнения испытаний был создан интерфейс для подписчиков, а также метод в классе ChallengeExecutor для их регистрации. С помощью данного механизма можно оповещать всех классов-подписчиков о ходе выполнения испытания. Чтобы при выполнении испытаний не блокировался интерфейс пользователя, необходимо запускать их выполнение в отдельном потоке. Для реализации можно унаследовать ChallengeExecutor от класса Thread и переопределить метод Run.

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

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

_Chcllenge&BQLter_

^>SLtosa1befB : UstflCh^lengaBcaJcrSLtosaiber]

n_rrï rx^Eteen : Chä I епдаВэеп ^¡rterrLpted : Bod eeri = fei se ^beansTcBeaiie : UstfChsllerigeBsen]

^reg sterSJDScri bert )

^ncö lî&fâoJi craäe( )

rcti fyNeAChsi I ergeGLtorrittecK ) vjrterrL|3t()

^adcBssnsTc&eoLteO

x

О

IChallengeB<BaicrS_b6aiber

^crBrotRecevett) ^cr&eoJi onasbsChsrgedO I erpsQJxrittedC )

fvferqqrui @Di€ntcte

P-bicvad n_n( ){ irterrujted =fel se;

1er (Лзе^эсОтаН ergeEtean besn : ЬеапзТс&еаЛе) { if 0 rterrupted) { fcreä<;

>

inrnin<£Etean=besn; if (! rurri n^fearuchecW^eqJ remarts( )) { гс^^Отсг('НЬнфт^ра^яре1бо-его места нб ^ исгыта-ин!"

' У^пНеабхщ^лэя кк><^и1ра_ин:>пм + n_rri rd=tesn.gd:lrifb( >gäF^qJ remerts () ■+■

"ТтГ^эсв^эьте соед^нэ-ме cдэн--ь^л/lyIтpa/cгEEЛA'1!,,)¡ breä<;

}

ncti1iB^alicn9^e(trueï

nctifjNa/vCbEl leng^Lbrnitted(ruTi п^эеп);

1ry{

rurri ngBsar sfert( );

> cäch (Exœçtian e) { e. pi rt9acKTraœ( );

гей iy=rrcr(e .gäJVfessageQ J breä<;

>

rurnin^9anoeäieRTDtood(fel se);

>

ndi fj&ecüi onGste(fel s eï

Рис. 3. Реализация паттерна Mediator

SnmpDevice Receiver

^address : String ^readCommunity : String ^►write Corn in unity : String ^►«final» device : SnmpDevice ^¡►«final» channels : List[ReceiverChannel] ^►«final» attenuators : List[ReceiverAttenuators] ^¡►serialNumber: String

^getlntegerfoid : String) : int ^getString(oid : String) : String ^getlpAddress(oid : String) : String ^getAddresst) : String ^getReadCommunityQ : String ^getWriteCommunityO : String ^setlntegerfoid : String, value : int) : void ^setString(oid : String, value : String) : void ^setlpAddress(oid : String, value : String) : void ^setAddress(address : String) : void ^setReadCornmunityfvalue : String) : void ^setWriteCommunity(value : String) : void

^setDefaultStateQ : void ^resetAttenuatorsQ : void ^turnExternalOscillator(state : boolean) : void ^bist: Map[String, String]!) ^setFrequencyAdjustment(value : int) : void ^opnameQ ^getAttenuatorByNurnberfn : int) : ReceiverAttenuator ^getChannelByNumber(n : int) : ReceiverChannel

V V

ReceiverChannel ReceiverAttenuator

^getEnableQ: boolean *getFrequency() : int ^getPassbandQ : int ^getPortQ : int ^setEnable(state : boolean) : void ^setFrequencyff: int) : void ^setPassband(passband : int) : void ^setPort(poit: int) : void ^getLevell) : int ^setLevel(n : int) : void

Рис. 4. Пример организации управления устройствами

Рисунок показывает разделение обязанностей в управлении устройствами. Класс SnmpDevice отвечает за низкоуровневую работу по SNMP. Класс Receiver предоставляет высокоуровневый интерфейс для управления изделием. Такая конструкция масштабируема. Можно добавлять управление другими устройствами, например аналоговым коммутатором, не ме-

няя при этом реализации управления по SNMP. Аналогично можно создавать реализации для других протоколов.

Для реализации, учитывая основные соображения, - максимальную скорость разработки и необходимость больших вычислений в реальном времени -были проанализированы языки высокого уровня Java,

Рис. 5. Пример интерфейса пользователя технологического ПО

Python, Ruby, Python, а также низкоуровневые языки, такие как C/C++. Хорошим кандидатом может являться язык C# на платформе .NET, который имеет динамический компилятор и развитые средства для разработки настольных приложений, но тогда выполнение программы будет возможно только на операционной системе Windows. Для определения, подходит ли платформа Java для разработки технологического ПО данного типа, был проведен эксперимент на возможность выполнения вычисления спектра сигнала в реальном времени. Достичь положительных результатов решения проблемы с периодическим пропаданием пакетов позволило отбрасывание той «порции», в которой был потерян хоть один пакет.

На рис. 5 представлен пример интерфейса пользователя технологического ПО. Стоит отметить, что такой интерфейс интуитивно понятен и не содержит лишних элементов. Вверху у нас есть возможность переключаться со списка испытаний (автоматического режима) на управление устройствами (ручной режим).

Разделение бизнес-логики и представления позволяет легко добавлять новые испытания или делать композицию из существующих.

Заключение

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

С использованием рассмотренных предложений было разработано технологическое ПО для четырех МРПУ, имеющих разные характеристики и набор испытаний.

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

Статья поступила 22.10.2014 г.

Библиографический список

1. Березкин А.В., Филиппов А.С. Методика синтеза тестов аппаратуры по спецификациям на языке им^ // Информационно-управляющие системы. 2010. № 5. С. 25-30.

2. Гик Ю. Л. Анализ методологий сервисно-ориентированной архитектуры (СОА) // Программная инженерия. 2013. № 7. С. 16-24.

3. Ершов Б.В., Прохоров П.В. Современные концепции построения систем управления узлами радиосвязи // Техника радиосвязи. 2009. № 14. С. 78-87.

4. Крэг Л. Применение им^ 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. М.: Вильямс, 2013. 736 с.

5. Паттерны проектирования / Эр. Фримен, Эл. Фримен, К. Сьерра, Б. Бейте / пер. с англ. СПб.: Питер, 2012. 656 с.

6. Приемы объектно-ориентированного проектирования.

Паттерны проектирования / Г. Эрих, Х. Ричард, Д. Ральф, В. Джон / пер. с англ. СПб.: Питер, 2001. 366 с.

7. Программно-аппаратные средства контроля / А.В. Павлик, В.А. Дергачев, А.С. Савельев, А.Н. Аникин, М.В. Цеховской // Современные научные исследования и инновации. 2013. № 7 [Электронный ресурс]. URL: http://web.snauka.ru /issues/2013/07/25508 (5 авг. 2014).

8. Тепляков С.В. Шаблоны проектирования. История успеха // RSDN Magazine - 2010. № 2 [Электронный ресурс]. URL: http://rsdn.ru/article/pattems/PattemsSuccessStory.Xml (8 марта 2014).

9. Unified Modeling Language™ (UML®) Resource Page [Электронный ресурс]. URL: http://www.uml.org/#UML2.0 (10 дек. 2013).