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

 

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

Необходимо, прежде всего, классифицировать возможные атаки угроз. Во-первых, требуется обеспечить безопасность передачи и получения данных из внешнних систем „ЭТРАН” и „АС Клиент УЗ”. Во-вторых, разрабатываемое программное обеспечение так же должно соответствовать стандартам безопасности.

Современные технологи позволяют  обеспечить выполнение таких требований.

Наружная безопасность, а именно, получение/передача данных, обеспечивается применяемыми технологиями, о которых говорилось во втором разделе (технологи VPN  и http-запросов).

Разработка же собственного програмного  обеспечения происходила в с  применением технологи SDL.

SDL на русский проще перевести  как «жизненный цикл безопасного  программного обеспечения». По сути, это документация, которая описывает  так называемые best practices – рекомендуемые  практики того, как разрабатывать  безопасные приложения, и какие  инструменты необходимо использовать для проверки безопасности. Если говорить просто: есть ряд правил, которым нужно следовать, и набор инструментов, которые нужно использовать. SDL предполагает, что разработка обязательно должна пройти семь стадий: обучение, подготовка требований, дизайн, разработка, проверка, выпуск, поддержка. На каждой стадии документация SDL описывает какие-то рекомендуемые практики, – каким образом разрабатываемый код получается безопасным. Например, на стадии разработки проверяется, не используются ли в проекте запрещенные функции, а также проводится статический анализ кода. Стадия проверки включает в себя такие вещи, как пентест, динамическое тестирование кода, а также фаззинг – и все это ради того, чтобы выявить проблемы в безопасности.

В соответствии с методикой данной технологии были выполнены следующие  действия:

- на этапе проетирования был  использован инструмент sdl threat modeling tool. Важной частью проектирования  будущего программного продукта  является моделирование угроз.  Результатом моделирования является схема основных элементов будущей системы и обозначенные на ней границы доверия. Так вот SDL Threat Modeling Tool позволяет экспертам в области, не связанной с безопасностью, создавать и анализировать модели угроз. Используя полученные диаграммы, можно распознать возможную опасность и выполнить ее смягчение. SDL Threat Modeling Tool сама предлагает подсказки во время построения диаграмм и указывает на возможные просчеты.

- был проведен  анализ бинарных файлов – сборок с помощью анализатора Binscope SDL. Это позволяет выяснить, использует ли приложение все рекомендации и требования SDL. Программа Binscope SDL проверяет, были ли установлены требуемые правилами SDL флаги компилятора/сборщика, использовались ли самые последние версии инструментария и так далее. Помимо этого Binscope сообщает об использовании опасных конструкций, который являются запрещенными или нежелательными (к примеру, использование указателей на глобальные функции);

- анализ программного кода с  помощью утилиты Code Analysis for C/C++ and Visual Basic. Автоматизированное исследование исходных кодов на наличие признаков уязвимостей называется статическим тестированием. В свою очередь, Code Analysis является стандартным статическим анализатором кода и по умолчанию входит в состав некоторых редакций Visual Studio. Продуманные механизмы позволяют автоматизировать поиск в native-коде утечек памяти, неотловленных исключений, проблем с быстродействием и, конечно же, уязвимостей в области безопасности.

- тестирование различными входными данными. Фаззеры MiniFuzz File Fuzzer. Согласно SDL, в качестве одного из обязательных этапов проверки приложения (на стадии верификации) должен использоваться фаззинг, то есть тестирование случайными входными данными. Minifuzz File Fuzzer — основное средство нечеткого тестирования, разработанное для упрощения поиска проблем, которые могут привести к уязвимости системы безопасности в коде обработки файлов. Тулза генерирует различные варианты содержания файла и "скармливает" его приложению, пытаясь выявить необрабатываемые исключения.

Общую концепцию SDL-технологии можно проиллюстрировать рисунком 3.7.

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

С помощью конвертора SDL-диаграммы превращаются в текст  на алгоритмическом языке (С# или Visual Basic), при этом выполняются дополнительные проверки на соответствие схеме объектов, по ней же происходит генерация служебных процедур (отправка сообщения, генерация экземпляра объекта в оперативной памяти и т.д.).

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

 

Рисунок 3.7 - Схема применения технологии  безопасного проектирования программ SDL

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

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

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

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

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

 

3.7 Разработка пользовательского  интерфейса

 

Как видно из пункта 3.5.1 , таблиц 3.21  – 3.33, Каждая последующая таблица (носитель информации) связана с предыдущими или другими таблицами некими информационными полями. Это означает, что однажды введенная в систему информация (например, все данные о контракте, или о трубе, или же о вагоне и так далее) может и должна быть использована при генерации других документов. Такой подход обеспечит экономию времени и человеческих ресурсов, ускорит ввод информации, повысит ее надежность, достоверность. При проектировании интерфейса пользователя необходимо это учесть. Это будет достигаться за счет сокращения полей ввода информации пользователем на оконных формах. Так же в целях облегчения зрительной нагрузки пользователя, снижения уровня его сосредоточенности,  количество автоматически заполняемых полей на формах будет минимально.

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

Наиболее информативными являются следующие сущности: Контракт, Задание на отгрузку, Паспорт трубы, Сертификат качества, Паспорт вагона.

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

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

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

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

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

 

 

Рисунок 3.8 – Окно идентификации пользователя в системе

 

 

Рисунок 3.9 – Главное меню пользователя Экспедитор

 

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

При нажатии кнопки «Назад»  происходит возврат к окну регистрации  пользователя, что дает возможность покинуть систему или сменить пользователя.

Первым важным документом является отгрузочный рапорт, для  заполнения которого разработано соответствующее  окно (рисунок 3.10). Этот документ содержит в себе как и уже определенную на момент обращения к нему информацию (дата – заполняется автоматически системой как текущая, № документа – так же автоматически назначается системой как порядковый учетный номер в системе), так и информацию, требующую ввод. Например, вводу подлежат доступные номера труб. Перечень доступных труб определяется предварительно лицом, владеющим информацией о том, на каком пролете (цехе) какие трубы складируются. Таким образом, круг номеров труб сужается (т.е. этот список труб является динамическим потому, что постоянно изменяется), и пользователю просто необходимо сделать отметку (поставить птичку) возле позиций. Так как список труб длиннее, чем окно выбора, то для наглядности и дополнительной проверки введенной информации ниже предусмотрено текстовое поле, в котором отображаются номера выбранных труб (автоматически, по мере появления «птичек»).

Данный документ заполняется  для каждого вагона/платформы, для  чего в соответствующем поле указывается  номер вагона.

Сбросить всю информацию можно по нажатию кнопки «Обновить».

При нажатии кнопки «Ввод данных» происходит занесение данных в систему (БД ХТЗ), экран частично очищается, поле номера документа обновляется следующим по порядку номером. Это означает, что документ и вся его информация учтены в системе.

 

 

Рисунок 3.10 – Окно ввода информации для документа «Отгрузочный рапорт»

 

Отменить заполнение документа можно нажатием кнопки «Отмена». Вернуться в меню позволяет  кнопка «Назад в меню».

Успешность операции подтверждается окном протокола  ввода данных (рисунок 3.11)

Соответствующие кнопки позволяют пользователю:

- выйти в главное  меню пользователя;

- вернуться в форму  для заполнения такого же документа  (отгрузочный рапорт);

 

 

Рисунок 3.11 – Окно протокола ввода данных в систему

 

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

- перейти к заполнению  следующего документа (лист расчета  крепежа);

- покинуть систему.

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