ссылки на подход Коберна и RUP.

Ага, про Коберна... Кого ни спрошу - отмахиваются:
У Коберна, в его Writing Effective Use Cases есть UML-диаграммки,
эдакая модель понятий - контекст для  Use Case.
Там Goal, Responsibility, Actor, Action и т.д.
Насколько я понял из книжки, сам Коберн признаётся, что это суровый драфт, который ещё править и править...
У меня по этому поводу 2 вопроса:
- Что уважаемые форумчане лично думают про эти самые диаграммы?
- и что знают про мнения и работы других в этом направлении?.

Ага, про Коберна... Кого ни спрошу - отмахиваются:
У Коберна, в его Writing Effective Use Cases есть UML-диаграммки,
эдакая модель понятий - контекст для  Use Case.
Там Goal, Responsibility, Actor, Action и т.д.
Насколько я понял из книжки, сам Коберн признаётся, что это суровый драфт, который ещё править и править...
У меня по этому поводу 2 вопроса:
- Что уважаемые форумчане лично думают про эти самые диаграммы?
- и что знают про мнения и работы других в этом направлении?.

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

В-третьих, существуют как сторонники визуализации, так и потивники.

ага, меня интересуют результаты сторонников визуализации :-)
и критика этих результатов

ага, меня интересуют результаты сторонников визуализации :-)
и критика этих результатов

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

UML UC диаграмма ... ну разве что запудрить мозги заказчику, типа "умеем картинки на UML малевать".

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

так здесь 2 направления для визуализации:
- собственно, функциональных требований (UML UC диаграмма)
- модели понятий вокруг- и для- понимания инструмента под названием Use Case (в каком-то смысле - метамодель).

с мнением по первому направлению - полностью согласен.
Но мои вопросы были относительно второго.

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

Согласен с Юрием.

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

Вот, перенабранные из книжки диаграммы, про которые спрашивал.
Снимаю предыдущие свои вопросы и заменяю на детские:
- что это такое?
- как оно правильно называется?
- кому это было интересно и кто брался развивать\дорабатывать\править?
(и если были таковые, то где посмотреть их результаты?)

- что это такое?
- как оно правильно называется?
- кому это было интересно и кто брался развивать\дорабатывать\править?
(и если были таковые, то где посмотреть их результаты?)

1. Представление Коберна о возможной структуре понятия действующее лицо
2. Диаграмма классов
3. Коберн привел эти диаграммы для того, кому нравится строить диаграммы
4. Кто и что брался развивать? Иерархию понятия действующего лица? Так не нравится - можно свое видение предложить

Далее UML средство формализации проектирования прежде всего.
Думаю нет необходимости пояснять значимость диаграммы классов.
Порядок использования UML трактуется в рамках определенного процесса. Процесс предлагает и методологию использования . Разные процессы могут трактовать порядок и метод использования UML диаграмм по своему.
Писатель пишет прозу, поэт умудряется писать стихи, ученый пишет статьи, двоечник делает кучу ошибок, кто-то умеет использовать язык виртуозно, другой косноязычен: однако все используют язык - русский например.
UML - это язык, язык тезаурусный, язык символьный.
Не могу понять вопроса, в чем проблема, какая цель?

Тысячи людей с успехом используют UML. Тысячи успешно используют Use Case диаграммы, на разных уровнях абстракции, кто-то сопровождает такие диаграммы текстом, другие предпочитают делать диаграммы деятельности или последовательности.
Другие считаю, что вполне достаточно таблички Действующие лица и их цели, дополняя это текстовым описанием сценариев.
Рамбо например советует для особо сложных сценариев ВИ представлять диаграммы деятельности и диаграммы последовательности.
Другие вообще ясно и однозначно утверждают - одна графическая диаграмма заменяет десятки и сотни строк текста. Тескт неодназначен, картинка мол однозначна, елси сделана по правилам.
Сами по себе картинки конечно важны, но имеет больше смысла, когда эти картинки постепенно преобразуются в модель приложения и на ее основе генерируется каркас кода.
Технология MDA позволяет сформировать диаграмму классов, которая становится управляемым объектным пространством приложения (BOLD, ECO).
Диаграмма состояния позволяет сгенерировать соотвествующий код для отслеживания изменений состояния объекта (ECO)
Логика использования канонических диаграмм заложена в том или ином процессе разработки. При этом некоторые процессы могут использовать смешанные языки моделирования как на разных так и на одном этапе моделирования, проектирования.

Я например могу видеть такую цепочки: Use Case -> Диаграмма классов (VOPC) -> диаграмма последовательности (диаграмма кооперации) -> уточнение диаграммы классов (выявление опреация) -> диаграмма состояний для избранный объектов

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

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

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

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

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

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

Саша, позволь не согласиться. Более того, это ты пошел немного не в ту область. Читай, что пишет автор сообщения.
Я ему лишь отвечаю. по существу вопроса, как я его понял.
Чуть позже я просто описываю проблему использования UML и акцентирую внимания на форме его использования.

А про диаграммы приведенные автором сообщения я ничего такого и не говорю. И вовсе, как ты приписываешь мне, я не интерпритирую так Коберна. Почитай внимательно ответ на вопрос в виде 1-4 пункта. Далее идет уже философствование на заданную тему.

А SuD это система проектируема, рассматирваемая система, system under discussion (or under design)

1. Представление Коберна о возможной структуре понятия действующее лицо

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

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

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

Важно лишь понять что Вы сами хотите получить от такой диаграммы?

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

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

Я вообще хотел поднять тему "Наука в области Анализа", т.е. расмотреть модные веянья в Анализе и UML в частности для написания диссера.

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

Я вот хочу спросить - это свойство аналитика додумывать за других их задачи и цели?
Пост опубликовал Gevorg, он инициатор и заявитель.
А некто bas имхо лишь участник дискуссии. Предложения для своего видения проблемы - безусловно хорошо, однако чреевато..

Я вообще хотел поднять тему "Наука в области Анализа", т.е. расмотреть модные веянья в Анализе и UML в частности для написания диссера.

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

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

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