Характерные ошибки use case диаграммы(Прочитано 35710 раз)
Друзья,

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

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

Спасибо



Re: Характерные ошибки use case диаграммы Ответ #1 : 26 Сентября 2014, 14:58:01
include и extend - безусловное зло, никогда их не использую, и предпочитаю даже не читать диаграммы, на которых они используются.

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Характерные ошибки use case диаграммы Ответ #2 : 26 Сентября 2014, 15:14:56
include и extend - безусловное зло, никогда их не использую, и предпочитаю даже не читать диаграммы, на которых они используются.
Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

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



Re: Характерные ошибки use case диаграммы Ответ #3 : 26 Сентября 2014, 16:25:36
Еще тогда предложу к обсуждению такой экземпляр



Re: Характерные ошибки use case диаграммы Ответ #4 : 26 Сентября 2014, 20:07:12
По первой диаграмме:

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

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



Re: Характерные ошибки use case диаграммы Ответ #5 : 26 Сентября 2014, 20:58:43
У юксейса «Выставить оценки в журнал» непонятны рамки — ученику? классу? всему потоку? За задание? За день? За неделю? За четверть? За год? Уточнение «в журнал» мне кажется лишним.
Да, конечно, ты прав. Ясно почему возникло именно такое наименование. А как бы ты сформулировал: оценка ставится ученику за выполнение какой-то учебной активности: домашнего задания, ответа на уроке, контрольная, что там еще бывает?
С точки зрения закона сохранения информационных потоков нет юскейсов, которые бы показывали использование занесённых данных.
Ну, возможно, это Сформировать отчет? Однако ты скорее имеешь в виду, что-то типа Просмотреть успеваемость ученика/класса?



Re: Характерные ошибки use case диаграммы Ответ #6 : 26 Сентября 2014, 21:03:49
С точки зрения закона сохранения информационных потоков
Денис, а не можешь развить эту мысль. Что это за закон? Есть ли какие-то ссылки на него? Я слышал о законе сохранения информации, но и то не в рамках нашей специальности.



Re: Характерные ошибки use case диаграммы Ответ #7 : 26 Сентября 2014, 23:43:48
Еще тогда предложу к обсуждению такой экземпляр

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

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

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

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

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

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

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Характерные ошибки use case диаграммы Ответ #8 : 26 Сентября 2014, 23:55:08
Да, конечно, ты прав. Ясно почему возникло именно такое наименование. А как бы ты сформулировал: оценка ставится ученику за выполнение какой-то учебной активности: домашнего задания, ответа на уроке, контрольная, что там еще бывает?
Слушай, ну у тебя же юскейсы должны не из воздуха браться, а из описания предметной области, процесса и интересов. В зависимости от контекста, сценария будет актуально «Оценить работу класса» или «Оценить работу ученика». Ещё может оказаться, что эти оценки устроены как процедуры очень по-разному для разных типов и потому юскейсы лучше разделить.



Re: Характерные ошибки use case диаграммы Ответ #9 : 26 Сентября 2014, 23:56:22
Ну, возможно, это Сформировать отчет? Однако ты скорее имеешь в виду, что-то типа Просмотреть успеваемость ученика/класса?
Да. Или уточнить название отчёта, если он готовится в этой, а изучается в другой системе или на бумаге.



Re: Характерные ошибки use case диаграммы Ответ #10 : 26 Сентября 2014, 23:58:41
Денис, а не можешь развить эту мысль. Что это за закон? Есть ли какие-то ссылки на него? Я слышал о законе сохранения информации, но и то не в рамках нашей специальности.
Ну это мой неформальный закон, который я использую при обучении разработке контекстной диаграммы и диаграммы юскейсов.

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

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



Re: Характерные ошибки use case диаграммы Ответ #11 : 29 Сентября 2014, 08:43:02
Ну это мой неформальный закон, который я использую при обучении разработке контекстной диаграммы и диаграммы юскейсов.

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

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



Re: Характерные ошибки use case диаграммы Ответ #12 : 29 Сентября 2014, 08:50:22
Я могу признать возможную пользу отношений include и extend разве что на довольно низком уровне проектирования - когда на диаграмме ВИ показываются не цели пользователей, а сценарии из уже продуманного множества, подготовленные к реализации или отчасти реализованные. Например, когда разрабатываемые ВИ должны надстраиваться над уже реализованными частями системы (хорошо это представляю, например, применительно к нашей АБС).

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



Re: Характерные ошибки use case диаграммы Ответ #13 : 29 Сентября 2014, 12:12:55
Денис, мне тоже нравится такой подход. Я обычно немного расширяю его с помощью CRUDL и задаю себе несколько вопросов:
C - Как информация должна попасть в систему чтобы её можно было использовать?
R - Раз уж мы вводим информацию в систему, значит она кому-то нужна и её будут использовать?
U - Действительно ли информация один раз вводится в систему и никогда больше не изменяется?
D - Нужно ли будет удалять введенную ранее информацию? Для чего?
L - Как введенная ранее информационная сущность будет выбираться среди других для просмотра, изменения или удаления? Будет ли таких сущностей настолько много, что нужна будет фильтрация/поиск в списке?
Проверка полноты функциональной модели про CRUDLS-матрице — это уже другой уровень контроля, более глубокий. Сначала бы разобраться с тем, что «замечательно входит и выходит» :) Тем более что входить могут одни структуры, а выходить совсем другие, и тут нам CRUDLS-матрицы не помощник.



Re: Характерные ошибки use case диаграммы Ответ #14 : 29 Сентября 2014, 12:15:51
Как бы вы ростроили модель чтобы не использовать включение и расширение, но избежать дублирования одинакового поведения?
Если дублирование большое, то можно объединить несколько юскейсов в один, а варианты описывать расширениями. Можно описать блок вариаций.

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19