4126

Sparx / Существуют ли скрипты отчетности в SPARX EA?

« : 03 Июня 2008, 15:07:09 »

Такая возможность есть, но хотелось бы уточнить что Вы хотите. Поскольку с АРИС я не работал и не могу точно знать, что Вам требуется

4127

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

« : 03 Июня 2008, 15:04:21 »

Насколько я понял Вы дружны с VB. Смотрите раздел Automation Interface и примеры на сайте в разделе Resourses. Мне кажется Вы скорее сделаете что-то полезное, чем будете пенять на невозможность сделать это иначе.
Возможно Вам удасться сделать что-то очень оригинальное. Поделившись опытом, Вы привлечете других энтузиастов

4128

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

« : 03 Июня 2008, 13:22:30 »

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

Я послал запрос в службу поддержки. Вот пришел ответ:
EA's automation interface is very useful for performing bulk changes across your model.  For more information on using automation, refer to the EA help file under the "Extend Enterprise Architect" chapter.

Additional code samples for EA Add-Ins are available from our website under the "Resources" area.

4129

Вакансии / Re: Требования к содержанию и оформлению объявлений о работе

« : 02 Июня 2008, 16:33:18 »

прикольно! Только они же работу дают, кто кому диктует условия?

4130

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 01 Июня 2008, 23:29:46 »

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

на данном этапе возможностей ООЯ, наверное, это действительно так, но почему же "могучая дурь"? Множественная классификация и множественное наследование в реальном мире встречается довольно часто, другое дело, что современный ООЯ просто не позволяет просто воспользоваться этим. Возможно пока в этом и нет потребности и есть гораздо более простые средства выразить это в программе.

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

а параметризированные классы не укладываются в то, что Вы описали?

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

Т.е. Вы считаете ассоциации - простой аналитической дурью?
А что вы понимаете здесь под "розой"

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

Т.е. единственная причина использовать автогенерацию - это лень?

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

Трудно не согласиться, но не стоит ли все-таки различать аналитическую работу и собственно реализацию. Или Вы полагаете, что аналитика - суть пиар и ничего более?

Фактически использовались мной лишь отношения наследования и зависимости. А также средства разбрасывания класов по пакетам - файлам .сpp и .h в терминах с++.

Но Вы использовали это не потому ли, что это было полезно и сокращало время и позволяла не потеряться в массе информации?

Но! Всерьез ассоциациями и проч. архианалитикой ничего не опишешь. Если у вас классов 500, в каждом технически методов по 10, и собственных полей в среднем штуки 4 - вы в стрелочках просто запутаетесь.

Может быть все дело в точке зрения? Что такое эти 500 классов - откуда они появились? Это классы предметной области? Или уже объекты программной реализации? Все ли 500 классов вам нужны для анализа одновременно? Не разбиваются ли эти 500 классов на смысловые группы, которые и следует рассматривать отдельно? Разве проектировщики баз данных отказываются от представления связей только из-за того, что их слишком много? Повторяюсь не следует ли всегда при решени задачи держать в голове: (1) точку зрения, (2) контекст использования, (3) уровень использования ?

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

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

опять же вопрос об уровне где и как использовать ассоциации и тем более агрегации.
Понимаете явное указание атрибута типа объект среди атрибутов другого класса по сути есть уже указание на решение, но задача аналитика не указать конкретное решение по реализации, а сказать что нужно реализовать. Ведь Вы не будете спорить, что ассоциацию можно реализовать по-разному? В то время как явное указание атрибута жестко будет определять и способ реализации связи между двумя объектами - через ссылку, массив, коллекцию или создание отдельного класса. Т.е. если на модели Вы укажите просто ссылку на объект, как это принято в C++, а в реальности вам потребуется сделать нечто иное - не приведет ли это к логическому разрыву между реализацией и моделью - как впрочем часто и бывает?

4131

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 01 Июня 2008, 18:23:08 »

Alys, спасибо за интерес к теме и полезные высказывания. Правда они несколько запоздали. Тема была начата более полутра лет. За это время ситуация значительно прояснилась и понимание тоже

А при таком обилии классов требуется именно наглядность представления, для работы с этой системой классов при ее коррекции или сопровождении.

Не до конца понял Вашу мысль о наглядности представления

4132

Примеры / Re: Какие диаграммы UML использовать для системы "электронный ключ"?

« : 01 Июня 2008, 18:04:01 »

Хорошо сказано!

4133

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 23 Мая 2008, 18:53:45 »

Так я и тему открыл, что бы это же самое узнать.

Насколько я понимаю этот вопрос, моделирование бизнес-процессов никак не определяется для или не для 1 С это делается. Я таки полагал другое, как используя метамодель 1С применять UML моделирование - возможно ли это или нет?

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

Конечно, при моделировании и проектировании функционала для 1С мы могли бы скажем сделать библиотеку объектов, компонентов, классов с соответствующими стереотипами. В принципе я помогал одним разработчкам применить моделирование данных в РОзе для конфигруации (вернее БД) под 1С. Правда там ситуация была несколько иная, хотя и похожая.

4134

Сообщество Аналитиков / Re: Нужны добровольцы для структурирования файлового архива

« : 22 Мая 2008, 17:20:12 »

Интересное решение для каталога файлов представлено здесь

4135

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

« : 22 Мая 2008, 17:14:59 »

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

4136

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

« : 22 Мая 2008, 15:05:41 »

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


Далее, формируем некоторую диаграмму и перетаскиваем нужные требования мышкой из дерева требований на диаграмму. Рисуем связи и трассировки.


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


Происходит ли это в результате формирования связи?

Решение проблемы:
В ответ на запрос служба поддержки EA написала следующее:

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

Это поведение может быть изменено или использованием [alt] при перемещении объект на  (по) диаграмму(е), или отключением опции "Auto Group Elements" в "Tools | Options | Diagram | Behaviour".
Более подробно смотри http://www.sparxsystems.com/EAUserGuide/diagrambehavoir.htm

Чтобы избежать этого типа случайного изменения в иерархии, мы рекомендуем отключить опцию "Auto Group Elements", описанную выше.

Если в любое время Вам потребуется изменить вложение любых элементов на диаграмме, Вы можете удерживать [alt] во время перемещения объекта, что обеспечивает изменения поведения объектов на диаграмме на противиположный тип, установленному в  "Tools | Options | Diagram | Behaviour" (в данном случае приводит к включению опции автогруппировки).

4137

Сообщество Аналитиков / Re: Нужны добровольцы для структурирования файлового архива

« : 22 Мая 2008, 14:39:51 »

Евгений, давайте уже решение, не томите.

4138

Sparx / Re: Мастер-класс по ЕА и Раквест

« : 21 Мая 2008, 09:44:41 »

Я вот усиленно подумываю, а не принять ли участие в этой конференции. Будет это в конце июня в субботу кажется ... самое оно.

Объединим усилия?

4139

О Сайте и Форуме / Re: УРА! Поздравляю всех!

« : 19 Мая 2008, 08:20:32 »

Да наши играли отменно.

Хотя, конечно это удаление в овертайме. Насколько бы более сильной была победа, если бы точно 4 на 4 игра продолжалась. Хотя в первом тайме Канада нам нащелкала именно по этой причине.

В общем действительно игра была зрелищной!

4140

Для всех / Re: Тесты по системному анализу

« : 19 Мая 2008, 08:16:46 »

Уважаемый Arix!

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

Так что учите Arix - учите. Ничего особо сложного тут нет, Анфилатов и др. Системный анализ в управлении Вам поможет