Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 05 Мая 2009, 23:02:49
-
Сразу хочу оговориться. Варианты использования - отличный инструмент работы с требованиями, областью знаний и т.п. Вообщем отличное средство. Однако, что касается диаграммы вариантов использования, то тут в семье не без урода.
И хотя я себя не отношу к "ярым" противникам использования ДВИ, тем не менее, ДВИ остается самой туманной и, кажется, никчемной диаграммой в UML.
Самое удивительное, что и специалисты, активно использующие ДВИ, и авторы книг, активно иллюстрирующие свои книги с помощью ДВИ, кажется, мало понимают, а что такое ДВИ и правильно ли ее используют. В результате есть такое ощущение. что каждый изображает то что ему хочется, называет это ДВИ и не парится.
Типичный пример (детальнее смотрите здесь (http://www.berdaflex.com/ru/eclipse/books/rcp_filemanager/ch01s02.html))
(http://www.berdaflex.com/ru/eclipse/books/rcp_filemanager/resources/th_use_case_diagram1.jpg)
С какого бодуна вообще решено изображать работу с файловым менеджером таким образом. И выделение пользователей не по ролевому признаку, а по опытности - что за бред??
А как вам нравится это "декомпозиция" ВИ Управление ресурсами файловой системы: Добавление, Правка и Удаление. А что простите такое управление ресурсами, которое должно обязательно включать добавление, правку и удаление - заметьте ОДНОВРЕМЕННО, если все-таки следовать букве закона использования ДВИ.
В общем пришло время поговорить серьезно. Есть плюсы или только минусы? Или минусы - это и есть плюсы?
Поскольку эта тема тревожит умы форумчан, а последовательный противник ДВИ - Денис Бесков, то я хотел бы призвать вас высказаться по существу, со своими аргументами.
Надеюсь, в споре родится истина. Родится что-то полезное. возможно правило форума - те кто попытается обратится с вопросом по ДВИ - тотчас исключается из форума ;D
-
Претензии в приведенном примере относятся к тому,
1. как именно была использована (нарисована) ДВИ или
2. к самой спецификации ДВИ?
Если 1, то, может быть стоит взять менее "игрушечные" примеры (например ДВИ (http://docs.oasis-open.org/ubl/prd-UBL-2.0/art/UBL-2.0-CombinedUseCase.jpg) из Universal Business Language 2.0 Public Review Draft (http://docs.oasis-open.org/ubl/prd-UBL-2.0/))? А то всякие примеры с наливанием чашки кофе или чая, честно говоря, достали. Можно подумать, что именно автоматизация наливания кофе в чашку является для ИТ такой же фундаментальной проблемой, какой была теорема Ферма для развития математики. Для таких "мелких" задач ДВИ точно бесполезна.
ИМХО, значение ДВИ для проекта определяется возможными вариантами этой диаграммы, из которых нужно сделать одну по результатам обсуждения с Заказчиком (а то и в результате объединенмя несколькмх диаграмм по результатам обсуждения с разными представитлеями Заказчика). Поэтому рассматривать диаграммы в отрыве от конкретной ситуации, различных пониманий бизнеса Заказчика, которые должны быть приведены к "общему знаменателю", весьма затруднительно. А без общего (для участников обсуждения) бизнес-контекста вряд ли удастся к этому знаменателю приблизиться.
Кстати, истина рождается в обсуждении, в споре она умирает :).
-
Ну вы блин даете.
ДИ - очень нужная диаграмма.
Она показывает ЧТО делает система в этом сумашедшем мире.
По сути правильная ДИ - это спецификация на систему в виде комиксов. Все наглядно и понятно.
ДИ рисуют аналитики. Надеюсь понятно зачем.
ДИ могут рисовать архитекторы, например, чтобы описать ЧТО делает та или иная подсистема и с кем и зачем она взаимодействует.
ДИ могут рисовать программисты, например, чтобы описать ответственности классов, компонент или других модулей. Все знают что такое CRC-карты? Так вот ДИ - это те же CRC-карты, только по другому нарисованные.
ДИ могут использоваться тестировщиками, так как ДЛ на ДИ - это роль, которую должен сыграть тестировщик при системном тестировании. ДИ показывает тестировщику систему не в виде черного ящика, как обычно, а как белый ящик. Каждый ВИ - набор тестов (сценариев).
Да масса применений ГРАМОТНО нарисованной ДИ.
Надо просто учиться и учить других. Вот и все. А то что кто-то там (ссылка Эдуарда) вообще не понимает что рисует ... так идиотов хватает.
Давайте на эмоциях-то ребенка не выплескивать.
-
Давайте разбираться с начала.
Зачем вообще нужны диаграммы (любые в анализе и проектировании)?
1. Помощь в продумывании — выявление понятий и свойств, установление взаимосвязей, анализ (не)полноты.
2. Фиксация некоторых решений и их коммуникация.
Что ещё забыл?
-
Претензии в приведенном примере относятся к тому,
1. как именно была использована (нарисована) ДВИ или
2. к самой спецификации ДВИ?
Кстати, истина рождается в обсуждении, в споре она умирает :).
Привет, Shur. Я уже думал, Вы нас покинули :)
Пример приведен лишь как пример - не более и не менее. Обсуждаем не пример. Обсуждаем + и -.
Насчет истины - согласен :) Однако я говорю об устоявшемся изречении.
Мне бы хотелось, чтобы участники полемики высказывались ясно и по существу. Т.е. не абстрактно -это полезно или не полезно, а конкретно. С четко обозначенной аргументацией за и против, демонстрацией примеров, возможно жизненного опыта и т.п.
-
Ну вы блин даете.
Надо просто учиться и учить других. Вот и все. А то что кто-то там (ссылка Эдуарда) вообще не понимает что рисует ... так идиотов хватает.
Давайте на эмоциях-то ребенка не выплескивать.
Денис, никто не выплескивает. Аргументы прошу давать не абстрактные, а точно конкретные.
Просто пока твои предложения это только предложения, которые многие читают и совершенно не воспринимают.
Нужна точность до абсолюта - типа вот пример смотрите понимайте.
Кстати насчет совпадения с CRC - у меня были такие же ассоциации, но все-таки CRC ближе к диаграмме класов, чем ДИ, разве нет?
-
Эдуард, как обычно ;) выступает с провокационными предложениями в поисках бури :) Можно сказать: "Над седой равниной моря гордо реет..."
Эх.... ничто не скроется от опытного взгляда, умудренного опытом Лодочника :)
Сергей, ты как всегда в ударе? Твой любимый метод индукции поясняет для окружающих много. Осталось записать это в скрижалях. Твой пример убедителен.
Выжимка:
есть мнение, что
ДИ - полезна при исходном обсуждении некоторого высокоуровневого набора требований
Она может быть полезна в дальнейшей работе команды разработчиков как контекстная диаграмма
ДИ - это комикс, емко и быстро передающий достаточно большую информацию
ДИ - это гешальт системы под рассмотрением. При этом данный гешальт достаточно понятен как стороне заказчика, так и стороне разработчика
ДИ - в первую очередь инструмент аналитика, особенно на начальной стадии формулирования и выявления требований к системе
Есть опровержения, дополнения, усиления?
-
Кстати насчет совпадения с CRC - у меня были такие же ассоциации, но все-таки CRC ближе к диаграмме класов, чем ДИ, разве нет?
А какая разница-то? ДИ можно рисовать для любой сущности (считая ее системой), а всех с кем это сущность взаимодействует описывать как ДЛ.
-
Аргументы прошу давать не абстрактные, а точно конкретные.
Просто пока твои предложения это только предложения, которые многие читают и совершенно не воспринимают.
Нужна точность до абсолюта - типа вот пример смотрите понимайте.
Кто не понял, что я написал? Задайте конкретные вопросы.
В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.
-
Итого — вроде рассказ Сергея не добавил каких-то новых функций диаграмм.
Что говорит Сергей?
Что ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.
Аналогичным образом я могу составить рассказ о том, как в взаимодействии с Заказчиком получить на доске Список ролей (например, с помощью Контекстной диаграммы), а потом пройдясь по каждой роли, получить Список задач, которые будут решать эти роли с помощью системы (Проходом по сценарию деятельности этой Роли вообще, в бизнесе, а не в системе).
-
ДИ - очень нужная диаграмма.
Она показывает ЧТО делает система в этом сумашедшем мире.
Давайте быть точнее. Не ЧТО делает система, а какие полезные результаты должен извлекать для себя агент, с ней взаимодействующий.
Не:
(http://yuml.me/diagram/usecase/[Автолюбитель]-(Ехать на машине))
А:
(http://yuml.me/diagram/usecase/[Автолюбитель]-(Добраться до работы))
Не:
(http://yuml.me/diagram/usecase/[Домашний пользователь]-(Сканировать компьютер на вирусы))
А:
(http://yuml.me/diagram/usecase/[Домашний пользователь]-(Убедиться в безопасности компьютера))
По сути правильная ДИ - это спецификация на систему в виде комиксов. Все наглядно и понятно.
Вообще, слово «спецификация» в переводе с латинского, английского это «указания» в смысле «детализация»,«проработка». ДИ — это наоборот, скорее верхнеуровневый взгляд на систему, а не детализация.
-
Теперь по поводу «наглядно и понятно».
Как показывает пример Сергея, наглядно и понятно это может быть, если мы вместе с Заказчиком/Пользователем рисуем ДИ вместе, как некоторую неформальную картинку.
А не присылаем её в составе документа, самостоятельно нарисовав и он недоумевает — ну да, всё так, только зачем она нужна, эта картинка?
А многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.
-
Ну понаписали .... Особенно Сергей ;)
1. Давайте все таки придерживаться обозначений, принятых на Форуме:
http://www.uml2.ru/index.php?option=com_content&task=view&id=71&Itemid=50
2. Как правильно сказал Сергей, многие западные коллеги используют ВИ именно как технику выявления Требований
3. Денис, если ты хочешь показать назначение ВИ, то твой пример не подходит:
Не "Добраться на работу", а "Добраться до пункта назначения", и не Автолюбитель, а Человек
Не "Убедиться в ..", а "Проверить безопасность компьютера" или "Вылечить Компьютер от Вирусов" (а от чего его спасает Антивирус, кроме как от Вирусов?)
4. Если же мы все таки говорим о + и - ДВИ, то давайте о них и говорить. Или мы говорим о ВИ и ДВИ?!
+ ДВИ:
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации
- ДВИ:
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ
5. Можно еще поговорить о (не) применимости ДВИ
Применимость ДВИ:
* Бизнес приложения, веб
* Сложные приложения
* Выявление пользовательских требований
* Сильная подготовка Аналитиков
* Итерационная разработка ДВИ
* Не более 5-7 ВИ на одной Д
Неприменимость ДВИ:
* Интеграционные решения, Один Пользователь
* Простые приложения
* Слабая подготовка Аналитика, и других членов Команды
* Постфактумная демонстрация ДВИ в Документации (без объяснений)
* ДВИ без описанных Сценариев ВИ
* Более 5-7 ВИ на одной Д
-
3. Денис, если ты хочешь показать назначение ВИ, то твой пример не подходит:
Не "Добраться на работу", а "Добраться до пункта назначения", и не Автолюбитель, а Человек
Откуда ты знаешь, о какой системе идёт речь?
Не "Убедиться в ..", а "Проверить безопасность компьютера" или "Вылечить Компьютер от Вирусов" (а от чего его спасает Антивирус, кроме как от Вирусов?)
Ну проверили безопасность, на выходе получили отчёт о 678 вирусах. Это ли настоящая цель пользователя? Не думаю.
Хорошая система должна помогать человеку в реализации интересов. Нет такого интереса — проверять.
Почему антивирус? Опять же, я не называл систему. В этом и прелесть ВИ, что они могут формулироваться тогда, когда ещё никакой системы нет и её категория неизвестна (ОС? Подсистема безопасности? Антивирус? — Да что угодно).
-
Денис, исправил пока писал, см. еще раз.
-
4. Если же мы все таки говорим о + и - ДВИ, то давайте о них и говорить. Или мы говорим о ВИ и ДВИ?!
Плюсы и минусы в сравнении с чем? Моё предложение — контекстная диаграмма (для выявления Агентов), проход по бизнес-сценарию Агента и список (для выявления Задач).
-
2. Как правильно сказал Сергей, многие западные коллеги используют ВИ именно как технику выявления Требований
Не понял, откуда ты взял про западных коллег.
-
Не понял, откуда ты взял про западных коллег.
Сибирь - это к востоку от Москвы. :)
-
Не понял, откуда ты взял про западных коллег.
Погугли requirement elicitation techniques
Плюсы и минусы в сравнении с чем? Моё предложение — контекстная диаграмма (для выявления Агентов), проход по бизнес-сценарию Агента и список (для выявления Задач).
Выявление - это не единственная задача ДВИ, еще это удобный метод Сохранения Знаний\Требований, дальнейшей их детализации и представления другим участникам. Все методы хороши при комплексном их применении и для нужных задач. И применение ДВИ не исключает, а даже приветствуется при начальной проработке Контекстной Д.
-
От погугли слышу %)
Саша, ещё раз — где СЕРГЕЙ сказал про ЗАПАДНЫХ коллег?
-
Денис,
Ля ля ля .... надо читать так:
Правильно сказал Сергей, например, многие западные коллеги используют ВИ именно как технику выявления Требований
-
Денис,
Ля ля ля .... надо читать так:
Правильно сказал Сергей, например, многие западные коллеги используют ВИ именно как технику выявления Требований
С таким отношением к языку и логике высказываний мы далеко не уедем :(
-
Денис,
Спасибо за уточнение :P
-
Кто не понял, что я написал? Задайте конкретные вопросы.
В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.
Денис ты написал все очень корректно. Но на мой взгляд ты говоришь примерно так: Очем тут разговор - ДИ полезна - это аксиома, доказательства не требует. Тем неменее ты приводишь, где будет полезна ДИ. Это хорошо. Но хотелось бы наглядных примеров в пользу твоей точки зрения.
ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.
Аналогичным образом я могу составить рассказ о том, как в взаимодействии с Заказчиком получить на доске Список ролей (например, с помощью Контекстной диаграммы), а потом пройдясь по каждой роли, получить Список задач, которые будут решать эти роли с помощью системы (Проходом по сценарию деятельности этой Роли вообще, в бизнесе, а не в системе).
Вот точка зрения Дениса. Полезна не сама ДИ, а процесс получения некой диаграммы в ходе взаимодействия З/П. При этом неважно будет ли это ДИ, или нечто иное.
UML дает нам в качестве КОНТЕКСТНОЙ именно ДИ и будет полезна
ЛЮБАЯ ГРАМОТНО составленная ДИ.
Что значает тогда грамотная?
многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.
Принимаем ли мы факт, что ДИ полезна только ходе взаимодействия З/П? А сама по себе даже с комментариями лишняя?
Добавлю, что наверное ДИ полезна в рамках UML инструмента, как содержание и средство навигации. Согласны ли вы с этим?
+ ДВИ:
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации
* а почему ты полагаешь, что таблица Участник/Задача не отвечает той же цели? А что делать, если система слишком велика, чтобы продемонстрировать ее функционал для охвата одним взглядом. ДВИ не подлежит декомпозиции
* а чем она хороша для выявления требований, если тебе нарисуют диаграмму, разве это позволит тебе выявить корректно требования?
* например?
* опять же чем плоха простая таблица?
- ДВИ:
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ
* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* а разве наглядность диаграммы не служит для облегчения понимания? Если диаграмма сложна для понимания зачем она вообще нужна?
* чем плохо множество взглядов. Может как раз эта позиция и сильна. Диаграммы IDEF0, DFD строго определяют одну и только одну точку зрения, так может множественность токи зрения как раз хороша, поскольку снимает ограничение
-
* а почему ты полагаешь, что таблица Участник/Задача не отвечает той же цели? А что делать, если система слишком велика, чтобы продемонстрировать ее функционал для охвата одним взглядом. ДВИ не подлежит декомпозиции
* а чем она хороша для выявления требований, если тебе нарисуют диаграмму, разве это позволит тебе выявить корректно требования?
* например?
* опять же чем плоха простая таблица?
* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.
* Тебе сценарий написал Сергей
* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТ
* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.
* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* а разве наглядность диаграммы не служит для облегчения понимания? Если диаграмма сложна для понимания зачем она вообще нужна?
* чем плохо множество взглядов. Может как раз эта позиция и сильна. Диаграммы IDEF0, DFD строго определяют одну и только одну точку зрения, так может множественность токи зрения как раз хороша, поскольку снимает ограничение
* Выделение ВИ и выявление Требований немного разные вещи
* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезна
* Если грамотно использовать, то это +, если нет, то это -
-
* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.
Демонстрация иерархии ролей может быть выполнена и без реализации диаграммы вариантов использования.
Когда я говорил о таблице Участник/Задача я подразумевал коберновскую таблицу участник-интерес. Интерес, задача, цель. Мне кажется мы слишком склоны ориентироваться на понятие цель, а ведь в английском слово цель имеет столь разнообразные значения. Потому когда я упоминал слова Задача, я не говорил что это функция системы, я говорил, что это задача участника, функция система одна обеспечить выполнение задачи пользователя
* Тебе сценарий написал Сергей
Написал, однако участие ДВИ здесь может быть минимальным.
* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТ
Напоминаю что мы обсуждаем диаграмму использования, а не целесообразность использования ВИ. О ней никто не дискутирует. Твоя фраза совершенно не в тему.
* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.
смотри выше. ВИ может и подход, но причем тут диаграмма?
* Выделение ВИ и выявление Требований немного разные вещи
ВИ - это функциональные ТРЕБОВАНИЯ. Нельзя говорить противопоставлять одно другому. Форма записи не означает различия смысла!
* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезна
Еще раз спрошу. Можно ли постулировать такое утверждение.
Диаграмма вариантов использования на начальной стадии анализа сама по себе, как средство документирования, средство отчуждения смысла знаний, бесполезна. Польза ее состоит на данном этапе только в ходе тесного взаимодействия заказчика и разработчика как иллюстрация хода мыслей по первичному выявлению потребностей заказчика.
Диаграмма вариантов использования может быть полезна в рамках организации процесса разработки специалистам компании разработчика, как часть их прфессиональных знаний в:
1. принятии проектных решений
2. в ходе разработке тестов
3. в ходе разработки пользовательской документации
4. как средство навигации по моделям проекта при использовании соотвествующих инструментов
* Если грамотно использовать, то это +, если нет, то это -
Что такое грамотно использовать. Приведи примеры грамотного использования.
-
Я хочу высказаться в пользу ДВИ в противоречии со занятой в данной теме позиции.
Итак, наш студент Batak, предложил для нашей рецензии свою диаграмму ВИ. Она плоха, ошибочная и неполна. Но...
Предположим этот студент попытался передать тоже, но чистым текстом в виде скажем иерархического списка, в котором верхний узел роль пользователя, подчиненные узлы - то что, он считал вариантами использования.
С чем бы он столкнулся:
1. повторением одних и тех же ВИ у разных ролей пользователей
2. сложно было бы передать обобщение одиних пользователей другими. Вернее не так сложно, как мало наглядно
3. скорее всего мы бы все равно заставили его что-то нам нарисовать.
4. скорее всего мы бы хуже поняли ход мысли студентам в тексте, чем в диаграмме
Теперь о возможных плюсах диаграммы над текстом (я уже ранее пытался высказать эту мысль в другом месте)
1. диаграмма - это образ, человеку проще воспринимать образы, чем просто текст. Все равно текст преобразуется в образы в голове.
2. диаграмма ВИ в данном случае имеет определенные ограничения в изображении и это заставляет ограничивать свою фантазию в изображении и передавать смысл более простыми средствами.
Далее может вы заметили, что между диаграммами DFD и диаграммами ВИ есть определенное сходство:
1. там и там есть понятие внешней сущности
2. там и там есть сущность, инициирующая процесс, и сущность вспомогательная - поставщик данных
3. в DFD нельзя изобразить обощение одних внешних сущностей через другие, на ДВИ можно
4. как на ДВИ, так и на диаграмме DFD не следует изображать внешние сущности, не взаимодействующие непосредственно с системой
5. контекстная диаграмма DFD почти тоже что и диаграмма ДВИ, если разрешить изображать на DFD внутренние процессы или подсистемы
6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой
7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.
Кстати Скотт Амблер в книге Гибкое моделирование тоже об этом говорит. Однако мне кажется, ДВИ выразительнее диаграммы DFD.
Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
- то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
- то, что одобряется руководством как исполнения полезной работы
- нечто краткое, сеансовое, законченное - транзакция
2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.
3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов
-
Между DFD и ДИ есть серьезное различие - на ДИ нет времени (ни в каком виде) и потоков данных, нет алгоритмов и, как следствие, меньше шансов сделать ошибку!
-
Эд,
Под идеологии ВИ я имел в виду - выделение Актеров, понятие ВИ как цели, спецификацию ВИ и ДВИ. ИМХО из идеологии что-то выдергивать можно, но это мало эффективно. Если мы правильно выделили ВИ и написали их спецификации, то почему бы нам не нарисовать ДВИ, чтобы было еще понятнее?!
Под выделением ВИ я имел в виду, что мы правильно определили ВИ как цели, а не просто как Системные Требования.
Еще раз спрошу. Можно ли постулировать такое утверждение.
Диаграмма вариантов использования на начальной стадии анализа сама по себе, как средство документирования, средство отчуждения смысла знаний, бесполезна. Польза ее состоит на данном этапе только в ходе тесного взаимодействия заказчика и разработчика как иллюстрация хода мыслей по первичному выявлению потребностей заказчика.
ДВИ полезна и при дальнейшей работы с требованиями, если все участники понимают ее смысл, т.е. она должна быть объяснена ЗЛ.
-
6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой
Вообще говоря, с помощью ДВИ можно изобразить взаимодействие действующих лиц (ДВИ), задействованных в некоторую совместную деятельность. Сама эта деятельность носит системный характер, поэтому и лица и ВИ в широком смысле являются частью некоей системы (не в смысле некоего программно-аппартного комплекса). Нарисовать границу системы (рамку), как указывал выше Boatman важно, особенно если необходимо выделить границы автоматизируемой деятельности, но иногда и без этой рамки картинка взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) через ВИ помогает понять бизнес Заказчика. Особенно если мы хотим прояснить топологию взаимодействия лиц.
7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.
ИМХО содержание ВИ, указанных на ДВИ, можно детализировать диаграммами деятельности. Особенно на этапе анализа, выявления логики бизнеса Заказчика, безотносительно к возможным программно-аппаратным решениям по его автоматизации. Можно конечно привлекать и диаграммы последовательности, состояний но они сразу тянут за собой диаграмму классов, а это ИМХО затрагивает компетенцию архитектора и эти диаграммы хорошо бы рисовать минимум вдвоем - бизнес-аналитик и архитектор.
Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
- то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
- то, что одобряется руководством как исполнения полезной работы
- нечто краткое, сеансовое, законченное - транзакция
2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.
ВИ на ДВИ допускает участие в ВИ нескольких пользователей, преследующих разные цели, поэтому пытаться выносить цели пользователей в название ВИ (на ДВИ) - очень сильное, не всегда реализуемое требование.
3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов
ИМХО некорректно пытаться отразить на ДВИ последовательность осуществления ВИ, что неизбежно возникает при попытке отразить на ДВИ отношения invoke и precede. Как отразить условия осуществления, ветвления последовательности осуществления ВИ при выполнении invoke и precede? Не лучше ли тогда просто нарисовать диаграмму(ы) деятельности?
-
.... картинка взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) через ВИ помогает понять бизнес Заказчика. Особенно если мы хотим прояснить топологию взаимодействия лиц.
ДИ не предназначена для того, чтобы описывать "взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) ". Стандартом UML определено единственное возможное отношение между ДЛ - обобщение, которое нужно для уменьшения количества ассоциация между ДЛ и ВИ на диаграмме.
Как отразить условия осуществления, ветвления последовательности осуществления ВИ при выполнении invoke и precede?
Это не та задача, которую должна решать ДИ
-
ДИ не предназначена для того, чтобы описывать "взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) ". Стандартом UML определено единственное возможное отношение между ДЛ - обобщение, которое нужно для уменьшения количества ассоциация между ДЛ и ВИ на диаграмме.
Это не та задача, которую должна решать ДИ
Это не так - см . (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, N o v e m b e r 2 0 0 7 )
16.3.6 UseCase (from UseCases)
Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...
Т.е. cубъект ВИ - экземпляр класса ДЛ может обладать поведением, которое он может осуществлять во взаимодействии с другими ДЛ.
Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.
Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.
-
Shur, у меня такое ощущение, что вы просто не поняли, что такое subject в UML.
Привычное нам отношение subject-object (subject - тот кто делает, а object - тот над кем совершается действие) здесь не работает.
Просто процитирую спеку.
The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors.
Subject это сама система, которую вы моделируете и которую на ДИ можете нарисовать в виде прямоугольника поместив туда ВИ и оставив ДЛ за бортом.
-
Согласен, что авторы спецификации предполагали использования понятия субъект прежде всего в качестве системы компьютерной, но явного запрета на интерпретацию системы как сообщества взаимодействующих для достижения некоторых целей по определенным правилом лиц спецификация ИМХО не содержит. Я не буду настаивать на том, что спецификация ДВИ в UML предназначена именно для описания взаимодействия пользователей с участием системы. Я писал о возможности такой интерпретации ДВИ. Система-субъект - посредник, которая взаимодействиует с ДЛ, причем, возможно с несколькими. Сам факт такого множественного участия ДЛ в ВИ представляется важным и, как правило, означает необходимость координации действий этих ДЛ при осуществлении ВИ. Увидеть на ДВИ кто какие работы выполняет, с кем нужно обсуждать требования к отдельным видам работ (ВИ), на этапе анализа бизнеса заказчика ИМХО весьма полезно. Для этого можно использовать ДВИ. Можно, конечно, интерпретировать все утверждения спецификации в смысле "что не разрешено явно, то запрещено". И не использовать ДВИ предложенным мной образом.
-
Уфф. Прочитал мнения участников дискуссии...
О диаграммах вообще. Чем диаграмма отличается от текста? Зачем вообще информацию изображают геометрически? Чем график лучше (или хуже) таблицы?
Резюме ответов на эти вопросы: так принято, так положено по инструкции, мы к этому привыкли и нам так удобнее...
К примеру, пошел я в магазин. Купил там электрическую дрель (желательно хорошую, подороже). Принес ее домой и стал пользоваться ей как молотком, гвозди в стену вбивать. Приноровился, привык и инструмент этот стал мне удобнее молотка. Всем рекомендую! На этом не остановился. Теперь все мои подчиненные должны точно так же прибивать гвоздики. Передовой опыт распространил на партнеров и контрагентов. Теперь акт приемки-сдачи не будет подписан, если гвозди на объекте приколачивались неправильно. Вытащить все, приколотить правильно! и т.д. и т.п.
Молоток и дрель внешне отличаются друг от друга. Гвозди можно успешно и качественно вбивать в стену как молотком, так и дрелью. Но электрический инструмент содержит в себе какие-то иные потенциальные возможности. И, наверное, гораздо эффективнее использовать дрель для решения других задач.
Точно так же, как дрель может заменить молоток, график или диаграмма могут использоваться (и успешно) вместо текста. Это все равно текст, только иначе форматированный. Но такое их употребление совсем не раскрывает потенциал, возможности графических средств.
Так зачем нужны все эти графики, схемы, диаграммы, в чем их потенциальные возможности?
(Это можно объяснять по-разному. Здесь воспользуюсь метафорой правого-левого полушарий.) Геометрические средства представления информации нужны для активизации образного мышления, для того чтобы задействовать в работе, в решении проблемы правую половину мозга. Зачем?
- Как минимум, чтобы синхронизировать правое полушарие мозга с левым, чтоб не мешало, не отвлекало, не уводило в сторону. При отсутствии нагрузки, правое полушарие очень сильно мешает работе, которую выполняет левое полушарие, вторгается, рассеивает внимание, не дает сконцентрироваться на проблеме и т.д. Левое полушарие мало того, что решает задачу, так еще должно бороться с помехами, создаваемыми правой половиной мозга. Поэтому нужно загрузить образное мышление хотя бы данной темой.
- Как максимум, загрузить правое полушарие такой задачей, с которой оно справляется лучше и эффективнее, чем левое. И тем самым увеличить продуктивность своей работы.
Специфика образного мышления - это рассмотрение и решение вопросов полноты, конструктивной целостности и сложности формы, упрощенное представление объекта в виде структуры-скелета и поиск похожих ассоциаций, нечувствительность к особенностям элементов объекта и логическим дефектам в них, рассмотрение объекта в реальном мире.
Об этих особенностях образного мышления знают, но этого мало. Образ не может быть безличным. Образ не может быть где-то там сам по себе, за лесом. Образ объекта создается, формируется у человека, который рассматривает, читает диаграмму. Это его личный образ.
Рассматривать, читать любую диаграмму можно как аналитически, так и образно. Аналитически - это почти как читать текст. Читать диаграмму образно - значит мыслить изображенное на диаграмме реальным и вступать с этим в реальное, личное взаимодействие, непосредственно самому ощущать динамику изменений, происходящих с объектом и его отношения с внешним миром. Другими словами, читать диаграмму образно - значит самому мысленно превратиться в то, что на ней изображено (или его часть), уподобиться проектируемому объекту. И через такое уподобление выявлять и решать вопросы полноты, целостности и т.д., своей собственной целостности.
Без такого образного рассмотрения диаграмм, схем, графиков и пр. все усилия на их рисование - это пустое, бессмысленное занятие, мартышкин труд. В этом случае я против диаграмм :) Если все равно предполагается только аналитическая работа, то текст лучше. (Гвозди правильнее забивать в стену молотком, а не чем-то еще.)
Что касается UML. Тут все то же самое. Мне попадалась работа, в которой автор заявлял, что знает как правильно оптимизировать диаграмму классов. И понимал под этим задачу кройки и шитья, наиболее плотную упаковку вот этих прямоугольников на листе формата А4. И такое упакованное нечто называется идеалом диаграммы классов. Это даже не смешно.
Но из всех видов диаграмм особое место занимают ДВИ. Вот этот символический человечек (не кружок или прямоугольник!!!) используется на диаграмме для чего? Тут прямо указывается тому, кто диаграмму будет рассматривать, чтобы он попытался сам стать этим человечком. Увидеть себя таким, как будто с тобой в реальности происходит то, что на диаграмме нарисовано, все эти связи и отношения.
Вот, собственно и все. Хорошая диаграмма помогает человеку мыслить образно. А плохая - это просто нагромождение вырезок текста в кружочках и рамочках, исключающее всякую возможность представить себя всей этой кашей...
-
Shur, я совершенно не против вашей точки зрения, но надо понимать, что вещи надо использовать по назначению. Конечно спека UML не идеальна, но спека написана для производителей инструмента, а не для пользователей. Для пользователей написаны другие книги (Руководства пользователей).
Если используется UML, то надо понимать для чего он предназначен.
“UML – графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем”
Г. Буч
Если задача не вписывается сюда, то оригинальный UML вам не нужен. Может какой-нибудь его profile, но не оригинальный UML.
-
Уфф. Прочитал мнения участников дискуссии...
Типа, чем бы дитятки не тешились? ;)
Итак, резюмируем.
Ясный плюс с позиции tolldo.
Диаграмма вариантов использования средство нагрузить правое полушарие и снять нагрузку с левого, которому приходится ублажать правое, что приводит с рассеиванию внимания. Т.е. диаграмма ВИ, как и любая другая - это средство сосредоточения внимания на предмете исследования. Исходя из этого, диаграмма в дискуссии помогает привлечь и удержать внимание участников на предмете разговора. Похожий вывод в иной подаче сделан Boatman и Денисом Бесковым.
Вопрос будет ли играть диаграмма ту же самую роль в случае чтения документации?
-
Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...
Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.
Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.
Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.
Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.
Варианты использования могут применяться как (и) для точного определения (внешних) требований к объекту(предмету) (вообще), так и (и) для точного определения функциональности, предлагаемой объектом (предметом). Кроме того, ВИ также устанавливают требования (тут явно что-то пропущено. союз, запятая, предлог), которые указанный объект (предмет) ставит перед своим окружением, определяя, как они (интересно кто эти они?) должны взаимодействовать с (этим) объектом (предметом), чтобы он (этот самый объект) был в состоянии выполнить взятые на себя обязательства (свои сервисы-услуги)
Вот как тут после этого друг друга понимать :)
-
А вообще любой инструмент окажется бесполезным в руках того, кто не умеет им пользоваться. ДВИ ничем не хуже и не лучше любого другого в этом отношении.
Ida, простите, но это демагогия. Для того чтобы научиться пользоваться инструментом, нужно точно понимать его назначение и правила его применения. Мне кажется, как раз это мы и пытаемся выяснить, поскольку на форуме существуют две диаметральные точки зрения КОНКРЕТНО на ДВИ.
-
Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.
Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.
Варианты использования могут применяться как (и) для точного определения (внешних) требований к объекту(предмету) (вообще), так и (и) для точного определения функциональности, предлагаемой объектом (предметом). Кроме того, ВИ также устанавливают требования (тут явно что-то пропущено. союз, запятая, предлог), которые указанный объект (предмет) ставит перед своим окружением, определяя, как они (интересно кто эти они?) должны взаимодействовать с (этим) объектом (предметом), чтобы он (этот самый объект) был в состоянии выполнить взятые на себя обязательства (свои сервисы-услуги)
Вот как тут после этого друг друга понимать :)
Sorry, если я Вас запутал.
*Если трактовать спецификацию так, настаивает Денис, то обе цитаты описывают поведение компьютерной системы с внешними по отношению к системе ДЛ. Некоторая проблема возникает, если компьютерной системы еще нет, но об этом ниже...
**Во второй цитате, ВИ взаимодействуют с субъектом-системой и на характер этого взаимодействия (поведения) ВИ накладывают требования (своим существованием).
В спецификации в разделе Notation для ВИ сказано - что
"A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier."
Из спецификации следует, что система-субъект не обладает ВИ. ВИ просто применяются к системе-субъекту!ИМХО это снимает кажушуюся "кривизну" формулировки цитаты про environment из спецификации.
Т.е. в самой спецификации противоречий (во всяком, случае, вопиющих:) не видно. ИМХО разлчие мнений о полезности или способах использования ДВИ имеет очень косвенное отношение к вопросу о точности опсания ВИ и ДВИ в спецификации. Но имеет непосредственное отношение к вопросу применения ДВИ на практике. Причем применения ДВИ для описания не собственно компьютерной системы (она может даже не существовать на момент анализа бизнес и рисования ДВИ), а для описания деятельности, которую еще только предстоит автоматизировать. Я предложил трактовку спецификации, которая устраняет необходимость рисования диаграммы про то, чего еще нет. И трактовать ДВИ как диаграмму описывающую вазимодейсстве ДЛ с системой действующих лиц. Систему, представляющую собой предприятие заказчика, логику его работы, значимую для реализации системы. Видимо, не случайно процитированная Денисом точка зрения Г.Буча в коллективном труде отцов-основателей - Г. Буч, Д. Рамбо, А. Джекобсон Язык UML Руководство пользователя" звучит в виде:
"Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит, программному обеспечению." Т.е. большая роль принадлежит ПО, но им не исчерпывается.
-
Galogen, прощаю :)
А на мой взгляд, демагогия - это то, чем занимаетесь вы. Почему ни у кого не возникает желания взять веник и начать его рассматрвиать, задаваясь вопросом - а правильно ли мы его используем, а нужен или он вообще?... Вероятно, потому, что все, кто умеет пользоваться веником, уже давно успешно им пользуются, какие бы точки зрения на него в природе не существовали. Им ведь можно и от мух отмахиваться. И как средство самообороны использовать.
Ида, у нас тут ситуация следующая — регулярно приходят новички и пытаются построить дом при помощи веника. Поэтому и есть необходимость разобраться и рассказать, можно ли построить дом при помощи веника, если да, то какой, почему веник плохо подходит, что ещё можно использовать вместо веника, как принимать решения в пользу веника или против.
Если тебе это не интересно — не участвуй в дискуссии.
Contribute or GTFO (http://kolomeetz.ru/blog/deepforest/contribute-or-gtfo)
-
Читая книгу Айвара Якобсона, Грэди Буча, Джеймс Рамбо "Унифицированный процесс разработки программного обеспечения", я вижу, что не имеет смысла так драматизировать ситуацию относительно ДВИ.
Вполне возможно сама по себе ДВИ на ранних стадиях анализа, в первичной работе аналитика (то что у нас обычно возникает при обращении студентов на форуме) ДВИ мала пригодна как инструмент отображения контекста. Ясно, что этот контекст уточняется итерационно.
Когда требования обретают определенную плотность и очертания - через ВИ например, то кажется, что ДВИ уже никому не нужно. Однако на мой взгляд, как раз вот на этом этапе, именно на этапе специфицирования требований, ДВИ и будет важна как часть модели использования, для визуализации последующих этапов анализа и проектирования.
Почему? Да хотя бы потому, что графические образы проще трассировать. Графические образы проще использовать повторно.
Например, гораздо проще представить, чем описать картинку UCDPN1
А картинка UCDPN2 - дает сразу логичскую связь между ДВИ и аналитической моделью VOPC
А как использовать такую картинку UCDPN3 или UCDPN4, если бы у нас не было исходной ДВИ?
Т.е. скорее наверное имеет смысл говорить не о + или - самой диаграммы, а способах ее использования или правильном и неправильном ее использовании. Но наверное нужно начинать новую тему? Начнем? И как ее лучше назвать?
-
Не влезло в предыдущий
Ну и в конце, я поступлю как студент. Скажите правильно ли или лучше не так, понятно ли то, что тут изображено UCDPN5? Предлагаю когда будет время, опубликовать ваши описания по диаграмме, как вы ее воспринимаете. Потом сравним...
-
Читая книгу Айвара Якобсона…
Он Ивар, швед.
-
Он Ивар, швед.
Ага ты прав, просто я что-то не обратил внимание когда сдирал библиографии книги :)
-
Не влезло в предыдущий
Ну и в конце, я поступлю как студент. Скажите правильно ли или лучше не так, понятно ли то, что тут изображено UCDPN5? Предлагаю когда будет время, опубликовать ваши описания по диаграмме, как вы ее воспринимаете. Потом сравним...
Можно рассмотреть диаграмму с нормативной точки зрения (соотнести с логикой спецификации) -1, и с точки зрения описываемого диаграммой бизнеса -2.
1. Согласно спецификации "A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system." ВИ на предложенной диаграмме представляются несколько фрагментарными. Может быть стоило сгруппировать действия учасников в меньшее количество более общих ВИ - например, "Заказ товара", "Оплата товара", "Доставка(поставка) товара"? ИМХО на диаграмме ВИ не стоит пытаться детально описать логику действий, которые подразумевает конкретный ВИ. Детальное описание действий, составляющих ВИ, можно раскрыть в диаграмме(ах) деятельности. В идеале: для каждого ВИ - по диаграмме. Причем после рисования диаграмм деятельности вернуться к ДВИ и поправить её, если нужно. Не стоит пытаться ответить в ДВИ сразу на все вопросы. Лучше если разные диаграммы будут дополнять и уточнять друг друга. Поскольку ВИ должны определять множество действий, лучше если название ВИ будет отражать множественность действий, которые необходимы для его выполнения - т.е. предлагаю не называть ВИ так, чтобы его можно было принять за единичное действие, если на самом деле он подразумевает целый бизнес-процесс.
2. Насколько я понял из ДВИ, на ней представлен бизнес, типа интернет-магазина, связанный с доставкой товара по заказу клиента с оплатой товара через банк. Но ИМХО в представленном виде ДВИ представляет скорее взгляд покупателя, чем продавца. Покупатель не всегда видит, что важная часть работы продавца может быть вынужденно не связана непосредственно с работой с покупателем. Возможность продажи товара представленным на диаграмме образом на регулярной основе, как правило, требует участия других действующих лиц (ролей), помимо приведенных на ДВИ. В частности, лиц, осуществляющих доставку товара потребителю (поскольку для подтверждения получения товара на диаграмме предусмотрен целый ВИ, самовывоз не предполагается в качестве основного варианта?). У продавца должен быть предусмотрен ВИ для управления доставкой товара с участием этого ДЛ (курьер?, транспортная компания?). Также необходимо организовывать поставку товара к продавцу извне, для чего у продавца тоже должны быть свои ВИ, связанные с заказом и доставкой товара от поставщика или со склада магазина. Возможно. взаимодействовать с поставщиком товара должно другое ДЛ, но оно должно координировать поставки товара с продавцом. Еще должно быть лицо, осуществляющее учет операций. Возможно с этим управится бухгалтер, но если управление товарными запасами развернется в целое направление деятельности, он, наверное, будет возражать и настаивать на появлении ещё одно роли. Возможно, с точки зрения представленного на диаграмме бизнеса стоит ДВИ дополнить еще некоторыми ролями и ВИ.
-
1. .... Не стоит пытаться ответить в ДВИ сразу на все вопросы. Лучше если разные диаграммы будут дополнять и уточнять друг друга. Поскольку ВИ должны определять множество действий, лучше если название ВИ будет отражать множественность действий, которые необходимы для его выполнения - т.е. предлагаю не называть ВИ так, чтобы его можно было принять за единичное действие, если на самом деле он подразумевает целый бизнес-процесс.
Возможно Вы и правы. Я думаю Вам и мне не достает каких-то дополнительных сведений, чтобы ясно ответить на поставленные Вами вопросы. Однако следует принять во внимание тот факт, что Ви обычно описываются через цели пользователей. А уровень ВИ (по словам Крэга Лармана) следует определять из понятия элементраный бизнес процесс или одобрения руководством.
"Заказ товара", "Оплата товара", "Доставка(поставка) товара" - вряд ли можно считать элементарными бизнес процессами..
2. Насколько я понял из ДВИ, на ней представлен бизнес, типа интернет-магазина, связанный с доставкой товара по заказу клиента с оплатой товара через банк. Но ИМХО в представленном виде ДВИ представляет скорее взгляд покупателя, чем продавца. Покупатель не всегда видит, что важная часть работы продавца может быть вынужденно не связана непосредственно с работой с покупателем. Возможность продажи товара представленным на диаграмме образом на регулярной основе, как правило, требует участия других действующих лиц (ролей), помимо приведенных на ДВИ. В частности, лиц, осуществляющих доставку товара потребителю (поскольку для подтверждения получения товара на диаграмме предусмотрен целый ВИ, самовывоз не предполагается в качестве основного варианта?). У продавца должен быть предусмотрен ВИ для управления доставкой товара с участием этого ДЛ (курьер?, транспортная компания?). Также необходимо организовывать поставку товара к продавцу извне, для чего у продавца тоже должны быть свои ВИ, связанные с заказом и доставкой товара от поставщика или со склада магазина. Возможно. взаимодействовать с поставщиком товара должно другое ДЛ, но оно должно координировать поставки товара с продавцом. Еще должно быть лицо, осуществляющее учет операций. Возможно с этим управится бухгалтер, но если управление товарными запасами развернется в целое направление деятельности, он, наверное, будет возражать и настаивать на появлении ещё одно роли. Возможно, с точки зрения представленного на диаграмме бизнеса стоит ДВИ дополнить еще некоторыми ролями и ВИ.
[/quote]
С этим трудно не согласиться. И опят все также зависит от уровня той автоматизации, которую подразумевает данная ДВИ. Вряд ли имеет смысл считать ее точной и законченной. С другой стороны она может говорить нам об ограничениях. Возможно вопросы, связанные с доставкой, находятся вне рамок рассматриваемой системы...
-
Возможно Вы и правы. Я думаю Вам и мне не достает каких-то дополнительных сведений, чтобы ясно ответить на поставленные Вами вопросы. Однако следует принять во внимание тот факт, что Ви обычно описываются через цели пользователей. А уровень ВИ (по словам Крэга Лармана) следует определять из понятия элементраный бизнес процесс или одобрения руководством.
"Заказ товара", "Оплата товара", "Доставка(поставка) товара" - вряд ли можно считать элементарными бизнес процессами..
Если исходить из определения спецификации (A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.), то определение, на которое ориентируется Ларман для понимания ВИ, чересчур жесткое. Если спецификация предполагает наблюдаемый результат, то в определении Лармана результат должен быть измеримым, действия должны производиться в одно время и в одном месте. И одним ДЛ. Жестковато. Он и сам абзацем ниже признает, что определение ЭБП скорее соответствует духу, но не букве ВИ.
Если оценивать ВИ с точки зрения ценности результата их завершения для ДЛ на бизнес уровне, то разбиение ВИ "Заказа товара" на ВИ "Заказать товары или услуги" и ВИ "Подтвердить получение заказа" ИМХО снижает ценность этих ВИ, поскольку для покупателя отправка заказа без подтверждения его получения продавцом едва ли может считаться самоцелью и, соответственно, завершенным бизнес-процессом. Подтверждение получения заказа может содержать важные уточнения условий доставки товара продавцом, по результатам которых покупатель может отказаться от покупки (оплаты заказа). Доводы, которые я привожу, относятся к ДВИ, рассматриваемой на бизнес-уровне.
Возможно, детализация ВИ (разбиение на частные ВИ) важна для учета результатов отдельных этапов бизнес-транзакции и в этом смысле представленные на диаграмме ВИ имеют ценность для продавца, как пользователя компьютерной системы. В этом случае, если рассматривать предложенную ДВИ для системного уровня, нанесение рамок системы на ДВИ представляется весьма полезным. Хотя ограничение количества действующих лиц 2-3 персонажами, как правило, действительно вызывает вопрос о полезности рисования ДВИ, особенно по сравнению с другими диаграммами для уровня системы.
-
Так к какому выводу мы можем придти? Просто диаграмма вызывает только неоднозначное ее понимание? Или что и мэтры тоже ошибаются?
-
Так к какому выводу мы можем придти? Просто диаграмма вызывает только неоднозначное ее понимание? Или что и мэтры тоже ошибаются?
Я бы предложил зафиксировать, что:
1. диаграммы ВИ могут соответствовать разным уровням. В спецификации самого UML применение одних и тех же диаграмм для описания ВИ разных уровней, кажется, не артикулированао. Но эта "разноуровневость" используется в методологиях анализа и разработки систем. Эти методологии (RUP и пр.), уже используют UML в качестве инструмента. Методологии описываются в книгах "мэтров", причем каждый "мэтр" демонстрирует авторский подход к использованию и трактовке инструментария UML. Подход Лармана, с моей точки зрения тяготеет к использованию UML на программно-техническом, а не бизнес уровне. Применительно к его трактовке ДВИ ИМХО можно говорить о неоправданном сужении содержания ДВИ. Это скорее не ошибка, а сознательное ограничение себя чересчур жесткими рамками, которые могут затруднить использование ДВИ для понимания анализируемой деятельности.
2. вроде бы предложенная мной интерпретация изображенной на ДВИ деятельности в целом совпадает с Вашей. Во всяком случае наши "неоднозначные" точки зрения касались не сколько того, что изображено на диаграмме, сколько того, что на ней не нарисовано, а также какими именно ВИ наше общее (однозначное?) понимание представленной на ДВИ деятельности может быть изображено.
3. использование ДВИ, как впрочем и других диаграмм UML представляется целесообразным использовать не сколько для описания того, что уже является "общим местом" для участников анализа/моделирования системы, сколько для фиксации разных точек зрения, разного видения анализируемых ВИ для дальнейшего обсуждения. Но видения, возникшего на основе общего для всех участников обсуждения контекста, например автоматизируемой деятельности Заказчика. В этом смысле сначала должен быть предъявлен контекст, на основании которого рисуется ДВИ, затем уже рисуется ДВИ и обсуждается её соответствие контексту. Этот контекст может возникать из обсуждения с ДЛ или из нормативных документов, регламентов Заказчика. Отсутствие реального контекста, общего для нас Вами и с другими участниками обсуждения, затрудняет развернутое обсуждение ВИ. Возможность выявления полезности ДВИ применительно к контекстам типа "наливание чашки кофе" вызывает сомнения.
4. ценность ДВИ существенно зависит от количества ВИ и ДЛ, представленных на диаграмме. ИМХО основная ценность ДВИ - это топология взаимосвязей ВИ и ДЛ: какие ДЛ в каких ВИ участвуют. Понимание в деталях, что стоит за каждым ВИ на ДВИ важно не сколько для "угадывания" правильного названия ВИ, сколько для того, чтобы правильно разграничить ВИ. ВИ Например, глядя на ДВИ удобно обсуждать распределение/разграничение прав в системе для различных ДЛ. Если ДЛ и ВИ мало, тема для обсуждения может отсутствовать - например, все права будут у Продавца.
Возможно, методически более ценно было бы обсуждать ценность не ДВИ самой по себе, а выгоды от использование её совместно с диаграммами деятельности, соответствующими разным ДВИ. Например - как понимание одной диаграммы уточняет понимание другой? И более того - может ли рисование одной диаграммы упростить, ускорить рисование другой, дать понимание некоего свойства, качества системы, которое не может быть получено рисованием этих диаграмм по отдельности ?