Граница между требованиями и проектированию не четкая, однако постарайтесь не делать в ваших спецификациях упор на реализацию, кроме тех случаев, когда имеется веская причина для намеренного ограничения проектирования. В идеале на описание предполагаемых функций системы не должно влиять представление о проектировании (Jackson, 1995). Надо признать, что во многих проектах учитываются ограничения проектирования, налагаемые разработанными ранее продуктами, а совместимость с предыдущими продуктами — самое стандартное требование. Именно поэтому в спецификации к требованиям практически всегда содержится некоторая информация о проектировании. Однако в спецификации не должны содержаться случайные элементы проектирования — то есть ненужные или незапланированные ограничения конечной архитектуры. Подключите проектировщиков или разработчиков к экспертизе требований, чтобы удостовериться, что требования могут служить надежной основой для проектирования. Требования к продукту, атрибуты качества и характеристики пользователей влияют на архитектуру продукта (Bass, Clements и Kazman, 1998). Изучая предлагаемую архитектуру, вы рассмотрите разные точки зрения, что поможет вам проверить требования и отшлифовать их точность, как и при использовании прототипов. Оба метода базируются на следующем посыле: «Если я правильно понимаю требования, то способ, который я сейчас проверяю, позволит удовлетворить их. Теперь же, когда у меня в руках предварительная архитектура (или прототип), поможет ли это мне лучше разобраться в требованиях?»
Архитектура особенно важна для систем, в которые входят компоненты ПО и оборудования, а также для сложных систем, состоящих исключительно из ПО. Важный этап анализа требований — распределение высокоуровневых требований к системе по различным подсистемам и компонентам. Системный инженер, аналитик или архитектор классифицирует требования к системе по их принадлежность к функциональным и требованиям к оборудованию (Leffingwell и Widrig, 2000). Трассируемая информация позволяет разработчикам отследить, в каких элементах архитектуры будет отражено каждое требование.
В результате неверного распределения решений может статься, что ПО, определенное как функциональное, следовало бы назначить компонентам оборудования (или наоборот); кроме того, в таком случае возможна низкая производительность или трудности при замене некоего компонента для улучшения версии. При разработке одного проекта инженер по оборудованию сообщил моей группе, что в нашем ПО должны быть преодолены все ограничения, налагаемые его архитектуре оборудования! Хотя ПО само по себе более гибко, чем оборудование, инженерам не следует использовать это качество, чтобы сэкономить на архитектуре оборудования. Воспользуйтесь приемом проектирования и создания программ, чтобы выработать оптимальные решения того, какие возможности каждый системный компонент будет удовлетворять в рамках заданных ограничений.
Распределение системных функций по подсистемам и компонентам надо выполнять «сверху вниз» (Hooks и Farry, 2001). Представьте DVD-проигрыватель, в который входит мотор, открывающий и закрывающий лоток дисковода и вращающий диск, оптическая подсистема для считывания данных с диска, ПО для формирования изображений, многофункциональный пульт дистанционного управления и многое другое, как показано на рис. 17-3. Подсистемы взаимодействуют для управления поведением в таких случаях, когда, скажем, пользователь нажимает кнопку на пульте дистанционного управления, чтобы открыть лоток дисковода во время проигрывания диска. В таких сложных продуктах требования к системе влияют на архитектуру, а архитектура в свою очередь влияет на распределение требований.
При разработке некоторых проектов архитектура ПО немного изменяется, тем не менее на проектирование время никогда не бывает потрачено зря. Разнообразные разработки ПО удовлетворяют большинству требований к продукту. Они различаются по производительности, эффективности и устойчивости к сбоям, а также по использованным техническим методам. Если вы перескакиваете от требований к коду, это означает, что вы по существу разрабатываете ПО «на лету». Вы предлагаете какую-то архитектуру, но не обязательно идеальную, вероятный результат в этом случае — плохо структурированное ПО. Переделывая код вы, конечно же, улучшите архитектуру (Fowler, 1999). Однако унция заранее разработанного дизайна стоит фунта переделок уже выпущенного продукта. Продумав альтернативы архитектуры, вы будете уверены, что разработчики будут принимать во внимание любые указанные ей ограничения.
Рис. 17-3. Такие сложные продукты, как DVD-проигрывателе, содержат множество подсистем ПО и оборудования
Невероятно уменьшившийся проект
Как-то я занимался проектом, имитирующим поведение фотографической системы с помощью восьми вычислительных процессов. После скрупулезного анализа требований команде не терпелось приступить к написанию кода. Но вместо этого нам пришлось создавать модель — в тот момент мы больше думали о создании решения, а не пытались разобраться в проблеме. Мы быстро поняли, что в трех этапах моделирования использовались идентичные вычислительные алгоритмы, в трех других применялся еще один набор алгоритмов, а в остальных двух — третий набор. Взгляд с позиций проектирования позволил упростить проблему и уменьшить число сложных вычислений с восьми до трех. Начни мы кодировать сразу же после анализа требований, в какой-то момент мы бы без сомнения обнаружили повторение кода, но мы сэкономили массу времени, выявив их гораздо раньше. Изменение моделей проектирования намного более эффективно, чем переделка кода!
Как и в случае с требованиями, отличный дизайн — это результат итераций. Многократно прорабатывайте проектные решения для уточнения первоначальной концепции по мере получения информации и появления дополнительных идей. При недостатках в архитектуре появляются продукты, которые трудно обслуживать и расширять, которые не удовлетворяют пожеланиям клиентов в отношении производительности, легкости и простоты использования и надежности. Время, затраченное на преобразование требований в проектные решения, — это отличная инвестиция в создание высококачественных и надежных продуктов.
Вам не нужно разрабатывать полный подробную архитектуру всего продукта до начала реализации, однако следует выполнить архитектуру каждого компонента до того, как вы приступите к ее реализации. Планирование архитектуры наиболее полезно для особенно трудных проектов, где разрабатываются системы со множеством внутренних граничащих и взаимодействующих друг с другом компонентов, а также тех, которыми занимаются неопытные разработчики (McConnell, 1998). Однако проекты любого типа выиграют, если вы:
· разработаете надежную архитектуру подсистем и компонентов, которая выдержит будущие изменения;
· определите ключевые классы объектов или функциональные модули, которые необходимо создать, определив их интерфейсы, функции и взаимодействия с другими элементами;
· разберетесь, как выполняются планируемые потоки или где размещается функциональность в параллельных процессах для параллельно работающих систем;
· определите предполагаемую функциональность каждой единицы кода, которая следует основному принципу архитектуры: сильная связанность, слабая связь и сокрытие информации (McConnell, 1993);
· убедитесь, что в архитектуру включены все функциональные требования и что она не содержит ненужной функциональности;
· удостоверитесь, что архитектура учитывает все условия исключения, которые могут возникнуть;
· убедитесь, что архитектура будет отвечать заданным критериям производительности, устойчивости к сбоям, надежности и др.
По мере преобразования требований в архитектуру и код разработчики сталкиваются с определенными неясными и запутанными местами. В идеале они могут обратиться к клиентам или аналитиками за разъяснениями. Если же проблему нельзя решить немедленно, любые предположения, догадки или интерпретации разработчики должны задокументировать и отправить на просмотр представителям клиента. Если таких проблем много, значит, требования сформулированы недостаточно ясно и детально до того, как аналитик передал их разработчикам. Просмотрите остальные требования вместе с одним или несколькими разработчиками и уточните их, прежде чем продолжите сборку продукта. Также пересмотрите процессы утверждения требований, чтобы выяснить, как получилось так, что требования низкого качества попали к разработчикам.