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).
Дополнительные источники
Скотт Амблер. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. J. Wiley, 2002.
Paul Clements, Rick Kazman, and Mark Klein. Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering). Addison-Wesley Professional, 2001.
Мартин Фаулер. UML, основы: краткое руководство по стандартному языку объектного моделирования, 2003.
Основы проектирования
В данный раздел руководства включены ряд тем, которые помогут понять основы многослойной архитектуры и обеспечат практическое руководство для создания некоторых типовых уровней12, используемых большинством приложений, таких как уровень представления, бизнес-уровень, уровень данных и уровень сервисов. Раздел включает следующие главы:
Глава 5 «Рекомендации по проектированию многослойных приложений»
Глава 6 «Рекомендации по проектированию слоя представления»
Глава 7 «Рекомендации по проектированию бизнес-слоя»
Глава 8 «Рекомендации по проектированию слоя доступа к данным»
Глава 9 «Рекомендации по проектированию слоя сервисов»
Как правило, каждый слой содержит ряд компонентов. При проектировании компонентов каждого слоя необходимо учесть широкий диапазон факторов, которые будут влиять на общий успех дизайна. В данный раздел руководства включены рекомендации по проектированию компонентов, которые помогут избежать типовых проблем и реализовать лучшие практики. Подробнее смотрите в следующих главах:
Глава 10 «Рекомендации по проектированию компонентов»
Глава 11 «Проектирование компонентов представления»
Глава 12 «Проектирование компонентов бизнес-слоя»
Глава 13 «Проектирование бизнес-сущностей»
Глава 14 «Проектирование компонентов рабочего процесса»
Глава 15 «Проектирование компонентов слоя доступа к данным»
Общее качество и последующий успех дизайна приложения зависит от того, насколько хорошо оно отвечает атрибутам качества, таким как безопасность, возможность повторного использования, производительность и удобство обслуживания. Кроме того, приложение, скорее всего, будет включать реализации общих аспектов, таких как обработка исключений, кэширование и протоколирование. В данном разделе представлены рекомендации по тому,
12 Понятия слой (layer) и уровень (tier) очень близки, слой используется для логического разделения, а уровень для физического разворачивания. Но когда в контексте не важно или абсолютно понятно, какое именно разделение имеется в виду, используется слово уровень, хотя в английском языке наоборот (прим. технического редактора).
как необходимо реализовывать показатели качества и сквозную функциональность в своих приложениях. Этим вопросам посвящены следующие главы:
Глава 16 «Показатели качества»
Глава 17 «Сквозная функциональность»
При проектировании приложения, особенно распределенного приложения, правильное проектирование инфраструктуры связи является ключом к успеху дизайна. Данный раздел руководства также поможет разобраться с требованиями к связи и реализовать дизайны, обеспечивающие соответствующие уровни отделения, безопасности и производительности. Подробно эти вопросы рассматриваются в Главе 18, «Взаимодействие и обмен сообщениями».
Наконец, необходимо подумать о развертывании приложения и учесть все ограничения, налагаемые физической средой, условиями работы с сетью и оборудованием, которое будет поддерживать приложение во время работы. Последняя глава данного раздела обсуждает сценарии физического развертывания и описывает некоторые проблемы, с которыми вам придется столкнуться при использовании многоуровневой модели развертывания, такие как безопасность. Подробнее смотрите в Главе 19, «Физические уровни и развертывание».