Архитектура как средство организации общения между заинтересованными лицами

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

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

«А что произойдет при нажатии кнопки выбора режима работы?» — внезапно прервал его один из слушателей. Им оказался представитель правительства — предполагаемого коллек­тива пользователей обсуждаемой системы.

«Простите?» — Архитектор не понял вопроса.

«Кнопка выбора режима работы, — повторил человек из правительства. — Что будет, если я ее нажму?»

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

«Нет, вы не поняли. Я имею в виду — что делает система? — Государственный муж вновь прервал докладчика. — Дисплей перезапускается? И что, если это произойдет в ходе рекон­фигурации системы?»

Несколько озадаченный архитектор убрал указку. Вообще-то вопрос не имел отношения к архитектуре, но, поскольку он все-таки архитектор, а положение это обязывает знать все требования, он ответил. «Если командная строка находится в режиме настройки, дисплеи перезапустятся, — изрек докладчик. — В противном случае на пульт управления выводится сообщение об ошибке, а сигнал игнорируется». — Лазерная указка вновь материализова­лась. — «Так вот, что касается механизма перезапуска...»

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

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

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

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

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

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

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

-РСС

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