106

ПО Аналитика / Re: Управление изменениями требований

« : 12 Апреля 2020, 18:14:35 »

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

107

ПО Аналитика / Re: Управление изменениями требований

« : 11 Апреля 2020, 18:06:17 »

Еще раз спасибо!

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

108

ПО Аналитика / Re: Управление изменениями требований

« : 11 Апреля 2020, 15:52:13 »

Что такое "с уровнем моря"?

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

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

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

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

109

Примеры / Re: UML диаграмма для сайта-магазина

« : 11 Апреля 2020, 14:47:39 »

А есть какие-то признаки? Это ведь должен быть докУмент какой-то?

Нету, ни признаков, ни докУментов. Приврало, по марсианскому обычаю. 
Как курьёз, есть геоинформационный ГОСТ Р 57668 -- калька с ISO 19115 и там содержится кусочек UMLя. Т. к. переводили геоспецы, то их ксенолингвист породил принцип Анти-Лизковы, согласно которому подклассы заменяются суперклассами. Теперь так, по ГОСТу.

110

ПО Аналитика / Re: Управление изменениями требований

« : 11 Апреля 2020, 13:40:03 »

Так что мужикам - яйца, экспертам - язык.

некротрединга псто:
Предлагаю желающим определить, чья нотация на следующих картинках: мужицкая или экспертная?

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

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

111

ПО Аналитика / Re: Управление изменениями требований

« : 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...

Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.

Теперь пройдёмте к Вашим воротам.

112

Примеры / Re: use case и диаграмма последовательноси работы парикмахерской

« : 11 Апреля 2020, 00:47:01 »

Да. Телекоммуникационных нотаций в UML перетекло довольно много.

113

Примеры / Re: UML диаграмма для сайта-магазина

« : 11 Апреля 2020, 00:45:06 »

Кажись, UML гостировали. А нафига, если профи его не нужно знать, если профи позволительно рисовать и понимать какой-то псевдоUML под видом настоящего? [Марсианская риторика, если что.]

114

ПО Аналитика / Re: Управление изменениями требований

« : 10 Апреля 2020, 01:29:34 »

А что на этой схеме не соответствует UML?

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

115

Примеры / Re: use case и диаграмма последовательноси работы парикмахерской

« : 10 Апреля 2020, 01:01:30 »

А что есть MSC?

Message sequence chart -- то, что "трое друзей" переоформили в UML-диаграммы последовательности.

116

Примеры / Re: UML диаграмма для сайта-магазина

« : 10 Апреля 2020, 00:58:27 »

а потом на производстве им говорят, да какая разница, правильно или неправильно нарисовано, главное же тебя поняли

Даже не знаю, как на такое ответить. Может быть, авторы профстандартов недоглядели, не оборонили землянскую софтверную индустрию от такого непрофессионального подхода.

117

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 10 Апреля 2020, 00:51:38 »

Тогда переименовываем тему в "диаграмма последовательности процесса успешного снятия денег в банкомате".
Экзэкьюшн-спек на uml-diagrams.org

118

ПО Аналитика / Re: Управление изменениями требований

« : 28 Марта 2020, 04:03:11 »

Вижу в ленте провод для некропоста. Приклею это и ненадолго отлечу.

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

119

Примеры / Re: UML диаграмма для сайта-магазина

« : 28 Марта 2020, 03:30:28 »

Некрокоммент: Местная озабоченность надуманным принципом "одна ДВИ -- один уровень всех ВИ на ней" позволила не заметить основные дефекты диаграммы: просматривать каталог гость и зарегистрированный пользователь обязаны, взявшись за руки; искать (?найти?) товары можно только в том случае, если этим займётся пара админ + зареганный пользователь. А всё почему, потому что в вузах плохо учат UMLю, якобы. 

120

Примеры / Re: use case и диаграмма последовательноси работы парикмахерской

« : 28 Марта 2020, 03:11:51 »

Некрокоммент: А мне нравится диаграмма последовательности. Напомнила одну историю про одного марсианского парикмахера, который стриг всех тех, кто не стригся сам. Или брил?.. А в моделируемой парикмахерской не бреют?
Нарисованная ДВИ показывает, что стрелочки всех видов обучаемый может нарисовать, дабы порадовать препода. Но если полагать, что за каждым "яйцом" на "муже-яйцевой" диаграмме должно быть описание, то радости будет мало.
Претензии к MSC-диаграмме можно снять, если предположить другую ДВИ, на которой будет единственный ВИ "Воспользоваться услугами парикмахерской". На MSC придётся добавить фрагменты взаимодействия и она перестанет быть такой уж безнадёжной.