Архитектурное решение при построении компонентной модели пользовательской части корпоративных систем
|
Введение 3
1 Анализ существующих архитектурных решений 8
1.1 Анализ научных работ, связанных с монолитным подходом 8
1.2 Анализ научных работ, связанных с модульным подходом 11
1.3 Анализ научных работа, связанных с микросервисным подходом 16
2 Формулирование компонентной модели пользовательского интерфейса системы 24
2.1 Описание обнаруженных проблем и формулирование требований 24
2.2 Суть компонентной модели пользовательского интерфейса системы, её терминология 26
2.3 Теоретическое описание компонентной модели пользовательского интерфейса системы 30
2.4 Взаимодействие микросервисов и компонентов 35
3 Реализация компонентной модели пользовательского интерфейса системы 37
3.1 Описание технологий реализации модели 37
3.2 Процесс реализации компонентной модели 38
4 Доказательство эффективности компонентной модели пользовательской части системы 46
4.1 Экономические показатели эффективности работы разработчиков 46
4.2 Доказательство эффективности компонентной модели 50
4.3 Тестирование компонентной модели 54
Заключение 60
Список используемой литературы 66
1 Анализ существующих архитектурных решений 8
1.1 Анализ научных работ, связанных с монолитным подходом 8
1.2 Анализ научных работ, связанных с модульным подходом 11
1.3 Анализ научных работа, связанных с микросервисным подходом 16
2 Формулирование компонентной модели пользовательского интерфейса системы 24
2.1 Описание обнаруженных проблем и формулирование требований 24
2.2 Суть компонентной модели пользовательского интерфейса системы, её терминология 26
2.3 Теоретическое описание компонентной модели пользовательского интерфейса системы 30
2.4 Взаимодействие микросервисов и компонентов 35
3 Реализация компонентной модели пользовательского интерфейса системы 37
3.1 Описание технологий реализации модели 37
3.2 Процесс реализации компонентной модели 38
4 Доказательство эффективности компонентной модели пользовательской части системы 46
4.1 Экономические показатели эффективности работы разработчиков 46
4.2 Доказательство эффективности компонентной модели 50
4.3 Тестирование компонентной модели 54
Заключение 60
Список используемой литературы 66
Первоначально все системы строились без каких-либо архитектурных принципов, множество строк следовали друг за другом, без наследований, классовых зависимостей и других возможностей языков программирования. С течением времени, они стремительно эволюционировали, стали увеличивать функциональность, расширяться. Схемы базы данных, интерфейсы, структура, архитектура программного кода и технологии разработки, реализующиеся и модернизирующиеся с их помощью, сильно изменились, системы стали распределёнными. Таким образом, без грамотно подобранной архитектуры уже не получается обходиться.
Архитектурой системы называют логическую структуру, описывающую отдельные компоненты, их свойства и связи как единую систему. Грамотно выбранная архитектура позволит реализовывать и поддерживать системы более простым и эффективным способом, их станет легче расширять и изменять, а также тестировать, отлаживать и понимать разработчикам. Архитектурный подход будет осуществлять выбор структурных элементов, их интерфейсы, а также взаимодействие между собой.
Существующие архитектурные решения хороши в применении, так, например, монолитный подход требует наименьших затрат на начальных этапах; модульный подход дает возможность реализовывать более сложные системы или приложения, которые состоят из множества различных модулей; микросервисный подход позволит создавать отказоустойчивые системы, которые легко можно расширять, не ориентируясь на конкретную платформу. Однако научная проблема заключается в том, что архитектурные решения дублирует некоторую функциональность, что приводит к повторному написанию кода, то есть потери времени и нерациональному использованию ресурсов команды, а следовательно, и компании.
Целью исследования является разработка компонентной модели, направленной на сокращение количества затраченного на разработку времени и эффективное использование ресурсов команды разработчиков.
Объектом исследования является архитектурные подходы реализации пользовательского интерфейса системы.
Предметом исследования являются моделирование пользовательского интерфейса корпоративной системы на основе архитектурных решений.
Гипотеза: сформулированная компонентная модель пользовательского интерфейса системы будет более эффективной, если
1) будут рассмотрены существующие модели пользовательского интерфейса системы;
2) будут определены положительные стороны существующих архитектурных решений, а также найдены их недостатки;
3) во время формулирования модели будут учтены ранее найденные достоинства и недостатки существующих решений;
4) будут описаны и рассмотрены новые термины и определения модели;
5) будут выбраны технологии, с помощью которых она будет реализована;
6) она будет реализована.
Для достижения поставленной цели были сформулированы и решены следующие задачи:
• изучение научной литературы, связанной с архитектурными подходами и технологиями их реализации;
• выявление достоинств и недостатков существующих архитектурных подходов;
• выявление достоинств и недостатков существующих технологий реализации;
• формулирование принципов компонентной модели пользовательского интерфейса системы;
• описание новых терминов и определений компонентной модели пользовательского интерфейса системы;
• построение и реализация компонентой модели;
• вычисление показателей, отвечающих за эффективное использование ресурсов команды;
• проведение функционального тестирования, показывающее корректность модели.
Научная новизна состоит в том, что будет реализована новая архитектурная модель пользовательского интерфейса системы.
Теоретические основы исследования включают использование трудов (работ) зарубежных и отечественных авторов по исследованию архитектурных решений.
Теоретическая значимость заключается в определении концептуального подхода нового архитектурного решения.
Практическая значимость состоит в том, что будет реализовано архитектурное решение, используемое при построении пользовательского интерфейса системы в проектах ИТ-компаний.
Достоверность и обоснованность научных положений и выводов, которые были сделаны в магистерской диссертации, следуют из адекватности архитектурной модели, сформулированной и реализованной в рамках исследования, подтверждаются экономическими показателями и результатами функционального тестирования.
Основные положения, выносимые на защиту:
1. Компонентная модель пользовательского интерфейса корпоративной системы, направленная на исключение дублирования ранее написанного функционала при эффективном использовании ресурсов команды разработчиков.
2. Результаты функционального тестирования реализованной компонентной модели пользовательского интерфейса системы, показывающие эффективность и корректность ее реализации.
Диссертация состоит из введения, четырех разделов, заключения и списка литературы. Объем диссертации составляет 72 страницы и содержит 32 рисунка, список литературы включает 62 наименований источников зарубежных и отечественных авторов.
Во введении обосновывается актуальность выбранной темы исследования, определяется объект, предмет и цель исследования, выдвигается гипотеза и формулируются задачи работы, рассматриваются научная новизна, практическая и теоретическая значимость результатов данного исследования.
В первой части диссертации описываются архитектурные решения, достоинства и недостатки, обнаруженные различными авторами научных работ, а также описывается найденная проблема, которая не рассматривалась авторами.
Во второй части формулируется компонентная модель пользовательского интерфейса системы, которая позволит решить обнаруженную в первой части проблему. Также описываются различные термины данной модели.
В третьей части описанная модель реализовываться с помощью выбранных технологий, приводятся скриншоты интерфейсов, с внедренными компонентами.
В четвертой части рассматривается доказательство эффективности реализованной модели пользовательского интерфейса с помощью различных показателей. Также проводится функциональное тестирование реализованной модели, которое доказывает корректность реализованной модели.
В заключении представлены основные результаты поставленных задач и сделаны следующие выводы:
1. В процессе изучения научной литературы была найдена проблема, которая не рассматривалась авторами в своих работах;
2. Обнаруженная проблема затрагивает актуальную тему, так как в рамках неё может быть решены насущные проблемы;
3. При формулировании принципов модели пользовательского интерфейса системы были учтены выявленные достоинства и недостатки существующих архитектурных решений;
4. Компонентная модель эффективна согласно экономическим показателям.
5. Реализованная модель работает корректно, что доказано с помощью функционального тестирования.
6. Используя данную модель, можно эффективнее использовать ресурсы команды.
Основные результаты исследования представлены в следующих публикациях:
1. Логинова М.А. Исследование и анализ архитектурных решений при построении пользовательской части распределенных корпоративных систем // сборник V международной научно-практической конференции (школы-семинара) молодых ученых «Прикладная математика и информатика: современные исследования в области естественных и технических наук».
2. Логинова М.А. Формирование новой модели пользовательской части корпоративного приложения // сборник VI международной научно-практической конференции (школы-семинара) молодых ученых «Прикладная математика и информатика: современные исследования в области естественных и технических наук».
Архитектурой системы называют логическую структуру, описывающую отдельные компоненты, их свойства и связи как единую систему. Грамотно выбранная архитектура позволит реализовывать и поддерживать системы более простым и эффективным способом, их станет легче расширять и изменять, а также тестировать, отлаживать и понимать разработчикам. Архитектурный подход будет осуществлять выбор структурных элементов, их интерфейсы, а также взаимодействие между собой.
Существующие архитектурные решения хороши в применении, так, например, монолитный подход требует наименьших затрат на начальных этапах; модульный подход дает возможность реализовывать более сложные системы или приложения, которые состоят из множества различных модулей; микросервисный подход позволит создавать отказоустойчивые системы, которые легко можно расширять, не ориентируясь на конкретную платформу. Однако научная проблема заключается в том, что архитектурные решения дублирует некоторую функциональность, что приводит к повторному написанию кода, то есть потери времени и нерациональному использованию ресурсов команды, а следовательно, и компании.
Целью исследования является разработка компонентной модели, направленной на сокращение количества затраченного на разработку времени и эффективное использование ресурсов команды разработчиков.
Объектом исследования является архитектурные подходы реализации пользовательского интерфейса системы.
Предметом исследования являются моделирование пользовательского интерфейса корпоративной системы на основе архитектурных решений.
Гипотеза: сформулированная компонентная модель пользовательского интерфейса системы будет более эффективной, если
1) будут рассмотрены существующие модели пользовательского интерфейса системы;
2) будут определены положительные стороны существующих архитектурных решений, а также найдены их недостатки;
3) во время формулирования модели будут учтены ранее найденные достоинства и недостатки существующих решений;
4) будут описаны и рассмотрены новые термины и определения модели;
5) будут выбраны технологии, с помощью которых она будет реализована;
6) она будет реализована.
Для достижения поставленной цели были сформулированы и решены следующие задачи:
• изучение научной литературы, связанной с архитектурными подходами и технологиями их реализации;
• выявление достоинств и недостатков существующих архитектурных подходов;
• выявление достоинств и недостатков существующих технологий реализации;
• формулирование принципов компонентной модели пользовательского интерфейса системы;
• описание новых терминов и определений компонентной модели пользовательского интерфейса системы;
• построение и реализация компонентой модели;
• вычисление показателей, отвечающих за эффективное использование ресурсов команды;
• проведение функционального тестирования, показывающее корректность модели.
Научная новизна состоит в том, что будет реализована новая архитектурная модель пользовательского интерфейса системы.
Теоретические основы исследования включают использование трудов (работ) зарубежных и отечественных авторов по исследованию архитектурных решений.
Теоретическая значимость заключается в определении концептуального подхода нового архитектурного решения.
Практическая значимость состоит в том, что будет реализовано архитектурное решение, используемое при построении пользовательского интерфейса системы в проектах ИТ-компаний.
Достоверность и обоснованность научных положений и выводов, которые были сделаны в магистерской диссертации, следуют из адекватности архитектурной модели, сформулированной и реализованной в рамках исследования, подтверждаются экономическими показателями и результатами функционального тестирования.
Основные положения, выносимые на защиту:
1. Компонентная модель пользовательского интерфейса корпоративной системы, направленная на исключение дублирования ранее написанного функционала при эффективном использовании ресурсов команды разработчиков.
2. Результаты функционального тестирования реализованной компонентной модели пользовательского интерфейса системы, показывающие эффективность и корректность ее реализации.
Диссертация состоит из введения, четырех разделов, заключения и списка литературы. Объем диссертации составляет 72 страницы и содержит 32 рисунка, список литературы включает 62 наименований источников зарубежных и отечественных авторов.
Во введении обосновывается актуальность выбранной темы исследования, определяется объект, предмет и цель исследования, выдвигается гипотеза и формулируются задачи работы, рассматриваются научная новизна, практическая и теоретическая значимость результатов данного исследования.
В первой части диссертации описываются архитектурные решения, достоинства и недостатки, обнаруженные различными авторами научных работ, а также описывается найденная проблема, которая не рассматривалась авторами.
Во второй части формулируется компонентная модель пользовательского интерфейса системы, которая позволит решить обнаруженную в первой части проблему. Также описываются различные термины данной модели.
В третьей части описанная модель реализовываться с помощью выбранных технологий, приводятся скриншоты интерфейсов, с внедренными компонентами.
В четвертой части рассматривается доказательство эффективности реализованной модели пользовательского интерфейса с помощью различных показателей. Также проводится функциональное тестирование реализованной модели, которое доказывает корректность реализованной модели.
В заключении представлены основные результаты поставленных задач и сделаны следующие выводы:
1. В процессе изучения научной литературы была найдена проблема, которая не рассматривалась авторами в своих работах;
2. Обнаруженная проблема затрагивает актуальную тему, так как в рамках неё может быть решены насущные проблемы;
3. При формулировании принципов модели пользовательского интерфейса системы были учтены выявленные достоинства и недостатки существующих архитектурных решений;
4. Компонентная модель эффективна согласно экономическим показателям.
5. Реализованная модель работает корректно, что доказано с помощью функционального тестирования.
6. Используя данную модель, можно эффективнее использовать ресурсы команды.
Основные результаты исследования представлены в следующих публикациях:
1. Логинова М.А. Исследование и анализ архитектурных решений при построении пользовательской части распределенных корпоративных систем // сборник V международной научно-практической конференции (школы-семинара) молодых ученых «Прикладная математика и информатика: современные исследования в области естественных и технических наук».
2. Логинова М.А. Формирование новой модели пользовательской части корпоративного приложения // сборник VI международной научно-практической конференции (школы-семинара) молодых ученых «Прикладная математика и информатика: современные исследования в области естественных и технических наук».
В рамках данного исследования были рассмотрены различные научные статьи и диссертации на тему архитектурных подходов разработки системы. В первой части данной работы были описаны достоинства и недостатки архитектурных решений, которые авторы выделяли в своих работах.
Монолит обеспечивает достаточно легкое начало и несет наименьшее количество расходов, но цена поддержки подобных систем увеличивается быстрее по сравнению с аналогами, реализованными с помощью других подходов. Также данные системы сложно масштабируемы и имеют ряд проблем, связанных с тем, что все их модули находятся на одной аппаратной части. Однако существует возможность допуска ошибки на его начальных этапах, потому что их можно быстро исправить.
Для реализации систем модульным решением необходимы большие расходы на начальной стадии, однако увеличение цены поддержки подобных систем менее резок. Данный факт обеспечивает поддержку подобных систем дольше и проще, чем монолита. В рамках данного решения происходит синхронное взаимодействие модулей. Однако, различие данного подхода и монолита весьма неявное, так как изначально подобные системы пишутся модулями, с явно описанной функциональностью каждого и четкими границами между ними. Но и монолит может включать в себя разные компоненты и классы, зависящие от данных других модулей и друг от друга. Другой проблемой модульного решения является реализация функциональности, существующей по другой схеме в другой части системы.
При использование микросервисного подхода необходимо затрачивать большие ресурсы на начальных этапах, потому что необходимо достаточно обширное проектирование развития системы. Однако подход имеет ряд преимуществ и в большей степени удовлетворяет современным требованиям. Микросервисный подход необязательно подходит для каждой системы, требующий иного подхода к проектированию, так как необходимо понимать принципы работы с ними, учитывать возможные побочные эффекты при работе с асинхронной связью, продумывать четкие границы ответственности команд разработчиков.
На основании выше рассмотренного был сделан вывод, заключающееся в том, что каждое рассмотренное архитектурное решение предоставляет свои плюсы и минусы. Однако в рамках исследования была найдена проблема, которая авторами не рассматривалась - дублирование функционала. Таким образом, в рамках работы необходимо было сформулировать модель, которая могла бы исключить нерациональное использование ресурсов команды разработчиков, убрав дублирование функционала. Другими словами, было доказано, что тема диссертации является актуальной, так как в рамках неё может быть решены насущные проблемы.
Модель, способная решить обнаруженную проблему, предполагает изолированность UI-частей, которые используется многими микросервисами в микросервисном подходе. Она называется компонентной моделью, потому что весь фронтенд (UI, интерфейс) различных микросервисов разбит на компоненты-фрагменты.
В рамках данной работы были сформулированы требования к компонентной модели пользовательского интерфейса системы, введены новые термины и определения, подробно описана суть модели, было рассмотрено определение «фрагмент» и его разновидности, а также были выделены UI-части, дублируемые в различных микросервисах. Кроме того, были выбраны технологии реализации, более того сформулированная компонентная модель пользовательского интерфейса системы была реализована.
Фрагментом является независимая UI-часть, которая соблюдает набор правил разработки, для того, чтобы его можно было использовать в общем интерфейсе системы, его стили должны быть максимально специфичны, прямого взаимодействия с другими фрагментами быть не должно.
Фрагменты компонентной модели необходимо разрабатывать как отдельные приложения, они будут отвечать за некий набор бизнес-функций, то есть будет являться полностью функциональным от начала и до конца. Также, фрагменты подобно обычным микросервисам могут быть написаны на различных языках. Кроме того, они могут встраиваться не только в микросервисы, некоторые фрагменты могут служить контейнерами для встраивания других фрагментов.
Для того, чтобы микросервисы могли встраивать фрагменты у себя на странице, им необходимо инициализировать Контроллер, который будет предоставлять микросервисам методы, для встраивания фрагментов. Для это микросервисам необходимо указать их название и конфигурационный флаг, а также поставить некий маркер - определенный класс - у себя в шаблоне. Если при инициализации конфигурационный флаг не был указан, считается что у фрагментов будет дефолтовая конфигурация, а следовательно, дефолтные стили и поведение.
Также в рамках данной работы были рассмотрены механизмы взаимодействия микросервисов между собой, а также микросервисов и встроенных в них компонентов. В рамках компонентной модели микросервисы будут взаимодействовать между собой посредством API. То есть клиент, обращаясь к шлюзу, который переадресовывает запрос к нужному микросервису, минует обращение к каждому из них по отдельности. А фрагменты и микросервисы в рамках данной модели взаимодействуют, используя Event Bus. То есть при изменении состояния компонента он сообщает об этом, используя метод publish(), в то время как микросервис, которому важны данные изменения подписывается на любые изменения компонента, используя метод subscribe(). Таким образом, микросервис своевременно обновляет данные, тем самым владея актуальной информацией.
Кроме того, в рамках данной работы была доказана эффективность реализованной модели, так как важным аспектом любой трудовой деятельности является продуктивность, потому что рациональное и продуктивное использование ресурсов команды разработчиков, её времени, предназначенное для определенного процесса разработки, позволяет оптимизировать трудовую деятельность этой команды.
Используя определенные экономические показатели, можно вывести временные затраты, необходимые разработчику для решения поставленной задачи. Другими словами, выполнив необходимые расчёты этих показателей, можно выявить оперативность разработчиков команды, а также существенно увеличить показатели эффективности процесса разработки.
Таким образом, знание определенных экономических показателей позволит увеличить производительность команды. Например, для оптимизации процесса разработки, сокращения времени разработки и получения большей выгоды необходимо было рассчитать количество затраченных на разработку одной «единицы» человеко-часов.
Учетная единица просто необходима при планировании объема задач для команды разработчиков на спринт или итерацию. Руководителю команды разработчиков с помощью данного показателя удобно планировать рабочее время членов команды, определять их необходимое количество для исполнения задач, а также устанавливать сроки для завершения работы. Нередко человеко-часы используются для установки сроков выполнения обязательств во время проектирования определённых задач, ставящихся руководством в жесткие ограничения по времени.
То есть, используя данный показатель можно вычислить временной отрезок или количество разработчиков, которые требуются для осуществления определенной задачи, направленной на разработку или багофикс.
Для этого в рамках данной работы были вычислены показатели «человеко-часы» команд при выполнении определенных задач с и без использования компонентной модели. А затем были вычислены человеко-часы всей команды, где необходимо было сложить индивидуальные человеко-часы разработчиков.
Под термином «человеко-часы» понимают единицу учёта рабочего времени, соответствующую одному часу работы одного разработчика. Данный показатель используется для планирования рабочего времени на ту или иную работу и вычисления количества разработчиков, необходимых для выполнения того или иного процесса. При вычислении данного показателя учитывалось только время фактического труда. Не учитывалось время больничных, отпусков, и другого неоплачиваемого или оплачиваемого времени, в течение которого работа не выполнялась. Другими словами, данный показатель обозначал один полностью отработанный час одним конкретным разработчиком.
В итоге, было вычислено, что, для решения описанных трех задач команда личного кабинета потратит 32 «человеко-час», команда галереи - 40 «человеко-час», а команда каталога продуктов - 48 часов.
Используя компонентную модель данные показатели можно было сократить. Вынося в отдельные компоненты, например, шапку и подвал, можно избежать необходимости выделять разработчиков каждой команды на задачи, связанные с ними, так как команды будут встраивать фрагменты на своей стороне с уже готовыми исправлениями или новым функционалом.
То есть команда, отвечающая за данные фрагменты, потратит определенное количество «человеко-часов», в то время как команды микросервисов не будут затрачивать их.
Другими словами, при использовании компонентной модели в спринте команда личного кабинета потратит на данные задачи 8 «человеко-часа», команда галереи - 12 «человеко-часа», а команда каталога продуктов - 32 «человеко-часа».
Таким образом, команды микросервисов могут потрать свои ресурсы на решения задач, которые являются уникальными для них. Команда личного кабинета и каталога продуктов может добрать на спринт задач на 16 «человеко-часов», а команда галереи - на 20 «человеко-часов», тем самым улучшая свой микросервис, не тратя при этом лишние ресурсы всего проекта.
Стоимость человеко-часа также может быть уменьшена, если, например, для решения повторяющихся задач разработчики каждой команды выходили в сверхурочные.
Таким образом, было доказано, что использование компонентной модели пользовательского интерфейса позволит эффективнее использовать ресурсы и время команды разработчиков.
Затем, в четвертой части данной работы было проведено функциональное тестирование системы, которая была реализована с помощью компонентной модели.
Функциональным тестированием называют тестирование системы, приложения, программного обеспечения в целях проверки реализуемости функциональных требований, то есть во время тестирования происходит проверка способности п определённых условиях решать задачи необходимые пользователю. Данное тестирование проводится на основании тест кейса, то есть последовательности действий, направленной на проверку какого-либо функционала и описывающей как добиться ожидаемого результата.
В рамках данной системы в компоненты были вынесены шапка и подвал. Также при тестировании было учтено, что микросервисами была задана одинаковая конфигурация данным фрагментам. Описанный тест кейс был пройдет, то есть после встраивания фрагментов шапки и подвала микросервисы работали ожидаемым образом. Другими словами, было показано, что компонентная модель работает корректно.
Таким образом, в рамках данного исследования была найдена актуальная проблема, было описано и реализовано её решение. Также было доказано, что при использовании компонентной модели можно разумнее и эффективнее использовать ресурсы и время команды разработчиков, а также то, что данная модель работает корректно.
Монолит обеспечивает достаточно легкое начало и несет наименьшее количество расходов, но цена поддержки подобных систем увеличивается быстрее по сравнению с аналогами, реализованными с помощью других подходов. Также данные системы сложно масштабируемы и имеют ряд проблем, связанных с тем, что все их модули находятся на одной аппаратной части. Однако существует возможность допуска ошибки на его начальных этапах, потому что их можно быстро исправить.
Для реализации систем модульным решением необходимы большие расходы на начальной стадии, однако увеличение цены поддержки подобных систем менее резок. Данный факт обеспечивает поддержку подобных систем дольше и проще, чем монолита. В рамках данного решения происходит синхронное взаимодействие модулей. Однако, различие данного подхода и монолита весьма неявное, так как изначально подобные системы пишутся модулями, с явно описанной функциональностью каждого и четкими границами между ними. Но и монолит может включать в себя разные компоненты и классы, зависящие от данных других модулей и друг от друга. Другой проблемой модульного решения является реализация функциональности, существующей по другой схеме в другой части системы.
При использование микросервисного подхода необходимо затрачивать большие ресурсы на начальных этапах, потому что необходимо достаточно обширное проектирование развития системы. Однако подход имеет ряд преимуществ и в большей степени удовлетворяет современным требованиям. Микросервисный подход необязательно подходит для каждой системы, требующий иного подхода к проектированию, так как необходимо понимать принципы работы с ними, учитывать возможные побочные эффекты при работе с асинхронной связью, продумывать четкие границы ответственности команд разработчиков.
На основании выше рассмотренного был сделан вывод, заключающееся в том, что каждое рассмотренное архитектурное решение предоставляет свои плюсы и минусы. Однако в рамках исследования была найдена проблема, которая авторами не рассматривалась - дублирование функционала. Таким образом, в рамках работы необходимо было сформулировать модель, которая могла бы исключить нерациональное использование ресурсов команды разработчиков, убрав дублирование функционала. Другими словами, было доказано, что тема диссертации является актуальной, так как в рамках неё может быть решены насущные проблемы.
Модель, способная решить обнаруженную проблему, предполагает изолированность UI-частей, которые используется многими микросервисами в микросервисном подходе. Она называется компонентной моделью, потому что весь фронтенд (UI, интерфейс) различных микросервисов разбит на компоненты-фрагменты.
В рамках данной работы были сформулированы требования к компонентной модели пользовательского интерфейса системы, введены новые термины и определения, подробно описана суть модели, было рассмотрено определение «фрагмент» и его разновидности, а также были выделены UI-части, дублируемые в различных микросервисах. Кроме того, были выбраны технологии реализации, более того сформулированная компонентная модель пользовательского интерфейса системы была реализована.
Фрагментом является независимая UI-часть, которая соблюдает набор правил разработки, для того, чтобы его можно было использовать в общем интерфейсе системы, его стили должны быть максимально специфичны, прямого взаимодействия с другими фрагментами быть не должно.
Фрагменты компонентной модели необходимо разрабатывать как отдельные приложения, они будут отвечать за некий набор бизнес-функций, то есть будет являться полностью функциональным от начала и до конца. Также, фрагменты подобно обычным микросервисам могут быть написаны на различных языках. Кроме того, они могут встраиваться не только в микросервисы, некоторые фрагменты могут служить контейнерами для встраивания других фрагментов.
Для того, чтобы микросервисы могли встраивать фрагменты у себя на странице, им необходимо инициализировать Контроллер, который будет предоставлять микросервисам методы, для встраивания фрагментов. Для это микросервисам необходимо указать их название и конфигурационный флаг, а также поставить некий маркер - определенный класс - у себя в шаблоне. Если при инициализации конфигурационный флаг не был указан, считается что у фрагментов будет дефолтовая конфигурация, а следовательно, дефолтные стили и поведение.
Также в рамках данной работы были рассмотрены механизмы взаимодействия микросервисов между собой, а также микросервисов и встроенных в них компонентов. В рамках компонентной модели микросервисы будут взаимодействовать между собой посредством API. То есть клиент, обращаясь к шлюзу, который переадресовывает запрос к нужному микросервису, минует обращение к каждому из них по отдельности. А фрагменты и микросервисы в рамках данной модели взаимодействуют, используя Event Bus. То есть при изменении состояния компонента он сообщает об этом, используя метод publish(), в то время как микросервис, которому важны данные изменения подписывается на любые изменения компонента, используя метод subscribe(). Таким образом, микросервис своевременно обновляет данные, тем самым владея актуальной информацией.
Кроме того, в рамках данной работы была доказана эффективность реализованной модели, так как важным аспектом любой трудовой деятельности является продуктивность, потому что рациональное и продуктивное использование ресурсов команды разработчиков, её времени, предназначенное для определенного процесса разработки, позволяет оптимизировать трудовую деятельность этой команды.
Используя определенные экономические показатели, можно вывести временные затраты, необходимые разработчику для решения поставленной задачи. Другими словами, выполнив необходимые расчёты этих показателей, можно выявить оперативность разработчиков команды, а также существенно увеличить показатели эффективности процесса разработки.
Таким образом, знание определенных экономических показателей позволит увеличить производительность команды. Например, для оптимизации процесса разработки, сокращения времени разработки и получения большей выгоды необходимо было рассчитать количество затраченных на разработку одной «единицы» человеко-часов.
Учетная единица просто необходима при планировании объема задач для команды разработчиков на спринт или итерацию. Руководителю команды разработчиков с помощью данного показателя удобно планировать рабочее время членов команды, определять их необходимое количество для исполнения задач, а также устанавливать сроки для завершения работы. Нередко человеко-часы используются для установки сроков выполнения обязательств во время проектирования определённых задач, ставящихся руководством в жесткие ограничения по времени.
То есть, используя данный показатель можно вычислить временной отрезок или количество разработчиков, которые требуются для осуществления определенной задачи, направленной на разработку или багофикс.
Для этого в рамках данной работы были вычислены показатели «человеко-часы» команд при выполнении определенных задач с и без использования компонентной модели. А затем были вычислены человеко-часы всей команды, где необходимо было сложить индивидуальные человеко-часы разработчиков.
Под термином «человеко-часы» понимают единицу учёта рабочего времени, соответствующую одному часу работы одного разработчика. Данный показатель используется для планирования рабочего времени на ту или иную работу и вычисления количества разработчиков, необходимых для выполнения того или иного процесса. При вычислении данного показателя учитывалось только время фактического труда. Не учитывалось время больничных, отпусков, и другого неоплачиваемого или оплачиваемого времени, в течение которого работа не выполнялась. Другими словами, данный показатель обозначал один полностью отработанный час одним конкретным разработчиком.
В итоге, было вычислено, что, для решения описанных трех задач команда личного кабинета потратит 32 «человеко-час», команда галереи - 40 «человеко-час», а команда каталога продуктов - 48 часов.
Используя компонентную модель данные показатели можно было сократить. Вынося в отдельные компоненты, например, шапку и подвал, можно избежать необходимости выделять разработчиков каждой команды на задачи, связанные с ними, так как команды будут встраивать фрагменты на своей стороне с уже готовыми исправлениями или новым функционалом.
То есть команда, отвечающая за данные фрагменты, потратит определенное количество «человеко-часов», в то время как команды микросервисов не будут затрачивать их.
Другими словами, при использовании компонентной модели в спринте команда личного кабинета потратит на данные задачи 8 «человеко-часа», команда галереи - 12 «человеко-часа», а команда каталога продуктов - 32 «человеко-часа».
Таким образом, команды микросервисов могут потрать свои ресурсы на решения задач, которые являются уникальными для них. Команда личного кабинета и каталога продуктов может добрать на спринт задач на 16 «человеко-часов», а команда галереи - на 20 «человеко-часов», тем самым улучшая свой микросервис, не тратя при этом лишние ресурсы всего проекта.
Стоимость человеко-часа также может быть уменьшена, если, например, для решения повторяющихся задач разработчики каждой команды выходили в сверхурочные.
Таким образом, было доказано, что использование компонентной модели пользовательского интерфейса позволит эффективнее использовать ресурсы и время команды разработчиков.
Затем, в четвертой части данной работы было проведено функциональное тестирование системы, которая была реализована с помощью компонентной модели.
Функциональным тестированием называют тестирование системы, приложения, программного обеспечения в целях проверки реализуемости функциональных требований, то есть во время тестирования происходит проверка способности п определённых условиях решать задачи необходимые пользователю. Данное тестирование проводится на основании тест кейса, то есть последовательности действий, направленной на проверку какого-либо функционала и описывающей как добиться ожидаемого результата.
В рамках данной системы в компоненты были вынесены шапка и подвал. Также при тестировании было учтено, что микросервисами была задана одинаковая конфигурация данным фрагментам. Описанный тест кейс был пройдет, то есть после встраивания фрагментов шапки и подвала микросервисы работали ожидаемым образом. Другими словами, было показано, что компонентная модель работает корректно.
Таким образом, в рамках данного исследования была найдена актуальная проблема, было описано и реализовано её решение. Также было доказано, что при использовании компонентной модели можно разумнее и эффективнее использовать ресурсы и время команды разработчиков, а также то, что данная модель работает корректно.
