CC BY
18
DOI 10.36622/^т2022.18А008 УДК 004.4'22
РАЗРАБОТКА ПРОГРАММНЫХ ИНСТРУМЕНТОВ НА БАЗЕ РАСШИРЯEМЫХ ПЛАТФОРМ С ОТКРЫТЫМ ИСХОДНЫМ КОДОМ
О.В. Минакова, Н.В. Акамсина, О.В. Курипта Воронежский государственный технический университет, г. Воронеж, Россия
Аннотация: представлен анализ известных архитектурных подходов и моделей анализа архитектуры с целью быстрой разработки приложений на готовой технологической платформе. Выбранные методы были использованы для проектирования системы управления фондом оценочных средств как примера программного инструмента для профессиональной деятельности. Последовательность этапов разработки программной системы на основе архитектурного подхода детально проанализирована. Обоснован выбор распространённой технологической платформ Visual Studio Code с открытым исходным кодом и набором стандартных расширений. Для основной функциональности - редактирования текста и интероперабельности с LMS и необходимых перспектив - распространённость, удобство использования и модифицируемость, проведено архитектурное проектирование. Представлено описание реализации необходимых расширений, в частности, навигации по банку тестовых заданий. Проведенные исследования позволили предложить методологию быстрой разработки программных инструментов на базе расширяемых платформ на основе архитектурного подхода. Описание технологии представлено в работе для обсуждения. Поскольку в современных условиях необходимы быстрая разработка новых программных средств, исследования возможностей использования расширяемых платформ, стандартизация подходов к использованию открытого исходного кода, проектирование шаблонов жизненно важно. Возможные решения этих ключевых задач предложены в работе на примере специального программного обеспечения
Ключевые слова: разработка программ, gift-файл, микроядерная архитектура, реализация расширений, открытый исходный код
Введение
В любой профессиональной деятельности возникает необходимость в собственных программных инструментах, что влечет за собой инициализацию Н разработки программного обеспечения. Естественно, это процесс трудоемок и требует значительных затрат, и существует множество облегченных решений. В настоящее время большинство компаний разработчиков ПО превращают свои продукты в полноценную экосистему, имеющую различные возможности для расширения функциональности и конфигурирования под различные потребности пользователя. Модульное построение с открытыми прикладными интерфейсами (API), микроядерная и микросервисная архитектуры становятся стандартами разработки, направленными на непрерывную модификацию распространяемого ПО [1].
Согласно закону Лемана, эволюционирующие программы повышают свою сложность, что приводит к нарушению функционирования и ограничению использования. Поэтому альтернативой стратегии сопровождения становится конструирование программы по потреб-
© Минакова О.В., Акамсина Н.В., Курипта О.В., 2022
ности [2], когда есть легковесное ядро, к которому подключают только необходимые для данного сценария использования модули расширения. Опыт применения этого подхода для создания программного инструмента для профессиональной деятельности преподавателя представлен в данной работе.
Сравнение нашего опыта этой разработки с созданием других инструментов профессиональной деятельности с помощью собственного фреймворка [3] и полностью нативной разработки [4] позволяет предложить методологию быстрой разработки приложений на основе расширяемых программных платформ. Предложенная практика полезна для дальнейшего ее развития членами профессионального 1Т-сообщества и получения обратной связи при построении проблемно-ориентированных инструментов.
Цель работы - исследование методов создания инструментов профессиональной деятельности на базе расширяемых программных платформ с открытым исходным кодом на примере разработки редактора фонда оценочных средств (ФОС).
Задачи исследования:
- архитектурное проектирование и анализ практической реализации программных инструментов;
- анализ особенностей построения расширяемых программных платформ;
- представление методологии разработки программных систем на готовом ядре.
Постановка задачи
Основой для разработки программного обеспечения является техническое задание или спецификация, которые отражают пользовательские требования и являются контрактом между разработчиком и заказчиком. Современные технологии позволяют пользователям самим создавать собственные инструменты профессиональной деятельности, опираясь на расширяемые платформы либо репозитории открытого исходного кода. Но в таком случае при отсутствии опыта, профподготовки требуется надежное и простое руководство.
Его основной может стать архитектурная спецификация. Обычно деятельность по проектированию состоит из архитектурного и детального проектирования. В последнем этапе нет необходимости, поскольку предполагается использовать готовую технологическую платформу или кодовую базу. Следовательно, достаточно создать архитектурное представление.
История архитектурного подхода в разработке ПО начинается с конференции ICSE2000, когда была определена дорожная карта [5] исследований архитектуры. Ранее считалось, что «программные системы имеют множество структур, которые служат разным инженерным целям», и любая система изобреталась заново. Появление шаблонов проектирования GoF, а затем архитектурных стилей, позволило осуществлять формальный анализ существующих систем. Развитие принципов архитектурного анализа привело к выделению компромиссов архитектуры, увязывающих архитектурные решения и показатели качества [6]. Развитие и исследование этих методов привело к созданию архитектурных оценок [7] и техник документирования архитектуры [8].
Сейчас коммерчески успешные многоуровневые клиент-серверные и сервис-ориентированные архитектуры совместно с прикладными программными интерфейсами и языками спецификаций, а также полностью реализованными компонентами и даже подсистемами являются распространёнными примерами архитектурного подхода к разработке программного обеспечения. На их базе возникло множество фреймворков, позволяющих автоматизировать создание линеек программных
продуктов по тому или иному стандартному архитектурному стилю, с поддержкой сквозной модели жизненного цикла во множестве предметных областей.
Но зачастую хорошие архитектурные решения теряются из-за невозможности установить формальное соответствие с кодом. Известные модели архитектурных представлений облегчают понимание архитектуры, но не позволяют генерировать код. Наши исследования ставят целью определить возможности использовать распространённые и успешные методы анализа архитектур для синтеза программных решений.
Выбор метода архитектурного анализа
Модель представления архитектуры «4+1» [9] возникла из традиционной каскадной разработки, выраженной методологией Rational Unified Process. Четыре представления описывают архитектуру с разных точек зрения: логическое представление (например, объектная модель и поток обработки данных), представление процессов (например, аспекты параллелизма и синхронизации), физическое представление (схема программных уровней и функций в распределенной аппаратной среде) и представление для разработчиков, описывающее реализацию. Сценарии использования («+1») связывают все эти представления воедино. Такие модели максимально полно специфицируют систему и используются в классических методологиях.
Модель С4 [10] используется для документирования архитектуры программного обеспечения в легковесных методологиях. Идея состоит в том, чтобы использовать четыре различных уровня детализации (или масштабирования) для документирования архитектуры программного обеспечения.
На начальном уровне строится контекстная диаграмма, описывающая взаимодействия с внешними системами и пользователями. На следующем - контейнерная диаграмма, включающая независимые части приложения (контейнеры - это приложения, БД, сервисы). Далее с помощью диаграммы компонентов определяется взаимодействие компонентов внутри контейнера, затем на последнем уровне кода описывается реализация в виде диаграммы классов каждого программного компонента.
Этот подход был использован в [11], но обоснование многих технических решений находилось за рамками модели. То есть модель
С4 оказалась пригодной до уровня компонентов, но не достаточной для генерации кода, а также принятия решений о функциональности компонентов и необходимых характеристиках разрабатываемого программного средства.
Архитектурный подход к разработке помимо множества точек зрения и, соответственно, множества архитектурных представлений оперирует и ожидаемыми характеристиками качества архитектуры [12]. Используемое понятие - перспектива развития архитектуры, определяет, какое конкретное свойство качества будет достигнуто, предлагает набор проверенных действий и методов и описывает вероятные проблемы, с которыми может столкнуться разработчик. Диаграмма деятельности, отражающая этот подход, на рис. 1.
Рис. 1. Алгоритм применения перспектив для проектирования систем
Применение этого метода к практической задаче является предметом текущего исследования.
Практическое решение
Современные образовательные стандарты требуют создания оценочных материалов по каждой дисциплине или учебному модулю. Интерактивно поддерживают управление банком заданий современные LMS, которые имеют разнообразные средства создания учебного контента и предоставления обратной связи о результатах. Но зачастую при разработке самих тестовых вопросов и заданий быстрее и комфортнее пользоваться привычными текстовыми редакторами или облачными сервисами создания опросов типа Google Form.
При этом вне зависимости от предпочтения разработчика ФОС при редактировании заданий требуется постоянно экспортировать задания в LMS, а также определять и помечать проблемные вопросы при ответном импорте. Эти проблемы позволяют сформулировать основные требования к системе управления ФОС - редактирование текстовым редактором и ин-тероперабельность c LMS.
Контекстное представление (рис. 2) позволяет определить механизм взаимодействия со сторонними системами, а для подчиненных систем, к которым относится разрабатываемая -это дает предпосылки для построения модели данных. Простой механизм обмена - файл в простом и распространенном gift-формате был выбран.
Рис. 2. Контекстное представление управлением ФОС
Согласно структуре gift-файла, составлена иерархическая модель данных базы тестовых заданий, представленная на рис. 3. Каждое тестовое задание - это запись в специальной разметке. В файле содержится произвольное число подкатегорий, которые состоят из заданий различного вида.
Рис. 3. Модель данных ФОС
Ввиду этого в системе будет два потока управления - для тестового задания, включающего стандартные операции редактирования (рис. 4), и для всего набора, составляющего основной поток (рис. 5). Их определение позволило выявить требуемую дополнительную функциональность разрабатываемой системы.
Для быстрой разработки системы необходимо выбрать технологическую платформу.
Рис. 4. Поток управления тестовым заданием
Рис. 5. Поток управления ФОС
Помимо ключевой функциональности -редактирования текстовых файлов, руковод-
ствовались следующими принципами (перспективами):
- распространенность;
- расширяемость;
- открытый исходный код с возможностью переиспользования.
В данном случае под распространённостью понимается привычность интерфейса пользователя как функций по редактированию текста. На сегодняшний день наиболее привычным и массово используемым является интерфейс Microsoft Word, который кроме обычных функций редактирования и форматирования (в том числе и ускоренного, такого как автозамена и ввод автотекста), позволяет работать с таблицами и изображениями, поддерживает стили и шаблоны для ускоренного создания однотипных документов, имеет средства проверки орфографии и грамматики, множество настраиваемых панелей для выбора необходимых операций и режимов навигации.
Способность к расширению в современном ПО обеспечивается возможностью включения сторонних плагинов, наличием и доступностью интерфейсов прикладного программирования (API) для расширения. API — один из наиболее распространенных способов интеграции с технологической платформой. Поэтому общедоступный, открытый и документированный API позволяет широко изменять функциональность и качественные характеристики программного обеспечения.
Политика использования ПО, заключающаяся в доступности исходного кода, его добровольной поддержки сообществом разработчиков и разрешения его переиспользования есть основа для быстрой и надежной разработки ПО в собственных целях. Это принципиальный базис вне индустриальной разработки, быстрого конструирования собственного программного инструментария, а также потенциальная возможность для всех стартапов и инновационных прототипов.
На сегодняшний день многие распространённые программные системы поддерживают архитектуру расширений: браузеры, IDE, из них имеются и доступные под разными лицензиями решения. Выбранный редактор кода Visual Studio Code (VSC) для кроссплатфор-менной разработки веб- и облачных приложений отличается легковесным ядром. По необходимости оно может расширяться за счет имеющегося полноценного набора компонентов — инструментов разработчика ПО, включающего синтаксический анализатор, отладчик,
средства для работы с системами контроля версий, интеллектуальных подсказок и автодополнения кода IntelliSense. Архитектура VSC идеальный пример микроядерной архитектуры, задействующей в качестве плагинов другие полнофункциональные средства - текстовый редактор moñaco, инструмент контроля версий git, среду выполнения chromium.
Анализ marketplace.visualstudio.com и доступных репозиториев ПО показал, что имеются плагины для решения задач по проверке синтаксиса GIFT Format и интерактивному отображению задания GIFT Format Preview. Разработка плагинов для покрытия остальной требуемой функциональности была выполнена самостоятельно [13, 14].
Было разработано четыре программных модуля расширения - навигации по банку тестовых заданий, слияния двух файлов, контроля версий и генерации задания по шаблону. На рис. 6 представлена проектная детализация расширения навигации по банку тестовых заданий. Компонент-класс Treeltem API VSC используется для представления модели данных (рис. 3) в виде иерархического списка, класс управления NavigationProvider реализует логику загрузки и синхронизации с редактируемым текстом, главный класс плагина extension отвечает за связывание с платформой и оперативное обновление.
Рис. 6. Представление уровня кода модуля навигации
Аналогичным образом реализованы другие плагины. Фактически написание кода требовалось только для выполнения преобразований gift-файла во внутреннюю структуру данных и специфики взаимодействия с API.
Архитектура разработанной системы управления ФОС представлена на рис. 7, серым выделены заимствованные плагины, белым — написанные конкретно для данной системы.
Рис. 7. Структура системы управления ФОС
Для удобства установки все плагины были объединены в интегратор, который позволяет загружать сразу весь набор в установленный VSC [15].
Методология быстрой разработки приложений на основе расширяемых программных платформ
Представленное практическое решение, а также наш опыт по созданию других программных инструментов для решения профессиональных задач позволяет определить основные шаги и рекомендации по разработке.
Ключевая цель подобных инструментов -это интеграция с основными профессиональными системами, поэтому необходимо определить механизм и формат обмена данными. Для этого необходимо построение контекстной диаграммы. Наиболее универсальным, легко трансформируемым является файл и его формат, альтернатива - АР1, в любом случае можно говорить о входном и выходном интерфейсах разрабатываемой системы.
На следующем этапе детализируется сам процесс обработки с целью выявления необходимого функционала (как преобразуются и изменяются данные из входного интерфейса, чтобы достигнуть результата). Как правило, наиболее эффективно построение диаграммы
потока данных или функциональной декомпозиции для выявления необходимой функциональности. По наибольшему числу функций в сочетании с выделенными интерфейсами выбирается класс технологических платформ.
Критериями выбора технологической платформы являются предпочтение пользователя, расширяемость, доступность исходного кода либо наличие экосистемы, а также возможные ограничения, связанные с техническим и программным окружением операционного применения.
После выбора технологической платформы остается ее развернуть, установить функциональные плагины и реализовать необходимые расширения при необходимости.
Предлагаемая методология представлена на рис. 8.
Рис. 8. Процесс быстрой разработки приложений на основе расширяемых программных платформ
Зрелые инженерные дисциплины характеризуются справочниками и наличием различных справочных материалов, которые предоставляют инженерам систематизированное знание области. По аналогии с каталогизацией архитектурных паттернов следует шаблонизировать и детали проектирования. Так CRUD (акроним операций - создание (create), чтение (read), модификация (update), удаление (delete)), описывающий четыре основные операции с базами данных и REST API, может использоваться для определения минимального набора функций с любыми хранимыми вычислительными сущностями (файлы, записи об элементах предметной области, сообщения). Если сущности характеризуются состоянием, то необходимо управление версиями. Для удобства работы с множеством сущностей необходим механизм
навигации, маркирования или выделения, а также проверок на возможные ошибки. Такие решения при кажущейся простоте должны быть отслеживаемыми и проверяемыми.
Пример шаблона для определения функциональности на основе анализа имеющихся плагинов и основного функционала VSC в стиле диаграмм причинно-следственных связей представлен на рис. 9.
Проведенные исследования показывают, что необходима разработка нормативов для анализа реализованных архитектур и оценки существующих программных проектов, чтобы прогнозировать свойства их реализации.
Рис. 9. Карта для определения функциональности ПО
Разрабатывается архитектурная поддержка для систем, которые динамически адаптируются к изменениям в ресурсах, ожиданиям и предпочтениям каждого пользователя. По мере того, как вычисления становятся повсеместными и интегрируются в повседневные устройства, базовые ресурсы, такие как пропускная способность и информационные ресурсы, данные о местоположении, изменяются динамически. Более того, у каждого отдельного пользователя разные потребности, которые меняются со временем. Разработка архитектур, которые могут динамически предвидеть эти изменения и реагировать на них, поможет максимизировать выгоду, которую может получить каждый пользователь. Для достижения этого потребуются не только адаптивные архитектуры, но и спецификации компонентов, отражающие изменчивость потребностей пользователей, а также оценки внутренних свойств компонента.
Выводы
1. В сложных экономических условиях, когда требуется воспроизведение различного рода программного обеспечения, использование расширяемых программных платформ с открытым исходным кодом наиболее эффективно. Это позволит ускорить процесс разработки при наименьших затратах.
2. Представленные практические результаты разработки системы управления фондом оценочных средств демонстрируют эффективность предлагаемой методологии быстрой разработки и позволяют предложить использовать ее как основу для разработки стандартного фреймворка.
3. Следует детально исследовать возможности расширяемых программных платформ с открытым исходным кодом для составления каталога перспектив - шаблонов выбора решения по известным характеристикам качества и контекста использования.
Литература
1. Форд Н., Парсонс Р., Куа П. Эволюционная архитектура. Поддержка непрерывных изменений. СПб.: Питер, 2019. - 272 с.
2. Wolfinger R. Plug-in architecture and design guidelines for customizable enterprise applications //Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications. 2008. р. 893894.
3. Минакова О.В., Трубников И.В., Курипта О.В. Построение генератора программного кода для решения инженерных задач //Вестник Воронежского государственного технического университета. 2020. Т. 16. №. 3. С. 1419.
4. Десятирикова Е.Н., Минакова О.В. Программное обеспечение мониторинга комплекса проектов студентов инженерных специальностей //Всероссийская научная конференция по проблемам управления в технических системах. СПб.: Санкт-Петербургский государственный электротехнический университет ЛЭТИ им. В.И. Ульянова (Ленина), 2021. Т. 1. С. 190-193.
5. Garlan D. Software architecture: a roadmap. The Future of Software Engineering 2000, Proceedings 22nd International Conference on Software Engineering, ACM Press 2000.
6. Experience with Performing Architecture Tradeoff Analysis/ R. Kazman, M. Barbacci, at all// Proc ICSE '99. 1999. рр. 54-63.
7. Clements P., Kazman R., Klein M. Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2001
8. Documenting Software Architectures: Views and Beyond/ P. Clements, F. Bachmann, at all. Addison Wesley, 2002
9. Kruchten P. The 4+1 View Model of Software Architecture. IEEE Software (Nov. 1995): 42-50
10. Brown S. The C4 model for software architecture //The C4 Model, verkkosivu. URL: https://www. infoq. com/articles/C4-architecture-model (дата проверки 07.06.2022). 2018.
11. Бойцов Б.В., Минакова О.В., Поцебнева И.В. Архитектурный подход к созданию программного инструментария для работы с оценочными средствами информационной системы по параметрам качества //Качество и жизнь. 2022. №(1). С. 23-30.
12. Rozanski N., Woods E. Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley, 2012.
13. А.с. №2022619134. Модуль управления версиями тестовых заданий gift-формата для Visual Studio Code/ О.В. Минакова, К.К. Петров. 19.05.2022
14. А.с. №2022619134. Модуль навигации по банку тестовых заданий для Visual Studio Code/ Н.В. Акамсина, К.К. Петров. 19.05.2022
15. Инструментарий по работе с банком тестовых заданий. URL: https://github.com/olgmina/MentorTools/tree/ main/ BankTest (дата проверки 07.06.2022) - 2022
Поступила 16.06.2022; принята к публикации 17.08.2022 Информация об авторах
Минакова Ольга Владимировна - канд. техн. наук, доцент, Воронежский государственный технический университет (394006, Россия, г. Воронеж, ул. 20-летия Октября, 84), e-mail: olgmina@gmail.com
Акамсина Надежда Валериевна - канд. техн. наук, доцент, Воронежский государственный технический университет (394006, Россия, г. Воронеж, ул. 20-летия Октября, 84), e-mail: akamsina@vgasu.vrn.ru
Курипта Оксана Валериевна - канд. техн. наук, доцент, Воронежский государственный технический университет (394006, Россия, г. Воронеж, ул. 20-летия Октября, 84), e-mail: kuripta-okcana@mail.ru
DEVELOPMENT OF SOFTWARE TOOLS BASED ON EXPANDABLE OPEN SOURCE
PLATFORMS
O.V. Minakova, N.V. Akamsina, O.V. Kuripta
Voronezh State Technical University, Voronezh, Russia
Abstract: the article presents an analysis of well-known architectural approaches and architecture analysis models for the purpose of rapid development of applications on a ready-made technological platform. We used the selected methods to design a management system for the fund of appraisal funds, as an example of a software tool for professional activities. We ana-
62
lyzed in detail the sequence of stages in the development of a software system based on the architectural approach. For the implementation, we justified the choice of the microkernel architecture of the widespread technological platform Visual Studio Code with open source code and a set of standard extensions. We designed the architecture for the core functionality - text editing and interoperability with LMS and perspectives - prevalence, usability and modifiability. We present a description of the implementation of the necessary extensions, in particular, navigation through the bank of test items. The conducted research allowed us to propose a methodology for the rapid development of software tools based on extensible platforms based on an architectural approach. We present the description of the technology in the paper for discussion. Since the rapid development of new software tools is necessary in modern conditions, research on the possibilities of using extensible platforms, standardizing approaches to using open source code, and designing patterns is vital. We proposed possible solutions to these key tasks in the work on the example of special software tools
Key words: software development, gift-file, microkernel architecture, implementation of extensions, open source
References
1. Ford N., Parsons R., Kua P. "Building evolutionary architectures: support constant change", O'Reilly Media, Inc., 2019, 272
P.
2. Wolfinger R. "Plug-in architecture and design guidelines for customizable enterprise applications", Companion to the 23rd ACM SIGPLAN Conf. on Object-oriented Programming Systems Languages and Applications, 2008, pp. 893-894.
3. Trubnikov I.V., Minakova O.V., Kuripta O.V. "Building a program code generator for solving engineering problems", 2019 Int. Multi-Conf. on Industrial Engineering and Modern Technologies (FarEastCon). IEEE, 2019.
4. Desyatirikova E.N., Minakova O.V. "Monitoring software for project based learning tasks", 2021IVInt. Conf. on Control in Technical Systems (CTS). IEEE, 2021, pp. 154-157.
5. Garlan D. "Software architecture: a roadmap", Proc. 22ndInt.Conf. on Software Engineering: The Future of Software Engineering 2000, ACM Press 2000.
6. Kazman R., Barbacci M. et al. "Experience with performing architecture tradeoff analysis", Proc ICSE '99, May 1999, pp.
54-63.
7. Clements P., Kazman R., Klein M. "Evaluating Software Architectures: Methods and Case Studies", Addison Wesley, 2001
8. Clements P., Bachmann F. et al. "Documenting Software Architectures: Views and Beyond", Addison Wesley, 2002
9. Kruchten P. "The 4+1 View Model of Software Architecture", IEEE Software, Nov. 1995, pp. 42-50
10. Brown S. "The C4 model for software architecture", The C4 Model, available at: https://www. infoq. com/articles/C4-architecture-model, 2018. (date of access 07.06.2022)
11. Boytsov B.V., Minakova O.V., Potsebneva I.V. "An architectural approach to the creation of software tools for working with evaluation tools of an information system in terms of quality parameters", Quality and Life, 2022, no. 1, pp. 23-30.
12. Rozanski N., Woods E. "Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives", Addison Wesley, 2012.
13. Minakova O.V., Petrov K.K. "Version control module for gift-format test tasks for Visual Studio Code" ("Modul' uprav-leniya versiyami testovykh zadaniy gift-formata dlya Visual Studio Code"), Certificate of state registration of the computer program No. 2022619134 dated May 19, 2022
14. Akamsina N.V., Petrov K.K. "Test bank navigation module for Visual Studio Code" ("Modul' navigatsii po banku tes-tovykh zadaniy dlya Visual Studio Code"), Certificate of state registration of the computer program No. 2022619134 dated May 19, 2022.
15. Test bank toolkit, available at: https://github.com/olgmina/MentorTools/tree/ main/ BankTest (date of access 06/07/2022)
Submitted 16.06.2022; revised 17.08.2022 Information about the authors
Ol'ga V. Minakova, Cand. Sc. (Technical), Associate Professor, Voronezh State Technical University (84 20-letiya Oktyabrya Str., Voronezh 394006, Russia), e-mail: olgmina@gmail.com
Nadezhda V. Akamsina, Cand. Sc. (Technical), Associate Professor, Voronezh State Technical University (84 20-letiya Oktyabrya Str., Voronezh 394006, Russia), e-mail: akamsina@vgasu.vrn.ru
Oksana V. Kuripta, Cand. Sc. (Technical), Associate Professor, Voronezh State Technical University (84 20-letiya Oktyabrya Str., Voronezh 394006, Russia), e-mail: kuripta-okcana@mail.ru
