Таблицы решений и деревья решений

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

Таблицы решений и деревья решений — это два альтернативных приема для представления того, что система должна делать, когда в игру вступают сложные логика и решения (Davis, 1993). В таблице решений (decision table) перечислены различные значения для всех факторов, влияющих на поведение системы, и приведены ожидаемые действия системы в ответ на каждую комбинацию факторов. Факторы могут быть показаны либо как утверждения с различными условиями true и false, либо как вопросы с возможными ответами «да» или «нет». Естественно, вы также можете использовать таблицы решений с фак торами, которые имеют более двух возможных значений.

В табл. 11-2 показана таблица решений с логикой, управляющей принятием или отклонением запроса нового химиката Chemical Tracking System. На решение влияет четыре фактора:

· авторизирован ли пользователь, создающий запрос;

· имеется ли химикат в наличии на складе или у поставщика;

· включен ли химикат в список опасных химикатов, для работы с которыми необходима специальная подготовка;

· есть ли у пользователя, создающего запрос, соответствующая подготовка для работы с этим типом опасного вещества.

Каждый из этих четырех факторов имеет два возможных условия, true или false. В принципе это увеличивает на 24 или 16 различные комбинации true/false для 16 вероятных отдельных функциональных требований. Однако на практике результатом многих комбинаций является одна и та же реакция системы. Если пользователь не авторизован для запроса химикатов, то система не примет запрос, и таким образом остальные условия несущественны (показаны прочерками в таблице решений). Таблица показывает, что результат различных логических комбинаций — лишь пять отдельных функциональных требований.

Таблица 11 -2. Пример таблицы решений для Chemical Tracking System

Рис. 11 -7. Пример дерева решений для Chemical Tracking System

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

Последнее напоминание

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