Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

приложений или проектирование конкретных компонентов и сервисов, должны

начинать с этого раздела. Из входящих в него глав можно узнать, как учитывать

показатели качества и разрабатывать стратегию физического развертывания.

 В третьем разделе, «Архетипы приложений», предлагается руководство по

проектированию архитектуры и дизайна общих типов приложений, таких как Веб-

приложения, RIA, насыщенные клиентские приложений, мобильные и сервисные

приложения. Те, кто уже имеет опыт создания архитектуры и дизайна и желает

узнать об архитектуре и основных принципах проектирования общих типов

приложений, а также получить рекомендации по каждому из них, могут начинать с

этого раздела. Во входящих в него главах все эти вопросы рассматриваются более

подробно.

 Наконец, в Приложениях предлагается обзор платформы Microsoft, технологий .NET

Framework и их возможностей. В этом разделе также представлены все общие

шаблоны проектирования и даются ссылки на дополнительные ресурсы и

материалы. Те, кто только начинают работать с .NET Framework или желают узнать,

какие технологии предлагает платформа Microsoft, найдут в этом разделе обзор

сервисов .NET Framework и платформы, увидят все основные технологии и смогут

ознакомиться с описаниями предложений группы patterns & practices, таких как

Enterprise Library и библиотека шаблонов patterns & practices.

В зависимости от имеющегося опыта и необходимости можно обращаться непосредственно к

определенному(ым) разделу(ам). Если требуется изучить развернутый обзор дизайна и

архитектуры на платформе Microsoft и в .NET Framework, можно читать это руководство

полностью, от начала до конца, оно поможет понять подходы к созданию архитектуры и

дизайна. Это руководство может быть включено в жизненный цикл и процессы разработки

приложения в качестве учебного пособия.

Обратная связь и поддержка

Мы постарались обеспечить максимальную точность и безошибочность сведений,

приводимых в данном руководстве. Однако будем признательны за любые отзывы по всем

затрагиваемым в нем темам, в частности, техническим вопросам, касающимся приведенных

рекомендаций, вопросам их применимости и полезности. Для упрощения доступа через Веб

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

http://www.microsoft.com/architectureguide.

Свои комментарии по данному руководству можете оставлять на сайте

http://www.codeplex.com/AppArchGuide.

Техническая поддержка

Техническую поддержку продуктов и технологий Microsoft, упоминаемых в данном

руководстве, обеспечивает Служба технической поддержки Microsoft (Microsoft Product

Support Services, PSS). Сведения о продуктах можно получить на Веб-сайте технической

поддержки Microsoft по адресу http://support.microsoft.com.

Сообщество и группа новостей

Получить поддержку сообщества, обсудить это руководство и оставить свои отзывы можно в

группах новостей на сайте Microsoft MSDN® по адресу http://msdn.microsoft.com/en-

us/subscriptions/aa974230.aspx.

Авторская группа

В создании этого руководства принимали участие такие специалисты по архитектуре и

разработке .NET-решений:

 J.D. Meier

 David Hill

 Alex Homer

 Jason Taylor

 Prashant Bansode

 Lonnie Wall

 Rob Boucher Jr.

 Akshay Bogawat

Авторы и рецензенты

Огромная благодарность авторам и рецензентам:

 Группа тестирования. Rohit Sharma; Praveen Rangarajan

 Редактор. Dennis Rea

 Независимые авторы и рецензенты. Adwait Ullal; Andy Eunson; Brian Sletten;

Christian Weyer; David Guimbellot; David Ing; David Weller; David Sussman; Derek

Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback;

Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan

Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan; Oren Eini aka Ayende

Rahien; Gregory Young

 Авторы и рецензенты, являющиеся сотрудниками компании Microsoft. Ade Miller;

Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti;

Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson;

Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov;

Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal

Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor;

Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Kashinath TR; Koby

Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo;

Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki

Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison;

Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh;

Simon Calvert; Srinath Vasireddy; Tom Hollander; Vijaya Janakiraman; Wojtek

Kozaczynski

Поделитесь с нами своими успехами

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

проблемы, с которыми вам приходилось сталкиваться, и то, как это руководство помогло с

ними справиться. Присылайте свои отзывы по электронной почте по адресу

MyStory@Microsoft.com.

Архитектура и дизайн

программного обеспечения

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

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

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

внимания, такие как требования и ограничения, а также точки соприкосновения пользователя,

предметной области и системы, в которой будет выполняться приложение. Далее следует

описание основных принципов проектирования, архитектурных шаблонов и стилей, обычно

применяемых сегодня. Наконец, предлагается подход, которому необходимо следовать при

проектировании архитектуры. Раздел содержит следующие главы:

 Глава 1 «Что такое архитектура программного обеспечения?»

 Глава 2 «Основные принципы проектирования архитектуры ПО»

 Глава 3 «Архитектурные шаблоны и стили»

 Глава 4 «Методика построения архитектуры и дизайна»

Что такое архитектура

программного обеспечения?

Создание архитектуры приложения – это процесс формирования структурированного

решения, отвечающего всем техническим и операционным требованиям и обеспечивающего

оптимальные общие атрибуты качества, такие как производительность, безопасность и

управляемость. Он включает принятие ряда решений на основании широкого диапазона

факторов. Каждое из этих решений может иметь существенное влияние на качество,

производительность, удобство обслуживания и общий успех приложения.

Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Курт Биттнер (Kurt Bittner) и Рич

Рейтман (Rich Reitman) доработали и уточнили определение архитектуры, приведенное в

работе Мэри Шоу (Mary Shaw) и Девида Гарлана (David Garlan) (Shaw and Garlan, 1996). Их

формулировка звучит так:

«Архитектура программного обеспечения (ПО) заключает в себе ряд важных решений об

организации программной системы, среди которых выбор структурных элементов и их

интерфейсов, составляющих и объединяющих систему в единое целое; поведение,

обеспечиваемое совместной работой этих элементов; организацию этих структурных и

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

которого придерживается данная организация. Выбор архитектуры ПО также касается

функциональности, удобства использования, устойчивости, производительности,

повторного использования, понятности, экономических и технологических ограничений,

эстетического восприятия и поиска компромиссов».

В книге «Архитектура корпоративных программных приложений» Мартин Фаулер (Martin

Fowler), рассматривая проектирование архитектуры, выделяет несколько общих элементов в

разных определениях этого понятия. Он определяет эти элементы как:

«Разделение системы на составные части в самом первом приближении; принятие

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

вариантов архитектуры для системы; важность с точки зрения архитектуры различных

аспектов может меняться в процессе жизненного цикла системы; и, в конечном счете,

под архитектурой можно понимать то, что имеет значение».

[http://www.pearsonhighered.com/educator/academic/product/0,3110,0321127420,00.html

]

В книге «Архитектура ПО на практике, 2-е издание» Басс, Клементс и Казман дают

следующее определение архитектуре:

«Архитектура программной или вычислительной системы – это структура или структуры

системы, включающие программные элементы, видимые извне свойства этих элементов

и взаимоотношения между ними. Архитектура касается внешней части интерфейсов;

внутренние детали элементов – детали, относящиеся исключительно к внутренней

реализации – не являются архитектурными».

[http://www.aw-bc.com/catalog/academic/product/0,4096,0321154959,00.html]

Почему архитектура так важна?

Как и любая другая сложная структура, ПО должно строиться на прочном фундаменте.

Неправильное определение ключевых сценариев, неправильное проектирование общих

вопросов или неспособность выявить долгосрочные последствия основных решений могут

поставить под угрозу все приложение. Современные инструменты и платформы упрощают

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

проектировании на основании конкретных сценариев и требований. Неправильно

выработанная архитектура обусловливает нестабильность ПО, невозможность поддерживать

существующие или будущие бизнес-требования, сложности при развертывании или

управлении в среде производственной эксплуатации.

Проектирование систем должно осуществляться с учетом потребностей пользователя, системы

(ИТ-инфраструктуры) и бизнес-целей. Для каждой из этих составляющих определяются

ключевые сценарии и выделяются важные параметры качества (например, надежность или

масштабируемость), а также основные области удовлетворенности и неудовлетворенности. По

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

областей.

Рис. 1

Пользователь, бизнес, система

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

этих трех областей. Например, пользовательский интерфейс решения очень часто является

производным от бизнес-целей и ИТ-инфраструктуры, и изменения одного из этих компонентов

могут существенно влиять на результирующие механизмы взаимодействия с пользователем.

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

сильное воздействие на требования к бизнес-области и ИТ-инфраструктуре. Например,

основной целью пользователя и бизнеса может быть производительность, но системный

администратор, вероятно, не сможет инвестировать в оборудование, необходимое для

реализации этой цели, 100 % своего рабочего времени. Компромиссным решением может

быть выполнение данной цели на 80%.

Основное назначение архитектуры – описание использования или взаимодействия основных

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

или деталей реализации отдельных компонентов являются вопросами проектирования. Часто

вопросы архитектуры и проектирования пересекаются. Вместо того чтобы вводить жесткие

правила, разграничивающие архитектуру и проектирование, имеет смысл комбинировать эти

две области. В некоторых случаях, принимаемые решения, очевидно, являются

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

архитектуры.

Описанные в данном руководстве процессы и предлагаемые в нем сведения помогут

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

развернуты в выбранной инфраструктуре и обеспечат результаты, отвечающие поставленным

целям и задачам.

Рассмотрим основные исходные вопросы при разработке архитектуры ПО:

 Как пользователь будет использовать приложение?

 Как приложение будет развертываться и обслуживаться при эксплуатации?

 Какие требования по атрибутам качества, таким как безопасность,

производительность, возможность параллельной обработки, интернационализация

и конфигурация, выдвигаются к приложению?

 Как спроектировать приложение, чтобы оно оставалось гибким и удобным в

обслуживании в течение долгого времени?

 Основные архитектурные направления, которые могут оказывать влияние на

приложение сейчас или после его развертывания?

Цели архитектуры

Архитектура приложения должна объединять бизнес-требования и технические требования

через понимание вариантов использования с последующим нахождением путей их

реализации в ПО. Цель архитектуры – выявить требования, оказывающие влияние на структуру

приложения. Хорошая архитектура снижает бизнес-риски, связанные с созданием

технического решения. Хорошая структура обладает значительной гибкостью, чтобы

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

пользовательских сценариев и требований. Архитектор должен учитывать общий эффект от

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

атрибутами качества (такими как производительность и безопасность) и компромиссы,

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

Необходимо помнить, что архитектура должна:

 Раскрывать структуру системы, но скрывать детали реализации.

 Реализовывать все варианты использования и сценарии.

 По возможности отвечать всем требованиям различных заинтересованных сторон.

 Выполнять требования, как по функциональности, так и по качеству.

Архитектура сегодня и завтра

Важно понимать основные факторы, которые формируют архитектурные решения сегодня и

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

факторы определяются пожеланиями пользователей, а также требованиями бизнеса о

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

рабочих процессов, а также улучшенной адаптируемости дизайна ПО.

Рассмотрим следующие основные направления:

 Наделение пользователя полномочиями. Дизайн, поддерживающий наделение

пользователя полномочиями, является гибким, настраиваемым и

ориентированным на пользователя. Проектируйте приложения, учитывая

соответствующий уровень персонализации и конфигурации для пользователя. Не

диктуйте, а позволяйте пользователям определять стиль взаимодействия с

приложением, но при этом не перегружайте их ненужными опциями и

настройками, что может сбить с толку. Определитесь с ключевыми сценариями и

сделайте их предельно простыми; обеспечьте простоту поиска информации и

использования приложения.

 Зрелость рынка. Используйте преимущества зрелости рынка, применяя

существующие платформы и технологии. Создавайте приложения в настолько

высокоуровневых средах, насколько это позволяют предъявляемые к приложениям

требования, это позволит сконцентрироваться на том, что действительно уникально

для вашего приложения, а не на воспроизведении уже существующих функций.

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

распространенных проблем.

 Гибкий дизайн. Все большую популярность приобретают гибкие дизайны,

использующие слабое связывание, что делает возможным повторное

использование и упрощает поддержку. Архитектура с возможностью подключения

модулей позволяет реализовать расширяемость после развертывания. Также для

обеспечения взаимодействия с другими системами можно использовать

преимущества таких сервис-ориентированных техник, как SOA.

 Тенденции. При построении архитектуры необходимо понимать тенденции,

которые могут оказать влияние на дизайн после развертывания. Например,

тенденции в насыщенных UI и мультимедиа, составных приложениях, увеличение

пропускной способности и доступности сетей, все большее распространение

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

интерес к моделям блогов и сообществ, рост популярности вычислений в облаке и

удаленной работы.

Принципы проектирования архитектуры

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

эволюционировать со временем и что совершенно невозможно наперед знать все то, что

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

в ходе реализации приложения по мере выявления новых сведений и в ходе тестирования на

соответствие требованиям реального окружения. Создавайте архитектуру, ориентируясь на

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

процесса проектирования известны не в полном объеме.

При проектировании архитектуры необходимо ответить на следующие вопросы:

 Какие части архитектуры являются фундаментальными, изменение которых в

случае неверной реализации представляет наибольшие риски?

 Какие части архитектуры вероятнее всего подвергнуться изменениям, а также

проектирование каких частей можно отложить?

 Основные допущения, и как они будут проверяться?

 Какие условия могут привести к реструктуризации дизайна?

Не пытайтесь создать слишком сложную архитектуру и не делайте предположений, которые не

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

Некоторые аспекты дизайна должны быть приведены в порядок на ранних стадиях процесса,

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

необходимо выявить как можно раньше и уделить им достаточное количество времени.

Основные принципы проектирования архитектуры

При проектировании архитектуры руководствуйтесь следующими основными принципами:

 Создавайте, чтобы изменять. Продумайте, как со временем может понадобиться

изменить приложение, чтобы оно отвечало вновь возникающим требованиям и

задачам, и предусмотрите необходимую гибкость.

 Создавайте модели для анализа и сокращения рисков. Используйте средства

проектирования, системы моделирования, такие как Унифицированный язык

моделирования (Unified Modeling Language, UML), и средства визуализации, когда

необходимо выявить требования, принять архитектурные и проектные решения и

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

формализованную модель, она может ограничить возможности для выполнения

итераций и адаптации дизайна.

 Используйте модели и визуализации как средства общения при совместной

работе. Для построения хорошей архитектуры критически важен эффективный

обмен информацией о дизайне, принимаемых решениях и вносимых изменениях.

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

для эффективного обмена информацией и связи со всеми заинтересованными

сторонами, а также для обеспечения быстрого оповещение об изменениях в

дизайне.

 Выявляйте ключевые инженерные решения. Используйте информацию,

представленную в данном руководстве, чтобы понять ключевые инженерные

решения и области, в которых чаще всего возникают ошибки. В самом начале

проекта уделите достаточное количество времени и внимания для принятия

правильных решений, это обеспечит создание более гибкого дизайна, внесение

изменений в который не потребует полной его переработки.

Рассмотрите возможность использования инкрементного и итеративного подхода при работе

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

и затем прорабатывайте возможные варианты в ходе итеративного тестирования и доработки

архитектуры. Не пытайтесь сделать все сразу; проектируйте настолько, насколько это

необходимо для начала тестирования вашего дизайна на соответствие требованиям и

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

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

сосредотачиваться на деталях. Общей ошибкой является быстрый переход к деталям при

ошибочном представлении о правильности крупных решений из-за неверных допущений или

неспособности эффективно оценить свою архитектуру. При тестировании архитектуры дайте

ответы на следующие вопросы:

 Какие допущения были сделаны в этой архитектуре?

 Каким явным или подразумеваемым требованиям отвечает данная архитектура?

 Основные риски при использовании такого архитектурного решения?

 Каковы меры противодействия для снижения основных рисков?

 Является ли данная архитектура улучшением базовой архитектуры или одним из

возможных вариантов архитектуры?

Более подробно об основных принципах проектирования архитектуры ПО рассказывается в

главе 2, «Основные принципы проектирования архитектуры ПО».

Инкрементный и итеративный подход к разработке архитектуры, базовая и возможные

варианты архитектуры, а также представление и обмен информацией о дизайне

рассматриваются в главе 4, «Методика построения архитектуры и дизайна».

Дополнительные источники

Л.Басс, П.Клементс, Р.Кацман. Архитектура программного обеспечения на практике, 2-е

издание. Питер, 2006.

Мартин Фаулер. Архитектура корпоративных программных приложений. Вильямс, 2007.