Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: PavelZh от 16 Августа 2011, 17:40:40
-
Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?
2. На некотором шаге ВИ возможным продолжением для пользователя является запуск другого ВИ (при этом обратно пользователь уже не возвращается). В данном случае я не фиксирую связей на диаграмме прецедентов, а в первоначальном ВИ создаю шаг альтернативного (на самом деле может быть и основным, полагаю) сценария, в котором прописываю "Публикатор иницирует Зарегистрировать ...". Верным ли является данный подход?
3. Наконец, я документирую ВИ используя блок-схемы, а не текстовое описание (при этом я стараюсь следовать стандартам текстовых описаний). Возможен ли такой подход? +/- такого решения, на ваш взгляд?
С терминологией могу немного плавать.
P.s. Вкратце о себе: работаю системным аналитиком 2 года, слежу за сообществом уже давно. Вот, наконец, решил включиться в активное общение.
Если вопросы придутся по душе, попробую задать ещё несколько :)
-
1. Т.к. Коберн принципиально "не видит" диаграммы UML применительно к UC, он использует единственно возможный метод. И очень удачный.
1-3. Если использовать UML: RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram). Если Ваша блок-схема - это диаграмма деятельности UML, то я могу посоветовать, как поступить в каждом из описанных случаев. Если нет - кто же знает, что Вы рисуете?
-
1. За действием "Отмена" могут быть разные алгоритмы. Можно условится, что мы отменяем какое либо запущенное действие. А запущенное действие приводит к достижению результата ВИ.
То есть тут даже не сколько важен факт нажатия кнопки "Отмена", сколько реакция системы после нажатия. Поэтому я бы описал шаги так
3. Система блокирует на счету пользователя нужную сумму
Если пользователь отменил покупку:
4. Система возвращает заблокированную сумму.
Но обычно делаю по другому:
Если пользователь сделал заказ:
3. Система блокирует на счету пользователя нужную сумму
Иначе:
3a. Система возвращает заблокированную сумму.
2. А может ли измениться цель пользователя при прохождении в основном потоке ВИ, чтобы перейти к другому ВИ для завершения потока?
3. Было бы неплохо увидеть пример такого описания, может и мне понравится. Сейчас пользуюсь средством Visual Paradigm оно накладывает ограничение на описание ВИ. Насколько я разобрался там ВИ описываются и как текстовые шаги и как Activity, причем они между собой взаимосвязаны.
PS Коберн вначале книги пишет, что возможен не только такой подход, но и циклограммы, сети Петри или языки программирования. Но рекомендуется использовать текстовое описание, чтобы всем были понятны сценарии ВИ.
-
3. Было бы неплохо увидеть пример такого описания, может и мне понравится. Сейчас пользуюсь средством Visual Paradigm оно накладывает ограничение на описание ВИ. Насколько я разобрался там ВИ описываются и как текстовые шаги и как Activity, причём они между собой взаимосвязаны.
Извините, чуть в сторону.
Мой первый инструмент UML был Paradigm+ от Platinum (ныне, кажется, в составе CA). Это оно?
-
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?
Я понял так, что имеется ввиду отмена всего, сделанного в рабочем потоке UC, Или только последнего действия? Реакция системы (и способ описания) существенно разные!
-
Извините, чуть в сторону.
Мой первый инструмент UML был Paradigm+ от Platinum (ныне, кажется, в составе CA). Это оно?
Нет, это совершенно новый продукт. Восходящая звезда Гонконга. http://visual-paradigm.com
-
Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?
Посмотрите такой вариант (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=47). Пример 5 и 7. Не подойдет?
-
Нет, это совершенно новый продукт. Восходящая звезда Гонконга. http://visual-paradigm.com
Спасибо, Эдуард!
-
Посмотрите такой вариант (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=47). Пример 5 и 7. Не подойдет?
Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC
-
Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC
Но и у Коберна, и в представленном примере, так и есть.
Если ВИ рассматривать как некий протокол взаимодействия актора и системы (а так оно и есть), то описывая разные постусловия, мы указываем возможные состояния системы после исполнения ВИ.
Ясно, что будет некое явное целевое состояние и какие-то побочные. Помните у Коберна - минимальные гарантии успеха. Т.е. что должно быть в самом худшем раскладе.
Отмена исполнения ВИ в процессе его реализации - это по сути откат транзакции, откат к исходному состоянию, к предусловию. Вам нужно это как-то указать. Это некое требование, причем, если вдуматься, негласное требование самого ВИ. Любой ВИ состоит из собственно себя - т.е. цели использования системы актором и описанием варианта использования (UCD - как говорят буржуи, причем эти буржуи всегда проводят грань между UC и UCD). В описании ВИ всегда должен присутствовать типичный сценарий событий. Отмена - тоже вполне типичный, но все-таки альтернативный сценарий. При этом словами с помощью описания это можно сделать очень просто, а графически изображать - надумаешься.
-
1-3. Если использовать UML: RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram). Если Ваша блок-схема - это диаграмма деятельности UML, то я могу посоветовать, как поступить в каждом из описанных случаев. Если нет - кто же знает, что Вы рисуете?
Гм. Попробую сформулировать свое понимание диаграмм деятельности. Поправляйте.
С помощью диаграммы деятельности удобно моделировать поведение системы: порядок выполнения действий/ операций. Еще можно, используя эти диаграммы, описать порядок выполнения ВИ.
С другой стороны, ВИ - как игра в настольный теннис. Здесь есть последовательные действия системы и действия актора. Поэтому затрудняюсь ответить: являются ли мои блок- схемы - диграммой деятельности.
Я постараюсь в ближайшее время показать каким образом выглядит мое описание ВИ. Тогда можно будет более детально оценить, покритиковать:)
-
3. Наконец, я документирую ВИ используя блок-схемы, а не текстовое описание (при этом я стараюсь следовать стандартам текстовых описаний). Возможен ли такой подход? +/- такого решения, на ваш взгляд?
Павел, Вам уже дал ответ Леонид Борисович, сославшись на такой компетентный источник как RUP, в котором он безусловно дока. Известно, что RUP создан теми же персонажами, которые приложили руку к UML. Отсюда следует, что по сути и то и другое создавалось одновременно.
Я не знаток RUP, т.е. не такой глубокий знаток. И, наверняка, ошибаюсь. Но мне не совсем нравится делать описание варианта использования с помощью диаграмм деятельности.
1. это сложнее (Вы же сами обратились, а подумайте что делать, если последовательность некоторых шагов не важна? Как это изобразить?)
2. это менее понятно окружающим
3. это требует от окружающих тонкого владения концепций UML и диаграммы деятельности в частности
4. это невольно заставляет усложнять описание вариантов использования и затруднять их понимание
5. я не понимаю модели (или механизма) трансформации диаграммы деятельности (правда и текстового описания) в реализацию варианта использования
---Потому все это личный выбор, дело личного опыта и собственной практики, способ, который по душе Вам и которому Вы сумели обучить окружающих (с учетом пунктов 1-4)
PS Знакомство с UML я начал с книги Джозефа Шмуллера (в 2001 году, если не ошибаюсь) в ней предлагался такой подход.
1. вы берете интервью и изображаете основной бизнес-процесс (важную деятельность) с помощью ДД
2. в ходе ее изображения у вас может появится потребность какую-то часть деятельностей свернуть - получите некий параллельный БП
3. обязательно виды деятельностей нужно раскидать по персоналиям - это также позволяит выделить какие-то параллельные БП или деятельности
4. Среди этих видов деятельностей какие-то и будут целью автоматизации
5. они сами по себе или после декомпозиции их на части станут вариантами использования
6. описание ВИ было словесным, но кратким и далее сразу предлагалось переходит к реализации ВИ (аналитической сначала)
-
Отмена - тоже вполне типичный, но все-таки альтернативный сценарий. При этом словами с помощью описания это можно сделать очень просто, а графически изображать - надумаешься.
Это все же не альтернативный, а параллельный сценарий.
Вот вариант:
-
Вот вариант:
Прекрасный вариант, снимаю шляпу.
Можно вопрос? А decision node после деятельности (или действия) Отмена нужен для того, чтобы обеспечить непрерывность правого потока? Какой вопрос задается в этом случае? Почему на ветки альтернативы еще приходится писать слово [cancel]? Смесь русского с английским - это нормально?
-
Я в первом варианте ошибся, спешил.
Если хочешь, нарисую, как перейти безвозвратно к другому UC. Но завтра уже.
-
Смесь русского с английским - это нормально?
Наверное, не очень. В данном случае "cancel" даже не слово, а некий символ, как "ОК".
А вообще, в жизни такой диаграммы для UC быть не может. Некоторые действия отменять нет необходимости. UC описывает последовательность взаимодействий, значит д.б. минимум 2 раздела - Actor и система. Если считать, что запуск UC - одно из предусловий, то первое действие: "Система отображает главное окно UC". В этом окошке где-то справа внизу кнопочка "Cancel". Пока ее нет, ничего отменить нельзя!
Кроме того, в большинстве случаев нужно сохранять сведения о сеансе по различным причинам. Правда, такое указание м.б. в описании действия "Отмена всех действий". Например: "Система сохраняет текущее состояние информации формы ввода." (продажа, прием заказа, для анализа статистики обращений клиентов). "Система готова ..." и т.д.
-
Как я это делаю...Критикуйте!!!
Вводная: речь идет о добавлении товаров в некий каталог.
При этом добавить товар (абстрактный ВИ) - обобщение для ВИ добавить базовую единицу и добавить единицу упаковки, поэтому на одной диаграмме я изображаю 2 ВИ.
В треугольниках - ссылка на бизнес-правила.
-
Если Вам, вашим клиентам и разработчиком понятно, то критиковать нечего. Мне кажется, я понял, что Вы хотели сказать этой иллюстрацией.
Но ...
... это не UML, увы.
Нужно ли изучать и моделировать на UML - это Ваш выбор. Многие обходятся без этого.
-
Если Вам, вашим клиентам и разработчиком понятно, то критиковать нечего. Мне кажется, я понял, что Вы хотели сказать этой иллюстрацией.
Но ...
... это не UML, увы.
Нужно ли изучать и моделировать на UML - это Ваш выбор. Многие обходятся без этого.
lnew, форумчане, тогда ещё вопрос задам: можно ли сказать, что это хорошо описанный ВИ или нет?
В конце концов: конечная цель у меня сделать хорошо свою работу, независимо от того какой стандарт я применяю.
Когда я читал различную литературу, у меня возникла идея вместо текстового описания попробовать что-то подобное. Подобные диаграммы я могу использовать в презентациях для разработчиков, чего не сделаешь с текстовыми описаниями.
-
Дорогой Павел!
Вы бывали, наверное, за границей, или встречали иностранцев на улице. И вы чаще всего понимали друг друга с помощью жестов и т.п.
Так и в данном случае. Если Вас понимают, да еще без дополнительных пояснений - все прекрасно!
Но есть языки. И если Вы владеете языком, которым владеет и Ваш собеседник, все становится существенно проще.
Сегодня наиболее распространенный язык общения в разработке ПО - это UML.
Для того, чтобы рассказывать (описывать) и понимать описания UC, достаточно уметь пользоваться двумя диаграммами: Use Case и Activity.
Ваша иллюстрация заведомо менее понятна и менее информативна.
Потратьте пару часов, найдите в интернете какую нибудь книжку. Это будет много эффективнее, чем обсуждать вашу "кустарную" нотацию.
Помните про Костю, который поступал в литературный институт? На приемном экзамене на вопрос: "Что вы читали Пушкина?" он ответил "Костя не читатель. Костя писатель!".
Только не обижайтесь на меня!
-
Как я это делаю...Критикуйте!!!
Леонид Борисович уже все сказал. Но такой мерзкий у меня характер ;), тоже хочется вставить слово.
Вы спросили понятно ли, можно ли так описывать ВИ и т.п.
Если следовать вашей диаграмме, то, боюсь, многое мне было бы непонятно, а, главное, и неправильно.
Смотрите, если вы используете классическую блок-схему, то и используйте ее правильно.
Овальный прямоугольник в начале и конце - это НАЧАЛО или КОНЕЦ программы или ее законченного участка (функции или процедуры).
Комментарий на классических блок-схемах записывается сбоку, вне фигур в квадратной скобке -[это комментарий
В случае условного перехода используется ромб (Да или Нет)
Параллельности в обычных блок-схемах нет (если я не ошибаюсь)
Теперь по существу UC. Как вы знаете, каждый UC имеет начало и конец, т.е. имеет предусловия и постусловия. Однако вхождение в вариант использование одно-единственное, а вот завершений может быть много. Это правильно. Поскольку это не входы и выходы, а именно точка начала - триггер, и точки завершения - дельта реки идеальная метафора.
Потребность внесения специальных дополнительных комментариев мне представляется избыточным или даже вредным, что же это за описание ВИ лаконичное и понятное, которое на некоторые формулировки (в пределе на каждую) еще будет содержать дополнительную информацию в виде комментариев.
Могу предложить вариант. Поскольку вы хотите быть понятым, можно попробовать действовать так: вы предлагаете диаграмму деятельности как описание ВИ, а я и может кто-то еще делает по ней словесное описание. А потом можно попросить третье лицо по описанию сделать диаграмму и сравнить вашу с полученной :)
-
lnew, книги я, конечно же читаю, но стараюсь анализировать предлагаемые стандарты описания и формировать свой удобный инструмент на основе стандартов, который будет понятен всем. Стандарт UML не является широко используемым в нашей компании, поэтому, повторюсь: главным для меня является корректное формулирование ВИ.
Изначально у меня были проблемы с изображением некоторых моментов на диаграмме. Например, отмены на любом шаге (в текстовом описании такая проблема легко решается). Кроме того, остались проблемы, по которым я формулирую вопросы ниже.
Я сейчас сформирую текстовое описание того, что изображено (просто напишу по картинке) и может быть мы попробуем обсудить его?
Опускаю описание абстрактного прецедента "Добавить товар"
Наименование ВИ: Добавить товар
Краткое описание ...
Участники: ...
Предусловия: ...
Постусловия: ...
Основной сценарий: ...
Альтернативные сценарии: ...
Бизнес-правила: ...
Здесь мы обобщенного опишем процедуру добавления товара (независимо от того штука это или единица упаковки)
Далее будет описание ВИ Добавить базовую единицу и Добавить единицу упаковки. Есть очень хороший пример (когда "чисто" определяется в каких местах наследуется поведение абстрактного ВИ, в каких местах оно переопределяется и т.д.) для реализации таких ВИ, у которых есть обобщенный описанный ВИ. Но сейчас, для упрощения, я просто опишу один из этих ВИ не следуя этим правилам.
Наименование ВИ: Добавить базовую единицу
Краткое описание: Добавление базовых единиц товара в каталог.
Участники: Публикатор.
Предусловия: нет предварительных условий (хотя здесь можно написать, что публикатор успешно авторизовался, но мне кажется это излишним)
Постусловия: товар добавлен и зарегистрирован [Комментарий: см. вопрос дальше]
Основной сценарий:
1. Публикатор запускает действие добавления базовой единицы товара.
2. Система предлагает форму для заполнения данных о товаре.
[Комментарий: Здесь на блок-схеме в пунктирном прямоугольнике значится точка расширения - это означало наличие точки расширения в будущих релизах на этом месте. Т.е. мы бы написали здесь: точка расширения: подменить пустую форму.]
3. Публикатор заполняет данные о товаре.
4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?
Альтернативные сценарии:
3а Публикатор прерывает выполнение сценария.
3а1 Система выдает запрос на сохранение изменений.
3а2 Публикатор подтверждает сохранение изменений. [Комментарий: здесь можно было бы использовать комбинацию Если...иначе]
3а2а Публикатор отклоняет сохранение изменений.
3а2b Публикатор отменяет прерывание выполнения сценария. Возвращается к шагу 2.
4а Публикатор сохраняет товар в черновики.
4а1 Система проверяет товар.
4а2 Система сохраняет товар в черновики. Вопрос: Стоит ли использовать "минимальные гарантии успеха" для того, чтобы зафиксировать, что сохранение в черновики - это тоже частичное выполнение сценария?
4а2а Система выдает публикатору сообщение об ошибке.
4b Публикатор инициирует Добавить упаковку. Вопрос: Здесь у меня возникает проблема: публикатор хочет запустить выполнение другого сценария, но системе предварительно необходимо произвести некоторые действия. Как это можно зафиксировать. При этом, опять же достигается выполнение сохранения товара в черновики, но не главная цель.
-
Извините, Павел.
Я консультант по UML. Если Вы будете использовать UML, я готов Вам помочь.
Нотацию, которую использует один человек во Вселенной, я считаю бесперспективной, по крайней мере, в обозримом будущем. Или Вы должны показать ее преимущество перед существующими.
Я понял, что Вы используете свою нотацию вместо Activity не потому, что она не подходит, а потому, что Вы ее не знаете, или знаете плохо. А учится не хотите. А для аналитика такая ситуация - смерть!
До свидания на новом, более высоком уровне Ваших знаний и желаний!
-
Я понял, что Вы используете свою нотацию вместо Activity не потому, что она не подходит, а потому, что Вы ее не знаете, или знаете плохо. А учится не хотите. А для аналитика такая ситуация - смерть!
Павел, я присоединяюсь к lnew и тоже бесконечно удивлен, почему Вы не хотите использовать то, что наработано человечеством? Что Вас не устраивает?
Далее, Павел, Вы наверное удивитесь, но стандарт UML умалчивает о том, как следует описывать варианты использования. Поскольку UML - это объектно-ориентированный язык моделирования, а UC - это отдельно стоящее, хотя и активно использующееся в технологиях ориентированных на варианты использования и UML - такие как ICONIX и RUP.
2. Система предлагает форму для заполнения данных о товаре.
а почему форму? а не страницу, не документ? Это уже почти навязывание реализации. Может просто:
Система предлагает заполнить данные о товаре (кстати а чем товар отличается от базовой единицы товара?)
[Комментарий: Здесь на блок-схеме в пунктирном прямоугольнике значится точка расширения - это означало наличие точки расширения в будущих релизах на этом месте. Т.е. мы бы написали здесь: точка расширения: подменить пустую форму.]
Совершенно не понятно на каком основании тут точка расширения? и чего собственно расширяется? Почему расширяется? Что такое подменить пустую форму? Разве это не реализация? Чего хочет пользователь (публикатор), какое его или чей-то (ну других участников вы не указали) защищает этот шаг?
4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?
Мне кажется совершенно неверно. Вы по сути описываете существующую систему или приглянувшийся вам аналог. Но вы не описываете требования, потому что не ясен процесс.
Получается, следуя вам, что сначала товар добавляется в систему в состоянии черновик, ну возможно, а зачем? Затем не выходя из этого сценария пользователь запускает другой ВИ - сменить состояние единицы товара, зачем? Это уже чистая синтетика. Добавить товар - это типичная операция любой информационной системы - т.е. заполнение справочника.
Резюме: это не чистый ВИ, это попытка выдать некую реализацию за ВИ. Такое возможно, в случае, когда Вы изучаете и описываете работу имеющейся системы.
ВИ - это точная цель пользователя и описание ее достижения и возможно препятствий мешающих этому
-
Вопросы ко всем
RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram).
А если язык реализации не ООП, а процедурный? Возможно ли рисовать такую диаграмму активности для UC в которой бы преобладали activity и они же постепенно раскладывались на диаграммы активности на более низком уровне опускаясь до реализации.
Мой инструмент(VP) упорно не хочет из шагов в текстовом описании создавать Activity, он их трактует как Action.
Всё таки хочется понять технологию трансформации ВИ в реализацию.
Или услышать рекомендации.
4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?
если такая ситуация верна то какое отношение у этих двух ВИ? в каком случае отношением будет "включить", а в каком "Зарегистрировать товар" является под целю "Добавить товар", то есть на более низком уровне. Оба способа я нарисовал на диаграммах.
-
Вопросы ко всемА если язык реализации не ООП, а процедурный? Возможно ли рисовать такую диаграмму активности для UC в которой бы преобладали activity и они же постепенно раскладывались на диаграммы активности на более низком уровне опускаясь до реализации.
Мой инструмент(VP) упорно не хочет из шагов в текстовом описании создавать Activity, он их трактует как Action.
Всё таки хочется понять технологию трансформации ВИ в реализацию.
Или услышать рекомендации.
Никаких ограничений на использовании ДД для описнаия структуруного подхода в програмиирования нет. вообще не вижу тут никакой проблемы.
Касаемой действий и деятельностей в ходе трансформации - ну, это проблемы парадигмы ВП. Просто у них стоит правило трансформации - превращать каждый шаг варианта в действие а не деятельность (что вполне разумно). Я не уверен, что можно настроить правило трансформации, но если да, то можно это учесть в коде трансформатора.
Иначе делайте вручную, меняйте тип действия на деятельность, если возможно, или просто заменяйте действие деятельностью
если такая ситуация верна то какое отношение у этих двух ВИ? в каком случае отношением будет "включить", а в каком "Зарегистрировать товар" является под целю "Добавить товар", то есть на более низком уровне. Оба способа я нарисовал на диаграммах.
Неверное понимание на мой взгляд. все эти переводы в чистовики и обратно - суть реализация. Что нужно пользователю. какая его цель, в чем бизнес-задача? Поймете - это и будет вам ответом.
Зарегистрировать товар предполагает его добавление в систему. Регистрировать более абстрактно чем добавление, добавление, шаг возникающий при регистрации
-
Немного изменил варианты использования. Суть в том что
ВИ "Получить товар" более абстрактный чем ВИ "Заказать товар".
Насколько я понимаю на ДВИ мы отображаем один уровень этих целей начиная с самого абстрактного.
Тогда получается, что более логично выглядит последняя картинка с двумя ДВИ на разных уровнях.
Или это не соответствует стандартам?
с другой стороны ВИ "Получить товар" скорее всего окажется за границами разрабатываемой системы. Но ВИ "Получить товар" будет присутствовать на БВДИ в границах организации.
А как тогда показать(или может описать) взаимосвязь между этими ВИ на БВДИ и ДВИ?
-
А как тогда показать(или может описать) взаимосвязь между этими ВИ на БВДИ и ДВИ?
Здесь нарушение на логическом уровне. Нельзя смешивать БВИ и СВИ. Но взаимосвязь показать можно зависимостью например.
Смотрите Заказать товар - что это такое? в каком контексте? Цель какова? Очевидно чтобы получить товар.
Т.е. бизнес-процесс для получения товара включает заказ товара. Если Вы автоматизируете заказ товара, то имеет смысл только ВИ Заказать товар. Хотя возможно в вашей галактике уже существует телепортация или вы живете в полностью информационном обществе и товар производится непосредственно дома, достаточно получить программу изготовления, но в нашей галактике мы еще не научились этого делать. Поэтому ВИ Получить товар к сожалению нет. Можно Получить извещение о получении товара (на почте например)
-
Да действительно телепорт лучше сделать отдельной системой. Чтобы его можно было использовать не только для получения товара :)
А если представить что последняя картинка это не ДВИ для разрабатываемой системы, а БДВИ для организации.
Неужели в этом случае "Получить товар" и "Заказать товар" оба будут находится на верхнем уровне(то есть в предельной области действия), где "Получить товар" включает "Заказать товар"? Может организация например допускает что можно просто Зарезервировать товар (или есть какой то другой ВИ который является под целю для "Получить товар", так же как и "Заказать товар"). То есть для БВДИ последняя картинка логичная?
-
А если представить что последняя картинка это не ДВИ для разрабатываемой системы, а БДВИ для организации.
Последняя с какого края (верхняя али нижняя)?
Неужели в этом случае "Получить товар" и "Заказать товар" оба будут находится на верхнем уровне то есть в предельной области действия), где "Получить товар" включает "Заказать товар"?
Все будет определяться контекстом. Контекст будут задавать ДЛ. В том виде как представлено у Вас - быть не может и не должно. Нужно понять, что ВИ - это не функция, не процесс, не часть системы - это описание ДИАЛОГА с системой, в котором описываются варианты достижения цели ИНИЦИАТОРА ВИ и возможные способы разрешения предусмотренных отклонений от целевого маршрута.
Вы рисуете зависимость включение от Получить товар к Заказать товар. Т.е. для того чтобы получить товар нужно его заказать. Но это причинно-следственная связь, она никакого отношения к использованию системы не имеет.
Да и вновь вопрос, а как система называется?
Ну к примеру Получатель товара (Актер) - Получить товар (В границах Почта) - это один ответ, если в границах Склад - другой и т.д.
Но на каком бы уровне мы не находились Получить товар и Заказать товар - два разных способа применения системы, какой бы она не была
Может организация например допускает что можно просто Зарезервировать товар (или есть какой то другой ВИ который является под целю для "Получить товар", так же как и "Заказать товар"). То есть для БВДИ последняя картинка логичная?
Все это причинно-следственные связи, а не связи включения или расширения
Получить товар - это цель, для этого Вы можете использовать разные системы, чтобы добиться своей цели. При этом Вы
Заказываете товар
Резервируете товар
делаете что-то еще.
Понятно?
-
Тут на самом деле вопрос по 5-ой главе в книге коберна.
Я подумал, что пока для разъяснения вопроса стоит исключить систему.
И оставить только предметную область в которой есть Клиент, который имеет цель Получить товар, ведь организация может помочь в достижении этой цели. Скорее всего этот уровень по коберну находится над уровнем моря, например уровень воздушного змея. А Заказать товар допустим это уровень моря(или на БДВИ не может быть уровня моря? )
Верно ли в этом случае использовать Subdiagram Use Case для ВИ "Получить товар", в которой присутствует ВИ "Заказать товар", как показано на картинке http://www.uml2.ru/forum/index.php?action=dlattach;topic=4396.0;attach=4032 . Границы организации тоже должны присутствовать на диаграмме. Но проблема в том, что я путаюсь в уровнях ВИ.
-
Не надо усложнять простые вещи.
UC - описывает взаимодействие двух действующих лиц. Одно ДЛ - наша система в разработке, на рассмотрении. Другое ДЛ - это внешняя сущность, то что вне системы, которую мы изучаем.
Внешние сущности нужны, чтобы понять каковы границы нашей системы, каков назначение нашей системы. Грубо зачем наша система нужна внешним актерам=сущностям
Актеры - это роли людей, других систем, в том числе организаций, устройства
Система - это организация, устройство, система
Вариант использования просто не имеет смысла рассматривать вне контекста субъекта, к которому он применяется.
То, что вы нарисовали - противоречит и здравому смыслу, и нотации. Один ВИ не может быть контекстом другому.
Разные уровни абстракции - это разные уровни детализации, а не способ композиции/декомпозиции.
ДБВИ - вообще возникли в RUP, в UML об этом нет ни слова. Потому каждый волен интерпретировать по-своему. Но тут нужно следовать здравому смыслу.
ДБВИ отличает от ДСВИ разве что контекстом (boundary) субъектом.
Вот пример:
Система = Магазин
Актер= Покупатель
ВИ = Купить книгу или Ознакомиться с ассортиментом (т.е. покупатель использует магазин чтобы Купить книгу или Ознакомиться с ассортиментом)
Актер = Поставщик
ВИ = Получить прибыль от поставки книг (поставщик использует магазин чтобы Получить прибыль от поставки книг согласно контракту)
Актер = Покупатель (цель покупателя получить книгу во владение или даже прочитать книгу или даже получить удовольствие от прочтение или улучшить свои знания в предмете...)
Система = Система он-лайн заказов книг магазина
ВИ = Разместить заказ, Ознакомиться с ассортиментом, Контролировать(наблюдать) исполнение заказа
Типично: уровень облака или воздушного змея - это уровень предприятия в целом, уровень моря - уровень пользователя - суть варианта использования, уровень дна - ВИ абстрактного типа или какие-то специфичные вещи типа Login to system
-
Спасибо за разъяснения по уровням.
Актер = Покупатель (цель покупателя получить книгу во владение или даже прочитать книгу или даже получить удовольствие от прочтение или улучшить свои знания в предмете...)
Тогда не проще ли как то графически изобразить ВИ на уровнях детализации(как показано на картинке из книги), чтобы выявлять уровень моря? У меня возникает разумное желание интерпретировать эту картинку в UML, но как я не понимаю.
Меня просто смущает, что VP предлагает в контекстном меню создать Sub diagram для ДВИ. И внимание на создание такой диаграммы акцентировано, выделением её в отдельное подменю.
Я честно прочитал тему http://www.uml2.ru/forum/index.php?topic=3729.135 до конца (что чуть не взорвало мне мозг :), но не нашел ответа стоит ли например уровень моря и рыбок отображать на разных диаграммах.
Ваш ответ я понял, как совет рисовать облако и змея на одной диаграмме. А рыбок и дно вообще не рисовать на ДВИ.
-
RuZzz,
все затруднения от того, что Вы слишком полагаетесь на ДВИ и некритично подходите к VP.
Диаграмма ВИ - лишь незначительная часть модели использования. Ее цель дать контекст. Вы вправе смешивать уровни ВИ на одной диаграмме ну как минимум уровня моря и дна (по сути уровень дна - это почти тот же уровень моря, только менее значимый).
Что отображать на диаграмме Вы решаете в зависимости от аудитории, на которую направлена эта диаграмма.
То что VP разрешает делать поддиаграмму - это проблемы VP. Ведь ВИ - это классификатор - UML элемент. К UML элементу можно построить поддиаграмму. Вопрос правомерности переложен на Вас :)
не нашел ответа стоит ли например уровень моря и рыбок отображать на разных диаграммах.
не стоит
-
Спасибо я понял!