Довольно часто совокупность ПО управляется сложной логикой, учитывающей разные комбинации условий, результатом которых есть разное поведение совокупности. К примеру, в случае, если шофер нажимает кнопку ускорения на совокупности автомобиль-контроля и круиз автомобиля сейчас двигается, то совокупность увеличит скорость автомобиля, в другом случае команда игнорируется. Для спецификации требований к ПО нужны функциональные требования, в которых будет обрисовано, что обязана делать совокупность при всех комбинациях условий. Но условие легко пропустить, в следствии чего пропускается и требование. Эти пробелы тяжело подметить, просматривая текстовые спецификации вручную.
Таблицы ответов и деревья ответов — это два других приема для представления того, что совокупность обязана делать, в то время, когда в игру вступают сложные решения и логика (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 продемонстрировано дерево ответов, воображающее ту же логику. Пять прямоугольников обозначают пять вероятных результатов принятия либо отклонения запроса на химикат. Таблицы ответов и деревья ответов — это хорошие методы документации требований (либо бизнес-правил), разрешающие не пропустить ни одну комбинацию условий. Кроме того сложная таблица либо дерево ответов более несложны для чтения, чем повторяющиеся требования в текстовом виде.
Последнее напоминание
У каждого приема моделирования, обрисованного в данной книге, имеется и собственные преимущества, и собственные ограничения. Эти приемы разрешают представить одинаковые области, исходя из этого вам не нужно создавать для собственного проекта все типы диаграмм. К примеру, если вы создаете диаграмму «сущность-словарь» и связь данных, не следует рисовать диаграмму классов (либо напротив). Не забывайте, что вы создаете модели анализа чтобы обеспечить более взаимодействия и высокий уровень понимания, чем тот, что дает текстовая спецификация требований к ПО либо любое второе представление требований. Старайтесь не стать догматиком и не принимать участие в религиозных войнах, каковые время от времени случаются в мире моделей и методов разработки ПО. Совместно этого, применяйте все дешёвые средства чтобы как возможно лучше растолковать требования к вашей совокупности.