91

Системный Анализ и Требования / Re: ...

« : 26 Июля 2016, 15:50:42 »

Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.

Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

При этом правило преобразования - это что-то простое (типа функции строка в дату), а не некоторая волшебная палочка

Поскольку вся интеграция идет черех xml или rest, то интеграционщики захотят в итоге именно такой формат. А обработка всех исключений, более сложные преобразования и т.д. должны быть описаны ранее в "обвесе". Если это интеграция, то это опять же оправдано, поскольку интеграционщики будут брать описания триггеров из одного места, а не выцеплять их из всего проекта.

92

Системный Анализ и Требования / Re: ...

« : 26 Июля 2016, 15:12:08 »

Огласите полный список... атрибутный состав объектов, пожалуйста.

Непонятен контекст. Кроме того, что два сервера между собой как-то обмениваются данными непонятно ничего.

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

Применение МДМ системы - это жест отчаянья. Это когда с компанией поработало пара десятков консалтинговых компаний под эгидой трех-пяти системных интеграторов, в итоге получился зоопарк систем, которые надо как-то сопрячь. Причем часть из этих систем не работает, часть уже не работает, а отчетность как-то получать нужно. IMHO если кто то образцом такого ТЗ и поделится, то разбираться в нем вы будете не один месяц

Совершенно другой поток моделирования при интеграции. Там все проще - если концепция интеграции прозрачна для понимания, то как правило проект интеграции имеет примерно следующую структуру :
- ER или диаграмма классов сопрягаемых систем (полная или в части взаимодействия)
- Описание взаимодействия (раньше применяли DFD, теперь диаграмма кооперации или диаграмма последовательности)
- mapping - таблица соответствия куда во что и какие правила преобразования
- Ну и потом собственно проектируете ваше интеграционное приложение , детализация этого проекта определяется тем, что вы будет для интеграции использовать

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

 

93

Системный Анализ и Требования / Re: Описание проверки при получении данных из другого сервака

« : 26 Июля 2016, 14:01:22 »

И дальше следует перечень тех самых открытий, которые автору темы еще предстоит сделать. )

Именно. Мои познания оттуда же.
А вообще, задача практически реликт девяностых-нулевых. Автору сильно "повезло".

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

94

Системный Анализ и Требования / Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 26 Июля 2016, 13:38:59 »

По сути эти правила сопоставления - обычные бизнес-правила.

На мой взгляд неплохой формат вот такой:

https://help.salesforce.com/apex/HTViewHelpDoc?id=workflow_examples.htm&language=ru#ContractExpire

95

Системный Анализ и Требования / Re: Описание проверки при получении данных из другого сервака

« : 26 Июля 2016, 13:18:12 »

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

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

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

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

Для реализации механизма обработки коллизий у элементов НСИ должно быть два ID - один внутренний, технический (какой-нибудь ROW( 8 ), маскированный идентификатором узла сети), и внешний, который польователю показывается.

Насколько я понимаю в 1С примерно так же филиальная система поддерживается.

В 90е - 0е зачастую со связью было совсем не густо, поэтому крутились как могли

96

ПО Аналитика / Re: Реверс-инжениринг с Python на UML

« : 26 Июля 2016, 12:50:27 »

При ближайшем рассмотрении идея получать диаграммы последовательности и диаграммы состояний по стеку оказались не лишены недостатков - похоже такая технология применима  только для desctop приложений под windows. Под линукс EA ставится только под Wine

http://www.sparxsystems.com/support/faq/enterprise-architect-WINE.html

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

А уж если брать варианты со всякими специфические диалекты Linux (типа Astra Linux), то там  вообще проблемы гарантированы.

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

В идеале было бы сделать рекордер вообще автономным. Чтобы он мог самостоятельно писать в некоторую базу или файл, а в EA его только обрабатывать. А рекордер собирать для отдельный для каждой ОС, заодно можно избавиться от привязки к языку программирования.

97

ПО Аналитика / Re: Реверс-инжениринг с Python на UML

« : 26 Июля 2016, 10:49:47 »

Большую работу вы проделали.

Гуглить не мешки ворочать

Кстати с фирмой либерлибер у меня есть контакты, если что. Личные

Класс!

Я кстати не понял, либерлибер разработали эту функциональность под EA, или только активно используют?
Насколько реально получить в EA поддержку Python самостоятельно, через Sparx или LieberLieber?

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

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

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

98

ПО Аналитика / Re: Реверс-инжениринг с Python на UML

« : 25 Июля 2016, 11:58:45 »

О! И генерация sequence в EA есть!

http://blog.lieberlieber.com/2010/09/22/enterprise-architect-auto-generating-a-sequence-diagram-from-code/

Но питона в списке поддерживаемых языков нет

Record executing programs and represent the behavior as a UML Sequence diagram; recording is supported for:

    Microsoft Windows Native C
    Microsoft Windows Native C++
    Microsoft Windows Visual Basic
    Microsoft .NET Family (C#, J#, VB)
    Sun Microsystems Java
    PHP

http://www.sparxsystems.com/enterprise_architect_user_guide/9.0/visual_execution_analyzer/using_the_execution_analyzer.html

99

ПО Аналитика / Re: Реверс-инжениринг с Python на UML

« : 25 Июля 2016, 11:54:20 »

EA как то не очень похож на такой продукт...

Виноват, у EA есть возможность вообще вести полностью разработку в его среде (раздел Analyser). Там и средства отдадки можно настроить. Так что потенциально у EA такая возможность может появится

100

ПО Аналитика / Re: Реверс-инжениринг с Python на UML

« : 25 Июля 2016, 10:36:06 »

Спасибо !

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

Visual Paradigm умеет строить sequence  diagramm , но почему-то только по java

https://www.visual-paradigm.com/support/documents/vpuserguide/276/277/39788_javatosequen.html

В EA диаграмму классов построить удалось (довольно неплохую), а вот признаков построения sequence  diagramm не обнаружено.

IMHO, для построения  поведенческих диаграмм по ОО коду исходников недостаточно (тем более для интерпретаторов типа Python или Perl). Скорее нужно средство типа debugger, который имея исходники может при исполнении программы фиксировать последовательность вызовов, а потом их обрабатывать и строить UML.

EA как то не очень похож на такой продукт...

101

ПО Аналитика / Реверс-инжениринг с Python на UML

« : 22 Июля 2016, 13:26:53 »

Добрый день!

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

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

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

102

Примеры / Re: Дипломная работа: варианты использования+диаграмма деятельности по СЭД

« : 28 Июня 2016, 14:52:25 »

Скажите, а в таком виде, корректна диаграмма?

Может она конечно и корректна. Но большие сомнения, что кому - то нужна.

Создание диаграммы вариантов использования имеет следующие цели:

Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
Сформулировать общие требования к функциональному поведению проектируемой системы
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями

Какие из этих целей преследует эта диаграмма? Насколько она их достигает?

103

Примеры / Re: Дипломная работа: варианты использования+диаграмма деятельности по СЭД

« : 23 Июня 2016, 14:39:12 »

Начиная с какой-то версии UML появилось дурацкое правило, что неуказанная мощность полюса равна 1 (т. е. 1..1).

Да вот с мощностями проблем нет.  Редко сталкивался с необходостью использования системы группой лиц по предварительному сговору:)

А вот втыкал две ассоциации в один ВИ частенько... Искренне считая, что по умолчанию xor

104

Примеры / Re: Дипломная работа: варианты использования+диаграмма деятельности по СЭД

« : 23 Июня 2016, 14:10:18 »

Оказывается не так у редко такой прием встречается

105

Примеры / Re: Дипломная работа: варианты использования+диаграмма деятельности по СЭД

« : 23 Июня 2016, 13:32:55 »

Чувствую себя студентом на комиссии.

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

Кстати в силу чего считается,  что по умолчанию И?