Архитектурное дежа вю

Архитектура — несомненно, существенный элемент разработки системы — как область ис­следований в настоящее время пользуется большой популярностью. При этом следует на­помнить, что отдельные ее аспекты уже давно и тщательно изучены. Во многих отношениях устойчивый интерес к архитектуре, который мы наблюдаем сейчас, — это «второе открытие» фундаментальных принципов, ярко и убедительно изложенных четверть века назад такими исследователями, как Фред Брукс, Эдсгер Дийкстра (Edsger Dijkstra), Дэвид Парнас и др.

Термин «архитектура» в программировании изначально употреблялся для описания не­единично реализованных вычислительных систем. Это значение сохраняется в силе до сих пор. В 1969 году Фред Брукс и Кен Айверсон (Ken Iverson) определили архитектуру как «кон­цептуальную структуру вычислительной машины... с точки зрения программиста» [Brooks 69]. Несколько лет спустя Брукс, ссылаясь на Г. Блау (G. Blaauw), привел другое определение ар­хитектуры — как «комплексной и подробной спецификации пользовательского интерфейса» [Brooks 75]. Между архитектурой и реализацией было проведено четкое разграничение. Ци­тируя Блау, Брукс писал: «архитектура сообщает о том, что происходит, а реализация — о том, как это должно происходить». Такое разграничение принято и сегодня — в эпоху объектно-ориентированного программирования оно как нельзя кстати.

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

Еще в 1969 году Эдсгер Дийкстра советовал обращать особое внимание на декомпози­цию и структуру программных средств, утверждая, что программировать с единственной це­лью — достичь корректного результата — недостаточно [Dijkstra 68]. В работе, посвященной одной из операционных систем, он ввел принцип многоуровневой структуры, согласно кото­рому программы следует группировать по отдельным уровням, причем те из них, что нахо­дятся на одном уровне, должны взаимодействовать только со смежными уровнями. Дийкстра указывал на концептуальную целостность подобной организации и, как следствие, простоту разработки и сопровождения.

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

♦ Принцип конструирования, описывающий разбиение системы на элементы с целью по­вышения удобства сопровождения и (в чем мы убедимся в главе 5) обеспечения возмож­ности повторного использования. Сложно найти более фундаментальный принцип по­строения архитектуры, нежели этот, названный Парнасом принципом информационной закрытости [Parnas 72].

♦ Принцип обращения к элементу исключительно через его интерфейс. Это вообще кон­цептуальная основа всего объектного проектирования [Parnas 72].

♦ Наблюдение, согласно которому любая программная система состоит из множества от­дельных структур, сопровождающееся предостережением о недопустимости их смеше­ния. Кстати, сегодняшние «архитектурщики» часто забывают этот совет [Parnas 74].

♦ Введение структуры использования — принципа управления связями между элемента­ми с целью повышения расширяемости системы, обеспечения оперативного и неслож­ного получения подмножеств [Parnas 79].

♦ Принцип выявления и обработки ошибок (теперь их называют исключениями) в компо­нентных системах, ставший в большинстве современных языков программирования ос­новополагающим [Parnas 72, 76].

♦ Тезисы о том, что (1) любую программу следует рассматривать как члена семейства про­грамм, (2) общность таких членов можно использовать в своих интересах и (3) те проект­ные решения, которые легче всего пересмотреть, необходимо реализовывать в послед­нюю очередь. Первичное структурирование программы — один из этапов создания архи­тектуры — должно предусматривать принятие начальных, распространяющихся на все семейство, проектных решений [Parnas 76].

♦ Признание воздействия структуры системы на атрибуты ее качества (в частности, на на­дежность) [Parnas 76].

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

Недавно мы с одним коллегой спорили насчет того, что конкретно следует называть ин­терфейсом программного элемента; для обоих было очевидно, что именами программ, к ко­торым существует возможность обращения, и принимаемыми ими параметрами определе­ние интерфейса не исчерпывается. Коллега выразил предположение, что на самом деле речь идет о ряде допущений об элементе, которые мы можем принять с достаточной степенью уверенности и которые варьируют в зависимости от контекста применения этого элемента. Я согласился и показал ему статью Парнаса [Parnas 71], в которой тот говорил абсолютно о том же. Мой приятель, изрядно упавший духом, изрек: «Теперь я знаю, что почувствовал Скотт, когда дошел до Южного полюса и увидел там флаг Амундсена. Он, наверное, подумал: "Черт! Что делать? Меня же теперь загрызут!"».

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

Вскоре после того как исследователи во главе с Парнасом заложили основы построения архитектуры, дисциплина встала на путь эволюционного развития. Известно, что опыт при­менения фундаментальных принципов постепенно приводит к их уточнению, экстраполяции на теорию практики и, в конечном итоге, к появлению совершенно новых концепций. Так, не­сколько десятилетий назад Парнас писал в своих работах о семействах программ (program families); теперь же достижения в области организации, процессов и управления наблюда­ются по большей части в контексте их наиболее успешных концептуальных наследников — линеек продуктов (product lines), — и на материале главы 14 вы сможете в этом убедиться. О разделении задач Дийкстра писал четверть века назад, но давно ли объекты (опять же, кон­цептуальное продолжение изложенного им принципа) получили широкое распространение как стандарт проектирования? Работы Брукса и Блау об архитектуре изданы еще раньше, и сейчас мы знаем, что разобраться в архитектуре невозможно без учета ее экономической составляющей; существуют даже способы проведения анализа архитектур до фактического конструирования систем (их мы рассмотрим позже).

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

-РСС

Глава 3

Авиационная система А-7Е: конкретный пример применения архитектурных структур

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

Э. Гамма, Р. Хелмс, К. Джонсон, Дж. Buccudec [Gamma 95]

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

В настоящей главе мы намерены разобрать конкретный пример архитектуры, созданной путем конструирования и специфицирования трех архитектурных структур: декомпозиции модулей (module decomposition), вариантов использования (uses) и процессов (process). Мы покажем, как эти структуры дополняют друг Друга, как в конечном итоге формируется полная картина функционирования системы и как проявляется влияние структур на отдельные атрибуты качества системы. Параметры трех структур приводятся в табл. 3.1.

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