Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: vacoola от 06 Октября 2008, 19:30:38
-
Стоит задача разработать обмен между двумя системами.
Нужно описать архитетуру обмена: состав мигрирующих данных, правила миграции, правила синхронизации, права доступа к вводу данных пользователями.
Подскажите как это дело оформить.
-
А какова цель, преследуемая этим описанием, и кто будет потребителем результата?
Исходя из этого и следует описывать.
-
Если вас никто не направит к более современным документам, попробуйте посмотреть ГОСТ 19 и 34. Понимаю, что пользоваться ими непросто, но это лучше, чем совсем ничего.
-
Стоп. 474 задал правильный вопрос - кто потребитель. Давай дождемся ответа.
А чисто гипотетически можно предложить нарисовать Д взаимодействия м\у элементами и текстом описать входящие\выходящие данные и правила трансформации
-
Нужно разработать документ "Архитектура обмена данными". Какие есть варианты оформления такой документации? Не хочется делать самопал в произвольной форме, а хотелось бы оформить согласно какой то нотации.
-
Чего только не напридумывает руководство различного уровня и заказчики :-). Главное назвать это громко -- "Архитектура <чего-то>" ... слово-то какое наукообразное!
Вобщем именно такой архитектуры "обмена данными", как таковой, не существует. Более того, не вполне понятно назначение такого документа.
По классике выделяют бизнес-архитектуру, архитектуру информации и данных, архитектуру приложений (и в ее рамка программную архитектуру) и технологическую архитектуру. Иногда отдельно выделяют т.н. архитектуру безопасности, хотя по мне она "размазана" по всем вышеперечисленным архитектурам и выделять ее отдельно нет смысла -- просто остальные архитектуры следует проектировать с учетом требований информационной и прочей безопасности. Следовательно, некоего стандарта на именно такого рода ДОКУМЕНТ не следует ожидать.
По сути, обмениваться данными может либо бизнес-процесс, либо какие-то информационные системы, зачастую в рамках некоего бизнес-процесса (если речь не идет о бакапах и прочих "технических" делах ...). Кроме этого, архитектура призвана в статической своей части показать интерфейсы различных компонент и в динамической части -- в рамках чего и каким образом эти компоненты взаимодействуют. Очевидно, что в процессе взаимодействия будет происходить обмен данными, который можно явно выделить.
Говоря о нотациях, можно использовать различные подходы -- от DFD, до UML Activity with object flow и Sequence\collaboration ...
-
vacoola, Вы ведь подобный вопрос уже задавали здесь (http://www.uml2.ru/forum/index.php?topic=960.0) недавно? В чем смысл повторения?
-
Объединил две темы
-
Для начала, извините за повторение. Думал что никто не отвечает и написал еще раз. Проверял по RSS правда.
Потребителем будут руководство проекта и технические специалисты со стороны заказчика.
Главная цель понятно описать логику обмена понятную заказчику . А главное - подписать этот документ и и использовать его как аргументацию того что клиент должен заплатить за последующие до(пере)работки.
Ну и второстепенная цель - постановка задач разработчикам (но это уже на последующие проекты)
-
Возьмите для этого SRS. Там как раз будут и цели проекта и ФТ и БПр и НеФТ. + еще нарисуйте диаграмму взаимодействия между системами, в ФТ укажите что нужна такая-то передача данных между такими-то Системами и ссылка на раздел БПр, где будет расписаны правила трансформации данных.