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

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

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

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

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

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

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

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

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

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

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

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

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

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

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