Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 26 Сентября 2014, 10:31:13
-
Друзья,
мне нужна ваша помощь. Обучая своих студентов, я обычно предостерегаю их от использования включений и расширений. особенно на начальных стадиях описания предметной области. К сожалению студенты затем проходят подготовку у другого преподавателя, где акценты построения сильно смещаются.
Вполне возможно, что на самом деле заблуждаюсь я сам. Потому прошу вас указать, какие вы видите ошибки на вложенной диаграмме и почему это ошибке. Я надеюсь, получить материла для формирования некого методического материала, который поможет избегать ошибок в будущем (если они конечно есть).
Спасибо
-
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-матрицы не помощник.
-
Как бы вы ростроили модель чтобы не использовать включение и расширение, но избежать дублирования одинакового поведения?
Если дублирование большое, то можно объединить несколько юскейсов в один, а варианты описывать расширениями. Можно описать блок вариаций.
В конце концов дублирование отдельных функций как шагов в разных юскейсах не является большой проблемой, это одно из свойств юскейсов как метода.
-
Студенты выполнили работу над ошибками. Где-то воспользовались рекомендациями Сергея. И вот что получилось:
Учитель:
Выставить оценки ученику (за урок, за четверть, за год), изменить оценки, удалить оценки, записать ДЗ, изменить ДЗ, удалить ДЗ, отметить отсутствующих, записать примечания, изменить примечания, удалить примечания
Админ:
Создать учетную запись с данными о пользователе (ученик, учитель), изменить данные (ФИО, дата рождения, адрес и т.д.) пользователя, удалить данные пользователя, занести расписание (за год), изменить расписание, удалить расписание, занести список учеников в журнал, изменить список учеников, удалить список, запросить отчет рейтинга оценок 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 выгодно использовать для того, чтобы не потерять на ДВИ функционал, который хоть и не является полезным, но тем не менее без него полезные ВИ теряют смысл.
Вот пример с тем же банкоматом:
(http://www.uml-diagrams.org/use-case-diagrams/use-case-include.png)
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 Требования к оповещению участников нового/измененного расписания.
Описание пошаговое потоков делать не буду, долго:)
-
Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?
Ты имеешь в виду описанные сценарии?
Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.) И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем. Я не знаю истории этой диаграммы - возможно, изначально она использовалась именно как "карта сценариев", но возможности её применения гораздо шире.
Во-вторых, если что-то действительно нужно синхронизировать, то это должно делаться автоматически. В этом случае ДВИ может генерироваться из набора сценариев подобно тому, как диаграммы классов генерируются из исходного кода. Но это совсем другая цель использования ДВИ, и если ты посмотришь на мой список, то увидишь, что там этой цели нет.
-
Ну, если бы надо было описать такое ВИ в спецификации, это выглядело бы примерно так:
Красиво, спасибо. Но, видимо, мне не удается донести свою мысль.
Каждый ВИ обладает определенной целостностью и имеет общие предусловия и постусловия.
Скажем, ясно что изменение расписания невозможно, пока не будет создано само это расписание. Как это все увязывается в единой спецификации варианта использования?
-
Каждый ВИ обладает определенной целостностью и имеет общие предусловия и постусловия.
Скажем, ясно что изменение расписания невозможно, пока не будет создано само это расписание. Как это все увязывается в единой спецификации варианта использования?
Я кажется понимаю куда вы клоните!
По определению, ВИ - это ровно один прецедент использования системы. Т.е. или создание или редактирование или удаление.
При такой декомпозиции очень просто определить основной поток прецедента и альтернативные.
Например, основной поток - удалить расписание. Если расписаний нет - это уже альтернативный поток.
В случае же такого сбора три в одном, в рамках описания ВИ затруднительно выделить основной поток, т.к. он должен вести актора к выполнению цели. Но мы не знаем какую цель преследует актор на старте сценария.
По этому, для одного ВИ "управление расписанием", я бы создал столько сценариев, сколько целей может достичь актор этим ВИ.
Это вы спрашивали?:)
-
Это вы спрашивали?:)
Ага :) При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других. Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.
-
Ага :) При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других.
Конечно.
Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.
У меня с практикой тоже не фонтан. Ни заказчики ни разработчики UML не знают, так что я рисую и пишу не по нотации, а чтобы людям понятно было:)
-
- случайный дубль
-
Если вы используете для разработки и поддержки требований систему, в которой диаграмма ВИ жёстко связана со сценариями (каждое "яйцо" является ссылкой на сценарий ВИ), то от этих отношений, наверное, никуда не деться. Но в этом случае диаграмма предназначена уже не столько для людей, сколько для роботов. Это такой механизм поддержки целостности модели требований, приближенный скорее к визуальному программированию.
А если вы не используете никакой системы с поддержкой трассировок? По-моему связи 1-к-1 для людей тоже удобнее, чем многие-ко-многим. Особенно если, к примеру разработчику, нужно будет потом разбираться какая часть спецификации к какому ВИ относится.
Что касается статьи по ссылке, то ВИ "Использовать банкомат" и "Выполнить одну транзакцию" кажутся мне искусственными.
Так и есть. Наследование (генерализация) часто делается именно от абстрактного (искуственного) ВИ. Соответственно абстрактный ВИ выражает абстрактную цель и может снижать сложность понимания модели.
Я не вижу для них практического применения ни со стороны целей пользователя, ни со стороны программной архитектуры.
Как же? Полезность есть как минимум с точки зрения:
1. Отсутствия необходимости изменения сценариев в нескольких местах с описанием общего поведения.
2. Снижения вероятности ошибок при таких изменениях.
3. Снижения вероятности многократной разработки одного и того же функционала.
4. Подсказки разработчикам в части применения нужных абстракций в коде.
5. Устранения необходимости многократного тестирования одного и того же функционала.
Я не понимаю, зачем это вообще нужно выражать графически на диаграмме, которая не описывает поведения. Для этого есть другие диаграммы.
Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.
Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)
В данном случае Эд говорит о подготовке студентов. Они, скорее всего, ещё не понимают целей, для которых может использоваться обобщение, и поэтому у них будут трудности с пониманием include и extend (и есть, судя по вопросам в этом форуме).
Полностью согласен!
-
Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.)
А зачем выявлять требования, но не описывать их? Agile?:).
И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем.
Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.
-
Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)
На костер его, богохульника!
Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.
По стандарту (если я не заблуждаюсь) все это можно считать разным способ реализации варианта использования
Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда (http://dit.isuct.ru/Publish_RUP/index.htm#core.base_rup/guidances/guidelines/use-case_model_CC121CF4.html)
-
Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.
Вариант использования как сценарий, безусловно, описывает поведение.
Диаграмма вариантов использования сама по себе поведение не описывает (хоть UML и относит её к классу bihavior diagram).
Графическое изображение варианта использования (как сценария) - imho это другие диаграммы (activity, sequence, communication в терминологии uml).
А зачем выявлять требования, но не описывать их? Agile?:).
Выявлять, но не описывать в виде сценариев. Сценарии ведь не являются единственно возможным вариантом описания требований.
Agile - да, диаграмма ВИ может быть источником user stories.
-
Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда (http://dit.isuct.ru/Publish_RUP/index.htm#core.base_rup/guidances/guidelines/use-case_model_CC121CF4.html)
Эдуард, спасибо за ссылку.
-
А зачем выявлять требования, но не описывать их? Agile?:).
Нет. Прокурор. :)
-
может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html
-
может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html
Вот это вообще для меня новость.
(http://www.sparxsystems.com/images/screenshots/uml2_tutorial/uc07.GIF)
-
Вот студенты выполнили работу над ошибками и сформировали немного иное представление.
Буду рад замечаниям и предложениям.
-
Если не считать того что я уже писал про компоновку CRUD (благодаря которой можно было бы уместить всех акторов на одной диаграмме:)), могу заметить следующее:
1.Выйти/войти - вообще не ВИ.
2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а не одинаковые, но это к самой диаграмме не относится.
3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?
4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.
-
Вот студенты выполнили работу над ошибками и сформировали немного иное представление.
Буду рад замечаниям и предложениям.
Мне нравится, из этих диаграмм уже хорошо видны различия ролей и цели пользователей.
Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"
-
1.Выйти/войти - вообще не ВИ.
Согласен, я тоже сказал, что это не может быть ВИ. Но в таком случае где следует описать процедуру входа в систему, возможность забыть пароль и потребовать его восстановления?
2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а не одинаковые, но это к самой диаграмме не относится.
Я думаю это просто ошибка
3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?
Просто выделенная связь - дефект копирования
4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.
Там Записать примечание, а что не понятно, кому примечание пишется?
-
Мне нравится, из этих диаграмм уже хорошо видны различия ролей и цели пользователей.
Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"
Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?
-
Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?
Я обычно просто рисую одно яйцо вместо четырёх и пишу что-то вроде "CRUD: оценка ученика". Примерно как здесь предлагается:
http://www.ijsce.org/attachments/File/v2i2/B0535042212.pdf (http://www.ijsce.org/attachments/File/v2i2/B0535042212.pdf)
Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.
-
Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.
Спасибо, Гриша. Никак не мог понять, почему ты говоришь о ДВИ при специфицировании ВИ. Я понимаю, что на диаграмме 4 яйца сворачиваются в 1. Я интересуюсь, как в этом случае формируется текстовая (другой я все равно не знаю) спецификация
-
Согласен, я тоже сказал, что это не может быть ВИ. Но в таком случае где следует описать процедуру входа в систему, возможность забыть пароль и потребовать его восстановления?
В разделе требований безопасности. Система состоит ведь не только из ВИ и функциональных требований.
Здесь я согласен с Григорием. ДВИ это хорошо и полезно, но самих по себе ВИ, и тех рамок их описания, которые предлагает нотация, недостаточно для полноценного описания системы.
По этому, я считаю, и не надо пытаться в ВИ впихивать того чего там быть не должно.
Там Записать примечание, а что не понятно, кому примечание пишется?
Да, именно. Т.е. если записать примечание к оценке, то я бы поместил его в CRUD оценок. Если примечание к ДЗ - в CRUD к ДЗ.
Сразу схема становится проще к восприятию.
PS: Но если бы мне надо было впихнуть в ВИ и вход с авторизацией, я бы изобразил его вот так (рис. во вложении). Но все же считаю что так делать не стоит все равно:)
-
Коллеги,
если Вам интересно осуществлять экспертизу студенческих ошибок, то предлагаю поупражняться вот на этом тексте. Буду признателен за ваши ценные комментарии и конструктивные предложения.
Имя: Добавить нового пользователя
ID: 1
Краткое описание: ВИ описывает создание нового пользователя
Действующие лица: Администратор
Предусловие:
1.Администратор авторизован в системе.
2.У администратора должны быть данные о новом пользователя для создания учетной записи.
Постусловие: Пользователь зарегистрирован в системе “Электронная школа”
1.0 Основной поток:
1.Администратор делает запрос на регистрацию нового пользователя.
2.Система предоставляет возможность для выбора роли пользователя
3.Администратор выбирает роль пользователя
4.Система предоставляет форму для заполнения личных данных о пользователе в зависимости от роли
5.Администратор заполняет предоставленную системой форму и сохраняет
6.Система сохраняет пользователя в базе данных
7.Система выводит сообщение об успешном сохранении данных
8.Система предлагает администратору добавить нового пользователя
Альтернативные потоки:
1.1Данный пользователь уже существует в системе (ответвление шага 5)
1.Система выдает сообщение, о том, что данный пользователь уже зарегистрирован в системе.
2.Возврат к пункту 2 основного потока.
1.2Не все обязательные поля заполнены (ответвление шага 5)
1.Система выдает сообщение, о том, что пропущено поле для заполнения
2.Возврат к пункту 4 основного потока.
Ограничения:
1.Пароль должен состоять из набора латинских букв и цифр, должен быть не менее 6 символов символов.
2.Логин должен содержать не меньше 6 цифр.
3.ФИО должен состоять из русских букв, начиная с заглавной буквы.
4.При заполнении поля “Класс” выбирается число от 1 до 11 включительно и без пробела ставится буква русского алфавита: А, Б, В ,Г ,Д.
5.Адрес должен состоять из букв русского алфавита и цифр и не должен превышать 50 символов.
6.Дата рождения ставится в соответствии с предложенным календарем.
7.Email представляет собой стандартную форму электронного почтового ящика.
8.Администратор может выбрать только одну из ролей, либо ученик, либо учитель.
9.Мобильный телефон должен состоять из 11 цифр, начиная с 8
-
Давай по шагам юскейса:
1. Чтобы Администратор мог сделать запрос, система должна сначала предоставить ему такую возможность. Хотя бы в виде курсора командной строки. Есть скрытый вариант типа горячих клавиш, но тут, как я понимаю, не тот случай. Не хватает этого шага.
2. Лучше разделить на 2-3 операции опять же (в одном шаге), например, «показывает список доступных ролей и предлагает выбрать одну из них». Если список ролей уже известен (и будет зашит в систему), лучше сразу написать его здесь.
4. Тут нужно указать состав полей или сослаться на структуру из Словаря данных. Юскейс может использоваться для проектирования и разработки без предварительного создания списка ФТ, поэтому в нём должно быть достаточно информации для проектирования.
5. Администратор не может ничего сохранять. Сохраняет система, пользователь только предоставляет данные и команды. См. заметку Сергея Нужненко: http://boatmanshome.ru/wiki/wacko/?page=Zametki/StopTheMagic&v=1c9h
6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.
8. Лучше этот шаг сделать шагом 0, а на 8-м шаге поставить «Сценарий продолжается с шага 0». Но таким образом возникнет бесконечный цикл, который придётся разрывать исключением 1а.
В целом из моей практики в конце не хватает шагов по оповещению пользователя об активации его аккаунта (если регистрация пользователя означает это) и не продумана логика того, что происходит после добавления.
Из текущего сценария получается, что пользователь видит заполненную форму и предложение добавить другого пользователя. Это странно.
Если Админ чаще вводит несколько пользователей подряд, то лучше указать, что система показывает форму нового пользователя с последней ролью и возможностью её сменить.
Если Админ чаще вводит по одному пользователю, то логично, чтобы сценарий показывал список всех пользователей с выделением только что добавленного или предлагал какие-то другие шаги, которые обычно делает Админ после регистрации (например, настройка квот, включение в группы, что-то ещё).
-
По расширениям:
Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.
Расширение 1.1. Условие входа в расширение — это условие-событие, которое ВЗАИМОИСКЛЮЧАЩЕЕ для событий того шага основного потока, в котором оно возникло. В данном случае события шага 5 основного потока и условие входа в расширение 1.1. вполне совместимы. Всё дело в пропущенном шаге контроля вводимых данных.
Обработка расширения — из условия входа неясно, каково всё-таки правило совпадения пользователей — должны совпадать имейлы, или имейлы+ФИО или ещё как-то? Если речь только об имейле, то очень глупо, если человек ошибся в одной букве имейла так, что это привело к совпадению с уже существующим пользователем, терять введённые им данные и просить заполнить всё заново.
Например, у вас уже есть smirnovaa@mstu.ru и вы пытаетесь добавить ещё одного однофамильца, у которого первая буква имени — A. Система должна подсказывать, что делать, а не тупо ругаться и сбрасывать форму.
-
Денис, спасибо за подробные комментарии и анализ предложенного описания. Я для студентов, естественно, сделал подобный анализ и уточнения по шагам. Правда он у меня получился чуточку отличным, в некоторых деталях.
1. Предусловие - оно на мой взгляд должно определять в каком положении начинается ВИ. В своем варианте я предложил студентам определить, что на экране открыт список имеющихся пользователей (можно определить и структуру списка и правила отображения сразу - например 20 пользователей, добавленных последними)
Ты пишешь
6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.
может ты и прав, но я помню рекомендации Коуберна. Он пишет, что проверка - это внутреннее поведение системы, поэтому мы прячем проверку за реакции - если она успешная, то переход к другому шагу, если нет - срабатывает исключение (альтернативный поток). Я понимаю, что некоторые проверки целесообразно делать на уровне логики представления, а не переносить их на уровень бизнеслогики. Как правильно это должно оформляться, является ли этот момент компетенцией аналитика?
Ты пишешь:
Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.
Не совсем понял твою схему -(кмк - как мне кажется?)
-
... я помню рекомендации Коуберна. Он пишет, что проверка - это внутреннее поведение системы, поэтому мы прячем проверку за реакции - если она успешная, то переход к другому шагу, если нет - срабатывает исключение (альтернативный поток).
Это где он о таком пишет?
-
Я понимаю, что некоторые проверки целесообразно делать на уровне логики представления, а не переносить их на уровень бизнеслогики. Как правильно это должно оформляться, является ли этот момент компетенцией аналитика?
В юскейсах нет уровней представления и бизнес-логики, есть чёрный ящик или серый. И ещё я использую юскейсы для выявления ФТ.
Описание системы даже на уровне чёрного ящика не означает, что мы совсем не описываем, что делает система внутри, а только поведение интерфейса (это частая ошибка новичков). Если система как-то сообщает пользователю об ошибках, значит, в ментальную модель пользователя входит и понятие «проверка», которую может выполнить система. Тут нет ничего страшного.
Да, эту работу может делать аналитик, тут не нужны никакие архитектурные компетенции.
-
Это где он о таком пишет?
Я имел в виду, именно это
-
Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».
Я своим студентам рекомендую писать «Система убеждается, что ... и сообщает …», т.к. вижу 2 разных операции, также, как, например, в случае сохранения.
-
Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».
Я своим студентам рекомендую писать «Система убеждается, что ... и сообщает …», т.к. вижу 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 пытаются рассматривать и критиковать не как язык, а как метод (назовём это так).
Ну, начальный вопрос был именно об ошибках использования нотации, но как всегда где-то что-то пошло не туда.