Как нарисовать архитектуру приложения
Архитектурный анализ представляет собой набор мероприятий по созданию и совершенствованию архитектуры программного обеспечения системы. При итеративном использовании такое обдумывание архитектуры помогает ставить и решать задачи при разработке программного обеспечения, не требуя значительных усилий по предварительному созданию архитектуры. Архитектурный анализ имеет решающее значение для любой сложной программной системы. Что бы ни говорили догматики гибкой разработки, успешное проектирование программного обеспечения без архитектурного анализа невозможно.
Чтобы наметить целевую архитектуру своей системы, архитектор программного обеспечения обычно выполняет следующие действия.
- Выявление значимых требований: основные функциональные и нефункциональные требования, оказывающие существенное влияние на архитектуру.
- Определение предполагаемой архитектуры: общая архитектура системы с учетом архитектурных ограничений и целей.
- Определение исходной модели развертывания: топология, отражающая узлы развертывания системы.
- Определение модели домена: ключевые бизнес-объекты и их взаимодействие.
Как правило, во время этапов разработки выполняются следующие мероприятия по уточнению архитектуры.
- Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
- Уточнение элементов структуры: архитектурно значимые элементы структуры.
- Уточнение архитектуры развертывания: единицы и топологии развертывания.
Итерационные мероприятия описаны во второй статье этого цикла.
Хотя эта статья не содержит обзора мероприятий, любой опытный программист знает, что архитектура должна регулярно проверяться на соответствие требованиям и потребностям группы. Поэтому нужен эффективный механизм оформления архитектуры и ее передачи различным участникам процесса.
В 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. Стандартный профиль архитектуры
Рисунок 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. Схема сценария использования меню заказов
Когда значимые требования выявлены, архитектор создает общую архитектуру. Сегодня системы редко разрабатываются с нуля. Мы обогащаем существующие приложения, модернизируем устаревшие системы и повторно используем имеющиеся ресурсы. Архитектор применяет накопленный опыт работы с аналогичными системами и обеспечивает рассмотрение всех целей и ограничений. Проект архитектуры принимает во внимание как функциональные (сценарии использования, истории, бизнес-процессы), так и нефункциональные (доступность, производительность, масштабируемость) требования, предъявляемые к системе.
Мы выбрали для своего примера N-уровневую архитектуру (рисунок 10) с Web-приложением, к которому можно обращаться и через Web-сервисы с клиентских устройств разного типа (о многоуровневых приложениях см. в разделе Ресурсы).
Обратите внимание, что эта технологическая схема (рисунок 10), созданная в RSA, на данном этапе довольно проста и может быть выполнена в течение короткого мозгового штурма. На рисунке показаны основные компоненты и стек технологий, выбранных для разработки решения.
Рисунок 10. Эскиз N-уровневой архитектуры для системы Online Catering
Используя представленный выше эскиз, архитектор может нарисовать картину развертывания модели. Он изображает основные компоненты программного и аппаратного обеспечения и их общее взаимодействие. Схема развертывания принимает во внимание ограничения среды развертывания и служит хорошим средством обмена информацией между группами разработки и инфраструктуры.
Спецификация UML предоставляет набор элементов для определения моделей развертывания. Однако в том, что касается возможностей развертывания, UML оказался ограниченным. В результате он не получил широкого распространения в отрасли, даже среди тех, кто интенсивно использует UML. RSA предоставляет богатый набор инструментов для определения топологий развертывания (логических, физических и примеров развертывания). Достоинства топологий RSA проявляются там, где пасуют UML-модели: в части простоты, многократного использования и отслеживания (подробнее о топологиях развертывания см. в разделе Ресурсы).
На схеме развертывания (рисунок 11) показаны различные компоненты оборудования, необходимые для размещения приложения. RSA содержит банк изображений, помогающих сделать диаграмму более наглядной, и позволяет добавлять свои собственные изображения для обозначения специальных элементов модели.
Рисунок 11. Узлы развертывания системы Online Catering
При создании бизнес-приложений исходная модель домена помогает группе разработчиков изучить основные бизнес-объекты и отношения между ними. Архитектор может получать информацию из различных источников, таких как функциональные требования, сценарии или бизнес-процессы.
Простой способ изучения объектов предприятия в RSA обеспечивает аналитический профиль. Этот профиль содержит три стереотипа, которые можно применять к элементам UML (рисунок 12).
Рисунок 12. Стереотипы UML
Стереотип Boundary используется для представления класса, действующего в качестве интерфейса к системе. Класс Control описывает компонент, осуществляющий контроль над другими классами. Стереотип Entity определяет класс, содержащий данные.
На этом этапе нам нужны только данные, поэтому используется только стереотип Entity. Важно составить общую лексику реализуемой системы. Это отправная точка аналитической модели, которая создается на следующем шаге.
Шаблон Analysis Model, присутствующий в RSA, готов к применению и содержит специальный пакет Perspective overviews для сбора информации, относящийся к ключевым понятиям (рисунок 13).
Рисунок 13. Пакет Perspective overviews для системы Online Catering
Чтобы составить первый проект модели домена с помощью аналитических стереотипов, архитектор может воспользоваться простой схемой класса (содержащей ключевые бизнес-объекты - рисунок 14).
Рисунок 14. Модель домена Online Catering
Имеются и другие способы определения модели домена в RSA. Во-первых, можно выбрать создание простого эскиза, отражающего бизнес-объекты (рисунок 15).
Рисунок 15. Эскиз модели домена системы Online Catering
На этом этапе мы определили план архитектуры программного обеспечения сложной программной системы. Зная, какие представления полезны для тех или иных субъектов и какие требования оказывают значительное влияние на техническое решение, мы наметили соответствующую целевую архитектуру. За короткое время (итерация 0) мы собрали в RSA ключевую информацию, связанную с технологиями, развертыванием и моделями домена.
Во второй статье этого цикла мы покажем, как использовать RSA для уточнения архитектуры сложной программной системы.
Есть несколько архитектурных стратегий по разработк е приложения, которые пользуются популярностью. На них мы остановимся немного подробнее.
Многослойная архитектура
слой представления — отвечает за интерфейс пользователя;
слой бизнес-логики — отвечает за функционал и логику приложения и не отвечает за интерфейс;
слой передачи данных — отвечает за работу с базами данных и обработку информации.
простой в реализации;
абстрактной;
защищенной за счет изолированности каждого слоя;
легко управляемой и масштабируемой.
Многоуровневая архитектура приложений
одноуровневая,
двухуровневая,
трехуровневая.
клиент — отвечает за обработку интерфейса, логики приложения и передачу информации;
сервер — отвечает за работу хранилищ и баз данных, а также за обработку информации.
клиент,
сервер для обработки,
базы данных для хранения.
Микросервисная архитектура приложений
изолированность каждого отдельного компонента;
сбой одного компонента не затрагивает работоспособность всего приложения;
удобно масштабировать и внедрять обновления;
и др.
Заключение
Архитектура приложений — это далеко не однозначный вопрос. При разработке приложения существует очень много факторов , влияющих на выбор архитектуры. Поэтому многие доступные виды « родились » совсем недавн о б лагодаря трудам неравнодушных разработчиков. Если ваша цель — разработать собственную архитектуру приложений, тогда вам обязательно нужно прочитать книгу « Руководство Microsoft по проектированию архитектуры приложений » .
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Перед тем, как создавать приложение, необходимо продумать его архитектуру. Как это сделать правильно рассмотрим в статье.
Упростите жизнь разработчикам
Поскольку самый ценный ресурс — человеческий, любой используемый фреймворк или инструмент должны помогать разработчику оптимизировать свою продуктивность.
Что упростит разработчику жизнь:
- Сделайте приложение максимально простым и понятным;
- Не перегружате его излишней функциональностью — внедряйте только необходимые фичи;
- Используйте общепринятый подход к решению задач;
- Используйте вспомогательные инструменты;
- Сделайте приложение выразительным — каждая задача, решаемая в нём, должна быть очевидной;
- Если вы планируете использовать сторонние библиотеки, то позаботьтесь о том, чтобы они были наилучшими.
Уделите внимание мелочам
- Решайте все задачи, поставленные перед проектом, последовательно;
- Сделайте так, чтобы самые часто встречающиеся задачи выполнялись проще и прозрачней других;
- Сделайте приложение легкорасширяемым;
- Сделайте его настолько простым, насколько это возможно;
Помните о юзабилити
Уровень юзабилити жизненно важен по ряду причин. Он повышает доверие и удовлетворённость клиентов и снижает затраты.
- Исключите из приложения технологии, специфичные для конкретного поставщика;
- Ваше приложение должно поддерживать последние стандарты;
- Обеспечьте приложению быстрый отклик;
- Ваше приложение должно по максимуму использовать графические возможности;
- Добавьте анимацию там, где это уместно;
- Добавьте поддержку A/B тестирования;
- Включите в приложение поддержку аналитики.
Обеспечьте безопасность
Безопасность — это способность системы снизить вероятность злонамеренных или случайных действий за пределами ожидаемого использования системы и предотвратить раскрытие или потерю информации.
- Проходите сторонние пентесты;
- Внедряйте стандарты безопасности везде, где это возможно;
- Следуйте лучшим практикам безопасности.
Обеспечьте надёжность
Надёжность — это способность системы продолжать работать ожидаемым образом с течением времени. Надёжность измеряется как вероятность того, что система не даст сбой и что она будет выполнять свои функции в течение заданного интервала времени.
- Очевидно, что в системе не должно происходить сбоев, но всё же они происходят. Нужно обеспечить журналирование и анализ таких сбоев;
- Система должна быть максимально автономной — если произошёл сбой, будет идеально, если она сама с этим справится;
С умом подходите к производительности
- Обеспечьте приложению уровень производительности, соответствующий вашей задаче и возможностям. Иногда увеличение производительности может слишком дорого стоить с точки зрения затрачиваемых человеческих и аппаратных ресурсов. Если производительность для ваших задач не критична, не стоит на этом зацикливаться;
- Минимизируйте задержку до появления интерфейса (< 250 мс для 90% запросов, < 2 с для всех запросов) или добавьте механизмы для её компенсации, например, кеширование.
Заложите масштабируемость
Масштабируемость — это способность системы обрабатывать возрастающую нагрузку без влияния на производительность, либо способность легко увеличить эту производительность.
- Отдайте предпочтение горизонтальному, а не вертикальному масштабированию;
- Заложите возможность легко добавить больше узлов системы;
- Позвольте балансировать нагрузку между узлами;
- Не перегружайте каждый отдельно взятый узел — распределяйте нагрузку.
Заложите тестируемость
Тестируемость — показатель того, насколько хорошо система или её компоненты позволяют создавать требования для тестирования и проводить тесты, чтобы определить, выполняются ли эти требования.
- Внедрите в систему механизмы для имитации данных;
- Убедитесь, что процессы, работающие с наборами данных, быстро обрабатывают наборы небольшого размера;
- Добавьте в приложение возможность автоматизации тестирования интерфейса.
Внедрите интероперабельность
Насколько хорошо ваша система взаимодействует с другими? Коммуникационные протоколы, интерфейсы и форматы данных являются ключевыми аспектами интероперабельности. Стандартизация также является важным аспектом, на который нужно обратить внимание при разработке интероперабельной системы.
- По возможности используйте открытые стандарты;
- Если это по какой-то причине невозможно, то опубликуйте используемые стандарты;
- Чем больше сторонних систем поддерживает ваше приложение, тем лучше.
Обеспечьте прозрачность и устранение неполадок
Когда что-то идёт не так, насколько легко проследить ошибку и воспроизвести её?
- Журналируйте все ошибки и важные события;
- Сделайте трассировку стека простой для понимания;
- Включайте в лог все данные, необходимые для повторного воспроизведения ошибки;
- Добавьте возможность включения/выключения отладочных логов;
- Сделайте так, чтобы течение процесса, вызвавшего ошибку, можно было легко проследить через всё приложение.
Используйте популярные фреймворки
У сторонних библиотек, которые вы используете, должно быть активное сообщество. Чем больше у продукта или фреймворка сообщество, тем проще будет с ним работать, так как, скорее всего, многие проблемы уже решили до вас другие пользователи.
Характеристики социально активного приложения:
Сделайте развёртывание максимально простым
Развёртывание и распространение в разных окружениях дорого обходится. Продукт, который трудно развернуть, требует более длительных циклов релиза и затрудняет реагирование на внесение изменений или исправление ошибок.
- Добавьте автоматическое развёртывание по сценарию;
- Упростите процесс написания автоматизированных тестов;
- Минимизируйте время сборки системы;
- Минимизируйте физический размер системы;
- Упростите откат системы, чтобы облегчить себе жизнь, если что-то пойдёт не так.
При проектировании вашего приложения пройдитесь по этому списку и посмотрите, сможете ли вы поставить галочку напротив как можно большего количества пунктов. Если вы будете учитывать все эти советы при создании своего приложения, то в итоге получите лучший результат.
Что такое архитектура веб-приложений? Из этого руководства вы можете изучить основы архитектуры веб-приложений. Мы обсудим, как работает архитектура веб-приложения, какие компоненты, слои и модели существуют
Архитектура веб-приложения в основном представляет отношения и взаимодействия между такими компонентами, как пользовательские интерфейсы, мониторы обработки транзакций, базы данных и другие. Основная цель - убедиться, что все элементы правильно работают вместе.
Логика довольно проста: когда пользователь вводит URL-адрес в браузере и нажимает «ввод», браузер делает запрос к серверу. Сервер отвечает, а затем показывает требуемую веб-страницу. Все эти компоненты создают архитектуру веб-приложения.
Как работает системная архитектура для веб-приложений?
Все приложения состоят из двух частей - клиентской (front-end) и серверной (back-end).
Поэтому, когда вы вводите свои учетные данные в регистрационную форму, вы имеете дело с внешним интерфейсом, но как только вы нажимаете «ввод» и регистрируетесь - это серверная часть заставляет его работать.
При правильной работе клиентская и серверная стороны составляют архитектуру программного обеспечения веб-приложения.
Слои и компоненты архитектуры веб-приложений
Чтобы лучше понять архитектуру веб-приложения, вам следует погрузиться в его компоненты и уровни. Веб-приложения разделяют свои основные функции на уровни. Это позволяет заменять или обновлять каждый слой независимо.
Базовые компоненты архитектуры веб-приложений
Веб-архитектура имеет компоненты пользовательского интерфейса и структурные компоненты. Последние также делятся на клиентские и серверные.
Компоненты пользовательского интерфейса
Компоненты пользовательского интерфейса обозначают все элементы интерфейса, такие как журналы активности, информационные панели, уведомления, настройки и многое другое. Они являются частью макета интерфейса веб-приложения.
Структурные компоненты состоят из клиентской и серверной сторон:
Клиентский компонент разработан с HTML, CSS или JavaScript. Веб-браузеры запускают код и преобразуют его в интерфейс, поэтому нет необходимости в настройке операционной системы.
Уровни архитектуры веб-приложений
Существует четыре общих уровня веб-приложений:
- Уровень представления (PL)
- Уровень обслуживания данных (DSL)
- Уровень бизнес-логики (BLL)
- Уровень доступа к данным (DAL)
Уровень службы данных
DSL передает данные, обработанные уровнем бизнес-логики, на уровень представления. Этот уровень гарантирует безопасность данных, изолируя бизнес-логику со стороны клиента.
Уровень доступа к данным
DAL предлагает упрощенный доступ к данным, хранящимся в постоянных хранилищах, таких как двоичные файлы и файлы XML. Уровень доступа к данным также управляет операциями CRUD - создание, чтение, обновление, удаление.
Типы архитектуры веб-приложений
Можно выделить несколько типов архитектуры веб-приложений, в зависимости от того, как логика приложения распределяется между клиентской и серверной сторонами. Наиболее распространенные архитектуры веб-приложений:
- Одностраничные веб-приложения
- Многостраничные веб-приложения
- Архитектура микросервисов
- Бессерверная архитектура
- Прогрессивные веб-приложения
Одностраничное приложение или SPA
SPA - это веб-сайт или веб-приложение, которое загружает всю необходимую информацию при входе на страницу. Одностраничные приложения имеют одно существенное преимущество - они обеспечивают потрясающий пользовательский интерфейс, поскольку пользователи не испытывают перезагрузки веб-страниц. Одностраничные веб-приложения часто разрабатываются с использованием фреймворков JavaScript, таких как Angular, React и других.
Известные СПА : Gmail, Facebook, Twitter, Slack.
Многостраничное приложение или MPA
Многостраничные приложения более популярны в Интернете, так как в прошлом все веб-сайты были MPA. В наши дни компании выбирают MPA, если их веб-сайт довольно большой (например, eBay). Такие решения перезагружают веб-страницу для загрузки или отправки информации с / на сервер через браузеры пользователей.
Известные MPA: eBay, Amazon.
Одностраничное приложение или многостраничное приложение ? У многостраничного и одностраничного приложения есть недостатки и преимущества.
Архитектура микросервисов
Чтобы понять архитектуру микросервисов , лучше сравнить ее с монолитной моделью.
Традиционная монолитная архитектура веб-приложения состоит из трех частей - базы данных, клиентской и серверной сторон. Это означает, что внутренняя и внешняя логика, как и другие фоновые задачи, генерируются в одной кодовой базе. Чтобы изменить или обновить компонент приложения, разработчики программного обеспечения должны переписать все приложение.
Что касается микросервисов, этот подход позволяет разработчикам создавать веб-приложение из набора небольших сервисов. Разработчики создают и развертывают каждый компонент отдельно.
Архитектура микросервисов выгодна для больших и сложных проектов, поскольку каждый сервис может быть изменен без ущерба для других блоков. Поэтому, если вам нужно обновить логику оплаты, вам не придется на время останавливать работу сайта.
Известные проекты: Netflix, Uber, Spotify, PayPal.
- Монолитные и микросервисы
- Бессерверная архитектура
Что это означает?
Чтобы сохранить веб-приложение в Интернете, разработчики должны управлять серверной инфраструктурой (виртуальной или физической), операционной системой и другими процессами хостинга, связанными с сервером. Поставщики облачных услуг, такие как Amazon или Microsoft, предлагают виртуальные серверы, которые динамически управляют распределением машинных ресурсов. Другими словами, если ваше приложение испытывает огромный всплеск трафика, к которому ваши серверы не готовы, приложение не будет отключено.
Прогрессивные веб-приложения или PWA
Одна из основных тенденций в разработке веб-приложений последних лет - это прогрессивные веб-приложения. Это веб-решения, которые работают как собственные приложения на мобильных устройствах. PWA предлагают push-уведомления, автономный доступ и возможность установить приложение на домашний экран.
Для создания PWA разработчики используют «языки веб-программирования», такие как HTML, CSS и JavaScript. Если приложению требуется доступ к функциям устройств, разработчики используют дополнительные API - NFC API, API геолокации, Bluetooth API и другие.
Известные PWA: Uber, Starbucks, Pinterest.
Как разработать архитектуру для веб-приложения
Качественная архитектура веб-приложения делает процесс разработки более эффективным и простым. Веб-приложение с продуманной архитектурой легче масштабировать, изменять, тестировать и отлаживать.
Читайте также: