Что такое архитектура в программировании
Перейти к содержимому

Что такое архитектура в программировании

  • автор:

Архитектура программного обеспечения

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

Обзор

Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best-practices), языков описания и формальная логика были разработаны в течение этого времени. ЕПИ-3-11 супер Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и разграничения полномочий. На сегодняшний день до сих пор нет согласия в отношении четкого определения термина «архитектура программного обеспечения».

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

История

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

В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.

Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.

Темы по программной архитектуре

Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.

Виды (views)

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

  • Функциональный/логический вид
  • Вид код/модуль
  • Вид разработки (development)/структурный
  • Вид параллельности выполнения/процесс/поток
  • Физический вид/вид развертывания
  • Вид с точки зрения действий пользователя
  • Вид с точки зрения данных

Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.

Базовые фреймворки для архитектуры ПО (software architecture frameworks)

Существуют следующие фреймворки, относящихся к области архитектуры ПО:

  • 4+1
  • RM-ODP (Reference Model of Open Distributed Processing)
  • Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).

Отличие архитектуры ПО от детального проектирования ПО

Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.

Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Детальное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.

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

Примеры архитектурных стилей и моделей

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

  • Blackboard
  • Клиент-серверная модель (client-server)
  • Архитектуры, построенные вокруг базы данных (database-centric architecture)
  • Распределенные вычисления (distributed computing)
  • Событийная архитектура (event-driven architecture)
  • Front end and back end
  • Неявные вызовы (implicit invocations)
  • Монолитное приложение (monolithic application)
  • Peer-to-peer
  • Пайпы и фильтры (pipes and filters)
  • Plugin
  • Representational State Transfer
  • Rule evaluation
  • Поиск-ориентированная архитектура
  • Сервис-ориентированная архитектура
  • Shared nothing architecture
  • Software componentry
  • Space based architecture
  • Структурированная
  • Трех-уровневая

Примечания

Ссылки

  • Крачтен Ф., Оббинк Х.,Стаффорд Д. Ретроспектива программных архитектур на сайте http://www.osp.ru
  • Software Architecture:Glossary, Software Engineering Institute (англ.)
  • Architecture: Publications, Software Engineering Institute (англ.)

Что такое архитектура в программировании

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

В книге An Introduction to Software Architecture Дейвид Гарлан (David Garlan) и Мэри Шоу (Mary Shaw) пишут, что архитектура — это особый уровень проекта: «Помимо создания алгоритмов и структур данных, необходимо решить еще одну принципиальную задачу — разработать общую структуру системы. Процесс разработки структуры включает в себя создание общей инфраструктуры организации системы и управления ею, выбор протоколов и методов синхронизации и доступа к данным, распределение функций системы между компонентами, физическое распределение, объединение элементов проекта, масштабирование, оптимизацию производительности и выбор оптимальных вариантов среди доступных альтернатив». [GAR93]

Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру «концепцией системы высочайшего уровня в своей среде» [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.

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

Описание архитектуры

Для обсуждения структуры программы сначала следует определить архитектурное представление, способ описания важных аспектов архитектуры. В RUP это описание фиксируется в Документе по архитектуре программного обеспечения.

Архитектурные представления

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

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

Типичный набор архитектурных представлений

Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает «значимый для архитектуры» элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется «моделью 4+1» [KRU95]. Модель содержит следующие компоненты:

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

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

Фокус архитектуры

Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:

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

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

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

Шаблоны архитектуры

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

Примеры шаблонов архитектуры

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

Категория Шаблон
Структура Уровни
Конвейеры и фильтры
Классная доска
Распределенные системы Посредники
Интерактивные системы Модель-представление-контроллер
Представление-абстракция-управление
Адаптивные системы Отражения
Микроядра

Две из этих категорий подробно описаны в данной главе в качестве иллюстрации идей. Подробное описание можно найти в книге [BUS96]. Шаблоны представлены в следующей широко распространенной форме:

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

    Большая система, нуждающаяся в декомпозиции

    Задача

    Система должна работать одновременно с несколькими уровнями абстракции. Например, система должна принимать во внимание вопросы управления аппаратным обеспечением, вопросы, связанные с общими службами, и вопросы, относящиеся к конкретным предметным областям. Крайне нежелательно разрабатывать вертикальные компоненты, в которых придется иметь дело со сложностями на всех уровнях сразу. Такой подход потребует многократного решения одних и тех же задач (вероятно, различными способами) в разных компонентах.

    • Компоненты системы должны быть взаимозаменяемы.
    • Изменение компонентов не должно нарушать стабильность системы в целом.
    • Схожие функции должны быть сгруппированы.
    • Сложные компоненты могут нуждаться в декомпозиции .
    Решение

    Структура системы должна представлять собой несколько слоев компонентов. Компоненты верхних слоев должны пользоваться компонентами нижних слоев (но ни в коем случае не наоборот). Не рекомендуется пользоваться компонентами «через слой» (единственный вариант, когда это оправданно — это ситуация, когда искусственно созданные промежуточные слои не несут полезной нагрузки).

    Примеры:

    1. Общие слои

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

    2. Уровни бизнес-системы

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

    Более подробная информация об этом шаблоне приведена в разделе Рекомендация: многослойные структуры.

    Имя шаблона

    Доска

    Контекст

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

    Задача

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

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

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

    Пример:

    На этой диаграмме показано структурное (или статическое) представление, смоделированное с помощью UML. Это часть параметризуемого кооперирования, для которого фактические параметры устанавливаются в момент создания экземпляра по шаблону.

    Архитектурный стиль

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

    Архитектурный эскиз

    Графическое изображение архитектурного представления называется архитектурным эскизом. Эскизы представлений, описанных выше, составляются из следующих диаграмм языка UML [UML01]:

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

    Процесс разработки архитектуры

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

    © Copyright IBM Corp. 1987, 2006. Все права защищены..

    Разработка архитектуры для чайников. Часть 1

    Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.

    И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же это собственно такое?

    Ниже я привёл несколько картинок которые описывают ту или иную архитектуру

    И как мы видим все эти картинки абсолютно разные. Так что же всё таки такое архитектура?

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

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

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

    Ну хорошо, мы разобрались что такое архитектура и зачем она собственно нужна, но как же её собственно строить?

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

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

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

    • fault tolerance (reliability) / отказоустойчивость (надёжность)
    • speed of development / скорость разработки
    • ease deployed / простота деплоя
    • scalability by the number of people in the project / масштабируемость по количеству человек в проекте
    • scalability in terms of requests per second / масштабируемость по количеству запросов в секунду
    • fast entry / exit to resolution / быстрый вход/выход в разработку
    • application deployment speed / скорость развертывания приложения
    • remove old code / избавиться от старого кода
    • complexity of adding new integrations / сложность новых интеграций
    • etc. / И т.д.

    Например на одном из моих проектов важно была отказоустойчивость, но вот масштабируемость проекта, чтобы на нём могли находиться тысяча человек одновременно — не требовалось. Есть проекты в которых наоборот нужно чтобы миллионы пользователей могли одновременно сидеть, но если у одного из них случались проблемы(например сообщение не отправилось за 5 секунд), то это не критично, отправим его через 10 секунд.

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

    Такс, а теперь давайте ещё раз повторим вопросы на которые нам нужно ответить. Их всего 5:

    1. Что мы делаем?
    2. Почему мы имеем текущую архитектуру?
    3. Почему нам нужна новая архитектура?
    4. Какие проблемы мы имеем с текущей архитектурой?
    5. Что хочет наш клиент от новой архитектуры?

    Ну а теперь мы можем приступать к разработке нашей новой архитектуры.

    Архитектура ПО: разница между архитектурой и проктированием

    Многие не знают, в чем состоит разница между архитектурой и проектированием приложения. Даже сами разработчики зачастую не могут разобрать строку кода и могут спутать элементы архитектуры приложения с элементами проектирования. Будучи разработчиком, я бы хотел объяснить эти понятия , а также разницу между проектированием приложения и его архитектурой. Помимо этого, я покажу вам, почему разработчикам важно хотя бы немного разбираться в архитектуре программного обеспечения и много — в проектировании. Итак, давайте начнем.

    Определение архитектуры программного обеспечения

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

    Характеристики архитектуры ПО

    Как я уже объяснил, характеристики ПО помогают понять требования к программному обеспечению и ожидания, относительно его на функциональном и техническом уровне. Поэтому, если владелец продукта говорит, что им приходится конкурировать в условиях быстро меняющегося рынка , значит, им следует быстро адаптировать свою бизнес-модель. Программное обеспечение должно «легко расширять свой функционал, состоять из блоков и быть легким в обслуживании», если мы хотим, чтобы оно было подготовлено качественно и вовремя. Если вы архитектор ПО, то должны знать, что основными параметрами для вас будут качество работы и низкая отказоустойчивость, масштабируемость и надежность. А теперь, определившись со всеми основными параметрами, вы слышите от своего руководителя, что бюджет на этот проект ограничен. Здесь вступает в дело ещё один параметр — осуществимость.

    Полный список параметров программного обеспечения или так называемых «качественных характеристик» вы найдете здесь.

    Архитектурные шаблоны программного обеспечения

    Большинство из вас, наверно, уже знакомы с термином «микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.

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

    Бессерверный архитектурный стиль

    Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
    Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».

    Более подробно прочитать о нем вы можете здесь.

    Архитектура, управляемая событиями

    Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж. Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.

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

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

    Архитектура микросервисов

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

    Проектирование программного обеспечения

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

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

    Принципы SOLID ( Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.

    • Принцип единственной ответственности означает, что каждый класс работает только над одной целью, ответственен только за неё и изменяется только по одной причине.
    • Принцип открытости/закрытости: класс должен быть открытым для расширения, но закрытым для изменений. Проще говоря, вы можете добавлять новую функциональность в класс, но не можете редактировать существующие функции таким образом, что они будут противоречить используемому коду
    • Принцип подстановки Барбары Лисков: согласно этому принципу, разработчик должен соблюдать наследственность таким образом, чтобы нигде не нарушалась логика приложения. Так, если новый класс «XyClass» происходит от родительского класса «AbClass», новый класс должен повторять функции родительского класса таким образом, чтобы они не изменяли поведение родительского класса. Тогда вы легко сможете использовать объект XyClass класса вместо объекта класса AbClass, не нарушая логики приложения.
    • Принцип разделения интерфейсов: Всё просто: класс способен реализовывать множество интерфейсов, создавайте свой код таким образом, чтобы классу никогда не приходилось реализовывать функцию, которая не важна для его задач. Вывод — разделяйте свои интерфейсы на категории.
    • Принцип инверсии зависимостей: Если вы когда-либо использовали TDD для создания своего приложения, вы знаете насколько важно расщеплять свой код перед тестированием и моделированием. Другими словами, если определенный класс «ex:Purchase» зависит от класса «Users», установка пользовательских объектов должна инициировать снаружи класса «Purchase».

    Шаблоны проектирования

    • Фабричная модель — самый часто используемый шаблон проектирования в мире OOП, так как он позволяет сэкономить много времени в будущем, когда потребуется изменить один из классов, который вы использовали. Рассмотрим на примере:

    Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:

    1 — $users = new Users();
    2 — $users = DataFactory::get(‘Users’);

    Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.

    • Адаптер (шаблон проектирования) — один из шаблонов структурного проектирования. Посмотрев на название, можно понять, что эта модель делает из неожидаемого использования класса ожидаемое.

    Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();

    Итак, вы вызвали эту функцию в 20 разных местах в приложении.

    А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();

    Теперь вам придется найти и переименовать эту функцию во всем приложении или создать адаптер-класс, как показано далее в примере:

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *