Насколько я понимаю, раз есть плата за ежегодное использование, то это должно подразумевать поддержку.
Сориентируйте, пожалуйста, что входит в услуги поддержки?

Гугл - найдется все:
http://www.sparxsystems.com/products/ea/license_info.html#subscription_benefits

Добрый день!
Подскажите как объединить два проекта? Очень извиняюсь, возможно где-то на поверхности, но никак не могу найти.
Второй вопрос, как вычистить из модели неиспользуемые элементы, то есть, те которые отсутствуют на диаграммах.
Пытался использовать Transfer Project.
Заранее спасибо!

Добрый день!

Подскажите как объединить два проекта? Очень извиняюсь, возможно где-то на поверхности, но никак не могу найти.
Второй вопрос, как вычистить из модели неиспользуемые элементы, то есть, те которые отсутствуют на диаграммах.
Пытался использовать Transfer Project.
Заранее спасибо!

Добрый!

Для объединения можете банально выгрузить в xml вашу модель или пакет и импортировать его в новый проект.


Для удаления неиспользуемых элементов можно пойти двумя путями:
1. Написать SQL Patch, исполняемый из Data Management меню EA, в котором будет написан sql-запрос, объединяющий t_object и t_diagramobjects таблицы и удаляющий несовпадения, например, по заданному типу объектов (через оператор DELETE).
2. Написать скрипт (на VBS, JScript или JavaScript), который итерировал бы по элементам модели и "выискивал" элементы, отсутствующие на диаграммах, с последующим удалением.

На мой взгляд предпочтительнее будет sql-запрос.

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

Умный человек, конечно же, воспользуется скриптами. А вот мудрый, по-моему, на будущее, будет пользоваться Audut'ом и Baseline'ами, только обязательно следите за объемом модельного репозитория - если у вас, конечно, все не на DBMS + индексация прикручена + не стеснены допустимыми объемами данных))) 

Подскажите как объединить два проекта? Очень извиняюсь, возможно где-то на поверхности, но никак не могу найти.
Пытался использовать Transfer Project.

Да, Project transfer не позволяет объединять модели в один репозиторий, тогда только по пакетам через xmi...
А вам зачем - чтобы все было в одном месте, или нужно наладить взаимодействие между несколькими пересекающимися проектами?
Если необходимо взаимодействие, то пользуйтесь svn. :-)

Спасибо за ответы!

Да, Project transfer не позволяет объединять модели в один репозиторий, тогда только по пакетам через xmi...
А вам зачем - чтобы все было в одном месте, или нужно наладить взаимодействие между несколькими пересекающимися проектами?
Если необходимо взаимодействие, то пользуйтесь svn. :-)

Не, не, не - у меня человек, по незнанию нарисовал процесс и модель предметной области в двух разных проектах. Пытаюсь слить их.
Про второй вопрос: я перепутал EA и Aris Tool Set - давно не пользовался. В ATS такая кнопка есть, вот я ее тут и искал.

Доброго времени суток.
Подскажите пожалуйста, как правильно хранить требования к многоверсионному продукту?
Нужна возможность отфильтровывать на диаграммах требования, относящиеся к определенной версии продукта. Без этого сложно отвечать на сакраментальный вопрос "а как оно должно работать в версии N?".
DIagram filters были бы идеальным решением, но с их помощью можно фильтровать только атрибуты объектов. В моем случае, если вписывать в каждое требование все версии, в атрибуте получится длинная и уродливая строка. Это решение проблемы, но не красивое и сулящие в перспективе проблемы(я не знаю максимальной длины строки атрибута).
Можно хранить все версии требования в Tagged Values. Это удобно, но DIagram filters не работает по ним(
В общем, прошу совета знающих людей

Доброго времени суток.
Подскажите пожалуйста, как правильно хранить требования к многоверсионному продукту?

Мне кажется, нужно идти в сторону baseline.

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

Спасибо)
Проблема решилась несколько иначе.
Для каждой версии я создаю отдельные папки.

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

Подскажите пожалуйста, как обеспечить связь конкретных полей таблицы БД с Activity diagrams?

С записями БД связаны не шаги диаграммы деятельности, а проектные entity-классы, которые в свою очередь мапятся на проектные boundary-классы (в вашем случае визуальные формы, которые видит пользователь). Поэтому маппинг должен описываться на уровне диаграмм последовательности, а не деятельности.

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

Возможно будет полезным такой способ?
поищите в справке Create Object From Attribute
If you drag an attribute from the Project Browser onto an Activity diagram, the attribute generates an Object element of the same name.

This is very useful for creating connectors between elements and specific attributes. For example, a Class element of stereotype table defines its fields as attributes; Requirement elements that define requirements for those fields can then be linked to the appropriate table fields via the attribute Object elements.

Если хранить версии в разных "папках", то сложнее будет отследить изменения между версиями.С записями БД связаны не шаги диаграммы деятельности, а проектные entity-классы, которые в свою очередь мапятся на проектные boundary-классы (в вашем случае визуальные формы, которые видит пользователь). Поэтому маппинг должен описываться на уровне диаграмм последовательности, а не деятельности.

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

Сейчас пытаюсь сообразить, как правильно хранить операции классов (программную часть системы тоже надо будет описывать). Создавать диаграммы для операций тоже нельзя(( Может у вас тоже есть готовое решение?

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

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

Это понятно. Но в какой-то момент нужно описать, что именно делает операция. Внутри операции может быть сложный алгоритм с условными переходами, циклами, вызовами других операций... Это логично описывать Activity диаграммой. Собственно, я и не могу понять, как правильно ассоциировать Activity диаграмму с операциями классов(((