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

×


Отношение extend(Прочитано 35212 раз)
Отношение extend : 15 Июля 2009, 23:34:01
«В двух ситуациях создание расширяющих вариантов использования оправдано. Наиболее распространенная ситуация - когда пользователь может применить много асинхронных или прерывающих выполнение услуг, которые не должны мешать базовому варианту использования. Часто эти услуги разрабатываются разными командами и проявляют себя при работе с «коробочным» программным продуктом, таким как текстовый редактор.   Другая ситуация - когда вы пишете дополнения к документу, излагающему зафиксированное описание требований»  Алистер Коберн  Оригинал: Отношение "extend"
« Последнее редактирование: 01 Апреля 2013, 20:36:27 от maestrosite.ru »



Re: Отношение Ответ #1 : 15 Июля 2009, 23:34:32
Прошу любить и жаловать. Критикуем, дополняем, исправляем



Re: Отношение \ Ответ #2 : 16 Июля 2009, 19:37:53
1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?



Re: Отношение extend Ответ #3 : 16 Июля 2009, 20:42:30
1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?

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

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

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

По-моему все предельно ясно в статьях написано - перечитайте их внимательно



Re: Отношение \ Ответ #4 : 16 Июля 2009, 22:01:19


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

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

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

  • Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?

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

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

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



Re: Отношение extend Ответ #5 : 16 Июля 2009, 22:53:27
Pshony,

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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



Re: Отношение extend Ответ #7 : 17 Июля 2009, 09:41:02
может на второй диаграмме extend в другую сторону?



Re: Отношение extend Ответ #8 : 17 Июля 2009, 10:33:44
А может кто-то объяснит почему стрелочка включения идет в одну сторону, а расширения в другую? Я все время их путаю :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Отношение extend Ответ #9 : 17 Июля 2009, 11:12:39
Направление зависит от того, какая сущность про какую знает.

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

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

Объяснение Эдуарда (с моей точки зрения) не давало ответа на вопрос, почему стрелки направлены в разные стороны.
Мое же объяснение более логично:).
В случае incude. Мы просто копируем все, что есть в независимом ВИ, в зависимый.
В случае extend. Мы передаем управление зависимому ВИ и он знает кто его вызвал и что надо делать.



Re: Отношение extend Ответ #10 : 17 Июля 2009, 15:12:40
Эдуард, Сергей,

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

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

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

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

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

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

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


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


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


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

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

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

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

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

С одной стороны, можно было бы подумать, что предварительное разделение на Include и Extend может подсказать что-то архитектору, но, с другой стороны, нужна ли ему такая «помощь»?



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



Re: Отношение extend Ответ #12 : 17 Июля 2009, 17:19:19
В связи с моим вопросом «Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?» просто напишу следующее.
Можно. Все инклюды, расширения и т.п. - все это в головах. Просто в ходе написания не Вы же первый сталкивается с проблемой оптимальности между полнотой и простотой. Вот Коберн и написал нам книгу, обобщив весь опыт. Когда Вы пишите текст Вы не думаете об инклюдах и экстендах.

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

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

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

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

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

Цитировать
С одной стороны, можно было бы подумать, что предварительное разделение на Include и Extend может подсказать что-то архитектору, но, с другой стороны, нужна ли ему такая «помощь»?
Архитектору в первую очередь важны нефукциональные требования. Функциональные хотя и влияют, но слабее. Скорее все эти инклюды и Экстенды важны для организации процесса разработки



Re: Отношение extend Ответ #13 : 20 Июля 2009, 13:27:36
Писал пол часа и не сохранил сообщение. Осталось только PS :). Если будет не лень напишу снова.

PS Чтобы окончательно разобраться с зависимостями советую прочитать Овергаарда. В книге рассмотрены все примеры и у вас не будет сомнений где какую связь использовать. Однако не стоит ими злоупотреблять. Лучше все описать в одном варианте использования, если не используется общее поведение. Расширение имеет смысл выносить в отдельный вариант использования если:
1. Поведение может инициироваться самостоятельно и вызываться из другого варианта использования - конкретный расширяющий ВИ
2. Поведение может использоваться в нескольких вариантах использования - абстрактный расширяющий ВИ
3. Расширяющее поведение сложное и его удобней записать отдельно (альтернативный поток событий вынесен вне) - абстрактный расширяющий ВИ

PSPS Выложил черновой вариант своей презентации по данной теме в своем блоге


« Последнее редактирование: 20 Июля 2009, 13:29:55 от Виталий Григораш »
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



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

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





 

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