"Технология клиент-сервер"

Содержание:

Введение

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

Основной принцип технологии «клиент-сервер» заключается в разделении функций приложения на три группы:

• ввод и отображение данных (взаимодействие с пользователем);
• прикладные функции, характерные для данной предметной области;
• функции управления ресурсами (файловой системой, базой данных и т.д.).

Поэтому, в любом приложении выделяются следующие компоненты:

• компонент представления данных;
• прикладной компонент;
• компонент управления ресурсом.

Связь между компонентами осуществляется по определенным правилам, которые называют «протокол взаимодействия».

В данной работе рассматривается разработка клиент-серверного приложения для учёта штрафов ГИБДД.

Описание клиент-серверной технологии

Концепция технологии

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. [3]

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

Компоненты информационной системы по выполняемым функциям можно разделить на три слоя: слой представления, слой бизнес-логики и слой доступа к данным. [2]

Слой представления – все, что связано с взаимодействием с пользователем: нажатие кнопок, движение мыши, отрисовка изображения, вывод результатов поиска и т.д.

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

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

Основные особенности данной архитектуры:

• Клиентская программа работает с данными через запросы к серверному ПО.
• Базовые функции приложения разделены между клиентом и сервером.

Плюсы:

• Полная поддержка многопользовательской работы.
• Гарантия целостности данных. [5]

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

Сервер может обслуживать нескольких клиентов одновременно. В этом случае говорят о многопользовательском режиме. Только не стоит понимать слово «одновременно» в буквальном смысле. Запросы выполняются сервером последовательно. Если одновременно приходит более одного запроса, то запросы устанавливаются в очередь. В данном случае очередь - это список невыполненных клиентских запросов. Иногда запросы могут иметь приоритеты. Приоритет - это уровень «важности» выполнения запроса. Запросы с более высокими приоритетами должны выполняться раньше. [7]

Существует концепции построения системы клиент-сервер:

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

2) Сильный клиент - часть обработки информации перепоручается клиенту. [6]

Итак, клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

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

Есть и более сложные реализации архитектуры клиент/сервер, например, трехуровневые информационные системы с использованием серверов приложений

Одной из необходимых частей клиент-серверной технологии является СУБД.

СУБД

База данных – это созданная структура хранения информации для конкретно поставленной цели. Это совокупность таблиц определённой целевой направленности.

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

Сведения, подлежащие сбору и хранению – это сущность. Свойства сущностей формируют группу по их общим свойствам.

Набор сущностей – это объединение сущностей, которые связаны общими свойствами.

Свойства сущностей – атрибуты. В каждой сущностей может содержаться несколько атрибутов.

Строка таблицы (или кортеж отношения) является отдельной сущностью внутри набора сущностей.

Столбец таблицы данных является атрибутом, который обладает своим уникальным именем в пределах таблицы.

Пересечение столбца и строки даёт одно единственное значение.

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

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

Столбец таблицы имеет диапазон значений, который называется доменом атрибута. [8]

Порядок строк и столбцов не должен нести смысловой нагрузки.

Основные характеристики любой БД:

• актуальность данных и их адекватность;
• полнота данных;
• управляемость БД;
• лёгкость в использовании и переносе данных;
• устойчивость к несанкционированным воздействиям, а также надёжность эксплуатации; [9]

Преимущества организации СУБД:

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

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

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

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

Данные стандартизированы, что делает доступ к ним проще.

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

Обеспечение целостности данных. Т.е. данные, которые хранятся в БД должны быть точными и непротиворечивыми.

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

Различают следующие типы связей:

• Связь один-к-одному - данная сущность может быть связана только с одной другой сущностью и наоборот. В реляционных моделях встречается редко, но обычно несёт логический характер разделения данных. Практической пользы разделения таких данных мало.
• Связь многие-ко-многим - это означает, что сущность связана с несколькими другими сущностями. Самая распространённая и идеальная связь для реляционной модели данных. Обычно организуется при помощи первичных и внешних ключей. [1]
• Связи многие-ко-многим означает, что несколько одних сущностей могут соответствовать многим другим сущностям. В реляционной модели реализуется сложно, так как противоречит основополагающим правилам. При реализации такого типа связей следует прибегать к разбиению на несколько связей тип один-ко-многим. При этом будет составлена промежуточная сущность, которая будет включать первичные ключи связываемых таблиц.

Рассмотрим подробнее понятие ключи таблиц данных.

Ключ включает в себя один или несколько атрибутов, который определяет весь набор атрибутов.

В каждой таблице должен быть определён первичный ключ, который идентифицирует строку.

Определение первичного ключа позволяет обеспечить целостность данных на уровне сущностей. [5]

Первичный ключ не может содержать значение «null», так как это приведёт к потере целостности данных.

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

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

Первичный ключ одной таблицы, который используется в качестве поля другой таблицы называется внешним ключом. Этот механизм позволяет контролировать избыточность данных. Таблицы базы данных совместно используют атрибуты.

Проектирование баз данных включает следующие требования:

• Данные должны отображаться адекватно. Это включает: полноту и актуальность данных; динамичность модели.
• Возможность взаимодействия с пользователями разных категорий и в разных режимах.
• Данные должны быть защищены от случайных или преднамеренных разрушений БД. Должна обеспечиваться конфиденциальность данных. Надёжность и целостность данных.

Должна быть обеспечена взаимная независимость данных от программ.

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

При проектировании базы данных разработчик должен заботиться о целостности данных. Нормализованная структура таблиц позволяет избавиться от нарушений связи, а также, от внесения некорректных значений. При этом требуется определить наилучший путь обеспечения целостности. Стойкость и точность данных - на этих аспектах основывается целостность данных.

Связь с базой данных по технологии клиент-сервер

Рассмотрим язык программирования Delphi. В нём предусмотрена технология ADO, которая позволяет наладить связь с любой СУБД и организовать клиент-серверную архитектуру.

Технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных различных типов. Например, приложение, использующее ADO, может применять одинаково сложные операции и к данным, хранящимся на корпоративном сервере SQL, и к электронным таблицам, и локальным СУБД. Запрос SQL, направленный любому источнику данных через ADO, будет выполнен.

В Delphi была реализована возможность работы с технологией ADO через компоненты. Это позволяет быстро создавать системы управления базами данных любой сложности.

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

Четыре компонента наборов данных (ADODataSet, ADOTable, ADOQuery и ADOStoredProc) фактически полностью реализованы общим для них базовым классом TCustomADODataSet. Этот компонент несет ответственность за выполнение большинства функций, присущих набору данных. Производные компоненты являются тонкими оболочками, которые делают доступными для внешнего мира те или иные возможности базового компонента. Таким образом, компоненты обладают множеством общих черт.

Компоненты доступа к данным ADO могут использовать два варианта подключения к хранилищу данных. Это стандартный метод ADO и стандартный метод Delphi.

Каждый компонент, обращающийся к хранилищу данных ADO самостоятельно, задавая параметры соединения в свойстве Connectionstring, открывает собственное соединение. Чем больше приложение содержит компонентов ADO, тем больше соединений может быть открыто одновременно.

Поэтому целесообразно реализовать механизм соединения ADO через специальный компонент – TADOConnection. Этот компонент открывает соединение, также заданное свойством Connectionstring, и предоставляет разработчику дополнительные средства управления соединением.

Проектирование ИС учёта штрафов ГИБДД

Постановка задачи

Предметной областью данной разработки является учёт штрафов ГИБДД. От системы учёта штрафов потребуются следующие функции:

• учёт автотранспорта;
• учёт владельцев;
• ведение ПТС;
• учёт полицейских;
• ведение штрафов.

Потребуется хранить следующие данные:

• информацию о автотранспорте;
• информацию о владельце;
• информацию о ПТС;
• информацию о полицейских;
• информацию о выписанных штрафах.

К информации об автомобилях относится:

• номер;
• модель;
• марка;
• тип кузова;
• категория ТС;
• цвет;
• год выпуска.

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

• Ф.И.О.;
• дата рождения;
• пол;
• паспортные данные;
• права;
• адрес;
• отметка о попадании в «чёрный список».

Информация о полицейском:

• Ф.И.О.;
• дата рождения;
• пол;
• личный номер;
• звание;
• должность;
• подразделение.

ПТС:

• владелец;
• транспортное средство;
• дата регистрации;
• отметка о снятии с учёта.

Штраф:

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

Требуется учесть, что после двух месяцев неоплаты штрафа, владелец транспортного средства попадает в чёрный список. Штраф, аннулируется через 3 года после его выписки.

Требуется ввести следующие справочники для ускорения работы в системе:

• марка;
• модель;
• категория транспортного средства;
• цвет транспортного средства;
• тип кузова;
• звание;
• должность;
• подразделение;
• нарушение.

Система должна позволять составлять списки штрафов:

• штрафы по владельцу;
• штрафы по номеру транспортного средства;
• все неоплаченные штрафы на данный момент.

Модель работы ИС учёта штрафов ГИБДД

На рисунке 2.1 представлена контекстная диаграмма верхнего уровня, в которой показаны входные, выходные, управляющие потоки и ресурсы.

Рис.2.1. Контекстная модель верхнего уровня

Входящие потоки:

• информация об участниках;
• информация о ТС;
• информация о нарушениях.

Выходящие потоки:

• карта ТС;
• карта владельца;
• карта полицейского;
• ПТС;
• список всех неоплаченных штрафов;
• список неоплаченных штрафов по владельцу;
• список неоплаченных штрафов по номеру транспортного средства.

Управляющие потоки:

• ПДД;
• суммы штрафов.

Ресурсы:

• ИС учёта штрафов ГИБДД;
• инспектор.

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

• учёт ТС и владельцев;
• учёт полицейских;
• ведение штрафов;
• формирование списков.

Рис 2.2. Декомпозиция контекстной диаграммы верхнего уровня

Рассмотрим подробнее процесс учёта ТС и владельцев, он включает в себя:

• учёт ТС;
• учёт владельцев;
• формирование ПТС.

Рис. 2.3. Декомпозиция процесса учёта ТС и владельцев

Каталог базы данных

База данных ИС учёта штрафов ГИББ включает следующие таблицы:

• владелец;
• автомобиль;
• ПТС;
• полицейский;
• штраф;
• марка;
• модель;
• категорияТС;
• кузов;
• цвет;
• звание;
• должность;
• подразделение;
• нарушение;
• пользователь.

В таблицах 2.1 – 2.15 представлено описание таблиц БД.

Таблица 2.1

Владелец

Поле	Тип	Ограничение
Код	int	PK
ФИО	varchar	50, not null
ДР	Datetime
Пол	char	1
Паспорт	Varchar	70, not null
Права	Varchar	50
Адрес	Varchar	100
ЧС	bit

Таблица 2.2

Автомобиль

Поле	Тип	Ограничение
Код	int	PK
Номер	Varchar	10, not null
Марка	Int	FK
Модель	Int	FK
КатегорияТС	Int	FK
Кузов	Int	FK
Цвет	Int	FK
ГодВыпуска	Int

Таблица 2.3

ПТС

Поле	Тип	Ограничение
Код	Int	PK
Автомобиль	Int	FK, not nulle
Владелец	Int	FK, not null
Зарегистрирован	Datetime
Снят	bit

Таблица 2.4

Полицейский

Поле	Тип	Ограничение
Код	int	PK
ФИО	Varchar	50, not null
ДР	Datetime
Пол	Char	1
Номер	Varchar	10, not null
Звание	Int	FK
Должность	Int	FK
Подразделение	Int	FK

Таблица 2.5

Штраф

Поле	Тип	Ограничение
Код	Int	PK
ПТС	Int	FK, not null
Полицейский	Int	FK
Выписан	Datetime	Not null
Нарушение	Int	FK, not null
Сумма	Money	Not null
Оплачен	bit
Аннулирован	bit

Таблица 2.6

Нарушение

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null
Сумма	money

Таблица 2.7

Марка

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.8

Модель

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null
Марка	int	FK, not null

Таблица 2.9

Кузов

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.10

КатегорияТС

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.11

Цвет

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.12

Звание

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.13

Должность

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.14

Подразделение

Поле	Тип	Ограничение
Код	int	PK
Название	varchar	50, not null

Таблица 2.15

Владелец

Поле	Тип	Ограничение
Код	int	PK
Имя	Varchar	20
Пароль	Varchar	15
Инспектор	Bit
Администратор	bit

На рисунке 2.4 представлена схема данных.

Рис. 2.4. Схема данных

Разработка ИС учёта штрафов ГИБДД

Общие сведения (сценарий диалога и дерево функций)

Рассмотрим сценарий диалога проектируемой ИС учёта штрафов ГИБДД – рисунок 3.1.

Рис. 3.1. Сценарий диалога ИС учёта штрафов

Главное меню содержит следующие пункты:

Основное:

• Автотранспорт;
• Владельцы;
• Полицейские;
• Проверка штрафов.

Справочники:

• Марка и модель;
• Цвет;
• Категория ТС;
• Тип кузова;
• Звание;
• Должность;
• Подразделение.

Настройка:

• Подключение к БД;
• Пользователи.

Построим дерево функций ИС учёта штрафов ГИБДД – рисунок 3.2.

Рис. 3.2. Дерево функций ИС учёта штрафов ГИБДД

Основные функции:

• учёт автотранспорта;
• учёт владельцев;
• учёт полицейских;
• ведение ПТС;
• ведение штрафов.

Служебные функции:

• ведение справочников;
• настройка подключения к БД;
• проверка штрафов;
• проверка прав пользователя.

Разработка запросов к базе данных

Для формирования списков:

• список неоплаченных штрафов по владельцу;
• список неоплаченных штрафов по номеру автотранспорта;
• список всех неоплаченных штрафов.

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

«Select

Штраф.Код

,Владелец.ФИО AS [Владелец]

,Автомобиль.Номер+' '+Марка.Название+' '+Модель.Название AS [Автомобиль]

,Полицейский.ФИО AS [Выписал]

,Нарушение.Название AS [Нарушение]

,Штраф.Выписан AS [Дата выписки]

,Штраф.Сумма AS [Сумма]

FROM Штраф

INNER JOIN ПТС ON ПТС.Код=Штраф.ПТС

INNER JOIN Владелец ON Владелец.Код=ПТС.Владелец

INNER JOIN Автомобиль ON Автомобиль.Код=ПТС.Автомобиль

INNER JOIN Марка ON Марка.Код=Автомобиль.Марка

INNER JOIN Модель ON Модель.Код=Автомобиль.Модель

INNER JOIN Полицейский ON Полицейский.Код=Штраф.Полицейский

INNER JOIN Нарушение ON Нарушение.Код=Штраф.Нарушение

WHERE (ISNULL(Штраф.Аннулирован,0)=0) AND (ISNULL(Штраф.Оплачен,0)=0) AND (Владелец.ФИО LIKE '')».

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

«Select

Штраф.Код

,Владелец.ФИО AS [Владелец]

,Автомобиль.Номер+' '+Марка.Название+' '+Модель.Название AS [Автомобиль]

,Полицейский.ФИО AS [Выписал]

,Нарушение.Название AS [Нарушение]

,Штраф.Выписан AS [Дата выписки]

,Штраф.Сумма AS [Сумма]

FROM Штраф

INNER JOIN ПТС ON ПТС.Код=Штраф.ПТС

INNER JOIN Владелец ON Владелец.Код=ПТС.Владелец

INNER JOIN Автомобиль ON Автомобиль.Код=ПТС.Автомобиль

INNER JOIN Марка ON Марка.Код=Автомобиль.Марка

INNER JOIN Модель ON Модель.Код=Автомобиль.Модель

INNER JOIN Полицейский ON Полицейский.Код=Штраф.Полицейский

INNER JOIN Нарушение ON Нарушение.Код=Штраф.Нарушение

WHERE (ISNULL(Штраф.Аннулирован,0)=0) AND (ISNULL(Штраф.Оплачен,0)=0) AND (Автомобиль.Номер LIKE '')».

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

«Select

Штраф.Код

,Владелец.ФИО AS [Владелец]

,Автомобиль.Номер+' '+Марка.Название+' '+Модель.Название AS [Автомобиль]

,Полицейский.ФИО AS [Выписал]

,Нарушение.Название AS [Нарушение]

,Штраф.Выписан AS [Дата выписки]

,Штраф.Сумма AS [Сумма]

FROM Штраф

INNER JOIN ПТС ON ПТС.Код=Штраф.ПТС

INNER JOIN Владелец ON Владелец.Код=ПТС.Владелец

INNER JOIN Автомобиль ON Автомобиль.Код=ПТС.Автомобиль

INNER JOIN Марка ON Марка.Код=Автомобиль.Марка

INNER JOIN Модель ON Модель.Код=Автомобиль.Модель

INNER JOIN Полицейский ON Полицейский.Код=Штраф.Полицейский

INNER JOIN Нарушение ON Нарушение.Код=Штраф.Нарушение

WHERE (ISNULL(Штраф.Аннулирован,0)=0) AND (ISNULL(Штраф.Оплачен,0)=0)».

Была разработана хранимая процедура для проверки штрафов по следующему принципу: штраф не оплачен более 2 месяцев, владелец транспортного средства попадает в чёрный список; штрафу более 3 лет, он аннулируется. Код процедуры представлен ниже:

«CREATE PROCEDURE [dbo].[PR_CHECK_PAY]

AS

BEGIN

DECLARE @dt datetime

SET @dt = GETDATE()

UPDATE Штраф

SET Аннулирован = 1

WHERE DateDiff(YY,Выписан,@dt)>=3 AND (ISNULL(Оплачен,0)=0)

UPDATE Владелец

SET Владелец.ЧС = (CASE WHEN (isNULL(Штраф.Оплачен,0)=0) AND (isNULL(Штраф.Аннулирован,0)=0) AND (DateDiff(MM,Выписан,@dt)>=2) THEN 1 ELSE 0 END)

FROM Владелец

INNER JOIN ПТС ON ПТС.Владелец = Владелец.Код

INNER JOIN Штраф ON Штраф.ПТС = ПТС.Код

END».

Структура ИС

Рассмотрим структуру ИС учёта штрафов ГИБДД. На рисунке 3.3 представлена схема взаимодействия программных модулей системы.

Рис. 3.3. Структура программных модулей

Система состоит из 10 программных модулей, описание которых представлено в таблице 3.1.

Таблица 3.1

Описание программных модулей

Модуль	Описание
uLogin	Авторизация в системе
uMain	Главный модуль, для ведения списков штрафов, пример кода приведён в приложении
uOwner	Модуль обработки карт владельцев
uPTS	Модуль обработки ПТС
uAuto	Модуль обработки карт автотранспорта
uPoliceman	Модуль обработки карт полицейских
uMarkModel	Модуль обработки справочника марок и списка моделей
uModel	Модуль обработки справочника моделей
uFine	Модуль обработки штрафа
uLibrary	Модуль ведения справочной информации
uDM	Модуль доступа к данным

Пример работы ИС

Разработанная система позволяет работать в многопользовательском режиме с разными профилями пользователей.

Рассмотрим работу инспектора в ИС. Работа в ИС учёта штрафов ГИБДД начинается с главного окна, пример которого представлен на рисунке 3.4. При выборе типа поиска данных появляются поля для ввода данных поиска: ФИО владельца или номер автотранспорта (рис. 3.5).

Рис. 3.4. Главное окно

Рис. 3.5. Смена типа поиска

Для редактирования карт автотранспорта требуется в главном меню выбрать пункт «Основное» - «Автотранспорт». Откроется окно, изображённое на рисунке 3.6.

Рис. 3.6. Окно «Автотранспорт»

Для редактирования карт владельцев требуется в главном меню выбрать пункт «Основное» - «Владелец». Откроется окно, изображённое на рисунке 3.7.

Рис. 3.7. Окно «Владельцы»

Для редактирования ПТС нужно вызвать контекстное меню таблицы ПТС и выбрать соответствующий пункт – рисунок 3.8.

Рис. 3.8. Окно «ПТС»

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

Рис. 3.9. Окно «Полицейские»

Для редактирования справочников требуется выбрать пункт меню «Справочники» и выбрать требуемый тип справочника, пример редактирования справочника «Модели и марки» представлен на рисунке 3.10.

Рис. 3.10. Окно справочника «Марки и модели»

Для добавления штрафа требуется в главном окне вызвать контекстное меню таблицы и выбрать пункт «Добавить». Появится окно, представленное на рисунке 3.11.

Рис. 3.11. Окно «Штраф»

Пункт меню «Основное» - «Проверка штрафов» - проверяем штрафы по датам: если штраф не оплачен более 2 месяцев, то владелец попадает в чёрный список. Если штрафу уже 3 года, то он аннулируется.

Заключение

Цель работы изучить и применить на практике технологию клиент-сервер. В первой главе был проведён анализ теории клиент-серверной технологии.

Во второй главе была произведена постановка задачи, описаны функции системы учёта штрафов ГИБДД:

• учёт автотранспорта;
• учёт владельцев;
• ведение ПТС;
• учёт полицейских;
• ведение штрафов.

Разработана концептуальная модель работы в ИС учёта штрафов ГИБДД. Рассмотрены входные, выходные, управляющие потоки. Построена модель декомпозиции. Более подробно рассмотрен процесс учёта владельцев и автотранспорта.

Была спроектирована база данных, которая состоит из следующих таблиц:

• владелец;
• автомобиль;
• ПТС;
• полицейский;
• штраф;
• марка;
• модель;
• категорияТС;
• кузов;
• цвет;
• звание;
• должность;
• подразделение;
• нарушение;
• пользователь.

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

Была рассмотрена модульная структура ИС учёта штрафов ГИБДД. Описан каждый программный модуль.

В конце, приведён пример работы в ИС учёта штрафов ГИБДД.

Список литературы

1. Бритов Г., Осипова Т. Моделирование бизнес-процессов. /Бритов Г., Осипова Т. - М.: LAP, 2014. – 124 с.
2. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М.: Интуит, 2014. 240с.
3. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб.: Питер, 2015. – 368 с.
4. Грофф Д., Вайнберг П., Оппель Э. SQL. Полное руководство. - СПб.: Вильямс, 214. - 960с.
5. Илюшечкин В. Основы использования и проектирования баз данных. Учебник. - М.:Юрайт, 2014. - 214с.
6. Коваленко В. Проектирование информационных систем. / Коваленко В. - М.: Форум, 2012. - 320с.
7. Кузнецов С. Базы данных. - М.: Academia, 2012. - 496с.
8. Основы использования и проектирования баз данных. Учебник / Илюшечкин В. - М.: Юрайт, 2014. - 214с.
9. Осипов Д. Delphi. Программирование для Windows, OS X, iOS и Android. - СПб.: БХВ-Петербург, 2016. - 310с.