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

Нынешняя архитектура программного обеспечения значительно отличается от использовавшейся в период зарождения отрасли. Давно миновали дни, когда разработчик рисовал простенькие блочные диаграммы, определяя отдельные функциональные модули, или вручную писал каждое приложение [6]. Современная архитектура предлагает развернутую и точную модель системы. Методики формирования программной архитектуры предполагают детальный анализ системы перед ее реализацией. Такие методики, как Attribute Driven Design (ADD) [3], гарантируют, что программное обеспечение, реализованное на основе предварительно сформированной архитектуры, будет точно отвечать своему предназначению.

Есть немало примеров использования архитектуры в стратегических целях. Один из самых известных — Common Object Request Broker Architecture; эта архитектура служит для связи унаследованных систем, для интеграции систем, написанных на разных языках, и поддержки взаимодействия между компьютерами с различными аппаратными архитектурами. CORBA позволяет дать новую жизнь унаследованным системам и в то же время быстро интегрировать в них новые приложения, что обеспечивает предприятиям стратегические преимущества перед конкурентами, модифицирующими унаследованные системы.

Более свежий пример — свободно распространяемая интегрированная среда разработки Eclipse.

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

Общее описание программной архитектуры

Архитектура программной системы определяет ее структуру, точнее — несколько структур, каждая из которых включает в себя элементы и взаимосвязи между ними. Элементы могут быть вычислительными объектами, связанными потоком управления или бизнес-объектами, связанными семантическими ограничениями.

В целом процесс проектирования архитектуры состоит из систематической декомпозиции элементов верхнего уровня на совокупности более мелких элементов. На рис. 1 исходный элемент путем декомпозиции разделяется на элементы «Модель», «Контроллеры» и «Представления». Каждый из них влияет на общее поведение исходного элемента.

Рис. 1. Декомпозиция архитектуры

С помощью подхода ADD архитектор выбирает конкретную декомпозицию, стремясь улучшить определенные свойства конечного продукта. Следует, однако, иметь в виду, что каждая декомпозиция, как правило, какие-то свойства ухудшает. На рис. 1 декомпозиция «Модель — Представление — Контроллер» (Model — View — Controller, MVC) выбрана для расширения возможностей модификации системы, в частности, для более эффективного добавления новых представлений модели. Но такая декомпозиция приведет к снижению производительности, поскольку при возникновении любых изменений «Модели» придется уведомлять «Представление». С точки зрения архитектора, это приемлемый компромисс, поскольку система работает не в реальном (компьютерном) времени, а в расчете на восприятие изменений человеком.

Процесс создания архитектуры предполагает разработку системы с конкретными свойствами и функциональностью, причем каждое из таких свойств имеет заданный приоритет. Начиная с общей структуры, которая поддерживает всю требуемую функциональность (она представлена в квадрате в левой части рис. 1), архитектор методично проводит декомпозицию функциональности и распределяет ее между компонентами.

Рис. 2. Дальнейшая декомпозиция

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

На рис. 1 и 2 схематически показаны элементы и связи простой архитектуры, но они не конкретизированы. Специалистам, знакомым с шаблоном проектирования MVC, изображение на рис. 1 покажется вполне информативным, но в нем отсутствуют существенные детали, непонятные новичкам. Были разработаны несколько языков описания архитектур [2, 7], поддерживающих детальные спецификации архитектур, но они так и получили широкого распространения. Многие из концепций, представленных в этих языках, реализованы в последней версии языка Unified Modeling Language — UML 2.0 [14]. Рис. 3 иллюстрирует некоторые из обозначений в декомпозиции, представленной в правой части рис. 1.

Рис. 3. Диаграмма архитектуры UML

Диаграмма UML содержит дополнительную информацию об интерфейсах предоставления/запроса и сигнала/получения для каждого модуля. Любой из маленьких прямоугольников на границе большого прямоугольника представляет собой порт — абстракцию интерфейса, которая скрывает, как именно интерфейс связан с модулем, большим прямоугольником. Каждое «шарнирное соединение» служит для иллюстрации механизма предоставления и запроса данных или ресурсов. Эти соединения на диаграмме показывают связи между модулями, но не описывают детально реализацию соответствующих механизмов. Диаграмма удобна для последующих ссылок.

Это — лишь малая часть необходимой информации; в нашем случае — преимущественно информация о статической структуре. Архитектор создает разные диаграммы для отображения компонентной структуры, взаимодействий между компонентами и их размещения. Описание архитектуры содержит несколько «представлений», которые используются собственно для отображения разных типов информации о структуре программного обеспечения. Одно из динамических взаимодействий между элементами статической архитектуры рис. 1 показано на рис. 4 с помощью диаграммы последовательностей UML.

Рис. 4. Выполнение изменений в модели

Приведенное описание включает в себя базовые операции проектирования архитектуры, но не отражает типичного процесса разработки архитектуры. В большинстве случаев архитектор начинает с предопределенной, эталонной архитектуры. Ею может быть пресловутый «фактический отраслевой стандарт» (скажем, J2EE для электронной коммерции и Web-приложений) или предписание (например, архитектурная платформа Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance, предусмотренная для определенных военных систем в США). Эталонные архитектуры обеспечивают декомпозицию высокого уровня, которая позволяет установить базовые характеристики свойств структуры, но оставляет за архитектором свободу в выполнении декомпозиций низкого уровня, более точно определяющих качество свойств его продукта.

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

Разработка архитектуры — процесс в равной степени творческий и планируемый. Бизнес-цикл разработки побуждает предприятие подумать о своей стратегии с учетом конкуренции, тенденций в отрасли и эволюции технологии [3].

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

В любой организации архитекторы помогают преобразовать бизнес-стратегию в стратегию техническую. В ряде случаев архитектор может внести свой вклад в формирование бизнес-стратегии [1,9]. В этом случае архитектура гарантированно будет согласована с корпоративной стратегией, что позволит эффективно использовать предоставляемые архитектурой стратегические перспективы. Портер описывает стратегию как «определение положения компании, выработку компромиссов и согласование различных видов деятельности» [15].

Стратегическое планирование

Архитектура может служить средством позиционирования предприятия на рынке. Маккари и Галал определяют архитектурное представление как средство, которое позволяет точно описать реальную и планируемую эволюцию архитектуры [8]. Это представление предполагает, что система формируется как набор уровней, которые делятся на модули архитектуры в соответствии с вероятностью изменения последних. Оценить такую вероятность можно на основе уже накопленных данных и прогнозов о предполагаемом изменении технологии и предметной области. На рис. 5 показано архитектурное представление MVC, где добавление и удаление «Представления» являются самыми вероятными изменениями системы. «Представление» может извлекать информацию о стратегии из исследований предметной области и различных средств бизнес-аналитики.

Рис. 5. Архитектурное представление MVC

Архитектура может повлиять на стратегические планы выпуска продуктов компании [11]. Убедиться в правильности выбранного направления эволюции архитектуры и продуктов позволяют специальные методики архитектурного анализа.

Корпоративная архитектура

Корпоративная архитектура дает руководству предприятия целостное представление обо всей инфраструктуре используемых в ней ИТ, показывает, как согласуются друг с другом все компоненты вычислительной среды. Корпоративная архитектура включает в себя не только программные архитектуры; она определяет контекст их координации.

Малве описывает, как корпоративная архитектура устраняет разрыв между стратегией развития бизнеса и стратегией технической, утверждая, что «при принятии критически важных бизнес-решений не должны приниматься во внимание технические соображения» [10]. В принципе, это верно, но за исключением слов «не должны». В тех компаниях, которые критическим образом зависят от программного обеспечения, технические соображения иногда учитывать необходимо. Предприятия принимают стратегии, предопределенные стандартными архитектурами той предметной области, в которой они работают. Ряд автомобилестроительных корпораций, в том числе BMW, Volkswagen и DaimlerChrysler, объявили о намерении создать и распространять стандартную программную архитектуру для автомобильной электроники AUTOSAR [5].

Архитектура Zachman Framework for Enterprise Architecture [17] определяет контекст, в котором данные, поступающие от технических специалистов, объединяются с информацией, предоставленной руководством предприятия. Вместе они формируют стратегию предприятия в отношении ИТ. Эта платформа помогает архитекторам принимать компромиссные решения с учетом информации из каждой клетки таблицы.

Например, рассмотрим клетку Application Architecture. Смежные клетки связывают архитектуру приложения с бизнес-процессами (сверху), системным проектированием (снизу), логической моделью данных (слева) и распределенной архитектурой (справа). Строка дает архитектурное представление, а колонка демонстрирует иерархические связи от абстрактного к конкретному, от прикладной области к реализации.

Эталонные архитектуры

Выбор эталонной архитектуры программного обеспечения, скажем архитектуры J2EE, в качестве отправной точки для продукта или серии продуктов имеет стратегическое значение. Прежде всего, выбирая эталонную архитектуру вы присоединяетесь к соответствующему сообществу (по аналогии с тем, как после свадьбы жена входит в семью супруга). Это сообщество имеет свою историю и свою культуру.

Главное, на что следует обратить внимание при выборе архитектуры, — ее готовность и стоимость артефактов. Действия сообщества, сформировавшегося вокруг данной архитектуры, будут нести на себе отпечаток его культуры. Сравните уровень готовности и стоимость артефактов для среды J2EE и CORBA. Предпочтение одного из сообществ неминуемо скажется на уровне затрат. Сообщество J2EE создало значительно больше недорогих, свободно распространяемых решений, чем сообщество CORBA.

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

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

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

Остановимся на адекватности эталонной архитектуры и ее общем влиянии на диапазон выпускаемых продуктов. Мы уже обсуждали методику декомпозиции, которая гарантирует, что архитектура будет иметь требуемые свойства. После выбора эталонной архитектуры эти свойства уже определены. Оценивать возможные архитектуры следует с помощью таких технологий, как Architecture Trade-off Analysis Method [3]: они помогают определить, какая из архитектур наиболее полно обеспечивает уровень свойств, которыми должны обладать созданные на ее основе продукты.

К примеру, один из наших клиентов использовал архитектуру J2EE для разработки приложения, значительная часть которого была связана с поддержкой потокового видео. В результате ориентированная на транзакции платформа J2EE стала причиной крайне низкой производительности системы при передаче видео.

Архитектура как продукт

Если вы определили, какое решение будет оптимальным для ваших основных рынков сбыта, следующая стратегическая цель — позиционировать себя как поставщика компонентов для своих конкурентов. К примеру, Nokia добилась стратегических преимуществ в отрасли сотовых телефонов, поскольку предлагаемые ею архитектура и библиотека компонентов заинтересовали других производителей, и теперь они выпускают на базе этой архитектуры свои продукты [12]. Сама Nokia выбрала данный стратегический подход, предлагая архитектуру и библиотеку компонентов для разных типов сотовых телефонов. Благодаря своему положению на рынке, Nokia теперь может диктовать направление развития не только собственных продуктов, но и продуктов ее конкурентов. Компания добилась точного баланса, совмещая деятельность в качестве производителя сотовых телефонов и поставщика компонентов.

Eclipse

Цель проекта Eclipse — создание свободно распространяемой платформы, которая может послужить основой для той или иной интегрированной среды разработки. Реализованная в ней архитектура призвана увеличить качество поддержки распределенной разработки и реализации разных сценариев использования платформы. Подобные сценарии, расширяющие основную функциональность, добавляются к Eclipse посредством определения и реализации подключаемых модулей. Такой модуль представляет собой пакет, который объединяет в себе код, реализующий добавляемую в Eclipse функциональность, и декларацию на языке XML, содержащую информацию о конфигурации. Декларация описывает расширения к меню, функциональность, необходимую для корректной работы подключаемого модуля, и новые окна, которые будут частью представления Eclipse. На рис. 7 показан экран Eclipse, полученный при работе с Java Development Tools. Список задач, расположенный внизу справа экрана — пример подключаемого модуля.

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

Проект Eclipse был инициирован корпорацией IBM несколько лет назад и относительно недавно предложен сообществу Open Source. Архитектура подключаемых модулей — стратегический шаг к поддержке максимально широкого спектра целей разработки. Eclipse — часть стратегии IBM, ориентированной на предоставление по требованию сервисов электронной коммерции. Простота расширения продуктов, поддерживаемая архитектурой Eclipse, позволяет IBM оставаться заметной на специализированных рынках, где корпорация не в состоянии удовлетворить требования каждого инструментария, но способна предложить основу для разработки другими компаниям их собственных продуктов. Свободное распространение Eclipse дает IBM возможность установить косвенные связи с другими производителями инструментальных средств — за счет взаимной зависимости от общей архитектуры.

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

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

Шаг за шагом

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

  • Разработайте развернутую, современную, проверенную программную архитектуру. Слишком многие компании все еще пренебрежительно относятся к этому первому и самому главному шагу. Используйте UML или аналогичные нотации для описания архитектуры так, чтобы данные описания были точными и однозначными.
  • Координируйте отдельные программные архитектуры, применяемые в вашей организации. Используйте методики формирования серий программных продуктов для решений, тесно связанных друг с другом.
  • Обеспечьте тесное согласование процессов, связанных с разработкой продуктов, за счет их организации на базе архитектуры. Используйте ADD или аналогичные методики проектирования архитектуры для поддержки согласованности между программной архитектурой и корпоративными приоритетами.
  • Убедитесь, что принимаемые компромиссные решения способствуют реализации заданных свойств продуктов и, в конечном счете, стратегических целей организации. Создавайте архитектурные представления, которые показывают соответствие между корпоративными стратегическими целями, с одной стороны, и архитектурными решениями и эволюцией архитектуры, с другой.
  • Постоянно изучайте рынок в поисках новых технологических тенденций, анализируйте деятельность отраслевых объединений, формируемых вокруг конкретной технологии (скажем, Object Management Group). Будьте в курсе программных архитектур, которые определяются группами, специализирующимися на конкретной предметной области, такой как автомобилестроение или телекоммуникации.

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

Литература
  1. AcmeStudio.
  2. Robert Allen, David Garlan. Formalizing Architectural Connection. Proceedings of the 16th International Conference on Software Engineering, May 1994.
  3. Bass, Paul Clements, Rick Kazman. Software Architecture in Practice, Addison-Wesley, 2003.
  4. Paul Clements, Linda Northrop. Software Product Lines: Practices and Patterns, Addison-Wesley, 2001.
  5. Paul Hansen. Software as Product. Automotive Industries, Oct. 2003.
  6. P.T.L. Lloyd, G.M. Galambos. Technical reference architectures. IBM Systems Journal, vol. 38, no. 1, 1999.
  7. David Luckham, James Vera. An Event-based Architecture Definition Language. IEEE Transactions on Software Engineering, vol. 21, no. 9, 1995.
  8. Alessandro Maccari, Galal Galal. Introducing the Software Architectonic Viewpoint. WICSA 2002.
  9. Ruth Malan, Dana Bredemeyer. Strategy Architect Competency Elaboration.
  10. Raphael Malveau. Bridginging the Gap: Business and Software Architecture, part 1-4.
  11. John McGregor. Software Product Lines. Journal of Object Technology, vol. 3, no. 3, 2004.
  12. Nokia.
  13. Object Management Group: Model Driven Architecture, Object Management Group, 2001.
  14. Object Management Group: OMG Unified Modeling Language Specification Version 1.5, Object Management Group, 2003.
  15. Michael Porter. What is Strategy? Harvard Business Review, Nov. Dec. 1996.
  16. Object Management Group. Unified Modeling Language 1.5, 2003.
  17. John Zachman. A Framework for Information Systems Architecture. IBM Systems Journal, vol. 26, no. 3, 1987.

Джон Макгрегор (johnmc@lumsoft.com) — доцент университета Клемсона и один из партнеров в консалтинговой компании Luminary Software, специализирующейся на вопросах программной инженерии, автор книги «Практическое руководство по тестированию объектно-ориентированных программ» (A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001).

Translated from «Software Architecture» by John D. McGregor in Journal of Object Technology (JOT), vol.3, No. 5, pages 65-77. Translated into Russian for Open Systems Journal under special permission of the original publisher. Copyright JOT May-June 2004. Original article.