Алекс,
по поводу Вашей работы. Я, конечно, не знаю что и как читал Вам Ваш преподаватель, но впечатление двойственное.
С одной стороны сама работа выглядит добротной. Или шаблон хороший, или объяснения были четкие.
С другой стороны есть ощущения попытки использовать UML ради самого UML.
Для начала не очень понятна цель применения вариантов использования.
Как мы знаем, ВИ - это функциональные требования, выраженные с точки зрения потребностей пользователя.
Вопрос использования ВИ в Вашем проекте не очевиден. На самом деле требования к системе уже прописаны.
Однако у Вас получается вторичное описание требований в виде сценариев ВИ.
Самая идея, кажется, нормальной. Но от ВИ только сама идея, причем ее применение идет в разрез тому, что пишут, говорят сами изобретатели ВИ и популяризаторы ВИ.
Возьмем концептуальный уровень и описания ВИ.
Пользователь один. Цель его можно сформулировать так: Получить справку на интересующий вопрос, все остальное это по сути реализация этого требования, т.е. требования пользователя - я хочу получить справку по интересующему вопросу.
При этом основной успешный сценарий - справка найдена, не успешный не найдена по тем или иным причинам
Ваши ВИ - это по сути уж предложения по реализации. При этом ВИ описаны очень контекстно, если не считать, что для описания функций системы (но вовсе не ВИ, как Вам кажется) Вы используете описание миниспецификаций процессов с использованием структурированного естественного языка в манере структурного подхода (например DFD)
Методика реализации ВИ на логическом уровне в целом выглядит вполне нормальной, правда предусмотрев управляющие классы (Просмотр следующего термина, предыдущего термина, заданного термина), Вы забыли об интерфейсах.
А ведь модель использования, которую Вы изобразили только с помощью диаграммы ВИ в первую очередь помогает определить граничные классы, т.е. некие сущности с которыми будет взаимодействовать пользователь. А у Вас кроме меню ничего нет.
Но меню оно же не само по себе, оно на чем-то расположено? Справка - термин куда-то выводится, подробное его описание тоже где-то проявляется
меню, следующий термин, предыдущий термин, заданный термин, запись, файл, имя файла, сообщение об отсутствии информации.
Первые четыре понятия, безусловно, можно рассматривать как объекты, причем объекты интерфейса, так как они непосредственно взаимодействуют с пользователем. Сообщение следует считать экземпляром объекта интерфейса типа Сообщение
Не совсем ясно, что тут имелось в виду.
Диаграммы состояний объектов не ясны, не ясен смысл их изображения и выбор объектов.
Непонятно разделения чего-то на два объекта Следующий и Предыдущий, не понятно, куда девался Текущий.
Если бы был объект Запись, у которого есть признак-состояние Текущая, Следующая, Предыдущая, Первая, Последняя, ну тут было бы понятнее.
Поиск - все таки это процесс. Процесс - безусловно смена состояний во времени. Но состояние это характеристика объекта. Тогда не понятно что описывает диаграмма состояний Поиск. ДС какого объекта - всей программы в целом?
Диаграмма последовательностей действий для какого сценария описывается - а ведь она описывает именно реализацию (возможную) сценария варианта использования. А у Вас похоже все в кучу
Ну про диаграмму компоновки и размещения я умолчу.
Возможно у вашего преподавателя была цель проверить, как Вы знаете различные диаграммы и как Вы их умеете применять, а вот корректность и правильность применения его особо не интересовала.
Как-то так
Контрольная по ООП.