Будущее программной архитектуры

Дополнительная литература

Материалы по методикам и процессам, рассмотренным в этой главе, содержатся в издании [Wallnau 02]. Вопросы внедрения коммерческих коробочных продук­тов — их квалификация, связанные с ними риски и миграция — раскрываются на сайте http://www.sei.cmu.edu/cbs/.

Архитектурное несоответствие и методы его исправления подробно рассмот­рены в работе [Garlan 95].

Глава 19

Предсказывать трудно — в особенности пред­сказывать будущее.

Нильс Бор

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

В 1970-х годах, в связи с нежеланием разработчиков ограничиваться одним- единственным атрибутом качества — корректным функционированием, програм­мы стали структурировать. На основе анализа потоков данных, диаграмм отно­шений «сущность-связь», информационной закрытости и ряда других принципов и методик формировались сотни проектных методологий. Каждая из них предпо­лагала создание подпрограмм и коллекций подпрограмм с возможностью рацио­нализации их функциональности в категориях атрибутов качества разработки. Эти элементы назывались модулями. В области соединителей изменений не на­мечалось, но в то же время некоторые новые модульные языки программирова­ния расширили возможности их создания. Абстракции, встраивавшиеся в моду­ли, со временем усложнялись и расширялись, что, в конечном итоге, привело к появлению первых повторно используемых модулей. Пакетировались они та­ким способом, который, теоретически, исключал необходимость изучения их внут­реннего содержания. Таким образом, 1970-е стали десятилетием модулей.

В 1980-х модульные языки программирования, принцип информационной закрытости и некоторые родственные методологии оформились в концепцию объектов. Объекты получили громадное распространение, а наследование обога­тило ассортимент (не относящихся к периоду прогона) соединителей.

В 1990-х годах появились первые стандартные объектные архитектуры, выра­женные поначалу в виде каркасов. В рамках объектной технологии сформиро­вался стандартный словарь элементов, подтолкнувший разработку новых ин­фраструктур для связывания коллекций элементов. Возможности абстракций неуклонно увеличивались. Благодаря этому домашние вычислительные платфор­мы сегодня позволяют обрабатывать сложные сущности — электронные табли­цы, документы, графические изображения, звуковые ролики и базы данных — как «черные ящики», которые можно без труда включать в экземпляры друг друга.

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

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

Рис. 19.1. Хронологические этапы развития типов абстракции

Вот на таком этапе мы находимся в данный момент. У нас нет повода усом­ниться в том, что тенденция к созданию более крупных и функциональных абст­ракций продолжится. Сегодня уже существуют генераторы (generators) для та­ких сложных и ресурсоемких приложений, как системы управления базами данных и авиационные электронные системы. Наличие в предметной области генератора есть первый признак перехода средств языка программирования в этой области на новый, более высокий уровень. Выражение «системы систем» (systems of systems), акцентирующее способность систем к взаимодействию и свидетельству­ющее об очередном повышении возможностей абстракций, употребляется все чаще.

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

Начнем с обобщения сведений об архитектурно-экономическом цикле (Archi­tecture Business Cycle, ABC), затем обсудим процесс создания архитектуры и ее отношения с жизненным циклом и, наконец, поговорим о том, как компоненты и компонентные каркасы видоизменяют задачи архитектора.

19.1. Снова архитектурно­экономический цикл

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

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

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

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

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

Каждая из перечисленных разновидностей архитектурно-экономического цикла состоит из тех же элементов, что и его первоначальная версия: заинтересованных лиц, технической базы, базы опыта, набора требований, которые необходимо реализовать, архитектора или архитекторов, одного или нескольких вариантов архитектуры, одной или нескольких систем. Вариантность архитектурно-эконо­мического цикла обусловливается коммерческим контекстом, емкостью рынка и поставленных задач.

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

Дата добавления: 2015-04-25