Моделирование проекта бед

Question

В нашей компании мы начали использовать VS 2010 для моделирования наших систем, в так называемых модельных проектах. Они находятся под контролем исходного кода TFS2010.

Это хорошо для одного пользователя, но как только мы представили этот инструмент для всей нашей команды архитекторов, мы столкнулись с серьезной проблемой: он крайне плохо справляется с несколькими пользователями! Позвольте мне провести вас по простому сценарию.

1. Архитектор 1 проверяет существующую диаграмму и некоторое время работает над ней
2. Архитектор 2 добавляет новую диаграмму и некоторое время работает над ней
3. Архитектор 2 проверяет свою новую диаграмму
4. Архитектор 1 проверяет свои изменения в модельном проекте
5. Архитектор 2 снова открывает свою диаграмму, но обнаруживает, что все элементы в ней отсутствуют!

Как я понял, проблема в том, что архитектурный проект основан на нескольких XML-файлах и, в частности, одном важном огромном фрагменте XML-файла, который называется ModelDefinition / Architecure.uml. Он содержит много знаний о диаграммах в проекте моделирования. Когда несколько человек вносят несколько изменений в этот файл одновременно, инструменты (TFS, VS) не обрабатывают необходимое объединение автоматически, и у нас остаются огромные проблемы параллелизма.

Так что в моем сценарии, поскольку в файле Architecture.uml, который зарегистрировал архитектор 1, ничего не известно об элементах, добавленных архитектором 2, эти элементы перезаписываются или иным образом разрушаются.

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

Итак, наше текущее «решение» - работать с использованием эксклюзивных проверок. Таким образом, только один архитектор может работать одновременно!

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

Answer 1

Попробуйте «разделяй и властвуй»: возможно ли, что каждый архитектор работает над своей личной ветвью, а затем все объединяется в «магистраль»?
Во время этих слияний должны появляться конфликты.

---

РЕДАКТИРОВАТЬ
Вы можете использовать инструмент, специфичный для XML, например, представленные здесь .
Таким образом, вы должны сохранитьподход ветвления на каждого архитектора, НО вместо использования одношагового слияния TFS вы можете:

• Выполнить сравнение каталогов между вашей папкой 'branch' и вашей папкой 'trunk'.Каждый найденный файл подлежит слиянию.
• Объедините каждый найденный файл в папку «ветвь», используя один из инструментов, представленных в статье.Я использовал Altova DiffDog , это очень хорошо - но имеет большой приз.
• Проверьте, что все в порядке, затем подтвердите «ветку».
• Теперь объединитес TFS-слиянием в 'trunk', которое теперь должно быть тривиальным слиянием.