Позволю себе ответить цитатой из книги Арлоу и Нейштадт. UML 2 и Унифицированный процесс, 2-е издание
Эдуард, спасибо!
Кажется, это как раз мой случай:
• При моделировании деловой активности:
• для моделирования бизнес¬процесса.
Прошу прощения за некоторую задержку с ответом - не было возможности и времени почитать форум
Спасибо за ответ, очень на него надеялась и ждала
Все ответы читаю сразу, но самой возможности написать развернутый ответ обычно нет.
Одно другому не мешает, Вы же не имеете в виду децентрализованное решение, когда каждый компонент или группа компонентов полностью самостоятельны. Централизованное решение - это когда все данные, например, хранятся в центральной базе. Типичный пример, этот сайт. С другой стороны, централизованное решение может быть распределенным в некоторой части, т.е. иметь несамостоятельные (являющиеся частью общего) куски приложения. Собственно, это как раз Ваш случай. Только Вам еще нужно перед защитой хорошо разобраться, какая часть решения входит в "центр", а какая "является распределенной". Скорее всего Вам такой или подобный вопрос зададут, поэтому надо держать в голове (или записать на бумажке - пояснительной записке) принципы, определяющие централизованное и распределенное решения.
За совет про принципы – спасибо! Обязательно посмотрю. У меня действительно в голове путаница, что есть централизованное и распределенное решение.
Ну вот, Вы же сами описываете свою систему как централизованную: единые справочники, движение информации в территориальном смысле, документы должны приходить в центральный офис и т.п.
Простейший способ - иметь одну центральную базу и ее образы (зеркала) на участках, такой механизм поддерживается основными производителями СУБД. Однако, у Вас одновременно и участков много (соответственно, их оснащение соответствующим оборудованием и ПО может представлять собой отдельную проблему), и интернет на них дохлый (что является уже другой проблемой). Разумным способом является регламентировать и сократить обмен информацией - слать только ту, что нужно. Например, обновление справочников слать ежемесячно или еженедельно, а данные о движении ГСМ - ежедневно.
Как вариант, подумайте над тем, чтобы не полностью зеркалить базы между участками, а только в той части, которая нужна для выполнения отдельных операций, например, первичная выписка документов.
Одна центральная база и зеркала это однако немножко не то (ИМХО), так как при таком варианте данные меняются в центре, а участки выступают получателями, но ничего не передают центру. Такая схема может быть реализована в том же Microsoft SQLServer'е. В моём же случае требуется двусторонний обмен, да ещё и желательно с офф-лайн репликацией, чтобы можно было файл выгрузки на дискете привезти или по электронной почте отправить.
Насколько я поняла, тот же MS SQLServer такого уже не поддерживает. Офф-лайн репликацию поддерживает, например, Sybase ASA и какой-то из очень дорогих вариантов Oracle. В моём дипломе предлагается бюджетный вариант реализации ИС на базе СУБД Firebird + IBReplicator от IBPhoenix. Хотя, честно говоря, сейчас сразу смотрела бы в сторону Sybase ASA.
В пользу зеркальных баз вижу следующие доводы:
- Справочники для выписки документов нужны все. В задаче ставится, чтобы водитель мог получить историю своего подотчета по ГСМ у диспетчера на любом участке. Поэтому документы тоже нужны практически все. Да в общем-то их не так уж и много, у меня в логической модели данных около 30 сущностей получается, штук 10 справочников, и 4-5 видов документов.
- Кроме того, на мой взгляд, репликацию зеркальных баз проще настраивать, да и в случае обвала какой-то из баз большая часть информации останется.
Довод в пользу не зеркальных баз – уменьшение трафика. Но Интернет там не то чтобы дохлый, скорее возможны перебои. Т.е. когда интернет есть, то скорость обычно нормальная.
Другое дело, что из 1С справочники можно выгружать не полностью. Например, справочник «Номенклатура», где нужны-то только разные бензин и дизтопливо. Здесь да, надо предусмотреть какую-то форму выгрузки, чтобы бухгалтер ставил галочки и выгружал выбранные элементы или группу, а не все 150 видов гвоздей и бруса, только потому, что у них поменялась одна буква в наименовании или их перенесли в другую группу.
Ой, только сейчас поняла, что мне придётся ещё и в 1С как-то отслеживать изменение справочников с последней выгрузки. Ужас-то какой
.
В общем-то получается, что проблемы основные не столько с основной функциональностью системы, сколько с необходимостью взаимодействия с 1С и распределенностью.
Непонятно, почему Вы делаете такой вывод (о дублировании, о сверке и т.п.)? Вам нужно четко представлять движение информации (судя по всему пока этого нет): где, какая информация появляется, где вводится, куда направляется и для каждого подобного информационного объекта нарисовать внятную диаграмму (или хотя бы отсебятинскую картинку), которая детально показывает особенности этого движения.
Ведь в конечном счете Ваша задача собрать в 1С всю информацию о движении ГСМ, поступившую из разных источников. Это же не значит, что Вы всегда должны гонять по системе полные данные. Если водитель поехал из точки А в точку Б и там закрывает путевой лист, Вы же не будете ждать закрытый лист из точки А, а используя единую идентификацию ПЛ спокойно найдете его в центральной базе (или ее копии в пункте Б) - главное предусмотреть, что пока водитель едет по своему маршруту, и центральная база и ее копия в пункте Б обновилась.
О дублировании информации и сверке.
Допустим, наша организация решила закупить ГСМ и оплатила счет компании-поставщика.
Поставщик отгружает ГСМ, но не нам, а организации, с которой у нас заключен договор ответственного хранения (на каждом участке разные организации).
Затем с участка на склад организации хранящей ГСМ едет водитель бензовоза с доверенностью на получение ГСМ, где и заливает Дизтопливо в бензовоз. Там он получает расходную накладную, выписанную организацией-посредником, на основании которой в диспетчерской системе приходуется топливо (там указано только количество). Таких расходных накладных несколько на один оплаченный счет.
Поступление ГСМ по бухгалтерии оформляется в 1С документом «Поступление материалов» на основании счета-фактуры и расходной накладной выписанных организацией-поставщиком (там указаны и количество и сумма). Такие счет-фактура и расходная накладная по одному на один оплаченный счет.
Таким образом, пока у меня получается, что одно и то же поступление ГСМ учитывается 2 раза – в диспетчерской системе и в 1С. Причем количество поступивших ГСМ в документах и количество самих документов не совпадают. Тут необходима сверка.
Что касается перемещения и расхода ГМС, то там дублирования вроде нет.
Про диаграмму – да, Вы правы, большое спасибо за совет! Действительно, надо как-то это внятно представить. Получится такая схема документооборота. Наверное, надо почитать про DFD, что-то мы их очень невнятно проходили…
С другой стороны может быть достаточно написать/напечать на путевом листе уникальный номер, сгенеренный системой и тогда операции прихода и расхода ГСМ могут быть введены раздельно, но тогда они должны быть сведены в центре. Вот и получится искомая прозрачность. В общем, надо подробнее смотреть на операции - будучи детальнее знаком с постановкой, я бы, наверное, мог бы предложить ряд технических решений, но думаю, что это и Вам по силу. Более того, это как раз и есть Ваша задача - не только показать "ЧТО Вы знаете", но и "КАК Вы умеете эти знания использовать".
Какая интересная идея!
Действительно, прозрачность...
Однако реализация такого механизма слияния, мне кажется, будет более сложной, чем просто подождать и дозаполнить документ. Однако сама идея!
Технически может быть проще несколько денормализовать данные об остатке ГСМ и сохранять не каждую операцию независимо друг от друга, а на каждую операцию хранить входящий остаток, изменение и исходящий остаток. Причем, т.к. операции могут быть приходные и расходные, то можно было бы хранить их в одной записи, но в разных колонках (пусть иногда и с нулевыми значениями). Я так однажды делал, это мне сильно упростило подготовку отчетов о движении объекта учета.
Про две колонки поняла, тоже думала, в общем-то разницы особой нет.
А вот про независимость операций. Если вдруг пришла какая-то операция по данному транспортному средству, введенная в другой базе два дня назад, то мне нужно будет пересчитать в моей базе входящий и исходящий остатки в операциях за последние 2 дня по этому транспортному средству? На первый взгляд, это сложнее чем просто хранить операции, где указана цифра прихода/расхода, а пересчет остатков идёт в конце месяца при закрытии периода.
Хотя сейчас подумала, что, в общем-то, в путевых листах оно так и хранится. Там конкретные цифры прихода, расхода, изменения, а также экономия/перерасход. Друг от друга путевые листы не зависят, хотя связаны с заправочными ведомостями (из них берется приход).
Возможно, когда я до этого дойду (если дойду), то в голове уже сложится картина, как это должно выглядеть.
и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.
Понятно, спасибо!
Пока пришла к выводу, что таблицы остатков и движений на диаграмме классов опущу, так как для задачи они не принципиальны. В общем-то остатки и движения для отчетов можно и по документам собирать. Чувствую, что так и будет
.
Что касается особенностей реализации, возможно на диаграмме классов стоит отразить будущую распределенность базы. Поэтому рассмотрю возможность добавления справочника информационных баз и атрибутов принадлежности документов к базам.
ИС Учета ГСМ. Use case и другие