Как создавать архитектуру программы

Этот цикл статей посвящен методам создания моделей для описания и распространения архитектуры сложных программных систем. Он иллюстрирует процесс разработки архитектуры системы интернет-сети ресторанного обслуживания (Online Catering) для вымышленной компании Yummy Inc.

С помощью итеративного подхода создается описание основных действий по созданию архитектуры, необходимых для определения сложной программной системы с помощью IBM Rational Software Architect (RSA). В первой части этого цикла мы сосредоточимся на типичных задачах проектирования архитектуры и согласования технической концепции с предъявляемыми требованиями. Во второй части говорится о том, как эта архитектура итеративно уточняется с помощью RSA. Обе статьи предполагают, что читатели знакомы с методологией итеративной разработки.

Основная цель этой статьи — проиллюстрировать, как Rational Software Architect 8 (далее ― RSA) помогает в проектировании и документировании архитектуры. RSA — это платформа коллективной работы для проектирования высококачественной архитектуры ПО. RSA помогает определить модели на различных уровнях абстракции и может использоваться для поддержки практических приемов проектирования программного обеспечения.

#Архитектура приложения и кода

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

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

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

1. Выявление значимых требований: основные функциональные и нефункциональные требования, оказывающие существенное влияние на архитектуру.
2. Определение предполагаемой архитектуры: общая архитектура системы с учетом архитектурных ограничений и целей.
3. Определение исходной модели развертывания: топология, отражающая узлы развертывания системы.
4. Определение модели домена: ключевые бизнес-объекты и их взаимодействие.

Электронная книга: Загрузите из блога автора электронную книгу Эволюционная архитектура ― с помощью Rational Software Architect v8 .

Архитектура ПО. Введение

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

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

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

1. Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
2. Уточнение элементов структуры: архитектурно значимые элементы структуры.
3. Уточнение архитектуры развертывания: единицы и топологии развертывания.

Итерационные мероприятия описаны во второй статье этого цикла.

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

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

В 1995 году Филипп Крухтен предложил модель для описания архитектуры сложных программных систем: модель представления архитектуры программного обеспечения «4+1» (см. раздел Ресурсы). Большинство идей модели «4+1» вошли в такие процессы разработки, как IBM Rational Unified Process (RUP) или OpenUP. Недавно IEEE 1471 стандартизировал определение представления для решения проблем различных пользователей архитектуры программного обеспечения (IEEE 1471-2000/ISO 42010, см. раздел Ресурсы).

В оригинальной модели «4+1» используются пять видов представлений, которые дают всеобъемлющее представление о системе, как показано на рисунке 2.

Каждое представление модели «4+1» отражает вопросы определенных участников процесса, позволяя им легко находить в архитектуре программного обеспечения то, что им нужно. Эту модель можно настраивать. В зависимости от сложности проекта можно получить только необходимое подмножество предлагаемых представлений. Модель можно также расширять, добавляя другие представления для описания архитектуры с другой точки зрения. Дополнительные представления обычно вкладываются в существующие как подкатегории.

В таблице 1 каждая строка соответствует представлению для определенной аудитории, области и модели.

Логическое Проектировщики Реализация вариантов использования Аналитическая модель
Структурная модель Процессов Интеграторы Производительность
Масштабируемость
Параллелизм Модель развертывания
Структурная модель Реализации Программисты Программные компоненты Модель реализации Развертывания Менеджеры по внедрению Физические узлы Модель развертывания Сценариев Все Функциональные требования Модель вариантов использования
Описание сценариев использования
Бизнес-процессы Данных
(дополнительно или в составе логического представления) Специалисты по обработке данных
Администраторы баз данных Персистентность данных Модель данных

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

Прежде чем запустить RSA, убедитесь, что у вас установлен минимальный набор инструментов для работы архитектора. В диспетчере установки должен быть отмечен параметр Architect — Standard , как показано на рисунке 3. Этот предопределенный профиль обеспечивает функции моделирования топологии и UML, необходимые для решения задач, рассматриваемых в этой статье.

Рисунок 3. Стандартный профиль архитектуры

Следующий шаг ― создание новой рабочей области. Запустите RSA и укажите каталог (рис. 4).

Рисунок 4. Окно Workspcae Launcher

RSA предоставляет много различных перспектив для настройки исходного набора и расположения представлений в окне Workbench. Прежде чем двигаться дальше, убедитесь, что открыта перспектива Modeling (рисунок 5).

Рисунок 5. Окно Open Perspective

RSA содержит много готовых шаблонов UML-моделей. В режиме Modeling Perspective можно добавлять модели для документирования архитектуры своей системы (рисунок 6).

Рисунок 6. Шаблоны UML-моделей

Каждый шаблон предназначен для конкретной архитектурной цели. Как правило, чтобы определить каждый аспект системы (вспомните модель представления «4+1»), нужны модели Use-Case, Analysis и Design. В нашем примере можно также создать эскиз архитектуры и топологии для определения целевой среды развертывания. Итак, рабочая область Yummy Inc. содержит следующие модели (рисунок 7). Каждая основана на своем шаблоне RSA.

Рисунок 7. Модели, описывающие представления архитектуры системы Online Catering

Обратите внимание, что мы могли бы использовать другие типы моделей из числа шаблонов RSA, например, модель BPMN (бизнес-процесс) или модель Services (SOA).

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

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

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

Выявленные требования для Yummy Inc. содержатся в модели сценариев использования RSA (рисунок 8).

Рисунок 8. Требования для системы Online Catering

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

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

Рисунок 9. Схема сценария использования меню заказов

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

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

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

В 2020 году в мире насчитывалось более 3,5 миллиарда пользователей мобильных телефонов, а в 2023 году ожидается рост этого числа до 3,8 миллиарда пользователей. Все эти факторы оказывают положительное влияние на мировой рынок приложений, который, по прогнозам, достиг 693 млрд долларов в 2021 году и вырастет до 935,2 млрд долларов в 2023 году. Поэтому, если вы планируете создание мобильного приложения, это станет верным способом привлечь и удержать больше клиентов и увеличить доходы вашей компании.

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

Что такое архитектура мобильного приложения?

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

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

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

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

Что определяет хорошую архитектуру мобильного приложения?

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

• SOLID — 5 принципов объектно-ориентированного программирования для построения простых в обслуживании и масштабируемых приложений.
• KISS — принцип сохранения простоты системы и кода для минимизации количества ошибок.
• DRY — принцип сокращения повторений в паттернах программного обеспечения для избежания избыточности.

Кроме того, при создании мобильного приложения разработчики должны ориентироваться на архитектуру CLEAN (Чистая архитектура). Этот тип архитектуры означает, что каждый слой приложения не зависит от каких-либо внешних программ или других слоев. Для соединения независимых слоев разработчики используют правило зависимости, когда переходы между слоями осуществляются с помощью границ. Границы — это порты ввода и вывода, которые позволяют передавать данные между слоями.

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

Еще один момент, который необходимо учитывать при создании архитектуры приложения, — это мобильная платформа приложения (Android, iOS), поскольку для этих платформ потребуются разные технологии разработки.

Для успешной разработки iOS разработчики обычно используют такие языки программирования как Swift, Objective-C и такие инструменты разработки как iOS SDK, XCode, AppCode, а для Android — языки программирования Kotlin, Java, C/C++ и инструменты Android SDK, Eclipse, Android Studio и другие. Эти языки программирования и инструменты являются наиболее эффективными, когда речь идет о разработке сложных функций приложений, необходимых любому бизнесу.

Многоуровневая архитектура мобильных приложений

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

• Презентационный слой
• Слой бизнес-логики
• Слой доступа к данным

Презентационный слой

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

Слой бизнес-логики

Бизнес-слой отвечает за обмен данными и обработку операций. На этом уровне ваше приложение выполняет различные задачи, такие как: проверка данных, кэширование, логирование, управление исключениями и другие. Кроме того, бизнес-слой устанавливает бизнес-правила, выполняет сложные бизнес-процедуры и регулирует рабочий процесс.

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

Слой доступа к данным

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

Как правильно выбрать архитектурное решение для мобильного приложения?

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

Существует три основных типа приложений:

• нативные приложения;
• гибридные приложения;
• мобильные веб-приложения.

Нативные приложения

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

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

Нативные приложения создаются для конкретной мобильной платформы с использованием определенных языков программирования и фреймворков. Например, для создания приложения для Android вам понадобится Java и Android studio. Поэтому, если вы хотите запустить еще и приложение на платформе iOS, вам придется создавать новое приложение с нуля, используя инструменты, подходящие для iOS, такие как Swift и AppCode.

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

Архитектура мобильных приложений для Android

Для операционной системы Android не существует такого понятия, как единая мобильная архитектура, и Google не предоставляет никакой документации или руководства по конкретной архитектуре. Тем не менее путем проб и ошибок специалисты пришли к выводу, что архитектура Clean лучше всего подходит для приложений Android.

Архитектура «Clean» обычно представляется в виде круга из четырех слоев:

• Entities— бизнес-логика общая для многих приложений.
• Use Cases (Interactors) — логика приложения.
• Interface Adapters — адаптеры между Use Cases и внешним миром. Сюда попадают Presenter’s из MVP, а также Gateways (более популярное название репозитории).
• Frameworks — самый внешний слой, тут лежит все остальное: UI, база данных, http-клиент, и т.п.

Для соблюдения Dependency Rule, бизнес-логика и логика приложения должны не зависеть от Presenter’s, UI, и каждый слой должен иметь свои Границы. Эти Границы устанавливают связь между слоями, предоставляя им два интерфейса — выходной порт для ответа и входной порт для запроса.

Четкая структура и независимость слоев и создают Clean Architecture:

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

Архитектура мобильных приложений для iOS

В отличие от Android, операционная система Apple предлагает разработчикам гораздо больше рекомендаций по построению архитектуры мобильных приложений iOS на основе модели MVC (Model-View-Controller). Однако разработчики iOS не ограничены только одним Архитектурным паттерном, этот паттерн просто является наиболее часто используемым в iOS приложениях.

Компоненты MVC:

• Модель / Model — этот компонент отвечает за данные, а также определяет структуру приложения. Например, если вы создаете To-Do приложение, код компонента model будет определять список задач и отдельные задачи.
• Представление / View — этот компонент отвечает за взаимодействие с пользователем. То есть код компонента view определяет внешний вид приложения и способы его использования.
• Контроллер / Controller — этот компонент отвечает за связь между model и view. Код компонента controller определяет, как сайт реагирует на действия пользователя. По сути, это мозг MVC-приложения.

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

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

Используя модель MVC, разработчики iOS:

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

Гибридные приложения

Гибридные приложения — это решения, представляющее собой по сути веб-приложение в нативной оболочке соответствующей мобильной платформы. Для разработки этих решений используют веб-технологии, запускаются внутри нативных приложений, представляя веб-контент в обертке собственного приложения. Их содержимое может быть размещено в приложении или доступно с веб-сервера. Таким образом, гибридные приложения имеют доступ к аппаратному обеспечению устройства и в то же время являются веб-приложениями, сочетая в себе веб- и нативные возможности. Эти приложения также можно найти в интернет магазинах приложений.

Обычно, гибридные приложения намного дешевле и быстрее в разработке, поскольку они могут использовать нативные API, такие как контакты, камеру и так далее. Они имеют одну кодовую базу для приложений Android и iOS, что означает, что вам не нужно разрабатывать два приложения с нуля для каждой платформы. Так же они являются более простыми в удобными в обслуживании.

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

Архитектура гибридных мобильных приложений

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

Гибридная архитектура обычно выглядит следующим образом:

Презентационный слой имеет веб-ориентированное представление. Он построен с помощью веб-технологий, таких как HTML, CSS и JavaScript, который работает на движке рендеринга. Разработчики программного обеспечения используют PhoneGap, Apache Cordova или Ionic Capacitor, которые взаимодействуют с нативной частью через вызовы API.

Мобильные веб-приложения

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

Эти приложения создаются с помощью технологий HTML, JavaScript и CSS и автоматически обновляются из Интернета без какого-либо процесса представления или утверждения пользователя.

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

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

Заключение

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

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

Источник: scand.com

Что такое архитектура продукта, кто и как ее разрабатывает + примеры

Архитектура продукта — это компоненты из которых продукт состоит и связь между ними.

Миша Ряженка
Founder, Executive Partner

Какие есть типы архитектуры продукта?

Есть два основных типа архитектуры продукта: модульный и интегральный. Модульная архитектура продукта фокусируется на взаимосвязях между разными функциями продукта. Интегральная архитектура продукта фокусируется на функциях, назначении и внутреннем устройстве каждого элемента с краткими заметками о взаимосвязях между ними.

Миша Ряженка
Founder, Executive Partner

Как создать архитектуру продукта?

Архитектуру продукта создают в четыре этапа: Схема, Группировка функций и элементов схемы, Карта продукта, Связи между элементами.

Продакт–менеджер
Долгосрочная программа

Обучение с нуля профессии «Продакт–менеджер» в IT на реальных рыночных кейсах. Передадим вам практический коммерческий опыт и подготовим к трудоустройству.