Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Pavel_T от 15 Декабря 2008, 12:06:07
-
Добрый день!
Я начинающий аналитик.
Активно изучаю методики анализа требований, вникаю в эту область.
И одновременно работаю аналитиком на проекте.
Мне попал в руки документ, якобы ТЗ...
В нем присутствует таблица со сценариями.
Выглядит это таким образом:
Функция: Подключение услуги
Сценарий:
1. PPPt получает запрос от NT на регистрацию услуги KLH.
2. В случае если получен запрос на регистрацию услуги пользователю, ранее не зарегистрированному в PPPt, то производится регистрация профайла пользователя и выдается системное предупреждение об автоматической регистрации.
3. При получении запроса на регистрацию услуги пользователю, уже имеющему эту услугу формируется документированное предупреждение системы. Повторная регистрация не производится.
4. PPPt в профайле зарегистрированного пользователя регистрирует запись о подписке на услугу с указанием даты регистрации, после чего обработка прекращается.
Уважаемые эксперты. Поправьте меня пожалуйста...
1. Актером здесь выступает система, внешняя (далее во всем ТЗ именно так). Имеет ли смысл оформлять все в таком виде и дальше, с рисованием юзкейс диаграмм?
2. Очень хочется использовать для такого описания какой-то иной документ, возможно архитектурный или системный (подскажите какой?). Прав ли я? Или оставить все в ТЗ? Просто мне привычнее видеть ТЗ в виде функций, которые удовлетворяют требования пользователя, а здесь - сторонняя система удовлетворяет требования системы.
3. Этот документ (это ТЗ) используется разработчиками как первоисточник, актуальный и понятный по функциям. Может имело бы смысл оформлять не юзкейс диаграммы, а какие-либо другие типы диаграмм, для подобного описания (см. выше 4 пункта)?
Вобщем... большая путаница. :(
-
Павел,
Немного сумбурно и не все понятно. Во первых - кто такие PPPt и NT?
Во-вторых, если у Вас ТЗ на интеграцию, то ее ни в коем случае не надо описывать в виде ВИ. Лучше это описать в виде ф-ций, как и описано, но внутренности этих ф-ций можно описать в виде сценария (последовательности действий). Для понимания можно оформить еще Д Взаимодействия, где компоненты будут Системы и показать движение потоков Данных.
теперь по вопросам:
1. См. выше
2. Не вижу проблем написать ТЗ на интеграцию
3. см. выше.
-
Во первых - кто такие PPPt и NT?
PPPt - разрабатываемая Система, на которую пишется ТЗ.
NT - сторонняя Система.
Во-вторых, если у Вас ТЗ на интеграцию, то ее ни в коем случае не надо описывать в виде ВИ.
Хм. На интеграцию? Данная разработка направлена на внедрение разрабатываемой Системы в уже существующую систему (это телеком). То есть разрабатываемая Система использует другие части большой системы.
Подскажите, это интеграция? ???
Лучше это описать в виде ф-ций, как и описано, но внутренности этих ф-ций можно описать в виде сценария (последовательности действий).
Предствленное выше описание, я попытался переложить таким образом:
Функция: Подключение услуги
Основной сценарий
1. Система получает запрос от NT на регистрацию услуги. Формат запроса приведен в Приложении 2.
2. Система проверяет регистрацию пользователя (наличие профайла пользователя в Системе).
3. Система проверяет наличие у пользователя услуги.
4. Система в профайле пользователя регистрирует услугу с указанием даты регистрации.
5. Сценарий завершен.
Альтернативные сценарии
Альтернатива 2.1
1. Система обнаружила, что пользователь не зарегистрирован (отсутствует профайл абонента).
2. В Системе формируется сообщение об автоматической регистрации пользователя.
3. Производится регистрация пользователя.
4. Возврат в п.3 основного сценария.
Альтернатива 2.2
1. Система обнаружила, что пользователь уже подписан на услугу.
2. В Системе формируется формируется сообщение о наличии услуги у пользователя.
3. Сценарий завершен.
Я на правильном пути? ???
Для понимания можно оформить еще Д Взаимодействия, где компоненты будут Системы и показать движение потоков Данных.
Можете показать пример, как это выглядит? ???
А то я нарисовал Актера (в виде сторонней системы NT и овал юзкейса, соединив стрелкой :(
-
1. Интеграция - это взаимодействие ИС (или их частей) между собой
2. Можно и так описывать внутренность ф-ций, только не называйте их ВИ :)
замечания по потокам:
из п. 2 не понятно что Система находит Пользователя. Т.е. надо так и писать - Система находит зарегистрированного Пользователя по параметрам Запроса. А в 2.1. писать: "Система обнаружила, что Пользователь не зарегистрирован (отсутствует профайл абонента)."
в. п.3. можно написать исключение прямо в этом п., например, "Система проверяет наличие у Пользователя Услуги. Если Услуга не найдена, то сценарий продолжается. Если услуга найдена, то Системе формирует сообщение о наличии услуги у пользователя и сценарий завершается."
3. Пример см. ниже. Вместо Данных можно писать название ф-ий.
-
PPPt - разрабатываемая Система, на которую пишется ТЗ.
NT - сторонняя Система.
Хм. На интеграцию? Данная разработка направлена на внедрение разрабатываемой Системы в уже существующую систему (это телеком). То есть разрабатываемая Система использует другие части большой системы.
Подскажите, это интеграция? ???
Предствленное выше описание, я попытался переложить таким образом:
Функция: Подключение услуги
Основной сценарий
1. Система получает запрос от NT на регистрацию услуги. Формат запроса приведен в Приложении 2.
Use case должен начинаться с действий основного действующего лица, инициирующего процесс. Т.е. с действий NT
2. Система проверяет регистрацию пользователя (наличие профайла пользователя в Системе).
3. Система проверяет наличие у пользователя услуги.
4. Система в профайле пользователя регистрирует услугу с указанием даты регистрации.
5. Сценарий завершен.
Здесь нет диалога, тут монолог. Действует разрабатываемая система, действий внешних систем нет.
Альтернативные сценарии
Альтернатива 2.1
1. Система обнаружила, что пользователь не зарегистрирован (отсутствует профайл абонента).
2. В Системе формируется сообщение об автоматической регистрации пользователя.
3. Производится регистрация пользователя.
4. Возврат в п.3 основного сценария.
Альтернатива 2.2
1. Система обнаружила, что пользователь уже подписан на услугу.
2. В Системе формируется формируется сообщение о наличии услуги у пользователя.
3. Сценарий завершен.[/i]
Опять монолог, нет ДИАЛОГА, неясны действия внешних систем-акторов
-
Эд,
Если ты прочитал внимательно наш разговор с Павлом, то я сказал, что можно описывать ф-ции Системы в виде сценария, но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ.
-
Здесь нет диалога, тут монолог.
Опять монолог, нет ДИАЛОГА, неясны действия внешних систем-акторов
В этом то и дело :( Пришел запрос от NT в нашу Систему и она там чего-то сама ворочает (регестрирует, сохраняет, изменяет).
Что посоветуете в таком случае?
...но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ
Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"?
-
Эд,
Если ты прочитал внимательно наш разговор с Павлом, то я сказал, что можно описывать ф-ции Системы в виде сценария, но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ.
Прости, Саша, не понял выпада?
Я просто человеку пытался указать на ошибки. А ВИ тут писать можно и даже может быть нужно...
-
Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"
К "сценарию" я притензий не имею :) Посмотрите мою презентацию по новому походу в описании ПТ:
Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ (http://www.uml2.ru/index.php?option=com_content&task=view&id=159&Itemid=64).
Можно в похожем ключе описывать и ФТ.
-
В этом то и дело :( Пришел запрос от NT в нашу Систему и она там чего-то сама ворочает (регестрирует, сохраняет, изменяет).
Что посоветуете в таком случае?
Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"?
Мне кажется ненужно относиться слишком серьезно к форме. Главное содержание и то, что Вы пытаетесь донести до разработчика(архитектора, проектировщика). Если у вас в компании развита культура UML, то значит есть старшие товарищи, которые помогут. Если нет, то скорее всего вам просто и легко никого не удивить и не убедить. Потому можно пойти по принципу: правильно применяем концепцию, а там сами поймете подходит или нет все это в к вам.
Мне кажется у вас подойдет простое описание алгоритма, нечто вроде DFD, диаграммы деятельности. В общем как САША уже сказал ;)
Но и ВИ вполне можно родить...
-
Но и ВИ вполне можно родить...
Еще раз повторюсь, что для интеграционных задач ВИ лучше не рожать ;)
-
It depends on..
Даю справку: рожать, родить- от слова род (правило проверки, поставить гласную под ударение)
Двоечник :P :-* ::)
-
Прежде всего, спасибо за ответы!
Посмотрите мою презентацию по новому походу в описании ПТ:
Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ.
Имеете ввиду вот это - "Пользовательские Сценарии как лучший способ описания Пользовательских Требований"?
Есть вопросы... не совсем понял... Дело в том, что пользовательских требований по сути нет в документе. Есть уже сразу фукции, со сценарием их реалицации.
Просто меня переклинивает, когда в разделе "Функциональные требования" присутствует "Сценарии работы с системой". Мне казалось - либо то, либо то :(
Мне кажется у вас подойдет простое описание алгоритма, нечто вроде DFD, диаграммы деятельности.
DFD - это что? Простите... а где можно посмотреть это? Это уже не будет ТЗ?
-
DFD - это что? Простите... а где можно посмотреть это?
http://unesco.kemsu.ru/study_work/method/po/dfd_idef3.pdf
-
Не нужно париться ... назовите это сценариями, и вы будете избавлены от формальных требований к юзкейсам. Диаграммы юзкейсов вам тут не помогут. Сценарии можно спокойно иллюстрировать collaboration диаграммами.
-
Не нужно париться ... назовите это сценариями, и вы будете избавлены от формальных требований к юзкейсам. Диаграммы юзкейсов вам тут не помогут. Сценарии можно спокойно иллюстрировать collaboration диаграммами.
Спасибо.
Простите, а что в моем случае (сценарий приведен выше) будет в качестве "прямоугольничков" в такой диаграмме?
-
Простите, а что в моем случае (сценарий приведен выше) будет в качестве "прямоугольничков" в такой диаграмме?
Вот что:
PPPt - разрабатываемая Система, на которую пишется ТЗ.
NT - сторонняя Система.
Или их подсистемы.
-
Диаграммы юзкейсов вам тут не помогут
Скажите, почему?
Просто, компетентные товарищи (на работе) к существующим сценариям рекомендовали нарисовать юзкейс-диаграммы. Даже если это будет "NT--->Овал с вписанной функцией".
Можете аргументировать несостоятельность такого визуального отображения? Точнее, я сам понимаю, что "диаграмма мало о чем говорит"... но ... хочется выслушать экспертов.
Вот что:Или их подсистемы.
Оно и понятно, но не совсем понятно, как между NT и PPPt нарисовать все то, что описано в сценарии? Получается, стрелочка с запросом от NT к PPPt... а дальше система ворочается сама в себе :(
-
Павел, правильно ли я понимаю, что внешняя система NT выступает в роли черного ящика, и Вы имеет в наличии только форматы передаваемых сообщений (описание интерфейса)?
В данном случае внешняя система может выступать как инициатор определенных действия, которые вы описали в виде сценария.
Моем мнение (коллеги могут не согласится :)):
1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.
2. Опишите алгоритмы обработки входящих сообщений и алгоритмы формирования исходящих сообщений.
Алгоритмы можно описать с помощью сценария (что вы и сделали) или с помощью диаграммы деятельности (если не знаете компоненты) или диаграммы последовательности/коммуникации (если известны компоненты - как показал выше Александр.). Называть это вариантом использования не совсем правильно, а вот алгоритмом или функцией наверное можно.
3. Рекомендую также подготовить список данных, которые "живут" в системе - Сущности и их параметры
4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.
Таким образом у вас будет общая картина взаимодействия двух систем, алгоритмы обработки (функции) и участвующие данные.
-
В общем пока писал, Виталий высказал мою мысль длиннее :)
Хочу только добавить про ВИ:
Аргументация лежит в книге Коберна "Современные методы описания функциональных требований к системам" (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=65).
Можно еще почитать ФАК по ВИ (http://www.uml2.ru/index.php?option=com_content&task=category§ionid=3&id=31&Itemid=47).
А вообще главная аргументация в том, что ВИ - это ЦЕЛЬ Пользователя по отношению к Системе. ВИ отражают ПОЛЬЗОВАТЕЛЬСКИЕ требования, а при взаимодействии м\у ИС - какие ПТ?
Но в нынешней эконом. ситуации лучше не спорить с "компетентные товарищи (на работе)" :)
-
Господа, прощу прощения!
Речь о передаче данных пока не идет. Представлен простейший сценарий:
Функция: Подключение услуги
Основной сценарий
1. Система получает запрос от NT на регистрацию услуги. Формат запроса приведен в Приложении 2.
2. Система проверяет регистрацию пользователя (наличие профайла пользователя в Системе).
3. Система проверяет наличие у пользователя услуги.
4. Система в профайле пользователя регистрирует услугу с указанием даты регистрации.
5. Сценарий завершен.
Альтернативные сценарии
Альтернатива 2.1
1. Система обнаружила, что пользователь не зарегистрирован (отсутствует профайл абонента).
2. В Системе формируется сообщение об автоматической регистрации пользователя.
3. Производится регистрация пользователя.
4. Возврат в п.3 основного сценария.
Альтернатива 2.2
1. Система обнаружила, что пользователь уже подписан на услугу.
2. В Системе формируется формируется сообщение о наличии услуги у пользователя.
3. Сценарий завершен.
"Система" - это наша разрабатываемая система.
"NT" - сторонняя система, которая инициирует запрос (то есть наша Система его принимает и начинает шуршать внутри себя).
:(
-
Павел,
ИМХО Вам уже все расписали как делать, это мы так уже упражняемся.
-
DFD - это что? Простите... а где можно посмотреть это? Это уже не будет ТЗ?
:o
-
:o
Эд, человек ведь новичок. Чего так удивляешься? Я, например, тоже никогда еще в жизни не использовал DFD в практике :)
-
Виталий Григораш
Мое мнение (коллеги могут не согласится ):...
Спасибо. Есть вопросы:
1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.
Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?
2. Опишите алгоритмы обработки входящих сообщений и алгоритмы формирования исходящих сообщений.
Алгоритмы можно описать с помощью сценария (что вы и сделали) или с помощью диаграммы деятельности (если не знаете компоненты)
То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?
(http://pic.ipicture.ru/uploads/081217/thumbs/QDqVt13WAT.png) (http://ipicture.ru/Gallery/Viewfull/10416095.html)
Было так:
(http://pic.ipicture.ru/uploads/081217/thumbs/3STr0pNwiq.png) (http://ipicture.ru/Gallery/Viewfull/10416117.html)
...
4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.
Судя по сценарию, там только запрос приходит от NT... и все. ???
-
Павел,
Вот теперь сравните две ваши диаграммы (ДВИ и Д Взаимодействия (или контекстную в данном случае)), какая несет больше пользы и дает наилучшее представление?
-
Павел,
Вот теперь сравните две ваши диаграммы (ДВИ и Д Взаимодействия (или контекстную в данном случае)), какая несет больше пользы и дает наилучшее представление?
Д Взаимодействия мне нравится больше.
Но ... на ней отображен поток, под названием сценария "Подключение услуги X" (он же - функция).
А как на этой же диаграмме отобразить шаги сценария?
Или без дополнительного обозначения компонентов Системы никак?
-
А как на этой же диаграмме отобразить шаги сценария?
А как на ДВИ "отобразить шаги сценария"??? Правильно - никак.
Поэтому шаги либо описываем текстом либо в виде Д Действий (поддиаграмма, раскрывающая смысл ф-ции или сценария или потока "Подключение услуги X") как сказал Виталий. Но в вашем случае текст рулит однозначно.
-
Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?
Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?
То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?
Диаграмма деятельности это activity (на ней обычно компоненты не показываются) - блок-схема
Диаграмма взамодействия - sequence
Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче
-
Эд, человек ведь новичок. Чего так удивляешься? Я, например, тоже никогда еще в жизни не использовал DFD в практике :)
Странно, публиковал ответ, а его не вижу. Я удивляюсь не незнанию человека, а нашему образованию. Это же классика!
Очень совету посмотреть сюда: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_19
-
Странно, публиковал ответ, а его не вижу. Я удивляюсь не незнанию человека, а нашему образованию. Это же классика!
А чему удивляться? Для меня, например, что DFD, что ДНД - всё едино.
Диаграмма деятельности, диаграмма потоков данных - это запоминаемо. А аббревиатуры и иностранные слова я, например, запоминаю с трудом - нет ассоциаций, не за что зацепиться.
Вот я уже раз двадцать заглядывал в словарь, чтобы вспомнить, что такое BPMS. И опять забыл.
А такие сокращения как IDEF0, IDEF1 и т. д. вообще придумали злобные извращенцы. ;)
-
Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?
В некоторых случаях в NT возвращается ответ с ошибкой. А так, в основном от NT запросы идут (они же и активируют наши функции в Системе, чтобы она там сама ворочалась).
Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче
Спасибо!
Итак, collaboration - она же "коммуникации", "она же контекстная", "она же Д взаимодействия". Я прав?
И я натыкаюсь вот на такие collaboration диаграммы:
(http://pic.ipicture.ru/uploads/081218/thumbs/gU7OBV8NGY.jpg) (http://ipicture.ru/Gallery/Viewfull/10451440.html)
И еще вопрос. В попавшемся мне ТЗ, по наследству, были обнаружены в приложении экранные снимки скриншотов, то есть, вроде как покрываются требования к GUI.
Для меня опять это не привычно (работал очень много с ГОСТ).
Подскажите пожалуйста, насколько правомерно размещать такую информацию сразу в ТЗ? Может стоит выныести в отдельный документ и существует ли такой?
Спасибо!
Очень совету посмотреть сюда: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_19
Спасибо!
Заглянул. С английским пока туго, ибо "еще учусь". Точнее "перевожу со словарем" :(
-
В некоторых случаях в NT возвращается ответ с ошибкой. А так, в основном от NT запросы идут (они же и активируют наши функции в Системе, чтобы она там сама ворочалась).
Ну можно показать не только сообщение в вашу ИС, но и ответ (например, ошибку с соответствующим комментарием)
В вашем конкретном случае (когда идет один запрос) в Д я не вижу смысла.
Итак, collaboration - она же "коммуникации", "она же контекстная", "она же Д взаимодействия". Я прав?
Контекстная Д это не то же самое что collaboration. collaboration=Контекстная Д, когда у Вас показана ваша и др. ИС без внутренностей.
И я натыкаюсь вот на такие collaboration диаграммы:
Простите, где натыкаетесь??
И еще вопрос. В попавшемся мне ТЗ, по наследству, были обнаружены в приложении экранные снимки скриншотов, то есть, вроде как покрываются требования к GUI.
Для меня опять это не привычно (работал очень много с ГОСТ).
Подскажите пожалуйста, насколько правомерно размещать такую информацию сразу в ТЗ? Может стоит выныести в отдельный документ и существует ли такой?
GUI в ТЗ могут быть, а могут не быть. Ничего предосудительно в этом нет, это как Вам удобнее, мне с GUI удобнее.
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.
-
В вашем конкретном случае (когда идет один запрос) в Д я не вижу смысла.
Смысл, я полагаю, в том, что человек (разработчик, заказчик), читая пункт, с названием функционального требования "Подключение услуги X" глазом упирается в картинку, где видны участники процесса.
Простите, где натыкаетесь??
Повсюду, в интернете. А это не правильный пример? Или... в чем подвох?
...
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.
Спасибо. В разделе "Функциональные требования" не стоит запихивать подразделом "Требования к GUI"? Это уже не есть "ФТ", правильно?
-
1. Вам виднее, если нужно так делайте, серебряной пули нет.
2. Подвоха нет, просто не понял эту часть Вашего поста.
3. Правильно, "Требования к GUI" - это НЕ "ФТ"
-
2. Подвоха нет, просто не понял эту часть Вашего поста.
А... просто привел другую, отличающуюся от Вашего примера диаграмму.
Вы привели:
(http://pic.ipicture.ru/uploads/081218/thumbs/01G6W535Zm.jpg) (http://ipicture.ru/Gallery/Viewfull/10455162.html)
А я "натыкаюсь" на:
(http://pic.ipicture.ru/uploads/081218/thumbs/gU7OBV8NGY.jpg) (http://ipicture.ru/Gallery/Viewfull/10451440.html)
-
Павел, это диаграммы одного типа диаграмма коммуникации. На первой используются значки стереотипов и она более абстрактная, чем вторая.
На второй показаны сообщения которые передаются между классами, а на первой нет, тк сообщения я показал на диаграмме последовательности. Все зависит от стиля моделирования.
-
замечания по потокам:
из п. 2 не понятно что Система находит Пользователя. Т.е. надо так и писать - Система находит зарегистрированного Пользователя по параметрам Запроса. А в 2.1. писать: "Система обнаружила, что Пользователь не зарегистрирован (отсутствует профайл абонента)."
в. п.3. можно написать исключение прямо в этом п., например, "Система проверяет наличие у Пользователя Услуги. Если Услуга не найдена, то сценарий продолжается. Если услуга найдена, то Системе формирует сообщение о наличии услуги у пользователя и сценарий завершается."
Спасибо.
То есть альтернативу засовываем в основной поток? Простите, а что тогда "спускать" в альтернативу? И в каких случаях?
Хочется понять... научиться.
-
То есть альтернативу засовываем в основной поток? Простите, а что тогда "спускать" в альтернативу? И в каких случаях?
Хочется понять... научиться.
Альтернативу МОЖНО засунуть в основной поток, если она не большая (1-2 пункта) и встречается 1 раз в осн потоке, тем самым получается более полный взгляд и не надо все время сверяться где же она наступила.
-
Еще раз повторюсь, что для интеграционных задач ВИ лучше не рожать ;)
Почему?
Ты сам сказал выше, что интеграционные задачи касаются взаимодействия 2-х и более систем. А use cases как раз и были придуманы для выявления и хранения требований к интерактивным, а не трансформационным системам.
-
Ты сам сказал выше, что интеграционные задачи касаются взаимодействия 2-х и более систем. А use cases как раз и были придуманы для выявления и хранения требований к интерактивным, а не трансформационным системам.
П.ч. наша ИС не может быть изображена на ДВИ как актер. Т.е. в лучшем случае получим одного Актера (внешняя ИС) и куча ВИ, кот. не будут являться ВИ по сути, и такая Д не даст никакой ценности.
-
П.ч. наша ИС не может быть изображена на ДВИ как актер. Т.е. в лучшем случае получим одного Актера (внешняя ИС) и куча ВИ, кот. не будут являться ВИ по сути, и такая Д не даст никакой ценности.
Да почему наша ИС не может быть актором? Где это написано и какой в этом смысл?
-
То есть на ДВИ это, конечно, изобразить трудно. Но разве ДВИ это панацея? ИМХО, всего лишь один из методов кластеризации пользовательских требований.
Получается, вопрос такой: если ВИ нельзя разместить на ДВИ, то он не имеет права на существование? Или это просто терминологическая проблема, и его всего лишь не нужно называть вариантом использования (хотя бы вслух ;))?
-
П.ч. наша ИС не может быть изображена на ДВИ как актер. Т.е. в лучшем случае получим одного Актера (внешняя ИС) и куча ВИ, кот. не будут являться ВИ по сути, и такая Д не даст никакой ценности.
Вообще-то может для этого использоваться суррогатный Агент, типа Таймера или Демона.
-
Аааааааааааааааааааааааааааааааааа, товарищи,
Ну зачем придумывать Демонов каких-то??? Ну сами говорите, что ВИ - это ПТ, и что ВИ - это цель, а при описании Тр. к интеграции в лучшем случае получаем ФТ и Задачи.
Зачем использовать инструмент не по назначению? Ну можно же молотком (ВИ описывать Инегр. Тр.) колоть орехи, если Вы не знаете других способов, но только часть из них выживит, почему бы для этого не использовать специальные щипцы (например, Д Взаимодействия и словесное описание ФТ) ?
-
Ну зачем придумывать Демонов каких-то??? Ну сами говорите, что ВИ - это ПТ, и что ВИ - это цель, а при описании Тр. к интеграции в лучшем случае получаем ФТ и Задачи.
Зачем использовать инструмент не по назначению? Ну можно же молотком (ВИ описывать Инегр. Тр.) колоть орехи, если Вы не знаете других способов, но только часть из них выживит, почему бы для этого не использовать специальные щипцы (например, Д Взаимодействия и словесное описание ФТ) ?
Вариант использования описывает последовательность взаимодействия. Это очень мощный инструмент для анализа требований, их описания и последующего тестирования (а также, как показывает опыт, для разработки пользовательской документации). Почему его нельзя использовать там, где есть взаимодействие?
В нашей практике ВИ идеально подходят, например, для описания взаимодействия приложения терминала ("наша система") с банковским хостом ("внешняя система").
Есть основной сценарий, есть альтернативы, есть начальные условия, есть целевые и минимальные гарантии. Одинаково понятно и разработчику, и заказчику, и тестировщику. То есть выглядит как ВИ и используется как ВИ.
А если что-то выглядит как утка, крякает как утка, плавает как утка и летает как утка, но не укладывается в концепцию "диаграммы уток" - то как его следует называть?
Я допускаю, конечно, что я просто чего-то не знаю. Так дай ссылочку - попробую разобраться, в чём я не прав.
-
Для размышления.
Пример из книги UML2 b унифицированный процесс Арлоу и Нейшдатда
стр. 452 русского издания раздел 20.5
Рассматривается проектирование вариантов использования для системы безопасности.
Акторами там являются некий SecurityGuard, Fire(Пожар) и Intruder(Взломщик)
и рассамтриваются ВИ - деактивация системы, Активациявсего, АктивацияСигналапоПожару и какойто триггерсенсор
система безопасности встроеная работает в автоматическом режиме
-
Аааааааааааааааааааааааааааааааааа, товарищи,
Ну зачем придумывать Демонов каких-то???
Кто сказал придумывать? На того, кто инициирует интеграционное взаимодействие – на того и вешаем, если Админ – то на Админа, если cron – то на cron'а (Отличая его от Системы как Таймер либо не отличая). В последнем случае это будет чисто Технический Способ Применения (Системный Вариант Использования).
Ну сами говорите, что ВИ - это ПТ, и что ВИ - это цель, а при описании Тр. к интеграции в лучшем случае получаем ФТ и Задачи.
Обновить, скажем, срез куба продаж за последние сутки – вполне себе Цель, связанная с реализацией интересов определённых Заинтересованных Лиц. Про только ФТ и Задачи – когда мы, например, моделировали Гарантированную Доставку для выгрузки Документов Дня Банка в отдельный Архив, мы вполне себе получили полноценный набор сценариев взаимодействия, с ожиданием подтверждения доставки и исключениями. Ещё раз – если интеграционная задача простейшая, не вариативная, т.е. не требующая учёта реакции агента, с которым она взаимодействует, например, генерация RSS или отправка фрагмента данных по почте – то да, можно попытаться обойтись без сценариев, хотя это только основной поток будет вырожденным до 1-2 шагов, а исключения всё равно лучше сценарными методами описывать.
Зачем использовать инструмент не по назначению? Ну можно же молотком (ВИ описывать Инегр. Тр.) колоть орехи, если Вы не знаете других способов, но только часть из них выживит, почему бы для этого не использовать специальные щипцы (например, Д Взаимодействия и словесное описание ФТ) ?
А с чего ты решил, что не по назначению? Чем "словесное описание" лучше набора сценариев? Д взаимодействия, как и любая Д, всегда носит вспомогательный характер и не может быть исчерпывающей.
-
Для размышления.
Пример из книги UML2 b унифицированный процесс Арлоу и Нейшдатда
стр. 452 русского издания раздел 20.5
Рассматривается проектирование вариантов использования для системы безопасности.
Акторами там являются некий SecurityGuard, Fire(Пожар) и Intruder(Взломщик)
и рассамтриваются ВИ - деактивация системы, Активациявсего, АктивацияСигналапоПожару и какойто триггерсенсор
система безопасности встроеная работает в автоматическом режиме
Эд, ну встроенное ПО здесь не совсем в кассу, т.к. мы всё-таки про интеграцию. Хотя как пример того, что Способ Применения "Сообщать об инциденте" инициируется отнюдь не Взломщиком и не Огнём – это хорошо.
Ещё хороший пример – отработка любого триггера в БД, например, Журналирование Операций в независимую специализированную систему из, скажем, АБС. Понятно, что запись отдельной операции при взаимодействии с другой системой может пройти более или менее удачно, для описания чего прекрасно подойдут сценацрии, а Агентом будет либо АБС, либо Демон Журналирования (на ваш выбор, меня вполне устроит АБС).
-
Интересно посмотреть на определения Use Case в интернет.
Первое определение - из Википедии. Именно такой трактовки, насколько я понимаю, придерживается BAS:
A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system.
Остальные определения, насколько я понял, содержатся в глоссариях различных проектов. Здесь трактовки более широкие, не настолько однозначные. Но интересны тем, что взяты из не учебников, а из реальной практики.
Use case is a sequence of actions that an actor (a person, external entity or another system) performs within a system to achieve a particular goal. Or from inside out, a use case is a sequence of actions a system executes that yield observable results of value to a particular actor.
http://costg9.plan.aau.dk/Bremen2001/Rados/RadosGlossary.htm
Use case describes, from a user’s perspective, a behaviourally related set of transactions that are normally performed together to produce some value for the user. Use cases may be modelled at varying degrees of abstraction, essential use cases, the most abstract, are technologically and implementation independent whereas real use cases describe how the use case actually operates in a particular environment.
http://highered.mcgraw-hill.com/sites/0077110005/student_view0/glossary.html
A use case is a description of how end-users will use a software code. It describes a task or a series of tasks that users will accomplish using the software, and includes the responses of the software to user actions. Use cases may be included in the Software Requirements Document (SRD) as a way of specifying the end-users' expected use of the software.
http://mydocs.epri.com/docs/SDRWeb/processguide/glossary.html
A specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of action initiated by an actor, and it specifies the interaction that takes place between an actor and the system. The collected use cases specify all the existing ways of using the system.
http://www.iram.fr/~lucas/almassr/SSR-UC-Glossary.html
A Use Case is a series of steps an actor performs on a system to achieve a goal. Actors are "objects" of any type, such as people, parts or other systems.
Следующее определение интересно тем, что помещено почему-то в описание типов данных. Оно самое короткое, но вполне выражает суть.
use case — type of interaction between a system and its environment.
Ну и у тестировщиков, как всегда, свой взгляд на вещи. :)
Use Case
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.
http://mavericsys.blogspot.com/2007/11/software-testing-dictionary.html
-
Ну что еще можно сказать :)
Нравится Вам описывать требования к интеграции через ВИ - описывайте. Никто Вам запретить не может.
ИМХО у нас получилась путаница, Вы говорите, что Тр. хорошо описывать в виде сценария, я с этим не спорю и даже поддерживаю, но только поэтому Вы назваете эти сценария ВИ, с чем я не согласен.
З.Ы. Гриша, показательно, что у тя нет ни одной цитаты от Коберна :)
-
Ну что еще можно сказать :)
Нравится Вам описывать требования к интеграции через ВИ - описывайте. Никто Вам запретить не может.
ИМХО у нас получилась путаница, Вы говорите, что Тр. хорошо описывать в виде сценария, я с этим не спорю и даже поддерживаю, но только поэтому Вы назваете эти сценария ВИ, с чем я не согласен.
Ну, собственно, я с самого начала об этом и говорил. Есть сценарий, обладающий всеми признаками варианта использования, но его почему-то нельзя называть вариантом использования.
Понимаешь, как мне кажется, ты исходишь из некоторого идеального подхода к проектированию, к которому надо стремиться: сначала определить пользователей, потом определить перечень варинтов, потом эти варианты разработать и реализовать. У меня же ситуация такая: есть текстовые сценарии, описывающие и реакцию приложения на действия пользователей, и динамику взаимодействия этого приложения с другими системами (не люблю слово "система", оно слишком ко многому обязывает). Эти сценарии, как я уже отмечал, удовлетворяют всех участников процесса разработки - заказчика, программиста, тестировщика, разработчика документации.
Нужно ли мне искусственно разбивать их на "варианты использования" и "сценарии" только на том основании, что первые инициируются пользователями, а вторые - самим приложением? С точки зрения теории, наверное, можно (хотя меня до сих пор никто окончательно не убедил). С точки зрения практики применения это только внесёт лишнюю путаницу.
Эта ситуация, кстати, должна быть довольно распространённой для терминальных приложений (или других "тонких клиентов"), у которых всегда есть два конца: на одном конце пользователь, а на другом - внешняя система, с которой нужно взаимодействовать. При этом в нашем случае, например, интересы большого числа заинтересованных лиц уже реализованы во внешней системе, а терминал должен отработать свои сценарии так, чтобы их не нарушить. Поэтому мы тратим гораздо больше сил и средств на отработку взаимодействий с внешними системами (включая длительные и дорогостоящие сертификации), чем на разработку пользовательских интерфейсов.
-
З.Ы. Гриша, показательно, что у тя нет ни одной цитаты от Коберна :)
Мы говорим "usecase", подразумеваем Коберна, мы говорим "Коберн", подразумеваем usecase. ;)
-
Нужно ли мне искусственно разбивать их на "варианты использования" и "сценарии" только на том основании, что первые инициируются пользователями, а вторые - самим приложением? С точки зрения теории, наверное, можно (хотя меня до сих пор никто окончательно не убедил). С точки зрения практики применения это только внесёт лишнюю путаницу.
Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).
-
Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).
ИМХО, ВИ - это часть системы (я имею ввиду системный уровень - более детальный), поэтому лучше все таки выделять акторов. Я например знаю следующие типы акторов:
1. Время (Таймер) - всегда за границами системы (среда)
2. Событие (Обработчик событий) - В одном ВИ завершилось действие, обработчик событий выявил его и инициировал новый ВИ. Я обычно такого актора не ввожу, а описываю события как предусловия в ВИ или подпотоками одного ВИ.
3. Девайс (Датчик) - например, датчик пожара, сообщает системе что начался пожар, датчик дождя сообщает системе о дожде и в машине начинают работать дворники и тд и тп. Причем датчик может мониторить не внешнюю среду но и состояние системы (обработчик событий - частный случай такого датчика)
4. Внешняя система - посылает инициирующее сообщение
5. Пользователь - инициирует какой-либо ВИ руками, через GUI или какой-нибудь скрипт
Один из способов структуризации модели ВИ - в пакеты по акторам. Чтобы отделить пользовательские от других, можно сгруппировать их таким образом.
-
Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).
Тогда уж разделять ВИ на Пользовательские и уровня подфункции.
-
Сценарии, назовите ЭТО сценариями и делайте ВСЕ ЧТО ХОТИТЕ!
Рисуйте себе статику и динамику КАК УГОДНО -- дерево функций в виде иерархической диаграммы, Взаимодействие, activity ... богатейший арсенал в распоряжении. Зачем рисовать диаграмму ВИ обязательно???? Просто чтобы buzzword использовать?
-
Сценарии, назовите ЭТО сценариями и делайте ВСЕ ЧТО ХОТИТЕ!
Рисуйте себе статику и динамику КАК УГОДНО -- дерево функций в виде иерархической диаграммы, Взаимодействие, activity ... богатейший арсенал в распоряжении. Зачем рисовать диаграмму ВИ обязательно???? Просто чтобы buzzword использовать?
Я скажу по секрету: диаграммы ВИ я вообще не рисовал. До сих пор такой необходимости не возникало.
А вот сами... хм... сценарии мы более-менее освоили.
-
Урааааааааааааааа, Сценарии - вот так я соглашусь :)
-
GUI в ТЗ могут быть, а могут не быть. Ничего предосудительно в этом нет, это как Вам удобнее, мне с GUI удобнее.
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.
Я всегда рассматривал ТЗ, как некое описание того, что "должно" (каким-либо образом) быть реализовано в Системе.
А "как это уже реализовано" (или "as is") - это уже был не ТЗ. Это уже был другой документ.
Так вот, готовые снимки экранных форм - это уже (по идее) - "as is".
Насколько правильно их размещать в ТЗ?
Поясните пожалуйста. Или я недопонимаю чего-то.
PS. То же самое касается описания функций (функциональных требований), точнее глубина их детализации.
К примеру: "Система производит переотправку сообщений с интервалом отправки, заданным параметром "Таймер переотправки"".
То есть в примере указано уже конкретное название таймера. Насколько это правильно в ТЗ? Насколько правомерно?
-
Господа!
(из топика "Вариант использования или..." перейду сюда)
Вот, я попытался изобразить схему, в которую вплетена наша Система и действия которой (функции) необходимо описать в сценариях (или ВИ или еще каким то образом).
(http://pic.ipicture.ru/uploads/081225/thumbs/9qYRs2GtbV.jpg) (http://ipicture.ru/Gallery/Viewfull/10751381.html)
На рисунке NNNt - наша Система. NT - это единственный Actor видимый нашей системой.
Как видно, никаких пользователей нашей Системе не видно.
Ваши комментарии? ???
-
Я всегда рассматривал ТЗ, как некое описание того, что "должно" (каким-либо образом) быть реализовано в Системе.
А "как это уже реализовано" (или "as is") - это уже был не ТЗ. Это уже был другой документ.
Так вот, готовые снимки экранных форм - это уже (по идее) - "as is".
Насколько правильно их размещать в ТЗ?
Открою Вам секрет, что GUI могут также проектировать и рисоваться в визуальном редакторе до разработке. Только имеет смысл проектировать только сложные GUI. А "as is" - это скорее Руководство Пользователя :)
PS. То же самое касается описания функций (функциональных требований), точнее глубина их детализации.
К примеру: "Система производит переотправку сообщений с интервалом отправки, заданным параметром "Таймер переотправки"".
То есть в примере указано уже конкретное название таймера. Насколько это правильно в ТЗ? Насколько правомерно?
Не совсем понял как это "То же самое касается описания функций". Что тоже самое??
Как я понял "Таймер переотправки" - это параметр, а не сам таймер. В ТЗ естественно нужно избегать деталей реализации и писать - "ЧТО должна делать ИС", а не "КАК". Но в ТЗ может и присутствовать детали реализации, все зависит от конкретного случая и квалификации Аналитика и Программиста.
-
(из топика "Вариант использования или..." перейду сюда)
Зачем гадить в чужой топик?? ИМХО Ваш вопрос не имеет ничего общего с топиком, в который Вы его поместили.
Вот, я попытался изобразить схему, в которую вплетена наша Система и действия которой (функции) необходимо описать в сценариях (или ВИ или еще каким то образом).
Ваши комментарии? ???
Ну вот эта Д более информативная. Теперь надо назвать связи и расписать взаимодействие внутри связи.
-
Зачем гадить в чужой топик?? ИМХО Ваш вопрос не имеет ничего общего с топиком, в который Вы его поместили.
Ну вот эта Д более информативная. Теперь надо назвать связи и расписать взаимодействие внутри связи.
Простите! Вы меня не поняли.
В моей диаграмме красным прямоугольником выделено два действующих "лица": 1 - Actor и 2 - наш черный ящик.
Все то, что находится дальше, включая двух пользователей (выделены в виде рисунков Actor - чисто условно) не должно нас волновать да и не волнует.
Мы только получаем сигналы от одной системы и шлем ей свои сигналы. А дальше - трава не расти!
Так вот, получается куцая диаграмма с двумя блоками и кучей стрелочек между ними. Поскольку в сценарии не учавствуют все те, кто "за красной линией".
-
Павел,
Мы говорим об описании одного сообщения! Ну что Вы хотите от Д еще? Что Вы вообще к ней привязались-то?? :)
Тут лучше чем текстом не опишешь требования.