Разработать информационную систему по продаже автомобилей в автосалоне

 

4 ИНФОРМАЦИОННАЯ МОДЕЛЬ СИСТЕМЫ УПРАВЛЕНИЯ ПРОДАЖАМИ В АВТОСАЛОНЕ И ЕЁ ОПИСАНИЕ

4.1 Информационная модель

 

Информационная  модель системы была разработана  с использованием методологии стандарта IDEF1.x (рисунок 4.1).

 

 

Рисунок 4.1– Информационная модель системы управления продажами в автосалоне

 

При разработке системы была определена необходимость  следующих сущностей:

1. Автомобиль – информация об автомобилях на складах автосалонов
2. Производитель – информация о производителях автомобилей
3. Клиент – информация о покупателях автомобилей
4. Продажа – информация о продажах автомобилей клиентам

 

1. Автомобиль

Сущность  содержит информацию об автомобилях  на складах автосалонов и имеет  следующие атрибуты:

- производитель автомобиля

- конкретная модель

- год выпуска

- цвет автомобиля

- стоимость автомобиля в долларах  США

- пробег в километрах

- фотография автомобиля

 

2. Производитель

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

- название производителя

- информация о производителе.

 

3. Клиент

Содержит  в себе информацию о клиентах автосалонов  и имеет следующие атрибуты:

- фамилия клиента

- имя клиента

- отчество клиента

- номер и серия паспорта клиента.

 

4. Продажа

Содержит  в себе информацию о продажах автомобилей  конкретным лицам и характеризуется  следующими атрибутами:

- покупатель автомобиля (клиент)

- автомобиль, который был продан

- дата продажи

- информация о продаже (например, вид продажи).

 

В модели присутствуют 3 идентифицирующих связи  «один-ко-многим». Данные связи были выбраны по следующим соображениям:

1. Каждый автомобиль имеет одного производителя в одном автосалоне, два разных производителя не могут производить один и тот же автомобиль.

2. Один  автомобиль может купить только  один, конкретный клиент. Два клиента  не могут приобрести один и  тот же автомобиль. При этом  клиент может приобретать несколько  автомобилей.

4.2 Нормализация

 

Первая  нормальная форма:

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

Для приведения сущности к первой нормальной форме  необходимо:

1) разделить сложные атрибуты на атомарные;

2) для групп повторяющихся атрибутов создать новые сущности;

3) установить с новыми сущностями связи типа «один ко многим»;

4) атрибуты, хранящие разносмысловую информацию, разделить на односмысловые.

Моя информационная модель соответствует вышеперечисленным требованиям, следовательно, находится в первой нормальной форме.

Вторая  нормальная форма:

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

 

Для приведения сущности ко второй нормальной форме  необходимо:

1) выделить атрибуты, которые функционально зависят только от    части первичного ключа;

2) поместить их в новую сущность;

3) установить с новой сущностью связь типа «один ко многим»;

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

 

Моя информационная модель соответствует вышеперечисленным требованиям, следовательно, находится во второй нормальной форме.

 

 

 

Третья  нормальная форма:

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

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

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

Для приведения сущности к третьей нормальной форме необходимо:

1) выделить атрибуты, которые функционально зависят от одного и того же неключевого атрибута;

2) поместить их в новую сущность;

3) установить с новой сущностью связь типа «один ко многим»;

4) повторить указанные выше операции, если это необходимо.

Моя информационная модель соответствует вышеперечисленным требованиям, следовательно, находится в третьей нормальной форме.

 

5 ОБОСНОВАНИЕ ОРИГИНАЛЬНЫХ РЕШЕНИЙ ПО ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАММНЫХ СРЕДСТВ, НЕ ВКЛЮЧЕННЫХ В ТРЕБОВАНИЯ

 

Взаимодействие  клиента с сервером было решено осуществить  по протоколу удаленного вызова методов  RMI:

Технология  Remote Method Invocation (RMI), впервые представленная в JDK 1.1, продвинула сетевое программирование на более высокий уровень. Хотя RMI относительно проста в использовании, она является необыкновенно мощной технологией и раскрывает перед обычным Java-программистом полностью новую парадигму – мир распределенных объектных вычислений.

Целью разработки архитектуры RMI было создание распределенной объектной модели Java, которая свободно интегрируется в язык программирования Java и локальную объектную модель. Разработчики RMI достигли этой цели; была создана система, которая переносит безопасность и устойчивость архитектуры Java в мир распределенных вычислений.

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

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

Конкретно в RMI определение удаленной службы кодируется при помощи интерфейса Java. Реализация удаленной службы кодируется в классе. Таким образом, ключ к пониманию RMI – помнить, что интерфейсы определяют поведение, а классы определяют реализацию.

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

Транспортный  уровень основан на соединениях  ТСР/IР между сетевыми машинами. Он обеспечивает основные возможности соединения и некоторые стратегии защиты от несанкционированного доступа.

При использовании  уровневой архитектуры каждый из уровней может быть изменен или  заменен без воздействия на остальную  систему. Например, транспортный уровень  может быть заменен протоколом UDP/IP без изменения остальных уровней.

 

6 ОПИСАНИЕ АЛГОРИТМОВ РЕАЛИЗУЮЩИХ БИЗНЕС-ЛОГИКУ СЕРВЕРНОЙ ЧАСТИ СИСТЕМЫ УПРАВЛЕНИЯ ПРОДАЖАМИ В АВТОСАЛОНЕ

 

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

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

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

Функции сервера вызываются клиентом удалённо, используя технологию Remote Method Invocation.

Рассмотрим  один из алгоритмов,  которых реализует  серверная часть.

Рассмотрим  функцию добавления продажи автомобиля в базу данных.

 

Шаг 1.

Клиент  вызывает удаленный метод вывода информации о всех клиентах:

public ArrayList GET_CLIENTS() throws RemoteException;

 

Шаг 2.

Формируется запрос на вывод всего списка клиентов:

rs = server.st.executeQuery( "SELECT * FROM Client ORDER BY surname,name,last_name ASC");

 

Шаг 3.

Для выбранного клиента вызывается удаленный метод оформления продажи:

public void ADD_SALE(String client_id,String car_id,String sale_date,String comments) throws RemoteException;

 

 

 

Шаг 4.

Формируется запрос на добавление продажи в таблицу:

server.st.executeUpdate( "INSERT INTO Sale VALUES("+client_id+","+car_id+","+producer_id+",'"+sale_date+"','"+comments+"')");

 

Шаг 5.

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

Листинг описанного выше алгоритма представлен в приложении Д, блок-схема представлена в приложении Г. 

7 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ ПО РАБОТЕ С СИСТЕМОЙ УПРАВЛЕНИЯ ПРОДАЖАМИ В АВТОСАЛОНЕ И РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ

 

Для работы приложения необходимо стартовать сервер, запустив файл runServer.bat.

 

 

Рисунок 7.1 – Стартовое окно сервера

 

После запуска сервера необходимо запустить клиентское приложение через файл runClient.bat. На экране появится главное диалоговое окно, представленное на рисунке 7.2.

 

 

Рисунок 7.2 – Стартовое окно клиента «Автоматизированная система управления продажами в автосалоне»

 

На рисунке 7.2 видны возможности, которыми обладает клиент. Функциональные возможности приложения обеспечиваются двумя страницами свойств. Первая страница свойств отвечает за управление продажами автомобилей.

 

Вторая  страница «Список клиентов» дает возможность работы с информацией  о клиентах автосалонов:

 

 

Рисунок 7.3 – Список клиентов

 

На главной  странице формы клиента (рисунок 7.2) имеются 2 списка:

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

Для добавления производителя необходимо нажать кнопку «Добавить…». Откроется диалог добавления производителя:

 

 

Рисунок 7.4 – Диалог добавления производителя

 

Введем  информацию о новом производителе  и нажмем кнопку «ОК»:

 

 

Рисунок 7.5 – Диалог добавления производителя с введенной информацией

 

В результате выполнения операции добавления появится новая запись в таблице производителей:

 

 

Рисунок 7.6 – Обновленный список производителей

 

 

Аналогичный диалог, только содержащий уже заполненные  поля, появляется при изменении атрибутов  производителя. Для этого необходимо выделить нужную строку в списке производителей и нажать кнопку «Изменить…».

 

 

Рисунок 7.7 – Диалог изменения производителя

 

Изменим информацию о производителе «Mazda» и нажмем кнопку «ОК»:

 

 

Рисунок 7.8 – Диалог изменения производителя с измененной строкой «Описание»

 

 

На рисунке 7.9 показан результат выполнения операции изменения:

 

 

Рисунок 7.9 – Список производителей с измененной информацией

 

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