Форум Сообщества Аналитиков
Обсуждения => Обсуждение статей => Тема начата: uml2.ru от 29 Июня 2009, 13:42:12
-
Иногда в вариантах использования присутствует многократное описание одних и тех же действий. Рассмотрим, к примеру, систему «Кадры» (рис.1) Рис.1. Фрагмент функциональности системы «Кадры» Оригинал: <a href="http://www.uml2.ru/faq/faq-uc/92/">Включение вариантов использования</a>
-
Читаем, комментируем, предлагаем, дополняем :)
-
Отношения включения в uml нет. Есть отношение зависимости со стереотипом include.
-
Из статьи
"Синтаксис и семантика отношения включения немного напоминает вызов процедуры или функции."
Не согласен. Это отношение зависимости со стереотипом extend напоминает вызов процедуры или функции, так как происходит передача управления.
В случае include это напоминает copy-paste, т.е. содержание включаемого ВИ просто копируется в базовый ВИ.
-
Это отношение зависимости со стереотипом extend напоминает вызов процедуры или функции, так как происходит передача управления.
В случае include это напоминает copy-paste, т.е. содержание включаемого ВИ просто копируется в базовый ВИ.
Здесь имеется в виду, что когда из главной программы вызывается процедура, то действие основной программы прекращается и управления передается подпрограмме, пока подпрограмма не отработает управление главной не передается. Экстенд - включение с условием - никакого противоречия не вижу
-
Отношения включения в uml нет. Есть отношение зависимости со стереотипом include.
Согласен могу поправить в статье
-
The OMG UML specification (UML Superstructure Specification, v2.1.1, p. 591) states:
Include is a DirectedRelationship between two Use Cases, implying that the behavior of the included Use Case is inserted into the behavior of the including Use Case. It is also a kind of NamedElement so that it can have a name in the context of its owning Use Case. The including Use Case may only depend on the result (value) of the included Use Case. This value is obtained as a result of the execution of the included Use Case.
А вот смотри, тут явно использовано слово - направленное отношение. Заметь, не зависимость, хотя дальше мы видим, что включающий ВИ может зависеть от результата включаемого. Интересна мысль по поводу МОЖЕТ зависеть
-
Смотри, DirectedRelationship - это абстрактный класс метамодели. У него нет прямых экземпляров, и следовательно, в модели он появиться не может. Include и Dependency (отношение зависимости), например - это классы метамодели, который является подклассами DirectedRelationship и оба они - направленные, так что заострять внимание на этом не имеет особого смысла.
Затем вот что. Тут я не прав, когда говорю про "отношение зависимости со стереотипом include". Эти деятели из OMG виноваты:) Раньше все, что писалось в двойных треугольных кавычках называли стереотипами, а все что было стереотипами писалось в двойных треугольных кавычках.
Сейчас это не так. Там ниже твоей цитаты в секции Notation написано, что "The arrow is labeled with the keyword «include»." Т.е. include - это ключевое слово, а не стереотип. А это уже разные вещи!
Поэтому когда ты пишешь отношение включения - это правильно:)! Это отдельное отношение. Не отношение зависимости! хотя визуально выглядит похоже.
Вывод: статью можешь не править:), хотя это все такие детали, что на содержание не отражаются...
По поводу copy-paste напишу позже...
-
Ты меня успокоил, поскольку я так это и понимал :)
-
ну и отлично. Всегда приятно получить подтверждение правильности своих взглядов:)
-
По поводу copy-paste напишу позже...
Обещанного три года жду?
-
По поводу copy-paste напишу позже...
ну вот в C например есть директива inline которая на этапе компилирования позволяет вставить тело функции в тело программы без вызова, по сути и есть copy-paste. но в исходнике мы эту функцию вызываем.
-
ну вот в C например есть директива inline которая на этапе компилирования позволяет вставить тело функции в тело программы без вызова, по сути и есть copy-paste. но в исходнике мы эту функцию вызываем.
Только в C++.
Или уже и в C вставили? Там обычно обходились макросами.
-
Отношения включения в uml нет. Есть отношение зависимости со стереотипом include.
И все же это отношение включения, которое обозначается как зависимость со стереотипом Include.
Наверное, нет смысла обсуждать реализацию, т.е. каким именно образом "включаемое" поведение "включается" в основное. Если пойти в другие источники, например, RUP, то есть прямые рекомендации планировать реализацию включаемого поведения в план как компонент многоразового использования.
Но, вполне возможно, все это просто перерастет в очередную терминологическую войну.
Я сейчас в Москве, в командировке, справочника под рукой нет!
-
Я прошу извинения за то, что "встрял"!
Конфликт, как я понимаю, исчерпан до моего выступления!
-
Я прошу извинения за то, что "встрял"!
Конфликт, как я понимаю, исчерпан до моего выступления!
Конфликта не было, была дискуссия.
-
Я новичек в UML, почему в примере 4, ВИ: Найти данные служащего, п.3. Менеджер удаляет данные служащего ?
-
Я новичек в UML, почему в примере 4, ВИ: Найти данные служащего, п.3. Менеджер удаляет данные служащего ?
Это недосмотр при копировании. п.3 нужно убрать
-
Статья [у меня] не открывается.
В текущей версии метамодели include и extend подвешены подклассами к DirectedRelationship как прямые наследники. При этом не сказано явно про disjoint. Следовательно, либо авторы метамодели не перешли на новые дефолтные свойства обобщений, либо они полагают, что какой-то include может быть также extend'ом. Во втором случае возникает пикантность при обсуждении различий между видами связей ВИ.
По синтаксису [предлагаемому Коберном] include напоминает гиперссылку. Никакой inline подстановки (как и копи-пасты описаний ВИ) не происходит. Тем более, компиляции. Неясно, что имели в виду авторы реплик.
По прагматике include близок в вызову процедуры, а extend -- к обработке исключения.
-
Подправил ссылку на статью
-
Небольшой довесок.
One author of a book on use cases told me that extend and include are best discussed by friends over beer.
Или в переводе
Один автор книг о вариантах использования сказал мне, что такие связи между ВИ лучше всего обсуждать с друзьями за бокалом пива.