Microsoft Application Architecture Guide, 2nd Edition

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


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


Параметры качестваПараметры качества – это общие свойства архитектуры, которые оказывают влияние на поведение во время выполнения, дизайн системы и взаимодействие с пользователем. Та степень, с которой приложение обеспечивает требуемое сочетание параметров качества, таких как удобство и простота использования, производительность, надежность и безопасность, определяет успешность дизайна и общее качество программного продукта. При проектировании приложения, отвечающего любому из этих параметров, необходимо учесть влияние и других требований, должны быть проанализированы плюсы и минусы по отношению к другим параметрам качества. Важность или приоритетность каждого из параметров качества для разных систем разная. Например, для бизнес-приложения (line-of-business, LOB) производительность, масштабируемость, безопасность и удобство использования будут более важны, чем возможность взаимодействия с другими системами. А вот для коробочного приложения такая возможность будет иметь большее значение, чем для LOB-приложения.
Параметры качества представляют функциональные области, которые потенциально могут оказывать влияние на все приложение, на все его слои и уровни. Некоторые параметры относятся ко всему дизайну системы, тогда как другие касаются только времени выполнения, времени проектирования или взаимодействия с пользователем. Следующий список систематизирует сведения о параметрах качества и помогает понять, на какие сценарии их влияние наиболее вероятно:
 Общесистемные качества. Общие качества системы в целом, такие как возможность технической поддержки и тестируемость.
 Качества времени выполнения. Качества системы, проявляемые непосредственно во время выполнения, такие как доступность, возможность взаимодействия с другими системами, управляемость, производительность, надежность, масштабируемость и безопасность.
 Конструктивные качества. Качества, отражающие дизайн системы, такие как концептуальная целостность, гибкость, удобство и простота обслуживания и возможность повторного использования.
 Пользовательские качества. Удобство и простота использования системы.
Более подробно о том, как обеспечить реализацию соответствующих параметров качества конструкцией, рассказывается в главе 16, «Параметры качества».


Сквозная функциональностьСквозная функциональность – это аспекты дизайна, которые могут применяться ко всем слоям, компонентам и уровням. Также это те области, в которых чаще всего делаются ошибки, имеющие большое влияние на дизайн. Приведем примеры сквозной функциональности:
 Аутентификация и авторизация. Как правильно выбрать стратегию аутентификации и авторизации, передачи идентификационных данных между слоями и уровнями и хранения удостоверений пользователей.
 Кэширование. Как правильно выбрать технику кэширования, определить данные, подлежащие кэшированию, где кэшировать данные и как выбрать подходящую политику истечения срока действия.
 Связь. Как правильно выбрать протоколы для связи между слоями и уровнями, обеспечения слабого связывания между слоями, осуществления асинхронного обмена данными и передачи конфиденциальных данных.
 Управление конфигурацией. Как выявить данные, которые должны быть настраиваемыми, где и как хранить данные конфигурации, как защищать конфиденциальные данные конфигурации и как обрабатывать их в серверной ферме или кластере.
Управление исключениями. Как обрабатывать и протоколировать исключения и обеспечивать уведомления в случае необходимости.
 Протоколирование и инструментирование. Как выбрать данные, подлежащие протоколированию, как сделать протоколирование настраиваемым, и как определить необходимый уровень инструментирования.
 Валидация. Как определить, где и как проводить валидацию; как выбрать методики для проверки длины, диапазона, формата и типа; как предотвратить и отклонить ввод недопустимых значений; как очистить потенциально злонамеренный и опасный ввод; как определить и повторно использовать логику валидации на разных слоях и уровнях приложения.
Подробнее о том, как обеспечить правильную обработку сквозной функциональности, рассказывается в главе 17, «Сквозная функциональность».


Вопросы, требующие особого внимания при проектированииАнализ параметров качества и сквозной функциональности в связи с имеющимися требованиями позволяет сосредоточиться на конкретных функциональных областях. Например, безопасность, несомненно, является жизненно важным фактором при проектировании и присутствует во многих слоях и во многих аспектах архитектуры. Сквозная функциональность, относящаяся к безопасности, является ориентиром, указывающим на области, на которых следует заострить внимание. Категории сквозной функциональности могут использоваться для разделения архитектуры приложения для дальнейшего анализа и выявления уязвимых мест приложения. Такой подход обеспечивает создание дизайна с оптимальным уровнем безопасности. При обсуждении сквозной функциональности относящейся к безопасности рекомендуется обратить внимание на следующие вопросы:
 Аудит и протоколирование. Кто, что сделал и когда? Приложение функционирует в нормальном режиме? Аудит занимается вопросами регистрации событий, связанных с безопасностью. Протоколирование касается того, как приложение публикует данные о своей работе.
 Аутентификация. Кто вы? Аутентификация – это процесс, при котором одна сущность четко и однозначно идентифицирует другую сущность, обычно это делается с помощью таких учетных данных, как имя пользователя и пароль.
 Авторизация. Что вы можете делать? Авторизация определяет, как приложение управляет доступом к ресурсам и операциям.
 Управление конфигурацией. В каком контексте выполняется приложение? К каким базам данных подключается? Как выполняется администрирование приложения? Как защищены эти настройки? Управление конфигурацией определяет, как приложение реализует эти операции и задачи.
 Шифрование. Как реализована защита секретов (конфиденциальных данных)? Как осуществляется защита от несанкционированного доступа данных и библиотек (целостности)? Как передаются случайные значения, которые должны быть
криптографически стойкими? Шифрование и криптография занимается вопросами реализации конфиденциальности и целостности.
 Обработка исключений. Что делает приложение при сбое вызова его метода? Насколько полные данные об ошибке оно предоставляет? Обеспечивает ли оно понятные для конечных пользователей сообщения об ошибках? Возвращает ли оно ценные сведения об исключении вызывающей стороне? Выполняется ли корректная обработка произошедшего сбоя? Предоставляет ли приложение администраторам необходимую информацию для проведения анализа основных причин сбоя? Обработка исключений касается того, как исключения обрабатываются в приложении.
 Валидация входных данных. Как определить, что поступаемые в приложение данные действительные и безопасные? Выполняется ли ограничение ввода через точки входа и кодировка вывода через точки выхода? Можно ли доверять таким источникам данных, как базы данных и общие файлы? Проверка ввода касается вопросов фильтрации, очистки или отклонения вводимых в приложение данных перед их дополнительной обработкой.
 Конфиденциальные данные. Как приложение работает с конфиденциальными данными? Обеспечивает ли оно защиту конфиденциальных данных пользователей и приложения? Здесь решаются вопросы обработки приложением любых данных, которые должны быть защищены либо при хранении в памяти, либо при передаче по сети, либо при хранении в постоянных хранилищах.
 Управление сеансами. Как приложение обрабатывает и защищает сеансы пользователей? Сеанс – это ряд взаимосвязанных взаимодействий пользователя и приложения.
Эти вопросы помогут принять основные проектные решения по безопасности приложения и задокументировать их как часть архитектуры. Например, на рис. 3 показано, как аспекты безопасности обозначены в архитектуре типового Веб-приложения.


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


Оценки на основании сценариевОценки на основании сценариев – это мощный метод анализа дизайна архитектуры. При такой оценке основное внимание направлено на наиболее важные с точки зрения бизнеса и имеющие набольшее влияние на архитектуру сценарии. Рассмотрите возможность применения одной из следующих типовых методик:
 Метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM). Изначально SAAM создавался для оценки модифицируемости, но позже был расширен для анализа архитектуры относительно показателей качества, таких как модифицируемость, портируемость, расширяемость, интегрируемость и функциональный охват.
 Метод анализа архитектурных компромиссов (Architecture Tradeoff Analysis Method, ATAM). ATAM – это доработанная и улучшенная версия SAAM, которая позволяет пересматривать архитектурные решения относительно требований параметров качества и того, насколько хорошо эти решения отвечают конкретным целевым показателям качества.
 Активный анализ конструкции (Active Design Review, ADR). ADR больше всего подходит для незавершенных архитектур или архитектур, находящихся в процессе разработки. Основное отличие этого метода в том, что анализ более сфокусирован на наборе проблем или отдельных разделах, а не на проведении общего анализа.
 Активный анализ промежуточных конструкций (Active Reviews of Intermediate Designs, ARID). ARID сочетает в себе подход ADR анализа архитектуры, находящейся в процессе разработки, с фокусом на наборе проблем и подход методов ATAM и SAAM анализа на основании сценария с основным вниманием на параметрах качества.
 Метод анализа рентабельности (Cost Benefit Analysis Method, CBAM). Метод CBAM основное внимание уделяет анализу затрат, выгод и планированию последствий архитектурных решений.
 Анализ модифицируемости на уровне архитектуры (Architecture Level Modifiability Analysis, ALMA). ALMA оценивает модифицируемость архитектуры для систем бизнес-аналитики (business information systems, BIS).
 Метод оценки семейства архитектур (Family Architecture Assessment Method, FAAM). FAAM оценивает архитектуры семейства информационных систем с точки зрения возможности взаимодействия и расширяемости.
Методики анализа и оценки дизайнов архитектур рассматриваются в книге Пола Клементса (Paul Clements), Рика Казмана (Rick Kazman) и Марка Клейна (Mark Klein) «Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering)» (Оценка программных архитектур: методы и практические примеры (Серия SEI по разработке ПО)) (Addison-Wesley Professional , ISBN-10: 020170482X, ISBN-13: 978-0201704822).


Представление дизайна архитектурыПредставление дизайна является очень важным для проведения анализа архитектуры, также это гарантирует, что все реализовано правильно. Дизайн архитектуры должен быть представлен всем заинтересованным сторонам, включая группу разработки, системных администраторов и операторов, владельцев бизнеса и др.
Один из способов представления архитектуры – карта важных решений. Карта это не территория, а абстракция, которая помогает раскрыть и представить архитектуру. Существует несколько широко известных методов описания архитектуры для ее представления:
 4+1. В данном подходе используется пять представлений готовой архитектуры. Четыре представления описывают архитектуру с разных точек зрения: логическое представление (например, объектная модель), представление процессов (например, аспекты параллелизма и синхронизации), физическое представление (схема программных уровней и функций в распределенной аппаратной среде) и представление для разработчиков. Пятое представление показывает сценарии и варианты использования ПО. Более подробно данный подход рассматривается в статье «Architectural Blueprints—The “4+1” View Model of Software Architecture» (Архитектурные проекты – модель программной архитектуры '4+1') по адресу http://www.cs.ubc.ca/~gregor/teaching/papers/4 1view-architecture.pdf.
 Гибкое моделирование. Данный подход следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей. Простота документа гарантирует активное участие заинтересованных сторон в моделировании артефактов. Более подробно этот подход рассматривается в книге Скотта Амблера «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820; Питер, ISBN 5-94723-545-5, 0-471-20282-7).
 IEEE 1471. IEEE 1471 – сокращенное название стандарта, формально известного как ANSI/IEEE 1471-2000, который обогащает описание архитектуры, в частности, придавая конкретное значение контексту, представлениям и срезам. Больше информации об этом можно найти в статье «Recommended Practice for Architecture Description of Software-Intensive Systems» (Рекомендованная практика описания архитектуры преимущественно программных систем) по адресу http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html.
 Унифицированный язык моделирования (Unified Modeling Language, UML). Этот подход обеспечивает три представления модели системы. Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования); статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов); и представление динамического поведения (взаимодействие объектов и изменения внутреннего состояния объектов, включая диаграммы последовательностей, деятельностей и состояний). Подробно об этом рассказывается в книге Мартина Фаулера «UML, основы: краткое руководство по стандартному языку объектного моделирования» (Addison-Wesley Professional, ISBN-10: 0321193687, ISBN-13: 978-0321193681; Символ-Плюс, ISBN 5-93286-060-X).