Друзья,

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

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

Спасибо

include и extend - безусловное зло, никогда их не использую, и предпочитаю даже не читать диаграммы, на которых они используются.

В данном случае UC "Оформить журнал" просто не нужен. Ощущение такое, что вместо диаграммы ВИ автор изобразил структуру меню.

include и extend - безусловное зло, никогда их не использую, и предпочитаю даже не читать диаграммы, на которых они используются.

Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

В данном случае UC "Оформить журнал" просто не нужен. Ощущение такое, что вместо диаграммы ВИ автор изобразил структуру меню.

Гриша, я тоже предположил, что выполнена некоторая декомпозиция. (Правда у Коуберна есть такой пример http://www.uml2.ru/faq/use-cases/421- (см рисунок 2).
Можешь ли ты из свое опыта сказать в чем тут будет проблема? И Следует ли просто удалить ВИ Оформить журнал, а то что выполнено как include просто превратить в самостоятельные ВИ.
Тут на мой взгляд достаточным условием будет то, что у учителя нет цели Оформить журнал.

Еще тогда предложу к обсуждению такой экземпляр

По первой диаграмме:

У юксейса «Выставить оценки в журнал» непонятны рамки — ученику? классу? всему потоку? За задание? За день? За неделю? За четверть? За год? Уточнение «в журнал» мне кажется лишним.

С точки зрения закона сохранения информационных потоков нет юскейсов, которые бы показывали использование занесённых данных.

У юксейса «Выставить оценки в журнал» непонятны рамки — ученику? классу? всему потоку? За задание? За день? За неделю? За четверть? За год? Уточнение «в журнал» мне кажется лишним.

Да, конечно, ты прав. Ясно почему возникло именно такое наименование. А как бы ты сформулировал: оценка ставится ученику за выполнение какой-то учебной активности: домашнего задания, ответа на уроке, контрольная, что там еще бывает?

С точки зрения закона сохранения информационных потоков нет юскейсов, которые бы показывали использование занесённых данных.

Ну, возможно, это Сформировать отчет? Однако ты скорее имеешь в виду, что-то типа Просмотреть успеваемость ученика/класса?

С точки зрения закона сохранения информационных потоков

Денис, а не можешь развить эту мысль. Что это за закон? Есть ли какие-то ссылки на него? Я слышал о законе сохранения информации, но и то не в рамках нашей специальности.

Еще тогда предложу к обсуждению такой экземпляр

Если роли Ученик и Родитель ничем не различаются, то зачем делать из одной роли три?
(На самом деле они, наверное, различаются, и диаграмма нужна как раз для того, чтобы показать это различие).

И снова "посмотреть профиль ученика" imho совершенно ненужный юзкейс. Да ещё сбивающий с толку (обычно под профилем понимаются настройки).

Вообще, здесь, конечно, совершена типичная для большинства диаграмм ошибка: смешиваются кони, люди сущности из разных слоёв абстракции. Бытовые роли и роли пользователей. Варианты использования, структура меню и элементы программной архитектуры. В результате получается каша: непонятно, какой уровень представлен на диаграмме, и когда нужно остановиться при её разработке.

Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

Нет, это же было только вступление.

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

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

Да, конечно, ты прав. Ясно почему возникло именно такое наименование. А как бы ты сформулировал: оценка ставится ученику за выполнение какой-то учебной активности: домашнего задания, ответа на уроке, контрольная, что там еще бывает?

Слушай, ну у тебя же юскейсы должны не из воздуха браться, а из описания предметной области, процесса и интересов. В зависимости от контекста, сценария будет актуально «Оценить работу класса» или «Оценить работу ученика». Ещё может оказаться, что эти оценки устроены как процедуры очень по-разному для разных типов и потому юскейсы лучше разделить.

Ну, возможно, это Сформировать отчет? Однако ты скорее имеешь в виду, что-то типа Просмотреть успеваемость ученика/класса?

Да. Или уточнить название отчёта, если он готовится в этой, а изучается в другой системе или на бумаге.

Денис, а не можешь развить эту мысль. Что это за закон? Есть ли какие-то ссылки на него? Я слышал о законе сохранения информации, но и то не в рамках нашей специальности.

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

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

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

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

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

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

Денис, мне тоже нравится такой подход. Я обычно немного расширяю его с помощью CRUDL и задаю себе несколько вопросов:
C - Как информация должна попасть в систему чтобы её можно было использовать?
R - Раз уж мы вводим информацию в систему, значит она кому-то нужна и её будут использовать?
U - Действительно ли информация один раз вводится в систему и никогда больше не изменяется?
D - Нужно ли будет удалять введенную ранее информацию? Для чего?
L - Как введенная ранее информационная сущность будет выбираться среди других для просмотра, изменения или удаления? Будет ли таких сущностей настолько много, что нужна будет фильтрация/поиск в списке?

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

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

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

Денис, мне тоже нравится такой подход. Я обычно немного расширяю его с помощью CRUDL и задаю себе несколько вопросов:
C - Как информация должна попасть в систему чтобы её можно было использовать?
R - Раз уж мы вводим информацию в систему, значит она кому-то нужна и её будут использовать?
U - Действительно ли информация один раз вводится в систему и никогда больше не изменяется?
D - Нужно ли будет удалять введенную ранее информацию? Для чего?
L - Как введенная ранее информационная сущность будет выбираться среди других для просмотра, изменения или удаления? Будет ли таких сущностей настолько много, что нужна будет фильтрация/поиск в списке?

Проверка полноты функциональной модели про CRUDLS-матрице — это уже другой уровень контроля, более глубокий. Сначала бы разобраться с тем, что «замечательно входит и выходит» Тем более что входить могут одни структуры, а выходить совсем другие, и тут нам CRUDLS-матрицы не помощник.

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

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

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