Разработка программного обеспечения АРМ Экспедитора

При разработке  АСУ Экспедитора необходимо обеспечить  контроль пользователем реквизитов электронной накладной и начисленных платежей, а также ввод соответствующих замечаний. Для этого можно использовать следущую последовательность действий: получение списка накладных по плательщику из системы ЭТРАН (запрос «Запрос статуса накладных по плательщику»( invoiceStatus)), получение данных по каждой накладной из списка(запрос «Запрос данных накладной»),  проверить данные полученные по накладным. При необходимости получения информации по заявке из конкретной накладной, можно воспользоваться запросом «Запрос данных заявки на перевозку»( getClaim).

С целью реализации взаимодействия АСУ Экспедитора и системы  ЭТРАН в части информации накладных  разработчик может воспользоваться  следующими запросами:

- запрос данных накладной;

- запрос статуса накладных по плательщику. Запрос возвращает только данные, относящиеся к запрашивающей организации;

- подача обращения  по провозной плате;

Если после проверки данных накладой  у пользователя остались замечания, то он может подать обращение по провозной плате (запрос «Подача обращения по провозной плате к накладной»(complaintToInvoice)). В этом обращении пользователь может менять реквизиты накладной, суммы начисленных платежей.

В ходе формирования в  ЭТРАН запроса «Подача обращения по провозной плате к накладной» (complaintToInvoice) пользователь должен ввести информацию: 

- тип претензии() тег  cmpComplType;

- номер накладной или  идентификатор накладной (теги cmpInvoiceNumber и cmpInvoiceID соответственно).

Кроме того, пользователь должен ввести признак наличия у  него на момент формирования обращения  по провозной плате счета-фактуры (тег cmpAccounts) . Если счет-фактура на данный перевозочный документ выдана Экспедитору, то пользователю надо заполнить поле «Дата создания счета-фактуры» (тег cmpAccountsDate). Далее, пользователю надо ввести приложение экспедитора в объеме накладной (поддокумент cmpExpedInvoice).  В приложении экспедитора следует отразить замечания, возникшие при проверке накладной. При этом, в реквизиты накладной, удовлетворяющие требованиям экспедитора, необходимо ввести прежние значения без изменений, а в вместо реквизитов накладной, не удовлетворяющих требованиям экспедитора, следует внести новые значения.

В случае успешного выполнения запроса «Подача обращения по провозной плате к накладной»(complaintToInvoice) в системе ЭТРАН будет создан документ «Обращение по провозной плате» в состоянии «На  рассмотрении».

При необходимости получения  информации о документе документ «Обращение по провозной плате» из системы ЭТРАН пользователю следует выполнить запрос «Получение данных обращения по провозной плате» (GetComplaint). Предусмотрены следующие обращения:

- получение данных обращения по провозной плате;

- подача обращения по провозной плате к накладной. Запрос подачи претензии к накладной.

В случае благополучной  генерации запросов на каждый система  ЭТРАН генерирует ответы. Полные листинги запросов и ответов приведены  в приложении Г.

В случае же неверного  обращения к системе при формировании запросов и обращений система ЭТРАН выдаст кодовое сообщение об ошибке.  В системе ЭТРАН определены следующие коды ошибок всех запросов (таблица 2.6).

 

Таблица 2.6 – Коды ошибок в системе ЭТРАН

Код ошибки	Значение
1	Ошибка синтаксиса XML
2	Неизвестный тип XML-запроса
3	Неизвестный тэг в XML-запросе
4	Ошибка при проверке данных из XML-запроса
100	Внутренняя ошибка

 

 

2.3 Выводы по разделу

 

Анализируя и учитывая все возможности, предоставляемые  системами ЭТРАН и АС Клиент УЗ по интеграции с приложениями конечных пользователей, а так же связанные с этим процессом требования этих систем, можно выделить основное:

• доступ пользователей к АС Клиент-УЗ осуществляется через общую сеть Internet с использованием технологии Virtual Private Network (VPN);
• подключение всех отделений, офисов осуществляется на основе технологий ADSL и SHDSL в зависимости от потребностей в скорости передачи входящих и исходящих данных;
• для организации подключения к АС Клиент-УЗ, рабочее место пользователя должно быть подсоединено к общей сети Internet с пропускной способностью канала не менее 56 kBit/s.
• для интеграции предлагаемой системы АРМ Экспедиции грузов на ХТЗ  с системой АС Клиент-УЗ необходимо определить детальную структуру, состав и формат реквизитов и атрибутов электронного перевозочного документа, а именно, необходимо учесть, что ЭПД состоит из электронных данных и ЭЦП. Электронные данные предоставляются в тезисе document- data.  ЭЦП в виде base64- сроки предоставляется в тезисе signature. Структура, состав атрибутов и типы данных ЭПД приведенные в приложении Б.
• определено пространство имен для создания нового ЭПД, причем электронные данные должны содержать тег OTPR с учетом этапа жизненного цикла ЭПД.  Соответствие стадий и пространств имен приведенное в таблице 2.1. Для формирования последовательности байт для наложения или проверки ЭЦП электроне данные необходимо:
• представить в виде xml- документа, структура которого описана в Приложении Б;
• полученное xml- документ привести к канонической форме;
• документ в канонической форме превратить в массив байт с применением кодирования utf-8 в нормальной форме, согласно требованиям, указанным в стандарте W3C [4]
• обмен информацией между функциональными разделами системы ЭТРАН и приложениями конечных пользователей осуществляется методом репликаций баз данных, а также с помощью процедур чтения (записи) таблиц баз данных. Допускается обмен с использованием файлов данных определенной структуры, а также с помощью специализированных процедур ввода (вывода) информации через программные интерфейсы;
• в основу проектирования средств взаимодействия положена обработка данных в режиме реального времени с использованием протокола TCP/IP, архитектуры клиент-сервер,  сетей Интернета и Интранета.
• для подключения к системе ЭТРАН и обеспечения функционирования АРМ Экспедитора ХТЗ необходимо располагать следующими вычислительными ресурсами:
• видеоподсистема с разрешением не менее 800х600;
• принтер формата А4;
• операционная система Windows 98 SE или Windows 2000;
• подключение к сети Интернет с эффективной скоростью работы с узлом доступа к системе ЭТРАН не менее 14 400 бит/сек;
• кроме того, следует учесть, что ПО ViPNet Client может работать на IBM-совместимых компьютерах (стационарных или переносных) с модемом или сетевым адаптером со следующей рекомендуемой конфигурацией:
• процессор – не менее Pentium III;
• ОЗУ – не менее 512 Мбайт;
• свободное место на жестком диске – не менее 300 Мбайт;
• операционная система – Microsoft Windows 2000 (32 бит) SP4 с установленным обновлением системы безопасности KB835732 (локализация обновления обязательно должна соответствовать локализации ОС Windows), XP (32 бит), Server 2003 (32 бит)/Vista (32/64 бит), Server 2008 (32/64 бит), Windows 7 (32/64 бит), Server 2008 R2;

- на компьютере не  должно быть установлено никаких  других Персональных Сетевых Экранов (Firewall);

• при подключении через Интернет компьютер должен иметь реальный интернетовский Ip-адрес  или  на  шлюзе, осуществляющем преобразование адресов (NAT), должны быть  проведены следующие настройки:
• разрешить прохождение исходящих udp-пакетов по порту 55777;
• настроить портфорвардинг (перенаправление) входящих udp-пакетов по порту 55777. Т.е. пакеты udp:55777 (по умолчанию), приходящие на внешнюю карту Proxy из Интернета, нужно переадресовывать на компьютер в локальной сети с установленным ViPNet (в заголовке таких пакетов нужно изменить destination: IP-адреса внешней карты прокси изменить на IP-адрес компьютера с ViPNet, - и отправить пакет во внутреннюю сеть При этом порты, указанные в исходном пакете, должны оставаться неизменными);
• программное обеспечение АСУ Экспедитора должно взаимодействовать с «Сервером приложений системы ЭТРАН» посредством СОМ-объектов;
• при передаче информации из АСУ Экспедитора в систему ЭТРАН, ПО организации взаимодействия должно производить форматный контроль передаваемой информации;
• кроме форматного контроля производится контроль в соответствии с технологией ЭТРАН для обработки соответствующего типа информации;
• в качестве сервера обработки запросов может быть выбран любой сервер приложений ЭТРАН;
• особенностью технологии ЭТРАН является то, что основной бизнес процесс отношений с клиентом организован с помощью различных видов запросов. В случае благополучной генерации запросов на каждый система ЭТРАН генерирует ответы. Полные листинги запросов и ответов приведены в приложении Г.

3 СПЕЦИАЛЬНАЯ ЧАСТЬ

 

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

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

 

3.1 Разработка диаграммы  вариантов использования

 

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

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

Прецедент описывает  взаимодействие программной системы  с актерами в виде последовательности сообщений. В понятие актер входят люди, компьютерные системы и процессы.

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

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

На данной диаграмме  присутствуют следующие актеры:

- экономист. Продуцирует  управляющие документы, такие  как «Задание на отгрузку», «Запрос на Ж/Д», указывает вид оплаты, конкретизирует данные о получателе из документа «Контракт» и другие;

- мастер погрузки. Управляет  процессом погрузки, для чего  отдает распоряжение об участке  отгрузки, генерирует рапорты об  отгрузках, ведет учет остатков вагонов и другие функции;

-  приемосдатчик. Вносит  данные в систему о результатах  погрузки и крепежа; 

Рисунок 3.1 -  Диаграмма  вариантов использования USE-case бизнес процесса формирования пакета документов для отправки груза железной дорогой

 

- сортировщик ведет  учет остатков труб по различным  пролетам;

- сертификационная группа  – снабжает систему данными  о качестве трубы, генерирует  документ «Сертификат качества»;

- экспедитор. Наиболее функционально  нагруженное лицо, которое генерирует  большинство сопровождающих документов, вносит недостающие данные в  систему, обеспечивает информационную связь внутренней системы ХТЗ с информационными системами РЖД и УЗ.

 

3.2  Разработка диаграммы  развертывания системы

 

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

Узел (node) есть некоторым физически  существующим элементом системы, которая  владеет некоторым вычислительным ресурсом. Как вычислительный ресурс узла может рассматриваться наличие  по меньшей мере некоторого объема электронной или магнитооптической памяти и процессора.

В данной диаграмме развертывания (рисунок 3.2) узлами являются:

- сервер, на котором установлен СУБД  Oracle Database

- рабочая станция –  рабочая станция, то есть ПК, с установленным автоматизированным рабочим местом (АРМ);

- сервер УЗ;

- сервер РЖД.

 

 

Рисунок 3.2 – Диаграмма развертывания системы

 

3.3 Разработка диаграммы взаимодействия

 

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

На рисунке 3.3 представлена такая  диаграмма. Объектами являются Пользователь, окно идентификации пользователя (Окно ввода пароля), непосредственно разработанная система, та ее часть, которая доступна данному пользователю (АРМ пользователя), Сервер базы данных ХТЗ, на котором хранится необходимая информация, Принтер, необходимый для печати пакета документов, и представители внешних систем, вовлеченные в бизнес-процесс предметной области – Сервер УЗ и Сервер РЖД. Причем, технологии информационной системы РЖД не предусматривают прямого обращения к собственно серверу. Доступ осуществляется с помощью COM-объектов, играющих роль своеобразных «капсул», в которые помещаются пересылаемые данные.