Создание макета системы

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Дополнительная литература

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

Плодовитая и новаторская деятельность Кристофера Алегзандера (Christopher Alexander) на поприще создания образцов проектирования в архитектуре (имеется в виду постройка здании) послужила основой для разработки образцов программного проектирования. Всем тем, кто стремится к пониманию сущности образцов проектирования, совершенно необходимо прочесть труд [Alexander 77]. (Кстати, эти знания пригодятся, если вам когда-нибудь придется строить дом.)

Из всех авторов, работающих в области образцов проектирования программ, чаще всего цитируются участники так называемой «великолепной четверки» [Gamma 95]. В исследовании [Buschmann 96] архитектурные стили рассматриваются как образцы проектирования — таким образом, эти две важнейшие понятийные области сводятся воедино.

«Мифический человеко-месяц» [Brooks 95] — это обязательное чтение для всех программных инженеров. В переработанной версии книги анализируются сильные стороны итерационной разработки на основе архитектуры, причем особый упор делается на то, как эти принципы применяются в компании Microsoft.

В издании [Bosch 00а] представлен оригинальный метод архитектурного проектирования, который отличается от ADD тем, что в нем сначала формируются предпосылки для реализации функциональности и уже потом на этой основе реализуются все остальные атрибуты качества.

Описание рационального унифицированного процесса содержится в работе [Kruchten 00]. Подробный анализ принципов разработки, принятых в компании Microsoft, дается в издании [Cusumano 95].

Дискуссионные вопросы

1. Исходя из архитектуры, составляются рабочие группы. Они занимаются конструированием модулей, из которых состоит архитектура. Итак, в большинстве случаев в структуре рабочих групп отражена модульная декомпозиция. Каковы преимущества и недостатки формирования рабочих групп исходя из компонентной структуры или на основе какой-то другой архитектурной структуры — например, структуры процессов?

2. ADD предусматривает метод «разбиения» требований. В первую очередь удовлетворяются архитектурные мотивы и только после этого в контексте подстроенного под них решения осуществляются попытки удовлетворить всем остальным требованиям. Какие еще существуют методы разбиения применительно к проектной стратегии декомпозиции? Почему ни одна де* композиция не дает возможности удовлетворить всем требованиям?

3. Какие еще методики помогают построить первоначальную версию программ* ной архитектуры или архитектуры системы? Как в рамках этих методик решаются вопросы соответствия функциональным, коммерческим требованиям и требованиям по качеству?

4. Как ADD соотносится со специализированными методиками проектирования в категориях конечного результата, времени и ресурсов, необходимых для реализации сравниваемых методов? В каких случаях лучше обращаться к ADD и в каких — к специализированным методам?

ОТКУДА БЕРУТСЯ СТАНДАРТЫ?

Пару лет назад в Usenet проскользнула занимательная тема. Обсуждался следующий вопрос: почему в США принята весьма странная стандартная ширина железнодорожной колеи — 4 фута 8 1/2 дюймов. Выводы, которые были сделаны, одинаково справедливы для всех областей технологии, в которых применяются стандарты.

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

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

Но и у вагонеток есть своя история. Первые вагонетки конструировались по образцу повозок. Соответственно, первые строители вагонеток пользовались теми же инструментами и отталкивались от тех же представлений, которые ранее применялись в строительстве повозок. Как бы то ни было, наш вопрос остается без ответа — почему расстояние между колесами повозок должно было быть равным 4 футам и 8 1/г дюймам?

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

Дороги тоже не появились из небытия. Сдерживавший нововведения технологический стандарт обусловливал эту немаловажную особенность повозок. На этот раз причины следует искать в Риме. Первые магистральные пути в Британии строились римлянами, и происходило это в течение первых четырех веков нашей эры. Зачем римляне приняли такое решение? Да затем, что по дорогам такой ширины могли проехать их колесницы. Следовательно, ширина колеи в современных Соединенных Штатах связана с конструкцией римских колесниц, применявшихся двумя тысячелетиями ранее.

Но это еще не все.

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

Все эти доводы, быть может, не слишком убедительны, но — вдумайтесь! — какие могут быть последствия легкомысленного отношения к стандартам. Когда Наполеон напал на Рос- СИ|о, движение его армии в Восточной Европе, сильно замедлились — все потому, что колея на местных дорогах не соответствовала римскому стандарту. Нарушив временные рамки, они п°пали в условия русской зимы. Что случилось после этого, мы все прекрасно знаем.

— RK