Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Виталий Григораш от 16 Декабря 2008, 15:57:37
-
Очередное обсуждение ВИ пошло отсюда:
http://www.uml2.ru/forum/index.php?topic=1078.msg11331#msg11331
А вообще главная аргументация в том, что ВИ - это ЦЕЛЬ Пользователя по отношению к Системе. ВИ отражают ПОЛЬЗОВАТЕЛЬСКИЕ требования, а при взаимодействии м\у ИС - какие ПТ?
Но в нынешней эконом. ситуации лучше не спорить с "компетентные товарищи (на работе)" :)
Саша, исходя из определения ВИ - это цель актора, а актор может быть пользователем, девайсом или внешней системой.
Дело здесь скорее всего в том, что обычно ПОЛЬЗОВАТЕЛЬ является инициатором ВИ (caller), а внешняя система вспомогательным актором (callee). В таком случае никаких противоречий нет и все вроде бы укладывается в "цели пользователя". А как быть со случаем, когда внешняя система является инициатором (caller)? У этой системы есть "своя цель" и про нее мы тоже не должны забывать. Или данный случай уже не относится к ВИ и является требованиями к интеграции?
-
А вообще главная аргументация в том, что ВИ - это ЦЕЛЬ Пользователя по отношению к Системе. ВИ отражают ПОЛЬЗОВАТЕЛЬСКИЕ требования, а при взаимодействии м\у ИС - какие ПТ?
А как же Коберн, ВИ "Гайки и болты" (варианты 13-17)? Я выпал из контекста?
В нашем случае, например, ВИ оказываются очень удобными для описания взаимодействия терминала с различными хостами и внешними устройствами (сценарий обмена данными с чиповой картой, например). Почему нельзя называть эти сценарии вариантами использования?
-
По классике:
1. ВИ - это ПТ. Так? Требования по интеграции это ПТ?
2. ВИ - это цель Эктора. У ИС не может быть целей, максимум что у них есть - это задачи и они могут выступать только как вспомогательные Экторы (callee)
3. ВИ наилучшим способом описывают ПТ при работе бизнес (интерактивного) приложения.
Это опять же по классике и если ограничиваться уровнем целей Пользователя (по Коберну) и не лезть в глубь до подфункций....
-
2. ВИ - это цель Эктора. У ИС не может быть целей, максимум что у них есть - это задачи и они могут выступать только как вспомогательные Экторы (callee)
Саша, рассмотрим ситуацию: Пользователь внешней системы инициирует какую-то операцию и внешняя система обращается к нашей системе. Мы не знаем, как во внешней системе и что происходит, но мы знаем, что она посылает нам инициирующее сообщение. Мы его обрабатываем и "выплевываем" ответ. По-твоему внешняя система в данном случае не может быть актором? Ведь в данном случае она не является callee.
Вспомни твой пример по продавца конфет и покупателя. У каждого своя цель!!! Цель актора. Цель пользователя, я считаю, это частный случай цели актора. Возможно я не прав, объясните пожалуйста в чем моя не правота.
-
Хотел написать про нестандартные ситуации (Главный Эктор - таймер, внешняя система и т.д.), но лень было ...
Если ИС большая, то наверное имеет смысл сделать отдельный ВИ под интеграцию ("Внешняя Система" ---> "Передать данные"), которорый в виде сценария будет описывать передачу верхоуровневых сообщений\данных, а далее их (сообщения) детализировать уже в ФТ.
Но если у нас на Д будет один Эктор ("Внешняя Система") и один ВИ ("Передать данные"), как в описываемом случае, то никакой пользы от это Д не будет.
-
...то наверное имеет смысл сделать отдельный ВИ под интеграцию ("Внешняя Система" ---> "Передать данные"), которорый в виде сценария будет описывать передачу верхоуровневых сообщений\данных, а далее их (сообщения) детализировать уже в ФТ.
Пример с проекта. Внешняя система посылает сообщение в нашу систему о начале налоговой проверки. Наша система, получив это сообщение, используя данные нашей системы, формирует специальный отчет, который в дальнейшем могут просматривать пользователи. Те получается, что в данном случае инициирует создание отчета внешняя система, а смотрят отчет пользователи. Я сделал 2 ВИ - Внеш. система --> Сформировать отчет, Пользователь --> Просмотреть отчет
Я прав?
-
Виталий,
ИМХО ты не прав. Нужен один ВИ - "Сформировать (или просмотреть) отчет по НУ", с двумя экторами - Внеш. система и Пользователь.
Ну нет же цели просто сформировать отчет, а цель именно его посмотреть. Так?
З.Ы. Начав читать, думал, ща ИС начнет тереть данные и все такое :)
-
....Нужен один ВИ - "Сформировать (или просмотреть) отчет по НУ", с двумя пользователями - Внеш. система, Просмотреть отчет.
Ну нет же цели просто сформировать отчет, а цель именно его посмотреть. Так?
Наверное ты хотел сказать..."с двумя пользователями - Внеш. система, Пользователь"?
С ВИ могут быть соединены 2 Актора только в том случае, если один из них caller, а другой callee. Два инициирующих актора к одному ВИ - это ошибка. В данном случае и Пользователь и система являются caller, тк начинают ВИ. Как объединить их в один не представляю. Если бы был один актор? то можно сделать CRUD.
PS Давай куда нибудь перенесем дискуссию и еще по обсуждаем? :)
-
Ну почему два? Инциатором как раз будет "Внеш. система". Пример сценария примерно такой:
1. Внешняя Система передает сообщение о начале налоговой проверке. Формат сообщения описан ...
2. Система получает данное сообщение и начинает действия по подготовке внутреннего отчета для нал проверке. Детально описание процедуры формирования см. ...
3. После формирования отчета Система сохраняет отчет и он становится доступен для Пользователя в любое время до его удаления или след. налоговой проверки.
4. В любой момент Пользователь заходит в Систему и вызывает операцию "Показать отчет по нал. проверке".
5. Система отображает последний сохраненный отчет по нал проверке.
6. пп.4-5 повторяются по инициации Пользователя до удаления очтета или наступления следующей налоговой проверки (формирования нового отчета).
Описав таким образом мы получаем:
1. Достяжение действительно нужной цели Пользователя (Посмотреть отчет), а не его подзадачи (Сформировать отчет)
2. Получаем полную картину по формированию и отображению Отчета.
-
Да не плохо вроде. Вот только мне не очень нравится "в любой момент Пользователь может...". Обычно системный вариант использования описывает один сеанс работы с системой (если несколько подходов, то это уже больше похоже на кусок бизнес-процесса или некоторое описание последовательности вызова вариантов использования (такое тоже встречается :))). Именно поэтому я их и разделил...
ЗЫ Ранее я не встречал примеров вариантов использования с двумя активными акторами.
-
Наверное ты хотел сказать..."с двумя пользователями - Внеш. система, Пользователь"?
С ВИ могут быть соединены 2 Актора только в том случае, если один из них caller, а другой callee. Два инициирующих актора к одному ВИ - это ошибка.
Рассмотрим такой вариант. Чтобы открыть дверь, два человека в разных местах должны поднести свои карты к ридерам. При этом один из них дополнительно аутентифицируется по сетчатке глаза, а другой вводит код с клавиатуры.
Как будет выглядеть ВИ с одним актором?
-
Виталий,
Вроде ничего плохого не вижу с т.з. здравого смысла, все лаконично и понятно. К ВИ надо в первую очередь подходить с т.з. здравого смысла, получая от него наибольшую выгоду при описании, естественно учитывая все ограничения :)
Гриша,
Полностью с тобой согласен в последнем посту :)
-
Рассмотрим такой вариант. Чтобы открыть дверь, два человека в разных местах должны поднести свои карты к ридерам. При этом один из них дополнительно аутентифицируется по сетчатке глаза, а другой вводит код с клавиатуры.
Как будет выглядеть ВИ с одним актором?
Как один ВИ с простым ветвлением
или как один ВИ с альтернативой
Или как два ВИ причем один из ВИ есть расширение первого
Один ВИ открыть дверь, другой аутифицироваться
Реально никто не хочет войти в дверь - народ хочет
а - попасть в здание (комнату) - в этом случае нужна аутентификация (к примеру)
б - покинуть здание (комнату) - аутентификация не нужна (к примеру)
т.е. после размышления имеем три варианта использования системы:
Войти в здание
Выйти из здания
Аутентификация как отдельный под ВИ, который может иметь и самостоятельно значение
-
Как один ВИ с простым ветвлением
или как один ВИ с альтернативой
Или как два ВИ причем один из ВИ есть расширение первого
Один ВИ открыть дверь, другой аутифицироваться
Реально никто не хочет войти в дверь - народ хочет
а - попасть в здание (комнату) - в этом случае нужна аутентификация (к примеру)
б - покинуть здание (комнату) - аутентификация не нужна (к примеру)
т.е. после размышления имеем три варианта использования системы:
Войти в здание
Выйти из здания
Аутентификация как отдельный под ВИ, который может иметь и самостоятельно значение
А зачем мне все эти сложности - два ВИ вместо одного или один ВИ с ветвлением, если в процедуре изначально участвуют два человека, и система должна взаимодействовать с обоими? Кому это облегчит жизнь?
-
А зачем мне все эти сложности - два ВИ вместо одного или один ВИ с ветвлением, если в процедуре изначально участвуют два человека, и система должна взаимодействовать с обоими? Кому это облегчит жизнь?
Т.е. два человеа подходят к двери и одновременно пытаются зайти в эту дверь?
Я не говорю, что надо усложнять. И потом почему усложнять, это не усложнение, а анализ, который позволяет усмотреть все нюансы в случае чего.
Весь сразу возникает вопрос, почему нужно иметь некую карту для прохода, зачем еще идентифицировать сетчатку, а набор кода заменяте считывание сетчатки или определяется формой допуска. А в каком случае нужно сетчатку считывать и почему другой набирает просто код на клавиатуре?
Ведь по сути мы описываем не факт открытия двери, а факт допуск.
ВИ полезны тогда когда - есть разные пользователи и роли, есть много интерфейсов,
Иначе если система описывается через ограничения (нефункциональные требования) то не используем ВИ - они вредны.
Тут я вижу некое взаимодействие и достаточно сложное с устройством
-
Т.е. два человеа подходят к двери и одновременно пытаются зайти в эту дверь?
Ну, представь, например, что нужно не дверь открыть, а дать команду, скажем, на старт ракеты. Участники находятся в разных углах помещения, чтобы один человек не мог одновременно воспользоваться двумя картами. Один из них - авторизованное лицо из списка (поэтому проверяется по сетчатке глаза), а другой - дежурный офицер (система с ним заранее "не знакома", но у него есть доступ к кодам запуска).
Это я фантазирую, конечно.
По-моему, если вариант использования позволяет компактно описать требуемое поведение системы так, чтобы оно было однозначно (в смысле, одинаково) воспринято закзачиком, разработчиком и тестировщиком, то это хороший ВИ.
Пример с дверью (или ракетой), конечно, несколько надуман, но в нём есть два очевидных участника, равноправных с точки зрения системы. Нельзя сказать, что кто-то один их них инициирует процедуру. Они должны одновременно поднести карты к ридерам. Но "одновременно" - это с точки зрения человека, конечно, в реальности запросы в систему придут последовательно, и система должна воспринимать их в любом порядке.
Если представить себе реализацию, то система должна ждать любого их двух событий - запрос с ридера 1 или запрос с ридера 2. После обработки обоих запросов она снова должна ждать двух событий в любом порядке. Если ещё остался соблазн использовать ветвления "для красоты", то можно добавить ещё парочку событий - экспоненциальный рост количества комбинаций в конце концов убедит кого угодно. :)
Я что хочу сказать. Я не вижу необходимости в каких-либо жёстких ограничениях по числу действующих лиц (хотя признаю разумные ограничения по заранее достигнутому соглашению). Тот же Коберн даёт только рекомендации (и сам, кстати, постоянно это подчёркивает). Очень хорошие рекомендации, и их можно считать "классикой", но не догмы. И выражения "нельзя использовать" или "ни в коем случае" применительно к описаниям требований считаю, как минимум, спорными, пока не будут представлены исчерпывающие доказательства и объяснения, почему именно нельзя.
-
Да, насчёт сетчатки это я, конечно, загнул.
Наверное, всё-таки по радужной оболочке. :)
-
Рассмотрим такой вариант. Чтобы открыть дверь, два человека в разных местах должны поднести свои карты к ридерам. При этом один из них дополнительно аутентифицируется по сетчатке глаза, а другой вводит код с клавиатуры.
Как будет выглядеть ВИ с одним актором?
Это будет один ВИ "Получить доступ в помещение", например. Где пользователь будет подносить карту, затем вводить свои данные (глаз или код или еще что-нибудь) и получать доступ. Способы получения доступа можно описать отдельно. Соглашусь с Эдом - могут быть альтернативные потоки.
А вот инстанса ВИ в данном примере будет 2:
Первый - когда Петя (первый инстанс актора) подставляет глаз и происходит проверка его глаза :) (выполняется сценарий 1)
Второй - когда Вася (второй инстанс актора) вводит код и происходит проверка кода (выполняется сценарий 2).
То что одновременно должны выполняться 2 инстанса - это ограничение (бизнес-правило, так сказать). Согласитесь, что можно придумать и 1 и 3 и 4 и хоть групповую идентификацию? В данном случае просто система будет ждать заданное количество времени (например 1 секунду) и если за это время не придет запрос со второй карты, то "до свидания"
Вопрос здесь именно в том, кому как удобно и для чего применяют ВИ. Я пишу системные варианты использования, довольно подробно описывая все действия пользователя и большое количество альтернативных потоков и эксепшинов, так как по ним сразу кодят разработчики и пишут тест кейсы тестеры (RUP, ICONIX).
Как говорится о вкусах не спорят ;)
-
И выражения "нельзя использовать" или "ни в коем случае" применительно к описаниям требований считаю, как минимум, спорными, пока не будут представлены исчерпывающие доказательства и объяснения, почему именно нельзя.
Ничего подобное мною не было озвучено кроме тгго, что ВИ должен инициироваться извне. Т.е. первый шаг всегда за актором. Даже если актор событие времени.
В нашем случае два основных лица, но кто-то всегда первый инициирует процесс. В результате имеем две альтернативы. Если первый инициирует процесс- сценарий идет так, другой иницирует процесс - сценарий идет иначе.
Если задача предсталяет собой сложную систему точек принятия решений - так это конечный автомат, таблица решений, дерево решений. Ясно что в этом случае ВИ не очень подходит. Разве что только для задания контекста, то есть закрепления понимания цели - запуск ракеты, открытия двери.
-
А вот интересно как будет выгладить пример ДВИ по варианту Boatman?!
С двумя или с тремя Актерами??