Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - artvish

Страницы: 1 2 3 4 5 6 »
1
Всем добрый день!

Поделитесь своим опытом, каким образом, как правило, вы отражаете в рамках, допустим, моделей предметной области то, что в некоторый частный шаг бизнес-процесса входит X-объектов и, собственно, выходит Y-объектов. С 1-2-3 объектами ситуация понятна, а если их значительно больше? Используется ли вами какая-то группировка / декомпозиция одного объекта на несколько (например, пакет документов, вместо перечисления всех документов)?

Используете ли какую-либо практику условий на выходные объекты? Причем условий именно не в качестве Decision в сценарии шагов на Activity Diagram, а условий на связи между деятельностью и объектом.

Заранее огромное спасибо!


2
Sparx / Re: Default Appearance
« : 28 Января 2016, 15:40:09 »
Добрый день!

На самом деле Default Appearance работает по такому принципу:
1. Выделяете элемент или группу элементов
2. Вызываете через контекстное меню настройку внешнего вида по умолчанию
3. Задаете необходимые цветовые и т.п. настройки

Применяется результат данной настройки только на выбранные элементы, а также все, допустим, линки на них на других диаграммах. Суть в том, что мы не выполняем глобального переназначение цвета, границ, шрифтов и т.п., допустим, у UC. Мы только лишь говорим EA, что применять изменения по цветам нужно не для конкретного объекта на данной диаграмме (как это делается через Format Bar на любой диаграмме), а для всех ссылочных копий или экземпляров исходного объекта на всех диаграммах, где он используется.

Прочтите хотя бы Tip, возникающий при наведении на кнопку редактирования Default Appearance. Кроме того, в справке 12.x версии сказано: "... you can change the default appearance for a specific element on all diagrams on which it is found, using the Default Appearance dialog".

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

3
Начну, пожалуй, с конца:

Цитировать
3) Удивило, что при формировании текста sql запроса отсутствую подсказки  - наименование таблиц, полей и т.д. Поэтому запрос формировал и отлаживал в акцессе. Это единственный путь, или все таки в EA предусмотрены средства по формированию запросов?
Вы можете использовать встроенную в EA отладку SQL-скриптов, которая вызывается через поиск. Сейчас, по-моему, она именуется SQL Scratch Pad. Чтобы вызвать все это дело, нажмите CTRL + F, находясь в EA, и выберите New Search (пиктограмма с увеличительным стеклом). Далее, полагаю, все будет понятно.
Чтобы использовать некоторое подобие интеллектуального ввода, вы можете начать вводить наименование таблицы, например, "t_o", и нажать на сочетание клавиш CTRL + Пробел.
Разумеется, отсутствие в окне конфигурации кастомных запросов отчетности механизмов отладки немного коробит, но что поделать :)

Цитировать
2) Где посмотреть, какие контекстные переменнные определены для каждого блока обычных шаблонов ( не знаю, как правильно эти переменные обозвать - в учебном видео в тексте запроса есть переменная #OBJECT# - я так понимаю набор таких переменных в блоке свой)
То, что находится в хэшах, в EA именуют макросами. По этой части рекомендую посмотреть здесь (в отношении конкретных трех макросов для фрагментов) и здесь (перечислены прочие макросы, возможные к использованию в кастомных SQL-скриптах EA).

Цитировать
1) Можно ли при использовании custom sql использовать sort by и задавать на каждый уровень группировки свой печатаемый блок?
Здесь, думаю, нужно экспериментировать. Меня, по крайней мере, смущает Sort By. Вы имеете в виду SQLный Order By? Перечень доступных для использования SQL-операторов в интерпретаторе EA можно посмотреть с использованием ранее упомянутого окна отладки в поиске (SQL Scratch Pad). Нужно тестировать.

4
Можете также дополнительно посмотреть по поводу использования Custom SQL Query в составе фрагментов отчетов EA здесь и здесь.

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

5
Полагаю, что есть два пути:
  • использовать API EA, реализовав либо скрипт на VBS / JS/ JScript, либо полноценное расширение Add-in
  • использовать кастомные SQL-запросы в шаблонах отчетов

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

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

6
Если есть желание почерпнуть немного ГОСТовых объяснений на сей счет, то разумно заглянуть сюда. В этом стандарте описана "испытательная" часть.

Пусть и будучи замененным, но все-таки п. 3.6 данного стандарта говорит нам: <...> Допускается по согласованию с заказчиком представлять АСУ на приемочные испытания без опытной эксплуатации <...>.

Если по существу в части процесса проведения ОЭ, то вы размещаетесь своим КТС, СПО и ППО в "контуре" Заказчика, вменяете (если такой порядок принят - Приказом) заданному перечню подразделений Заказчика, деятельность которых связана с автоматизируемыми функциями, обязательства по участию в ОЭ и "гоняете" вашу АС по всем требованиям, представленным в ТЗ. Условия и порядок проведения ОЭ вы регламентируете Программой проведения ОЭ. В ней же (в Программе) вы описываете и прочие специфичные особенности, характерные и вашей АС, и вашему Заказчику и т.п.

В ходе пользовательских функциональных "прогонов" (максимально приближенных к реальной эксплуатации) АС вы наверняка соберете какую-то критическую массу замечаний / предложений и т.п как по АС, так и по проектной, эксплуатационной документации на нее (см. п. 3.2 данного стандарта). Все это ляжет в основу некоторого Журнала проведения ОЭ, который станет, допустим, приложением к Протоколу.

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

Далее вами совместно с Заказчиком будет проведена приемочная процедура (обычно, в разы более быстрая, чем, разумеется, сроки проведения ОЭ). Конечно, приемка должна проводиться в "боевой" среде. На выходе - подписанный Акт о приемке АС в постоянную эксплуатацию. Далее уже, исходя из условий ТЗ / договора вы находитесь на сопровождении (быть может гарантийном) и решаете согласованный перечень задач по поддержке промышленной эксплуатации внедренного вами автоматизированного решения (АС / АСУ и т.п.).

Таким образом, как было упомянуто davvol, промышленная эксплуатация будет характеризоваться заметно большим "натиском" пользователей на систему, нежели чем во время ОЭ. Объясняется это, в том числе, и тем, что ОЭ имеет ограниченный срок проведения и даже тех же данных за время ее проведения будет сформировано заметно меньше, чем за время последующей "боевой" эксплуатации. Кроме того, персонал в ходе промышленной эксплуатации может расти, нагрузка на систему возрастать, достижимость показателей назначения падать и вы будете очень кстати Заказчику в этих условиях :-)

Если в довесок у вас будут какие-либо сертификационные мероприятия, допустим, ТИ по части ИБ (лаборатории ФСТЭК, ФСБ, ...) или что-то в этом духе, то едва ли пользователи во время ОЭ смогут оперировать реальными, а не "синтетическими" данными в вашем автоматизированном решении, размещенном в Заказчике. Отсюда желание пользователей работать с системой, где одни "рога и копыта", "ромашки" и т.п., резко упадет, а, следовательно, упадет и качество ОЭ, и нагрузка на испытываемую систему в целом.

Резюме: проводите ОЭ, работайте с "живыми" данными и отлавливайте все, что только будет возможно в рамках заявленных сроков. На душе потом будет спокойнее  :)

7
Для всех / Re: Пишем ТЗ по ГОСТ 34
« : 06 Декабря 2014, 17:03:27 »
Добрый день!

В рамках выполнения работ по ГК мы, как правило, по согласованию с проектным офисом и тех.политикой (правда, не всегда такие организационные единицы есть :) ) готовили, согласовывали, утверждали и тиражировали на все проектные команды документ типа "Правила оформления отчетной документации".
Структуру данного документа, думаю, приводить не обязательно. Но в качестве использованных источников для нас всегда было следующее:
1.   ГОСТ 2.105-95. Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к текстовым документам
2.   ГОСТ 7.1 – 2003. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления
3.   ГОСТ 7.21-2001. Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления
4.   ГОСТ 19.105-78. Единая система программной документации. Общие требования к программным документам
5.   И некоторые другие типа ОК 005 и прочие ГОСТ, например, по видам и комплектности документов.

Само оформление складывалось из четкого соответствия требованиям к:
1. Лист утверждения
2. Титульный лист
3. Список исполнителей
4. Аннотация
5. Содержание
...
8. Основная часть
8.1. Оформление раздела
8.2. Оформление подраздела
...
8.6. Оформление рисунков
8.7. Оформление таблиц
И т.д.

Сами требования к оформлению, допустим, основного текста отчетных документов, описывали следующим образом:

"Абзацы должны быть оформлены следующим образом:
-   шрифт: Times New Roman, 12 пт.;
-   первая строка: отступ 1,27 см;
-   междустрочный интервал: 1,5 строки;
-   выравнивание: по ширине;
-   без переноса в словах."

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

Конечно, здесь можно много спорить относительно использования различных государственных стандартов смежных по отношению к 34-ой серии. Однако в нашем случае практика показала, что отказ в передаче отчетного документа Исполнителя на тех.политику Заказчика по формальным признакам ГОСТ после предварительного рецензирования методологами побуждает проектные команды использовать положения выше указанных Правил для сдачи этапа / проекта в целом.

8
Добрый день!

blackx, если правильно вас понял, то речь идет о необходимости "слияния" с использованием элемента Merge (коль уж говорим об Activity Diagram из UML).

Более детальная информация есть здесь, здесь и, например, здесь.

9
Марина все проще и сложнее.

1. http://www.uml2.ru/forum/index.php?topic=312.msg30830#msg30830
2. Не надо включать отображение унаследованных атрибутов и так отобразяться
Связь в итоге получается Dependency? Проводите ее и указываете этот стереотип вручную?

10
Для отображения у дочернего элемента атрибутов родительского следует:
1) Выбрать на диаграмме дочерний элемент, соединенный с родительским связью Generalization, вызвать контекстное меню и указать Feature Visibility
2) В открывшемся окне в группе Inherited Features отметить опцию Show Attributes

Если же нужно от класса сделать N-экземпляров, указав у них значения наследованных атрибутов, то для этого следует использовать в контекстном меню дочернего элемента пункт Advanced -> Override Attribute Initializers. В открывшемся окне будет возможность указать наследованный атрибут, его значение и примечание.

11
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 28 Марта 2013, 23:22:37 »
Добрый день!

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

Добрый!

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


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

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

12
Денис, спасибо за ответ.
Насчет "как" — все понятно. А вот насчет "что потребуется": не мог бы ты уточнить, с помощью какого ПО можно сделать справочную систему, подобную той, что упомянута в 1 сообщении? Интересует техническая часть вопроса.
Ответ по технической части вопроса: смотри helpandmanual.com
В исходниках js (helpman_navigation.js) прописано, откуда они взялись (EC Software).

13
А зачем вообще пытаться нагромоздить требования такой деталистикой?

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

Если такой вариант не подходит, то, видимо, придется либо плодить приложения к ТЗ, на которые будут ссылки из требований, зафиксированных в тексте, либо (если разрабатываете) в ПЗ в соответствующих подразделах с описанием основных технических решений.

Смотрите сами, но стадии и комплектности документов для этого и придуманы.

14
А Google Sites поддерживают JavaScript, который активно используется на страницах сгенерированного HTML Report'a EA?
Можно через FTP оперативно загрузить, например, на narod.ru, если есть почтовый аккаунт на Яндексе.

15
Sparx / Re: Добраться до Элементов JScriptom
« : 14 Июля 2012, 13:51:28 »
Привет!
Смотря что ты имел в виду под "вложенными (дочерними)" элементами.

Добраться до свойств элементов, которые в иерархии располагаются на уровне ниже, чем выбранный элемент на JS можно, например, так:

function childElemFunc()
{
Repository.ClearOutput("Script")
Repository.EnsureOutputVisible( "Script" );

Session.Output( "++++++++++++++++++++" );

var curElem as EA.Element;
curElem = Repository.GetTreeSelectedObject(); //возвращает выбранный в браузере проекта элемент (или пакет)

var childElem as EA.Element;

for ( var i = 0 ; i < curElem.Elements.Count ; i++ ) //итерация по всем элементам 1-го уровня, находящимся под выбранным элементом
{
childElem = curElem.Elements.GetAt(i);
Session.Output("Дочерний элемент: " + childElem.Name); //вывод имен дочерних элементов
}

Session.Output( "++++++++++++++++++++" );
}

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

childElemFunc();

Для решения какой задачи нужны дочерние элементы?

Страницы: 1 2 3 4 5 6 »