Что такое вариант использования или прецедент(Прочитано 56307 раз)
Решил создать данную тему, именно, здесь, т.к. она по смыслу подходит в этот раздел.
Я уже обсуждал вопрос о ВИ (варианте использовании или прецеденте), правда в другой ветке. (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=47.0)

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

Итак за основу возьмем таки классиков:
Г. Буч, Д. Рамбо, А. Джекобсон
Язык UML Руководство пользователя

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

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

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

Если Вы сравните данное определение с тем, которое я в конце концов придумал, то найдете безусловное сходство. Я лишь подчеркнул, что
эта последовательность действий НЕДЕЛИМА. Это к слову, почему ВИ не декомпозируется фукнционально, а может лишь детализироваться на разных уровнях абстракции. Попробуйте поделить ребенка при разводе, а? (сорри за черный юмор). Конечно последовательность действий может быть поделена на шаги. И каждый шаг можно рассмотреть как нечто самостоятельное, уж точно неделимое.  Только смысл потеряется. Можно, конечно, разделить трапезу и общение с друзьями. Но разве Вы получите то удовольствие, которое дает пирушка в кругу друзей и близких? Т.е. все определяется целью, конечно потребностью пользователя, актера, действующего лица.
Регистрация на сервере - цель получить аккаунт, доступ. Потому вся последовательность его получения: заполнение форму, отправка данных, получения активации, подтверждение активации - все это тот неделимый процесс, ради которого Вы и начали регистрацию. А каждый из отдельных элементов-этапов сам по себе не приводит Вас к цели, лишь все в целом, как единый (entire) процесс.
В этом главное отличие ВИ от функционального блока в IDEF или DFD. Хотя общее безусловно есть.

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

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

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

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

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

Стоит обратить внимание и на это
Цитировать
Прецеденты являются классификаторами и могут иметь атрибуты и операции, которые изображаются так же, как для классов. Атрибуты можно считать объектами внутри прецедента, которые требуются для описания его внешнего поведения, а операции - действиями системы, необходимыми для описания потока событий. Эти объекты и операции разрешается включать в диаграммы взаимодействия, чтобы специфицировать поведение прецедента.

Как и ко всем остальным классификаторам, к прецедентам можно присоединять автоматы. Позволительно расценивать их как еще один способ описания поведения прецедента.



Ну довольно полное теоретическое описание ВИ.

Тебе нравится больше твое определение:
Вариант использования, прецедент, use case - конечная НЕДЕЛИМАЯ последовательность событий, возникающих в системе для удовлетворения потребности действующего лица, инициирующего эту последовательность.

А мне больше мое нравится:
Вариант использования, прецедент, use case - это конечная НЕДЕЛИМАЯ последовательность событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенной бизнес цели.

Эти два определения говорят об одном и том же. Пускай народ выбирает, какой им больше нравится. Даешь демокартию :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Эти два определения говорят об одном и том же.
Вот это самое главное, надо было с этого и начинать  ;D
На самом деле сложный вопрос... Оба определения достаточно неоднозначны... Чувствую, что
как-то недопонимаю авторов, поэтому хочу пару вопросов задать, может хоть для себя проясню что же такое ВИ

2Galogen и BAS
Цитировать
действующего лица, инициирующего эту последовательность
А возможно существование таких ВИ, которые выполняются не потому что некоторый пользователь их инициировал, а в следствии каких-то событий?
Цитировать
чтобы достигнуть определенной бизнес цели
Тоже тонкий момент... Что понимается под бизнес целью?




Цитировать
А возможно существование таких ВИ, которые выполняются не потому что некоторый пользователь их инициировал, а в следствии каких-то событий?
есть, это нечто иное как ВРЕМЯ. Время это тоже возможное действующее лицо. Не уверен на счет того, может ли время появляться на бизнес-уровне, но на системном оно появляется обязательно, посмотри например в Примерах, я там пытался составить модель, заказанную Денисом

Цитировать
Тоже тонкий момент... Что понимается под бизнес целью?
Этот термин восходит к потребностям в ИС именно сферы бизнеса и англоязычной литературе, к управлению.
Думаю это нечто, что следует достичь при реализации бизнеса, система ведь только инструмент, помогающая достичь ее. Например бизнес цель - обслуживание в каждом магазине комании "Классик" должно бы высококачественным и аналогичным. Не важно где этот магазин находится в деревне или крупном городе.
Правда в этом вопросе все-таки я не очень силен, послушаем что ответят другие



Я перескажу Коберна: он предлагает вводить актера таймер  (или планировщик ОС) для периодических событий. Время все же слишком расплывчатое определение, к тому же у него нет цели.
Я бы ещё рассуждал так - таймер - это объект, а время - это абстрактное понятие. Абстрактное понятие не вступает во взаимодействие и не имеет целей.
Цитировать
Про бизнес-цели согласен - ИМХО это цель бизнеса в целом (предприятия, организации) в противовес цели конкретного действующего лица.
Ну не знаю, не знаю. Я предпочитаю бизнес-цели тоже сопоставлять конкретным людям, представляющим интересы организации, как они их понимают. Потому как у организации самой по себе целей скорее всего нет, кроме традиционных термодинамических или эгрегорных - минимизация внутренней энергии, сохранение равновесия или максимальное расширение.



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



Изучаю ВИ, ибо пишу статью для сайта про пользовательские требования => про ВИ.

Цитировать
Вариант использования, прецедент, use case - конечная НЕДЕЛИМАЯ последовательность событий, возникающих в системе для удовлетворения потребности действующего лица, инициирующего эту последовательность.

т.е. это Конечный Неделимый набор событий в системе (внутри системы)?

Не конечный и неделимый набор взаимодействий между пользователем и системой для удовлетворения потребности действующего лица?

Цитировать
Вариант использования, прецедент, use case - это конечная НЕДЕЛИМАЯ последовательность событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенной бизнес цели.

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

Ваше мнение?




Вообще нужно понимать так: вариант использование это соглашение об использовании системы:-)

А вообще думаю последнее определение более верно, кроме достижения бизнес-цели. Просто цели, а вот уровень цели определятеся типов ВИ: бизнес-ВИ, ВИ уровня цели, системный ВИ.

Я думаю тут надо следовать классикам Коберну и Рамбо с друзьями.



Большой разницы м/у этими определениями нет. Лучше звучит последнее, но "бизнес" надо убрать, оставить -просто "цели" или "его цели".
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



<...>
Это определние мне нравится больше,но я бы сказал: как Пользователь должен взаимодействовать с системой...
Как пользователь работает и где ему нужна система - это бизнес-UC.
Как пользователю предлагается работать с системой - это системные UC.
А пользователь ничего не должен. Это система - должна.



Вариант использования, прецедент, use case - это конечная НЕДЕЛИМАЯ последовательность событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенной бизнес цели.

В этих определениях мне не нравиться:
последовательность событий (так как имхо последовательность указывает на что за чем, а это уже не use case).



В этих определениях мне не нравиться:
последовательность событий (так как имхо последовательность указывает на что за чем, а это уже не use case).
предложите свое определение use case, если Вам не нравится слово последовательность.

вариант использования описывает взаимодействия. Взаимодействия есть последовательность или набор возможных последовательностей (Алистер Коберн)



'последовательность', лично у меня ассоциируется с наличием фактора 'нечто следует за другим' (а для этого есть другое в uml2), имхо лучше 'множество'.



'последовательность', лично у меня ассоциируется с наличием фактора 'нечто следует за другим' (а для этого есть другое в uml2), имхо лучше 'множество'.
Григорий, не могли бы Вы дать определение множества? Запамятовал что-то



Григорий, не могли бы Вы дать определение множества? Запамятовал что-то

погуглите :)




 

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