Студенты выполнили работу над ошибками. Где-то воспользовались рекомендациями Сергея. И вот что получилось:

Учитель:
Выставить оценки ученику (за урок, за четверть, за год), изменить оценки, удалить оценки, записать ДЗ, изменить ДЗ, удалить ДЗ, отметить отсутствующих, записать примечания, изменить примечания, удалить примечания

Админ:
Создать учетную запись с данными о пользователе (ученик, учитель), изменить данные (ФИО, дата рождения, адрес и т.д.) пользователя, удалить данные пользователя, занести расписание (за год), изменить расписание, удалить расписание, занести список учеников в журнал, изменить список учеников, удалить список, запросить отчет рейтинга оценок N класса, запросить отчет о недельной нагрузке учителей в часах, запросить отчет о недельной загрузке учеников N класса в часах

Ученик/родитель: просмотреть расписание, просмотреть оценки, просмотреть ДЗ, просмотреть посещаемость, просмотреть примечания

Что скажет почтенная публика?

Что скажет почтенная публика?

А все действия типа выставить/изменить/удалить они показывают как CRUD или каждое отдельным ВИ?

А все действия типа выставить/изменить/удалить они показывают как CRUD или каждое отдельным ВИ?

На самом деле никаких явных рекомендаций по использованию/не использованию CRUD я не давал. Предполагается по правилам игры, что знания у них есть (3 и 4 курсы), и сейчас они эти знания должны применять.

В текущий момент, модель никак пока не изменена. Верифицируется список ВИ для планирования. К сожалению у меня нет реального использования CRUD ВИ (ну кроме учебных проектов), так что буду рад Вашим советам.

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

А как можно дублировать поведение на диаграмме ВИ?

Дублировать можно программный код. Это и есть самый низкий уровень, о котором я говорю. Правда, мне не приходилось использовать диаграммы ВИ на уровне описания фрагментов кода, но я слышал, что есть такие подходы.

Можно найти уровень чуть повыше - дублирование механизмов реализации. Например, в АБС можно описать бухгалтерскую проводку четырьмя разными способами (что особенно смешно, так получилось в погоне за универсальностью каждого из четырёх механизмов). Это четыре разных ВИ. Тогда в ВИ более высокого уровня (настроить банковскую операцию) имеет смысл сделать include для того способа, который является предпочтительным.


Но вернёмся к банкомату. Если мы описываем цели пользователей по отношению к банкомату, то зачем нам избегать дублирования? Пользователю всё равно, как будет реализовано достижение этих целей. А целей «ввести ПИН» или «подтвердить операцию» по отношению к банкомату у него нет.

Если же мы опускаемся на уровень ниже и начинаем складывать наши процедуры из однотипных кубиков (то есть переходим к проектированию), то зачем нам здесь роли пользователей? Или, другими словами, зачем нам диаграмма ВИ? Здесь лучше использовать старые добрые блок-схемы.

Все примеры диаграмм ВИ с использованием include и extend, которые я видел, рисовались со смешением этих двух уровней, поэтому они только затрудняли понимание.

А как можно дублировать поведение на диаграмме ВИ?

Дублирование может быть допущено в спецификации ВИ в части описания общих для нескольких ВИ фрагментов диалога эктора и системы.

Но вернёмся к банкомату. Если мы описываем цели пользователей по отношению к банкомату, то зачем нам избегать дублирования? Пользователю всё равно, как будет реализовано достижение этих целей. А целей «ввести ПИН» или «подтвердить операцию» по отношению к банкомату у него нет.

Целей «ввести ПИН» или «подтвердить операцию» по отношению к банкомату у него нет, но есть такие фрагменты поведения в рамках нескольких ВИ. Если повторяющийся фрагмент большой и сложный, то я предпочитаю вынести его в обобщающий ВИ чтобы впоследствии было легче поддерживать. Вы бы не выделяли общее поведение в обобщающем ВИ? Как бы тогда решилалась проблема поддержки требований? При их изменении вы бы меняли сразу несколько спецификаций ВИ?
Описание обсуждаемого кейса и решения можно найти по тексту "Использовать банкомат":
http://www.uml2.ru/index.php?option=com_content&view=article&id=421

Все примеры диаграмм ВИ с использованием include и extend, которые я видел, рисовались со смешением этих двух уровней, поэтому они только затрудняли понимание.

Может дело в правильности использования include и extend и просто нужно рисовать без смешения?

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

Выделил бы, конечно. Но спецификация ВИ - это же не диаграмма ВИ.

Если вы используете для разработки и поддержки требований систему, в которой диаграмма ВИ жёстко связана со сценариями (каждое "яйцо" является ссылкой на сценарий ВИ), то от этих отношений, наверное, никуда не деться. Но в этом случае диаграмма предназначена уже не столько для людей, сколько для роботов. Это такой механизм поддержки целостности модели требований, приближенный скорее к визуальному программированию.

Что касается статьи по ссылке, то ВИ "Использовать банкомат" и "Выполнить одну транзакцию" кажутся мне искусственными. Я не вижу для них практического применения ни со стороны целей пользователя, ни со стороны программной архитектуры.

В статье сказано

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

Я не понимаю, зачем это вообще нужно выражать графически на диаграмме, которая не описывает поведения. Для этого есть другие диаграммы.

Но должен оговориться: если я чего-то не понимаю, это не означает, что это что-то неправильно. Если у кого-то include и extend эффективно используются, то это прекрасно.

В данном случае Эд говорит о подготовке студентов. Они, скорее всего, ещё не понимают целей, для которых может использоваться обобщение, и поэтому у них будут трудности с пониманием include и extend (и есть, судя по вопросам в этом форуме).

В данном случае Эд говорит о подготовке студентов. Они, скорее всего, ещё не понимают целей, для которых может использоваться обобщение, и поэтому у них будут трудности с пониманием include и extend (и есть, судя по вопросам в этом форуме).

Гриша абсолютно верно подметил. Потому, друзья, про банкомат предлагаю тему не продолжать либо в контексте "характерная ошибка", т.е. ее описание и что не так и как избегать.

На самом деле никаких явных рекомендаций по использованию/не использованию CRUD я не давал. Предполагается по правилам игры, что знания у них есть (3 и 4 курсы), и сейчас они эти знания должны применять.

В текущий момент, модель никак пока не изменена. Верифицируется список ВИ для планирования. К сожалению у меня нет реального использования CRUD ВИ (ну кроме учебных проектов), так что буду рад Вашим советам.

Могу ошибиться, но тут возможно студенты пошли по пути "чем больше - тем лучше", наделать кучу ВИ в надежде что какие-то окажутся верными.

Лично я, компоновал бы CRUD действия в один ВИ по типу "управление пользователями", "управление расписанием" - если эти ВИ доступны/ не доступны всем акторам одинаково.
Если же, например, кому-то доступно выставление оценок, а кому-то только просмотр, то разделял бы в разные ВИ

Но должен оговориться: если я чего-то не понимаю, это не означает, что это что-то неправильно. Если у кого-то include и extend эффективно используются, то это прекрасно.

Насколько я понимаю, то тот же Include выгодно использовать для того, чтобы не потерять на ДВИ функционал, который хоть и не является полезным, но тем не менее без него полезные ВИ теряют смысл.
Вот пример с тем же банкоматом:


PS: Простите что вернулся к теме банкомата:)

Лично я, компоновал бы CRUD действия в один ВИ по типу "управление пользователями", "управление расписанием" - если эти ВИ доступны/ не доступны всем акторам одинаково.
Если же, например, кому-то доступно выставление оценок, а кому-то только просмотр, то разделял бы в разные ВИ

Ага, спасибо.

А как на Ваш взгляд (ну технически) будет выглядеть ВИ "управление расписанием", например?

Мне кажется, корень разногласий в разных целях применения ДВИ. Давайте попробуем сформулировать эти цели: для чего вы разрабатываете диаграммы ВИ?

Начну с себя. Я использую ДВИ
- для выявления и описания целей пользователей по отношению к разрабатываемой системе;
- для визуализации ролей пользователей и различий между ними.

- для выявления и описания целей пользователей по отношению к разрабатываемой системе;
- для визуализации ролей пользователей и различий между ними.

Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?

От себя добавлю:
- как иллюстрированное содержание
- как инструмент планирования работы

Ага, спасибо.

А как на Ваш взгляд (ну технически) будет выглядеть ВИ "управление расписанием", например?

Смотря что подразумевать под "технически"
Помимо описания основных и альтернативных потоков ВИ, я бы еще добавил прототип интерфейса работы с ВИ. Т.к. ценю наглядность, а прототип как раз и указывает на очевидно необходимый функционал.

Например как-то так:

Смотря что подразумевать под "технически"
Помимо описания основных и альтернативных потоков ВИ, я бы еще добавил прототип интерфейса работы с ВИ. Т.к. ценю наглядность, а прототип как раз и указывает на очевидно необходимый функционал.

Спасибо. Под технически я имел в виду, как формируется спецификация при этом. Ведь по сути нет такого ВИ как Управление расписанием: скорее есть набор действий, имеющий  некоторые общие черты: создать расписание, изменить расписание, скопировать расписание. Как на Ваш практический взгляд это выглядит?

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

Спасибо. Под технически я имел в виду, как формируется спецификация при этом. Ведь по сути нет такого ВИ как Управление расписанием: скорее есть набор действий, имеющий  некоторые общие черты: создать расписание, изменить расписание, скопировать расписание. Как на Ваш практический взгляд это выглядит?

Ну,  если бы надо было описать такое ВИ в спецификации,  это выглядело бы примерно так:

1. Требуется реализовать функционал управления расписанием занятий.
  1.1 Требования к функционалу менеджера расписаний.
    1.1.1 Контроль прав доступа к функционалу менеджера расписаний.
    1.1.2 Макет менеджера расписаний.
  1.2. Требования к созданию расписания.
    1.2.1 Правила заполнения формы расписания.
    1.2.2 Контроль ввода значений в форме расписания.
    1.2.3 Сохранение нового расписания.
  1.3. Требования к редактированию расписания.
    1.2.1 Правила редактирования формы расписания.
    1.2.2 Контроль ввода значений в форме расписания.
  1.4 Требования к удалению расписания.
  1.5 Требования к печати расписания.
    1.5.1 Макет печатной формы расписания.
  1.6 Требования к логированию добавления/изменения расписания.
  1.7 Требования к оповещению участников нового/измененного расписания.

Описание пошаговое потоков делать не буду, долго:)