Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: Лопушок от 09 Мая 2010, 19:53:06
-
Здравствуйте, уважаемые эксперты!
Прошу помощи в построении диаграмм на UML для системы учета ГСМ.
В общем-то простая учетная система: ведение справочников транспортных средств, водителей, номенклатуры и других, а также оформление ряда документов - путевых листов, заправочных ведомостей, ввод начальных остатков, перемещение ГСМ, заправка от поставщика.
Система распределенная, кроме того, должна быть связь с 1С (импорт-экспорт) и экспорт документво и отчетов в формат MS Excel.
Для начала пыталась построить диаграмму вариантов использования. Понимаю, что очень корявая, но уже всю голову сломала. ???
Покритикуйте, пожалуйста, а может и какие предложения возникнут? ::)
-
Для начала попробуйте написать текст основного успешного сценария для UC "Вести учет движения ГСМ" ... посмотрите что при этом получиться. Понравиться ли он вам? Второй момент - у Диспетчера действительно нет никакой возможности редактировать после ввода ни один из документов, ввод которых отмечен included USs? Учет движения ГСМ заключается только в импорте справочников и ввода документов?
-
А в чём ваша цель заключается?
Сдать экзамен?
Попудрить мозги начальству?
Найти новый смысл в скучной для себя работе?
Спроектировать робастную систему?
Обеспечить реализацию интересов заказчика?
-
Для начала попробуйте написать текст основного успешного сценария для UC "Вести учет движения ГСМ" ... посмотрите что при этом получиться. Понравиться ли он вам?
Да, сейчас конечно попробую. Однако у меня ощущение, что слишком это слишком большой кусок. Наверное его всё-таки надо разбить.
-Вообще-то я его уже разбивала так:
1) просто на ввод отдельных документов:
- ввод путевого листа;
- ввод заправочной ведомости;
и т.д.
2) и пыталась обобщить:
- учет поступления ГСМ (--> Ввод начальных остатков, --> Заправка ГСМ от поставщика)
- учет перемещения ГСМ (--> Перемещение ГСМ, --> Заправочная ведомость)
- учет списания ГСМ (--> Путевой лист)
Потом решила не разбивать и сделала опять один вариант действия.
Второй момент - у Диспетчера действительно нет никакой возможности редактировать после ввода ни один из документов, ввод которых отмечен included USs? Учет движения ГСМ заключается только в импорте справочников и ввода документов?
Это я некорректно написала, редактировать конечно может, по крайней мере пока период не закрыт и документы (или итоги по ним) не ушли в 1С. Просто не могу сформулировать одним словом. Неужели разные UC разводить и на ввод, и на редактирование, и чтобы на удаление пометить?
В некоторые справочники диспетчер может вводить новые элементы, а также их редактировать.
А в чём ваша цель заключается?
Дипломный проект
-
Для начала попробуйте написать текст основного успешного сценария для UC "Вести учет движения ГСМ" ... посмотрите что при этом получиться. Понравиться ли он вам?
ВИ: Вести учет движения ГСМ
ID: 1
Краткое описание:
Диспетчер документально отражает движение ГСМ
Основные действующие лица:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию «Создать новый документ» или «Редактировать документ» или «Пометить документ»
2. Если Диспетчер выбирает опцию «Создать документ», то
2.1. Система открывает форму создания нового документа
2.2. Диспетчер заполняет реквизиты документа.
2.3. Система проверяет корректность введенных данных.
2.4. Диспетчер выбирает опцию «Записать».
2.5. Система сохраняет документ в БД.
2.6. Диспетчер выбирает опцию «Провести».
2.7. Система отражает движение ГСМ в таблицах движения ГСМ.
2.8. Диспетчер выбирает опцию «Закрыть».
2.9. Система закрывает форму документа.
3. Если Диспетчер выбирает опцию «Редактировать документ», то
3.1. Система открывает форму документа
3.2. Диспетчер редактирует реквизиты документа.
3.3. Система проверяет корректность введенных данных.
3.4. Диспетчер выбирает опцию «Записать».
3.5. Система сохраняет документ в БД.
3.6. Диспетчер выбирает опцию «Провести».
3.7. Система отражает движение ГСМ в таблицах движения ГСМ.
3.8. Диспетчер выбирает опцию «Закрыть».
3.9. Система закрывает форму документа.
4. Если Диспетчер выбирает опцию «Пометить документ на удаление», то
4.1. Система помечает документ на удаление.
4.2. Система удаляет движение ГСМ в таблицах движения ГСМ.
Постусловия:
Нет (Хотя, вероятно, должны быть, причем для разных "Если" свои?)
Альтернативные потоки:
Нет.
В реальном приложении кроме кнопок "Записать", "Провести", "Закрыть" будет также кнопка "ОК", которая сразу выполняет все эти три действия.
Смущает меня в этом сценарии то, что:
1. Документы могут быть разными, а в сценарии у меня какой-то абстрактный документ.
2. Наличие многих "Если". Как-то хотелось бы от них уйти. Причем возможно, что Если здесь использовать неправомерно, а следует использовать, допустим, альтернативные потоки?
Может лучше поделить на несколько ВИ? Тогда как? Каждый документ отдельно?
Или каждый документ и операцию отдельно? Тогда при наличии 6 документов и 4 операций (ввод, редактирование, просмотр, удаление) получится 24 ВИ?
В общем наверное следует поделить ВИ "Учет движения ГСМ" на несколько ВИ, но только не знаю как.
-
А в рамках дипломного проекта уже проведено обследование, сформулированы решаемые проблемы, выдвинуты принципиальные решения, сформирована концепция? Есть контекстная диаграмма системы, словарь ключевых понятий предметной области? Можно с ними ознакомиться?
-
А в рамках дипломного проекта уже проведено обследование, сформулированы решаемые проблемы, выдвинуты принципиальные решения, сформирована концепция? Есть контекстная диаграмма системы, словарь ключевых понятий предметной области? Можно с ними ознакомиться?
Словаря ключевых понятий предметной области нету, у нас не требуют. ::)
Обследование и ТЗ прикрепила в вордовском файле
IDEF0 сделала пока только TO BE.
-
Ещё диаграммы...
-
Да, сейчас конечно попробую. Однако у меня ощущение, что слишком это слишком большой кусок. Наверное его всё-таки надо разбить.
А не случайно Юрий Вам вопрос задал. Он прямо намекал на то, что у Вас должны возникнуть с этим проблемы.
Просто если слегка задуматься, а что такое вести учет движения ГСМ? Учет это что? Функция, деятельность, задача, процесс. Можно ли выразить "ведение учета движения ГСМ" через понятие - СПОСОБ, ВАРИАНТ того, как я использую систему в данный конкретный момент, чтобы ... чтобы что?
Это я некорректно написала, редактировать конечно может, по крайней мере пока период не закрыт и документы (или итоги по ним) не ушли в 1С. Просто не могу сформулировать одним словом. Неужели разные UC разводить и на ввод, и на редактирование, и чтобы на удаление пометить?
Работа по созданию, редактированию, просмотру и удалению может быть описана шаблоном CRUD ВИ +. + означает некоторый дополнительный ВИ типа поиска по критерию.
В некоторые справочники диспетчер может вводить новые элементы, а также их редактировать.
Вообще справочник в данном контексте - это результат реализации. ВИ же описываются на уровне хотения, т.е. или AS IS -
это описание ВИ в стиле прозрачного ящика, или TO BE - описание ВИ в стиле черного.
Смущает меня в этом сценарии то, что:
1. Документы могут быть разными, а в сценарии у меня какой-то абстрактный документ.
2. Наличие многих "Если". Как-то хотелось бы от них уйти. Причем возможно, что Если здесь использовать неправомерно, а следует использовать, допустим, альтернативные потоки?
Рекомендации по написанию спецификаций вариантов использования (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=51)
Как моделировать альтернативные потоки?
(http://www.uml2.ru/index.php?option=com_content&task=view&id=418&Itemid=51)
Тогда при наличии 6 документов и 4 операций (ввод, редактирование, просмотр, удаление) получится 24 ВИ?
Всего-то, а почему Вас это пугает?
В общем наверное следует поделить ВИ "Учет движения ГСМ" на несколько ВИ, но только не знаю как.
То что ВИ "Учет движения ГСМ", это не ВИ, я надеюсь Вы поняли. Теперь дело за малым, выделить эти самые ВИ :)
Немного по диаграммам.
1. На контекстной диаграмме не указаны цель построения диаграммы и точка зрения - грубейшее нарушение SADT подхода.
2. Не понимаю как Приказ (нормативный или распорядительный документ) является у Вас входом? Это же чистое управление
3. на диаграммах очень мало обратных связей - единственный вид обратный выход - вход. Устойчивые системы, системы с обратными связями выход управление
4. В IDEF0 допускается отсутствие входа, но отсутствие управления карается оставлением без сладкого!
-
А не случайно Юрий Вам вопрос задал. Он прямо намекал на то, что у Вас должны возникнуть с этим проблемы.
Я, честно говоря, сразу подумала, что он хочет так "мягко подвести"...
Работа по созданию, редактированию, просмотру и удалению может быть описана шаблоном CRUD ВИ +. + означает некоторый дополнительный ВИ типа поиска по критерию.
Честно искала по форуму, но не нашла. Так и писать "CRUD+ документа "Путевой лист"?
Скачала "Use Cases Patterns and Blueprints" By Gunnar Övergaard, Karin Palmkvist. Пытаюсь изучать. Ещё думаю может написать какой-нибудь "синоним", типа "Оформление документа "Путевой лист", чтобы не смущать преподавателей?
Рекомендации по написанию спецификаций вариантов использования (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=51)
Как моделировать альтернативные потоки?
(http://www.uml2.ru/index.php?option=com_content&task=view&id=418&Itemid=51)
Угу, первую Вашу статью я уже читала, по ней и старалась делать описание.
Просто у нас требуют описывать ВИ в виде диаграммы действия, а не текстуально. Т.е. типа каждый ВИ - своя диаграмма действия. Сейчас попробую описать свои ВИ.
Всего-то, а почему Вас это пугает?
Вроде как диаграмма должна быть понятна и неспециалисту. Мне кажется, что диаграмма со множеством непонятных кружков мелким шрифтом должна не то что пугать, но казаться сложной и непонятной.
В общем-то дело даже не в количестве, а в росте этого количества с увеличением числа документов, ну и гибкость - неудобно 4 ВИ добавлять-убирать, если нужно добавить-убрать один документ. Хотя описывать такие ВИ в виде диаграмм действий гораздо удобнее.
То что ВИ "Учет движения ГСМ", это не ВИ, я надеюсь Вы поняли. Теперь дело за малым, выделить эти самые ВИ :)
Угу, пойду пока по самому простому пути, сделаю ВИ в виде документов, просто больше ничего в голову не приходит.
Немного по диаграммам.
1. На контекстной диаграмме не указаны цель построения диаграммы и точка зрения - грубейшее нарушение SADT подхода.
2. Не понимаю как Приказ (нормативный или распорядительный документ) является у Вас входом? Это же чистое управление
3. на диаграммах очень мало обратных связей - единственный вид обратный выход - вход. Устойчивые системы, системы с обратными связями выход управление
4. В IDEF0 допускается отсутствие входа, но отсутствие управления карается оставлением без сладкого!
Хорошо, спасибо!
Сейчас буду исправлять.
В приказе об установлении норм расхода топлива содержатся нормы расхода топлива для каждой модели транспортного средства, которые просто забиваются в справочник "Модели транспортных средств". Если я переформулируют этот поток как "Нормы расхода топлива", то это будет корректный входной поток?
-
IMHO, двигаясь от ввода отдельных документов, Вы будете очень долго ...э... двигаться к тому, что Вам нужно.
Я понимаю, что это задача для Вас новая, но Вы же должны не просто "двигаться", а решать выявленные проблемы, с учетом их приоритетов.
Какие у Вас проблемы выявлены? Какая - главная? На каких этапах работы с ГСМ они потенциально возникают?
Думаю, что Вам нужно в целом посмотреть на задачу и определить из каких участков состоит движение ГСМ на предприятии (а ГСМ всегда находятся в движении: откуда-то они берутся, как-то используются, что с ними происходит)
Опишите этот процесс, а потом наложите на него свои документы (для большей простоты можно начать с информационного потока: т.е. как появляется и движется информация о ГСМ) - попробуйте проследить "путь" ГСМ в контексте имеющихся проблем, попытайтесь установить причинно-следственную связь между проблемами и состоянием участков, где они возникают/проявляются...
Пробуйте смотреть на это хозяйство сверху, а не изнутри.
P.S. Кстати, в Вашем ТЗ практически отсутствуют функциональные требования к тому, что должна делать система. Это большое упущение.
-
Какие у Вас проблемы выявлены? Какая - главная? На каких этапах работы с ГСМ они потенциально возникают?
Ох, попробую. Главная проблема в том, что мне нужно написать диплом в условиях катастрофической нехватки времени. Шучу конечно.
Взгляд на проблемы у меня однобокий, со стороны бухгалтерии, потому что общалась я в основном с бухгалтерами. К сожалению, я не вижу проблемы с позиции начальника участка, например или самих водителей.
Итак, Главная Проблема – хищение ГСМ, т.е. водители сливают дизтопливо и продают.
Вторая проблема – первичная документация, на основании которой происходит списание ГСМ, т.е. путевые листы, приходят к бухгалтеру по ГСМ с опозданием и ещё позже отражаются по бухгалтерии.
Третья проблема – путевые листы и заправочные ведомости часто заполняются неправильно, цифры «не идут» и бухгалтер исправляет их, подгоняет. Кроме цифр иногда не понятно, например, какой из водителей Ивановых имелся ввиду.
Четвертая проблема – организация выросла, стало много техники, сотрудников, и, соответственно, путевых листов. Бухгалтер не успевает их обрабатывать.
Пятая проблема – расчет нормативного и фактического расхода топлива по путевым листам проводится в Экселе, а итоги забиваются в 1С. Это не очень удобно и приводит возникновению ошибок.
Все эти проблемы появляются на последнем этапе движения ГСМ, когда дизтопливо было выдано водителям и должно быть списано путевыми листами. Ну или на этапе документального оформления списания ГСМ.
Ещё, возможно, проблемой является нехватка оборотных средств, необходимые счета оплачиваются с большим опозданием. Таким образом, начальникам участков выгоднее завысить расход дизтоплива и занизить остатки, потому что в этом случае руководство раньше «пошевелится», счета оплатят, и вероятность простоя будет ниже. С оборотными средствами решить трудно, однако установление оперативного контроля над расходом дизтоплива, безусловно, поможет.
Из-за наличия данных проблем руководством организации было решено создать диспетчерскую службу, которая бы занималась оперативным контролем за расходом дизтоплива. Т.е. вместо бухгалтера в центральном офисе, к которому путевые листы приходят с опозданием на месяц, да ещё неправильно заполненными, на дорожно-строительном участке будет сидеть диспетчер и отслеживать, кому и зачем даётся дизтопливо. Бухгалтерия, отдел снабжения и коммерческий отдел в центральном офисе при этом оперативно видят, сколько дизтоплива осталось и с какой скоростью оно расходуется, т.е. можно даже попытаться планировать, когда оно закончится.
Разрабатываемая ИС как раз и должна автоматизировать работу диспетчерской службы.
Думаю, что Вам нужно в целом посмотреть на задачу и определить из каких участков состоит движение ГСМ на предприятии (а ГСМ всегда находятся в движении: откуда-то они берутся, как-то используются, что с ними происходит)
Опишите этот процесс, а потом наложите на него свои документы (для большей простоты можно начать с информационного потока: т.е. как появляется и движется информация о ГСМ) - попробуйте проследить "путь" ГСМ в контексте имеющихся проблем, попытайтесь установить причинно-следственную связь между проблемами и состоянием участков, где они возникают/проявляются...
Пробуйте смотреть на это хозяйство сверху, а не изнутри.
О движении ГСМ:
Дизтопливо покупается у поставщика. От поставщика дизтопливо вроде приезжает на наших бензовозах. С бензовозов заливается в машины и строительную технику.
Это основной вариант. Кроме этого есть ещё заправка по пластиковым картам, по талонам, за наличный расчет (это, в основном, легковые машины в офисе).
О документальном оформлении:
Поставщик выставляет счет-фактуру и накладную. По бухгалтерии это проводится документом «Поступление материалов».
Заправка конкретных машин оформляется заправочной ведомостью, где написано, какое топливо, в какую машину, в каком количестве и какому водителю залито. Соответственно, каждый водитель расписывается в получении.
Водителю выдается путевой лист, в нём написано какая машина, какой водитель. Водитель заполняет путевой лист данными о начальном и конечном пробеге, заправках, маршруте. Исходя из этих данных, диспетчер рассчитывает расход топлива по нормам и по факту.
Путевые листы и заправочные ведомости передаются бухгалтеру, который на основании заправочной ведомости списывает ГСМ с заправщика на водителя. На основании путевого листа ГСМ списываются с водителя.
На мой взгляд, слабое место здесь - заправочные ведомости и путевые листы. Видимо потому, что над процессом расхода ГСМ не установлен нормальный контроль, так как бухгалтеру на расстоянии трудно отследить правильность и обязательность заполнения первичной документации.
Сейчас поняла, что совсем плохо представляю сам процесс, расспрошу бухгалтера.
Мда, опять у меня получается старая схема – «Поступление – Перемещение – Расход». :-\
P.S. Кстати, в Вашем ТЗ практически отсутствуют функциональные требования к тому, что должна делать система. Это большое упущение.
Спасибо! Да, действительно, постараюсь исправить.
-
Сделала "диаграмму классов". Вот где ужас-то. :'(
-
А почему вы идёте от документов, а не от объектов реального мира?
Документ - это же просто форма представления информации о каком-то срезе вашей информационной модели реальности.
А в реальности есть факты заправки, есть ёмкости, есть их объёмы, есть расходы.
Документы - это уже понятия от них производные.
На основе учётных данных можно сформировать как отчёты об объекте (у вас = документы), так и о их множестве (аналитические).
А на основе документов вы уже посчитать аналитических отчёт не сможете
-
А почему вы идёте от документов, а не от объектов реального мира?
Документ - это же просто форма представления информации о каком-то срезе вашей информационной модели реальности.
От объектов я начинала идти, а скатилась к документам, видимо потому что для меня это конкретика, а объекты - абстракция.
Сейчас попробую вернуться к объектам, чтобы можно было проследить связи и зависимости.
-
Переделала диаграмму классов. ::)
Хо-хо, мой мозг испорчен 1С-ом.
-
Ну выложу ещё до кучи логическую модель.
Первый рисунок - модель полностью. Так как там ничего не понятно, то остальные рисунки - куски логической модели, разбитые по предметным областям.
-
Продолжение
-
Вернусь к одному из первоначальных вариантов.
Опять диаграмма Use Case.
-
Ох, попробую. Главная проблема в том, что мне нужно написать диплом в условиях катастрофической нехватки времени. Шучу конечно.
Взгляд на проблемы у меня однобокий, со стороны бухгалтерии, потому что общалась я в основном с бухгалтерами. К сожалению, я не вижу проблемы с позиции начальника участка, например или самих водителей.
Вообще судя по проблемам смотреть нужно с точки зрения того, кто тратит на это деньги и не получает нужной выработки при этом.
Итак, Главная Проблема – хищение ГСМ, т.е. водители сливают дизтопливо и продают.
Информационная система, созданная для контроля, гарантировано делу не поможет: как писали фигню в документах, так и будут писать ее же в системе. Тут нужно управленческий подход менять, чтобы воровство топлива было не из кармана начальника, а из кармана водителя. Тогда ему будет элементарно невыгодно воровать у себя и он никому этого не позволит. Варианты подобного развития событий имеются...
Вторая проблема – первичная документация, на основании которой происходит списание ГСМ, т.е. путевые листы, приходят к бухгалтеру по ГСМ с опозданием и ещё позже отражаются по бухгалтерии.
Эту проблему с помощью системы решить будет можно, но... для этого нужно будет нехило вложиться (инвестировать) в систему.
Третья проблема – путевые листы и заправочные ведомости часто заполняются неправильно, цифры «не идут» и бухгалтер исправляет их, подгоняет. Кроме цифр иногда не понятно, например, какой из водителей Ивановых имелся ввиду.
Это перекликается с первой проблемой. Водителям невыгодно заполнять правильно, вот бухгалтер и мучается... причем зазря...
Четвертая проблема – организация выросла, стало много техники, сотрудников, и, соответственно, путевых листов. Бухгалтер не успевает их обрабатывать.
мало одного бухгалтера - берите еще. в нашей стране нет ничего дешевле человеческого труда :о(((
Пятая проблема – расчет нормативного и фактического расхода топлива по путевым листам проводится в Экселе, а итоги забиваются в 1С. Это не очень удобно и приводит возникновению ошибок.
Используемое средство - не проблема. IMHO подгонка нормативов и расхода в ущерб правильному учету - вот проблема!
Все эти проблемы появляются на последнем этапе движения ГСМ, когда дизтопливо было выдано водителям и должно быть списано путевыми листами. Ну или на этапе документального оформления списания ГСМ.
Ещё, возможно, проблемой является нехватка оборотных средств, необходимые счета оплачиваются с большим опозданием. Таким образом, начальникам участков выгоднее завысить расход дизтоплива и занизить остатки, потому что в этом случае руководство раньше «пошевелится», счета оплатят, и вероятность простоя будет ниже. С оборотными средствами решить трудно, однако установление оперативного контроля над расходом дизтоплива, безусловно, поможет.
здесь тоже нужно менять управленческий подход, чтобы изменить направление заинтересованности начальников участков. например они должны не получать топливо, а приобретать в рамках своего бюджета. Уложились - молодцы, получай премию...
Из-за наличия данных проблем руководством организации было решено создать диспетчерскую службу, которая бы занималась оперативным контролем за расходом дизтоплива. Т.е. вместо бухгалтера в центральном офисе, к которому путевые листы приходят с опозданием на месяц, да ещё неправильно заполненными, на дорожно-строительном участке будет сидеть диспетчер и отслеживать, кому и зачем даётся дизтопливо. Бухгалтерия, отдел снабжения и коммерческий отдел в центральном офисе при этом оперативно видят, сколько дизтоплива осталось и с какой скоростью оно расходуется, т.е. можно даже попытаться планировать, когда оно закончится.
тоже вариант, но получается вместо централизованного решения с его проблемами (точнее в основном палками в колеса) создано децентрализованное, которое имеет свои проблемы и вроде как должно решить проблемы предыдущего.
Разрабатываемая ИС как раз и должна автоматизировать работу диспетчерской службы.
это понятно.
К сожалению, навскидку конкретики по решению дать не могу...
-
Водолей, я это все понимаю, и со всеми Вашими выводами, в основном, согласна.
Про водителей - думаю, там есть ещё и кадровая проблема, образования не хватает. Многие пишут с ошибками, и, мне кажется, некоторые просто считают плохо. ::)
В общем-то я описала ситуацию годичной давности, правда, думаю, она не сильно поменялась.
Тогда набрали диспетчеров, посадили их за решение на базе Рарус:Автотранспорт + 1С:Бухгалтерия 7.0. Этот Рарус оказался каким-то "корявым", а конфигурация была с большими изменениями и старый релиз.
Внедрялось решение на 1С, так как на участках кроме диспетчера сидел ещё и бухгалтер, документы которого требовалось видеть максимально оперативно и в общей базе. Обмен данными шёл через УРИБ.
Система работала, скажем так, "не фонтан", и требовала серьезных доработок, которые велись.
Плюс часто были проблемы со связью, технические проблемы и проблемы самого решения (в частности очень долго загружалась измененная конфигурация 1С).
Как там обстоят дела сейчас - не знаю, думаю, ситуация сильно не изменилось. К концу года выйду - посмотрю. ::)
Кстати, бюджеты внедрялись, вроде составлялись, утверждались. Но тут проблема была ещё и в том, что средства трудно изыскать в рамках утвержденного бюджета (!). И это не только от неправильного планирования, но и от того, что заказчик не рассчитывался в сроки, установленные договором.
Да, все проблема в людях, даже скорее в отношении к ним, в отношении к подбору персонала.
На предприятии очень большая текучесть кадров - ВСЕХ - рабочих, диспетчеров, начальников отделов.
Вот так значит. А сейчас задача у меня в основном умозрительная - написать диплом. ::) Т.е. построить модели, сочинить ТЗ и сделать работающее приложение.
Варианты подобного развития событий имеются...
Может кинете ссылку, правда интересно, хотя бы на будущее...
-
Вот так значит. А сейчас задача у меня в основном умозрительная - написать диплом. Т.е. построить модели, сочинить ТЗ и сделать работающее приложение.
Ну так не думайте о предприятии - думайте о своем дипломе. И потом в описанных Вами условиях любая толковая система будет работать "не фонтан". Поэтому:
- проблема должна быть поставлена корректно
- проблема должна быть поставлена и решаться на том уровне управления, который обладает достаточными полномочиями и ресурсами для его решения
- для решения проблемы должны использоваться адекватные средства
в данном случае, извините, я ничего этого не вижу. поэтому могу порекомендовать не париться и заниматься решением некоей абстрактной задачи, "похожей на настоящую"
насчет опыта, ссылок скорее всего не найти, т.к. мне это в приватной беседе рассказывал один из участников проекта. речь шла об учете отгрузки топлива на одном из предприятий кого-то из нефтянки.
Суть была в том, чтобы заставить (!) персонал на разливе топлива в цистерны правильно заполнять документы с указанием правильных фактических данных по отгруженному топливу.
есть и другие из личного опыта, но они с ГСМ не были связаны.
общая мысль в том, что нужно не постконтроль делать, а планировать распределение топлива и контролировать его использование, заинтересовав в предоставлении отчетности получателей топлива, хотя текучка практически не оставляет шансов на организацию учета - значит это никому реально не нужно, дешевле набрать новых водил.
-
в данном случае, извините, я ничего этого не вижу. поэтому могу порекомендовать не париться и заниматься решением некоей абстрактной задачи, "похожей на настоящую"
Хм... я вроде так и хотела делать.
Да в общем-то у нас обоснование сильно не требуется, главное спроектировать и реализовать систему. Думаю, что стандартного "все делается вручную, медлено, неудобно и с ошибками" будет достаточно.
Постараюсь подумать, как переформулировать проблемы, чтобы решение выглядело адекватным.
-
Думаю, что стандартного "все делается вручную, медлено, неудобно и с ошибками" будет достаточно.
Типичное заблуждение имхо.
Да, конечно, следует признать и принять, что новое время вносит новые подходы и технологии - это нормально. Естественно ожидать увеличение производительности, повышения комфорта, снижение ошибок, прозрачность исполнения, доступность информации, упрощения поиска, возможность получения информации в историческом срезе.
Ясно, что все это делалось и ранее, и я бы не стал утверждать что делалось хуже, медленнее. Опять же все зависило от организации и продуманности.
Но я бы не сказал, что новый способ делает работу более быстрой, более удобной и уменьшает ошибки. Практика показывает, что это часто не так. Причина возможно в том, что как раз неверно понимаются процессы и не верно проектируются системы.
-
Но я бы не сказал, что новый способ делает работу более быстрой, более удобной и уменьшает ошибки.
А я и не утверждала, что ВСЕГДА делает. Часто делает, часто - нет, а иногда новый способ производит революцию в области внедрения.
-
Переделала диаграмму классов.
Уважаемые эксперты, подскажите, пожалуйста, это уже ближе к тому, что должно быть или я опять скатилась к документам?
-
а какая-то связь между поступлением и заправкой есть?
Вы, очевидно, имеете трудности с "позиционированием" диаграммы классов, которая должна определять сущности и связи между ними.
Может попробуете через ответы на вопросы, например, какие документы должны создаваться при поступлении? Какие факты хозяйственной деятельности отражаются с помощью этих документов? Как связаны документы при поступлении с документами на перемещение? Какие объекты используются при контроле одного и другого? и т.п.
-
а какая-то связь между поступлением и заправкой есть?
Связи вроде нету. Поступлением ГСМ ставится на определенное материально-ответственное лицо, заправкой - списывается с него и ставится на другое лицо (на водителя).
Помню, у нас главбух периодически ставила вопрос, о том, что такая связь должна быть, т.е. чтобы можно было проследить весь путь потраченных денег, начиная с заявки на платеж, платежного поручения, поступления материалов (ОС), акта установки (ввода в эксплуатацию) и заканчивая списанием материалов (ОС). Даже начинали делать. Правда, думаю, так и не доделали.
Вы, очевидно, имеете трудности с "позиционированием" диаграммы классов, которая должна определять сущности и связи между ними.
Может попробуете через ответы на вопросы, например, какие документы должны создаваться при поступлении? Какие факты хозяйственной деятельности отражаются с помощью этих документов? Как связаны документы при поступлении с документами на перемещение? Какие объекты используются при контроле одного и другого? и т.п.
Ох, действительно, имею трудности. Лучше и не скажешь. У меня всё скатывается к конкретике, к логической модели. Попробую продумать этот вопрос.
-
Связи вроде нету.
Неправда - есть связь. Ищите!
Помню, у нас главбух периодически ставила вопрос, о том, что такая связь должна быть, т.е. чтобы можно было проследить весь путь потраченных денег, начиная с заявки на платеж, платежного поручения, поступления материалов (ОС), акта установки (ввода в эксплуатацию) и заканчивая списанием материалов (ОС).
Может уже настало время не только начать делать, но и сделать. Вопрос-то резонный.
То, что Вы пишете, о передаче материальной ответственности с одного лица на другое, безусловно, важно, но IMHO стоит вернуться (или начать) к простым вопросам, на которые должна давать ответ система, типа: сколько предприятие получило ГСМ всего, где оно, куда и сколько было использовано, почему именно столько и т.д. и т.п.
Тогда, глядишь, постепенно и ответите на вопрос главбуха.
-
Почитала форум, почитала Коберна, переделала диаграмму ВИ, написала набросок сценариев.
Действительно, ДВИ - это Зло, больше думаешь не о самих вариантах, а о том, чтобы красивее их представить.
Покритикуйте, пожалуйста! ???
Вариант использования "Войти в систему"
ВИ: Войти в систему
ID: 1
Краткое описанисе:
Вход в систему
Основное действующее лицо:
Диспетчер или Бухгалтер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Сотрудник запускает приложение.
2. Система показывает экран для входа.
3. Сотрудник вводит свои Логин и Пароль.
4. Система проверяет информацию.
5. Система устанавливает права доступа.
6. Система показывает основной экран.
Постусловия:
1. Пользователь успешно вошёл в систему
2. Пользователю установлен определенный набор прав.
Альтернативные потоки:
Нет.
Вариант использования "Оформить поступление ГСМ"
ВИ: Оформить поступление ГСМ
ID: 2
Краткое описание:
Регистрация поступления ГСМ от поставщика
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Поступление ГСМ»
2. Диспетчер выбирает вид поступления (за наличный расчет, по талонам, по картам безналичной оплаты, от поставщика).
3. Система запрашивает необходимые данные в соответствии с выбранным видом поступления.
4. Диспетчер вводит запрашиваемые данные.
5. Диспетчер подтверждает правильность заполнения документа.
6. Система запрашивает подтверждение проведения документа – оператор подтверждает.
7. Система сохраняет документ «Поступление ГСМ» в БД.
8. Система отражает в БД поступление ГСМ в подотчет выбранному МОЛ.
Постусловия:
1. В БД сохранен новый документ «Поступление ГСМ».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
Нет.
Вариант использования "Оформить перемещение ГСМ"
ВИ: Оформить перемещение ГСМ
ID: 3
Краткое описание:
Регистрация передачи ГСМ от одного МОЛ другому
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Перемещение ГСМ».
2. Система запрашивает реквизиты документа.
3. Диспетчер вводит запрашиваемые реквизиты.
4. Диспетчер подтверждает правильность заполнения документа.
5. Система запрашивает подтверждение проведения документа – оператор подтверждает.
6. Система сохраняет документ «Перемещение ГСМ» в БД.
7. Система проверяет корректность введенных данных и отражает в БД перемещение ГСМ с подотчета одного МОЛ в подотчет другого МОЛ.
Постусловия:
1. В БД сохранен новый документ «Перемещение ГСМ».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
На подотчете МОЛ-источника не достаточно ГСМ для списания.
Вариант использования "Оформить перемещение ГСМ: На подотчете МОЛ-источника недостаточно ГСМ для списания"
ВИ: Оформить перемещение ГСМ
ID: 3.1
Краткое описание:
Система сообщает пользователю, что на подотчете МОЛ-источника не достаточно ГСМ для списания
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 7 основного потока
2. Система сообщает, что на подотчете у МОЛ-источника недостаточно ГСМ
Постусловия:
1. В БД не было отражено движение ГСМ
Альтернативные потоки:
Нет
Вариант использования "Оформить заправку транспортного средства"
ВИ: Оформить заправку транспортного средства
ID: 4
Краткое описание:
Регистрация заправки транспортных средств из бензовоза
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Заправочная ведомость».
2. Система запрашивает реквизиты документа.
3. Диспетчер вводит запрашиваемые данные.
4. Система рассчитывает общее количество и сумму ГСМ и производит проверку наличия на подотчете заправщика данных ГСМ.
5. Диспетчер подтверждает правильность введенных данных.
6. Система запрашивает подтверждение проведения документа – оператор подтверждает.
7. Система сохраняет документ «Заправочная ведомость» в БД.
8. Система проверяет корректность введенных данных и отражает в БД перемещение ГСМ с подотчета заправщика в подотчет Водителям.
Постусловия:
1. В БД сохранен документ «Заправочная ведомость».
2. В БД отражено движение ГСМ.
Альтернативные потоки:
На подотчете у заправщика недостаточно ГСМ
Вариант использования "Оформить заправку транспортного средства: На подотчете у заправщика недостаточно ГСМ"
ВИ: Оформить заправку транспортного средства
ID: 4.1
Краткое описание:
Система сообщает пользователю, что на подотчете МОЛ-источника не достаточно ГСМ для списания
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 8 основного потока.
2. Система сообщает, что на подотчете у заправщика недостаточно ГСМ.
Постусловия:
1. В БД не было отражено движение ГСМ.
Альтернативные потоки:
Нет
Вариант использования "Создать путевой лист"
ВИ: Оформить путевой лист
ID: 5
Краткое описание:
Создание нового документа «Путевой лист»
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Путевой лист».
2. Диспетчер выбирает вид путевого листа (легкового автомобиля, грузового автомобиля, тяжелой техники).
3. Система запрашивает данные в соответствии с выбранным видом путевого листа.
4. Диспетчер вводит запрашиваемые данные.
5. Диспетчер выбирает опцию печать документа «Путевой лист».
6. Диспетчер подтверждает правильность введенных данных.
7. Система запрашивает подтверждение проведения документа – оператор подтверждает.
8. Система сохраняет документ «Путевой лист» в БД.
9. Система распечатывает документ «Путевой лист».
Постусловия:
В БД сохранен новый документ «Путевой лист».
Альтернативные потоки:
Нет.
Вариант использования "Рассчитать путевой лист"
ВИ: Рассчитать путевой лист
ID: 6
Краткое описание:
Списание ГСМ с водителя путевым листом
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Водитель
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер открывает для редактирования сохраненный документ «Путевой лист».
2. Диспетчер заполняет незаполненные реквизиты Путевого листа.
3. Система рассчитывает расход топлива по нормам и по факту.
4. Диспетчер подтверждает правильность расчета.
5. Система запрашивает подтверждение проведения документа – оператор подтверждает.
6. Система сохраняет отредактированный Путевой лист в БД.
7. Система проверяет корректность введенных данных и отражает в БД списание ГСМ с подотчета водителя.
Постусловия:
1. В БД сохранен отредактированный документ «Путевой лист».
2. В БД отражено списание ГСМ с подотчета водителя.
Альтернативные потоки:
На подотчете водителя недостаточно ГСМ
Вариант использования "Рассчитать путевой лист: На подотчете водителя недостаточно ГСМ"
ВИ: Рассчитать путевой лист
ID: 6.1
Краткое описание:
Списание ГСМ с водителя путевым листом
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Водитель
Предусловия:
Нет
Основной поток:
1. ВИ начинается с шага 8 основного потока
2. Система сообщает Диспетчеру, что на подотчете водителя недостаточно ГСМ
Постусловия:
1. В БД не было отражено списание ГСМ с подотчета водителя
Альтернативные потоки:
Нет
Вариант использования "Формировать отчеты об остатках и движении ГСМ"
ВИ: Формировать отчеты об остатках и движении ГСМ
ID: 7
Краткое описание:
Формирование отчетов об остатках и движении ГСМ
Основное действующее лицо:
Диспетчер или бухгалтер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию «Сформировать отчет».
2. Диспетчер выбирает вид отчета.
3. Система запрашивает параметры формирования отчета (период, фильтр, группировку, итоги).
4. Диспетчер вводит параметры отчета.
5. Диспетчер подтверждает правильность введенных данных.
6. Система осуществляет отбор и обработку данных согласно заданным критериям.
7. Система выводит на экран форму отчета.
Постусловия:
Сотрудник получил отчет.
Альтернативные потоки:
Нет.
Вариант использования "Произвести выгрузку данных о движении ГСМ для системы 1С:Предприятие"
ВИ: Произвести выгрузку агрегированных данных о движении ГСМ для системы 1С:Предприятие
ID: 8
Краткое описание:
Произвести выгрузку агрегированных данных для системы 1С:Предприятие.
Основное действующее лицо:
Главный диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Наступил конец месяца
Основной поток:
1. ВИ начинается, когда Главный диспетчер выбирает опцию «Выгрузить итоги за месяц».
2. Система отбирает проведенные документы за месяц
3. Главный диспетчер подтверждает правильность отбора документов и выбирает опцию «Начать выгрузку».
4. Система выгружает итоги по документам.
5. Диспетчер подтверждает правильность выгрузки.
6. Система присваивает выгруженным документам статус «Выгружен».
Постусловия:
1. Создана выгрузка итогов за месяц для 1С.
2. Выгруженные документы помечены как «Выгруженные».
Альтернативные потоки:
Нет.
-
ВИ: Войти в систему
ID: 1
Краткое описание:
Вход в систему
Я бы сосредоточился на цели. Цель какова, получить некие права доступа к информации и функциям системы
Основное действующее лицо:
Диспетчер или Бухгалтер
Лучше обобщить в Пользователя, поскольку могут появится и иные роли.
Предусловия:
Нет
Пользователь имеет учетную запись в системе, Пользователь зарегистрирован в системе.
Основной поток:
1. ВИ начинается, когда Сотрудник запускает приложение.
2. Система показывает экран для входа.
3. Сотрудник вводит свои Логин и Пароль.
4. Система проверяет информацию.
4 шаг следует убрать, проверка внутренняя функция системы, нужно сразу
5. Система устанавливает права доступа.
Альтернативные потоки:
Нет.
Они есть, ценность этого ВИ как раз в альтернативе.
Неверный логин и пароль к примеру, сколько раз можно сделать попыток и т.п. штучки, которые как раз и заменяют Ваш 4 шаг и отвечают на вопросы: А что если.
6. Система запрашивает подтверждение проведения документа – оператор подтверждает.
Я бы убрал это шаг, это похоже на реализацию в 1с, а не то что действительно важно. Нужно просто написать Оператор проводит документ,
Система сохраняет его и переводит в состояние Проведен (Учтен, Подписан и т.п.)
В остальных ВИ примерно тоже самое.
-
Лопушок, скажите, в каком это вы вузе учитесь? Это Москва?
-
Лопушок, скажите, в каком это вы вузе учитесь? Это Москва?
Нет, это г. Улан-Удэ, Восточно-Сибирский государственный технологический университет.
У меня вечерняя форма обучения, на этот предмет я не ходила, так как тогда ребенок был совсем маленьким.
Хотя да, у нас на кафедре всё довольно печально, и, к сожалению, не только с UML.
Я там работала 2 года и просто не могу упрекать преподавателей.
Преподавателям часто приходится самим изучать совершенно новую дисциплину в течение семестра, у них элементарно нет возможности досконально вникать с предмет :(
-
Нет, это г. Улан-Удэ
Ой любимый мною город, все-таки два года службы прошли в непосредственной близости.
У меня вечерняя форма обучения, на этот предмет я не ходила, так как тогда ребенок был совсем маленьким.
Для вечерней формы, Вы очень неплохо в целом подготовлены..
Хотя да, у нас на кафедре всё довольно печально, и, к сожалению, не только с UML.
Не только у Вас.
Преподавателям часто приходится самим изучать совершенно новую дисциплину в течение семестра, у них элементарно нет возможности досконально вникать с предмет :(
Да такова, наша хваленная система образования...
-
Ой любимый мною город, все-таки два года службы прошли в непосредственной близости.
Да, у нас хорошо!
Для вечерней формы, Вы очень неплохо в целом подготовлены..
Спасибо, честно говоря, не ожидала. :)
У меня просто первое образование очень близкое - "Информационные системы в экономике" и работаю программистом.
Не только у Вас.
Да такова, наша хваленная система образования...
Да уж :(. А Вы молодец, что работаете преподавателем, да ещё и помогаете чужим студентам! Спасибо Вам большое! :)
-
У меня просто первое образование очень близкое - "Информационные системы в экономике" и работаю программистом.
Ага, все-таки чувствуется профподготовка. А на кого же Вы сейчас учитесь?
-
Сейчас я учусь на инженера-программиста (ПО ВТ и АС). ::)
3 года назад у меня было много свободного времени, хотела повысить квалификацию.
Вот, повышаю ;D.
-
Эдуард, большое спасибо за Ваши замечания! Подправила.
Естественно во всех сценариях надо добавить ещё альтернативные потоки.
Постараюсь добавить позже, просто сейчас надо собрать в кучу весь материал.
Хотелось бы ещё спросить про использование шаблона CRUD+.
Насколько я поняла, при использовании шаблона CRUD следует написать вместо ВИ "Оформить поступление ГСМ" ВИ "Управлять документом "Поступление ГСМ".
Допустимо ли, на Ваш взгляд, оставить название ВИ "Оформить поступление ГСМ", но сделать альтернативные потоки, что-то типа:
1. Пользователь выбрал опцию "Отмена".
2. Пользователь выбрал опцию "Редактировать документ".
3. Пользователь выбрал опцию "Пометить документ на удаление".
Просто мне кажется, что "Оформить поступление ГСМ" более точно отражает цель Пользователя, чем "Управлять документом "Поступление ГСМ".
Или я вообще неправильно понимаю использование данного шаблона?
-
Забыла прикрепить исправленные сценарии.
ВИ "Получить доступ к работе с системой":
1. Получить доступ к работе с системой
ВИ: Получить доступ к работе системой
ID: 1
Краткое описание:
Пользователь авторизуется в системе и получает доступ к работе системой
Основное действующее лицо:
Пользователь
Второстепенные действующие лица:
Нет
Предусловия:
1. Пользователь имеет учетную запись в системе
2. Пользователю установлен определенный набор прав
Основной поток:
1. ВИ начинается, когда Сотрудник запускает приложение.
2. Система показывает экран для входа.
3. Сотрудник вводит свои Логин и Пароль.
4. Система устанавливает права доступа.
5. Система показывает основной экран.
Постусловия:
1. Пользователь успешно вошёл в систему
2. Пользователю присвоен определенный набор прав.
Альтернативные потоки:
Пользователь ввёл неправильный Логин или Пароль
ВИ "Получить доступ к работе с системой: Пользователь ввёл неправильный Логин или Пароль":
1.1 Получить доступ к работе с системой: Пользователь ввёл неправильный Логин или Пароль
ID: 1.1
Краткое описание:
Система сообщает Пользователю, что он ввёл неверный Логин и/или Пароль.
Основное действующее лицо:
Пользователь
Второстепенные действующие лица:
Нет
Предусловия:
Пользователь ввёл неправильный Логин и/или Пароль
Основной поток:
1. ВИ начинается с шага 4 основного потока
2. Система сообщает, что Пользователь ввел неверный Логин и/или Пароль.
Постусловия:
1. Вход Пользователя в БД не осуществлен.
Альтернативные потоки:
Нет
ВИ "Оформить поступление ГСМ":
2. Оформить поступление ГСМ
ВИ: Оформить поступление ГСМ
ID: 2
Краткое описание:
Регистрация поступления ГСМ от поставщика
Основное действующее лицо:
Диспетчер
Второстепенные действующие лица:
Нет
Предусловия:
Нет
Основной поток:
1. ВИ начинается, когда Диспетчер выбирает опцию создания нового документа «Поступление ГСМ»
2. Диспетчер выбирает вид поступления (за наличный расчет, по талонам, по кар-там безналичной оплаты, от поставщика).
3. Система запрашивает необходимые данные в соответствии с выбранным видом поступления.
4. Диспетчер вводит запрашиваемые данные.
5. Диспетчер подтверждает правильность заполнения документа.
6. Система сохраняет документ «Поступление ГСМ» в БД.
7. Диспетчер проводит документ.
8. Система присваивает документу статус «Проведен» и отражает в БД поступление ГСМ в подотчет выбранному МОЛ.
Постусловия:
1. В БД сохранен новый документ «Поступление ГСМ».
2. В БД отражено движение ГСМ, документу присвоен статус «Проведен».
Альтернативные потоки:
Нет.
-
Неправда - есть связь. Ищите!
Может уже настало время не только начать делать, но и сделать. Вопрос-то резонный.
То, что Вы пишете, о передаче материальной ответственности с одного лица на другое, безусловно, важно, но IMHO стоит вернуться (или начать) к простым вопросам, на которые должна давать ответ система, типа: сколько предприятие получило ГСМ всего, где оно, куда и сколько было использовано, почему именно столько и т.д. и т.п.
Тогда, глядишь, постепенно и ответите на вопрос главбуха.
Думала-думала... Вопрос-то конечно резонный, вот только если рассматривать именно ГСМ...
Как я понимаю, чтобы отследить конкретные единицы ГСМ от поступления до списания, нужно использовать партионный учет, а это существенное усложнение алгоритма, и, возможно, неудобства для пользователя.
А вот что даст внедрение партионного учета? ???
Честно говоря, особого смысла в партионном учете не вижу, ведь нет необходимости отслеживать сроки годности.
Если смотреть шире, то для того, чтобы была "сквозная" связь всех документов, поступление ГСМ должно быть как-то обосновано. Т.е. должен быть какое-то плановое значение затрат на ГСМ, берущееся из Бюджета и вычисляемое, допустим, на основе анализа затрат на ГСМ и выработки за прошлые периоды. Кроме того, наверное должна быть связь с платежными поручениями, договорами... Т.е. получается уже выход за границы простой учетной системы.
-
Допустимо ли, на Ваш взгляд, оставить название ВИ "Оформить поступление ГСМ", но сделать альтернативные потоки, что-то типа:
1. Пользователь выбрал опцию "Отмена".
2. Пользователь выбрал опцию "Редактировать документ".
3. Пользователь выбрал опцию "Пометить документ на удаление".
Просто мне кажется, что "Оформить поступление ГСМ" более точно отражает цель Пользователя, чем "Управлять документом "Поступление ГСМ".
Это допустимо, но что является альтернативой чему? Например, ясно, что нельзя отменить еще не созданный документ. Но ВИ описывает сценарий взаимодействия, а потому все действия вполне равноправны. Исключение разве Отмена, поскольку Отмена может произойти на любой стадии оформления, редактирования
Пометить на удаление - это уже часть реализации имхо.
Естественно, можно оставить ВИ Оформить поступление. Зададимся вопросом, а когда возможна правка документа? И возможна ли она вообще. Например, в SAP, созданный и проведенный документ нельзя отменить, его изменение осуществляется иными документами - например типа сторнирования.
Кроме того, под оформлением поступления ГСМ вполне можно подразумевать все перечисленные манипуляции, разве кроме удаления
-
... это существенное усложнение алгоритма, и, возможно, неудобства для пользователя...
Задача-то в чем? "Неудобство пользователя" ... хм... так пользователю удобнее всего вообще не работать.
IMHO правильно поставленная цель должна достигаться правильным использованием правильного инструментария. Как глупо организовывать полный (в т.ч. партионный) учет для ввода какой-нибудь путевки, так же глупо путем регистрации только расходных накладных решать задачу избежаний потерь (краж)
Честно говоря, особого смысла в партионном учете не вижу, ведь нет необходимости отслеживать сроки годности.
У Вас разве стоимость топлива всегда постоянная? И что Вы делаете, чтобы рассчитать себестоимость?
Если смотреть шире, то для того, чтобы была "сквозная" связь всех документов, поступление ГСМ должно быть как-то обосновано.
Производственными планами, например. И нормами расхода.
Кроме того, наверное должна быть связь с платежными поручениями, договорами... Т.е. получается уже выход за границы простой учетной системы.
Вообще-то границы системы определяете Вы, как я это понимаю. Только IMHO они должны определяться с учетом подлежащих решению проблем.
по поводу CRUD могу сказать следующее. Если говорить о некотором абстрактном документе (например, о файле в файловой системе), то, безусловно, подобным шаблоном операций можно пользоваться. В учетной же системе каждая из операций в системе для каждого отдельного документа может иметь более сложную природу, определяемую некоторым контекстом - в частности содержанием хозяйственных операций. Причем не все эти операции могут быть выполнены оператором.
Преподавателям часто приходится самим изучать совершенно новую дисциплину в течение семестра, у них элементарно нет возможности досконально вникать с предмет
А кому сейчас легко? Мне тоже часто приходится изучать совершенно новую (для меня) предметную область :о))) Про возможность досконально вникнуть в предмет скромно умолчу :о)))
-
Эдуард, Вадим, спасибо за ответы по ВИ! Подумаю, как будет лучше.
Вадим,
В общем хочется сделать так:
1. Переформулировать проблему. Действительно, от хищения ГСМ невозможно избавиться внедрением ИС.
Поэтому смотрю в сторону того, что
- необходимо иметь оперативные данные о движении и остатках ГСМ на участках
- необходимости унификации процессов учета ГСМ на производственных участках ???
В общем про проблему ещё думаю. :(
Кстати, диспетчеры как главную проблему обозначили "Нет ГСМ", типа денег не хватает. ::)
2. Сделать в системе только количественный учет в литрах, суммовой не делать.
Дизтопливо в организацию поступает:
- от поставщика.
- по картам безналичной оплаты;
- за наличный расчет; (скорее всего этот вариант в системе рассматривать не будет)
- по талонам;
Сумма ГСМ, поступающих по картам безналичной оплаты, известна только в конце месяца, т.к. организация-поставщик даёт скидки, зависящие от общего объёма заправок за месяц. Литры при этом известны.
В конце месяца итоги по движению ГСМ, выгружаются в 1С. В 1С будет создаваться документы "Списание материалов" и "Перемещение материалов". Из системы выгружаются литры, в 1C рассчитываются по средней рубли.
3. Попытаться сделать партионный учет. Хотя бы в проекте системы.
Ещё надо добавить в заправочной ведомости ссылку на документ, которым оформляется поступление ГСМ. Типа связь поступление - перемещение, в добавок к партионному учету.
В общем как-то так.
Пыталась сделать диаграмму классов.
Поругайте, пожалуйста. Мне очень поможет.
-
1. Переформулировать проблему.
why not? как я понимаю, вас никто не сдерживает в этом вопросе
- необходимо иметь оперативные данные о движении и остатках ГСМ на участках
неплохо для начала.
- необходимости унификации процессов учета ГСМ на производственных участках ???
для чего процессы-то унифицировать? снижение накладных расходов? что-то еще?
Кстати, диспетчеры как главную проблему обозначили "Нет ГСМ", типа денег не хватает. ::)
нечеткая формулировка. ведь ее можно решить, например, с помощью получения кредита... в общем, подумайте еще о проблеме
2. Сделать в системе только количественный учет в литрах, суммовой не делать.
как первый шаг вполне себе ничего...
Дизтопливо в организацию поступает:
- от поставщика.
- по картам безналичной оплаты;
- за наличный расчет; (скорее всего этот вариант в системе рассматривать не будет)
- по талонам;
нужно, например, провести инвентаризацию фактического количества топлива на складе на определенную дату и организовать учет на каждом канале поступления топлива.
Сумма ГСМ, поступающих по картам безналичной оплаты, известна только в конце месяца, т.к. организация-поставщик даёт скидки, зависящие от общего объёма заправок за месяц. Литры при этом известны.
В конце месяца итоги по движению ГСМ, выгружаются в 1С. В 1С будет создаваться документы "Списание материалов" и "Перемещение материалов". Из системы выгружаются литры, в 1C рассчитываются по средней рубли.
а "ежемесячно" - это достаточно "оперативные данные о движении и остатках ГСМ"?
3. Попытаться сделать партионный учет. Хотя бы в проекте системы.
Ещё надо добавить в заправочной ведомости ссылку на документ, которым оформляется поступление ГСМ. Типа связь поступление - перемещение, в добавок к партионному учету.
если вы не собираетесь учитывать разницу в стоимости или по другим характеристикам - зачем партионный учет. он нужен, если у вас от партии к партии меняются существенные параметры одной и той же учитываемой сущности.
Пыталась сделать диаграмму классов.
будьте проще. Помните в повести Носова "Витя Малеев в школе и дома", он решал задачу про орехи - изобразите свою схему подобным образом (для начала без какого бы то ни было моделирования): нарисуйте каналы поступления ГСМ;"бочку", куда это сливается; ТС/бензобак, которые заправляются; маршрут, на котором расходуется топливо; остаток топлива в бензобаке и т.п. - это будут состояния, для каждого изменения которых нужно иметь документ (впрочем они у вас в том или ином виде есть), нужно обеспечить прослеживание (чтобы в любой момент времени было ясно сколько всего топлива находится в системе и где именно - то ли на складе, то ли в бензобаке...), т.е. запасы ГСМ пополняются при закупке/поступлении топлива, а "исчезают" в процессе работы водителя/ТС - если работа не выполняется, то ГСМ никуда не исчезает.
У Вас по схеме нельзя, например, ответить на вопрос сколько топлива осталось в бензобаке?
А "поступление" и "заправка" - это что за сущности? "Поступило на склад" и "заправлено в бензобак ТС"?
-
для чего процессы-то унифицировать? снижение накладных расходов? что-то еще?
Диспетчера в подразделениях работают вахтовым методом, периодически сменяются, могут менять участки. Кроме того, большая текучесть кадров. В общем чтобы быстро передавать дела друг другу, не объясняя, что в этом журнале я записываю то-то и так-то, а здесь я веду это...
Да и вообще это как-то удобнее, главный диспетчер требует с диспетчеров на участках отчеты по одинаковым формам, одинаково им объясняет что и как делать. Требования соответственно также ко всем одинаковые. С поправкой на объём работы, конечно. Он везде разный.
нечеткая формулировка. ведь ее можно решить, например, с помощью получения кредита... в общем, подумайте еще о проблеме
Это я как проблему не выделяла, просто сообщила для сведения.
а "ежемесячно" - это достаточно "оперативные данные о движении и остатках ГСМ"?
Я имела ввиду, что ежемесячно данные по движению ГСМ будут выгружаться в 1С.
Сами же данные в литрах (в диспетчерской базе) будут доступны в центральном офисе после каждой репликации с базами удаленных подразделений, которые должны происходить несколько раз в день.
если вы не собираетесь учитывать разницу в стоимости или по другим характеристикам - зачем партионный учет. он нужен, если у вас от партии к партии меняются существенные параметры одной и той же учитываемой сущности.
Это меня на нём замкнуло. Всё про него думала-думала и свыклась. В общем-то технически я его всё равно не успею реализовать, слишком много там нюансов.
будьте проще.
Да, Вы правы. Я заметила в своей модели перекос - с одной стороны сильное упрощение, часть сущностей вообще опущено, с другой - усложнение, связей слишком много и они трудно отслеживаются. В общем, наблюдается явный диссонанс.
Помните в повести Носова "Витя Малеев в школе и дома", он решал задачу про орехи - изобразите свою схему подобным образом (для начала без какого бы то ни было моделирования): нарисуйте каналы поступления ГСМ;"бочку", куда это сливается; ТС/бензобак, которые заправляются; маршрут, на котором расходуется топливо; остаток топлива в бензобаке и т.п. - это будут состояния, для каждого изменения которых нужно иметь документ (впрочем они у вас в том или ином виде есть), нужно обеспечить прослеживание (чтобы в любой момент времени было ясно сколько всего топлива находится в системе и где именно - то ли на складе, то ли в бензобаке...), т.е. запасы ГСМ пополняются при закупке/поступлении топлива, а "исчезают" в процессе работы водителя/ТС - если работа не выполняется, то ГСМ никуда не исчезает.
Книгу читала не раз, но помню только дрессированную собаку, которая объелась и больше не хотела показывать фокусы. :D
Хм, по модели вроде можно отследить где и сколько топливо находится, а модель всё равно какая-то корявая. Видимо, слишком много там от логической модели. Очень трудно от этого уйти. :-\
У Вас по схеме нельзя, например, ответить на вопрос сколько топлива осталось в бензобаке?
За это отвечает сущность "ГСМ в баках", там должен быть ещё реквизит "Дата".
А сущность "ГСМ на сотруднике" должна отслеживать на каком сотруднике в каком подразделении каких ГСМ сколько содержится. (У нас учет подотчета по сотрудникам идёт в разрезе подразделений)
Я хотела сделать чтобы к этим сущностям от документов тянулись стрелки "изменяет", например. Ну или что-то в этом роде.
А "поступление" и "заправка" - это что за сущности? "Поступило на склад" и "заправлено в бензобак ТС"?
В общем да.
Пошла делать модель классов. ??? ??? ???
-
Диспетчера в подразделениях работают вахтовым методом, периодически сменяются, могут менять участки. Кроме того, большая текучесть кадров. В общем чтобы быстро передавать дела друг другу, не объясняя, что в этом журнале я записываю то-то и так-то, а здесь я веду это...
Да и вообще это как-то удобнее, главный диспетчер требует с диспетчеров на участках отчеты по одинаковым формам, одинаково им объясняет что и как делать. Требования соответственно также ко всем одинаковые. С поправкой на объём работы, конечно. Он везде разный.
Это понятно, но сформулируйте это проще, в терминах "снизить" или "повысить", "улучшить" и т.п.
Это я как проблему не выделяла, просто сообщила для сведения.
значит вычеркиваем. не надо бояться этого вычеркивания... лучше решить небольшую проблему, чем не решить никакой.
Я имела ввиду, что ежемесячно данные по движению ГСМ будут выгружаться в 1С.
Сами же данные в литрах (в диспетчерской базе) будут доступны в центральном офисе после каждой репликации с базами удаленных подразделений, которые должны происходить несколько раз в день.
во-первых, проще сделать централизованное решение, все равно у каждого участка своя совокупность данных о ГСМ, ТС и водителях, так что они не перепутаются. или там интернета нет?
во-вторых, надо бы четко разделить какие данные в какой системе будут вестить, и как системы будут ими обмениваться.
Это меня на нём замкнуло. Всё про него думала-думала и свыклась. В общем-то технически я его всё равно не успею реализовать, слишком много там нюансов.
тоже вычеркивайте... нет проблемы (которая решается партионным учетом) - нет смысла что-то решать (этим способом), только усилия зря тратить...
Да, Вы правы. Я заметила в своей модели перекос - с одной стороны сильное упрощение, часть сущностей вообще опущено, с другой - усложнение, связей слишком много и они трудно отслеживаются. В общем, наблюдается явный диссонанс.
когнитивный? :о)))
начните с главного. Что у Вас главное?
Книгу читала не раз, но помню только дрессированную собаку, которая объелась и больше не хотела показывать фокусы. :D
А, точно! Было такое (позабыл уже, хотя недавно читал :о)))! Впрочем это тоже к Вашему случаю подходит :о))) с логической моделью данных.
Хм, по модели вроде можно отследить где и сколько топливо находится, а модель всё равно какая-то корявая. Видимо, слишком много там от логической модели. Очень трудно от этого уйти. :-\
Выделите места, где у Вас могут находиться ГСМ (нарисуйте их). Определить (выпишите) действия, которые могут происходить с ГСМ (это будут Ваши стрелочки перемещений). Зафиксируйте состояния, в которых могут находиться ГСМ, и какие документы каждому переходу или состоянию соответствуют.
Проиграйте ситуацию от "на склад поступила тонна горючего", до "все горючее израсходовано и списано". Нарисуйте это на схеме пусть даже без моделирования (на UML).
Потом задайте вопрос: какие данные нужны на каждом этапе? Нарисуйте сущности (справочники пока можно не рисовать, только отмечайте? что нужно будет поместить в справочники) и опираясь на движение ГСМ (в соответствии со схемой) сопоставьте сущности с ним (когда и какие данные будут куда попадать)
Если сделаете последовательно и аккуратно, то найдете большинство ответов на безответные вопросы. А потом возьметесь за справочники.
За это отвечает сущность "ГСМ в баках", там должен быть ещё реквизит "Дата".
Ну и дальше как Вы ответите на этот вопрос (сколько осталось)?
А сущность "ГСМ на сотруднике" должна отслеживать на каком сотруднике в каком подразделении каких ГСМ сколько содержится. (У нас учет подотчета по сотрудникам идёт в разрезе подразделений)
Так Вы все-таки стремитесь к ведению параллельного учета в нескольких системах? Это более сложная задача, чем у Вас сейчас получается... Лучше пока сконцентрироваться на основном потоке информации, ляжет на схему, заработает - можно будет подумать и о расширении.
-
Это понятно, но сформулируйте это проще, в терминах "снизить" или "повысить", "улучшить" и т.п.
Поняла. ;)
во-первых, проще сделать централизованное решение, все равно у каждого участка своя совокупность данных о ГСМ, ТС и водителях, так что они не перепутаются. или там интернета нет?
во-вторых, надо бы четко разделить какие данные в какой системе будут вестить, и как системы будут ими обмениваться.
Так Вы все-таки стремитесь к ведению параллельного учета в нескольких системах? Это более сложная задача, чем у Вас сейчас получается... Лучше пока сконцентрироваться на основном потоке информации, ляжет на схему, заработает - можно будет подумать и о расширении.
Распределенная система - требование к диплому, я его менять не могу. :(
Пока предполагаю разработать основную логику программы, т.е. сам учет ГСМ, а уже после этого внести изменения в логическую модель (ввести префиксы, признаки баз, ограничить редактирования документов из других баз, добавить статусы документов и элементов справочников (типа выгружен, изменен), возможно ввести какие-то триггеры, фиксирующие изменения и т.д.).
Вообще у меня сложилось впечатление, что на защите саму реализацию распределенности особо не рассматривают.
На предприятии несколько удаленных подразделений. Справочники сотрудников и техники - единые. Одни и те же сотрудники и транспортные средства работают на разных участках. С документами возможны ситуации, когда сотрудник заправился на одном участке, получил путевой лист, потом поехал на другой участок и сдал путевой лист там. Я предполагаю, что информация в базах должна быть практически зеркальная.
На участках периодически нет интернета, при этом должна сохраняться возможность выписки документов и получения отчетов, хотя бы и с не совсем актуальными данными. В центральный офис документы должны приходить или когда появиться интернет, или когда какой-нибудь сотрудник привезёт файл обмена, т.е. должна быть предусмотрена возможность офф-лайн репликации.
Справочники сотрудников, подразделений и номенклатуры ведутся в 1С и выгружаются в разрабатываемую ИС. В системе эти справочники не редактируются. Вот что я не очень хорошо представляю, так это как движения ГСМ будут выгружаться в 1С. Там получится дублирование информации по поступлению, т.е. ГСМ приходуется 2 раза - в бухгалтерии и в разрабатываемой ИС. Надо предусмотреть какой-то механизм сверки.
Ну и дальше как Вы ответите на этот вопрос (сколько осталось)?
Предполагалось, что в таблице «ГСМ в баках» хранится остаток ГСМ в баке транспортного средства на первое число месяца. Нужно к нему прибавить/отнять движение ГСМ по транспортному средству и получится количество на текущую дату.
Выделите места, где у Вас могут находиться ГСМ (нарисуйте их). Определить (выпишите) действия, которые могут происходить с ГСМ (это будут Ваши стрелочки перемещений). Зафиксируйте состояния, в которых могут находиться ГСМ, и какие документы каждому переходу или состоянию соответствуют.
Проиграйте ситуацию от "на склад поступила тонна горючего", до "все горючее израсходовано и списано". Нарисуйте это на схеме пусть даже без моделирования (на UML).
Потом задайте вопрос: какие данные нужны на каждом этапе? Нарисуйте сущности (справочники пока можно не рисовать, только отмечайте? что нужно будет поместить в справочники) и опираясь на движение ГСМ (в соответствии со схемой) сопоставьте сущности с ним (когда и какие данные будут куда попадать)
Если сделаете последовательно и аккуратно, то найдете большинство ответов на безответные вопросы. А потом возьметесь за справочники.
Вадим, спасибо Вам большое за советы!
Нарисовала. Позже постараюсь описать предметную область и что получилось.
Вот только у меня возник вопрос, на котором застряла. Чтобы узнать количество топлива по транспортному средству, нужно обратиться к Таблице остатков. Насколько я понимаю, таблицы остатков и движений – это уже реализация. Или они тоже могут быть представлены на диаграмме классов? ??? Честно говоря, оставила бы их, но тогда связей получается слишком много.
Да, опять «трудности с позиционирование диаграммы классов». :'(
-
Уважаемые эксперты!
Подскажите, пожалуйста, какие ещё диаграммы целесообразно сделать для описания системы?
Пока есть мысль, что необходимо сделать диаграмму состояний для абстрактного документа (или конкретного, Путевой лист, например).
Думаю, необходимо осветить следующие аспекты:
1. Документ может быть "Проведён", "Непроведён" - что-то подобное хочется.
2. Выгрузка в 1С: "был выгружен и не может редактироваться", "нужно выгрузить", "не нужно выгружать"...
3. Репликация: ушёл - не ушёл, был ли вообще выгружен, "Был изменен, а значит нужно выгрузить", пришло ли подтверждение загрузки.
Кроме того: доступно ли редактирование (закрыт период, документ из базы другого подразделения), помечен на удаление.
Конкретно документ "Путевой лист" ещё может быть "Рассчитан" и "Не рассчитан".
Честно говоря, довольно смутная картина представляется. Надо мне эти моменты продумать.
Нужна ли такая диаграмма состояний?
Сделала диаграммы деятельности для некоторых прецедентов и диаграмму развертывания.
Честно говоря, ДД меня печалят. ::) Они такие и должны быть или я их неправильно понимаю?
-
Уважаемые эксперты!
Подскажите, пожалуйста, какие ещё диаграммы целесообразно сделать для описания системы?
Любые, которые помогут Вам передать то, что Вы собственно хотите передать. Поймите в реальной практике Вы все-таки будете иметь разделение труда, а следовательно возникнет задача коммуникации. В Вашем случае это может быть задача повторного использования.
Пока есть мысль, что необходимо сделать диаграмму состояний для абстрактного документа (или конкретного, Путевой лист, например).
Думаю, необходимо осветить следующие аспекты:
1. Документ может быть "Проведён", "Непроведён" - что-то подобное хочется.
2. Выгрузка в 1С: "был выгружен и не может редактироваться", "нужно выгрузить", "не нужно выгружать"...
3. Репликация: ушёл - не ушёл, был ли вообще выгружен, "Был изменен, а значит нужно выгрузить", пришло ли подтверждение загрузки.
Кроме того: доступно ли редактирование (закрыт период, документ из базы другого подразделения), помечен на удаление.
Конкретно документ "Путевой лист" ещё может быть "Рассчитан" и "Не рассчитан".
Честно говоря, довольно смутная картина представляется. Надо мне эти моменты продумать.
Нужна ли такая диаграмма состояний?
Это разумно, скорее диаграмму ЖЦ документа :)
Сделала диаграммы деятельности для некоторых прецедентов и диаграмму развертывания.
Честно говоря, ДД меня печалят. ::) Они такие и должны быть или я их неправильно понимаю?
Вопрос, следует делать ДД для простого ВИ, обычно ее делают для сложного ВИ или для отображения взаимодействия частей программы, объектов, других ВИ между собой. Если ДД элементарно, то какой в ней смысл, с другой стороны она может быть наглядна.
Подумайте ДД - это сеть Петри с одной стороны, а с другой ОО-блок-схема. Наверняка ДД будет более актуальная например на стадии описания алгоритмов. Или если вы черный ящик ИС таки попробуете вскрыть
-
Любые, которые помогут Вам передать то, что Вы собственно хотите передать. Поймите в реальной практике Вы все-таки будете иметь разделение труда, а следовательно возникнет задача коммуникации. В Вашем случае это может быть задача повторного использования.
Да-да, как раз думала про задачу коммуникации.
Помню я читала то ли статью, то ли какой-то отзыв где автор рассказывал, как они с коллегами разрабатывают программные продукты. У них один кодер в Киеве, другой в Москве, дизайнер интерфейсов и проектировщик ещё где-то.
В общем смысл был тот, что если бы не UML, то они никогда не поняли бы друг друга и не собрали бы в кучу отдельные (и подходящие друг другу!) куски кода.
Тогда я первый раз подумала о "реальной" нужности UML, а не о том, чтобы строить модели ради моделей. ;)
Ну что же, попробую думать с той стороны, что кодер по моим диаграммам должен хорошо представить себе задачу.
Хм, легко сказать, попробую... :(
Это разумно, скорее диаграмму ЖЦ документа :)
Пойду почитаю про ЖЦ документа.
Вопрос, следует делать ДД для простого ВИ, обычно ее делают для сложного ВИ или для отображения взаимодействия частей программы, объектов, других ВИ между собой. Если ДД элементарно, то какой в ней смысл, с другой стороны она может быть наглядна.
Подумайте ДД - это сеть Петри с одной стороны, а с другой ОО-блок-схема. Наверняка ДД будет более актуальная например на стадии описания алгоритмов. Или если вы черный ящик ИС таки попробуете вскрыть
Да, в моих ДД всё слишком элементарно.
Вообще-то у меня была мысль, что в ДД можно отразить процесс выдачи и обработки путевого листа. Т.е. что-то типа такого:
1. Диспетчер заполняет некоторые реквизиты путевого листа.
2. Диспетчер отдаёт путевой лист Водителю.
3. Водитель расписывается в журнале выдачи путевых листов.
4. Мед. работник осматривает Водителя и ставит в путевом листе штамп о прохождении медосмотра.
5. Водитель ездит-ездит и заполняет маршрут, показания спидометра...
6. ...
7. Водитель возвращает путевой лист диспетчеру.
8. Диспетчер вводит в Систему незаполненные реквизиты путевого листа.
9. Система рассчитывает нормы расхода топлива...
10. ...
В общем, чтобы было бы наглядно видно сам процесс. Но преподаватель мне сказал, что это не правильно, так как Водитель, например, не является частью ИС, да и вообще действий типа "Диспетчер выдаёт путевой лист водителю" на ДД
быть не должно. Ну не должно, так не должно. Только вот у меня всё равно какие-то сомнения остались.
Эдуард, на Ваш взгляд, допустимо ли таким образом использовать ДД, вроде как для описания процессов предметной области?
-
Эдуард, на Ваш взгляд, допустимо ли таким образом использовать ДД, вроде как для описания процессов предметной области?
Позволю себе ответить цитатой из книги Арлоу и Нейштадт. UML 2 и Унифицированный процесс, 2-е издание
Из собственного опыта можем сказать, что диаграммы деятельности чаще всего используются в следующих случаях.
• В процессе анализа:
• для графического моделирования потока прецедента. Такое представление является более понятным для заинтересованных сторон;
• для моделирования потока между прецедентами. При этом используется особая форма диаграммы деятельности – диаграмма обзора взаимодействий (раздел 15.12).
• При проектировании:
• для моделирования деталей операции;
• для моделирования деталей алгоритма.
• При моделировании деловой активности:
• для моделирования бизнес процесса.
Обычно заказчикам проще понимать диаграммы деятельности, поскольку большинство из них имеет представление о блок схемах в той или иной форме. Следовательно, диаграммы деятельности могут быть замечательным средством общения, если они просты.
-
Прошу прощения за некоторую задержку с ответом - не было возможности и времени почитать форум
проще сделать централизованное решение
Распределенная система - требование к диплому, я его менять не могу. :(
Одно другому не мешает, Вы же не имеете в виду децентрализованное решение, когда каждый компонент или группа компонентов полностью самостоятельны. Централизованное решение - это когда все данные, например, хранятся в центральной базе. Типичный пример, этот сайт. С другой стороны, централизованное решение может быть распределенным в некоторой части, т.е. иметь несамостоятельные (являющиеся частью общего) куски приложения. Собственно, это как раз Ваш случай. Только Вам еще нужно перед защитой хорошо разобраться, какая часть решения входит в "центр", а какая "является распределенной". Скорее всего Вам такой или подобный вопрос зададут, поэтому надо держать в голове (или записать на бумажке - пояснительной записке) принципы, определяющие централизованное и распределенное решения.
На предприятии несколько удаленных подразделений. Справочники сотрудников и техники - единые. Одни и те же сотрудники и транспортные средства работают на разных участках. С документами возможны ситуации, когда сотрудник заправился на одном участке, получил путевой лист, потом поехал на другой участок и сдал путевой лист там. Я предполагаю, что информация в базах должна быть практически зеркальная.
На участках периодически нет интернета, при этом должна сохраняться возможность выписки документов и получения отчетов, хотя бы и с не совсем актуальными данными. В центральный офис документы должны приходить или когда появиться интернет, или когда какой-нибудь сотрудник привезёт файл обмена, т.е. должна быть предусмотрена возможность офф-лайн репликации.
Ну вот, Вы же сами описываете свою систему как централизованную: единые справочники, движение информации в территориальном смысле, документы должны приходить в центральный офис и т.п.
Простейший способ - иметь одну центральную базу и ее образы (зеркала) на участках, такой механизм поддерживается основными производителями СУБД. Однако, у Вас одновременно и участков много (соответственно, их оснащение соответствующим оборудованием и ПО может представлять собой отдельную проблему), и интернет на них дохлый (что является уже другой проблемой). Разумным способом является регламентировать и сократить обмен информацией - слать только ту, что нужно. Например, обновление справочников слать ежемесячно или еженедельно, а данные о движении ГСМ - ежедневно.
Как вариант, подумайте над тем, чтобы не полностью зеркалить базы между участками, а только в той части, которая нужна для выполнения отдельных операций, например, первичная выписка документов.
Справочники сотрудников, подразделений и номенклатуры ведутся в 1С и выгружаются в разрабатываемую ИС. В системе эти справочники не редактируются. Вот что я не очень хорошо представляю, так это как движения ГСМ будут выгружаться в 1С. Там получится дублирование информации по поступлению, т.е. ГСМ приходуется 2 раза - в бухгалтерии и в разрабатываемой ИС. Надо предусмотреть какой-то механизм сверки.
Непонятно, почему Вы делаете такой вывод (о дублировании, о сверке и т.п.)? Вам нужно четко представлять движение информации (судя по всему пока этого нет): где, какая информация появляется, где вводится, куда направляется и для каждого подобного информационного объекта нарисовать внятную диаграмму (или хотя бы отсебятинскую картинку), которая детально показывает особенности этого движения.
Ведь в конечном счете Ваша задача собрать в 1С всю информацию о движении ГСМ, поступившую из разных источников. Это же не значит, что Вы всегда должны гонять по системе полные данные. Если водитель поехал из точки А в точку Б и там закрывает путевой лист, Вы же не будете ждать закрытый лист из точки А, а используя единую идентификацию ПЛ спокойно найдете его в центральной базе (или ее копии в пункте Б) - главное предусмотреть, что пока водитель едет по своему маршруту, и центральная база и ее копия в пункте Б обновилась. С другой стороны может быть достаточно написать/напечать на путевом листе уникальный номер, сгенеренный системой и тогда операции прихода и расхода ГСМ могут быть введены раздельно, но тогда они должны быть сведены в центре. Вот и получится искомая прозрачность. В общем, надо подробнее смотреть на операции - будучи детальнее знаком с постановкой, я бы, наверное, мог бы предложить ряд технических решений, но думаю, что это и Вам по силу. Более того, это как раз и есть Ваша задача - не только показать "ЧТО Вы знаете", но и "КАК Вы умеете эти знания использовать".
Предполагалось, что в таблице «ГСМ в баках» хранится остаток ГСМ в баке транспортного средства на первое число месяца. Нужно к нему прибавить/отнять движение ГСМ по транспортному средству и получится количество на текущую дату.
Технически может быть проще несколько денормализовать данные об остатке ГСМ и сохранять не каждую операцию независимо друг от друга, а на каждую операцию хранить входящий остаток, изменение и исходящий остаток. Причем, т.к. операции могут быть приходные и расходные, то можно было бы хранить их в одной записи, но в разных колонках (пусть иногда и с нулевыми значениями). Я так однажды делал, это мне сильно упростило подготовку отчетов о движении объекта учета.
Чтобы узнать количество топлива по транспортному средству, нужно обратиться к Таблице остатков. Насколько я понимаю, таблицы остатков и движений – это уже реализация.
и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.
-
Позволю себе ответить цитатой из книги Арлоу и Нейштадт. 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 дня по этому транспортному средству? На первый взгляд, это сложнее чем просто хранить операции, где указана цифра прихода/расхода, а пересчет остатков идёт в конце месяца при закрытии периода.
Хотя сейчас подумала, что, в общем-то, в путевых листах оно так и хранится. Там конкретные цифры прихода, расхода, изменения, а также экономия/перерасход. Друг от друга путевые листы не зависят, хотя связаны с заправочными ведомостями (из них берется приход).
Возможно, когда я до этого дойду (если дойду), то в голове уже сложится картина, как это должно выглядеть.
и да, и нет. Вы отталкиваетесь от того, что сначала описываете логику работы - логическую модель, а потом спускаетесь на уровень реализации. Но ведь и модель данных для СУБД, и диаграмму классов для приложения Вы все равно будете делать для разных компонентов приложения, и описывать все данные в Вашей системе они будут вместе, а не по отдельности. Поэтому при рассмотрении логического уровня Вы иногда должны учитывать особенности реализации, хотя лучше конечно идти последовательно.
Это же относится и к остальным (динамическим) диаграммам, которые взаимосвязаны.
Понятно, спасибо!
Пока пришла к выводу, что таблицы остатков и движений на диаграмме классов опущу, так как для задачи они не принципиальны. В общем-то остатки и движения для отчетов можно и по документам собирать. Чувствую, что так и будет :( .
Что касается особенностей реализации, возможно на диаграмме классов стоит отразить будущую распределенность базы. Поэтому рассмотрю возможность добавления справочника информационных баз и атрибутов принадлежности документов к базам.
-
опять извиняюсь за задержку с ответом - не было возможности ответить раньше
Одна центральная база и зеркала это однако немножко не то (ИМХО), так как при таком варианте данные меняются в центре, а участки выступают получателями, но ничего не передают центру. Такая схема может быть реализована в том же 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 вроде собирались моделировать, зачем Вам смешанное моделирование из разных методологий?), нарисуйте в понятных картинках. А когда разберетесь с суть задачи, найдете время нарисовать в виде семантически правильных моделей выбранной методологии.
Возможно, когда я до этого дойду (если дойду), то в голове уже сложится картина, как это должно выглядеть.
Ну вот Вы уже пытаетесь ставить вопросы к своей системе - продолжайте в том же духе, только разделите их на бизнес-уровень (про документы и их заполнение/движение) и на уровень реализации (классы/объекты/данные/процедуры). Что будет, если произойдет то-то событие или какое-то другое - как это должно будет отразиться в системе (с помощью системы).
Пока пришла к выводу, что таблицы остатков и движений на диаграмме классов опущу, так как для задачи они не принципиальны. В общем-то остатки и движения для отчетов можно и по документам собирать. Чувствую, что так и будет :( .
Ваша ответственность - Ваше и решение. Или наоборот :о)))
Что касается особенностей реализации, возможно на диаграмме классов стоит отразить будущую распределенность базы. Поэтому рассмотрю возможность добавления справочника информационных баз и атрибутов принадлежности документов к базам.
Если во всех местах, где он используется, класс остается неизменным - то "отражать распределенность" не надо. Подумайте лучше над тем, "где экземпляр появляется", "куда и как он перемещается", соответственно, где будут его копии. И нарисуйте это на территориально распределенной схеме. Вот тут и проявится Ваша распределенная архитектура.
-
опять извиняюсь за задержку с ответом - не было возможности ответить раньше
Вот и сделайте в своей пояснительной записке сравнение этих вариантов архитектур. Основы ведь Вы, в принципе, понимаете. А конкретика - почему такое-то решение в данном случае будет предпочтительнее? - это Ваше решение.
Хмм… А ведь действительно, надо бы сравнить. А то у меня как одним-двумя предложением упоминается, что связь нестабильная, нужна офф-лайн репликация, а также максимальная нетребовательность к администрированию вследствие территориальной удаленности производственных участков. Дальше идет сравнение и выбор СУБД исходя из этих требований… а развернутого обоснования самих критериев выбора СУБД как такового и нет.
Поправка формулировки: помимо проблем с функциональностью системы, существуют проблемы с построением архитектуры системы, в частности при взаимодействии с 1С.
Спасибо за эту поправку! Совсем по-другому звучит!
И потом у Вас по определению две базы: 1С и системы учета. "Тупо" выгружайте из 1С то, что поменялось, разделив предварительно на области видимости (ГСМ - не ГСМ), и не думайте выгружалось оно раньше или нет, нужно только чтобы оно легло на то же место с тем же кодом (чтобы дублей не было) - и всё!
Ну я именно так и собираюсь делать. Просто при этом ведь всё равно надо отслеживать что поменялось, т.е. вести какие-то логи изменений (вообще-то в 1С вроде какой-то журнал был, может быть можно его приспособить). Кроме того, должна быть какая-то обратная связь, что выгрузка измененных элементов в диспетчерскую систему произошла успешно и не надо их больше выгружать. Так будет больше шансов «не потерять» изменения.
Уж не знаю почему возникла такая схема, но не избавившись от нее, будет трудно поставить реальный учет - много сил будет уходить именно на сверку. С точки зрения бизнеса это должно сильно мешать. Возможно она (такая схема) как раз возникла из-за того, что невовремя приходили ПЛ, а сроки оплаты по счетам истекали, или может кому-то было лень разбираться с путевками. Кто знает???
Зачем Вам нужен двойной учет? Заводите в систему факты хозяйственной деятельности и будет Вам счастье и не будет нужна никакая сверка, кроме сравнения физических объемов ГСМ в бензобаке и написанного на бумаге - даже в формуле 1 такое делают :о))
Вы же ставите задачей ускорить доставку информации, вот и решайте ее, а полученное решение позволит устранить "перегибы на местах" и уменьшить дополнительную работу.
Дублирование пока получается только в оформлении прихода, там совсем мало документов (уточню количество) и бухгалтеру их нужно сверять в любом случае, т.е. даже без диспетчерской системы и диспетчеров вообще. По сути это же контроль выданных доверенностей и выполнения поставщиком своих обязательство по договору. Думаю, бухгалтер вообще проблему в этом не увидит.
На мой взгляд, никакого ужаса там нет. Ужас у нас в складском учете, который дублируется ПОЛНОСТЬЮ. Сложилось так, что на предприятии существует 2 параллельные системы (обе на 1С) – одна для кладовщика, вторая – 1С бухгалтерия, куда бухгалтер забивает оформленные кладовщиком в складской системе документы. Вот там настоящий ужас.
Вся система реализует некую специализированную схему документооборота. Не грузитесь пока синтаксисом DFD (тем более Вы ведь на UML вроде собирались моделировать, зачем Вам смешанное моделирование из разных методологий?), нарисуйте в понятных картинках. А когда разберетесь с суть задачи, найдете время нарисовать в виде семантически правильных моделей выбранной методологии.
Хорошо. Ведь зачастую чем проще, тем понятней.
Ну вот Вы уже пытаетесь ставить вопросы к своей системе - продолжайте в том же духе, только разделите их на бизнес-уровень (про документы и их заполнение/движение) и на уровень реализации (классы/объекты/данные/процедуры). Что будет, если произойдет то-то событие или какое-то другое - как это должно будет отразиться в системе (с помощью системы).
Хмм. В этом месте никаких вопросов не вижу, честно говоря. Но разделить уровни попытаюсь. А то у меня всё в кучу – и реализация и проектирование и бизнес-логика. Вот и получается много и запутано.
Ваша ответственность - Ваше и решение. Или наоборот :о)))
Скорее наоборот :). Хорошо, что задача учебная.
Если во всех местах, где он используется, класс остается неизменным - то "отражать распределенность" не надо. Подумайте лучше над тем, "где экземпляр появляется", "куда и как он перемещается", соответственно, где будут его копии. И нарисуйте это на территориально распределенной схеме. Вот тут и проявится Ваша распределенная архитектура.
Хорошо. Попробую.
-
по Вашим ответам я пока не вижу, чем еще можно Вам помочь. Так что творите-пробуйте, должно же хоть что-то получиться :о))) А потом поделитесь опытом, и будем обсуждать его.
-
Защитила я свой диплом всё-таки. Хотя очень тяжело он мне дался.
Несмотря на его позорность, даже "отлично" поставили.
Огромное пасибо за помощь! :D
-
Ну что ж, поздравляем! (подставляет стакан)
Поделитесь подробностями, что было тяжело, в чем позорность и т.п.