Юра, при всем к тебе уважении, ну прочитай еще раз свой текст.

Тьфу, блин ... совсем сдурел ... это чистая оговорка (точнее опечатка?) ... Клерк, Клиент ... оба на букву "К", да и время было 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), и в оригинальном (с Клерком как бизнес-вокером) ... просто есть один подход, со стереотипами ... интересно узнать ваши предположения на эту тему, т.к. эту идею пока никто не стал развивать.