Характерные ошибки use case диаграммы(Прочитано 58796 раз)
Re: Характерные ошибки use case диаграммы Ответ #30 : 30 Сентября 2014, 17:27:16
Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?

Ты имеешь в виду описанные сценарии?

Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.) И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем. Я не знаю истории этой диаграммы - возможно, изначально она использовалась именно как "карта сценариев", но возможности её применения гораздо шире.

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

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



Re: Характерные ошибки use case диаграммы Ответ #31 : 30 Сентября 2014, 17:57:40
Ну,  если бы надо было описать такое ВИ в спецификации,  это выглядело бы примерно так:
Красиво, спасибо. Но, видимо, мне не удается донести свою мысль.

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



Re: Характерные ошибки use case диаграммы Ответ #32 : 30 Сентября 2014, 21:10:59

Каждый ВИ обладает определенной целостностью и имеет общие предусловия и постусловия.
Скажем, ясно что изменение расписания невозможно, пока не будет создано само это расписание. Как это все увязывается в единой спецификации варианта использования?
Я кажется понимаю куда вы клоните!
По определению, ВИ - это ровно один прецедент использования системы. Т.е. или создание или редактирование или удаление.
При такой декомпозиции очень просто определить основной поток прецедента и альтернативные.
Например, основной поток - удалить расписание. Если расписаний нет - это уже альтернативный поток.

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

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

Это вы спрашивали?:)



Re: Характерные ошибки use case диаграммы Ответ #33 : 30 Сентября 2014, 21:15:57
Это вы спрашивали?:)

Ага :) При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других. Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.



Re: Характерные ошибки use case диаграммы Ответ #34 : 30 Сентября 2014, 21:29:22
Ага :) При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других.

Конечно.

Цитировать
Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.

У меня с практикой тоже не фонтан. Ни заказчики ни разработчики UML не знают, так что я рисую и пишу не по нотации, а чтобы людям понятно было:)



Re: Характерные ошибки use case диаграммы Ответ #35 : 30 Сентября 2014, 21:29:38
- случайный дубль



Re: Характерные ошибки use case диаграммы Ответ #36 : 01 Октября 2014, 13:07:25
Если вы используете для разработки и поддержки требований систему, в которой диаграмма ВИ жёстко связана со сценариями (каждое "яйцо" является ссылкой на сценарий ВИ), то от этих отношений, наверное, никуда не деться. Но в этом случае диаграмма предназначена уже не столько для людей, сколько для роботов. Это такой механизм поддержки целостности модели требований, приближенный скорее к визуальному программированию.
А если вы не используете никакой системы с поддержкой трассировок? По-моему связи 1-к-1 для людей тоже удобнее, чем многие-ко-многим. Особенно если, к примеру разработчику, нужно будет потом разбираться какая часть спецификации к какому ВИ относится.

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

Я не вижу для них практического применения ни со стороны целей пользователя, ни со стороны программной архитектуры.
Как же? Полезность есть как минимум с точки зрения:
1. Отсутствия необходимости изменения сценариев в нескольких местах с описанием общего поведения.
2. Снижения вероятности ошибок при таких изменениях.
3. Снижения вероятности многократной разработки одного и того же функционала.
4. Подсказки разработчикам в части применения нужных абстракций в коде.
5. Устранения необходимости многократного тестирования одного и того же функционала.

Я не понимаю, зачем это вообще нужно выражать графически на диаграмме, которая не описывает поведения. Для этого есть другие диаграммы.
Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.

Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)

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



Re: Характерные ошибки use case диаграммы Ответ #37 : 01 Октября 2014, 13:07:52
Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.)
А зачем выявлять требования, но не описывать их? Agile?:).

И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем.
Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.



Re: Характерные ошибки use case диаграммы Ответ #38 : 01 Октября 2014, 13:30:12
Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)
На костер его, богохульника!

Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.
По стандарту (если я не заблуждаюсь) все это можно считать разным способ реализации варианта использования

Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда



Re: Характерные ошибки use case диаграммы Ответ #39 : 01 Октября 2014, 13:44:16
Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.

Вариант использования как сценарий, безусловно, описывает поведение.

Диаграмма вариантов использования сама по себе поведение не описывает (хоть UML и относит её к классу bihavior diagram).

Графическое изображение варианта использования (как сценария) - imho это другие диаграммы (activity, sequence, communication в терминологии uml).

А зачем выявлять требования, но не описывать их? Agile?:).

Выявлять, но не описывать в виде сценариев. Сценарии ведь не являются единственно возможным вариантом описания требований.

Agile - да, диаграмма ВИ может быть источником user stories.
greesha.ru

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



Re: Характерные ошибки use case диаграммы Ответ #40 : 01 Октября 2014, 15:19:01
Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда
Эдуард, спасибо за ссылку.



Re: Характерные ошибки use case диаграммы Ответ #41 : 01 Октября 2014, 15:25:54
А зачем выявлять требования, но не описывать их? Agile?:).

Нет. Прокурор. :)



Re: Характерные ошибки use case диаграммы Ответ #42 : 01 Октября 2014, 18:54:47
может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html



Re: Характерные ошибки use case диаграммы Ответ #43 : 01 Октября 2014, 19:06:37
может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html

Вот это вообще для меня новость.
greesha.ru

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



Re: Характерные ошибки use case диаграммы Ответ #44 : 02 Октября 2014, 13:35:40
Вот студенты выполнили работу над ошибками и сформировали немного иное представление. 
Буду рад замечаниям и предложениям.




 

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