Спецификация требований. 
Компьютерные технологии обучения

Для полномасштабного отражения требований к проекту системы в дополнение документа-концепции, включим в интегрированный пакет требований спецификацию прецедентов — модельное представление функциональных требований (см. раздел 4.2).

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

Таким образом, метод прецедентов на раннем этапе разработки создаст активы проекта, которые можно повторно использовать.

Принципы специфицирования требований путем формализации всей совокупности информации реализованы на технологическом этапе управления требованиями в Rational Unified Process. Для моделирования модуля компьютерной обучающей системы использован стандартизованный язык Unified Modeling Language. В соответствии с современными тенденциями программной инженерии моделирование требований осуществлено с использованием CASE-срсдства Rational Rose.

Выбор компоновки интегрированной среды разработки компьютерных обучающих систем (процесс — язык моделирования — CASE-срсдства) обусловлен необходимостью дальнейшей автоматической генерации программного кода и осуществления реверсного инжиниринга для повторного использования программных компонентов в новых проектах КОС.

На основе документа-концепции функциональное описание модуля представляется в модели прецедентов, включающей текстовое описание и UML-диаграммы прецедентов. Фрагмент диаграммы прецедентов, которые инициируются одним из пользователей системы — студентом, представлен на рис. 5.17.

Рис. 5.17. Фрагмент диаграммы прецедентов для модуля генерации учебно-тренировочных заданий.

Поскольку вся серия авторских разработок осуществлялась в рамках процесса Rational Unified Process, при описании прецедентов был использован развернутый шаблон, рекомендуемый этим процессом и имеющий следующую структуру:

• 1. Название прецедента
• 1.1. Краткое описание
• 1.2. Акторы
• 1.3. Триггеры
• 2. Поток событий
• 2.1. Основной поток
• 2.2. Альтернативные потоки
• 2.2.1. Условие 1
• 2.2.2. Условие 2
• 3. Специальные требования
• 4. Предусловия
• 5. Постусловия
• 6. Точки расширения

В качестве примера спецификации приведем описание некоторых прецедентов модуля генерации учебно-тренировочных заданий.

Прецедент 1.

• 1. Название прецедента: Генерация вопросов для теста
• 1.1. Краткое описание

Модуль, следуя определенному алгоритму и в соответствии с заданным уровнем сложности, генерирует набор вопросов для реализации в режиме тестирования по теме конкретной дисциплины.

1.2. Действующие лица

Пользователь, инициирующий прецедент, — студент.

1.3. Триггеры:

Нс выявлено.

• 2. Потоки событий
• 2.1. Основной поток
• 2.1.1. Пользователь активирует модуль генерации компьютерной обучающей системы нажатием на кнопку «Генерация вопросов теста» в меню тестирования.
• 2.1.2. Система выводит окно с запросом дисциплины, по которой пользователь хочет сгенерировать вопросы для тестирования.
• 2.1.3. Пользователь вводит необходимое название дисциплины.
• 2.1.4. Система выводит список тем относящихся к данной дисциплине, по которым у нее заполнена база вопросов.
• 2.1.5. Пользователь выбирает тему для тестирования.
• 2.1.6. Система запрашивает пользователя об уровне сложности вопросов для теста.
• 2.1.7. Пользователь выбирает уровень сложности.
• 2.1.8. Система, получив информацию об уровне сложности, на основе заложенных алгоритмов генерирует вопросы для тестирования.
• 2.2. Альтернативные потоки:
• 2.2.1. Студент ввел имя дисциплины, которой не существует в базе КОС.
• 2.2.1.1. Система выводит сообщение об отсутствии в базе данных этой дисциплины.
• 2.2.1.2. Система просит пользователя повторно ввести название дисциплины, по которой он намерен тестироваться.
• 2.2.2. В системе нет базы вопросов по указанной пользователем дисциплине.
• 2.2.2.1. Система выводит сообщение об отсутствии вопросов по данной дисциплине.
• 2.2.2.2. Система спрашивает пользователя, хочет ли он продолжить генерацию вопросов для тестирования по другой дисциплине. При утвердительном ответе пользователя система переходит к пункту 2.1.2, а при отрицательном ответе — к основному окну КОС.
• 3. Предусловия

Пользователь должен быть идентифицирован в системе как «Студент» и иметь соответствующие права доступа.

4. Постусловия

Система генерирует набор вопросов и передает их КОС, которая, в свою очередь, позволяет перейти к прецеденту «Работа с тестом».

5. Точки расширения

Не выявлено.

Прецедент 2.

1. Название прецедента: Генерация заданий для тренажера

/. 1. Краткое описание

Модуль генерирует набор заданий из базы данных в соответствии с уровнем сложности выбранным студентом.

1.2. Действующие лица:

Пользователь — студент.

1.3. Триггеры

Не выявлено.

• 2. Потоки событий
• 2.1. Основной поток:
• 2.1.1. Пользователь выбирает генерацию заданий из главного меню КОС.
• 2.1.2. Система запрашивает предмет, по которому пользователь хочет сгенерировать набор заданий для тренажера.
• 2.1.3. Пользователь вводит предмет.
• 2.1.4. Система выводит список тем, по которым в базе данных КОС есть набор заданий для тренажера.
• 2.1.5. Пользователь выбирает необходимую ему тему.
• 2.1.6. Система запрашивает информацию об уровне сложности генерируемых заданий для тренажера (так же, как и с тестом, таких уровней три).
• 2.1.7. Пользователь выбирает необходимый ему уровень сложности.
• 2.1.8. Система генерирует набор заданий для тренажера, используя алгоритм, привязанный к выбранному Пользователем уровню сложности, и передает сгенерированные задания КОС, которая начинает реализацию прецедента «Работа с тренажером».
• 2.2. Альтернативные потоки:
• 2.2.1. Пользователь ввел предмет, которого в базе данных системы нет.
• 2.2.2. Система выведет сообщение о том, что такого предмета нет в ее базе данных, и повторно запросит ввести предмет.
• 2.2.3. В системе нет набора заданий для тренажера по введенному пользователем ранее предмету.
• 2.2.4. Система сообщит о том, что на момент набора заданий для тренажера по данному предмету пока нет.
• 2.2.5. Система спросит: «желает ли Пользователь сгенерировать набор заданий по другому предмету», — и при утвердительном ответе перейдет к пункту 2.1.2. основного потока событий.
• 3. Предусловия

Пользователь должен быть идентифицирован системой как Студент и иметь соответствующие права доступа.

4. Постусловия

Система генерирует набор заданий и передает их КОС, которая в свою очередь позволяет перейти к прецеденту Работа с тренажером.

5. Точки расширения

Не выявлено.

Прецедент 3.

• 1. Название прецедента: Генерация вопросов для самопроверки.
• 1.1. Краткое описание:

Модуль генерирует список вопросов для реализации в режиме самопроверки. Вопросы могут быть представлены с вариантами правильного ответа и без них. Вопросы берутся из базы данных КОС.

1.2. Действующие лица:

Пользователь, инициирующий прецедент, — студент.

1.3. Триггеры:

Запуск ссылки в конце материала учебника, либо активация кнопки генерации вопросов для самопроверки из основного меню КОС.

• 2. Потоки событий
• 2.1. Основной поток
• 2.1.1. Пользователь активирует модуль генерации компьютерной обучающей системы нажатием на кнопку «Генерация вопросов для самопроверки» в меню работы с компьютерным учебником.
• 2.1.2. Система запрашивает дисциплину, по которой нужно сгенерировать вопросы для самопроверки, либо считывает ее из компьютерного учебника.
• 2.1.3. Пользователь вводит название дисциплины.
• 2.1.4. Система выводит список тем дисциплины, по которым есть вопросы в базе данных.
• 2.1.5. Пользователь выбирает список тем, для которых необходимо сгенерировать набор вопросов для самопроверки.
• 2.1.6. Система запрашивает вариант отображения вопросов (с ответами или без них).
• 2.1.7. Пользователь выбирает необходимый ему вариант.
• 2.1.8. Система запрашивает уровень сложности генерируемых вопросов.
• 2.1.9. Пользователь выбирает необходимый ему уровень сложности.
• 2.1.10. Система генерирует набор вопросов в соответствии с алгоритмом, определяющим формирование тестового задания по заданным уровням сложности, и выводит список вопросов.
• 2.2. Альтернативные потоки:
• 2.2.1. Пользователь ввел название дисциплины, информация о которой отсутствует в базе КОС.
• 2.2.1.1. Система сообщает, что такой дисциплины в базе нет, и просит повторно ввести название дисциплины.
• 2.2.2. Для указанной пользователем дисциплины нет набора вопросов в базе данных.
• 2.2.2.1. Система сообщает об отсутствии вопросов для самопроверки по данной дисциплине.
• 2.2.2.2. Система запрашивает пользователя о генерации набора вопросов для самопроверки по другой дисциплине.
• 3. Предусловия

Пользователь должен быть идентифицирован в системе как «Студент» и иметь соответствующие права доступа.

4. Постусловия

Не выявлено.

5. Точки расширения

Не выявлено.

Следует отметить, что прецеденты, описывающие последовательность действий системы и пользователя, а не отдельные требования, значительно упрощают проблему ортогональности, которая заключается в отсутствии прямой связи между отражающими проблемную область требованиями и реализационным кодом. Приблизиться к цели непосредственного преобразования требований в код позволяют характеристики прецедентов и модельные конструкции универсального языка моделирования Unified Modeling Language.