В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы.

Tinner, в задании не менее чётко поставлена и другая задача "Предоставить use case diagram". DeepShadow начал с этого задания, а активити-диаграмму мы пока не обсуждали.

У приведенных мной сущностей есть состояния действий, которые можно отобразить на диаграмме. Тогда почему, в данном контексте нельзя на диаграмме отобразить их на отдельных дорожках?

Состояния можно придумать для многих предметов типа провода, который питает считыватель или дверной замок. Проблема в том что диаграмма ВИ даёт общий обзор функциональных требований к системе и подобные предметы на ней не должны упоминаться.

- Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.

Это не вопрос детализации, а вопрос замусоривания диаграммы неспецифическими для неё элементами. Use Case модель это способ представления функциональных требований к системе. Зачем на диаграмме нужны лишние экторы или ВИ если они не будут реализованы в системе?

- UML - не язык сбора и фиксирования требований, а язык моделирования

Из книги G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide:
"A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system"
Этим авторам я больше верю.

Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте

Что по Вашему "Малая часть UML" и "узкоспециализированный контекст"? Я лишь говорил о том, что у Коберна сама система упоминается как действующее лицо, но разрабатывамая система не является эктором и не отображается на диаграмме ВИ.
Цитата из RUP про эктора: "This artifact defines a coherent set of roles that users of the system can play when interacting with it"
То есть по определению сама система не является эктором.

Tinner, в задании не менее чётко поставлена и другая задача "Предоставить use case diagram". DeepShadow начал с этого задания, а активити-диаграмму мы пока не обсуждали.

Моя диаграмма на 2 странице, ее самой первой обсуждали. Главная задача отобразить процесс когда кто нибудь пытается получить доступ и думаю моя диаграмма отображает это, с учетом всех нюансов сценария

Состояния можно придумать для многих предметов типа провода, который питает считыватель или дверной замок. Проблема в том что диаграмма ВИ даёт общий обзор функциональных требований к системе и подобные предметы на ней не должны упоминаться.

Прошу не путать активити и ДВИ. Использовать разную детализацию в разных диаграммах не преступление. Кроме этого, можно показать на активити диаграмме взаимодействие между компонентами системы, это даст представление о том, что происходит в целом, откуда какие отказы появляются. Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

Это не вопрос детализации, а вопрос замусоривания диаграммы неспецифическими для неё элементами. Use Case модель это способ представления функциональных требований к системе. Зачем на диаграмме нужны лишние экторы или ВИ если они не будут реализованы в системе?

Снова, при чем здесь UC и варианты использования?

Из книги G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide:
"A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system"
Этим авторам я больше верю.

Не вижу противоречия =) Модель, написанная на языке UML для всего этого и предназначена. А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были. И какой бы хорошей не была задумка, когда начинали разрабатывать сам язык UML, он сейчас используется иначе.

Что по Вашему "Малая часть UML" и "узкоспециализированный контекст"? Я лишь говорил о том, что у Коберна сама система упоминается как действующее лицо, но разрабатывамая система не является эктором и не отображается на диаграмме ВИ.
Цитата из RUP про эктора: "This artifact defines a coherent set of roles that users of the system can play when interacting with it"
То есть по определению сама система не является эктором.

Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.

Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

Это я уже добавил, просто не выложилю После действия прочитать карту, у меня идет decision mode - не удалось прочитать карту и на access deny, else и далее как указано.

Сейчас я решил отобразить еще отправку отчета в этой диаграмме, стоит ли? Использую для этого TimeEvent
Пока думаю отобразить как параллельное событие или лучше в конце, как было, добавить снизу отправку. Или вообще не стоит?

Прошу не путать активити и ДВИ.

Прошу извинить. Неверно понял о чём речь.

А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были.

Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.

Значит Джиму Арлоу и Айле Нейштадт вы доверяете больше? Несомненно книга очень полезная, но в чём они не соглашаются с создателями UML и RUP?

Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.

Исходя из данной цели, предлагаю пройтись по заданию:Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

Вы предлагаете выделить элементы с разных уровней абстракции и назвать их действующими лицами. Какими деятельностями на диаграмме деятельности будут заниматься дверь с карт ридером?

Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

А вот это как раз совершенно не важно, почему доступ не получен.
А вдруг клиент приложил к считывателю ботинок, а не карту? Это совершенно лишняя, мусорная, информация, которая усложнит восприятие.
и отображаться она не должна, т.к. сам ВИ "use swipe card" уже предполагает что клиент приложил нужную карту.
Что клиент прикладывал к ридеру до этого (проездной от метро или ботинок) не имеет значения, т.к. НЕ на карту ридер не сработает.