Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: bas от 22 Декабря 2006, 13:03:51
-
Вроде у меня все улеглось про ДВИ, масштаб (scope) и актеров в голове, но тут опять двадцать пять.
Пробла в следующем:
1. Есть некий БВИ - "Получить отчетность"
2. Есть его сценарий/реализация:
«Клиент» связывается с сотрудником «БО Банка».
Сотрудник «БО (бэк-офиса) Банка» идентифицирует «Клиента» по его полному ФИО и ключевому слову.
«Клиент» запрашивает отчет за указанный период у сотрудника «БО Банка» по определенному Счету. Список предоставляемых отчетов следующий:
• Состояние Счета
• Открытые позиции
• Закрытые позиции
• Margin Call
• Транзакции по Счету
Сотрудник «БО Банка» запрашивает у Системы данный отчет, получает и сохраняет его.
Сотрудник «БО Банка» отправляет отчет по электронной почте
«Клиент» получает запрошенный отчет.
Так вот, я думаю/думал, что на БДВИ надо показать только одного актера - Клиента. А уже сотрудника "БО Банка" - это бизнес вокер (bussines worker), и он появляется только при реализации данного БВИ.
Юрий говорит, что нужно на БДВИ показать и сотрудника "БО Банка", т.к. это уже маштаб/scope - Система, но с точки зрения Бизнеса. Т.е. мы написали уже как сотрудника "БО Банка" взаимодействует с Системой, для нужд Клиента.
Так вот хотелось бы услышать мнения согласных/не согласных. И четкое описание Юрия по данному вопросу.
-
Оригинальная автоматизация, не лечь не встать:)
Как насчет банального запроса этого отчета при помощи е-маила? не говоря уже о web энде для клиентов банка?:)
Думаю можно и так и так. Смотря на что упор делать:
1. Отчет этот делать сотрудник может те только клиенту, но и контролирующим органам, и др. лицам. По запросу все это делает, запрос идет не через систему а через самого оператора.
2. Клиент имеет право работать с системой, например получать отчет по запросу. Запрос временно или по причинам безопасности\бюджета делается через другого актера (служащего банка, оператора). Отправка е-маила автоматическая и входит в систему. Если нет, то тогда клиент никак не завязан на систему, связь имхо просто с сотрудником. А сотрудник (оператор) может работать с системой.
Хотя я так понимаю мы бизнес модель делаем? Возможно такой подход не применим, и он чисто системный.
Вобшем первый вариант:
актер работник банка + показать взаимодействие с клиентом, и другими внешними просителями информации.
Второй вариант: Клиент актер, оператора как bussines worker
Жду комментов:)
-
Ну данный вопрос родился в принципе из того, что нужно нарисовать две модели БП - "as is" и "to be".
Т.е. в первом посте был БП "as is".
Вот что стало с "to be":
«Клиент» заходит на Интернет сайт Банка
«Клиент» авторизируется на Интернет сайте Банка
«Клиент» выбирает нужный ему отчет за период по определенному Счету из предлагаемого списка:
• Состояние Счета
• Открытые позиции
• Закрытые позиции
• Margin Call
• Транзакции по Счету
Интернет сайт Банка отображает выбранный отчет
«Клиент» печатает или сохраняет отображенный отчет
Просто с "to be" все понятно, тут нужно просто показать актера - Клиента и все.
Вопрос родился в контексте того, что если на БДВИ "as is" мы показываем только одного актера - Клиента, что с моей т.з. правильно, то БДВИ "as is" и "to be" не будут отличаться, а будет отличаться только реализация данных БВИ.
-
Вобшем первый вариант:
актер работник банка + показать взаимодействие с клиентом, и другими внешними просителями информации.
Второй вариант: Клиент актер, оператора как bussines worker
Жду комментов:)
Первый вариент - это Системный ВИ получается, т.к. это уже как непосредственно сотрудник работает с Системой, а что там с Клиентом происходит, нам до фене.
Второй я как раз и предлагаю, но BW (бизнес вокер) не показывается на БДВИ, а показывается на Д реализации БВИ
-
Ну так тогда простой вопрос, бизнес модель меняется при переходе с "as is" к "to be"?
Отсюда и ответ как рисовать:)
П.С. А я уж думал что мы жили живем и будем жить в каменном веке:) ну в том смысле что ваш "as is" будет разрабатываемой системой. Был немного в шоке:)
-
Ну так тогда простой вопрос, бизнес модель меняется при переходе с "as is" к "to be"?
Отсюда и ответ как рисовать:)
Не обязательно. Так же как модель может не поменяться при переходе от БМ к СМ, сама модель может не поменяться, а реализация может/должна поменяться.
Тут надо исходить от другого - как правильно показать актеров на БМВИ "as is".
П.С. А я уж думал что мы жили живем и будем жить в каменном веке:) ну в том смысле что ваш "as is" будет разрабатываемой системой. Был немного в шоке:)
Я так и понял, поэтому пояснил :)
-
Ну вообщем-то я в RUP дуб дубом, так что не претендую на правоту и т.п.
Не обязательно. Так же как модель может не поменяться при переходе от БМ к СМ, сама модель может не поменяться, а реализация может/должна поменяться.
Тут надо исходить от другого - как правильно показать актеров на БМВИ "as is".
Я о БМ и говорю. Сравните Бизнес Модель которую вы делаете с той которая была.
Что-то поменялось? Актеры поменялись? Как по мне так да.
Значит и рисовать их нужно соответствующе...
-
Я о БМ и говорю. Сравните Бизнес Модель которую вы делаете с той которая была.
Что-то поменялось? Актеры поменялись? Как по мне так да.
Значит и рисовать их нужно соответствующе...
Так в том то и дело, что по моему мнению в "as is" сотрудник - это не актер на БДВИ, а бизнес вокер, который на БДВИ не показывается.
Мое обоснование такое:
Для БМ масштаб/scope - это организация (или отдел организации, смотря что мы моделируем). Поэтому мы НЕ показывает на БДВИ тех лиц, которые работают внутри организации, а эти люди - это бизнес вокеры, которые, по РУП, показываются на Д реализации БВИ или просто в спецификации БВИ. На БДВИ показываются только актеры, которые являются ВНЕШНИМИ сущностями по отношению к организации.
Юрий Булуй (возьмем его, как эксперта в этой области) говорит, что можно так и так. Так вот хотелось понять точно когда так, а когда иначе, именно применительно к БВИ "as is"
-
Вот мое мнение. Что такое БВИ - это как внешние сущности используют систему. Что есть система? это банк, что есть внешняя сущность в даном случае - это клиент. Кто такой сотрудник банка? - это исполнитель БВИ.
Когда мы приняли решение заменить сотрудника банка - живого, на программу (которая фактически) заменяет его мы ничего не изменили по сути, нет тут новой модели бизнеса, как было так и осталось.
Однако если при этом меняется
1. технологический цикл работы сотрудника банка, то по моему это и будет рассматрением аз из и ту би
2. что-то меняется в принципе получения отчета вообще для клиента - это тоже предмет реинжиниринга,
А у тебя Саша - ну нет никакого реального модифицирования бизнес-модели. Она была одна
клиент обращается с запросом и получает отчет. Что тут меняется? Ничего...
А значит и нет никакого ту би,
С точки же зрения реализации процесса, естественно был ручной труд стал электронный на лицо прогресс и снижение себестоимости
Конечно ты скажешь, мы теперь можем уволить сотрудника А которому платили В, и отдади эти В разработчику С, который будет нас держать на крючке, если он не дурак:-))
-
2 Galogen,
Т.е. ты предлаегаешь расмотреть Банк как черный ящик?! Но тогда как мы будем описывать бизнес-процессы внутри Банка, т.е. что там внутри происходит?
Т.е. на лицо все таки изменение БП в самом Банке, не так ли? Как мы это покажем?
-
Саша. RYP процесс утверждает, а UML полагает, что Бизнес-модель есть совокупность двух моделей модель бизнес-процессов(ВИ) и модель бизнес-объектов.
1-ая есть внешнее представление о системе, фактически желания других в использовании системы
2-ая есть реализация этих ВИ и является внутренним представлением системы, т.е. Ви реализуется через взаимодействие бизнес-актеров, бизнес-вокеров и бизнес-сущностей, который в свою очередь могу дополняться моделями взаимодействия. Вот
-
Ну в общем мы с тобой на одном мнении стоим:
1. Бизнес Диаграмма ВИ не изменилась при переходе от "as is" к "to be", т.е. на ней мы показывает одного актера (Клиента) и один ВИ ("Получить отчетность")
2. Изменилась только реализация БВИ "Получить отчетность"
-
очевидно, так и есть
-
Что я хотел сказать ...
1. Мы можем отобразить Клерка как эктора на диаграмме, в том случае, если он является secondary actor, т.е. при условии, что Клиент и Клерк взаимодействуют через scope. Такая ситуация возможна при условии существования, например, системы где в одном или нескольких шагах юзкейса "мяч" оказывается на стороне Клерка (т.е. долежен сделать какие-то телодвижения в рамках сценария(ев)), чтобы Клиент мог продолжить выполнение сценария. В общем виде -- когда происходит взаимодействие двух (или более) разных сущностей, посредством того что в scope, в рамках конкретной цели.
2. У Коберна есть такая вещь как идентификация internal actor ... но он эту тему у себя не развивает сильно, просто декларирует, что да ... есть. В тексте юзкейса он их явно выделяет (именует). Это IMHO некий аналог бизнес-вокера в RUP. На диаграмме он этого не показывает ... известно как он относится к UC диаграммам :-). Но это не secondary actor! Можно ли в таком случае показывать его на диаграмме. По-умолчанию -- нет, но допускаю возможность если показать сего с определенным стереотипом :-), это не запрещено, но IMHO изврат.
3. Если выбросить из головы Коберна с его white и black boxes, и бизнес доменом и системным доменом ..., то на диаграмме BUC, будет только Клерк, и все. Разницу в б/п можно показать только на activity диаграммах, либо на реализации юзкейса
-
Юра, при всем к тебе уважении, ну прочитай еще раз свой текст. Если честно, ты сам себе противоречишь. С одной стороны рассуждаешь о возможности присутствия на диаграмме Клерка в роли второстепенного члена, но не исполнителя. А в конце концов делаешь вывод: на диаграмме BUC будет только Клерк. Это как понимать? Неужели весь этот процесс затевается лишь для того, чтобы Клерк мог сделать свои телодвижения? Кто такой клерк? это работник банка, КАдры решают все! Согласен, но ... вспомним будущее.. вместо клерка сидит робот-человек, как тут?
Думаю все-таки надо разделять это, а не "класть яйца в одну корзину" (с).
Думаю второстепенные члены или роли, это все-таки не те кто исполняют ВИ, а те кто могут в нем участвовать опосредственно, или явно, но которые нам сейчас особо не важны. Но влияние которых учесть хотелось... Например в том же UC Формировать отчетность, можно предусмотреть доставку отчетов через курьера, где курьер сторонняя фирма.
-
Юра, при всем к тебе уважении, ну прочитай еще раз свой текст.
Тьфу, блин ... совсем сдурел ... это чистая оговорка (точнее опечатка?) ... Клерк, Клиент ... оба на букву "К", да и время было 2 ночи .... виноват ... что-то я переутомился похоже :-), ну скоро отдохну :-).
Конечно же я имел ввиду КЛИЕНТА!!!! ... сорри ...
-
Вот именно предследовать свои цели. какая же цел у клерка в данной ситуации? О конечно наилучшим образом выполнить заказ клиента, чтобы не уволили, чтобы дали большую зарплату и т.д.
Все-таки должна быть какая-то строгая грань, когда того же клерка включаем в UC, а когда исключаем.
В этом отношении мне нравится как описано в книге Нейбурна и Максимчука - Использование UML для разработки БД.
Бизнес-уровень - только внешние по отношению системы сущности. они появляются на BUC, исполнители появляются в диаграмме деятельности и бизнес-объектов.
Системный уровень - BUC превращаются в подсистемы (необязательно все)
Исполнители в актеров и UC, если часть функций испольнителя автоматизируются, либо вообще превращается в вариант использования. бизнес-актеры могут становится исполнителями - актерами системного уровня, либо превращаться в классы-сущности
Такой подход мне понятен - он прозрачен и показывает суть перехода от бизнес-уровня к системному, а также позволяет использовать информацию бизенс уровня - в системном.
Ваше слово, сударь:-)
-
Вот опять все зависит от точки зрения человека, реализующего модель.
Вот считает этот человек, что так логично - будет так, не считает будет по другому.
Скажет мой студент на зачете, а чего вы придераетесь, я так полагаю. Как вы докажите обратное.
Все время разговаривая о моделировании мы можем найти сотню аргументов как за так и против той модели, которую мы рассматриваем. Тогда о чем спорить? Один считает так как считает - ну и на здоровье, другой считает по-другому, ай молодец.
Как мы проверим что есть правда? Да никак! Нужно построить систему, проверить ее в жизни, но сорри - жизнь то одна,... как быть?
Думаю что-то не правильно в королестве датском...
-
Подолью масла в огонь :-) ... нужно помнить про seconary actor, если про Коберна речь ведем ... вот и пример (не помню у него в книге возможно он есть), когда есть коммуникационная система, есть звонящий и есть вызываемый ... они беседуют по телефону. Что будем делать с экторами в этом случае ;-)?
-
Уточнение принимается. Однако в данной ситуации имеет место быть два внешних лица, к системе явного отношения не имеющего. В этом случае естественно, что один актор - инициирующий, другой пассивный, отвечающий. В этом случае один актор использует систему, чтобы общаться с другим. Таких примеров можно привести массу. Однако, если рассмотрим коммутирующую систему, в которой используется человеческий труд для коммутации абонентов, то очевидно, оператор есть исполниетль, часть системы, ее персонал.
Все таки нужно строго отделять - персонал системы и внешних акторов, какого бы типа они не были.
На уровен бизнеса, раз уж мы используем такую терминалогию, все участники процесса (но не исполнители) могут и должны отображаться. Исполнители появляются на диаграмме деятельности или бизнес-объектов. Что вполне логично и очевидно.
На мой взгляд - это очень сильная сторона UML. Ни IDEF, ни DFD к сожалению не имеют средств разграничения.
Хотя в IDEF есть механизм, все-таки это тол ко исполнители, внешние лица остаются за кадром, более того мы вынуждены учитывать только 1 точку зрения. В DFD правда можно указывать исполнителя процесса, а внешние сущности суть бизнес-акторы. Но опять же это не столь очевидно, и скажем BPwin, этого не поддерживает.
Напротив в ВИ мы имеем разные точки зрения в одной диаграмме, что дает более реальное и естественное представление и системе
-
вот в качестве домашнего задания:-)
5. Рассматривается процесс телефонного разговора с использованием обычной телефонной сети. Объектами являются: два абонента А и Б, два телефонных аппарата, коммутатор и сам разговор как объект моделирования. Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата первым абонентом. Тем самым он посылает сообщение телефонному аппарату, которое переводит этот аппарат в активное состояние и вызывает действие - подачу тонового сигнала в телефонную трубку для первого абонента. Следующее действие также инициируется первым абонентом - набор цифр телефонного номера. После набора цифр номера телефона аппарат рекурсивно вызывает процедуру посылки коммутационных импульсов на коммутатор. Последний инициирует создание нового объекта в моделируемой системе - телефонного разговора. «Разговор» посылает сообщение второму телефонному аппарату на выполнение действия - звонка вызова, при этом второй абонент снимает трубку. Устанавливается прямое соединение между абонентами А и Б. После того как абоненты опустят трубки, разговор заканчивается, тем самым объект "разговор" уничтожается. Выполните моделирование разговора с помощью диаграммы последовательности.
-
2Юрий Булуй, смотря что из этого System Under Construction или рассматриваемая система. Если система - это коммутатор и телефонная сеть, то основной актер - это звонящий он инициирует действия и имеет ЦЕЛЬ, дополнительнгый актер - вызываемый - он ыне системы и имеет свой ИНТЕРЕС, в соответствии с которым будет развиваться сценарий и система должна учитывать не только ЦЕЛЬ, но и ИНТЕРЕСЫ всех актеров.
1. Каков интерес secondary actor и как этот интерес влияет на сценарий? (думаю имеет смысл это озвучить в рамках обсуждения)
2. Отображение на диаграмме в этом примере (secondary actor), и в оригинальном (с Клерком как бизнес-вокером) ... просто есть один подход, со стереотипами ... интересно узнать ваши предположения на эту тему, т.к. эту идею пока никто не стал развивать.