16

Sparx / Re: Enterprise Architect: Практика использования

« : 27 Августа 2008, 18:23:52 »

Нифига себе заявление. Почему такое мнение? Я уже хотел взять его за основу для инструмента моделирования.

дак и я до сих пор пользую, не нешёл пока лучшего,
но нужно трезво смотреть в будущее:
реально ожидать от Sparx-a можно только косметических доработок и багфиксинга,
править концептуальные уродства в своём продукте они и не думают.
Уже, наверное, с десяток таких уродств обсуждалось здесь на форуме,
запросы им посылались, ответ один: нет и не будет.

они ребята хорошие принимают предложения

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

Назови мне  что-то идельное. Мне кажется ты утрируешь ситуацию

Нет, я просто стараюсь реалистично смотреть на эту сАмую ситуацию.
У нас речь не об идеальности, а о перспективности.
Я говорю о том, что в основу ЭА заложена очень удачная метамодель, благодаря которой он до сих пор остаётся лучшим выбором.
НО!

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

Поскольку от этих пунктов ребята в Sparx-е упорно воротят нос,
я и делаю для себя заключение, что перспектив здорового развития у них нет.

17

Sparx / Re: Enterprise Architect: Практика использования

« : 27 Августа 2008, 13:57:35 »

Вообще при всех прелестях ЕА неожидано ловишь себя на мысли, а не является ли низкая цена единственной прелестью?

многое вообщем-то бывает либо недоступно, либо приходится вставать на уши, чтобы сделать это доступным.

Или это просто проблемы роста?

IMHO - не роста, а старения и развала, здесь мне видится наиболее уместной ассоциация со старческими маразмами.

Лично я не вижу здоровых перспектив у ЭА, его разработчики занимают нездоровую позицию: выжимания из загнивающего продукта максимум прибыли, - и никаких серъёзных движений к его оздоровлению.

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

- выбросить и забыть, как страшный сон.

18

Sparx / Re: Enterprise Architect: Практика использования

« : 27 Августа 2008, 13:56:27 »

Александр, к сожалению в ЕА нет явных средств для этого, как, например, в VISIO. Однако следует придерживаться правила справа-налево-сверху-вниз.

Я выкручивался путем изображения направления навигации или включения в текст имени ассоциации знака -> или <-. Конечно не так удобно. Однако направление чтения часто тривиально и понимаемо

Прийдется выкручиваться...

Ребята, вы прикалываетесь или действительно не знаете?

1. Прописываем ассоциации имя.
2. На диаграмме тыцаем мышкой в имя ассоциации (именно в имя, а не в саму ассоциацию), выделяем оное.
3. ПКМ->контекстноеМеню->Direction.
4. Выбираем направление.
5. Наслаждаемся закрашенным треугольником в имени ассоциации, проставленным с нужной стороны и в нужном направлении.

Да, как и многое в ЭА  - извращённо,
но всё-таки, есть такая возможность.

19

Sparx / Re: Enterprise Architect: Практика использования

« : 05 Августа 2008, 18:03:31 »

свойства ParentID в дочернем элементе задается родитель. Но родитель именно в смысле project browser. Каково отражение отношения родитель-ребенок (project browser) в UML отношения

Я тоже задавался этим вопросом.
В смысле соответствия UML-ному стандарту,
я вижу интерпретацию связи родитель-ребенок в project browser EA только в контексте пакетов.

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

Так вот, интересно, что в ЭА роль пакета может исполнять и класс,  и состояние, и активность, и Юзкейс похоже, любой элемент модели, изображение которого на диаграмме имеет вид фигуры с полощадью.
Как минимум, в контексте project browser-а.

Как-то мне по работе нужно было дать Заказчику диаграмму зависимости пространств имён в разрабатываемом .NET-приложении.
Получилось достаточно удачная диаграмма файлов-компонентов, в которых содержались пакеты-пространстваИмён. (Я использовал MagicDrowUML)
Мне очень понравилась конструкция с плавным переходом:
NameSpace.SubNameSpace.ClassName.ClassFunctionName()

Если NameSpace и SubNameSpace моделируем на диаграммах пакетами, то логично пойти дальше, и воспринимать и ClassName и ClassFunctionName тоже как в каком-то смысле, пакеты.

Например, диаграмму состояний (вместе с состояниями) можно сделать в project browser-е дочерней для соответствующего класса.

Диаграмму активности, детализирующую ЮзКейс, вместе с активностями - делаем дочерними самому Юзкейсу.


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

В том и вся привлекательность этого дерева:
его можно строить и перестраивать,
повторяя какие-то логические структуры модели, не изменяя при этом саму модель.

Но не всё так красиво в ЭА.
Мы с Galogen-ом давно нарвались на обидный хомут:
Есть функция у класса, очень хочется активити-диаграмму с алгоритмом вычисления этой функции сделать дочерней...
Ан-нет :-( ЭА функцию в дереве показывает, а прицепить к ней дочерний элемент не даёт.

Ещё - ЭА не хочет цеплять пакет дочерним куда бы то ни было, кроме другого пакета.

Но самое страшное - это риск "полного съезда крыши" у ЭА,
как только начинаешь более-менее основательно перестраивать дерево браузера.

20

Sparx / Re: Enterprise Architect: Практика использования

« : 22 Мая 2008, 15:48:56 »

Проблема:
Для создании структуры требований используется RaQuest. После формирования части или всего списка требований - список иерахический, данные по требованиям переносятся в EA, где возникает собственная - но аналогичная структура требований (см. рисунки).

маленькое уточнение: данные по требованиям - одни и те же, хранятся в одних и тех же таблицах, только есть возможность с ними работать, как из RaQuest, так и через EA.
в моём случае окзывается удобным вначале создавать требования в RaQuest, а потом открывать EA и уже там дальше с ними работать.

21

Sparx / Re: Enterprise Architect: Практика использования

« : 24 Апреля 2008, 14:43:57 »

Для чего удобно видеть эти даты? Какова цель создания диаграммы?
Обычно диаграмма создается для визуального отображения элементов и связей между ними,

Irr, не совсем так.
Есть много любителей, в роде меня, работать с диаграммами в бумажном варианте.
Я нахожу в этом особую прелесть:
держать в реале картинку и разрисовывать её маркером и карандашом :-)
Так вот, в процессе работы таких бумажек собирается много, каждая из них хранит безценные зацепки для вытягивания из недр памяти "гениальных мыслей" или важных аспектов.
Как правило, эти зацепки - в виде мазков маркером и карандашных каракулей-приписок, родившихся в транспорте или на митинге с Заказчиком.
А когда такие бумаги начинаешь пересматривать - вот тут и жалеешь, что не видна версия диаграммы и дата её распечатки.

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

ох уж эта мне больная тема с контролем версий в ЭА :-)

тут мысль родилась:
вообще все элементы, которые выносятся из системы версионного контроля надо бы снабжать "бирками", какой они версии.

22

Сообщество Аналитиков / Re: Клуб любителей EA

« : 08 Февраля 2008, 19:29:36 »

а плюсик за кудесничество?

2Irr: sorry за безграмотность, только что Galogen просветил
+1 добавил в Вашу копилку :-)

23

Сообщество Аналитиков / Re: Клуб любителей EA

« : 08 Февраля 2008, 17:27:08 »

.. если использовать окошко Hierarchy (Ctrl-Shft-4), то будет легче :-)

Irr, Вы просто кудесница!
Именно то, что надо, это Ваше окошко Hierarchy,
с этим же теперь можно реальную трассировку требований делать!

24

UML SysML и пр. / Re: Связь между диаграмми последовательности и диаграммами состояний

« : 06 Февраля 2008, 15:43:58 »

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

используется, используется!

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

- Набор состояний, как правило, удаётся получить от заказчика напрямую.

Остаётся увязать всё это в диаграммы состояний.

Сбор соответствия Communication message - State-Chart signal приходится пока делать вручную и
независимо отображать результат в ЭА диаграммах.

25

Сообщество Аналитиков / Re: Клуб любителей EA

« : 06 Февраля 2008, 13:41:48 »

Эд, ребята со Спракса мне очень нравятся своей логикой. Она нефрагментарна, а последовательна.
Единственная непонятная фича - почему обделили на параметры элемент Requirement,
для меня обрела ответ, когда я увидела RaQuest: чтоб не мешать друг другу разрабатывать софт.

Irr, а Вы не можете уболтать этих классных ребят из Sparx-а,
чтоб в окне свойств Requirement-а вставили закладку Links, как у других элементов?

Ну уж очень без этого тяжко :-(

26

Sparx / Re: Enterprise Architect: Практика использования

« : 01 Февраля 2008, 19:05:52 »

... я бы с 1 диаграммы делала копирование в буфер - во 2 диаграмме вставку из буфера....

с тех пор, как загробил себе мессиджи в 1-й Communication Diagram при попытке скопировать объекты через буфер в новую,
я вААще остерегаюсь пользоваться буфером, ото тягать элементы на новую диаграмму из браузера - надёжнее...

а причина моих неприятностей с буфером, как мне видится - вот в чем:

ЭА не переносит в новую диаграмму мессиджи вместе с ассоциацией между двумя взаимодействующими объектами,
что есть удобно и видится правильным.
При попытке скопировать фрагмент коммуникативной диаграмы через буфер,
в последний помещаются данные УЖЕ без мессиджей.
И вот в этом узком месте чуть что не так сделаешь - потеряешь мессиджи, а то и ассоциации в исходной диаграмме.

27

Sparx / Re: Enterprise Architect: Практика использования

« : 01 Февраля 2008, 18:10:57 »

Кстати я кажется нашел решение для трансформации sequence to communication и наоборот. Правда работает вероятно только на 6.5 корректно, на 7 версии только от communication to sequence.

а поделиться можете?

28

Sparx / Re: Enterprise Architect: Практика использования

« : 01 Февраля 2008, 18:08:31 »

В ЕА есть такая фишка как привязка Note к внутренним элементам.
А фишка очень удобная. Меняешь этот самый элемент, а заметка тутже отображает его изменение

есть ещё фича: прицепить комментарий к ассоциации (или даже к целому набору ассоциаций) на диаграмме,
но здесь уже фокус с выводом текста из внутреннего элемента не проходит, токо вручную писать.

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

29

UML SysML и пр. / Re: Что есть сигнал в State mashine

« : 15 Января 2008, 20:15:41 »

в данном случае сигналом будет сообщение Обнаружен дефект, конечно не очень понятно, но можно представить, что объект делает самопроверку и соотвествее носылаей сам себе сообщение если обнаружен дефект

мне кажется, у Ice в данном случае дефект - это абстрактный объект в какой-то баг-трекинговой системе, со своим ЖЦ.
Какой-то ВНЕШНИЙ объект формирует и посылает сообщение, по которому должен родиться новый абстракный объект: Дефект.
Скорее всего - это сообщение генерируется не автоматически, а из пользовательского диалога.

может, я повторяю уже понятое, но на всякий случай ещё раз:
в наших простых случаях переход их состояния в состояние выполняется ТОЛЬКО по событию:
событие инициирует этот переход.
События могут быть разными, в частности - приход сигнала.

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

не передача сигнала, а ПРИЁМ сигнала объектом,
событие не получают и не передают, оно ПРОИСХОДИТ,
а объект на него, на это событие, должен ОТРЕАГИРОВАТЬ
запуском соответствующего перехода.

30

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 14 Января 2008, 19:02:25 »

IDEF0,
IDEF3,
DFD -
ARIS-
Расширения UML Эриксона-Пенкера,
BPMN -
Кто продолжит ?

только вчера дали шаблон типа для оформления результатов бизнес-анализа.
так там притянули ещё и
"Методику построения диаграммы Исикавы-Сибирякова для анализа нетехнических систем"

шо за зверь такой, может, кто пользовался?