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

Обсуждения => Обсуждение статей => Тема начата: uml2.ru от 15 Июля 2009, 23:34:01

Название: Отношение extend
Отправлено: uml2.ru от 15 Июля 2009, 23:34:01
«В двух ситуациях создание расширяющих вариантов использования оправдано. Наиболее распространенная ситуация - когда пользователь может применить много асинхронных или прерывающих выполнение услуг, которые не должны мешать базовому варианту использования. Часто эти услуги разрабатываются разными командами и проявляют себя при работе с «коробочным» программным продуктом, таким как текстовый редактор.   Другая ситуация - когда вы пишете дополнения к документу, излагающему зафиксированное описание требований»  Алистер Коберн  Оригинал: Отношение "extend" (http://"http://www.uml2.ru/index.php?option=com_content&task=view&id=445")
Название: Re: Отношение
Отправлено: Galogen от 15 Июля 2009, 23:34:32
Прошу любить и жаловать. Критикуем, дополняем, исправляем
Название: Re: Отношение \
Отправлено: pshony от 16 Июля 2009, 19:37:53
1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?
Название: Re: Отношение extend
Отправлено: Galogen от 16 Июля 2009, 20:42:30
1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?

1. Вообще понятие расширяющий ВИ довольно смутно. Так Коберн говорит о расширениях основного потока варианта использования именно как об альтернативах.

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

2. а причем тут инклюд? инклюд - это то что включается всегда, без чего основной ВИ неполон и завершится не может. А расширяющий - это то без чего можно спокойно обойтись.

По-моему все предельно ясно в статьях написано - перечитайте их внимательно
Название: Re: Отношение \
Отправлено: pshony от 16 Июля 2009, 22:01:19


1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?

...
2. а причем тут инклюд? инклюд - это то что включается всегда, без чего основной ВИ неполон и завершится не может. А расширяющий - это то без чего можно спокойно обойтись. По-моему все предельно ясно в статьях написано - перечитайте их внимательно

Никаких нареканий на текст статьи нет, просто хочется услышать авторитетные мнения (т.к. невозможность разобраться с такими вопросами вынуждает отказываться от использования "extend", что и рекомендуют делать многие авторы на практике).


Пример (чтобы мне лучше разобраться):

Посылка емэйла с помощью почтового клиента. Чтобы послать емэйл, пользователь должен выбрать как минимум 1 адрес получателя (несколько тоже можно, текст письма опционален). Но пользователь, может и не указывать адрес, если он хочет сохранить то, что есть, в черновики и дописать письмо потом.

Вопрос к примеру: На каких шагах такого ВИ можно/нужно включить ВИ для выбора адресатов из адресной книги (если предположить, что другого способа указать адресата, типа просто ввести его имя с клавиатуры, не существует)? Т.е. какая здесь ДВИ получается?
Название: Re: Отношение extend
Отправлено: Galogen от 16 Июля 2009, 22:53:27
Pshony,

давайте разберемся, что и как мы моделируем.

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

Это базис, который позволяет создать контекст решаемой задачи.

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

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

Критерий тут только опыт - опыт написания (и рисования) вариантов использования для ДРУГИХ людей, получения от них обратной связи (рефлексии).

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

Но, конечно, Вы можете делать то, что полагаете нужным, но правильно. Что это значит? Рисуя пиктограммы ВИ (овал с описанием цели), Вы инкапсулируете все виды сценариев данного ВИ, т.е. видя овал, мы не видим всех сценариев данного ВИ: успешных или неуспешных. Далее  структурируя диаграмму использования и добавля отношения включения и расширения между ВИ, мы никаким образом не указываем в каком месте какого конкретного сценария будет происходить включение или расширения.

МЕСТО включения Вы определяете в тексте - для меня же видно только два овальчика о --> о, они мне говорят - первый базовый ВИ, он где-то (в основном потоке или в каких-то исключениях) включает в себя другой ВИ. Без этого другого ВИ он неполный, несостоятельный, он просто не имеет экземпляра. Другой ВИ - нечто самостоятельное, возможно тоже не инициируемое ДЛ, но которое как-то спокойно может обойтись и без своего базового.

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

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

Обратите внимание, что у Вас ВИ - Послать письмо - ограничивается именно пересылкой письма, т.е. как бы получается примерно следующее:
ВИ: Отправить новое письмо (ответ)
Предусловие: текст письма написан и готово к отправке
Основной поток:
1. Пользователь вводит email получателя
точка расширения: массовая рассылка
2. Пользователь вводит тему письма, если необходимо
3. Пользователь отправляет письмо
4. Система (почтовый клиент) сообщает об успешной отправки письма
Альтернативные потоки (исключения, ветвления, прерывания, расширения)
* В любой момент пользователь закрывает редактор письма
   *1 система предлагает сохранить письмо как черновик
   *2 если пользователь соглашается
       *2.1 система сохраняет письмо как черновик и помещает в папку Черновики
   иначе
       *2.2 система удаляет новое письмо
И1. нет соединения с сервером
   И1.1. система сообщает, что отсутствует соединение с сервером
   И1.2. система помещает письмо в папке Исходящие

Далее можно написать расширяющий ВИ: Указать адреса для массовой рассылки

В любом случае - ВИ - это нестрогие математические законы, это семантика + ваше понимание и умение. Наверняка, Вы можете придумать что-то свое и не менее оригинальное и понятное
Название: Re: Отношение extend
Отправлено: Galogen от 16 Июля 2009, 23:02:20
Разница в том, что включение задает явную подцель пользователя, а расширение задает дополнительную цель, то есть какую-то прибавку к конечному результату.
Чаще всего расширяющий вариант использования имеет самостоятельный смысл и ценность и не зависит от расширяемого.
Включаемый вариант имеет смысл только в рамках одного или нескольких включащих и может быть использован для вынесения повторяющихся шагов нескольких сценариев в одно место.

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

Спасибо, Сергей. Ты написал то, что я специально не включил в статью.

Я бы усил эффект

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

Расширяющий ВИ имеет иную цель. В моей статье. Принять возврат книг явно не имеет ничего общего с назначением штрафа. Будет ли назначен штраф, заплатит ли читатель, книги которые он принес будут приняты. Будет выполнена цель, защищен интерес библиотеки (назад получены книги фонда), будет защищен интерес читателя(он сдал книги и получил возможность взять еще). Последнему интересу может препятствовать факт наличия штрафа. Однако это вовсе не означает, что в системе обязательно должна быть такая функция.

Если мы делаем ПО - то функция принятия возврата книг реализуется сначала, она используется и в библиотеках с системой штрафов и в библиотеках без таковой.

Более того, если наше ПО платное, то некая библиотека без штрафов может и не захотеть платить за возможность назначать штрафы через систему (особенно если этот модуль буде платный :)
Название: Re: Отношение extend
Отправлено: Денис Иванов от 17 Июля 2009, 09:41:02
может на второй диаграмме extend в другую сторону?
Название: Re: Отношение extend
Отправлено: bas от 17 Июля 2009, 10:33:44
А может кто-то объяснит почему стрелочка включения идет в одну сторону, а расширения в другую? Я все время их путаю :)
Название: Re: Отношение extend
Отправлено: Денис Иванов от 17 Июля 2009, 11:12:39
Направление зависит от того, какая сущность про какую знает.

Кстати, у нас была тема где-то о том, как можно интерпретировать include и extend. Эдуард говорил про вызов подпрограммы для include и вызов подпрограммы с условием (или что-то подобное) для extend.

Мое мнение было - include = copy/paste, extend = вызов подпрограммы.

Объяснение Эдуарда (с моей точки зрения) не давало ответа на вопрос, почему стрелки направлены в разные стороны.
Мое же объяснение более логично:).
В случае incude. Мы просто копируем все, что есть в независимом ВИ, в зависимый.
В случае extend. Мы передаем управление зависимому ВИ и он знает кто его вызвал и что надо делать.
Название: Re: Отношение extend
Отправлено: pshony от 17 Июля 2009, 15:12:40
Эдуард, Сергей,

Спасибо за развернутые ответы. Конечно, все это в том или ином виде я читал. Для меня же важно услышать авторитетные мнения, основывающиеся на успешной практике. Также, думаю, что это будет полезным дополнением к статье.

В связи с моим вопросом «Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?» просто напишу следующее.

1.   Когда-то ход мыслей у меня был примерно следующий:

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

Далее, у меня было некорректное понимание сущности расширяющих ВИ, что, якобы, они отличаются от включаемых только лишь тем, что включаются по ходу выполнения базового ВИ только при определенном условии (ну и зачем-то текстовое оформление ссылки на расширяющий ВИ чуть-чуть другое – Extension Point :-).  Соответственно, становится не понятно, в чем же существенная разница между расширяющим ВИ и ВИ, включенном в один из альтернативных потоков. Другими словами, я не видел никакой существенной разницы между вызовом расширяющего ВИ и выполнением одинаковых последовательностей шагов в альтернативных потоках, которые выполняются при определенном условии (ведь такие шаги тоже можно вынести в отдельный ВИ и ссылаться на него из альтернативного потока).

Утверждения типа «В отношении «extend» любопытно то, что базовый ВИ ничего не знает о расширяющих ВИ, он просто предоставляет для них точки входа.» не имели для меня никакого практического смысла, т.к. какая разница, «знает» или «не знает», если мне все равно в базовом ВИ нужно прописать эти точки расширения, без которых ничего не произойдет (т.е. мне все равно нужно знать наперед, что тем или иным способом мне нужно вызвать такую-то функциональность и в таком-то месте. Не зная, какую функциональность я хочу вызвать, как я могу сказать, где заранее расставить точки расширения? Иначе, чтобы впоследствии не редактировать документ с базовым ВИ, придется наставить столько точек расширения, что потом вообще никому не объяснишь, кому это надо, зачем, и что с этим делать :-) Вот если бы можно было действительно как-то так написать расширяющий ВИ, чтобы документ с расширяемым ВИ редактировать не приходилось... :-)

Чтобы никого не сбивать с толку, процитирую еще раз «правильное» понимание:


Разница в том, что включение задает явную подцель пользователя, а расширение задает дополнительную цель, то есть какую-то прибавку к конечному результату. Чаще всего расширяющий вариант использования имеет самостоятельный смысл и ценность и не зависит от расширяемого. Включаемый вариант имеет смысл только в рамках одного или нескольких включащих и может быть использован для вынесения повторяющихся шагов нескольких сценариев в одно место. В результате расширяющий ВИ может иметь тот же уровень цели (по Коберну), что и расширяемый, а включаемый ВИ - это подцель, то есть уровень цели ниже.


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


2.   Правда, я так и не нашел ответа на следующую проблему:

ВИ пишутся, для:
- клиентов – чтобы они могли понять, как ПО поможет им выполнять их работу, и чтобы они могли внести корректировки, если им нужна чуть-чуть другая «помощь», нежели предлагается.
- разработчиков – чтобы они могли понять, что должно делать ПО, на сколько это сложно и сколько будет стоить.
- тестировщиков – чтобы они могли написать тест-кейсы и проверить, что ПО работает так, как предполагалось.

По факту, никому из них не интересно вникать в правила и особенности написания ВИ.

Очевидно, ВИ не пишутся для самовыражения бизнес-/системных аналитиков :-)

Чем же наличие двух разных возможностей запустить определенную функциональность (в тексте ВИ) может помочь в достижении целей первых 3х? Что же эти возможности дают такого, что оправдывало бы дополнительную сложность простых вещей?

С одной стороны, можно было бы подумать, что предварительное разделение на Include и Extend может подсказать что-то архитектору, но, с другой стороны, нужна ли ему такая «помощь»?
Название: Re: Отношение extend
Отправлено: bas от 17 Июля 2009, 16:00:20
2. Поэтому и не надо злоупотреблять расшрениями, а тем более включениями, без лишней необходимости.
Пример когда это может нести ценность:
1. Клиент говорит, а где вот эта ф-ть (н-р, Начисление штрафов), а Вы говорите, что это описано в спецификации, можем вывести на ДВи вот таким образом - расширение. Объясняете это Разработчику.
2. Чтобы помочь разработчику (и себе) можно вынести некую ф-ть повторяющую во включение, объяснив при этом что Вы сделали Клиенту.
Название: Re: Отношение extend
Отправлено: Galogen от 17 Июля 2009, 17:19:19
В связи с моим вопросом «Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?» просто напишу следующее.
Можно. Все инклюды, расширения и т.п. - все это в головах. Просто в ходе написания не Вы же первый сталкивается с проблемой оптимальности между полнотой и простотой. Вот Коберн и написал нам книгу, обобщив весь опыт. Когда Вы пишите текст Вы не думаете об инклюдах и экстендах.

Не понимаю какого ответа вы все-таки хотите услышать?

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

ВИ потому и хороши, что пишутся простым языком в определенной установленной формой. Пишутся вами для других. Если никто не будет вас понимать, то соотвественно Вы пишете что-то не то, если будут понимать, значит все окей.
ВИ - это требования, они должны быть настолько точны и ясны, насколько нужно для однозначного понимания их. ВСЕ

Цитировать
Очевидно, ВИ не пишутся для самовыражения бизнес-/системных аналитиков :-)
Именно для этого они и пишутся, если понимать под самовыражением БА и СА их профпригодность

Цитировать
Чем же наличие двух разных возможностей запустить определенную функциональность (в тексте ВИ) может помочь в достижении целей первых 3х?
Что же эти возможности дают такого, что оправдывало бы дополнительную сложность простых вещей?
Написание ВИ как и разработка циклична.
Ничего иного не придумано в оласти ПО для борьбы со сложностью как ДЕКОМПОЗИЦИЯ. В данном случае ДЕКОМПОЗИЦИЯ этапов разработки.
Сначала простейшие кратчайшие ВИ, постепенно обрастающие деталями для нужных действитеьно важных моментов.
Появление потребности в инклюдах и расширениях возникает не сразу, а постепенно по мере необходимости.

Цитировать
С одной стороны, можно было бы подумать, что предварительное разделение на Include и Extend может подсказать что-то архитектору, но, с другой стороны, нужна ли ему такая «помощь»?
Архитектору в первую очередь важны нефукциональные требования. Функциональные хотя и влияют, но слабее. Скорее все эти инклюды и Экстенды важны для организации процесса разработки
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 20 Июля 2009, 13:27:36
Писал пол часа и не сохранил сообщение. Осталось только PS :). Если будет не лень напишу снова.

PS Чтобы окончательно разобраться с зависимостями советую прочитать Овергаарда (http://www.amazon.com/Use-Cases-Patterns-Blueprints-Software/dp/0131451340). В книге рассмотрены все примеры и у вас не будет сомнений где какую связь использовать. Однако не стоит ими злоупотреблять. Лучше все описать в одном варианте использования, если не используется общее поведение. Расширение имеет смысл выносить в отдельный вариант использования если:
1. Поведение может инициироваться самостоятельно и вызываться из другого варианта использования - конкретный расширяющий ВИ
2. Поведение может использоваться в нескольких вариантах использования - абстрактный расширяющий ВИ
3. Расширяющее поведение сложное и его удобней записать отдельно (альтернативный поток событий вынесен вне) - абстрактный расширяющий ВИ

PSPS Выложил черновой вариант своей презентации по данной теме в своем блоге (http://grigorash.ru/archives/273)


Название: Re: Отношение extend
Отправлено: Galogen от 20 Июля 2009, 13:34:55
2. Поведение может использоваться в нескольких вариантах использования - абстрактный расширяющий ВИ
А почему в этом случае мы вдруг имеем дело с абстрактным? Т.е. по сути ВИ которые не имеет экземпляра, получается, что интерпретация расширения осуществляется в расширяемом ВИ? Как это должно выглядеть, нельзя привести пример?

Цитировать
3. Расширяющее поведение сложное и его удобней записать отдельно (альтернативный поток событий вынесен вне) - абстрактный расширяющий ВИ
Почему все время абстрактный?, мне лично это непонятно

Название: Re: Отношение extend
Отправлено: Виталий Григораш от 20 Июля 2009, 14:00:04
Абстрактный вариант использования - читай ВИ который невозможно инициировать самостоятельно, которые не сможет выполниться сам по себе без помощи других вариантов использования.
Теперь примеры с картинками (см. аттач)
Цитировать
Пример 1 (Actor 1)
Самый простой пример - ВИ "Получить справочную информацию" - расширяющий и конкретный.
Если вызывать из другого ВИ то это контекстная справка по конкретной функции (открывается нужная страница справки).
Если вызывать самостоятельно, то это просмотр полной справки

Цитировать
Пример 2 (Actor 2)
Общее поведение, которое используется опционально в нескольких вариантах использования, но самостоятельно не вызывается пользователем.
Вернуть книгу и Зарегистрировать новую книгу могут быть расширены общим поведением - Проверить очередь желающих почитать данную книжку.

Цитировать
Пример 3 (Actor 3)
Выносим альтернативный поток событий отдельно с одной лишь целью - не усложнять описание базового варианта использования. В том случае когда альтернатива громоздка и может содержать в себе много проверок, альтернатив и взаимодействие с новыми акторами.
Например дополнительная проверка требующая обращения во внешнюю систему с описанием обработки ошибок разрыва связи и таймингов, причем проверка опциональная при определенном условии или желании пользователя. Абстрактным будет потому, что сам по себе такой поток событий не представляет интереса и вызывается только из базового варианта использования.


Название: Re: Отношение extend
Отправлено: Galogen от 20 Июля 2009, 16:50:06
Абстрактный вариант использования - читай ВИ который невозможно инициировать самостоятельно, которые не сможет выполниться сам по себе без помощи других вариантов использования.
Мне кажется, в данном случае понятие абстрактный используется несовсем корректно. Что значит иницироваться самостоятельно? Любой ВИ кто-то инициирует. Его инициирует непосредственно действующее лицо, либо он инициируется из другого ВИ (вероятно самой системой) для обеспечения интересов какой-то из сторон.

Как в статье: назначить штраф не иницируется самим билиотекарем, а иницируется событием или условием - текущая дата больше, чем дата предельного срока сдачи книг.

Причем же тут абстрактность? Абстракность - это когда конкретное поведение ВИ не может быть инстацировано
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 20 Июля 2009, 16:52:26
Все верно Эд, только ВИ со штрафом должен быть абстрактным, так как сам по себе инстансом не может быть.
Название: Re: Отношение extend
Отправлено: Денис Иванов от 20 Июля 2009, 17:47:03
Абстрактность имеет смысл использовать только для показа некоторого обобщения, которое специализируется уже конкретными ВИ (может быть на других диаграммах).

Абстрактный вариант использования - читай ВИ который невозможно инициировать самостоятельно, которые не сможет выполниться сам по себе без помощи других вариантов использования.
Это откуда такое определение?
Абстрактный - эначит нет прямых экземпляров. Больше ничего. Возможность или невозможность иниициировать тут не при чем.
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 20 Июля 2009, 17:57:25
Абстрактный - эначит нет прямых экземпляров. Больше ничего.
Правильно. Нет экземпляров, т.е. не может существовать самостоятельно, только в виде наследников или в виде "куска" другого ВИ. Абстрактный можно инициировать, но инстанс будет не сам ВИ, а совокупность неабстрактных шагов данного ВИ и подмены его абстрактных шагов конкретными из наследника. Другими словами когда инициируешь вариант использования уже работаешь с объектами и их взаимодействиями, а не с вариантами использования. Все абстрактное перерождается в конкретное, подменой или соединением шагов.

А фраза - это моя интерпретация мыслей откуда-то из произведений Айвара Джакобсона и Ko :)
Название: Re: Отношение extend
Отправлено: Денис Иванов от 20 Июля 2009, 18:33:31
... т.е. не может существовать самостоятельно, только в виде наследников или в виде "куска" другого ВИ. Абстрактный можно инициировать, но инстанс будет не сам ВИ, а совокупность неабстрактных шагов данного ВИ и подмены его абстрактных шагов конкретными из наследника. Другими словами когда инициируешь вариант использования уже работаешь с объектами и их взаимодействиями, а не с вариантами использования. Все абстрактное перерождается в конкретное, подменой или соединением шагов.
Мне кажется очень много философии:)

Лично я, Виталий, твои объяснения принять не могу.
Под абстрактным ВИ ничего нет. Ни самого маленького "кусочка" реализации (сценария). Абстракции служат, чтобы уменьшить сложность. Абстрактный ВИ - хороший тому пример (как и абстрактное ДЛ, кстати).
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 20 Июля 2009, 21:30:03
Мне кажется очень много философии:)

Лично я, Виталий, твои объяснения принять не могу.
Под абстрактным ВИ ничего нет. Ни самого маленького "кусочка" реализации (сценария). Абстракции служат, чтобы уменьшить сложность. Абстрактный ВИ - хороший тому пример (как и абстрактное ДЛ, кстати).
Денис, наверное я не умею доходчиво объяснять :). Только не я являюсь источником этих идей. Я лишь выступаю в роли пророка и пытаюсь донести (может и криво) идеи Овергаарда, Джакобсона и Арлоу, которые об этом пишут в своих книгах. И в книге, которую последнее время часто упоминают на форуме, все это четко прописано, если немного детальнее ее поизучать. С одиниковостью абстракций вариантов использования и действующий лиц я не соглашусь, так как это по природе своей разные вещи - один сущность, второй поведение. Возможно я не знаю многих деталей UML, но последнее время я смотрю все больше в сторону текстового описания и использую модель лишь для собственного понимания системы и ее границ. UML это помощник нам в нашей работе, если он начинает усложнять мне жизнь, то я просто от него отказываюсь, придерживаясь принципа KISS :)

Как ты ранее писал:
Абстрактный - эначит нет прямых экземпляров. Больше ничего. Возможность или невозможность иниициировать тут не при чем.
Я полностью с этим согласен. А теперь немного цитат из книги Арлоу про абстрактные варианты использования, экземпляры и другое отновительно абстракции включаемых и расширяющих вариантов использования:
Цитировать
Арлоу. UML2 и унифицированный процесс
...Если в родительском прецеденте нет потока событий или поток событий не завершен, это абстрактный прецедент
Цитировать
Поскольку в абстрактных прецедентах поток событий отсутствует или является не полным, они не могут быть выполнены системой
Цитировать
Однако включаемые прецеденты могут быть как полными, так и неполными. Если включаемый прецедент неполный, он просто содержит часть потока событий, которая имеет смысл только тогда, когда включена в соответсвующий базовый прецедент. Обычно такие прецеденты называют фрагментом поведения. В этом случае говорят, что экземпляр включаемого прецедента не может быть создан, т.е. он не может быть инициирован актерами напрямую.
Цитировать
Расширяющие прецеденты обычно не являются полными прецедентами, поэтому, как правило, их экземпляр не может быть создан

Автор четко говорит о том, что неполные варианты использования не имею экземпляров, а следовательно являются абстрактными. Если описанное выше противоречит UML значит авторы его не знают. И им прежде чем писать книги, стоило бы наверное самим подучиться.
Если в дополнение к этому сослаться на Овергаарда, то мы увидим абсолютно схожую картину.
Название: Re: Отношение extend
Отправлено: bas от 20 Июля 2009, 22:10:43
Может быть в нашу Дискуссию включить и Арлой с Овергаардом?
Можно им написать и спросить что же они имели в виду под абстрактными ВИ, но с ними должен спорить Денис, как человек знающий досконально спецификацию ;)
Название: Re: Отношение extend
Отправлено: Galogen от 21 Июля 2009, 00:06:40
Ай яй яй Виталий. Как не хорошо так порочно цитировать Арлоу, и сваливать на него вопросы абстракции ВИ.

1. Не надо приводить цитаты вне контекста их использования! А контекст там - использование обобщения.

2. На мой взгляд ты сделал неверный логический вывод, сопоставив похожие рассуждения о неполноте базового ВИ (в случае наличия включения). Неполный - незавершенный <> абстрактный.

Назначить штраф вполне можно осуществить и после, между прочим:)
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 21 Июля 2009, 10:06:34
Ай яй яй Виталий. Как не хорошо так порочно цитировать Арлоу, и сваливать на него вопросы абстракции ВИ.
Процитировал я слово в слово. Контекст там очевиден. Останусь при своей точке зрения. ;)

ЗЫ ИМХО Варианты использования в UML недостаточно полно покрыты, поэтому Арлоу все время приходится оговариваться, что в UML этого нет. На практике люди ищут пути решения проблем расширяя и дополняя имеющиеся нотации. Если бы например использовал только UML при описании ВИ - они получились бы далеки от совершенства. Не удивлюсь если через пару лет в каком-нибудь uml3 будет существенное расширения вариантов использования (Джекобсон вводит четкое описание классификтора ВИ), ибо там только человечки, овальчики и никому не понятные extend и include :).
ЗЫЗЫ Я не против UML я за рациональное его использование - решение проблем в разработке ПО :). Оттачивать знания можно бесконечно как и спецификацию требований...
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 21 Июля 2009, 15:38:13
Цитировать
Abstract and Concrete Use Cases
A concrete use case is a particular type of use case that is directly invoked by an actor and achieves a specific goal. It is self-contained and illustrates a complete flow of events. A concrete use case is a specific instance of using a common set of steps referred to as an abstract use case.

An abstract use case is a particular type of use case that is not directly invoked by an actor but is called by another use case.
When two or more use cases have a sequence of the same steps, these steps are extracted and put into a common use case. This common, or abstract, use case is then available to be included in any other use case within the system. Abstract use cases eliminate redundancy and promote reuse, a goal of object-oriented systems design.

Because an abstract use case contains only a subset of the steps in a flow of events, it may not make sense as a standalone use case. An abstract use case is included as part of one or more concrete use cases in order to represent a complete flow of events.

Цитировать
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition by Craig Larman
30.2. Terminology: Concrete, Abstract, Base, and Addition Use Cases
A concrete use case is initiated by an actor and performs the entire behavior desired by the actor [RUP]. These are the elementary business process use cases. For example, Process Sale is a concrete use case. By contrast, an abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story, such as Process Sale.

A use case that includes another use case, or that is extended or specialized by another use case is called a base use case. Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use case. On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case. Handle Credit Payment is the addition use case in the include relationship to Process Sale. Addition use cases are usually abstract. Base use cases are usually concrete.
Название: Re: Отношение extend
Отправлено: Galogen от 22 Июля 2009, 18:30:01
Приходится признать такое понимание абстрактного варианта использования. Поскольку сам создатель нам об этом говорит.
Цитировать
An abstract use case is a use case which is not to be instantiated. Typically, the use case does not provide a complete declaration of a usage. The intention is that the use case is to be used in e.g. generalizations, include relationships or extend relationships.

Abstract use cases are used for declaring commonalities at one place which later can be reused when defining new use cases that share these commonalities, to declare parts of usages (subflows) that are added in a later version of the model, or to model subflows explicitly.

An abstract use case is denoted with an ellipse like an ordinary use case, but with the name italicized. I have a typical example. It is the usual ATM example where the Card Identification use case is abstract and included in the Withdrawal and the Transfer Funds use cases. None will just perform Card Identification. It is not a concrete use case. However, the behavior declared in the Card Identification use case is important in the system, and it is included in multiple use case.

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

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

Вот ситуация. Предположим что создать клиента (информацию) можно только в ходе создания заказа.
Иначе создать клиента нельзя. Править данные по клиенты тоже можно только из заказа.
Почему так сложилось не суть.

Исходя из правил того же Ивара, получается, что ВИ Создать клиента абстрактен, поскольку к нему нет прямого доступа. В чем тут абстрактность?

Абстрактность основного действующего лица? В том смысле что это может быть менеджер заказов, менеджер доставки или кто-то еще кто может в заказе создавать править данные по клиенту?

Лично мне понятна такая абстракция, когда есть некое скелетное описание действий, но конкретное их наполнение наполняется адаптивно в контексте базового ВИ. Хотя и эту ситуацию представить сложно
Название: Re: Отношение extend
Отправлено: Денис Иванов от 23 Июля 2009, 09:04:23
Да... Приходится признать.
Название: Re: Отношение extend
Отправлено: Shur от 24 Июля 2009, 12:00:24
"Крамольное предположение": если исходить из тезиса Якобсона о том, что "Abstract use cases are used for declaring commonalities at one place which later can be reused when defining new use cases that share these commonalities, to declare parts of usages (subflows) that are added in a later version of the model, or to model subflows explicitly." то может быть полезно было бы использовать нотацию aggregation(composition) для описания отношений между ВИ (хотя это и не соответствует спецификации)?
Название: Re: Отношение extend
Отправлено: Виталий Григораш от 24 Июля 2009, 13:29:23
Агрегация и композиция не подходят. ВИ не состоит из частей. ВИ - это есть целое + кусочек из другого ВИ (в случае зависимостей).
Название: Re: Отношение extend
Отправлено: Shur от 24 Июля 2009, 14:12:22
Агрегация и композиция не подходят. ВИ не состоит из частей. ВИ - это есть целое + кусочек из другого ВИ (в случае зависимостей).

Я как раз про кусочки :).  И Якобсон пишет про parts of usages. Если мы все таки можем говорить о "кусочках из другого ВИ" , то тезис о единстве и неделимости ВИ фактически ставится под сомнение. Почему бы про такие "кусочки" прямо не указать - частью чего они являются на диаграмме нотацией агрегации(композиции), принятой для "обычных" классов? Где жмет? Почему у авторов UML use case как бы и класс, и в то же время не класс? Оправдано ли на практике такое обособление ВИ от "обычных классов"?