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

ДИ не предназначена для того, чтобы описывать "взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) ". Стандартом UML определено единственное возможное отношение между ДЛ - обобщение, которое нужно для уменьшения количества ассоциация между ДЛ и ВИ на диаграмме.

Как отразить условия осуществления, ветвления последовательности осуществления ВИ при выполнении invoke и precede?

Это не та задача, которую должна решать ДИ

ДИ не предназначена для того, чтобы описывать "взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) ". Стандартом UML определено единственное возможное отношение между ДЛ - обобщение, которое нужно для уменьшения количества ассоциация между ДЛ и ВИ на диаграмме.

Это не та задача, которую должна решать ДИ

Это не так - см . (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, N o v e m b e r 2 0 0 7 )
 
16.3.6 UseCase (from UseCases)

Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...

Т.е. cубъект ВИ - экземпляр класса ДЛ может обладать поведением, которое он может осуществлять во взаимодействии с другими ДЛ.

Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ  для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.

Shur, у меня такое ощущение, что вы просто не поняли, что такое subject в UML.
Привычное нам отношение subject-object (subject - тот кто делает, а object - тот над кем совершается действие) здесь не работает.

Просто процитирую спеку.

The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors.

Subject это сама система, которую вы моделируете и которую на ДИ можете нарисовать в виде прямоугольника поместив туда ВИ и оставив ДЛ за бортом.

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

Уфф. Прочитал мнения участников дискуссии...

О диаграммах вообще. Чем диаграмма отличается от текста? Зачем вообще информацию изображают геометрически? Чем график лучше (или хуже) таблицы?

Резюме ответов на эти вопросы: так принято, так положено по инструкции, мы к этому привыкли и нам так удобнее...

К примеру, пошел я в магазин. Купил там электрическую дрель (желательно хорошую, подороже). Принес ее домой и стал пользоваться ей как молотком, гвозди в стену вбивать. Приноровился, привык и инструмент этот стал мне удобнее молотка. Всем рекомендую! На этом не остановился. Теперь все мои подчиненные должны точно так же прибивать гвоздики. Передовой опыт распространил на партнеров и контрагентов. Теперь акт приемки-сдачи не будет подписан, если гвозди на объекте приколачивались неправильно. Вытащить все, приколотить правильно! и т.д. и т.п.

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

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

Так зачем нужны все эти графики, схемы, диаграммы, в чем их потенциальные возможности?

(Это можно объяснять по-разному. Здесь воспользуюсь метафорой правого-левого полушарий.) Геометрические средства представления информации нужны для активизации образного мышления, для того чтобы задействовать в работе, в решении проблемы правую половину мозга. Зачем?

• Как минимум, чтобы синхронизировать правое полушарие мозга с левым, чтоб не мешало, не отвлекало, не уводило в сторону. При отсутствии нагрузки, правое полушарие очень сильно мешает работе, которую выполняет левое полушарие, вторгается, рассеивает внимание, не дает сконцентрироваться на проблеме и т.д. Левое полушарие мало того, что решает задачу, так еще должно бороться с помехами, создаваемыми правой половиной мозга. Поэтому нужно загрузить образное мышление хотя бы данной темой.
• Как максимум, загрузить правое полушарие такой задачей, с которой оно справляется лучше и эффективнее, чем левое. И тем самым увеличить продуктивность своей работы.

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

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

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

Без такого образного рассмотрения диаграмм, схем, графиков и пр. все усилия на их рисование - это пустое, бессмысленное занятие, мартышкин труд. В этом случае я против диаграмм Если все равно предполагается только аналитическая работа, то текст лучше. (Гвозди правильнее забивать в стену молотком, а не чем-то еще.)

Что касается UML. Тут все то же самое. Мне попадалась работа, в которой автор заявлял, что знает как правильно оптимизировать диаграмму классов. И понимал под этим задачу кройки и шитья, наиболее плотную упаковку вот этих прямоугольников на листе формата А4. И такое упакованное нечто называется идеалом диаграммы классов. Это даже не смешно.

Но из всех видов диаграмм особое место занимают ДВИ. Вот этот символический человечек (не кружок или прямоугольник!!!) используется на диаграмме для чего? Тут прямо указывается тому, кто диаграмму будет рассматривать, чтобы он попытался сам стать этим человечком. Увидеть себя таким, как будто с тобой в реальности происходит то, что на диаграмме нарисовано, все эти связи и отношения.

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

Shur, я совершенно не против вашей точки зрения, но надо понимать, что вещи надо использовать по назначению. Конечно спека UML не идеальна, но спека написана для производителей инструмента, а не для пользователей. Для пользователей написаны другие книги (Руководства пользователей).

Если используется UML, то надо понимать для чего он предназначен.

“UML – графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем”
Г. Буч

Если задача не вписывается сюда, то оригинальный UML вам не нужен. Может какой-нибудь его profile, но не оригинальный UML.

Уфф. Прочитал мнения участников дискуссии...

Типа, чем бы дитятки не тешились?

Итак, резюмируем.

Ясный плюс с позиции tolldo.

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

Вопрос будет ли играть диаграмма ту же самую роль в случае чтения документации?

Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...

Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.

Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.

Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ  для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.

Варианты использования могут применяться как (и) для точного определения (внешних) требований к объекту(предмету) (вообще), так и (и) для точного определения функциональности, предлагаемой объектом (предметом). Кроме того, ВИ также устанавливают требования (тут явно что-то пропущено. союз, запятая, предлог), которые указанный объект (предмет) ставит перед своим окружением, определяя, как они (интересно кто эти они?) должны взаимодействовать с (этим) объектом (предметом), чтобы он (этот самый объект) был в состоянии выполнить взятые на себя обязательства (свои сервисы-услуги)

Вот как тут после этого друг друга понимать

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

Ida, простите, но это демагогия. Для того чтобы научиться пользоваться инструментом, нужно точно понимать его назначение и правила его применения. Мне кажется, как раз это мы и пытаемся выяснить, поскольку на форуме существуют две диаметральные точки зрения КОНКРЕТНО на ДВИ.

Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.

Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.
Варианты использования могут применяться как (и) для точного определения (внешних) требований к объекту(предмету) (вообще), так и (и) для точного определения функциональности, предлагаемой объектом (предметом). Кроме того, ВИ также устанавливают требования (тут явно что-то пропущено. союз, запятая, предлог), которые указанный объект (предмет) ставит перед своим окружением, определяя, как они (интересно кто эти они?) должны взаимодействовать с (этим) объектом (предметом), чтобы он (этот самый объект) был в состоянии выполнить взятые на себя обязательства (свои сервисы-услуги)

Вот как тут после этого друг друга понимать

Sorry, если я Вас запутал.
*Если трактовать спецификацию так, настаивает Денис, то обе цитаты описывают поведение компьютерной системы с внешними по отношению к системе ДЛ. Некоторая проблема возникает, если компьютерной системы еще нет, но об этом ниже...
**Во второй цитате, ВИ взаимодействуют с субъектом-системой и на характер этого взаимодействия (поведения) ВИ накладывают требования (своим существованием).

В спецификации в разделе Notation для ВИ сказано - что
"A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier."
Из спецификации следует, что система-субъект не обладает ВИ. ВИ просто применяются к системе-субъекту!ИМХО это снимает кажушуюся "кривизну" формулировки цитаты про environment из спецификации.

Т.е. в самой спецификации противоречий (во всяком, случае, вопиющих:) не видно. ИМХО разлчие мнений о полезности или способах использования ДВИ имеет очень косвенное отношение к вопросу о точности опсания ВИ и ДВИ в спецификации. Но имеет непосредственное отношение к вопросу применения ДВИ на практике. Причем применения ДВИ для описания не собственно компьютерной системы (она может даже не существовать на момент анализа бизнес и рисования ДВИ), а для описания деятельности, которую еще только предстоит автоматизировать. Я предложил трактовку спецификации, которая устраняет необходимость рисования диаграммы про то, чего еще нет. И трактовать ДВИ как диаграмму описывающую вазимодейсстве ДЛ с системой действующих лиц. Систему, представляющую собой предприятие заказчика, логику его работы, значимую для реализации системы.  Видимо, не случайно процитированная Денисом точка зрения Г.Буча в коллективном труде отцов-основателей - Г. Буч, Д. Рамбо, А. Джекобсон Язык UML Руководство пользователя" звучит в виде:
"Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит, программному обеспечению." Т.е. большая роль принадлежит ПО, но им не исчерпывается.

Galogen, прощаю
А на мой взгляд, демагогия - это то, чем занимаетесь вы. Почему ни у кого не возникает желания взять веник и начать его рассматрвиать, задаваясь вопросом - а правильно ли мы его используем, а нужен или он вообще?... Вероятно, потому, что все, кто умеет пользоваться веником, уже давно успешно им пользуются, какие бы точки зрения на него в природе не существовали. Им ведь можно и от мух отмахиваться. И как средство самообороны использовать.

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

Если тебе это не интересно — не участвуй в дискуссии.
Contribute or GTFO

Читая книгу Айвара Якобсона, Грэди Буча, Джеймс Рамбо "Унифицированный процесс разработки программного обеспечения", я вижу, что не имеет смысла так драматизировать ситуацию относительно ДВИ.

Вполне возможно сама по себе ДВИ на ранних стадиях анализа, в первичной работе аналитика (то что у нас обычно возникает при обращении студентов на форуме) ДВИ мала пригодна как инструмент отображения контекста. Ясно, что этот контекст уточняется итерационно.

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

Почему? Да хотя бы потому, что графические образы проще трассировать. Графические образы проще использовать повторно.

Например, гораздо проще представить, чем описать картинку UCDPN1

А картинка UCDPN2 - дает сразу логичскую связь между ДВИ и аналитической моделью VOPC

А как использовать такую картинку UCDPN3 или UCDPN4, если бы у нас не было исходной ДВИ?

Т.е. скорее наверное имеет смысл говорить не о + или - самой диаграммы, а способах ее использования или правильном и неправильном ее использовании. Но наверное нужно начинать новую тему? Начнем? И как ее лучше назвать?

Не влезло в предыдущий

Ну и в конце, я поступлю как студент. Скажите правильно ли или лучше не так, понятно ли то, что тут изображено UCDPN5? Предлагаю когда будет время, опубликовать ваши описания по диаграмме, как вы ее воспринимаете. Потом сравним...

Читая книгу Айвара Якобсона…

Он Ивар, швед.

Он Ивар, швед.

Ага ты прав, просто я что-то не обратил внимание когда сдирал библиографии книги