¬аше окно в мир —јѕ–
 
Ќовости —татьи јвторы —обыти€ ¬акансии Ёнциклопеди€ –екламодател€м
—татьи

26 но€бр€ 2019

—овместна€ работа в Renga 3.3

јнастаси€ “€н, »ль€ ћаз

јнастаси€ “€н »ль€ ћаз

јнастаси€ “€н Ц технический писатель, »ль€ ћаз Ц технический директор, Renga Software
ƒорогие читатели! ѕросим вас простить нас за долгое отсутствие. Ќадеемс€, что вы следили за Renga в других источниках и знаете, что здесь долго не было заметок не потому, что нам было не о чем сказать.

—егодн€ хочетс€ поговорить о том, что мы так долго готовим, а многие так долго ждут. Ёто —овместна€ работа в Renga.

”же в ближайшее врем€ вы сможете работать всем отделом над одним проектом в Renga, не разговарива€ со своими коллегами (шутка, мы категорически рекомендуем общатьс€).

≈сли коротко, то дл€ совместной работы вам понадобитс€ Renga Server и всего две кнопки в вашей Renga: —инхронизировать и ќпубликовать. ¬ общем-то можно отделатьс€ парой слов. Ќо мы знаем наперед, что эти две команды (а вернее, отсутствие каких-либо других команд) могут стать €блоком раздора, и чтобы не возникло недопонимани€, хотим рассказать вам о нашем замысле подробно.

Ќачнем наш разговор с теории.

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

ѕервый тип, самый пон€тный и доступный каждому, Ц это диалог. “ехнологии, которые помогают диалогу, всем известны Ц телефон, различные мессенджеры и электронна€ почта.

Renga совместна€ работа

¬торой тип Ц это заключение сделки. ќн предполагает обмен чем-то, проводитс€ по определЄнным правилам, а в результате заключени€ сделки мен€ютс€ отношени€ между ее участниками. “о есть один человек становитс€, например, продавцом, а другой покупателем. ѕрограммное обеспечение, которое предназначено дл€ такого вида взаимодействи€ должно надежно хранить новые статусы участников.   такому программному обеспечению относ€т системы управлени€ транзакци€ми, например 1—:ѕредпри€тие.
Renga совместна€ работа

» третий тип Ц сотрудничество, то есть люди работают вместе дл€ достижени€ общих целей, при этом происходит обмен знани€ми, обучение и достижение согласи€. Ќапример продвижение новой идеи, создание новой конструкции. „етких правил, как действовать при сотрудничестве, нет. ѕолучаетс€, что технологии дл€ его обеспечени€ должны быть достаточно гибкими. ќни должны включать в себ€ и управление данными, и средства дл€ ведени€ обсуждений, и возможность восстановить историю внесенных изменений, и многое другое.
Renga совместна€ работа

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

Ќадеемс€, что возражений нет, продолжаем.

ƒавайте разберемс€, зачем нам вообще налаживать это сотрудничество с помощью Renga, вроде как-то раньше справл€лись? “ак-то оно так, но вы могли работать только последовательно, один поработал, передал проект другому, потом третьему, а если третьего не устроило, он оп€ть первому передал, и так по кругу. ѕроцесс зат€гиваетс€. ”ж если работаем в команде, то хочетс€, чтобы все члены команды могли работать над одним проектом одновременно.

ќдновременно? Ќа этом придетс€ остановитьс€ поподробнее.  огда люди работают параллельно над одной задачей, сама€ непри€тна€ ситуаци€, котора€ может возникнуть, это конфликт, то есть ситуаци€, когда разные пользователи измен€ют одни и те же данные одновременно и по-разному. ѕоэтому ключевой вопрос, над которым бьютс€ разработчики ѕќ, как обрабатывать конфликты.

ѕопытки ответа на данный вопрос привели к возникновению трех основных стратегий организации совместной работы:

  1. ќптимистичный контроль параллелизма (Optimistic concurrency control). ѕредполагаетс€, что изменени€, полученные от разных пользователей при работе приложени€, могут примен€тьс€, не меша€ друг другу. ¬о врем€ работы данные не блокируютс€. ѕеред записью данных кажда€ транзакци€ провер€ет, что никака€ друга€ транзакци€ не изменила прочитанные данные. ≈сли проверка вы€вл€ет конфликтующие изменени€, транзакци€ отмен€етс€ и может быть перезапущена.
  2. ѕессимистичный контроль параллелизма (Pessimistic concurrency control). ѕредполагаетс€, что два или более пользовател€ обновл€ют одни и те же данные одновременно, что приводит к конфликту. „тобы его предотвратить, приложение блокирует обновл€емые данные, и пока блокировка не будет сн€та, то есть пока первый пользователь не закончит редактирование данных, доступ к ним будет ограничен дл€ других пользователей.
  3. Ђ¬ыигрывает последнийї (Last writer wins). ¬ этой стратегии данные просто перезаписываютс€ последним.
ѕосмотрим, как обычно эти стратегии примен€ютс€, и решим, кака€ из них подходит дл€ совместной работы в Renga.

—ама€ проста€ стратеги€ из трех представленных это, разумеетс€, Ђ¬ыигрывает последнийї. ¬ этом случае совместна€ работа может быть устроена, например, с помощью файловой системы. ‘айл проекта хранитс€ на сетевом диске, открываетс€ на разных рабочих компьютерах. ≈сли пользователи внесли изменени€ одновременно, то при сохранении проекта каждым из пользователей итоговый проект будет ровно таким, каким он был у последнего пользовател€, то есть данные всех остальных пользователей будут утер€ны. —огласитесь, организовать работу команды в таких услови€х довольно сложно.

ƒавайте рассмотрим ѕессимистичный контроль параллелизма. „тобы защитить своих пользователей от потери данных, разработчики приложений блокируют файл, то есть тот, кто открыл проект первым, сможет его сохран€ть, а все остальные смогут открыть его в режиме Ђтолько чтениеї и не смогут перезаписать. ƒанные, конечно, сохран€ютс€, но работа становитс€ не параллельной, а последовательной, и с точки зрени€ организации совместной работы, можно выделить следующие недостатки такого подхода:

  • ¬ один момент времени только один пользователь может вносить изменени€. „ем крупнее проект, тем больше людей необходимо дл€ работы над ним, тем острее данна€ проблема.
  •  аждое изменение требует его полного обновлени€ в любой системе, даже на сетевом диске (проектировщик подвинул колонну, а по факту получилс€ еще один файл).
  • Ќевозможно обеспечить автономную работу, так как чтобы редактировать файл, надо его заблокировать, а без доступа к серверу, даже просто к сетевой папке, нельз€ и заблокировать файл.
  • ≈сли забыли разблокировать, то никто не может редактировать файл.
ƒанный вариант используетс€ дл€ организации совместной работы в MCAD-системах, поскольку в них работа ведетс€ со множеством отдельных файлов-деталей. ј когда проект представлен одним файлом, то дл€ организации совместной работы его можно поделить на разные наборы данных внутри файла.

ѕосмотрим, что происходит в этом случае.  то-то открывает проект, блокируетс€ часть, с которой он работает. “ут есть свои плюсы и минусы.

ѕлюсы:

  • ¬ один момент времени сразу несколько пользователей могут вносить изменени€, но только в той части проекта, котора€ закреплена за каждым из них.
  • ћожно продолжать работать в своих част€х, даже если кто-то забыл разблокировать другую часть.

ћинусы:

  • Ќевозможно обеспечить автономную работу, так как чтобы редактировать часть файла, надо ее заблокировать, а без доступа к серверу, даже просто к сетевой папке, нельз€ заблокировать часть проекта.
  • ¬ проектах с большим количеством св€зей между объектами блокировка одного объекта может потребовать блокировки св€занных объектов.
  • ƒл€ организации совместной работы требуетс€ тщательное планирование. Ќужно определить, как и когда блокировать данные.
ƒанный вариант распространен в AEC-системах.

ѕринима€ во внимание минусы, продолжаем поиск.

¬споминаем, что мы, разработчики Renga, тоже ведем совместную работу. —истемы, обеспечивающие совместную работу программистов эволюционировали по мере развити€ информационных технологий и осознани€ плюсов и минусов каждой стратегии. ¬ результате в разработке сложного ѕќ чаще всего используетс€ стратеги€ оптимистичного контрол€ параллелизма. ћы работаем без вс€ких блокировок. ѕреимущества такого подхода:

  • Ќесколько пользователей могут вносить изменени€ одновременно.
  • ћожно свободно работать без огл€дки на блокировки и прочие условности.
  • ћожно работать автономно, потому что дл€ редактировани€ элементов не нужно уведомл€ть сервер о необходимости блокировки.
  • ћожно передавать минимальный набор данных дл€ синхронизации с сервером.

Ќо в нашей работе есть одно серьезное Ђної:

  • Eсли изменени€ внесены одновременно в один и тот же файл, то возникает необходимость объединени€ изменений, полученных от каждого участника. ѕри этом должны сохранитьс€ намерени€ всех.  огда изменена одна и та же строка, возникнет конфликт, который необходимо разрешить. ѕри разрешении конфликта, чтобы сохранить намерени€ всех пользователей, может по€витьс€ необходимость создани€ новой версии данных, отличной от простого объединени€ изменений. —оответственно, чем больше конфликтов, тем больше времени и сил будет потрачено на их анализ и разрешение.
≈сли вернутьс€ к выбору стратегии организации совместной работы в Renga, преимущества, несомненно, подкупают, а с недостатком придетс€ поборотьс€.

¬еро€тность возникновени€ конфликта можно уменьшить двум€ способами:

  1. ѕроводить синхронизацию данных между участниками проектировани€ как можно чаще, чтобы в момент прин€ти€ того или иного решени€ у пользовател€ всегда были актуальные данные.
  2. –азбивать данные на как можно более мелкие фрагменты, чтобы исключить пересечение измен€емых данных.
≈сли провести аналогию между разработкой программы и проектированием здани€ в Renga, то, допустим, строка кода аналогична параметру объекта. “о есть конфликт возникнет в тот момент, когда два проектировщика измен€т один и тот же параметр одновременно. ¬ыполнить объединение таких данных вр€д ли возможно. Ќо мы полагаем, что веро€тность такого совпадени€ практически стремитс€ к нулю при нормально поставленном процессе проектировани€ и когда участники проекта общаютс€ между собой и часто синхронизируют свои данные.

 онфликты при таком подходе к проектированию здани€ случаютс€ редко, поэтому мы остановились на стратегии ќптимистичного контрол€ параллелизма, и пользователи Renga получат следующие преимущества:

  • ќдновременно внесение изменений.
  • –абота без блокировки.
  • јвтономна€ работа.
  • ѕередача минимального набора данных дл€ синхронизации с сервером.

 ак уже было упом€нуто в самом начале статьи, в первой версии —овместной работы Renga мы реализовали обмен данных с помощью команды —инхронизировать. Ќа этом, конечно, развитие —овместной работы не остановитс€, и в следующих верси€х по€витс€ возможность обновлени€ проекта в режиме реального времени, тогда пользователи не смогут забыть о синхронизации и веро€тность возникновени€ конфликтов станет еще меньше.

Ќе переборщили с теорией? ѕереходим к практике.
  • »так, до начала работы на каком-то компьютере в локальной сети, назовем его сервер, нужно запустить Renga Server.

  •  то-то из команды создает проект, в котором добавл€ет необходимую информацию и, возможно, создает модель здани€.  огда он готов поделитьс€ своей работой и продолжить работу над проектом в команде, он нажимает кнопку ќпубликовать, а затем отправл€ет своим коллегам файл проекта любым удобным способом.

  •  оллеги сохран€ют файл проекта на своих компьютерах там, где им удобно, могут даже переименовать его.

  • „тобы продолжить работу над проектом, коллеги открывают проект и, периодически вызыва€ команду —инхронизировать, продолжают работу. ≈сли синхронизироватьс€ часто и при случае перекидыватьс€ парой слов между собой, то совместна€ работа будет максимально эффективной.

¬ общем, как только выйдет верси€ 3.3, скачивайте, устанавливайте и пробуйте работать вместе на реальных проектах. ј если после прочтени€ по€вились вопросы, задавайте их пр€мо сейчас!

»ллюстрации @sonya8berg



¬акансии:

јктуальное обсуждение

RSS-лента комментариев

-->

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: „то можно назвать Ђчудо-оружиемї отрасли —јѕ–?
ѕроект ЂЌародное —јѕ–-интервьюї

—лучайна€ стать€:

ќбзор инструментов платформы 3DEXPERIENCE дл€ полного цикла аддитивного [...] — јлексей —иверский, »ван Ћебедев (7 но€бр€ 2019)
isicad Top 10

—амые попул€рные материалы

   ‘орумы isicad:

isicad-2010 isicad-2008
isicad-2006 isicad-2004

ќ проекте

ѕриглашаем публиковать на сайте isicad.ru новости и пресс-релизы о новых решени€х и продуктах, о проводимых меропри€ти€х и другую информацию. јдрес дл€ корреспонденции - info@isicad.ru

ѕроект isicad нацелен на

  • укрепление контактов между разработчиками, поставщиками и потребител€ми промышленных решений в област€х PLM и ERP...
ѕодробнее

»нформаци€ дл€ рекламодателей


¬се права защищены. © 2004-2019 √руппа компаний «Ћ≈ƒј—»

ѕерепечатка материалов сайта допускаетс€ с согласи€ редакции, ссылка на isicad.ru об€зательна.
¬ы можете обратитьс€ к нам по адресу info@isicad.ru.