Проектирование архитектуры программного обеспечения – это один из этапов жизненного цикла архитектуры программного обеспечения. Как и в любом жизненном цикле программного проекта, эта деятельность связана с переводом требований в дизайн и реализацией. В частности, архитектору необходимо беспокоиться о следующих проблемах:
- Архитектурные требования. Среди всех требований некоторые будут иметь особое значение в отношении архитектуры программного обеспечения. Эти архитектурно значимые требования включают не только наиболее важные функциональные возможности системы и ограничения, которые необходимо учитывать, но также – и, что наиболее важно, – такие качественные характеристики, как высокая производительность, высокая доступность, простота разработки и надежная безопасность. Эти требования, наряду с четкой целью проектирования и другими архитектурными проблемами, которые никогда не могут быть записаны или могут быть невидимы для внешних заинтересованных сторон и компонентов по сравнению с другими.
- Архитектурный дизайн. Дизайн – это перевод из мира потребностей (требований) в мир решений с точки зрения структур, состоящих из кода, фреймворка и компонентов. Хороший дизайн – это тот, который удовлетворяет водителей.
- Архитектурная документация. Некоторый уровень предварительной документации (или эскизов) конструкций должен быть создан как часть архитектурного проектирования. Это действие, однако, относится к созданию документа большего формата из этих эскизов. Если проект небольшой и имеет прецедент, то архитектурная документация может быть минимальной. Напротив, если проект большой, если сотрудничают распределенные команды или существуют значительные технические проблемы, то архитектурная документация окупит усилия, вложенные в эту деятельность. В то время как документация часто избегается и создается программистами, она является стандартным, не подлежащим обсуждению результатом практически в любой другой инженерной дисциплине. Если ваша система достаточно велика и если она критически важна, она должна быть задокументирована. В других инженерных дисциплинах “план” – своего рода документированный проект – является абсолютно необходимым шагом на пути к внедрению и выделению ресурсов
- Архитектурная оценка. Как и в случае с документацией, если ваш проект нетривиален, то вы обязаны оценить его перед собой и своими заинтересованными сторонами, то есть убедиться, что принятые решения соответствуют критическим требованиям. Могли бы вы предоставить код без тестирования? Конечно, нет. Точно так же, зачем вам выделять огромные ресурсы на разработку архитектуры, если вы сначала не “протестировали” дизайн? Возможно, вы захотите сделать это при первом создании системы или при ее серьезном рефакторинге. Обычно оценка проводится неофициально и внутри компании, но для более важных проектов желательно, чтобы формальная оценка проводилась внешней командой
- Архитектурная реализация/проверка соответствия. Наконец, вам нужно реализовать созданную вами архитектуру. Как архитектору, вам может потребоваться изменить дизайн по мере роста системы и изменения требований. Это нормально. В дополнение к этой настройке, ваша главная ответственность во время внедрения заключается в обеспечении соответствия кода дизайну. Если разработчики неверно реализуют архитектуру, они могут подорвать качества, которые вы разработали. Опять же, рассмотрим, что делается в других областях инженерии. Когда заливается бетонный фундамент для нового здания, здание, которое опирается на этот фундамент, не строится до тех пор, пока фундамент не будет сначала протестирован, обычно с помощью образца керна, чтобы убедиться, что он достаточно прочный, достаточно плотный, достаточно непроницаемый для воды и газов и так далее. Без проверки соответствия у нас нет возможности обеспечить качество того, что впоследствии будет построено.
Роль архитектора
Архив – это гораздо больше, чем “просто”дизайнер”. Эту роль может играть один или несколько человек, обладающих длинным списком обязанностей, навыков и знаний, которые должны быть выполнены, чтобы она была успешной. Эти предварительные условия включают следующее:
- Лидерство: наставничество, формирование команды, формирование видения, тренер
- Коммуникация: как техническая, так и нетехническая, поощряющая сотрудничество
- Переговоры: работа с внутренними и внешними заинтересованными сторонами и их противоречивыми потребностями и ожиданиями
- Технические навыки: навыки жизненного цикла, опыт работы с технологиями, непрерывное обучение, кодирование
- Проектные навыки: составление бюджета, персонал, управление расписанием, управление рисками
- Аналитические навыки: архитектурный анализ, общее аналитическое мышление для управления проектами и измерения
Почему архитектурный дизайн так важен? Проект обходится очень дорого из-за того, что он не принимает определенных решений или принимает их недостаточно рано. Без некоторого архитектурного мышления и некоторых ранних проектных работ вы не сможете с уверенностью предсказать стоимость проекта, график и качество. Без архитектуры преимущества, которые должна принести система, будет гораздо труднее реализовать. Если вы не примете некоторые ключевые архитектурные решения на ранней стадии и не допустите ухудшения архитектуры, вы не сможете поддерживать скорость spring, потому что вы не сможете легко реагировать на запросы на изменения. Такие решения могут включать:
- Выбор инструментов
- Структурирование среды разработки
- Вспомогательные выпуски
- DevOps – разработчики
Архитектурные проблемы
Архитектурные проблемы включают дополнительные аспекты, которые необходимо учитывать как часть архитектурного проектирования, но которые не выражены в виде рациональных требований. Существует несколько различных типов проблем.
- Общие проблемы. Это “широкие” проблемы, с которыми приходится сталкиваться при создании архитектуры, такие как определение общей структуры системы, распределение функциональных возможностей по модулям, распределение модулей по группам, организация базы кода, запуск и завершение работы, а также поддержка доставки, развертывания и обновлений.
- Конкретные проблемы. Это более подробные системные внутренние проблемы, такие как управление исключениями, управление зависимостями, настройка, ведение журнала, аутентификация, авторизация, кэширование и так далее, Которые являются общими для большого числа приложений. Некоторые конкретные проблемы решаются в эталонных архитектурах, но другие будут уникальными для вашей системы. Особые проблемы также возникают в результате предыдущих проектных решений. Например, вам может потребоваться обратиться к управлению сеансами, если вы ранее решили использовать эталонную архитектуру для разработки веб-приложений.
- Внутренние требования. Эти требования обычно явно не указываются в традиционных документах о требованиях, например, клиенты обычно редко выражают их. Внутренние требования могут касаться аспектов, которые облегчают разработку, развертывание, эксплуатацию или техническое обслуживание системы. Их иногда называют “производными требованиями”.
- Проблемы. Они являются результатом аналитических мероприятий, таких как анализ проекта, поэтому они могут отсутствовать изначально. Например, архитектурная оценка может выявить риск, который требует внесения некоторых изменений в текущий проект.
Некоторые решения, связанные с архитектурными проблемами, могут быть тривиальными или очевидными. Например, ваша структура развертывания может быть одним процессором для встроенной системы или одним мобильным телефоном для приложения. Ваша эталонная архитектура может быть ограничена политикой компании. Ваши политики аутентификации и авторизации могут быть продиктованы архитектурой вашего предприятия и реализованы в общей среде. В других случаях, однако, решения, необходимые для удовлетворения конкретных проблем, могут быть менее очевидными – например, при управлении исключениями или проверке входных данных или структурировании базы кода. Исходя из своего прошлого опыта, мудрые архитекторы обычно осознают проблемы, связанные с определенным типом системы, и необходимость принятия проектных решений для их решения. Неопытные архитекторы обычно менее осведомлены о таких проблемах; поскольку эти проблемы, как правило, являются скорее скрытыми, чем явными, они могут не рассматривать их как часть процесса проектирования, что часто приводит к возникновению проблем позже или. Архитектурные проблемы часто приводят к введению новых сценариев атрибутов качества. Например, проблема “поддержки ведения журнала” слишком расплывчата и нуждается в уточнении.
Выбор компонентов, разработанных извне, что является ключевым аспектом процесса проектирования, может быть сложной задачей из-за их большого количества. Вот несколько критериев, которые вы должны учитывать при выборе компонентов, разработанных извне:
- Проблема, которую он решает. Is – это что-то конкретное, например фреймворк для объектно-ориентированного сопоставления отношений или что-то более общее, например платформа.
- Стоимость. Какова стоимость лицензии, и если она бесплатная, какова стоимость поддержки и обучения?
- Тип лицензии. Есть ли у него лицензия, совместимая с целями проекта?
- Поддержка. Хорошо ли это поддерживается? Существует ли обширная документация об этой технологии? Существует ли обширное сообщество пользователей или разработчиков, к которому вы можете обратиться за советом?
- Кривая обучения. Как трудно освоить эту технологию. Другие сотрудники вашей организации уже освоили его? Доступны ли эти курсы?
- Зрелость. Является ли это технологией, которая только что появилась на рынке, которая может быть захватывающей, но все еще относительно нестабильной или неподдерживаемой?
- Популярность. Является ли это относительно широко распространенной технологией? Являются ли эти положительные отзывы или принятие зрелыми организациями? Легко ли будет нанять людей, обладающих глубокими знаниями в этой области? Существует ли активное сообщество разработчиков или группа пользователей?
- Совместимость и простота интеграции. Совместим ли он с другими технологиями, используемыми в проекте? Может ли он быть легко интегрирован в проект? Поддержка важнейших атрибутов качества. Ограничивает ли это такие атрибуты, как производительность? Является ли он безопасным и надежным?
- Размер. Окажет ли использование технологии негативное влияние на размер разрабатываемого приложения
В своей статье “Общая модель проектирования архитектуры программного обеспечения, основанная на пяти промышленных подходах”, Хофмейстер и ее коллеги сравнили пять методов проектирования архитектуры промышленного программного обеспечения и извлекли из их общих черт общий подход к проектированию архитектуры программного обеспечения. Полученная общая модель состоит из трех основных видов деятельности, которые присутствуют во всех пяти рассмотренных моделях:
- Архитектурный анализ. В этом упражнении требования (называемые проблемами) и системный контекст используются в качестве входных данных для определения набора архитектурно значимых требований (ASR).
- Архитектурный синтез. Эта деятельность описывается как основа архитектурного проектирования. В нем предлагается архитектурное решение для набора ASR, переходящее от проблемы к пространству решений. Результатами этой деятельности являются архитектурные решения-кандидаты, которые представляют собой частичные или полные архитектурные проекты, включающие информацию об обосновании.
- Архитектурная оценка. Эта деятельность гарантирует, что архитектурные решения являются правильными. Возможные архитектурные решения оцениваются по ASR. Ожидается несколько оценок различных архитектурных решений, но конечный результат – это проверенная архитектура.
Анализ – это процесс разбиения сложной сущности на составные части с целью ее понимания . Противоположностью анализа является синтез. Таким образом, анализ и проектирование являются взаимосвязанными видами деятельности. В процессе проектирования деятельность по анализу может относиться к нескольким аспектам
- Изучение исходных данных для процесса проектирования, чтобы понять проблему, решение которой вы собираетесь разработать.
- Изучение альтернативных концепций дизайна, которые вы определили для решения проблемы проектирования, чтобы выбрать наиболее подходящую из них. В таких ситуациях анализ заставляет вас предоставить конкретные доказательства вашего выбора.
- Обеспечение соответствия решений, принятых в процессе проектирования (или итерации).
Оригинал: “https://dev.to/vrnsky/software-architecture-3-final-e3c”