Все выглядит солидно и проработано. Но понять ценность информации, видимо, можно, только начав работать со структурой, ведя реальный проект и отслеживая рефлексию участников. Все-таки порог вхождения, чтобы начать это использовать очень высокий. Кроме того, максимальная ценность от этой информации достигается только при использовании RSA. В других инструментах придется самому выстраивать всю метамодель, правила преобразования в шаблоны и т.п.
1. Почему считается, что способ рисования сценариев ВИ (т.е. реализации ВИ) в виде ДД лучше, чем текст?
2. Почему считается, что реализации ВИ через ДД удобнее и прагматичнее, чем реализации сценариев чере диаграммы сценариев = ДП?
3. Почему ограничивается, что любой include и extend ВИ - есть абстрактный ВИ?
4. Почему ограничивается, запрещается наличии ассоциации между actor и include / extend ВИ ?
3. Я ничего не ограничивал. В метамодели UML UC - это классификатор. Абстрактный классификатор не имеет собственных экземпляров. UCI и UCE не имеют собственных экземпляров: они выполняют экземпляры основного UC.
4. Наверное, Коберн ввел понятие первичного Actor (цель которого реализует UC). Взаимодействие первичного Actor создает экземпляр UC. С UC могут взаимодействовать другие Actor, но они "помогают" (пример - клиент банкомата и процессинг). Т.о., ограничение относится только к первичному Actor. Вторичные могут "помогать", взаимодействуя с экземпляром основного UC в границах основного UC, UCI или UCE.
2. ДД, на мой взгляд, удобнее и прагматичнее, т.к. просто нагляднее, особенно, если процесс достаточно "запутанный" (много логики). RUP вообще возможность использования ДП для этих целей не рассматривает!
1. Простите, за других не говорю! Для меня - несколько причин.
- Я никогда не сумел бы в голове построить схему сложного процесса с параллельными и альтернативными потоками и описать ее. Все равно стал бы что-то рисовать и писать по рисунку
- Я использую инструменты, которые позволяют рисовать и генерировать текст из модели в нужной мне форме
- Я могу использовать MDA, в частности, преобразовать BUC в пакет функциональной области в модели UC, автоматизируемые действия ДД - в UC, а соответствующий раздел - в Actor (и т.п.)
5. Каким образом диаграммы активностей помогают построить MDA?
В чем, на мой взгляд, состоит отличие MDA от MDD?
- В MDD есть моделирование и преобразование модели в код
- В MDA есть 4 вида моделей: бизнес (включая UC), анализ, проект, код и преобразования "туда-обратно" для каждой пары смежных моделей.
Наверное, теоретически возможно преобразовать описание UC на естественном языке в модель анализа. Трудно придется! А для моделей это не проблема, есть множество примеров. Если средство моделирования поддерживает MDA, в нем д.б. инструментарий для создания преобразований (так написано на сайте OMG).
6. Имеются ли какие-либо оценки эффективности, полезности на создание и поддержание модели или ее фрагмента отнесенного к трудозатратам на использование специалиста? Сколько вообще нужно специалистов?
7. А также есть ли какие-то оценки именно повышения производительности работы аналитика? И что понимается под производительностью аналитика?
Если говорить о MDA, то формально вопрос о необходимости поддержки моделей в актуальном состоянии не стоит. Сгенерировался неправильный код - ищи ошибку в модели или в модели/коде преобразования. Но фактически это скорее неблизкое будущее.
По жизни. Система должна отвечать требованиям. Т.о., модель требований первична. Если требования изменились, нет другого способа довести изменения до исполнителей, кроме, как изменить модель (если документы требований генерятся из модели). Или изменить документы. Но если изменить (написать) документы проще, чем изменить модель, на фига она вообще, эта модель?
Конечно, никаких замеров я не делал. Но результаты видел. Я уже говорил, что я иногда зарабатываю на хлеб тем, что помогаю внедрять технологию RUP. Я прихожу не с пустыми руками. И вижу производительность до и после.
Любой специалист накапливает опыт. Свой и чужой (даже самые крутые, если умные). Те примеры, которые я представляю, не предназначены для непосредственного использования.
Думаю, Ваши инструменты позволяют использовать представленные идеи и примеры, такие, как моделирование с использованием строительных блоков, настройка шаблонов для генерации презентационных документов и т.п. Если не позволяют, хочу задать вопрос: "Неужели Вы так богаты, что можете себе позволить покупать (использовать) дешевые инструменты?"
Относительно солидности и проработанности. А разве аналитик имеет право представлять "не проработанные материалы". Тем более, когда вину свалить не на кого!
Спасибо, Эдуард, за содержательные вопросы.
Повышение производительности аналитика