Форум Сообщества Аналитиков

×


Управление изменениями требований(Прочитано 55114 раз)
Re: Управление изменениями требований Ответ #135 : 11 Апреля 2020, 00:05:49
Я перед тем как написать свое первое сообщение по этому вопросу, открыл стандарт и посмотрел в нем схемы.
Никаких принципиальных отличий от выложенной здесь схемы я не увидел.
В этом случае никакие мои слова ни в чем Вас не убедят.

А вам видимо доставляет удовольствие говорить загадками на протяжении уже нескольких дней.
Почему загадками. У меня своя точка зрения, у Вас своя. Для меня очевидным является факт, что это диаграмма не корректна с позиции именно нотации UML.
Вы же утверждаете, что она ни чем не противоречит. Мне как раз Ваша точка зрения не понятна.

Очень продуктивный способ вести обсуждение.
Называется маевтика :)

https://www.uml-diagrams.org/use-case-actor-association.html
https://www.uml-diagrams.org/use-case-extend.html
https://www.uml-diagrams.org/use-case-include.html



Re: Управление изменениями требований Ответ #136 : 11 Апреля 2020, 01:16:43
Было бы хорошо, если бы без лишних слов Вы просто объясните, чем схема не соответствует стандарту.
На Марсе в футбол играют в одни ворота. Слышало, что на Земле используют больше чем одни ворота в этой игре. Уважая традиции Вашей планеты, обращаюсь к Вам с симметричной просьбой обосновать свою точку зрения.

Открываем по Вашей просьбе стандарт OMG UML v2.5.1
В параграфе 18.1.4 на странице 642 сказано:
Цитировать
An Extend relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the extending UseCase towards the extended UseCase. The arrow is labeled with the keyword «extend»... An Include relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the base UseCase to the included UseCase. The arrow is labeled with the keyword «include»...

Стало быть, стандартная нотация нарушена при изображении связи включения от Usecase2 к Usecase3 (проведена пунктирная линия, а не предписываемая стандартом пунктирная стрелка). Стало быть, стандартная нотация нарушена при изображении связи расширения от Usecase4 к Usecase2 (также отсутствует стрелка).

Сплошной линией в стандартном UML изображается ассоциация. Проводить ассоциацию между двумя вариантами использования стандарт разрешает только тогда, когда  они находятся внутри разных subject-ов (внутри рамкок двух разных систем). Для этого в параграфе 18.2.5.6 на стр. 650 заведено ограничение:
Цитировать
no_association_to_use_case
UseCases cannot have Associations to UseCases specifying the same subject.
context UseCase inv: Association.allInstances()->forAll(a | a.memberEnd.type->includes(self) implies (
let usecases: Set(UseCase) = a.memberEnd.type->select(oclIsKindOf(UseCase))->collect(oclAsType(UseCase))->asSet() in
usecases->size() > 1 implies usecases->collect(subject)->size() > 1))

Выше в параграфе 8.1.3 на стр. 640 также сказано:
Цитировать
Two UseCases specifying the same subject cannot be associated...
Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.

Теперь пройдёмте к Вашим воротам.
[...и улетело НЛО.]



Re: Управление изменениями требований Ответ #137 : 11 Апреля 2020, 12:24:04
Называется маевтика :)
Жаль, что Вас "маевтика" больше интересует, чем UML.



Re: Управление изменениями требований Ответ #138 : 11 Апреля 2020, 12:33:53
Открываем по Вашей просьбе стандарт OMG UML v2.5.1 ...
Стало быть, стандартная нотация нарушена при изображении связи включения от Usecase2 к Usecase3 (проведена пунктирная линия, а не предписываемая стандартом пунктирная стрелка).
Стало быть, стандартная нотация нарушена при изображении связи расширения от Usecase4 к Usecase2 (также отсутствует стрелка).
...
Сплошной линией в стандартном UML изображается ассоциация.
Проводить ассоциацию между двумя вариантами использования стандарт разрешает только тогда, когда  они находятся внутри разных subject-ов (внутри рамкок двух разных систем).
Для этого в параграфе 18.2.5.6 на стр. 650 заведено ограничение:
Выше в параграфе 8.1.3 на стр. 640 также сказано:  Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.

Спасибо!
Так как два авторитетных аналитка сказали о некорректности схемы, я в этом не сомневался.
Просто хотелось точнее определить в чем заключается эта некорректность.
Теперь я еще раз перечитаю стандарт, уделяя особое внимание указанным "тонкостям".



Re: Управление изменениями требований Ответ #139 : 11 Апреля 2020, 13:40:03
Так что мужикам - яйца, экспертам - язык.
некротрединга псто:
Предлагаю желающим определить, чья нотация на следующих картинках: мужицкая или экспертная?

Подпись к 1й картинке: Юзвери, юзвериные цели, экземпляры юзверей

Подпись ко 2й картинке: Связи между вариантами использования, юзвериными целями, деловыми целями
Эксперты по "прекрасным визуализациям" могут попытаться здесь рассмотреть, что цель юзверя и вариант использования (даже если это вариант использования с уровнем "моря") -- это разные вещи. Их нельзя отождествлять.
[...и улетело НЛО.]



Re: Управление изменениями требований Ответ #140 : 11 Апреля 2020, 14:03:25
... если это вариант использования с уровнем "моря" ...
Что такое "с уровнем моря"?



Re: Управление изменениями требований Ответ #141 : 11 Апреля 2020, 15:52:13
Что такое "с уровнем моря"?
С подачи Алистера Кобёрна считается, что у варианта использования есть т. н. "уровень цели" -- той цели [действующего лица], которая может быть достигнута в ходе взаимодействий, описываемых сценариями этого ВИ. Т. к. Кобёрн связывал ВИ-1---1-Цель [действующего лица] (1994й год, на минуточку), то из-за этого он упрощённо называл "уровень цели" ВИ просто "уровнем ВИ". Кобёрн придумал 5 "уровней цели" = 5 "уровней ВИ":
 "уровень облака"
 "уровень воздушного змея"
 "уровень моря"
 "уровень рыбы"
 "уровень моллюска"
Цели пользователя (user goal) находятся на "уровне моря". Отсюда закрепилось "вариант использования уровня моря" или "вариант использования уровня цели пользователя".

Тут можно найти поводы для неразберихи:
-- соблазнительно отождествить цель действующего лица с целью пользователя;
-- собразнительно отождествить цель действующего лица и вариант использования;
-- собразнительно отождествить цель пользователя и вариант использования;
-- соблазнительно выродить набор из 5ти уровней цели в один единственный "уровень моря";
-- соблазнительно вещать о том, что на одной диаграмме ВИ должны быть ВИ одного и того же уровня.

Выше можно видеть, что Кобёрна уточнили, что в общем случае ВИ-*---*-Цель [действующего лица]. Нужно учитывать, что ВИ может быть связан с несколькими действующими лицами, у каждого из которых, вообще говоря, есть своя собственная цель по отношению к системе (у клиента банкомата -- получить налик, у банковского сервера -- получить от банкомата вменяемую пачку данных, чтобы можно было разобрать, отбить запрос или удовлетворить). Тогда выходит, что "уровень цели" ВИ по Кобёрну = "уровень цели" основного действующего лица этого ВИ. Глядя на ВИ с позиций разных действующих лиц, связанных с ним, мы можем видеть уровни цели этих лиц, и уровни эти не обязаны совпадать. Для точного и полного описания ВИ следовало бы у каждого ВИ указывать перечень целей всех причастных действующих лиц.

Но это марсианские реалии. Любое совпадение с реалиями тутошней планеты случайно. 
[...и улетело НЛО.]



Re: Управление изменениями требований Ответ #142 : 11 Апреля 2020, 17:44:29
... считается, что у варианта использования есть т. н. "уровень цели" -- той цели [действующего лица], которая может быть достигнута в ходе взаимодействий, описываемых сценариями этого ВИ ...
Еще раз спасибо! Коберна читал когда-то очень давно.
Хороший повод для самообразования. Надо будет перечитать все что связано с целями ВИ и их уровнями.
Можете порекомендовать что почитать кроме Коберна?

Но это марсианские реалии. Любое совпадение с реалиями тутошней планеты случайно.
У меня всегда есть стремление глубже разобраться и сделать что-то как можно "правльнее".
Не важно где я нахожусь: на марсе или на тутошней планете.
Поэтому в первую очередь интересует "истина", которая всегда "дороже".



Re: Управление изменениями требований Ответ #143 : 11 Апреля 2020, 18:06:17
Еще раз спасибо!

Благодарю Вас. Есть какие-то вещи, которые крутятся в голове, а повода оформить их в текст не находится. Общение на форуме такие поводы иногда даёт. Спасибо.
[...и улетело НЛО.]



Re: Управление изменениями требований Ответ #144 : 12 Апреля 2020, 18:14:35
Можно дополнить, что саму моделируемую систему Кобёрн относил к действующим лицам. В этом можно усмотреть повод к тому, чтобы в рамках варианта использования посмотреть на всё глазами этого действующего лица, а именно признать, что система тоже имеет цели по отношению к действующим лицам, причастным к этому ВИ. Фиксация целей этого действующего лица и соответственно обязанностей, возлагаемых им на других причастных действующих лиц, может пригодиться для некоторых нефункциональных требований.
[...и улетело НЛО.]



Re: Управление изменениями требований Ответ #145 : 18 Апреля 2020, 23:30:11
(у клиента банкомата -- получить налик, у банковского сервера -- получить от банкомата вменяемую пачку данных, чтобы можно было разобрать, отбить запрос или удовлетворить).
Коберн говорит о том, что в каждом шаге ВИ должен защищаться чей-то интерес. И он приводит довольно сложную классификацию ДЛ.
Но ВИ все-таки стремится обеспечить цель основного ДЛ, попутно удовлетворяя интересы других участников.
Причем БС - это второстепенное ДЛ (т.е. используемое). Но понятно что с точки зрения правления банка, оно хочет, чтобы транзакции осуществлялись корректно.
Т.е. множественность целей - это отличное наблюдение, но все-таки одна из них всегда в фокусе, и это цель ОДЛ.



Re: Управление изменениями требований Ответ #146 : 18 Апреля 2020, 23:32:35
Можете порекомендовать что почитать кроме Коберна?
Если интересно разобраться именно с use case modeling, я бы рекомендовал книгу: https://yadi.sk/d/j20Pd2DUftGuv



Re: Управление изменениями требований Ответ #147 : 19 Апреля 2020, 00:16:20
Я не такой хейтер Коберна как RUP-евангелистка Терри Кватрани. Я лишь обозначило возможное развитие его идей, с учётом приведённых выше IBM-овских диаграмм.
Могу продолжить болтать в том же ключе. Например, о том, что в большинстве случаев ВИ рассматривается как непротиворечивое взаимодействие действующих лиц и системы. Гитотетически можно предположить ВИ, в рамках которого несколько действующих лиц являются антагонистами со взаимно исключающими целями. Такой "лебедеракощучный" ВИ. В таком гипотетическом случае, считая основным лебедя и выделяя только его цель, забывая про то, что "рак пятится назад, а Щука тянет в воду", мы получим перекошенное описание. И не соблюдём завет классика: "Кто виноват из них, кто прав, — судить не нам...". 
[...и улетело НЛО.]




 

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