7.3. Формирование рабочих групп

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

Не так давно — а именно в 1968 году — в литературе проходила дискуссия относительно тесной взаимосвязи между архитектурой и компанией-разработчиком. В работе [Conway 68, 29] эта проблема оценивается следующим образом.

Возьмем любые два узла системы — х и у. Либо они соединены ветвью, либо нет. (Другими словами, либо обмен данными между ними имеет какое-то значение в контексте функционирования системы, либо нет.) Если ветвь имеется, значит, две (не обязательно явно выраженные) рабочие группы X и У, которые разрабатывали эти два узла, очевидно, как-то согласовывали спецификацию интерфейса, через который они должны были обмениваться информацией. Если же между хм у нет никакой ветви, значит, эти подсистемы не передают друг другу никаких данных, что со всей ясностью предполагает отсутствие предмета для обсуждения между разрабатывавшими их рабочими группами, — итак, связь между X и Y мы в этом случае установить не можем.

Согласно мысли Конвэя (Conway), структуру организации (по крайней мере, в том, что касается каналов взаимодействия между ее подразделениями) можно установить по структуре разработанной ею системы; при этом отношения между структурами организации и системы обязательно являются двунаправленными.

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

Таким образом, группы в рамках организации работают над модулями. Участники каждой отдельно взятой группы должны при взаимодействии друг с другом пользоваться средствами связи с высокой пропускной способностью — дело в том, что они постоянно обмениваются информацией, представленной в форме подробных проектных решений. Низкая пропускная способность вполне достаточна (на самом деле даже желательна) для средств связи между группами. (На этот счет у Фреда Брукса (Fred Brooks) свое мнение — по его убеждению, если не регламентировать обмен информацией между участниками одной группы, проект может провалиться.) Все эти принципы, естественно, справедливы лишь в том случае, если в системе проведено разделение задач.

Результатом несоблюдения этих проектных критериев становятся излишне сложные системы. Оказывается, что от структуры рабочих групп и качества их координации во многом зависит судьба любого крупного проекта. С чем может быть связана необходимость в сложном и активном взаимодействии между рабочими группами? Либо с тем, что излишне сложны механизмы взаимодействия между элементами, над которыми они трудятся, либо с тем, что требования к этим элементам не были предварительно в достаточной степени «ужесточены». В таком случае не обойтись без высокой пропускной способности средств связи между группами (не только внутри групп), сложных переговоров и согласований, а иногда — даже без переработки элементов и их интерфейсов. Подобно программным системам, рабочие группы должны стремиться к низкому сцеплению и высокой связности.

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

♦ Модуль, относящийся к уровню пользовательскою интерфейса системы. Интерфейс прикладного программирования, который он предоставляет Другим модулям, никоим образом не связан с какими бы то ни было конкретными элементами пользовательского интерфейса (переключателями, шкалами, диалоговыми окнами и т. д.), при помощи которых информация представляется человеку; связано это с тем, что последние подвержены изменениям.

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

♦ Модуль физических моделей архитектуры системы А-7Е (см. главу 3). Он инкапсулирует уравнения, при помощи которых вычисляются показатели физической среды. Предметная область в данном случае включает в себя численный анализ (уравнения следует реализовать с расчетом на поддержание в числовом компьютере достаточной степени точности) и авиационную электронику.

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

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

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

ОРГАНИЗАЦИОННЫЕ И АРХИТЕКТУРНЫЕ СТРУКТУРЫ

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

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

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

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

-LJB

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

7-4. Создание макета системы

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

Согласно классической методике программной инженерии, следует «заглу-шать» секции кода — так, чтобы различные части системы можно было вводить Действие и тестировать по отдельности. О каких именно частях идет речь? Последовательность реализации всегда можно установить по характеристикам ар- Хит(*туры.

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

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

Приняв решение относительно введения в систему очередной порции функциональности, обратитесь к структуре использования (см. главу 2) — она сообщит

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

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

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

Согласно Кусумано (Cusumano) и Селби (Selby), компания Microsoft выстраивает свою стратегию на основе эволюционного жизненного цикла поставки (Evolutionary Delivery Life Cycle). По той версии методики, которой пользуется Microsoft, «завершенный» макет системы создается на раннем этапе жизненного цикла продукта, а впоследствии с некоторой регулярностью (во многих случаях ежедневно строятся рабочии версии с сокращенной функциональностью. В результате получается рабочая система, о достаточности характеристик которой можно принять решение в любой момент и которую в любой же момент можно развернуть. впрочем, одна проблема, которую следует предусмотреть, — дело та рабочая группа, которая заканчивает свою часть системы первой, задает интерфейс которому должны соответствовать все последующие системы. Это обстоятельство ставит в невыгодное положение наиболее сложные части системы - их разработка сопряжена со значительно большими объемами аналитических действий, вследствие чего вероятность первоочередного определения их интерфейсов он сильно снижается. Таким образом, и без этого сложные подсистемы становятся еще более сложными. По нашему убеждению, все согласования по поводу интерфейсов следует проводить на этапе создания макета системы — при таком условии на последующих стадиях разработки можно будет обратить большее внимание на достижение эффективности.