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

Вот это попрошу пояснить. Почему ВИ - это "набор сценариев"? (я не спорю, я хочу понять) Во-первых, если брать диаграмму ВИ в целом, то это скорее перечисление функций (именованных), их обзор так сказать, которые требуются пользователям. Отображение их последовательностей не является назначением данного представления. Да, к нему предусмотрен сопровождающий документ "Сценарий", но это ведь все же только опция, а не одно и тоже. Но о каких "сценариях" тогда идет речь? Ведь сценарии это, суть, последовательности ... Сами элементы диаграммы, эти именованные функции, тоже называются ВИ, только в единственном числе (на данном уровне деталировки). Я знаю, что систему в целом можно представить в виде сценария, например(!), с помощью диаграммы Activity (такие у меня пока примитивные представления сложились). А кроме того, в свойствах каждого из единичных ВИ, присутствует возможность описать его внутренний сценарий. Если вы имеете ввиду, что каждый из прецедентов в диаграмме ВИ таким образом представляет некий сценарий, тогда я вашу фразу понимаю, а если нет - ну тогда значит не понимаю о чем идет речь. Собственно, вот и вопрос для начала: так правильно я понимаю ВИ или нет, и если нет, то в чем ошибка? А еще лучше, если вы не станете отвечать на мои вопросы, которые заведомо содержат новые изъяны, а попробуете просто перефразировать ваше выражение так, чтобы эти вопросы не могли возникнуть.

Вот это попрошу пояснить. Почему ВИ - это "набор сценариев"? (я не спорю, я хочу понять) Во-первых, если брать диаграмму ВИ в целом, то это скорее перечисление функций (именованных), их обзор так сказать, которые требуются пользователям. Отображение их последовательностей не является назначением данного представления. Да, к нему предусмотрен сопровождающий документ "Сценарий", но это ведь все же только опция, а не одно и тоже. Но о каких "сценариях" тогда идет речь? Ведь сценарии это, суть, последовательности ... Сами элементы диаграммы, эти именованные функции, тоже называются ВИ, только в единственном числе (на данном уровне деталировки). Я знаю, что систему в целом можно представить в виде сценария, например(!), с помощью диаграммы Activity (такие у меня пока примитивные представления сложились). А кроме того, в свойствах каждого из единичных ВИ, присутствует возможность описать его внутренний сценарий. Если вы имеете ввиду, что каждый из прецедентов в диаграмме ВИ таким образом представляет некий сценарий, тогда я вашу фразу понимаю, а если нет - ну тогда значит не понимаю о чем идет речь. Собственно, вот и вопрос для начала: так правильно я понимаю ВИ или нет, и если нет, то в чем ошибка? А еще лучше, если вы не станете отвечать на мои вопросы, которые заведомо содержат новые изъяны, а попробуете просто перефразировать ваше выражение так, чтобы эти вопросы не могли возникнуть.

Диаграмма вариантов использования - это что-то вроде оглавления, план будущей книги. А сами варианты использования - текстовое наполнение, главы этой книги.

Вы можете разработать для каждого "яйца" на диаграмме отдельный текстовый вариант использования (в стиле Коберна, например), можете вместо текста нарисовать по диаграмме последовательности или взаимодействия или активности, или по старой доброй блок-схеме алгоритма, а можете передать в разработку и так, если нет явной необходимости "задокументировать всё", а есть уверенность, что разработчики и без дополнительных диаграмм разберутся.

Однозначного соответствия между вариантами использования и классами в большинстве систем, скорее всего, нет. Это разные сущности, Хотя это зависит от выбранной архитектуры, конечно, но мне сейчас как-то трудно представить пример такого соответствия. Скорее, каждый сценарий реализуется взаимодействием множества экземпляров разных классов.

Вопрос взаимодействия диаграмм - вопрос методологии, вопрос технологии использования. Потому Вам следует изучить вопросы методологии разработки в стиле ООП. Без этого знания и понимания основ, у вас не будет движения.

Где-то в какой-то статье о UML был использован в общем-то штамп о том, что типа "не так страшен волк, как его малюют", - возьмите и попробуйте". Я в принципе из этого и исхожу. Мне UML нужен в той мере, в какой он мне нужен, а не я ему (в конечном счете). Я знаю основы ООП, со мной смело можно гаварить о "наследовании, инкапсуляции и полиморфизме ..." (господи, до чего ж длинные слова). Я не знаю ООП так, как его знают программисты, но и они не знают ООП так, как его знаю я, и стоит оставить их без присмотра, как это на каждом шагу вылазит боком. Я не знаю множества деталей использования ООП в коде, но зато я знаю что такое идея и композиция, гармония (баланс) и стиль применительно к структуре объектной модели приложения и/или его компонентов, и к бизнес-архитектуре в целом, что для программистов как правило пустые звуки, потому что этому их не учат, потому что программистская школа слишком молода и у нее еще не успела сложится своя эстетика. Понесло ... Стоп!

В Вашем случае "класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции""
- совершенно не правильный вывод. Спросите себя что делает класс док.Путевка, для чего он предназначен, какова его ответственность?

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

Я думаю тут вам еще мешает что вы мыслите категориями 1С, правильно ли я понимаю?

Относительно 1С совершенно правильно! А вот по поводу "мешает" мог бы поспорить, но лучше не надо... Я действительно являюсь убежденным сторонником той же концепции бухучета и ее воплощения в IT,  которой придерживалась 1С в своих старых бухгалтерских системах. Собственно, первая моя работа в сфере производства ПО, куда меня пригласили в качестве бизнес-аналитика (повезло), подспудно сопровождалась мыслью создать продукт такой же классный, как 1С, но лишенный его недостатков . Тогда еще не существовало 7-ки. Через несколько лет работы (1С7.5 я прозевал) случилось мое знакомство с 1С7.7, и я с изумлением узнал там множество "своих собственных" решений (конвергенция, однако!). Однако к этому времени уже пару лет моя система (ERP) работала на довольно большом предприятии (около 6000 работников, тысячи единиц номенклатуры, несколько десятков одновременно работающих пользователей), где и сейчас работает, где и возник собственно обсуждаемый вопрос. 1С в то время и близко не подходила к подобным масштабам предприятий, да и сейчас только-только подбирается, и никак не подберется ... Но, я думаю, за ней будущее, хотя и не одобряю нового ее, именно концептуально, направления. Вообще, нахожу что в России, в сфере учета, побеждает откровенное невежество, а 1С просто сдалась с этим бороться ...

Michaj, Вы не прочитали сообщение №11?

Но судя по Вашим вопросам, следует еще раз перечитать книги. Причем лучше не книги по UML, а книги по использованию UML. Подойдут книги перечисленные в FAQ сайта. Крэг Ларман в этом случае отлично торкает

<to greesha> но я ведь практически в точности так и трактую понятие "Варианты использования", как вы описали. В чем разница?

Проблема в том, что проковырявшись уже достаточно долго в книгах, факах и хелпах, познакомившись с большим количеством сущностей UML и вооружившись Sparx, я так и не сумел составить какой-либо вразумительный общий образ использования дисциплины (не теории, а практики).

Именно по UML советую прослушать/просмотреть этот курс.

Michaj, Вы не прочитали сообщение №11?

Мой №15, на который я возлагал особые надежды, это именно на №11

... Крэг Ларман в этом случае отлично торкает

Большое спасибо, попробую

Именно по UML советую прослушать/просмотреть этот курс.

На первый взгляд, чрезвычайно интересно и именно то, что мне было надо . Спасибо! Что-то похожее предлагается на Intuit, и я пытался, но то ли там какие-то непреодолимые глюки на очередной страничке, то ли просто мелкое мошенничество, но там затея не удалась ...

... Предусмотрена ли в UML вообще, в CASE-системах в частности, и в EA в частности частности, нотация для явного отображения таких связей? Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?
......

В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

В последующем, при анализе зависимостей (через матрицы или как показано на рисунке), всегда видно, сколько будет стоить. изменение.

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).

В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

В последующем, при анализе зависимостей (через матрицы или как показано на рисунке), всегда видно, сколько будет стоить. изменение.

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).

Спасибо, еще один мазок в создание образа Мотаю на ус ...

<to greesha> но я ведь практически в точности так и трактую понятие "Варианты использования", как вы описали. В чем разница?

Разница, как мне кажется, в том, что use case на диаграмме вариантов использования и use case как способ описания требований к системе - это не совсем одно и то же. Или почти одно и то же, но с разных точек зрения.

Из-за этого и возникает путаница: для кого-то use case это, в первую очередь, сценарий взаимодействия с системой (для тех, кто начинал с Коберна), а для кого-то другого - функция, предоставляемая системой (для тех, кто начал с UML). Однозначного соответствия между ними может и не быть.

Разница, как мне кажется, в том, что use case на диаграмме вариантов использования и use case как способ описания требований к системе - это не совсем одно и то же. Или почти одно и то же, но с разных точек зрения.

Я еще раньше понял, что у ВИ есть оба эти предназначения, но пока плохо представляю, что из этого следует и из-за этого ли возникает путаница. Но, по крайней мере, что путаница имеет место,  значит мне не пригрезилось? В моей диаграмме это точно констатация "функции, предоставляемой системой".

ВИ - это не функция. ВИ - это цель актера, которую система помогает достигнуть своими какими-то действиями. Именно исходя из этого и надо рассматривать ВИ. Никак иначе.

ВИ должен отражать цель. Цель имеют одушевленные предметы или предметы-аватры одушевленных

Связь класса с UC - вполне нормальная вещь, если понятно, для чего она нужна. Что делает ваш класс для UC? Он "аналитический" или относится к тому, что реально есть в коде? Он entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC? Что и до кого вы хотите донести этой связью, поймут ли вас?

В данном случае (но только в данном), класс "док.Путевка" (наследник прототипа "Документ") действительно практически целиком и единолично реализует функционал "Создание партии ..." (т.е., я понимаю, что так бывает не везде и не всегда) и, более того, так "реально есть в коде". Насчет, "до кого хочу донести" и "поймут ли меня" ... видите ли, кроме этих, у меня существует еще один, первичный мотив - я полагаю, с помощью этих рисунков очень удобно думать (придумывать решения). Немаловажно и то, что выяснилось, что в результате, без дополнительных трудозатрат, возникает красивый материал, хорошо воспринимаемый программистами (UC+Activity). Зачем же заниматься почеркушками на бумаге, искать слова для длинных текстов и псевдокодов, если можно делать то же самое весело и сразу в "товарном виде"? Если рассматривать с этой т.з., то так ли уж важно квалифицировать "entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC?" Большая часть из перечисленного - епархия программистов, в этом я им доверяю - поэтому, честно говоря, в этом слабо или совсем не разбираюсь. Неужели мне в UML без этого не обойтись? Надеюсь, что нет.

Опять же, для чего вы используете UC? Они у вас "бизнес", "системные про взаимодействие с actor'ами" или "технические про алгоритмы системы"?

А так ли важно знать это (уметь различать) с самого начала освоения?[/quote]

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

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

Про средства отображения такой связи - в Rational Rose, насколько я помню, была связь через UC Realization, в EA можно рисовать напрямую,

Вот черт! Это же и есть буквальный ответ на исходный вопрос! Действительно, так я еще не пробовал... Попробовал, действительно можно. Единственно, - UC-диаграмма вроде как "засоряется". Поэтому попытаюсь еще разобраться с "но IMHO лучше стереотипировать и комментировать.", но это уже следующий вопрос ...

Чтобы отобразить в EA связь между UC и классом, UC и компонентом - достаточно
- перетащить оба элемента на одну диаграмму из дерева проекта; насколько я пиню, между ними будут доступны связи dependency и trace, но их можно стереотипировать

Действительно, можно это сделать на отдельной диаграмме, чтоб не засорять ни UC, ни Class-диаграм. А может для подобной цели еще и какой-н специальный тип(подтип?) диаграммы предусмотрен, или просто оптимален?

ВИ - это не функция. ВИ - это цель актера, которую система помогает достигнуть своими какими-то действиями. Именно исходя из этого и надо рассматривать ВИ. Никак иначе.

Ну это уже максимализм. Разумеется ВИ это цель. Потому что любой функционал Системы, который предусмотрен для взаимодействия с актором, по определению преследует достижение какой-нить нужной актору цели. Но почему нельзя назвать это "функцией"? Мне кажется, это уже дело вкуса или нюанс конкретного разговора.