powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / UML диаграммы прецедентов
9 сообщений из 9, страница 1 из 1
UML диаграммы прецедентов
    #36405995
Ringnarr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем доброго времени суток!
Я проектирую небольшую информационную систему. Ее я в большей или меньшей степени себе уже обрисовал что в ней будет. Но вот теперь мне нужно начертить диаграммы прецедентов и диаграммы бизнес-прецедентов. По первому пункту я нашел достаточно литературы и в той или иной мере понял как их чертить. Но вот по бизнес-прецедентам я не могу найти ничего путного, все что нахожу под названием диаграмм бизнес-прецедентов в описании полностью совпадает с обычными диаграммами прецедентов. Если кто может объясните мне непонятливому в чем же между ними разница? Ведь она должна быть, особено если учесть что в UML-редакторах в разделе Use-Case есть как элементы с меткой "Business", так и обычные. Заранее благодарен за ответы.
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36406575
divv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ringnarrя в большей или меньшей степени себе уже обрисовал что в ней будет. Но вот теперь мне нужно начертить диаграммы прецедентов и диаграммы бизнес-прецедентов.
Если Вы уже себе все обрисовали что будет в системе, то зачем Вам теперь рисовать диаграммы прецедентов? Диаграммы - это инструмент выяснения того, что должно быть.

Или у вас заказчик требует, чтобы эти диаграммы были в документации?
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36406806
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Например, есть прецедент "Смена пин-кода на банковской карточке"
С точки зрения бизнеса этот прецедент выполняется кардхолдером (Бизнес-Актор - это Кардхолдер, Бизнес-прецедент - это "смена пин-кода")
С точки зрения системы этот прецедент выполняется сотрудником (Систем-Актор - это сотрудник банка, систем-прецедент - это "смена пин-кода")

То есть принципиально отличие в том, что в одном случае прецедент - это цель действующего лица, а в другом случае - это фактически требование к системе (то что система обязана предоставлять).
Соответственно, это моделируется в разных процессах: бизнес-моделирование (бизнес-прецеденты) и моделирование требований к системе (системные прецеденты).
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36409825
CountZerro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
RingnarrВсем доброго времени суток!
Я проектирую небольшую информационную систему. Ее я в большей или меньшей степени себе уже обрисовал что в ней будет. Но вот теперь мне нужно начертить диаграммы прецедентов и диаграммы бизнес-прецедентов. По первому пункту я нашел достаточно литературы и в той или иной мере понял как их чертить. Но вот по бизнес-прецедентам я не могу найти ничего путного, все что нахожу под названием диаграмм бизнес-прецедентов в описании полностью совпадает с обычными диаграммами прецедентов. Если кто может объясните мне непонятливому в чем же между ними разница? Ведь она должна быть, особено если учесть что в UML-редакторах в разделе Use-Case есть как элементы с меткой "Business", так и обычные. Заранее благодарен за ответы.

Нормальное описание бизнес-моделирования в UML есть в RUP (в ихнем HTML - справочничке). Только нужна не свободно-скачиваемая версия (откуда они этот раздел удалили жмоты), а полная версия.
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36411009
Ringnarr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Big17
То есть принципиально отличие в том, что в одном случае прецедент - это цель действующего лица, а в другом случае - это фактически требование к системе (то что система обязана предоставлять).
Соответственно, это моделируется в разных процессах: бизнес-моделирование (бизнес-прецеденты) и моделирование требований к системе (системные прецеденты).

Ага. То есть в одном случае мы рассматриваем людей-актеров, а в другом актерами выступают некоторые функционалы приводящие в действие систему, причем сами прецеденты могут быть идентичными. Я правильно понял?

divv
Или у вас заказчик требует, чтобы эти диаграммы были в документации?
То-то и оно что требует руководитель).

CountZerro
Нормальное описание бизнес-моделирования в UML есть в RUP (в ихнем HTML - справочничке). Только нужна не свободно-скачиваемая версия (откуда они этот раздел удалили жмоты), а полная версия.
Понял будем искать)).

Всем спасибо за советы!
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36411142
CountZerro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Big17Например, есть прецедент "Смена пин-кода на банковской карточке"
С точки зрения бизнеса этот прецедент выполняется кардхолдером (Бизнес-Актор - это Кардхолдер, Бизнес-прецедент - это "смена пин-кода")
С точки зрения системы этот прецедент выполняется сотрудником (Систем-Актор - это сотрудник банка, систем-прецедент - это "смена пин-кода")

То есть принципиально отличие в том, что в одном случае прецедент - это цель действующего лица, а в другом случае - это фактически требование к системе (то что система обязана предоставлять).
Соответственно, это моделируется в разных процессах: бизнес-моделирование (бизнес-прецеденты) и моделирование требований к системе (системные прецеденты).

Верно все выше написано, но чуть добавлю:
граница системы в бизнес-модели - предприятие или подразделение, в просто модели - информационная система.
Акторы в бизнесе - это как правило внешние контрагенты (поставщики, клиенты, контрагенты, банки и т.п), в просто - пользователи системы - операционисты, менеджеры, кассиры и т.д (в бизнес - модели им как правило соответствуют бизнес-исполнители business-worker - на диаграмме активностей им выделяют свои плавательные дорожки) - не обязательно кстати это всегда люди, это могут быть внешние ИС или автоматы.
Бизнес - прецедент не обязательно соответствует прецеденту один в один - он может быть больше.
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36411193
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RingnarrЯ правильно понял?
Да, все правильно

CountZerro
Верно все выше написано, но чуть добавлю:
граница системы в бизнес-модели - предприятие или подразделение, в просто модели - информационная система.
Акторы в бизнесе - это как правило внешние контрагенты (поставщики, клиенты, контрагенты, банки и т.п), в просто - пользователи системы - операционисты, менеджеры, кассиры и т.д (в бизнес - модели им как правило соответствуют бизнес-исполнители business-worker - на диаграмме активностей им выделяют свои плавательные дорожки) - не обязательно кстати это всегда люди, это могут быть внешние ИС или автоматы.
Бизнес - прецедент не обязательно соответствует прецеденту один в один - он может быть больше.

Можно еще добавить, что при переходе от бизнес-моделирования к моделированию системных прецедентов Business Worker как правило (но не всегда!) становится System Actor'ом.
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36424114
Фотография byur
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разница в business use cases и system use cases в их scope (область действия/применения, видимо так можно перевести в данном контексте). В случае бизнес-юзкейсов, в качестве скоупа выступает ОРГАНИЗАЦИЯ (или ее часть, например подразделение организации) в целом, Экторами являются внешние, по отношению к организации сущности - например, клиенты, регулирующие органы, партнеры, поставщики и т.п. В случае системных юзкейсов - их скоуп - создаваемое вами ПО. И его экторами будут уже внешние, по отношению к ПО сущности - суть пользователи, другое ПО, hardware и т.п. ...

Например, если вы как клиент банка пришли взять кредит, то бизнес-юзкейсом будет для вас как для бизнес-эктора - "Получить кредит", но в рамках этого бизнес-юзкейса, будет существовать один или более системных юзкейсов, относящихся, для простоты скажем к АБС банка, где клерки банковские (будучи уже экторами системы), взаимодействуя с системой будут иметь юзкейс системного уровня, типа "Оформить получение кредита".

Такой стереотип, как бизнес-юзкейс имеет смысл использовать в случаях комплексной автоматизации, когда нам нужно понимать как устроена и как работает организация/подразделение, чтобы более детально понимать как основные бизнес-процессы (точнее, их "проекция", выраженная в формате целей экторов по отношению к организации - суть бизнес-юзкейсов) будут отражены в различных (или в вырожденном случае в одной) системах.

RingnarrВсем доброго времени суток!
Я проектирую небольшую информационную систему. Ее я в большей или меньшей степени себе уже обрисовал что в ней будет. Но вот теперь мне нужно начертить диаграммы прецедентов и диаграммы бизнес-прецедентов. По первому пункту я нашел достаточно литературы и в той или иной мере понял как их чертить. Но вот по бизнес-прецедентам я не могу найти ничего путного, все что нахожу под названием диаграмм бизнес-прецедентов в описании полностью совпадает с обычными диаграммами прецедентов. Если кто может объясните мне непонятливому в чем же между ними разница? Ведь она должна быть, особено если учесть что в UML-редакторах в разделе Use-Case есть как элементы с меткой "Business", так и обычные. Заранее благодарен за ответы.
...
Рейтинг: 0 / 0
UML диаграммы прецедентов
    #36424116
Фотография byur
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
byur,

а вообще, для обсуждения подобных вопросов есть форум на www.uml2.ru, там вы можете быстрее получить квалифицированный ответ по данной тематике.
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / UML диаграммы прецедентов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]