Блог >
Как разработать требования к программному обеспечению на языке ДРАКОН
Требуй чёткой постановки задачи
Разработка требований к программному обеспечению начинается с постановки задачи. Чётко поставленная задача — необходимое входное условие для составления требований. Если клиент не предоставил описание задачи, такое описание придётся составить и согласовать с клиентом.
Описание делают коротким, желательно в виде пунктов.
Пример:
- Реализовать вход с паролем на вебсайт.
- Во время входа заменить текущую сессию на новую.
- После успешного входа связать новую сессию с записью пользователя.
- После успешного входа показать персонализированную начальную страницу.
- После успешного входа закрыть все остальные сессии пользователя.
- Система автоматически закрывает сессию после бездействия пользователя.
- Если неправильный пароль введён 3 раза, заблокировать пользователя.
- Сделать паузу между проверками пароля одного пользователя в 3 секунды.
Изображения и списки вместо прозы
Чем меньше сплошного текста в требованиях, тем лучше. Вместо прозы рисуйте диаграммы, составляйте списки и таблицы.
В состав требований будут входить следующие материалы:
- ДРАКОН-схемы для описания поведения программного обеспечения. Основная сложность программ заключается в поведении, поэтому ДРАКОН-схемы будут составлять большую часть требований.
- Описание логической структуры данных, с которыми будут работать алгоритмы программы.
- Форматы входных и выходных данных.
- Эскизы для графического интерфейса пользователя.
- Приёмочные тесты, или acceptance tests.
Эта статья рассказывает, как рисовать ДРАКОН-схемы для требований к программному обеспечению. Как составлять приёмочные тесты из ДРАКОН-схем, смотрите здесь: ссылка.
Найди входные точки
Рассматривайте программу как пассивный чёрный ящик, который ничего не делает, пока не получит толчок из внешнего мира. Во внешнем мире происходят события, которые приводят программу в движение. Это входные точки в систему.
Создайте список входных точек. Каждой входной точке соответствует алгоритм, по которому программа будет реагировать на событие.
Входные точки разбивают единое полотно программы на отдельные куски. Действует принцип "разделяй и властвуй".
Важно найти все входные точки. Это не всегда просто, так как некоторые входные точки не очевидны.
Возьмём пример с входом на сайт. Первая входная точка — "Вход с паролем". Пользователь нажимает кнопку "Войти", чтобы залогиниться. Здесь всё понятно.
"Система автоматически закрывает сессию после бездействия пользователя." Данное утверждение скрывает дополнительную входную точку — автоматическое закрытие сессии. Это событие примечательно тем, что произойдёт в будущем.
Когда алгоритм планирует действие в будущем, это действие — тоже входная точка. В таком случае внешний толчок во входную точку приходит не от пользователя, а как бы по сигналу будильника. Не смотря на это отличие, документируйте и тестируйте входные точки отложенных действий на общих основаниях.
Откладывание автоматического закрытия сессии — ещё одна скрытая входная точка. Каждым своим действием на сайте пользователь откладывает автоматическое закрытие сессии. Описание задачи не указывает это в явном виде, и поэтому эту входную точку легко пропустить.
Входные точки:
- Вход с паролем
- Автоматическое закрытие сессии
- Отложить автоматическое закрытие сессии
Нарисуй ДРАКОН-схему для каждой входной точки
Приход внешнего толчка во входную точку запускает процесс. Алгоритм этого процесса описывают одной ДРАКОН-схемой верхнего уровня и, возможно, несколькими подчинёнными ДРАКОН-схемами.
Разложи процесс на шаги — приказы и вопросы
Чтобы создать ДРАКОН-схему процесса, изобразите поведение системы в виде последовательности приказов и вопросов. Соблюдайте принцип: одна икона — одна мысль. Читайте руководство по рисованию ДРАКОН-схем здесь: ссылка.
Рассмотрим входную точку "Вход с паролем" из нашего примера.
Царская дорога
Царская дорога, или happy path, идёт сверху-вниз по главной вертикали:
- Приказ: получить имя и пароль от пользователя.
- Приказ: найти пользователя в базе.
- Вопрос: пользователь найден? Ответ: да.
- Приказ: проверить пароль.
- Вопрос: проверка пароля завершилась успехом? Ответ: да.
- Приказ: подключить сессию к пользователю.
- Приказ: отложить автоматическое закрытие сессии.
- Приказ: показать персонализированную главную страницу.
Менее успешный сценарий уходит вправо:
- Вопрос: пользователь найден? Ответ: нет.
- Приказ: показать сообщение об ошибке.
- Приказ: через три секунды дать пользователю попробовать ещё раз.
Стрелки — только для циклов
Стрелки — графические детали, которые отвлекают внимание и занимают место. Для линейного течения событий в ДРАКОНе не применяют стрелки. В ДРАКОНе время течёт вниз. Так как направление движения процесса известно, простых линий достаточно.
Стрелка на ДРАКОН-схеме означает цикл и встречается редко, поэтому циклы бросаются в глаза.
Обратите внимание, что решения, принимаемые на основании наличия пользователя и правильности пароля, вынесены в головную схему. Как неправильное имя пользователя, так и неправильный пароль вызывают одинаковое видимое поведение системы: сообщение об ошибке, пауза на три секунды, новая попытка.
Отбрось ненужные детали
ДРАКОН-схема показывает последовательность действий системы точно и однозначно, но без лишних технических деталей и формализмов.
В нашем примере икона "Ввод" задаёт, что процесс получает данные извне — от пользователя.
Схема не объясняет, как работают виджеты для имени пользователя и пароля, показываются ли эти виджеты одновременно или по очереди. Читатель узнаёт только суть: пользователь вводит данные в систему.
Аналогично, икона "Вывод" отправляет данные наружу из процесса — сообщение об ошибке пользователю. В каком месте на экране появляется сообщение и с каким шрифтом — не важно на этом уровне абстракции.
Икона "Пауза" говорит: процесс замирает на три секунды, и пользователь не влияет на ход процесса в это время. ДРАКОН-схема "Вход с паролем" не указывает, как реализовать паузу. Возможно, вся страница или только некоторые виджеты будут "заморожены" на время паузы. Такие технические детали не требуются для понимания работы системы в целом. Если нужно, эти детали можно описать в требованиях более низкого уровня.
Избегай переменных и параметров
Программисты любят переменные. Программисты кладут в переменные значения и передают переменные в аргументы функций. Переменные превращают требования в нечитаемый программный код. Место переменных — в программах, не в требованиях.
Избегайте переменных в требованиях, если можете. Это относится и к передаче параметров в подчинённые ДРАКОН-схемы.
Процедура "Проверить пароль" принимает в составе входных данных пользователя и пароль. ДРАКОН-схема "Проверить пароль" показывает это в иконе "Параметры".
В ДРАКОН-схеме "Вход с паролем" икона "Вставка" вызывает подчинённую ДРАКОН-схему "Проверить пароль", но в тексте иконы нет переменных "пароль" и "пользователь". В иконе "Вставка" есть только название подчинённой схемы — "Проверить пароль".
Если щёлкнуть на этой иконе правой кнопкой мыши, в контекстном меню появится возможность перейти к схеме "Проверить пароль". DrakonHub автоматические вставил эту ссылку, так как нашёл имя схемы в тексте иконы.
Чем правее, тем хуже
Рассмотрим процедуру "Проверить пароль". Царская дорога на этой диаграмме идёт прямо, без поворотов по главной вертикали:
- Вопрос: пользователь заблокирован? Ответ: нет.
- Вопрос: с прошлой проверки пароля прошло более 3 секунд? Ответ: да.
- Вопрос: пароль правильный? Ответ: да.
- Приказ: считать проверку пароля успешной.
Кроме наилучшего сценария, через диаграмму проходят и другие, менее успешные пути. Правило "чем правее, тем хуже" предписывает сортировать пути через диаграмму. Чем менее удачно складывается сценарий, тем правее этот сценарий расположен на диаграмме.
В нашем примере неправильный пароль хуже правильного, а блокировка пользователя хуже, чем ещё один шанс попробовать.
Сообщай намерение в приказах и вопросах
На диаграмме "Проверить пароль" нет никаких переменных или счётчиков для подсчёта неудачных попыток входа. Для программиста естественно завести такой счётчик и совершать с ним следующие действия:
- обнулить в начале;
- сравнивать значение счётчика с числом 3, когда пароль неправильный;
- увеличивать значение при неудачных попытках входа.
Не программируйте в требованиях, уберите переменные. Вместо того, чтобы жонглировать значениями переменных, поместите в вопрос или приказ намерение, желаемый результат этого шага. В нашем примере намерение — выяснить, совершил ли пользователь 3 неудачных попытки входа. Разработчики догадаются, как реализовать это намерение.
Смотрите также
Инструкция по рисованию ДРАКОН-схем
