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

Kozaczynski

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

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

[e-mail].

Архитектура и дизайн программного обеспечения

Темы, включенные в данный раздел этого руководства, помогут понять основы архитектуры и дизайна. Обсуждение начинается с определения архитектуры программного обеспечения и объяснения, почему она так важна. Рассматриваются общие вопросы, заслуживающие особого внимания, такие как требования и ограничения, а также точки соприкосновения пользователя, предметной области и системы, в которой будет выполняться приложение. Далее следует описание основных принципов проектирования, архитектурных шаблонов и стилей, обычно применяемых сегодня. Наконец, предлагается подход, которому необходимо следовать при проектировании архитектуры. Раздел содержит следующие главы:

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

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

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

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

1

Что такое архитектура программного обеспечения?

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

Филипп Крачтен (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

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

Необходимо искать компромиссы и находить баланс между конкурирующими требованиями этих трех областей. Например, пользовательский интерфейс решения очень часто является производным от бизнес-целей и ИТ-инфраструктуры, и изменения одного из этих компонентов могут существенно влиять на результирующие механизмы взаимодействия с пользователем. Аналогично, изменения в требованиях по взаимодействию с пользователем могут оказывать сильное воздействие на требования к бизнес-области и ИТ-инфраструктуре. Например,