Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».

Я своим студентам рекомендую писать «Система убеждается, что ... и сообщает …», т.к. вижу 2 разных операции, также, как, например, в случае сохранения.

Ну Денис, мне кажется, у Коуберна именно то, что я тебе и сказал. Понятно он не пишет про внутреннее поведение, скажем это мое прочтение, но про не проверять и подтверждать у него написано, верно? И о том как развиваются события дальше.

В общем, не вижу причин в чем-то друг друга убеждать.  Думаю мы говорим об одном и том же. Это лишь было уточнение.

Друзья,

интересно ваше мнение по спецификации данного варианта использования.

Имя: Просмотреть дневник ученика
ID: 006
Краткое описание: ВИ описывает просмотр расписания, оценок, ДЗ, посещаемости, примечаний в дневнике учеником или родственником
Действующие лица: Ученик
Предусловие:
1.Ученик авторизован в системе
2. Система отображает профиль ученика с его личными данными (ФИО, дата рождения, класс, адрес, телефон, email, ФИО родственников) и тремя опциями: выйти, рейтинг успеваемости, дневник.
Постусловие: Отображено расписание, ДЗ, оценки, посещаемость, примечания в электронном дневнике
Основной поток:
1.Ученик или родственник выбирает опцию ”Дневник”.
2.Система отображает текущую неделю в дневнике, с возможностью перелистывать страницы назад и вперед (предыдущая и следующая неделя), в котором содержится информация о расписании занятий, посещаемости, успеваемости, домашних заданиях и примечаниях.

Друзья,

интересно ваше мнение по спецификации данного варианта использования.

Имя: Просмотреть дневник ученика
ID: 006
Краткое описание: ВИ описывает просмотр расписания, оценок, ДЗ, посещаемости, примечаний в дневнике учеником или родственником
Действующие лица: Ученик
Предусловие:
1.Ученик авторизован в системе
2. Система отображает профиль ученика с его личными данными (ФИО, дата рождения, класс, адрес, телефон, email, ФИО родственников) и тремя опциями: выйти, рейтинг успеваемости, дневник.
Постусловие: Отображено расписание, ДЗ, оценки, посещаемость, примечания в электронном дневнике
Основной поток:
1.Ученик или родственник выбирает опцию ”Дневник”.
2.Система отображает текущую неделю в дневнике, с возможностью перелистывать страницы назад и вперед (предыдущая и следующая неделя), в котором содержится информация о расписании занятий, посещаемости, успеваемости, домашних заданиях и примечаниях.

IMHO: меньше текста - лучше читается.

-----------------------------------------------------
Название: просмотр своего дневника
ОДЛ: ученик, "родитель ученика"
Основной сценарий:
1. ОДЛ отдает команду на просмотр дневника
2. SuD отображает текущую неделю в дневнике (атрибуты страницы смотри в разделе "Описание объектов")

Расширение: есть навигация, позволяющая перемещаться на неделю назад - вперед или переместиться на произвольную неделю.
-- Все. Больше ничего не надо. ----------------------------------------------------

Предусловие: ОДЛ авторизован в системе - мне кажется необязательно это писать. Если указана роль, то определить ее система может только после авторизации.
Постусловие в данном случае не нужно. Если сильно хочется, можно добавить раздел "минимальные гарантии", но здесь это только затуманит понимание.

Спасибо, Сергей.

А как должно выглядеть Описание объектов в таком случае?

Один из студентов подсказал мне хорошую ссылку по теме: https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html#top

Один из студентов подсказал мне хорошую ссылку по теме: https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html#top

Спасибо, но мне интересны Ваши профессиональные замечания

Я готов под ними подписаться, поэтому можешь считать и моими замечаниями тоже.

Я готов под ними подписаться, поэтому можешь считать и моими замечаниями тоже.

Это советы по диаграмме вариантов использования.
Но по мимо этого интересуют ошибки описаний вариантов использования.

А как должно выглядеть Описание объектов в таком случае?

В требованиях мы описываем инфологическую модель https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Вариантов масса, выбираем по месту.
* Мне нравится табличный вид. Пример есть в опубликованным мной примере требований. Ты его даже рекомендовал.
* Многие считают, что ER-диаграмма "круче". Тем кто хочет считать себя "крутыми" (студентам) можно рекомендовать такой вид записи.
* Часто важно не только содержание, но и форма. В этом случае хорош метод описания конечных форм. Прикладываете фото кассового чека, а потом описываете, что на этом чеке что. Не так "круто", как ER-диаграмма, но куда более полезно.

PS. Кстати. На рынке нет (или мало) тренингов по описанию предметной области. Есть ли на это спрос?

Пролетая мимо, интересно заметить, что в подразделе форума, посвящённому UML-нотации, размещена тема, в которой по большей части обсуждаются не ошибки с точки зрения нотации, а ошибки use-case моделирования (назовём это так), за которые некоторые участники обсуждения выдают любые отклонения от привычных им практик. Всё это довольно близко к подходу, в рамках которого UML пытаются рассматривать и критиковать не как язык, а как метод (назовём это так).

Пролетая мимо, интересно заметить, что в подразделе форума, посвящённому UML-нотации, размещена тема, в которой по большей части обсуждаются не ошибки с точки зрения нотации, а ошибки use-case моделирования (назовём это так), за которые некоторые участники обсуждения выдают любые отклонения от привычных им практик. Всё это довольно близко к подходу, в рамках которого UML пытаются рассматривать и критиковать не как язык, а как метод (назовём это так).

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