Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: базука от 13 Сентября 2011, 16:15:55
-
Недавно я обдумывала документ об образе и границах системы и нашла, что сопроводить описание основных функций будущей системы диаграммой использования будет удобно и наглядно. Смущает то, что в диаграмму попадают функции, которые будут присутствовать в системе, и это важно явно обозначить заранее, но при этом сами по себе эти функции чисто служебные, которые я обычно в отдельные UC не выделяю.
Пример. Допустим, мы описываем образ и границы некоего приложения на мобильном устройстве, которое будет позволять вводить данные двумя способами - фотографируя и распознавая значение, и с клавиатуры. Затем эти данные будут передаваться в основную БД. Ниже приведена диаграмма использования.
Считаете ли вы корректным выделение в отдельные UC таких функций, как "сохранение данных", "удаление данных" и "авторизация"? Если нет, то как бы вы составили диаграмму использования без потери информативности?
-
Уже 100 раз говорили о том, что ДВИ не имеет смысла без описания сценариев. Все на ДВИ не отобразишь - будет каша.
Как вариант: ДВИ+описание каждого ВИ на несколько строк о его назначении.
-
Уже 100 раз говорили о том, что ДВИ не имеет смысла без описания сценариев. Все на ДВИ не отобразишь - будет каша.
Как вариант: ДВИ+описание каждого ВИ на несколько строк о его назначении.
А кто говорит о ДВИ без описания сценариев? Я написала, что
нашла, что сопроводить описание основных функций будущей системы диаграммой использования будет удобно и наглядно.
Для всех: если можно, прошу давать ответы не общетеоретические, а касательно конкретной приведенной диаграммы.
-
На мой взгляд, диаграмма в корне не верная, т.к. здесь перемешаны и действия, выполняемые системой, и пользовательские цели.
На мой взгляд, цель у пользователя одна - "Ввести данные" (да и то - цель ли это?). Это обобщающий ВИ. Его частными случаями будут: "Ручной ввод данных" и "Ввод через фотографирование". А ВИ "Ввести данные" включает "Авторизацию".
Действия с данными (CRUD) лучше не описывать.
В итоге должно получиться что-то подобное (см. рисунок во вложении).
-
базука, то что вы изобразили на диаграмме - это не варианты использования.
Это овальчики в рамке с человечком за ее пределами. Это может быть похоже на что угодно. Например, DFD диаграмма, но это не ДВИ.
Почему:
1. все кто пользуются пользователи. Поэтому от того, что я вижу на вашей картинке Пользователя это не прибавляет мне понимания требований к системе.
2. из диаграамы я могу понять что система МобильнаяСуперПупер должна уметь(позволять) ручной ввод данных, ввод данных через фотографирование, сохранение данных в каком-то МТ, авторизацию в системе, передачу данных в некую БД, включая удаление сохраненных данных из МТ. Но это никак не сообщает мне о том ЗАЧЕМ ВСЕ ЭТО ДЕЛАЕТСЯ И ДЛЯ КОГО
3. Т.е. эта диаграмма может быть концепцией решения, иллюстрацией при разговоре с программистом, но скорее всего не функциональными требованиями к системе от лица его возможных пользователей - опять же непонятно для кого и зачем
4. если убрать слово расход и таинственное МТ, то подобная диаграмма подойдет пожалуй к любому приложению баз данных
-
1. все кто пользуются пользователи.
А что с этим не так? Если предусмотрена единственная роль в системе.
2. из диаграамы я могу понять что система МобильнаяСуперПупер должна уметь(позволять) ручной ввод данных, ввод данных через фотографирование, сохранение данных в каком-то МТ, авторизацию в системе, передачу данных в некую БД, включая удаление сохраненных данных из МТ.
Я стремилась именно к тому, чтобы проиллюстрировать этой диаграммой предполагаемый функционал будущей системы.
Но это никак не сообщает мне о том ЗАЧЕМ ВСЕ ЭТО ДЕЛАЕТСЯ И ДЛЯ КОГО
Да, верно. "Зачем и для кого" описывается в прочих разделах документа. Или вы хотите сказать, что все это должно быть ясно из диаграммы? А первый отвечавший высказался, что ДВИ без описания сценариев не имеет смысла. )
-
На мой взгляд, диаграмма в корне не верная, т.к. здесь перемешаны и действия, выполняемые системой, и пользовательские цели.
Вот это и меня смущает.
А ВИ "Ввести данные" включает "Авторизацию".
По замыслу ввод данных и сохранение их в МТ возможно без авторизации. Авторизация нужна лишь для передачи данных в основную базу.
Убрать передачу данных как системную функцию с диаграммы верно только если она происходит автоматически, а не инициируется пользователем. Допустим, инициируется. Что вы можете тогда сказать о ВИ "удаление данных", корректно ли тогда его присутствие?
-
Улучшенная версия.
-
Улучшенная версия.
Мне кажется, ввести данные о расходе это нормально, а Сфотографировать или ввести с клавиатуры что-то не то.
Для чего их объединять? выделять общую часть, каков смысл? Разве я не могу просто сфотографировать объект данных? разве операция фотогравирования должна непременно вводить данные о расходе? Разве процесс фотографирования и ввода данных о расходе нельзя явно отделить?
Я бы выделил ВИ Сфотографировать объект данных, Распознать объект данных, Передать данные в хранилище
Опишите пожалуйста кратко идею ВИ ввести данные о расходе с клавиатуры
Опишите пожалуйста кратко идею ВИ ввести данные о расходе фотографированием
Опишите пожалуйста кратко идею ВИ передать данные в БД
-
Распознать объект данных
Так это тоже будет системный ВИ. Пользователям то, что система распознает данные, так же интересно, как и то, что она их сохраняет, а после передачи удаляет.
Основная функция приложения на мобильном устройстве - ввод данных о расходах и передача их в основную БД на лицевой счет пользователя. Поэтому фотографирование и ввод с клавиатуры объединены общим UC. Фотографирование лишь способ быстрого ввода данных. А в первой версии диаграммы распознавание было упущено, да.)
-
Так это тоже будет системный ВИ. Пользователям то, что система распознает данные, так же интересно, как и то, что она их сохраняет, а после передачи удаляет.
Что значит будет системный, а Вы какие рассматриваете?
Распознать объект данных - возможно не удачно - я следую вашей терминологии.Вы фотографируете объект, потом система по вашей команде его распознает.
Эти две операции могут быть совершенно самостоятельными и транзакционно завершенными:
сфотали сохранили в хранилище телефона
потом запустили распознавалку, извлекли фотку, распознали, сохранили
Основная функция приложения на мобильном устройстве - ввод данных о расходах и передача их в основную БД на лицевой счет пользователя. Поэтому фотографирование и ввод с клавиатуры объединены общим UC. Фотографирование лишь способ быстрого ввода данных. А в первой версии диаграммы распознавание было упущено, да.)
Я в общем то специально несколько все утрировал.
Какова основная задача или цель использования МУ?
Нечто вроде Занести расход на лицевой счет пользователя - это что за цель? цель пользователя. Зачем это делается - все за кадром. Это и есть системный ВИ, а не бизнес ВИ...
А далее описываем сценарии
1. Выбрать отправку СМС сообщения
2. Указать адрес держателя лицевого счета (утрировано)
3. ввести информацию о расходе
4. отправить сообщение
реакцию системы проигнорировал, но она есть
Или
1. выбрать отправку СМС сообщения
2 Указать адрес держателя лицевого счета (утрировано)
3 выбрать распознанный ранее текст
4 отправить сообщение
ну как-то так...
-
Ответ на вопрос, ради которого я создавала тему, я уже получила. Спасибо ответившим. Не следовало упоминать в документе об образе и границах такие функции, как сохранение и удаление, а потому и в диаграмме их быть тоже не должно.
Что значит будет системный, а Вы какие рассматриваете?
Да, конечно, я неточно выразилась. Я имела в виду действия, совершаемые системой и пользователю малоинтересные, как те же удаление и сохранение данных. Но распознавание я пожалуй в диаграмму включила бы.
Вы фотографируете объект, потом система по вашей команде его распознает. Эти две операции могут быть совершенно самостоятельными и транзакционно завершенными:
сфотали сохранили в хранилище телефона
потом запустили распознавалку, извлекли фотку, распознали, сохранили
Согласна.
Какова основная задача или цель использования МУ?
Нечто вроде Занести расход на лицевой счет пользователя - это что за цель? цель пользователя. Зачем это делается - все за кадром. Это и есть системный ВИ, а не бизнес ВИ...
А если наше приложения для МУ будет частью некой системы учета личных расходов? Допустим, основной функционал уже работает, а этой доработкой для МУ мы его только расширяем. Оптимизируем операцию ввода данных. Ввод и передача данных – основные UC, для нашей доработки они будут уровня БВИ.
Вот так пожалуй должна выглядеть эта диаграмма. Хотя авторизация тоже вызывает сомнения, нужно ли ее тут показывать как отдельный UC.