2.4 Разработка физической модели данных
Составим схемы создаваемых объектов подсистемы синхронизации в виде диаграмм. Так как в разработке участвуют справочники основной конфигурации УНФ, большинство стандартных реквизитов, не связанных с разработкой и обменом, будет упущено. Добавленные для разрабатываемой системы реквизиты имеют префикс «ec». Стрелками обозначены связи между объектами. На рисунке 12 представлена схема справочника «Номенклатура» и связанных с ним объектов.
Рисунок 12 – Схема справочника «Номенклатура» и связанных с ним объектов
Разрабатываемая система представляет собой автоматический обмен данными между двумя программами и их базами. На рисунке 13 представлена схема обмена информацией между базами для справочника «Номенклатура» в «1С: УНФ» и таблицами программы ЕС. Один справочник в 1С соответствует нескольким справочникам (таблицам) в чертежной программе. При обмене механизм должен это учитывать и обращаться к таблице, соответствующей типу номенклатуры, которой в данный момент обменивается. В схему включен справочник «ХарактеристикиНоменклатуры», так как он тесно связан со справочником «Номенклатура».
Рисунок 13 – Схема обмена информацией справочника «Номенклатура»
Также в подсистему синхронизации данных входит функционал работы с заказом покупателя, который включает в себя создание заказа и обновление информации по заказу. На рисунке 14 представлена схема создания заказа.
Рисунок 14 – Схема создания заказа покупателя
В 1С заказ покупателя должен заполняться данными из справочников, а автоматический обмен создавать заказ в базе программы ЕС.
2.5 Требования к надежности и сохранности данных
Разработанная система должна выполнять минимальные требования по надежности и сохранности данных при работе с ними. При работе пользователей с системой должны быть исключены или обработаны ситуации, при которых система может аварийно завершить работу и повлечь за собой утерю важных данных. Такие ситуации могут возникнуть при работе синхронизации данных, так как в данном механизме будет задействована база данных чертежной программы и в самых простых случаях она может быть недоступна. Такая ситуация должна заканчиваться предупреждением пользователя о том, что база не доступна или параметры подключения к базе некорректны [19].
2.6 Архитектура системы и ее взаимодействия
Создаваемая система в серверной части будет состоять из двух программ и их баз данных. Клиентская часть будет состоять из двух программ. Серверная часть будет вынесена на отдельный физический сервер, клиентские приложения будут обращаться к ней и получать ответ [10]. На рисунке 15 изображена архитектура будущей системы.
Рисунок 15 – Архитектура системы
Разрабатываемая система синхронизации данных будет являться активным компонентом взаимодействия между программами
2.7 Состав аппаратно-программного обеспечения
Внедряемая система не требует никаких особых технических характеристик и будет использоваться на имеющихся ресурсах аппаратно-программного обеспечения организации. На рисунке 16 представлена схема аппаратного обеспечения.
Рисунок 16 – Схема аппаратного обеспечения
Взаимодействие систем будет вестись в локальной сети организации. Имеется возможность подключить удаленных пользователей через настроенную виртуальную частную сеть (VPN) на маршрутизаторе.
Выводы по главе 2
В данной главе последовательно описана разрабатываемая система. Была выбрана система для реализации разработки. Описана функциональная структура разрабатываемой системы и описаны объекты, входящие в ее состав, дано подробное описание объектов и их функций. Разработаны физические модели объектов с указанием названий и типов данных, а также составлены графических модели. Сформулированы требования к надежности и сохранности данных. Представлена архитектура системы и ее взаимодействия, а также представлен состав аппаратно-программного обеспечения.
Хороший пост, поделился с друзьями.