Техника Моделирования Архитектуры (4ч)ContentsТехника Моделирования Архитектуры (4ч) 1
Идентификация целей архитектуры 2
Идентификация ключевых сценариев 2
Обзор приложения 3
Iидентификация ключевых проблем 4
Определение решения-кандидата 5
Sources 8 В процессе конструирования архитектуры должны быть определены список сценариев использования, критичных с точки зрения архитектуры, проблемы связанные с архитектурой и требующие специального внимания, и архитектурные решения — кандидаты, которые удовлетворяют требованиям и ограничениям, определенным в процессе дизайна. Для построения конечной архитектуры методом последовательного улучшения дизайна используется итеративный подход, который включает пять основных стадий:

Последовательность итеративные действий по дизайну архитектуры
Основные действия включают:
Определение целей архитектуры. Ясное понимание архитектуры позволяет сосредоточиться на на построениии архитектуры и решение правильных проблем дизайна. Точные цели позволяют определить момент завершения текущей фазы и готовности перехода к следующей.
Ключевые сценарии. Ключевые сценарии используются для определения наиболее важных сторон архитектуры и оценкм готовности архитектуры - кандидата.
Обзор приложения. Определите тип приложения, архитектурные стили и технологии чтобы связать приложение с реальной средой где оно будет функционировать.
Ключевые проблемы. Определите ключевые проблемы базируясь на атрибутах качества. Ключевые проблемы идентифицируют области наиболее вероятного появления ошибки в разработке приложения.
Решения - кандидаты. Создавайте прототипы, которые развивают и улучшают текущее принятое решениетия и оценивайте в соответствии с ключевыми сценариями, проблемами и ограничениями прежде чем начинать следующую итерацию построения архитектуры.
Предполагается что процесс построения архитектуры использует подход итеративного улучшения. Превая архитектура — кандидат будет представлять собой высокоуровневый дизайн, который должен проверяться на соостветствие ключевым сценариям, требованиям, известным ограничениям,атрибутам качества и соответствию архитектурным рамкам для выбранного архитектурного шаблона. В процессе улучшения кандидата — архитектуры новые детали становятся известны, что позволяет изменять ключевые сценарии, и применять новые подходы к решению проблем.
Идентификация целей архитектуры
Цели архитектуры представляют собой цели и ограничения, формирующие архитектуру и определяющие процесс разработки, область применения и определяющие когда процесс завершен. Следующие ключевые моменты важны для определения целей архитектуры;
Определение целей архитектуры в самом начале. Количество времени, проведенное над каждой фазой построения архитектуры зависит от этих целей. Например разрабатываете ли вы прототип, тестируете возможные способы решения проблем, или начинаете длительный процесс построения новой архитектуры?
Определите потребителей вашей архитектуры. Определите будет ли архитектура использоваться другими архитекторами, будет ли она доступна разработчикам и тестировщикам илм руководству. Примите во внимание нужды и опыт целевой аудитории, чтобы сделать результирующий дизайн наиболее доступным и понятным для них.
Определите ограничения. Необходимо понимать возможности и ограничения используемых технологий, условий внедрения и использования. Это позволит избежать неожиданных изменений в процессе разработке приложения.
Идентификация ключевых сценариев
В контексте архитектуры и дизайна случай использования (use-case) представляет собой описание множества действий выполняемых в процессе коммуникации между системой и одним или более действующими лицами (либо пользователем, либо другой системой). Сценарий использования представляет собой более широкое понятие и описывает определенный вид взаимодействия пользователя с системой. При определении архитектуры системы, необходимо определить несколько ключевых сценариев, которые помогут принять решение об архитектуре. Небходимо добиться баланса между целями пользователя, предприятия и системы.
Ключевые сценарии определяются согласно следующим критериям:
Он описывает проблему — важную неизвестную область или область связанную с высокими рисками.
Он относится к архитектурно значимым случаям использования.
Он представляет пересечения качественных атрибутов и функциональности.
Он представляет компромисс между между атрибутами качества.
Например: сценарии, описывающиу аутентификацию пользователя могут быть определены как ключевые, т.к. В этом сценарии перекрывается важная функциональность(вход пользователя в систему) и атрибут качества(безопасность). Другим примером ключевого сценария может быть такой, который базируется на использовании незнакомой или новой технологии.
Архитектурно значимые случаи использования
Cлучаи использования являются архитектурно значимыми если:
Критичны для бизнеса. Use-case, который применяется часто или имеет большую важность для конечных пользователей или других заинтересованных лиц, или связан с высоким риском.
Характеризуется широкой областью воздействием. Это случай использования который находится на пересечении функциональности и качественных характеристик, или влияет на более чем один уровень приложения (сквозное воздействие, касательство — crosscutting concern). Примером могут быть операции Create, Read, Update, Delete (CRUD) которые являются чувствительными с точки зрения безопасности.
После того как определены архитектурно значимые случаи использования (use cases), они могут использоваться для оценки успешности архитектуры кандидата.
Если архитектура-кандидат включает решения для большего числа случаев использования(use=-cases), или решает проблемы представленные уже рассмотренными случаями использования более эфективно, это является определяющим фоктором при решении о том что архитектура-кандидат является лучшим вариантом по сравнению с существующей базовой.
Обзор приложения
При пострении архитектуры необходимо создать обзор того как приложение будет выглядеть после завершения разработки. Это позволяет привязать архитектуру к ограничениям и решениям реального мира. Для создание обзора приложения выполняются следующие действия:
Определите тип приложения. Является ли это приложение мобильным приложением, rich client («толстый» клиент), Internet приложением, сервисом, Web-приложением, или комбинацией нескольких типов?
Определите ограничения внедрения. При разработке приложения должны приниматься во внимание корпоративные практики и процедуры, а также инфраструктура на базе которой предполагается внедрение приложения. Если целевая среда негибкая и неизменяемая, то приложение должно отражать ограничения, существующие в этой среде. Так же должны учитываться атрибуты качества обслуживания (Quality-of-Service (QoS)), такие как безопасность и надежность. Иногда необходимо выбирать компромиссные решения, например из-за ограничений накладываемых сетевой топологией и используемыми протоколами.
Определите важные архитектурные шаблоны (patterns). Например широко распространенными архитектурными стилями являются Service Oriented Architecture (SOA), client/server, уровневая (layered), шина обмена сообщениями (message-bus). Часто используется комбинация разных стилей.
Определите подходящие технологии. Выбор подходящих технологий базируется на выборе типа приложения и ограничений. Выбор технологий может диктоваться политикой организации, ограничениями инфраструктуры, знаниями и опытом разработчиков и т.д.
Набросок Архитектуры
Набросок архитектуры играет важную роль независимо от того каким образом он создается и распространяется, ключевой задачей является показать главные ограничения и решения с тем чтобы начать обсуждение и обозначить его рамки. Если вы не в состоянии создать набросок архитектуры, это означает что она недостаточно хорошо разработана и неясна для понимания.

Пример наброска архитектуры, представляющий высокоуровневый дизайн Web-приложения, с указанием протоколов и методов аутентификации.
Iидентификация ключевых проблем
Идентификация проблем при построении архитектуры необходима для определения мест наиболее вероятного появления ошибок. В качестве потенциальных проблем можно рассматривать использование новой технологии и реализацию требований, критичных для бизнеса. При реализации системы проблемные места, как правило привязаны к требованиям, отражающим атрибуты качества и сквозной функциональности.
Примеры ключевых проблем:
Возможность замены одного сервиса другим
Добавление поддержки нового типа клиентов
Возможность изменения бизнес-правил, связанных с налогоообложением
Атрибуты качества представляют архитектору проблемную область, которая будет влиять на множество уровней приложения. Одни из атрибутов качества связаны с выбранным дизайном системы в целом, другие связаны с функционированием системы во время выполнения (run-time), третьи относятся к взаимодействию с пользователями.
Атрибуты качества могут быть классифицированы следующим образом:
Качества системы — определяют качества системы в целом, такие как тестируемость, простота поддержки.
Качества функционирования системы (run-time qualities) — проявляются во время работы системы. Это такие качества как доступность, управляемость, производительность, надежность, масштабируемость, безопасность.
Качества дизайна системы — гибкость, целостность и непротиворечивость, возможность повторного использования.
Качества с точки зрения пользователя — простота и удобство использования системы (usability).
Сквозная функциональность (crosscutting concerns) – это функциональность системы, которая оказывает влияние на различные компоненты и уровни системы и не может быть изолирована.
Примеры сквозной функциональности:
Аутентификация и авторизация
Кэширование данных
Коммуникации
Управление исключениями

Пример определения проблемных мест с точки зрения безопасности в архитектуре типичного Web приложения.
Определение решения-кандидата
После того как ключевые проблемы определены, строится начальный вариант базовой архитектуры, которая в процессе дальнейшей детализации используется для построения архитектуры-кандидата. В процессе построения можно использовать пробные реализации отдельных частей архитектуры (architectural spikes) системы для исследования определенных областей или оценки новых концепций. Построенная архитектура-кандидат оценивается с точки зрения ключевых сценариев и требований, которые были определены ранее.
Базовая архитектура и архитектура-кандидат
Базовая архитектура описывает существующее состояние системы на текущий момент. Начальная базовая архитектура принимается за отправную точку для построения последующих кандидатских архитектур. Архитектура кандидат включает тип приложения, архитектуру внедрения, архитектурный стиль, выбор технологии, качественные параметры, и сквозную функциональность.
В процессе развития дизайна необходимо убедиться что на каждом этапе учитываются ключевые риски и выполняются необходимые действия по их уменьшению, что все изменения доводятся до сведения всех заинтересованных лиц и обсуждаются, при построении архитектуры учитывается необходимость рефакторинга и поддержания гибкости. Если кандидатская архитектура является улучшением базовой то она, в свою очередь становится базовой архитектурой, на основе которой строится следующая архитектура-кандидат.
Этот итеративный последовательный процесс позволяет решить проблемы связанные с основными рисками при построении архитектуры в первую очередь, и использовать процедуры тестирования архитектуры чтобы доказать, что кажддая новая базовая архитектура является улучшением предыдущей. Следующие вопросы должны рассматриваться при тестировании новой архитектуры кандидата на роль базовой:
Не добавляются ли новые риски с принятием новой архитектуры?
Позволяет ли новая архитектура уменьшить большее число известных рисков чем архитектура принятая на предыдущей итерации?
Включает ли новая архитектура решения для дополнительных требований?
Включает ли новая архитектура решения для реализации процедур, описанных архитектурно значимыми случаями использования (architecturally significant use cases)?
Включает ли архитектура решения, касающиеся качественных атрибутов системы?
Включает ли архитектура решения для дополнительных случаев сквозной функциональности?
Архитектурные пробы(Architectural Spikes)
Архитектурная проба (An architectural spike) представляет собой тестовую реализацию небольшой части дизайна приложения. Целью использования проб является анализ технических аспектов определенной части архитектурного решения чтобы оценить технические предположения, выбрать оптимальный вариант из возможных вариантов дизайна и стратегий реализации и оценить время , которое потребуется на реализацию решения.
Последующие шаги
After you complete the architecture-modeling activity, you can begin to refine the design, plan tests, and communicate the design to others. Keep in mind the following guidelines:
If you capture your candidate architectures and architectural test cases in a document, keep the document lightweight so that you can easily update it. Such a document may include details of your objectives, application type, deployment topology, key scenarios and requirements, technologies, quality attributes, and tests.
Use the quality attributes to help shape your design and implementation. For example, developers should be aware of anti-patterns related to the identified architectural risks, and use the appropriate proven patterns to help address the issues.
Communicate the information you capture to relevant team members and other stakeholders. This may include your application development team, your test team, and your network and system administrators.
// Следующая лекция!!!!
Reviewing Your Architecture
Reviewing the architecture for your application is a critically important task in order to reduce the cost of mistakes and to find and fix architectural problems as early as possible. Architecture review is a proven, cost-effective way of reducing project costs and the chances of project failure. Review your architecture frequently: at major project milestones, and in response to other significant architectural changes. Build your architecture with common review questions in mind, both to improve your architecture and to reduce the time required for each review.
The main goal of an architecture review is to determine the feasibility of your baseline and candidate architectures, and verify that the architecture correctly links the functional requirements and the quality attributes with the proposed technical solution. Additionally, it helps you to identify issues and recognize areas for improvement.
Scenario-Based Evaluations
Scenario-based evaluations are a powerful method for reviewing an architecture design. In a scenario-based evaluation, the focus is on the scenarios that are most important from the business perspective, and which have the greatest impact on the architecture. Consider using one of the following common review methodologies:
Software Architecture Analysis Method (SAAM). SAAM was originally designed for assessing modifiability, but later was extended for reviewing architecture with respect to quality attributes such as modifiability, portability, extensibility, integratability, and functional coverage.
Architecture Tradeoff Analysis Method (ATAM). ATAM is a refined and improved version of SAAM that helps you review architectural decisions with respect to the quality attributes requirements, and how well they satisfy particular quality goals.
Active Design Review (ADR). ADR is best suited for incomplete or in-progress architectures. The main difference is that the review is more focused on a set of issues or individual sections of the architecture at a time, rather than performing a general review.
Active Reviews of Intermediate Designs (ARID). ARID combines the ADR aspect of reviewing in-progress architecture with a focus on a set of issues, and the ATAM and SAAM approach of scenario-based review focused on quality attributes.
Cost Benefit Analysis Method (CBAM). This CBAM focuses on analyzing the costs, benefits, and schedule implications of architectural decisions.
Architecture Level Modifiability Analysis (ALMA). ALMA evaluates the modifiability of architecture for business information systems (BIS).
Family Architecture Assessment Method (FAAM). FAAM evaluates information system family architectures for interoperability and extensibility.
For information about techniques for analyzing and reviewing architecture designs, see "Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering)" by Paul Clements, Rick Kazman, and Mark Klein (Addison-Wesley Professional , ISBN-10: 020170482X, ISBN-13: 978-0201704822)
Representing and Communicating Your Architecture Design
Communicating your design is critical for architecture reviews, as well as to ensure it is implemented correctly. You must communicate your architectural design to all the stakeholders including the development team, system administrators and operators, business owners, and other interested parties.
One way to think of an architectural view is as a map of the important decisions. The map is not the terrain; instead, it is an abstraction that helps you to share and communicate the architecture. There are several well-known methods for describing architecture to others, including the following:
4+1. This approach uses five views of the complete architecture. Four of the views describe the architecture from different approaches: the logical view (such as the object model), the process view (such as concurrency and synchronization aspects), the physical view (the map of the software layers and functions onto the distributed hardware infrastructure), and the development view. A fifth view shows the scenarios and use cases for the software. For more information, see "Architectural Blueprints—The “4+1” View Model of Software Architecture" at http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf.
Agile Modeling. This approach follows the concept that content is more important than representation. This ensures that the models created are simple and easy to understand, sufficiently accurate, and consistent. The simplicity of the document ensures that there is active stakeholder participation in the modeling of the artifact. For more information, see "Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process" by Scott Ambler (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820).
IEEE 1471. IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000, which enhance the content of an architectural description; in particular giving specific meaning to context, views, and viewpoints. For more information, see “Recommended Practice for Architecture Description of Software-Intensive Systems” at http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html.
Unified Modeling Language (UML). This approach represents three views of a system model. The functional requirements view (functional requirements of the system from the point of view of the user, including use cases); the static structural view (objects, attributes, relationships, and operations including class diagrams); and the dynamic behavior view (collaboration among objects and changes to the internal state of objects, including includes sequence, activity, and state diagrams). For more information, see "UML Distilled: A Brief Guide to the Standard Object Modeling Language" by Martin Fowler (Addison-Wesley Professional, ISBN-10: 0321193687, ISBN-13: 978-0321193681)

Sources
http://msdn.microsoft.com/en-us/library/ee658084.aspx