Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 20 Декабря 2006, 19:33:36
-
Решил создать данную тему, именно, здесь, т.к. она по смыслу подходит в этот раздел.
Я уже обсуждал вопрос о ВИ (варианте использовании или прецеденте), правда в другой ветке. (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), имхо лучше 'множество'.
Григорий, не могли бы Вы дать определение множества? Запамятовал что-то
-
Григорий, не могли бы Вы дать определение множества? Запамятовал что-то
погуглите :)
-
Ха! Множества... А вот кто может сходу дать математическое определение графа, а, аналитики? А ведь весь UML, по сути, сводится к набору графов.
-
множеством считается любой чётко определенный набор объектов (элементов множества)
А множество у меня ассоциируется с набором объектов (событый), в любой последовательности, что не верно.
-
То есть говорит, что мне это "не нравиться" - Вам не сложно.
А сказать по существу, влом?
Хорошо: множество неупорядоченная совокупность отличных друг от друга однотипных элементов. - Это математическое определение, определение для программиста.
В рамках наивной теории множеств множеством считается любой чётко определенный набор объектов (элементов множества).
Каким боком это подходит понятию use case? Множество описывающих его слов или символов? Или множество действий - одинаковых по типу? А какому типу? Если же это некое множество сценариев - тут я соглашусь, но тогда, а что есть сценарий?
A scenario (from Italian, that which is pinned to the scenery) is a synthetic description of an event or series of actions and events.
series I ['sI(q)ri:z] n (pl без измен.)
1. ряд (тж. мат.)
a series of years [of events, of victories] — ряд лет [событий, побед]
a series of brilliant statesmen — плеяда блестящих государственных деятелей
infinite series — бесконечный ряд
binomial series — мат. биномиальный ряд
in series — по порядку; последовательно
time series — временной ряд (в статистике)
2. серия, выпуск; комплект; группа
in a series of 40 lessons — выпусками по 40 уроков
the men of letters series — серия «великие писатели»
to complete [to conclude] a series — закончить [завершить] серию
3. геол. свита; отдел, система
4. кино, тлв. многосерийный фильм, в котором каждая серия составляет законченный эпизод
series II ['sI(q)ri:z] a эл.
последовательный
series connection — последовательное соединение
series winding — последовательная /сериесная/ обмотка сети
-
Ха! Множества... А вот кто может сходу дать математическое определение графа, а, аналитики? А ведь весь UML, по сути, сводится к набору графов.
А это надо?? Это мне напоминает вопрос при приеме программиста на работу - скажите все параметры ф-ции Жава для парсинга XML
-
То есть говорит, что мне это "не нравиться" - Вам не сложно.
А сказать по существу, влом?
Эд, не надо нападать на человека, а то получится как у нас на форуме с логотипом :)
-
Ха! Множества... А вот кто может сходу дать математическое определение графа, а, аналитики? А ведь весь UML, по сути, сводится к набору графов.
граф (в математике) — объект, состоящий из вершин и соединяющих их ребер.
граф (в программировании) — это совокупность узлов и ребер, соединяющих эти узлы. Объектные графы обеспечивают простой способ учета взаимных связей в множестве объектов, и не обязательно, чтобы эти связи в точности проецировались в классические связки объектно-ориентированного программирования (такие как отношения старшинства и подчиненности), хотя они моделируют эту парадигму достаточно хорошо. Каждому объекту в объектном графе назначается уникальное числовое значение. Следует иметь в виду, что эти числовые значения, приписываемые членам в объектном графе, произвольны и не имеют никакого смысла вне графа. После назначения всем объектам числового значения объектный граф может начать запись множества зависимостей каждого объекта.
Обыкновенным графом называется пара G=(V,E) , где V - конечное множество, E - множество неупорядоченных пар различных элементов из V . Элементы множества V называются вершинами графа, элементы множества E - его ребрами.
Слегка модифицируя это определение, можно получить определения других типов графов без кратных ребер: если заменить слово "неупорядоченных" словом "упорядоченных", получится определение ориентированного графа без петель, если убрать слово "различных", получится определение графа с петлями. Ориентированный граф часто называют орграфом.
-
Григорий,
А не могли бы представить ваше ПОЛНОЕ определение ВИ?
-
Эд, не надо нападать на человека, а то получится как у нас на форуме с логотипом :)
Где это, я нападаю? Я спорю, дискутирую, доказываю, спрашиваю.
Просто Григорий делает утверждение, но его не обосновывает. Может он заблуждается, но может и прав. Я и прошу его высказать точку зрения и свои аргументы.
-
граф (в математике) — объект, состоящий из вершин и соединяющих их ребер.
С третьего курса помню: "граф - это совокупность множества с заданным на нём бинарным отношением". :)
-
1. То есть говорит, что мне это "не нравиться" - Вам не сложно.
2. А сказать по существу, влом?
1. да, не сложно и я пояснил почему
2. а хамство для вас норма?
to: 'А множество у меня ассоциируется с набором объектов (событый), в любой последовательности, что не верно.'
ваше право, для указания на последовательность я использую sequence diagram, например.
-
Григорий,
А не могли бы представить ваше ПОЛНОЕ определение ВИ?
-
Чего вообще зацепились словами-то?
Ещё в первом посте галогена была цитата: "Прецедент описывает множество последовательностей..."
-
Ну, если пошла такая пьянка, то ДВИ - это граф?
-
А не могли бы представить ваше ПОЛНОЕ определение ВИ?
Из моего раннего поста следует, что ваше определение (см. цитату в первом моем посте топика) для меня приемлемо, за исключением 'последовательность' и я уже предложил свой вариант 'множество'; и пожалуй, множественность бизнес целей, так как они могут быть различны для различных Актеров.
итого:
Вариант использования, прецедент, use case - это конечная НЕДЕЛИМАЯ множество событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенных бизнес целей.
-
Ну, если пошла такая пьянка, то ДВИ - это граф?
Разговор напоминает анекдот с диалогом с покупателем в аптеке про свечи - "а вы что, их ели!!??"
-
итого:
Вариант использования, прецедент, use case - это конечная НЕДЕЛИМАЯ множество событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенных бизнес целей.
Григорий, давайте сначала - когда вы последний раз писали use case?
-
Чего вообще зацепились словами-то?
Ещё в первом посте галогена была цитата: "Прецедент описывает множество последовательностей..."
А за что еще цепляться-то? Только за слова и можно.
дык "множество последовательностей", тем более когда это было, давно уже раскритиковали.
-
Разговор напоминает анекдот с диалогом с покупателем в аптеке про свечи - "а вы что, их ели!!??"
+1 :)
-
дык "множество последовательностей", тем более когда это было, давно уже раскритиковали.
Где раскритиковали? Не нашёл. Вижу только, что после него пошли альтернативные, ошибочные определения про только "множество" или только "последовательность".
-
не ну согласись "множество последовательностей" не равно "множеству".
конечно можно пойти по пути определения множество сценариев, который есть суть поток событий, последовательность событий.
можно высказаться так - множество (или набор, что кстати используется в англоязычной литературе) экземпляров варианта использования
http://epf.eclipse.org/wikis/openupru/ Use Case:Концепция
Вариант использования
Экземпляр вариант использования описывает последовательность действий, выполняемых системой, которая приводит к заметному результату, представляющему ценность для отдельного действующего лица. В этом определении можно выделить несколько ключевых понятий:
Экземпляр варианта использования
Вариант использования может следовать по почти неограниченному, но счетному, количеству путей (вполне может подойти к понятию множество путей, а путь предполагает последовательность). Эти пути представляют альтернативы, раскрывающиеся при описание потоков событий варианта использования. Выбор того или иного пути зависит от событий
-
ваше право, для указания на последовательность я использую sequence diagram, например.
sequence diagram описывает один сценарий или, если хотите, экземпляр варианта использования: успешный поток, ответвления от успешного или основного потока, исключения, альтернативные потоки
-
ваше право, для указания на последовательность я использую sequence diagram, например.
А что, используя sequence diagram невозможно описать реализацию варианта использования?
-
sequence diagram описывает один сценарий или ...
да, пожалуй я ошибочно предположил, что идет речь о use case diagram
-
да, пожалуй я ошибочно предположил, что идет речь о use case diagram
Да, конечно, имея в виду диаграмму прецедентов, можно сказать что имеем набор, множество прецедентов, описывающих взаимодействие с системой