Форум Сообщества Аналитиков

×


ИС Учета ГСМ. Use case и другие(Прочитано 49506 раз)
Re: ИС Учета ГСМ. Use case и другие Ответ #45 : 24 Мая 2010, 00:45:28
Цитата: Лопушок
Диспетчера в подразделениях работают вахтовым методом, периодически сменяются, могут менять участки. Кроме того, большая текучесть кадров. В общем чтобы быстро передавать дела друг другу, не объясняя, что в этом журнале я записываю то-то и так-то, а здесь я веду это...
Да и вообще это как-то удобнее, главный диспетчер требует с диспетчеров на участках отчеты по одинаковым формам, одинаково им объясняет что и как делать. Требования соответственно также ко всем одинаковые. С поправкой на объём работы, конечно. Он везде разный.

Это понятно, но сформулируйте это проще, в терминах "снизить" или "повысить", "улучшить" и т.п.

Цитировать
Это я как проблему не выделяла, просто сообщила для сведения.

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

Цитировать
Я имела ввиду, что ежемесячно данные по движению ГСМ будут выгружаться в 1С.
Сами же данные в литрах (в диспетчерской базе) будут доступны в центральном офисе после каждой репликации с базами удаленных подразделений, которые должны происходить несколько раз в день.

во-первых, проще сделать централизованное решение, все равно у каждого участка своя совокупность данных о ГСМ, ТС и водителях, так что они не перепутаются. или там интернета нет?
во-вторых, надо бы четко разделить какие данные в какой системе будут вестить, и как системы будут ими обмениваться.

Цитировать
Это меня на нём замкнуло. Всё про него думала-думала и свыклась. В общем-то технически я его всё равно не успею реализовать, слишком много там нюансов.

тоже вычеркивайте... нет проблемы (которая решается партионным учетом) - нет смысла что-то решать (этим способом), только усилия зря тратить...

Цитировать
Да, Вы правы. Я заметила в своей модели перекос - с одной стороны сильное упрощение, часть сущностей вообще опущено, с другой - усложнение, связей слишком много и они трудно отслеживаются. В общем, наблюдается явный диссонанс.

когнитивный? :о)))
начните с главного. Что у Вас главное?

Цитировать
Книгу читала не раз, но помню только дрессированную собаку, которая объелась и больше не хотела показывать фокусы.  :D

А, точно! Было такое (позабыл уже, хотя недавно читал :о)))! Впрочем это тоже к Вашему случаю подходит :о))) с логической моделью данных.

Цитировать
Хм, по модели вроде можно отследить где и сколько топливо находится, а модель всё равно какая-то корявая. Видимо, слишком много там от логической модели. Очень трудно от этого уйти. :-\

Выделите места, где у Вас могут находиться ГСМ (нарисуйте их). Определить (выпишите) действия, которые могут происходить с ГСМ (это будут  Ваши стрелочки перемещений). Зафиксируйте состояния, в которых могут находиться ГСМ, и какие документы каждому переходу или состоянию соответствуют.
Проиграйте ситуацию от "на склад поступила тонна горючего", до "все горючее израсходовано и списано". Нарисуйте это на схеме пусть даже без моделирования (на UML).
Потом задайте вопрос: какие данные нужны на каждом этапе? Нарисуйте сущности (справочники пока можно не рисовать, только отмечайте? что нужно будет поместить в справочники) и опираясь на движение ГСМ (в соответствии со схемой) сопоставьте сущности с ним (когда и какие данные будут куда попадать)
Если сделаете последовательно и аккуратно, то найдете большинство ответов на безответные вопросы. А потом возьметесь за справочники.

Цитировать
За это отвечает сущность "ГСМ в баках", там должен быть ещё реквизит "Дата".

Ну и дальше как Вы ответите на этот вопрос (сколько осталось)?

Цитировать
А сущность "ГСМ на сотруднике" должна отслеживать на каком сотруднике в каком подразделении каких ГСМ сколько содержится. (У нас учет подотчета по сотрудникам идёт в разрезе подразделений)

Так Вы все-таки стремитесь к ведению параллельного учета в нескольких системах? Это более сложная задача, чем у Вас сейчас получается... Лучше пока сконцентрироваться на основном потоке информации, ляжет на схему, заработает - можно будет подумать и о расширении.

Лью воду...



Re: ИС Учета ГСМ. Use case и другие Ответ #46 : 25 Мая 2010, 20:47:59
Это понятно, но сформулируйте это проще, в терминах "снизить" или "повысить", "улучшить" и т.п.
Поняла.  ;)

во-первых, проще сделать централизованное решение, все равно у каждого участка своя совокупность данных о ГСМ, ТС и водителях, так что они не перепутаются. или там интернета нет?
во-вторых, надо бы четко разделить какие данные в какой системе будут вестить, и как системы будут ими обмениваться.


Так Вы все-таки стремитесь к ведению параллельного учета в нескольких системах? Это более сложная задача, чем у Вас сейчас получается... Лучше пока сконцентрироваться на основном потоке информации, ляжет на схему, заработает - можно будет подумать и о расширении.

Распределенная система - требование к диплому, я его менять не могу.  :(
Пока предполагаю разработать основную логику программы, т.е. сам учет ГСМ, а уже после этого внести изменения в логическую модель (ввести префиксы, признаки баз, ограничить редактирования документов из других баз, добавить  статусы документов и элементов справочников (типа выгружен, изменен), возможно ввести какие-то триггеры, фиксирующие изменения и т.д.).
Вообще у меня сложилось впечатление, что на защите саму реализацию распределенности особо не рассматривают.

На предприятии несколько удаленных подразделений. Справочники сотрудников и техники - единые. Одни и те же сотрудники и транспортные средства работают на разных участках.  С документами возможны ситуации, когда сотрудник заправился на одном участке, получил путевой лист, потом поехал на другой участок и сдал путевой лист там. Я предполагаю, что информация в базах должна быть практически зеркальная.
На участках периодически нет интернета, при этом должна сохраняться возможность выписки документов и получения отчетов, хотя бы и с не совсем актуальными данными. В центральный офис документы должны приходить или когда появиться интернет, или когда какой-нибудь сотрудник привезёт файл обмена, т.е. должна быть предусмотрена возможность офф-лайн репликации.

Справочники сотрудников, подразделений и номенклатуры ведутся в 1С и выгружаются в разрабатываемую ИС. В системе эти справочники не редактируются. Вот что я не очень хорошо представляю, так это как движения ГСМ будут выгружаться в 1С. Там получится дублирование информации по поступлению, т.е. ГСМ приходуется 2 раза - в бухгалтерии и в разрабатываемой ИС. Надо предусмотреть какой-то механизм сверки.

Ну и дальше как Вы ответите на этот вопрос (сколько осталось)?

Предполагалось, что в таблице «ГСМ в баках» хранится остаток ГСМ в баке транспортного средства на первое число месяца. Нужно к нему прибавить/отнять движение ГСМ по транспортному средству и получится количество на текущую дату.

Выделите места, где у Вас могут находиться ГСМ (нарисуйте их). Определить (выпишите) действия, которые могут происходить с ГСМ (это будут  Ваши стрелочки перемещений). Зафиксируйте состояния, в которых могут находиться ГСМ, и какие документы каждому переходу или состоянию соответствуют.
Проиграйте ситуацию от "на склад поступила тонна горючего", до "все горючее израсходовано и списано". Нарисуйте это на схеме пусть даже без моделирования (на UML).
Потом задайте вопрос: какие данные нужны на каждом этапе? Нарисуйте сущности (справочники пока можно не рисовать, только отмечайте? что нужно будет поместить в справочники) и опираясь на движение ГСМ (в соответствии со схемой) сопоставьте сущности с ним (когда и какие данные будут куда попадать)
Если сделаете последовательно и аккуратно, то найдете большинство ответов на безответные вопросы. А потом возьметесь за справочники.

Вадим, спасибо Вам большое за советы!
Нарисовала. Позже постараюсь описать предметную область и что получилось.

Вот только у меня возник вопрос, на котором застряла. Чтобы узнать количество топлива по транспортному средству, нужно обратиться к Таблице остатков. Насколько я понимаю, таблицы остатков и движений – это уже реализация. Или они тоже могут быть представлены на диаграмме классов?  ??? Честно говоря, оставила бы их, но тогда связей получается слишком много.
Да, опять «трудности с позиционирование диаграммы классов».  :'(



Re: ИС Учета ГСМ. Use case и другие Ответ #47 : 25 Мая 2010, 23:07:26
Уважаемые эксперты!

Подскажите, пожалуйста, какие ещё диаграммы целесообразно сделать для описания системы?

Пока есть мысль, что необходимо сделать диаграмму состояний для абстрактного документа (или конкретного, Путевой лист, например).
Думаю, необходимо осветить следующие аспекты:
1. Документ может быть "Проведён", "Непроведён" - что-то подобное хочется.
2. Выгрузка в 1С: "был выгружен и не может редактироваться", "нужно выгрузить", "не нужно выгружать"...
3. Репликация: ушёл - не ушёл, был ли вообще выгружен, "Был изменен, а значит нужно выгрузить", пришло ли подтверждение загрузки.
Кроме того: доступно ли редактирование (закрыт период, документ из базы другого подразделения), помечен на удаление.
Конкретно документ "Путевой лист" ещё может быть "Рассчитан" и "Не рассчитан".
Честно говоря, довольно смутная картина представляется. Надо мне эти моменты продумать.

Нужна ли такая диаграмма состояний?

Сделала диаграммы деятельности для некоторых прецедентов и диаграмму развертывания.
Честно говоря, ДД меня печалят.  ::) Они такие и должны быть или я их неправильно понимаю?



Re: ИС Учета ГСМ. Use case и другие Ответ #48 : 25 Мая 2010, 23:27:30
Уважаемые эксперты!
Подскажите, пожалуйста, какие ещё диаграммы целесообразно сделать для описания системы?
Любые, которые помогут Вам передать то, что Вы собственно хотите передать. Поймите в реальной практике Вы все-таки будете иметь разделение труда, а следовательно возникнет задача коммуникации. В Вашем случае это может быть задача повторного использования.

Цитировать
Пока есть мысль, что необходимо сделать диаграмму состояний для абстрактного документа (или конкретного, Путевой лист, например).
Думаю, необходимо осветить следующие аспекты:
1. Документ может быть "Проведён", "Непроведён" - что-то подобное хочется.
2. Выгрузка в 1С: "был выгружен и не может редактироваться", "нужно выгрузить", "не нужно выгружать"...
3. Репликация: ушёл - не ушёл, был ли вообще выгружен, "Был изменен, а значит нужно выгрузить", пришло ли подтверждение загрузки.
Кроме того: доступно ли редактирование (закрыт период, документ из базы другого подразделения), помечен на удаление.
Конкретно документ "Путевой лист" ещё может быть "Рассчитан" и "Не рассчитан".
Честно говоря, довольно смутная картина представляется. Надо мне эти моменты продумать.

Нужна ли такая диаграмма состояний?
Это разумно, скорее диаграмму ЖЦ документа :)

Цитировать
Сделала диаграммы деятельности для некоторых прецедентов и диаграмму развертывания.
Честно говоря, ДД меня печалят.  ::) Они такие и должны быть или я их неправильно понимаю?
Вопрос, следует делать ДД для простого ВИ, обычно ее делают для сложного ВИ или для отображения взаимодействия частей программы, объектов, других ВИ между собой. Если ДД элементарно, то какой в ней смысл, с другой стороны она может быть наглядна.

Подумайте ДД - это сеть Петри с одной стороны, а  с другой ОО-блок-схема. Наверняка ДД будет более актуальная например на стадии описания алгоритмов. Или если вы черный ящик ИС таки попробуете вскрыть



Re: ИС Учета ГСМ. Use case и другие Ответ #49 : 26 Мая 2010, 00:06:55
Любые, которые помогут Вам передать то, что Вы собственно хотите передать. Поймите в реальной практике Вы все-таки будете иметь разделение труда, а следовательно возникнет задача коммуникации. В Вашем случае это может быть задача повторного использования.
Да-да, как раз думала про задачу коммуникации.
Помню я читала то ли статью, то ли какой-то отзыв где автор рассказывал, как они с коллегами разрабатывают программные продукты. У них один кодер в Киеве, другой в Москве, дизайнер интерфейсов и проектировщик ещё где-то.
В общем смысл был тот, что если бы не UML, то они никогда не поняли бы друг друга и не собрали бы в кучу отдельные (и подходящие друг другу!) куски кода.
Тогда я первый раз подумала о "реальной" нужности UML, а не о том, чтобы строить модели ради моделей.  ;)

Ну что же, попробую думать с той стороны, что кодер по моим диаграммам должен хорошо представить себе задачу.
Хм, легко сказать, попробую...  :(

Это разумно, скорее диаграмму ЖЦ документа :)
Пойду почитаю про ЖЦ документа.

Вопрос, следует делать ДД для простого ВИ, обычно ее делают для сложного ВИ или для отображения взаимодействия частей программы, объектов, других ВИ между собой. Если ДД элементарно, то какой в ней смысл, с другой стороны она может быть наглядна.

Подумайте ДД - это сеть Петри с одной стороны, а  с другой ОО-блок-схема. Наверняка ДД будет более актуальная например на стадии описания алгоритмов. Или если вы черный ящик ИС таки попробуете вскрыть
Да, в моих ДД всё слишком элементарно.

Вообще-то у меня была мысль, что в ДД можно отразить процесс выдачи и обработки путевого листа. Т.е. что-то типа такого:
1. Диспетчер заполняет некоторые реквизиты путевого листа.
2. Диспетчер отдаёт путевой лист Водителю.
3. Водитель расписывается в журнале выдачи путевых листов.
4. Мед. работник осматривает Водителя и ставит в путевом листе штамп о прохождении медосмотра.
5. Водитель ездит-ездит и заполняет маршрут, показания спидометра...
6. ...
7. Водитель возвращает путевой лист диспетчеру.
8. Диспетчер вводит в Систему незаполненные реквизиты путевого листа.
9. Система рассчитывает нормы расхода топлива...
10. ...
В общем, чтобы было бы наглядно видно сам процесс. Но преподаватель мне сказал, что это не правильно, так как Водитель, например, не является частью ИС, да и вообще действий типа "Диспетчер выдаёт путевой лист водителю" на ДД
быть не должно. Ну не должно, так не должно. Только вот у меня всё равно какие-то сомнения остались.

Эдуард, на Ваш взгляд, допустимо ли таким образом использовать ДД, вроде как для описания процессов предметной области?



Re: ИС Учета ГСМ. Use case и другие Ответ #50 : 26 Мая 2010, 10:41:11
Эдуард, на Ваш взгляд, допустимо ли таким образом использовать ДД, вроде как для описания процессов предметной области?

Позволю себе ответить цитатой из книги Арлоу и Нейштадт. UML 2 и Унифицированный процесс, 2-е издание

Цитировать
Из собственного опыта можем сказать, что диаграммы деятельности чаще всего используются в следующих случаях.

• В процессе анализа:
  • для графического моделирования потока прецедента. Такое представление является более понятным для заинтересованных сторон;
  • для моделирования потока между прецедентами. При этом используется особая форма диаграммы деятельности – диаграмма обзора взаимодействий (раздел 15.12).

• При проектировании:
  • для моделирования деталей операции;
  • для моделирования деталей алгоритма.

• При моделировании деловой активности:
  • для моделирования бизнеспроцесса.

Обычно заказчикам проще понимать диаграммы деятельности, поскольку большинство из них имеет представление о блоксхемах в той или иной форме. Следовательно, диаграммы деятельности могут быть замечательным средством общения, если они просты.




Re: ИС Учета ГСМ. Use case и другие Ответ #51 : 30 Мая 2010, 13:44:13
Прошу прощения за некоторую задержку с ответом - не было возможности и времени почитать форум

Цитата: Водолей
проще сделать централизованное решение

Цитата: Лопушок
Распределенная система - требование к диплому, я его менять не могу.  :(

Одно другому не мешает, Вы же не имеете в виду децентрализованное решение, когда каждый компонент или группа компонентов полностью самостоятельны. Централизованное решение - это когда все данные, например, хранятся в центральной базе. Типичный пример, этот сайт. С другой стороны, централизованное решение может быть распределенным в некоторой части, т.е. иметь несамостоятельные (являющиеся частью общего) куски приложения. Собственно, это как раз Ваш случай. Только Вам еще нужно перед защитой хорошо разобраться, какая часть решения входит в "центр", а какая "является распределенной". Скорее всего Вам такой или подобный вопрос зададут, поэтому надо держать в голове (или записать на бумажке - пояснительной записке) принципы, определяющие централизованное и распределенное решения.

Цитировать
На предприятии несколько удаленных подразделений. Справочники сотрудников и техники - единые. Одни и те же сотрудники и транспортные средства работают на разных участках.  С документами возможны ситуации, когда сотрудник заправился на одном участке, получил путевой лист, потом поехал на другой участок и сдал путевой лист там. Я предполагаю, что информация в базах должна быть практически зеркальная.
На участках периодически нет интернета, при этом должна сохраняться возможность выписки документов и получения отчетов, хотя бы и с не совсем актуальными данными. В центральный офис документы должны приходить или когда появиться интернет, или когда какой-нибудь сотрудник привезёт файл обмена, т.е. должна быть предусмотрена возможность офф-лайн репликации.

Ну вот, Вы же сами описываете свою систему как централизованную: единые справочники, движение информации в территориальном смысле, документы должны приходить в центральный офис и т.п.
Простейший способ - иметь одну центральную базу и ее образы (зеркала) на участках, такой механизм поддерживается основными производителями СУБД. Однако, у Вас одновременно и участков много (соответственно, их оснащение соответствующим оборудованием и ПО может представлять собой отдельную проблему), и интернет на них дохлый (что является уже другой проблемой). Разумным способом является регламентировать и сократить обмен информацией - слать только ту, что нужно. Например, обновление справочников слать ежемесячно или еженедельно, а данные о движении ГСМ - ежедневно.
Как вариант, подумайте над тем, чтобы не полностью зеркалить базы между участками, а только в той части, которая нужна для выполнения отдельных операций, например, первичная выписка документов.

Цитировать
Справочники сотрудников, подразделений и номенклатуры ведутся в 1С и выгружаются в разрабатываемую ИС. В системе эти справочники не редактируются. Вот что я не очень хорошо представляю, так это как движения ГСМ будут выгружаться в 1С. Там получится дублирование информации по поступлению, т.е. ГСМ приходуется 2 раза - в бухгалтерии и в разрабатываемой ИС. Надо предусмотреть какой-то механизм сверки.

Непонятно, почему Вы делаете такой вывод (о дублировании, о сверке и т.п.)? Вам нужно четко представлять движение информации (судя по всему пока этого нет): где, какая информация появляется, где вводится, куда направляется и для каждого подобного информационного объекта нарисовать внятную диаграмму (или хотя бы отсебятинскую картинку), которая детально показывает особенности этого движения.
Ведь в конечном счете Ваша задача собрать в 1С всю информацию о движении ГСМ, поступившую из разных источников. Это же не значит, что Вы всегда должны гонять по системе полные данные. Если водитель поехал из точки А в точку Б и там закрывает путевой лист, Вы же не будете ждать закрытый лист из точки А, а используя единую идентификацию ПЛ спокойно найдете его в центральной базе (или ее копии в пункте Б) - главное предусмотреть, что пока водитель едет по своему маршруту, и центральная база и ее копия в пункте Б обновилась. С другой стороны может быть достаточно написать/напечать на путевом листе уникальный номер, сгенеренный системой и тогда операции прихода и расхода ГСМ могут быть введены раздельно, но тогда они должны быть сведены в центре. Вот и получится искомая прозрачность. В общем, надо подробнее смотреть на операции - будучи детальнее знаком с постановкой, я бы, наверное, мог бы предложить ряд технических решений, но думаю, что это и Вам по силу. Более того, это как раз и есть Ваша задача - не только показать "ЧТО Вы знаете", но и "КАК Вы умеете эти знания использовать".

Цитировать
Предполагалось, что в таблице «ГСМ в баках» хранится остаток ГСМ в баке транспортного средства на первое число месяца. Нужно к нему прибавить/отнять движение ГСМ по транспортному средству и получится количество на текущую дату.

Технически может быть проще несколько денормализовать данные об остатке ГСМ и сохранять не каждую операцию независимо друг от друга, а на каждую операцию хранить входящий остаток, изменение и исходящий остаток. Причем, т.к. операции могут быть приходные и расходные, то можно было бы хранить их в одной записи, но в разных колонках (пусть иногда и с нулевыми значениями). Я так однажды делал, это мне сильно упростило подготовку отчетов о движении объекта учета.

Цитировать
Чтобы узнать количество топлива по транспортному средству, нужно обратиться к Таблице остатков. Насколько я понимаю, таблицы остатков и движений – это уже реализация. 

и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.
Лью воду...



Re: ИС Учета ГСМ. Use case и другие Ответ #52 : 02 Июня 2010, 20:53:35

Позволю себе ответить цитатой из книги Арлоу и Нейштадт. 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, что-то мы их очень невнятно проходили…

С другой стороны может быть достаточно написать/напечать на путевом листе уникальный номер, сгенеренный системой и тогда операции прихода и расхода ГСМ могут быть введены раздельно, но тогда они должны быть сведены в центре. Вот и получится искомая прозрачность. В общем, надо подробнее смотреть на операции - будучи детальнее знаком с постановкой, я бы, наверное, мог бы предложить ряд технических решений, но думаю, что это и Вам по силу. Более того, это как раз и есть Ваша задача - не только показать "ЧТО Вы знаете", но и "КАК Вы умеете эти знания использовать".

Какая интересная идея! :D Действительно, прозрачность...
Однако реализация такого механизма слияния, мне кажется, будет более сложной, чем просто подождать и дозаполнить документ. Однако сама идея!

Технически может быть проще несколько денормализовать данные об остатке ГСМ и сохранять не каждую операцию независимо друг от друга, а на каждую операцию хранить входящий остаток, изменение и исходящий остаток. Причем, т.к. операции могут быть приходные и расходные, то можно было бы хранить их в одной записи, но в разных колонках (пусть иногда и с нулевыми значениями). Я так однажды делал, это мне сильно упростило подготовку отчетов о движении объекта учета.

Про две колонки поняла, тоже думала, в общем-то разницы особой нет.
А вот про независимость операций. Если вдруг пришла какая-то операция по данному транспортному средству, введенная в другой базе два дня назад, то мне нужно будет пересчитать в моей базе входящий и исходящий остатки в операциях за последние 2 дня по этому транспортному средству? На первый взгляд, это сложнее чем просто хранить операции, где указана цифра прихода/расхода, а пересчет остатков идёт в конце месяца при закрытии периода.
Хотя сейчас подумала, что, в общем-то, в путевых листах оно так и хранится. Там конкретные цифры прихода, расхода, изменения, а также экономия/перерасход. Друг от друга путевые листы не зависят, хотя связаны с заправочными ведомостями (из них берется приход).
Возможно, когда я до этого дойду (если дойду), то в голове уже сложится картина, как это должно выглядеть.

и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.

Понятно, спасибо!
Пока пришла к выводу, что таблицы остатков и движений на диаграмме классов опущу, так как для задачи они не принципиальны. В общем-то остатки и движения для отчетов можно и по документам собирать. Чувствую, что так и будет :( .
Что касается особенностей реализации, возможно на диаграмме классов стоит отразить будущую распределенность базы. Поэтому рассмотрю возможность добавления справочника информационных баз и атрибутов принадлежности документов к базам.



Re: ИС Учета ГСМ. Use case и другие Ответ #53 : 04 Июня 2010, 18:56:49
опять извиняюсь за задержку с ответом - не было возможности ответить раньше

Цитата: Лопушок
Одна центральная база и зеркала это однако немножко не то (ИМХО), так как при таком варианте данные меняются в центре, а участки выступают получателями, но ничего не передают центру. Такая схема может быть реализована в том же Microsoft SQLServer'е. В моём же случае требуется двусторонний обмен, да ещё и желательно с офф-лайн репликацией, чтобы можно было файл выгрузки на дискете привезти или по электронной почте отправить.
Насколько я поняла, тот же MS SQLServer такого уже не поддерживает. Офф-лайн репликацию поддерживает, например, Sybase ASA и какой-то из очень дорогих вариантов Oracle. В моём дипломе предлагается бюджетный вариант реализации ИС на базе СУБД Firebird + IBReplicator от IBPhoenix. Хотя, честно говоря, сейчас сразу смотрела бы в сторону Sybase ASA.
В пользу зеркальных баз вижу следующие доводы:
- Справочники для выписки документов нужны все. В задаче ставится, чтобы водитель мог получить историю своего подотчета по ГСМ у диспетчера на любом участке. Поэтому документы тоже нужны практически все. Да в общем-то их не так уж и много, у меня в логической модели данных около 30 сущностей получается, штук 10 справочников, и 4-5 видов документов.
- Кроме того, на мой взгляд, репликацию зеркальных баз проще настраивать, да и в случае обвала какой-то из баз большая часть информации останется.
Довод в пользу не зеркальных  баз – уменьшение трафика. Но Интернет там не то чтобы дохлый, скорее возможны перебои. Т.е. когда интернет есть, то скорость обычно нормальная.

Вот и сделайте в своей пояснительной записке сравнение этих вариантов архитектур. Основы ведь Вы, в принципе, понимаете. А конкретика - почему такое-то решение в данном случае будет предпочтительнее? - это Ваше решение.

Кстати, поправка: с точки зрения использования нескольких реплицируемых баз, когда базы реплицируются один к одному, то каждая их них в момент работы с нею является "как бы" единственной и полной (как будто других нет). Поэтому использование репликации для пользователя прозрачно - ее вроде бы и не видно, да и выполняется она в нерабочее время. Останется вопрос в увеличивающемся объеме базы, но IMHO это не Ваш случай. Думаю, что основная проблема скорее в том, что у Вас МНОГО точек, где должна быть копия базы. Но сама система централизованная. Если Вы нарисуете архитектурную схему системы, показав на ней пользовательские модули и сами базы, которые соединены стрелочками репликации, а потом обведете все базы рамочкой, то Вам это должно броситься в глаза.

Цитировать
Другое дело, что из 1С справочники можно выгружать не полностью. Например, справочник «Номенклатура», где нужны-то только разные бензин и дизтопливо. Здесь да, надо предусмотреть какую-то форму выгрузки, чтобы бухгалтер ставил галочки и выгружал выбранные элементы или группу, а не все 150 видов гвоздей и бруса, только потому, что у них поменялась одна буква в наименовании или их перенесли в другую группу.
Ой, только сейчас поняла, что мне придётся ещё и в 1С как-то отслеживать изменение справочников с последней выгрузки. Ужас-то какой  :(.
В общем-то получается, что проблемы основные не столько с основной функциональностью системы, сколько с необходимостью взаимодействия с 1С и распределенностью.

Поправка формулировки: помимо проблем с функциональностью системы, существуют проблемы  с построением архитектуры системы, в частности при взаимодействии с 1С.
Но это нестрашно, Вы ведь для того и работаете/учитесь, чтобы [научиться] решать такого рода проблемы.

И потом у Вас по определению две базы: 1С и системы учета. "Тупо" выгружайте из 1С то, что поменялось, разделив предварительно на области видимости (ГСМ - не ГСМ), и не думайте выгружалось оно раньше или нет, нужно только чтобы оно легло на то же место с тем же кодом (чтобы дублей не было) - и всё!

Цитировать
О дублировании информации и сверке.
Допустим, наша организация решила закупить ГСМ и оплатила счет компании-поставщика.
Поставщик отгружает ГСМ, но не нам, а организации, с которой у нас заключен договор ответственного хранения (на каждом участке разные организации).
Затем с участка на склад организации хранящей ГСМ едет водитель бензовоза с доверенностью на получение ГСМ, где и заливает Дизтопливо в бензовоз. Там он получает расходную накладную, выписанную организацией-посредником, на основании которой в диспетчерской системе приходуется топливо (там указано только количество). Таких расходных накладных несколько на один оплаченный счет.
Поступление ГСМ по бухгалтерии оформляется в 1С документом «Поступление материалов» на основании счета-фактуры и расходной накладной выписанных организацией-поставщиком (там указаны и количество и сумма). Такие счет-фактура и расходная накладная по одному на один оплаченный счет.
Таким образом, пока у меня получается, что одно и то же поступление ГСМ учитывается 2 раза – в диспетчерской системе и в 1С. Причем количество поступивших ГСМ в документах и количество самих документов не совпадают. Тут необходима сверка.

Уж не знаю почему возникла такая схема, но не избавившись от нее, будет трудно поставить реальный учет - много сил будет уходить именно на сверку. С точки зрения бизнеса это должно сильно мешать. Возможно она (такая схема) как раз возникла из-за того, что невовремя приходили ПЛ, а сроки оплаты по счетам истекали, или может кому-то было лень разбираться с путевками. Кто знает???
Зачем Вам нужен двойной учет? Заводите в систему факты хозяйственной деятельности и будет Вам счастье и не будет нужна никакая сверка, кроме сравнения физических объемов ГСМ в бензобаке и написанного на бумаге - даже в формуле 1 такое делают :о))
Вы же ставите задачей ускорить доставку информации, вот и решайте ее, а полученное решение позволит устранить "перегибы на местах" и уменьшить дополнительную работу.

Цитировать
Получится такая схема документооборота. Наверное, надо почитать про DFD, что-то мы их очень невнятно проходили…

Вся система реализует некую специализированную схему документооборота. Не грузитесь пока синтаксисом DFD (тем более Вы ведь на UML вроде собирались моделировать, зачем Вам смешанное моделирование из разных методологий?), нарисуйте в понятных картинках. А когда разберетесь с суть задачи, найдете время нарисовать в виде семантически правильных моделей выбранной методологии.

Цитировать
Возможно, когда я до этого дойду (если дойду), то в голове уже сложится картина, как это должно выглядеть.


Ну вот Вы уже пытаетесь ставить вопросы к своей системе - продолжайте в том же духе, только разделите их на бизнес-уровень (про документы и их заполнение/движение) и на уровень реализации (классы/объекты/данные/процедуры). Что будет, если произойдет то-то событие или какое-то другое - как это должно будет отразиться в системе (с помощью системы).

Цитировать
Пока пришла к выводу, что таблицы остатков и движений на диаграмме классов опущу, так как для задачи они не принципиальны. В общем-то остатки и движения для отчетов можно и по документам собирать. Чувствую, что так и будет :( .

Ваша ответственность - Ваше и решение. Или наоборот :о)))

Цитировать
Что касается особенностей реализации, возможно на диаграмме классов стоит отразить будущую распределенность базы. Поэтому рассмотрю возможность добавления справочника информационных баз и атрибутов принадлежности документов к базам.

Если во всех местах, где он используется, класс остается неизменным - то "отражать распределенность" не надо. Подумайте лучше над тем, "где экземпляр появляется", "куда и как он перемещается", соответственно, где будут его копии. И нарисуйте это на территориально распределенной схеме. Вот тут и проявится Ваша распределенная архитектура.


Лью воду...



Re: ИС Учета ГСМ. Use case и другие Ответ #54 : 05 Июня 2010, 07:09:19
опять извиняюсь за задержку с ответом - не было возможности ответить раньше

Вот и сделайте в своей пояснительной записке сравнение этих вариантов архитектур. Основы ведь Вы, в принципе, понимаете. А конкретика - почему такое-то решение в данном случае будет предпочтительнее? - это Ваше решение.

Хмм… А ведь действительно, надо бы сравнить. А то у меня как одним-двумя предложением упоминается, что связь нестабильная, нужна офф-лайн репликация, а также максимальная нетребовательность к администрированию вследствие территориальной удаленности производственных участков. Дальше идет сравнение и выбор СУБД исходя из этих требований… а развернутого обоснования самих критериев выбора СУБД как такового и нет.

Поправка формулировки: помимо проблем с функциональностью системы, существуют проблемы  с построением архитектуры системы, в частности при взаимодействии с 1С.

Спасибо за эту поправку! Совсем по-другому звучит!

И потом у Вас по определению две базы: 1С и системы учета. "Тупо" выгружайте из 1С то, что поменялось, разделив предварительно на области видимости (ГСМ - не ГСМ), и не думайте выгружалось оно раньше или нет, нужно только чтобы оно легло на то же место с тем же кодом (чтобы дублей не было) - и всё!

Ну я именно так и собираюсь делать. Просто при этом ведь всё равно надо отслеживать что поменялось, т.е. вести какие-то логи изменений (вообще-то в 1С вроде какой-то журнал был, может быть можно его приспособить). Кроме того, должна быть какая-то обратная связь, что выгрузка измененных элементов в диспетчерскую систему произошла успешно и не надо их больше выгружать. Так будет больше шансов «не потерять» изменения.

Уж не знаю почему возникла такая схема, но не избавившись от нее, будет трудно поставить реальный учет - много сил будет уходить именно на сверку. С точки зрения бизнеса это должно сильно мешать. Возможно она (такая схема) как раз возникла из-за того, что невовремя приходили ПЛ, а сроки оплаты по счетам истекали, или может кому-то было лень разбираться с путевками. Кто знает???
Зачем Вам нужен двойной учет? Заводите в систему факты хозяйственной деятельности и будет Вам счастье и не будет нужна никакая сверка, кроме сравнения физических объемов ГСМ в бензобаке и написанного на бумаге - даже в формуле 1 такое делают :о))
Вы же ставите задачей ускорить доставку информации, вот и решайте ее, а полученное решение позволит устранить "перегибы на местах" и уменьшить дополнительную работу.

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

На мой взгляд, никакого ужаса там нет. Ужас у нас в складском учете, который дублируется ПОЛНОСТЬЮ. Сложилось так, что на предприятии существует 2 параллельные системы (обе на 1С) – одна для кладовщика, вторая – 1С бухгалтерия,  куда бухгалтер забивает оформленные кладовщиком в складской системе документы. Вот там настоящий ужас.

Вся система реализует некую специализированную схему документооборота. Не грузитесь пока синтаксисом DFD (тем более Вы ведь на UML вроде собирались моделировать, зачем Вам смешанное моделирование из разных методологий?), нарисуйте в понятных картинках. А когда разберетесь с суть задачи, найдете время нарисовать в виде семантически правильных моделей выбранной методологии.
 

Хорошо. Ведь зачастую чем проще, тем понятней.

Ну вот Вы уже пытаетесь ставить вопросы к своей системе - продолжайте в том же духе, только разделите их на бизнес-уровень (про документы и их заполнение/движение) и на уровень реализации (классы/объекты/данные/процедуры). Что будет, если произойдет то-то событие или какое-то другое - как это должно будет отразиться в системе (с помощью системы).

Хмм. В этом месте никаких вопросов не вижу, честно говоря.  Но разделить уровни попытаюсь. А то у меня всё в кучу – и реализация и проектирование и бизнес-логика.  Вот и получается много и запутано.

Ваша  ответственность - Ваше и решение. Или наоборот :о)))

Скорее наоборот :). Хорошо, что задача учебная.

 
Если во всех местах, где он используется, класс остается неизменным - то "отражать распределенность" не надо. Подумайте лучше над тем, "где экземпляр появляется", "куда и как он перемещается", соответственно, где будут его копии. И нарисуйте это на территориально распределенной схеме. Вот тут и проявится Ваша распределенная архитектура.
 

Хорошо. Попробую.



Re: ИС Учета ГСМ. Use case и другие Ответ #55 : 05 Июня 2010, 14:49:02
по Вашим ответам я пока не вижу, чем еще можно Вам помочь. Так что творите-пробуйте, должно же хоть что-то получиться :о))) А потом поделитесь опытом, и будем обсуждать его.
Лью воду...



Re: ИС Учета ГСМ. Use case и другие Ответ #56 : 16 Июня 2010, 21:32:00
Защитила я свой диплом всё-таки. Хотя очень тяжело он мне дался.
Несмотря на его позорность, даже "отлично" поставили.
Огромное пасибо за помощь!  :D



Re: ИС Учета ГСМ. Use case и другие Ответ #57 : 17 Июня 2010, 16:35:38
Ну что ж, поздравляем! (подставляет стакан)

Поделитесь подробностями, что было тяжело, в чем позорность и т.п.
Лью воду...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19