ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ

База данных – один из основных элементов курсового проекта, поэтому разработка ее структуры является важным этапом проектирования.

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

В разрабатываемой базе данных можно выделить следующие сущности и, соответственно, таблицы:

– декларант;

– товары;

– дополнительные таможенные услуги;

– таможенные сборы;

– коэффициенты на товары;

– тарифы на дополнительные таможенные услуги;

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

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

В таблице дополнительных таможенных услуг будут храниться данные о выбранных декларантом дополнительных таможенных услугах.

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

В таблицу таможенных сборов будет вноситься номер декларации и суммы основного, дополнительного сборов за таможенное оформление, а также сборов за дополнительные услуги. Сумма этих данных определяет суммарный таможенный сбор. Таблица будет связана с таблицей декларанта связью «один к одному».

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

Рис. 5.1 Логический уровень модели базы данных в ERwin

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

Логический уровень модели базы данных графически представлен на рис. 5.1. Графическое отображение физического уровня модели базы данных представлено на рисунке 5.2.

Рис. 5.2 Физический уровень модели базы данных в Erwin

ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ

ИНТЕРФЕЙСОВ СИСТЕМЫ

Рассмотрим наиболее важные классы и методы, которые были применены при разработке программы.

Серверное приложение начинается свою работу со статической функции main(), реализованной в классе Main. Здесь в бесконечном цикле осуществляется прослушивание порта, на который настроен сервер. При подключении клиента осуществляется ответвление потока – объекта класса ServStream, который будет обслуживать клиентские запросы и осуществлять взаимодействие с базой данных. Класс ServStream организован следующим образом: при создании потока создаются переменные классов BufferedReader и ObjectOutputStream, привязанные к потокам ввода и вывода сокета, ассоциируемого с соединением. Из потока ввода сервер читает строку, представленную в виде запроса языка SQL и выполняет запрос. Затем сервер соединяется с базой данных посредством методов класса DBConnector, которые реализуют соединение с помощью JDBC-ODBC моста. В результате выполнения запроса сервер получает из базы данных объект класса ResultSet. В связи с невозможностью послать клиенту данный объект из-за его несериализуемости, возникла необходимость вначале «обернуть» его в объект класса Vector, а затем записывать в выходной поток ObjectOutputStream. Запись данных из объекта класса ResultSet в объект класса Vector реализуется с помощью методов класса VectorTable.

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

При старте клиентского приложения, пользователь вводит с клавиатуры строку IP-адреса и порта, с помощью которых формируется объект класса Socket для реализации соединения с сервером. Непосредственное соединение с серверным приложением осуществляется методами класса ServerConnection: getObjectInput() и getOutput(), возвращающих соответственно выходной и входной потоки, связанные с сокетом. Схема взаимодействия с базой данных осуществляется по следующему алгоритму. При взаимодействии оператора с элементами управления окон формируются строки запросов к базе данных, которые отправляются серверу. Сервер выполняется запрос к базе данных по принципу, описанному выше и присылает клиенту объект класса Vector, заключающий в себя данные – результат запроса.

Большой интерес представляет собой реализация вывода этих данных в таблицы – объекты JTable. Для решения этой задачи был создан класс TableManager – наследник класса AbstractTableModel, в котором переопределены методы getColumnCount(), getRowCount(), getValueAt(). Объект данного класса принимает в конструкторе объект класса Vector, в котором инкапсулированы все данные, касающиеся таблицы. Затем данная модель таблицы(объект класса TableManager) «привязывается» к объекту класса JTable и с помощью переопределенных методов модели осуществляется автоматическое заполнения полей таблицы. При проектировании окон клиентского приложения для расположения компонентов в контейнере был использован менеджер компоновки AbsoluteLayout. Как известно, данный менеджер компоновки является реализацией NetBeans, и, как следствие, при запуске программы с помощью других сред обнаруживается ошибка. Для обхода этой проблемы класс AbsoluteLayout был включен в проект вместе с остальными разработанными в ходе написания программы классами.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: