Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Виталий Григораш

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
316
Артем, если у Вас трудности с чтением английской литературы, и  есть возможность, купите книжку по UML2 на русском. Я сам использую "UML. 2-е издение" Буча.
Диаграмма обзора взаимодействия (interaction overview) это что-то очень похожее на ДД, но вместо actions и activity на ней используются ссылки на диаграммы взаимодействия (это могут быть ДП, ДК, timing diagram..). Более детально взаимодействие вы расписываете на внутренних диаграммах, а на общей представляете последовательность их вызовов и условия.
Примеры такой диаграммы в аттаче.
На первой используются ссылки на диаграммы, во второй приведены сами диаграммы

ЗЫ Учите английский :) В нашей области без него туго.

317
:)

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

318
Цитировать
business actor
An actor defined as part of a business use-case model. A business actor defines a role that something outside the business (for example an individual, a system, or another business) can play when interacting with the business.

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

ЗЫ Может вы лучше переведете :)

319
Артем, почитайте UML2 Superstructure Specification

320
А как вам такое определение
Цитировать
actor
An element in the use-case model that represents something external to a system. It can represent the role a user plays with respect to the system. It can also represent an external system or an external device.

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

321
Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).
ИМХО, ВИ - это часть системы (я имею ввиду системный уровень - более детальный), поэтому лучше все таки выделять акторов. Я например знаю следующие типы акторов:
1. Время (Таймер) - всегда за границами системы (среда)
2. Событие (Обработчик событий) - В одном ВИ завершилось действие, обработчик событий выявил его и инициировал новый ВИ. Я обычно такого актора не ввожу, а описываю события как предусловия в ВИ или подпотоками одного ВИ.
3. Девайс (Датчик) - например, датчик пожара, сообщает системе что начался пожар, датчик дождя сообщает системе о дожде и в машине начинают работать дворники и тд и тп. Причем датчик может мониторить не внешнюю среду но и состояние системы (обработчик событий - частный случай такого датчика)
4. Внешняя система - посылает инициирующее сообщение
5. Пользователь - инициирует какой-либо ВИ руками, через GUI или какой-нибудь скрипт

Один из способов структуризации модели ВИ - в пакеты по акторам. Чтобы отделить пользовательские от других, можно сгруппировать их таким образом.

322
Павел, это диаграммы одного типа диаграмма коммуникации. На первой используются значки стереотипов и она более абстрактная, чем вторая.
На второй показаны сообщения которые передаются между классами, а на первой нет, тк сообщения я показал на диаграмме последовательности. Все зависит от стиля моделирования.

323
Давайте поговорим про системные варианты использования? Кто, как пишет такие варианты использования? С какой целью и уровнем детализации?
Я пишу такие варианты использования, пытаясь придерживаться схемы RUP. ВИ согласовываются с разработчиками и тестировщиками и на их основе происходит кодирование и тестирование ПО.
Пример описания "классического" системного варианта использования из книги Use Case Modeling прикрепил в виде аттача к сообщению
Тема навеяна обсуждением.

ЗЫ Несколько пояснений к описанию. В фигурных скобках приводятся внутренние точки расширения, так сказать закладки, к которым можно вернутся из других шагов ВИ.

324
Рассмотрим такой вариант. Чтобы открыть дверь, два человека в разных местах должны поднести свои карты к ридерам. При этом один из них дополнительно аутентифицируется по сетчатке глаза, а другой вводит код с клавиатуры.

Как будет выглядеть ВИ с одним актором?
Это будет один ВИ "Получить доступ в помещение", например. Где пользователь будет подносить карту, затем вводить свои данные (глаз или код или еще что-нибудь) и получать доступ. Способы получения доступа можно описать отдельно. Соглашусь с Эдом - могут быть альтернативные потоки.

А вот инстанса ВИ в данном примере будет 2:
Первый - когда Петя (первый инстанс актора) подставляет глаз и происходит проверка его глаза :) (выполняется  сценарий 1)
Второй - когда Вася (второй инстанс актора) вводит код и происходит проверка кода (выполняется сценарий 2).
То что одновременно должны выполняться 2 инстанса - это ограничение (бизнес-правило, так сказать). Согласитесь, что можно придумать и 1 и 3 и 4 и хоть групповую идентификацию? В данном случае просто система будет ждать заданное количество времени (например 1 секунду) и если за это время не придет запрос со второй карты, то "до свидания"

Вопрос здесь именно в том, кому как удобно и для чего применяют ВИ. Я пишу системные варианты использования, довольно подробно описывая все действия пользователя и большое количество альтернативных потоков и эксепшинов, так как по ним сразу кодят разработчики и пишут тест кейсы тестеры (RUP, ICONIX).
Как говорится о вкусах не спорят ;)

325
Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?
Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?

То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?
Диаграмма деятельности это activity (на ней обычно компоненты не показываются) - блок-схема
Диаграмма взамодействия - sequence
Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче

326
Да не плохо вроде. Вот только мне не очень нравится "в любой момент Пользователь может...". Обычно системный вариант использования описывает один сеанс работы с системой (если несколько подходов, то это уже больше похоже на кусок бизнес-процесса или некоторое описание последовательности вызова вариантов использования (такое тоже встречается :))). Именно поэтому я их и разделил...

ЗЫ Ранее я не встречал примеров вариантов использования с двумя активными акторами.

327
:o
Эд, человек ведь новичок. Чего так удивляешься? Я, например, тоже никогда еще в жизни не использовал DFD в практике :)

328
....Нужен один ВИ - "Сформировать (или просмотреть) отчет по НУ", с двумя пользователями - Внеш. система, Просмотреть отчет.
Ну нет же цели просто сформировать отчет, а цель именно его посмотреть. Так?
Наверное ты хотел сказать..."с двумя пользователями - Внеш. система, Пользователь"?
С ВИ могут быть соединены 2 Актора только в том случае, если один из них caller, а другой callee. Два инициирующих актора к одному ВИ - это ошибка. В данном случае и Пользователь и система являются caller, тк начинают ВИ. Как объединить их в один не представляю. Если бы был один актор? то можно сделать CRUD.

PS Давай куда нибудь перенесем дискуссию и еще по обсуждаем? :)

329
...то наверное имеет смысл сделать отдельный ВИ под интеграцию ("Внешняя Система" ---> "Передать данные"), которорый в виде сценария будет описывать передачу верхоуровневых сообщений\данных, а далее их (сообщения) детализировать уже в ФТ.
Пример с проекта. Внешняя система посылает сообщение в нашу систему о начале налоговой проверки. Наша система, получив это сообщение, используя данные нашей системы, формирует специальный отчет, который в дальнейшем могут просматривать пользователи. Те получается, что в данном случае инициирует создание отчета внешняя система, а смотрят отчет пользователи. Я сделал 2 ВИ - Внеш. система --> Сформировать отчет, Пользователь --> Просмотреть отчет
Я прав?

330
2. ВИ - это цель Эктора. У ИС не может быть целей, максимум что у них есть - это задачи и они могут выступать только как вспомогательные Экторы (callee)
Саша, рассмотрим ситуацию: Пользователь внешней системы инициирует какую-то операцию и внешняя система обращается к нашей системе. Мы не знаем, как во внешней системе и что происходит, но мы знаем, что она посылает нам инициирующее сообщение. Мы его обрабатываем и "выплевываем" ответ. По-твоему внешняя система в данном случае не может быть актором? Ведь в данном случае она не является callee.
Вспомни твой пример по продавца конфет и покупателя. У каждого своя цель!!! Цель актора. Цель пользователя, я считаю, это частный случай цели актора. Возможно я не прав, объясните пожалуйста в чем моя не правота.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »