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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
91
Было бы хорошо, если бы без лишних слов Вы просто объясните, чем схема не соответствует стандарту.
На Марсе в футбол играют в одни ворота. Слышало, что на Земле используют больше чем одни ворота в этой игре. Уважая традиции Вашей планеты, обращаюсь к Вам с симметричной просьбой обосновать свою точку зрения.

Открываем по Вашей просьбе стандарт 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...
Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.

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

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

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

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

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

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

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

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

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

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

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

101
Некрокоммент: Если нет описаний, то осмысленность использования экстендов/инклюдов и выделения именно этих ВИ под вопросом. С таким же успехом "Закрыть заказа" может быть подпотоком внутри ВИ "Контролировать", а не выноситься как отдельный ВИ. Скорее, всего вместо экстендов всюду должны быть инклюды. Не нужно верить в то, что есть какие особые ситуации, которые моделируются только экстендами, но не инклюдами. Пригодность только экстенда, но не инклюда связана не с тем, что моделируется, а с тем какие ограничения наложены на манипуляции с описаниями ВИ. Если у Вас заморожено описание базового ВИ (но там заблаговременно заведена точка расширения), то годится только экстенд. Наконец, есть установившаяся практика, что включаемый или расширяющий ВИ неявно берёт от базового все его связи с действующими лицами. То есть, явную связь к расширяющему ВИ стоит проводить только если к взаимодействию подключится новое действующее лицо, которое раньше не было соединено с базовым ВИ. Возможно, Вы хотели показать при помощи явных связей, что расширяющие ВИ могут запускаться сами по себе, а не из-за переключения из запущенного базового ВИ, но такое неочень согласуется с использованием  экстендов/инклюдов. Главный дефект, полагаю, состоит в том, что диаграмма не кроет кое-что из описанного: полностью укомплектованные заказы закрываются автоматически.   

102
Тогда с учетом общей критики наверное так :-\
Некро-коммент: дефект диаграммы в том, что клиент всегда получает налик и ему всегда возвращают карту. В жизни это не так. Некоторую странность  диаграммы можно усмотреть в том, что заканчивается она двумя возвратами на один и тот же call. Разумно было бы либо делать один возврат, либо вообще не моделировать взаимодействие с экземпляром действующего лица сообщениями типа call и reply. И финальная рекомендация. Ради Марса, не рисуйте экзекьюшн спецификации на диаграммах последовательности. Их отсутствие почти всегда ни на что не влияет, а присутствие, как правило, провоцирует нарушения стандарта.

103
Не понял, что нужно сделать :)
Ничего не _нужно_. _Можно_, к примеру, потрындеть, сколько человек соберутся рисовать именно Information flow diagram, а не диаграмму классов (учитывая, что в реальной UML-среде можно средствами диаграммы классов создать что-то визуально не отличимое от UML-IFD). И почему, к примеру, UML-IFD -- поведенческая, хотя по конкретному синтаксису она вполне себе выглядит структурной.

104
Ненормативные диаграммы не указаны явно в тексте стандарта UML в той его части, которая посвящена диаграммам -- аппендиксе A.
Можно, при желании, просто понекротредить про эти дополнения.

105

На картинке ненормативные диаграммы, описанные by Kirill Fakhroutdinov, выделены цветом.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »