Злой ты стал Эд Я просто высказал свое мнение, а ты сразу "некто bas" ...
Я просто не понял, что обращался именно к создателю топика.

Надо в общем тему создавать про Науку ....

Злой ты стал Эд

У какой я злой - не подходи а то укушу 

Я просто высказал свое мнение, а ты сразу "некто bas" ...
Я просто не понял, что обращался именно к создателю топика.

Ну это простая художественная обработка текста, чтобы передать эмоциональное отношение:-) Ничего личного, дружище:-))

Надо в общем тему создавать про Науку ....

Для начала надо определится с темой научных изысканий

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

я как раз отношусь к таким "любителям графических образов", и мне подобные игрушки понадобились для улучшения понимания Use Case-а, как средства описания функциональных требований.
Взялся вчитываться в эти Коберновские диаграммы, - и попал в странную ситуацию:
диаграммы есть, - а понимания не добавляют.
Наоборот, переворачивают и те представления, которые сложились при прочтении текстовой части книги.
Начал спрашивать у знающих людей - оказалось, у них такого рассогласования не возникало...
но и особого интереса тоже.
Вывод: разбираться нужно самому, по ходу задавая частные вопросы.

Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.

В оригинале у Коберна написано:
This model fragment expresses that use case is the primary actor's goal, calling upon the responsibility of the system under design (SuD).
Я не силён в английском, но мне кажется, что описание Коберна намного более примитивное по сравнению с тем, что привёл BAS.
у меня здесь вопросы:
- как всё-таки, трактуется стрелочка с закрашенным треугольником на конце в общем случае.
- что ближе к современному пониманию ЮзКейса?
  -- примитивное Коберновское ЮзКейс - это цель основного Актёра или
  -- Юз-Кейс (или их набор) не есть цель, а есть некое представление цели (одной или нескольких?),
                   (если я правильно понял BASa)
- что же тогда такое по Коберну Ответственность? другое название для ЮзКейса?

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

Полый не закрашенный ромб - это агрегация, закрашенный - композиция, т.е. более строгий вид агрегации, когда с изчезновением агрегата(композита) уничтожаются его части или агрегат перестает иметь смысл.
Системный болок состоит из - бла бла, тут агрегация, поскольку это блабла вполне самостоятельное имеет значение.
Рубашка состоит из рукава, воротника, кокетки спинки грудки. Разорвем рубашку - цельность исчезла.
Окно - имеет меню, строку состояние, окно редактирование, кнопки панели инструментов - закрываем окно изчезает все - это композиция.
Коберн к сожалению относится к картинкам халатно - потому у него стрелочки теряют свою информативнойсть. Стрелка с полым равнобедернным треугольником (незакрашенная) - это обощение, генерелизация, моделирует наследование. У Кобрена закрашено. Там где агрегация тоже есть стрелка и очень похожа на равноберенный треугольник - думаю это может быть просто навигация - иначе просто теряется смысл, связь не может быть с одного конца обобщением, а с другого агрегацией. Думаю в этом случае мы имеем самоассоциацию с агрегацией, т.е. поведение агрегирует другие виды поведения. Ну нельзя же самое себя наследовать верно?, а направление навигации показывает что поведение-агрегат прослеживается только в сторону поведения-части

Далее рисунок 2. Поведение. Ориентированное на цель поведение включает обязанности, цели и действия.
1 ДЛ имеет разные виды поведения: это некие обязанности (служебные и т.д.), цели, которые также определяют поведение, действия (некоторые шаги - взять, написать, подписать, распечать) Через действия ДЛ может либо взаимодейстовать с другим ДЛ (сотрудником) либо с неким участником через его интерес к систем. Бухгалтер производит начисления коммунальных платежей некой коммунальной службе( наша система гарантирует коммунальной службе полную информацию о платежах...)

Вообще, жалко, что народ не был на вчерашнем семинаре. Там как раз (к моему сожалению очень подробно) рассказывалось один из методов составления ВИ:
1. Берем ВИ, вчерашний пример - это "Запланировать курс"
2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"

Вообще, жалко, что народ не был на вчерашнем семинаре. Там как раз (к моему сожалению очень подробно) рассказывалось один из методов составления ВИ:
1. Берем ВИ, вчерашний пример - это "Запланировать курс"
2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"

Может сделаешь нормальный пост с примерами, либо статью опубликуешь "По результатам семинара...."

Как Асхат выложит материалы (что-бы ничего не забыть) сделаю обобщающую статью ...

Вообще, жалко, что народ не был на вчерашнем семинаре

а конспект семинара где-то есть?

Велась видео запись и есть презентация Дена (ведущего семинара), будет все выложено в ближайшее время на сайте www.agilerussia.ru. Дальнейшие вопросы по семинару в ветке: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=195.0

А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить".  То, что диграмма UC дает возможность окинуть общим взглядом предстоящее поле деятельности, отобразить основных фигурантов проекта (декомпозировать, как правило, еще нечего) и в какие именно специальные области деятельности эти фигуранты-акторы вовлечены, позволяет эффективно использовать диаграмму в качестве карты (roadmap) для обсуждения с самими акторами диаграммы, а также основы для дальнейшей детализации этих видов деятельности. Поэтому эта диаграмма ИМХО может быть целиком отнесена к арсеналу средств бизнес-аналитика.

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

По мере доработки диаграммы по результатам обсуждения, сам факт, какие акторы с какими областями  деятельности (трактуемыми как элементы диаграммы - собственно UC) связаны часто оказывается весьма информативным для обсуждения и даже неожиданным для некоторых интервьюируемых акторов, позволяют отделить важное от второстепенного. Гляда на диаграмму собседник при повторном обсуждении часто вспоминает важные детали.

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

К сожалению, в практике автоматизации бизнеса (особенно отечественного) очень часто задачи автоматизации отдельных видов деятельности превалируют на собственно интеграциоными задачами. Там где фактически идет автоматизации технологического процесса, связанного с конкретной профессиональной специализацией, детальное описание процесса (алгоритм) часто явлется единственно значимым для работы. Попытка рисовать юзкейсы для таких работ приводит к тому, что в качестве юзкейсов на таких диаграммах появляются обезличенные универсальные операции. Взаимосвязь таких операций с акторами и между собой без наглядной причнно-следственно связи получается достаточно бессмысленной (имею в виде именно диагрмму UC, а не диаграммы взимодействия и пр.). Особенно забавно, когда такие юзкейсы в руководствах по UML рисуют именно для таких случаев - типа "актор наливает себе чашку кофе" .
 
Практике текстового описания алгоритмов столько же лет, сколько программированию, широкое же применение диаграмм в качестве специального инструмента (а не иллюстративного материала)  менеджмента и анализа бизнеса  началось гораздо позже - примерно в 70-е годы 20 века. Возможно, этот факт играет не последню роль в отношении к графическим средствам описания и анализа бизнес- процессов...

2. Берем всех выделенных на раннем этапе ЗЛ (заинтересованных лиц) и для каждого расписываем что-то же делает его счастливым (его ответственность) в рамках этого ВИ
3. Расписываем этот ВИ, чтобы удовлетворить все потребности из п. 2, хотя по сути актер один - "Админмитратор Курсов"

Не чуствуешь как от этого "пахнет Коберном" с его "защитить интересы всех стейкхолдеров" ;-) ?

А насчет использования дигарамм UC, поднятой автором этой темы, ИМХО значительная часть скепсиса по поводу их применения связана с тем, что их "просто не умеют готовить". 

Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").

Скепсис в большей степени вызывают не столько сами диаграммы, сколько "только диаграммы" (читай "только диаграммы юзкейсов и ничего больше").

К сожалению, дело обстоит не совсем так.  Цитата из Коберна (стр 226 из текста из библиотеки сайта):

"The Unified Modeling Language defines graphical icons that people are determined to use. It
does not address use case content or writing style, but it does provide lots of complexity for people
to discuss. Spend your energy learning to write clear text instead. If you like diagrams, learn the
basics of the relations, and then set a few, simple standards to keep the drawings clear."

Т.е. в третьем предложении г.Коберн совершенно недвусмысленно советует предпочесть текстовое описание юзкейса использованию его графических представлений. Для тех кто все таки захочет использовать диаграммы он в этом предложении даже не предлагает придерживаться стандартов UML! Характерно, что при переводе:

"Унифицированный язык моделирования UML определяет набор используемых гpaфических нотаций. Он не касается содержания варианта использования и стиля изложения, но создает значительные сложности при их обсуждениях. Вместо этого лучше научиться писать ясные тексты. Если вам нравятся диаграммы, освойте основы отношений и затем введите несколько простых стандартов, чтобы диаграммы были понятны."

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

На стр. 230  русскоязычного издания сказано:

"С тех пор как вышла книга Object-Orieпted Software Eпgiпeeriпg (1993) многие авторы при создании вариантов использования сфокусировали внимание на фиryрах из палочек и эллипсах, упуская из виду, что варианты использования  это текстовая форма представления. "

Трудно себе представить человека, который после прочтения этого пассажа насчет "фигур и палочек" захочет разобраться с UML нотацией и применить графическое представление юзкейса для пользы дела….

В целом трактовка Коберном графического представления UML носит достаточно противоречивый характер. Наряду с цитированными выше фрагментами, прямо указывающими на необходимость предпочтения текстового описания графическим  у него есть и более взвешенные рекомендации (стр. 238):
"Рисунок  это двумерная мнемоническая схема, которая служит выделению связей. Применяйте его для данной задачи, а не заменяйте им текст"

Но примеры диаграмм вариантов использования,  например на стр. 231, даже почерпнутые из книги Буча ИМХО крайне неудачны, потому что диаграммы юзкейсов на уровне системы без (диаграмм) "юзкейсов на уровне цели",  по терминологии Коберна, действительно бессмысленны, а приведенный им пример скорее относятся именно к такой ситуации.


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

Можно я вставлю маленькое слово?

1. Спор об использовании или не использовании графических средств ведется давно. В каждом лагере есть свои аргументы в пользу использования своей концепции взгляда.
Как я понимаю, использование текстовой формы или графического представления ВИ зависит от уровня представления и изучения. На уровне бизнеса, взаимодействия с заказчиком подойдет любая форма, помогающая найти общий язык. Контекстная диаграмма ВИ Коберном вполне поддерживается, посмотрите, он называет ее модель Действующие лица и Цели. Т.е. Диаграмма ВИ может использоваться в этом случае, но скорее только как СОДЕРЖАНИЕ, однако в этом виде ничего показательного особо нет, потому Коберн и говорит - достаточно изобразить ее в виде таблицы. Все люди по крайней мере с 7 лет учаться читать и в этом деле их можно считать профессионалами. А вот рисовать диаграммы UML учать в вузах, да и не во всех, и не во всех специальностях.

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

2. Далее. Тема называется структурные диаграммы для представления ВИ. Если говорить точно, ВИ есть часть поведения системы и часть модели взаимодействия системы с окружением. Структурная диаграмма отображает структуру, т.е. нечто статичное. Конечно можно назвать ВИ функциональной структурой - но правильно ли это будет.

Т.е. я хочу задать вопрос, а явяляется ли тема правильно сформулированной, в том ли направлении идет дискуссия?