В Камаев - Технологии программирования

Далее будет изложена технология проектирования на основе обязанностей (или RDD-проектирование — Responsibility-Driven-Design), предложенная Т. Бадтом. Технология ориентирована на малые и средние проекты. Она основана на поведении систем. Данная технология по способу мышления аналогична разработке структуры служб какой-то организации: директора, заместителей директора, служб и подразделений.

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

В качестве составной части этого процесса полезно изображать объекты с помощью CRC-карточек. Название CRC-карточки образовано от слов: Component, Responsibility, Collaborator — компонента (объект), обязанности, сотрудники. По мере того как для объектов выявляются обязанности, они записываются на лицевой стороне CRC-карточки (рис. 8.6).

Рис. 8.6. Образец CRC-карточки

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

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

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

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

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

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

Анализ аналогов выявил, что уже известен ряд программных реализаций электронных поваренных книг с рецептами блюд. В данной области применения новой была бы программа, позволяющая планировать питание на заданный период. План питания на заданный период состоит из ежедневных планов питания с трех- или четырехразовым приемом пищи. Что надо учесть при разработке ежедневных планов питания? Число человек, калорийность питания каждого человека, любимые и нелюбимые блюда, затраты на питание. Ранние, описанные в литературе попытки оптимизации питания с учетом только продуктов, их калорийности и цен привели к решениям вида: оптимальный завтрак — 12 чашек уксуса. Генерация меню обеда с использованием датчика случайных чисел может привести к решениям с несовместимыми блюдами: молочный суп, сельдь с гороховым гарниром, квас. Решение проблемы — использование набора комплексных завтраков, обедов и ужинов. Есть ли в литературе достаточное описание возможных комплексов? Необходимо ли привлечь специалистов по питанию для разработки требуемого количества комплексов? Сколько будет стоить база данных комплексов? Следует ли реализовать функцию автоматической передачи заказа на продукты в магазин? На эти и другие вопросы необходимо дать ответ, чтобы уложиться в отпущенные средства и сроки.