Архитектура как средство организации общения между заинтересованными лицами
Заслушивался отчет о проекте. Его разработка, финансируемая из правительственного фонда, давно вышла за рамки графика и бюджета. Масштаб же его был столь серьезен, что упомянутые недочеты удостоились внимания конгрессменов, и теперь, пытаясь решить забытую было проблему, правительство организовало занудную отчетную сессию с обязательным посещением. Компанию-разработчика недавно перекупили, однако делу это не помогло. На второй день сессии была запланирована презентация программной архитектуры. Молодой архитектор — ученик главного архитектора системы — бодро объяснял, каким образом архитектура столь масштабной системы обеспечит соответствие высоким требованиям по работе в реальном времени, распределенности и высокой надежности. Основательная архитектура презентовалась не менее основательно. Анализ проводился тщательно и корректно. Тем не менее слушатели — около 30 представителей правительства с различными функциями в управлении и надзоре за этим нелегким проектом — утомились. Некоторые из них даже подумывали, что легче уйти в недвижимость, чем пытаться выдержать очередной отчет по принципу «ну давайте же наконец сделаем все как надо». На схеме, составленной на полуформальной нотации из прямоугольников и линеек, были зафиксированы основные программные элементы представления системы периода прогона. Названия обозначались сокращениями, и если бы молодой архитектор не давал объяснений, в них вряд ли можно было бы разобраться. Линии указывали потоки данных, передачу сообщений и синхронизацию процессов. По словам архитектора, эти элементы внутренне избыточны. «В случае сбоя, — сказал он, наведя лазерную указку на одну из линий, — на этом пути сработает механизм перезапуска...» «А что произойдет при нажатии кнопки выбора режима работы?» — внезапно прервал его один из слушателей. Им оказался представитель правительства — предполагаемого коллектива пользователей обсуждаемой системы. «Простите?» — Архитектор не понял вопроса. «Кнопка выбора режима работы, — повторил человек из правительства. — Что будет, если я ее нажму?» «Ну-у, при этом запускается событие в драйвере устройства, вот здесь, — начал архитектор, манипулируя указкой. — Затем считываются данные в регистре, интерпретируется код события. Если речь идет о выборе режима, то... на доску объявлений будет подан сигнал, та, в свою очередь, сигнализирует объектам, которые на это событие подписались...» «Нет, вы не поняли. Я имею в виду — что делает система? — Государственный муж вновь прервал докладчика. — Дисплей перезапускается? И что, если это произойдет в ходе реконфигурации системы?» Несколько озадаченный архитектор убрал указку. Вообще-то вопрос не имел отношения к архитектуре, но, поскольку он все-таки архитектор, а положение это обязывает знать все требования, он ответил. «Если командная строка находится в режиме настройки, дисплеи перезапустятся, — изрек докладчик. — В противном случае на пульт управления выводится сообщение об ошибке, а сигнал игнорируется». — Лазерная указка вновь материализовалась. — «Так вот, что касается механизма перезапуска...» «Вы знаете, я вот почему интересуюсь, — продолжил будущий пользователь. — Исходя из вашей схемы, складывается впечатление, что дисплейный пульт подает сигналы целевому модулю.» «А что, собственно, должно произойти? — В разговор включился еще один слушатель, адресуя свой вопрос любознательному джентльмену. — Вы что, хотите, чтобы во время перестройки режима пользователь получал какие-то данные об этом режиме?» В течение последующих 45 минут архитектор внимательно наблюдал за тем, как слушатели тратят отведенное ему время на обсуждение корректного поведения системы в самых разных, одним им известных состояниях. Дискуссия не имела отношения к архитектуре, однако именно она (и ее графическое представление) послужила побудительным мотивом. Архитектуру имеет смысл рассматривать как основу для взаимодействия заинтересованных лиц помимо архитекторов и разработчиков. К примеру, с ее помощью руководители проектов формируют рабочие группы и распределяют между ними ресурсы. Ну а пользователи? Для них архитектура незаметна, так с какой стати они должны вникать в сущность системы именно с ее помощью? Но именно так они и делают. В представленном случае человек, который начал задавать вопросы, просидел два дня, уставившись в схемы функций, операций, пользовательского интерфейса и тестирования. Он устал, ему хотелось домой, но именно во время изложения отчета об архитектуре он понял, что что-то ему непонятно. Прослушав множество отчетов о вариантах архитектуры, я убедился в том, что рассмотрение системы под новым углом выводит на поверхность многие неясности. В такой роли для пользователей часто выступает именно архитектура, причем вопросы, которые они начинают задавать, оказываются по своему характеру поведенческими. Во врезке «Их решение не годится» (см. главу 11) мы рассмотрим пример процесса оценки архитектуры, в ходе которого представители пользователей больше интересовались не тем, как система будет работать, а тем, что она сможет делать, и это совершенно естественно. До представленного момента все их контакты с производителем осуществлялись только через посредство продавцов. Архитектор — настоящий специалист по интересующей их системе, и им довелось с ним пообщаться; вполне объяснимо, что они, нисколько не колеблясь, воспользовались моментом. Очевидно, что рассматриваемую проблему можно решить при помощи тщательно составленных, всесторонних спецификаций требований; впрочем, в силу самых разных причин не во всех случаях они создаются или оказываются доступными. В отсутствие подобных документов именно спецификация архитектуры способна вывести недопонимание на уровень вопросов и таким образом внести в проблему ясность. Этот эффект разумнее принять к сведению, чем опровергать. В главе 11 мы будем рассматривать уточнение требований и их классификацию согласно приоритетам как один из основных аргументов за проведение оценки архитектуры. Иногда подобная практика помогает выявить необоснованные требования, к обсуждению полезности которых впоследствии можно возвратиться. Проведение такого рода обзора, в ходе которого акцент ставится на взаимодействие требований и архитектуры, позволило бы вышеупомянутому молодому архитектору отвлечься от основной темы и уделить в рамках отчетной сессии некоторое время на разбор соответствующей информации. Тогда и представитель гвардии пользователей не почувствовал бы себя неуютно, задав вопрос в самый неподходящий момент. Хотя, в конце концов, он всегда может уйти в недвижимость. -РСС
|
