Автор Тема: Моделирование требований пользователей в MS VisualStudio  (Прочитано 2729 раз)

bas

  • Moderator
  • Hero Member
  • *****
  • Сообщений: 4708
  • Рейтинг читателей: 82
    • Просмотр профиля
    • Профиль в МК
Наткнулся на описание ЮМЛ от МС:
https://msdn.microsoft.com/ru-ru/library/dd409376.aspx

Кто какие ошибки найдет?

На затравку: мне очень не понравилась вот эта схема:


Что это за ЗЛ - Ресторан? Как Клиент заказывает еду без него?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.


Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1318
  • Рейтинг читателей: 57
    • Просмотр профиля
    • http://www.greesha.ru
А по-моему, отличный пример. Понятная и простая иллюстрация.
greesha.ru

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

Сергей Евтухович

  • Full Member
  • ***
  • Сообщений: 130
  • Рейтинг читателей: 14
    • Просмотр профиля
Наткнулся на описание ЮМЛ от МС:
https://msdn.microsoft.com/ru-ru/library/dd409376.aspx

Кто какие ошибки найдет?

На затравку: мне очень не понравилась вот эта схема:


Что это за ЗЛ - Ресторан? Как Клиент заказывает еду без него?

1. Описываются несколько типов диаграмм и предлагается начать разработку с любой, хотя надо идти от общего к частному. Т.е. будет странным от sequence перейти к use case диаграмме.
2. С одной стороны говорится о том что требования описывают внешнее поведение, видимое через UI и API, с другой стороны, к примеру, sequence диаграмма описывается как часть требований, но говорится про взаимодействие с частями системы.
3. Непонятный UC "Доставить еду" на второй диаграмме. Вынесен за границу некой подсистемы, но вместе с тем приведён на той же диаграмме и непонятно к чему он относится. Такое ощущение,  что это неудачно названный бизнес-UC.

Дальше читать не стал. Много букв:) А пример с эктором ресторан конечно не очень удачный. Хотя такой Эктор может существовать если, к примеру, в ресторане работает одно лицо, которое выполняет все роли.


Galogen

  • Moderator
  • Hero Member
  • *****
  • Сообщений: 6011
  • Рейтинг читателей: 187
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Как эктор Ресторан узнает о заказах, если он взаимодействует с подсистемой только как поставщик сведений о меню.

Другой логических разрыв подмеченный Сашей, это на ДП есть взаимодействие в процессе заказа еды с объектом Ресторан, а на уровне UCD это взаимодействие пропадает. Появляется эктор Банк, но на UCD его нет вообще. Система как-то общается с Рестораном в ходе подтверждения заказа (пришла оплата), но на UCD это не показано.

Да начальная UCD вполне понятна, но синтаксически и семантически ошибочная на мой взгляд. Вопрос стоил ли к этому придираться? И если оставить как есть, точно не приведет к логическом разрыву. Учтите, тут моделюшечка то микропусенькая. А в реальности все куда суровее.

Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1318
  • Рейтинг читателей: 57
    • Просмотр профиля
    • http://www.greesha.ru
Эти картинки только иллюстрируют возможности применения схемы, а вовсе не представляют "полную модель юскейсов".

Если расписать всех возможных пользователей и все их цели по отношению к системе, получится карта, которую можно вешать на стену, а не использовать в качестве иллюстрации к статье.

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

Я в одном могу согласиться: это не диаграмма вариантов использования. Но imho сама схема несправедливо (или, скорее, недальновидно) узурпирована методологами разработки по юскейсам. Хотя это очень мощный инструмент визуализации, возможности применения которого распространяются далеко за пределы ДВИ. Юскейсы отомрут, а схема останется.
greesha.ru

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

Denis Beskov

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 2405
  • Рейтинг читателей: 90
    • Просмотр профиля
    • Школа системного анализа
Я в одном могу согласиться: это не диаграмма вариантов использования.
а что это?

Григорий Печенкин

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 1318
  • Рейтинг читателей: 57
    • Просмотр профиля
    • http://www.greesha.ru
а что это?

Ой, я имел в виду не ту, которая здесь приведена в начале топика, а ту, которую обсуждают, она в статье. Прилагаю её.
Здесь "доставить еду" - это цель. Но я бы не сказал, что это usecase.

greesha.ru

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

Denis Beskov

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 2405
  • Рейтинг читателей: 90
    • Просмотр профиля
    • Школа системного анализа
я повторяю свой вопрос

davvol

  • Full Member
  • ***
  • Сообщений: 204
  • Рейтинг читателей: 33
    • Просмотр профиля
Я в одном могу согласиться: это не диаграмма вариантов использования. Но imho сама схема несправедливо (или, скорее, недальновидно) узурпирована методологами разработки по юскейсам. Хотя это очень мощный инструмент визуализации, возможности применения которого распространяются далеко за пределы ДВИ. Юскейсы отомрут, а схема останется.

А почему нет? Я считаю что это вполне себе диаграмма использования. Конечно, "Доставить еду" вылезает за ее рамки, и в таком случае, было бы лучше нарисовать это все как процесс, например в BPMN, но это уже мелочи.
А почему юзкейсы отомрут? Это вполне себе самостоятельный элемент исследования возможностей системы.