А чем фильтр по фазе отличается от фильтра по стереотипу и т.п.?

Если модель поддерживает разработку, то значения фазы будут меняться.

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

Думаю, Galogen знает!

Здесь дело даже не в некоторых свойствах.
Ведь если попробовать поставить фильтр на Phase из вкладки Element Filter, то пакет благополучно проигнорирует этот фильтр и все равно влезет в документ.
С Phase из вкладки Options групп-бокса Filter ситуация иная. Эта фаза действительно работает, исключая пакеты.
Почему так - непонятно. Но эти Element-фильтры однозначно отказываются работать с пакетами.
Я написал пост на форуме sparxsystems по этому поводу.

Давно?

Давно?

Пару часов назад.

Спасибо!

Коллеги, реально я мало работал с ЕА в качестве инструмента документирования и получения этой документации. Я в большей степени использовал как средство моделирования, получения каркасов кода.

Так что по поводу документирования меня спрашивать бесполезною Но я могу, если мне предложат набор вопросов, задать их в поддержке ЕА. Они отвечают мне в течение одного двух дней.

Изыскания относительно диагноза "поиск пакетов не работает в Model Document" в объектной модели EA (Help > Automation > EA Object Model > Reference):

- Сведения о модельных элементах сохраняются в таблице t_object
- Сведения о пакетах сохраняются в таблице t_package. Но атрибутов у класса Package немного. Для сохранения недостающих в t_object создается Element - дублер для сохранения недостающей информации, например, стереотипа. Класс Package имеет атрибут Element. В классе Element атрибута, отвечающего за связь с пакетом-дублером я не нашел. Т.е. элемент в t_object ничего не знает о том, что он является дублером пакета. Сведений о том, какая именно информация о пакете заносится в соответствующий Element при создании Package мне найти не удалось. Вряд ли она дублируется.

Предположение о причине проблемы.

Когда Model Document получает результат поиска, он ищет "отфильтрованные" объекты в t_object, и ничего не находит, т.к. запрос поиска составлен применительно к пакету, полная информация о котором содержится в t_package.

Возможно, это бред! Но если это так, разрешить проблему будет трудно, если не невозможно!

Вопрос, кажется, решен!

Делаем все, как делали. Но: в шаблоне документа нужная нам информация лежит не под тэгами  Package и пакетиковые детки, а под тэгами Element!

Т.е., при создании шаблона RTF, который будет использоваться с Model Document, нужно иметь ввиду, что непосредственно в тэгах package> ... <package полей не должно быть. Т.е шаблон должен иметь структуру:
    package>
    element>
     ...
     ...
    <element
    <package

Model Search обращается только к t_object и не касается t_package.
Простой SQL-запрос возвратит кортеж по условию.
Help EA рекомендует использовать ea_guid AS CLASSGUID, Object_Type AS CLASSTYPE, если результат запроса будет использоваться, например, в RTF Reporting.
Возвращается все как надо (ucm__), только вот генерировать все равно не хочет

То, что написано в предыдущем сообщении, точно работает.

Документ - рис.1
Шаблон - рис. 2
Поиск - рис. 3
Результат - рис. 4

Почему-то не отобразились диаграммы прецедентов и названия дочерних элементов пакета FA (прецедентов).

Наверное, нужно покопаться в опциях.

А Keywords = 'FA' на пакетах "висели"? Просто ObjectType не указан.

Я при моделировании в RSA применял "систему" ключевых слов для разметки (отнесение элементов к разделам, сортировка и т.п.).
В RUP-е есть понятие функциональной области. Пакеты функциональных областей используются в структурах моделей прецедентов и в моделях анализа и проекта (в пакете реализации прецедентов).
Я маркирую эти пакеты ключевым словом "FA".

Но в RSA (шаблоны SoDA) поиск элементов происходит "от текущей позиции". Как я понял, в EA поиск каждый раз по всей модели. И, если использовать подход, придется ввести ключевые слова, например, ucmFA, amFA и dmFA.

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

Нехорошо, когда решения (структура документа) зависит от возможностей инструмента. В SoDA и BIRT (eclips-овский инструмент) таких проблем нет.

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

Почему-то в результат не попали диаграммы и прецеденты из прошедших фильтр пакетов.
Причину не могу найти.

Опытные люди, посоветуйте, что посмотреть?

Спасибо!

Не претендую на звание "Опытного", но шаблон у Вас правильный.
Во всяком случае он действительно сработает (текст+диаграммы под UC-элементами), если Вы "руками" (без поиска и MD) сгенерируете документ по пакету "Оказание услуги".
Почему Вы отказываетесь от организации "Класс (MD) <- Атрибуты (Pkg)"? Ведь там таких проблем с пакетами вообще нет.

Я долго работал с инструментами Rational. В частности - с RSA для моделирования и проектирования. Наработал множество приемов и шаблонов.
Одна из претензий к циклу статей "Повышение производительности аналитика" - опыт заточен на дорогие инструменты и для широкого круга аналитиков его использование невозможно.

Ну и, поскольку я безработный, я решил попробовать адаптировать, что можно, для EA.

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

Использование стиля "класс - атрибут" проблематично по многим причинам:
- для каждого типа отчета нужно явно определять все атрибуты классов. В сложном мастер-документе будет много MD, которые нужно грамотно выбрать. Написать инструкцию по каждому типу документа - не фокус. Но не будет же аналитик держать ее под руками для создания каждого документа. Какое уж тут увеличение производительности!
- есть и внутренние проблемы. Например спецификация UC. Описание рабочего потока должно выполнятся с использованием диаграммы деятельности. Самое большее, что можно допустить - это разметку элементов, которую должен понимать шаблон. И здесь без фильтров и сортировки не обойтись.

Короче, я поставил себе задачу отработать приемы создания сложных отчетов на примере двух документов: Обзор модели прецедентов и Спецификация прецедента <название>. Документы должны напоминать документы RUP.

Если это не удастся, бросаю это черное дело. Если получится - буду делать "технологию" под названием "Интегрированное моделирование" с профилем UPIA.

Если кто-то хочет поучаствовать - милости просим!
Если кто-то найдет коммерческое применение - тем более!

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