Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области 'ГАИ'

Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области 'ГАИ'

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

Национальный аэрокосмический университет им. Н.Е. Жуковского

«Харьковский авиационный институт»

КУРСОВАЯ РАБОТА

по дисциплине: «Информационные технологии и интегрированные системы управления»

на тему: Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области «ГАИ»

Студента 4 курса 440-м группы

направления подготовки 6.040303

специальности «Системный анализ»

Руководитель: к. т. н., доцент

каф.405 Г. А. Мирошниченко

г. Харьков - 2015 год

РЕФЕРАТ

Пояснительная записка к курсовой работе содержит: 41 страницу, 43 рисунка, 2 таблиц, 9 источников литературы.

Цель работы - разработка полнофункционального клиент - серверного приложения в трехуровневой архитектуре, реализующего прототип ИС для предметной области «ГАИ».

Объект исследования - клиент - серверного приложение, его функции, технологии реализации.

ТРЕХУРОВНЕВАЯ АРХИТЕКТУРА КЛИЕНТ-СЕРВЕР, РЕЛЯЦИОННАЯ БАЗА ДАННЫХ, ИНФОРМАЦИОННАЯ СИСТЕМА, «СУЩНОСТЬ-СВЯЗЬ», ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ, ФИЗИЧЕСКАЯ МОДЕЛЬ ДАННЫХ, WPF.

СПИСОК УСЛОВНЫЙ СОКРАЩЕНИЙ

БД - база данных;

ИС - информационная система;

ИС - информационная система;

ИТ - информационные технологии;

СУБД - система управления базами данных;# - язык программирования, разработанный Microsoft;

для передачи электронной почты;-универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных БД

ВВЕДЕНИЕ

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

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

Могут появляться новые требования к совместимости, или возникать новые технологии ИТ-инфраструктуры, которые сократят затраты или повысят доступность и масштабируемость.

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

Цель данной курсовой работы - разработка полнофункционального клиент - серверного приложения, реализующего прототип ИС для предметной области «ГАИ». Информационной моделью для курсового проекта стала трехуровневая архитектурная модель, реализованная для windows - приложения.

ПОСТАНОВКА ЗАДАЧИ

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

Запросы:

вывести полный список ДТП, возникших по вине пешеходов, за указанный период времени с полными сведениями о них;

найти место, где произошло максимальное количество ДТП;

вывести полный список ДТП, на которые выезжали милиционеры с указанным званием за указанный период времени, с полными сведениями о ДТП;

составить список водителей, которые участвовали более чем в одном ДТП за указанный период времени, с полными сведениями об этих водителях;

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

Транзакции:

внести сведения о новом ДТП;

удалить сведения о ДТП, которые произошли ранее указанной даты.

Специальная часть:

.КЛАССИФИКАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ ПО АРХИТЕКТУРЕ. ОСНОВНЫЕ КОНЦЕПЦИИ РАЗРАБОТКИ ПРИЛОЖЕНИЯ В АРХИТЕКТУРЕ MVVM

.1 Базовые функции ИС. Классификация ИС по архитектуре

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

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

Рисунок 1.1 - Компоненты приложения

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

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

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

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

По степени распределённости ИС (Рисунок 1.2) различают:

настольные или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

распределённые ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

файл-серверные ИС (ИС с архитектурой «файл-сервер»);

клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл - серверных ИС БД находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент - серверных ИС БД и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент - серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных ИС всего два типа «звеньев»:

сервер БД, на котором находятся БД и СУБД

рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую.

В многозвенных ИС добавляются промежуточные «звенья»: серверы приложений. Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями [1].

Рисунок 1.2 - Классификация ИС по архитектуре

.2 Технология «клиент - сервер»

Общие принципы разработки

Архитектура «клиент - сервер» разделяет функции приложения пользователя (клиента) и сервера. Приложение - клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер - специальная программа, управляющая удаленной БД. SQL - сервер обеспечивает выполнение запроса в БД, формирование результата выполнения запроса и выдачу его приложению-клиенту. Клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Архитектура представлена на рисунке 1.3.

Различают двухуровневую и трехуровневую архитектуры «клиент - сервер».

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

Основные особенности:

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

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

Плюсы:

Высокая производительность.

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

Гарантия целостности данных.

Минусы:

Бизнес логика приложений осталась в клиентском ПО. При любом изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.

Слабая защита данных от взлома.

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

Необходимость использовать мощные ПК на клиентских местах.

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

Большинство недостатков двухуровневой архитектуры клиент-сервер происходят от использования клиентской станции в качестве исполнителя бизнес-логики ИС. Поэтому для решения этих недостатков используют архитектуру с т.н. «тонким клиентом», который управляет исключительно пользовательским интерфейсом, а логикой приложения управляет дополнительный уровень программного обеспечения (т.н. сервер приложения).

Такая архитектура называется трехуровневой архитектурой «клиент-сервер»

Плюсы:

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

При изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей;

Сервер приложения ИС может быть запущен в одном или нескольких экземплярах на одном или нескольких компьютерах;

Дешевый трафик между сервером приложений и СУБД;

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

Минусы:

Выше расходы на администрирование и обслуживание серверной части.

Более высокая сложность создания приложений [2].

Технология MVVM

Шаблон Model-View-ViewModel (MVVM) - применяется при проектировании архитектуры приложения. Первоначально был представлен сообществу Джоном Госсманом (John Gossman) в 2005 году как модификация шаблона Presentation Model. MVVM ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight от компании Microsoft.используется для разделения модели и её представления, что необходимо для изменения их отдельно друг от друга. Например, разработчик задает логику работы с данными, а дизайнер соответственно работает с пользовательским интерфейсом.удобно использовать вместо классического шаблона MVC и ему подобных в тех случаях, когда в платформе, на которой ведётся разработка, присутствует «связывание данных».

В шаблонах проектирования MVC/MVP изменения в пользовательском интерфейсе не влияют непосредственно на Mодель, а предварительно идут через Контроллер (англ. Controller) или Presenter. В таких технологиях как WPF и Silverlight есть концепция «связывания данных», позволяющая связывать данные с визуальными элементами в обе стороны. Следовательно, при использовании этого приема применение модели MVC становится крайне неудобным из-за того, что привязка данных к представлению напрямую не укладывается в концепцию MVC/MVP.

Шаблон MVVM (Рисунок 1.3) делится на три части:

Модель (англ. Model), так же, как в классической MVC, Модель представляет собой фундаментальные данные, необходимые для работы приложения.

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

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

Рисунок 1.3 - Концепция MVVM

Общие правила выбора шаблона MVVM

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

Частым примером является технология WPF.

. ПРОЕКТНОЕ РЕШЕНИЕ, РЕАЛИЗУЮЩЕЕ МОДЕЛЬ РЕЛЯЦИОННОЙ БД

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

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

Язык SQL - универсальный способ манипулирования такими данными.

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

сама предметная область;

концептуальная модель данных;

логическая модель данных;

физическая модель данных;

собственно база данных и приложения [2].

Предметная область - это часть реального мира, данные о которой необходимо отразить в базе данных.

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

2.1Логическая модель данных

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

диаграмма “сущность-связь” (Entity Relationship Diagram, ERD);

модель данных, основанная на ключах (Key Based model, KB);

полная атрибутивная модель (Fully Attributed model, FA).

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

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

.2 Физическая модель данных

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

Физическая модель данных представлена на рисунке 2.2.

Рисунок 2.1 - Физическое представление модели

3. СПЕЦИФИКАЦИИ НА РАЗРАБОТКУ ИНТЕРФЕЙСА

.1 Работа с программой

При запуске приложения на экране появляется главное окно (MainWindow), на котором расположены:

два элемента управления DatePicker для выбора начальной и конечной даты;

элемент управления с выпадающим списком ComboBox для выбора звания милиционера;

пять кнопок в правом верхнем углу для выполнения запросов;

элемент управления DataGrid для отображения результатов запросов

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

Рисунок 3.1 - Главное окно приложения

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

Запрос №1

Задание: вывести полный список ДТП, возникших по вине пешеходов, за указанный период времени с полными сведениями о них.

В DatePicker’ах необходимо выбрать начальную и конечную дату периода, после чего нажать кнопку «Виновник пешеход».

Примечание: по умолчанию в DatePicker’ах автоматически выбраны дата первого ДТП и дата запуска приложения.

В DataGrid будет выведена информация об адресе ДТП, дате и времени, виновнике ДТП, и звании инспектора.

Текст запроса:

"SELECT DTP.Place AS 'Адрес ДТП', DTP.Date AS 'Дата и время ДТП',

P.Name AS 'Виновник ДТП', (Pol.Title + ' ' + Pol.P_Name) AS 'Инспектор' FROM DTPJOIN PeopleDTP PDTP ON DTP.ID_DTP = PDTP.ID_DTP DTP.ID_Author = PDTP.ID_People AND PDTP.Passenger = 0JOIN Police Pol ON DTP.ID_Police = Pol.ID_PoliceJOIN People P ON PDTP.ID_People = P.ID_PeopleDTP.Date BETWEEN @param1 AND @param2"

@param1 - дата начала периода, @param2 - дата конца периода

Результат выполнения запроса показан на рисунке 3.2.

Рисунок 3.2 -Результат выполнения запроса №1

Запрос №2

Задание: найти место, где произошло максимальное количество ДТП.

Для выполнения запроса №2 нажать кнопку «Максимальное количество ДТП». Для данного запроса ввод дополнительных данных не требуется.

Текст запроса:

SELECT TOP 1 Place AS 'Адрес', COUNT(Place) AS 'Количество ДТП'

FROM DTP BY Place BY 'Количество ДТП'

DESC"

Результат выполнения запроса показан на рисунке 3.3.

Рисунок 3.3 -Результат выполнения запроса №2

Запрос №3

Задание: вывести полный список ДТП, на которые выезжали милиционеры с указанным званием за указанный период времени, с полными сведениями о ДТП.

В DatePicker’ах необходимо выбрать начальную и конечную дату периода, а в ComboBox’e звание милиционера, после чего нажать кнопку «По званию милиционера».

Примечание: по умолчанию в DatePicker’ах автоматически выбраны дата первого ДТП и дата запуска приложения. Данные в ComboBox считаны с БД. Заполнение ComboBox’а происходит с помощью строки запроса:

"SELECT Title FROM Police GROUP BY Title ORDER BY Title"

В DataGrid будет выведена информация об адресе ДТП, дате и времени, виновнике ДТП, и звании инспектора.

Текст запроса:

"SELECT DTP.Place AS 'Адрес ДТП', DTP.Date AS 'Дата и время ДТП',

P.Name AS 'Виновник ДТП', Pol. Title + ' ' + Pol.P_Name AS 'Инспектор' DTPJOIN Police Pol ON DTP.ID_Police = Pol.ID_PoliceJOIN People P ON DTP.ID_Author = P.ID_PeoplePOL.Title = @param1 AND DTP.Date

BETWEEN @param2 AND @param3"

@param1 - дата начала периода, @param2 - дата конца периода

@param3 - звание милиционера

Результат выполнения запроса показан на рисунке 3.4.

Рисунок 3.4 -Результат выполнения запроса №3

Запрос №4

Задание: составить список водителей, которые участвовали более чем в одном ДТП за указанный период времени, с полными сведениями об этих водителях.

В DatePicker’ах необходимо выбрать начальную и конечную дату периода.

Примечание: по умолчанию в DatePicker’ах автоматически выбраны дата первого ДТП и дата запуска приложения.

В DataGrid будет выведена информация количестве ДТП и полная информация об участнике.

Текст запроса:

"SELECT t1.CNT AS 'Количество ДТП', P.Name AS 'Водитель', .DrvLic AS 'Удостоверение',P.Passport AS 'Паспорт', P.Adress AS 'Адрес' (SELECT V.ID_People, COUNT(*) AS CNT

FROM VehicleDTP V GROUP BY V.ID_People) t1JOIN People P ON t1.ID_People = P.ID_Peoplet1.CNT > 1 BY t1.CNT

DESC"

Результат выполнения запроса показан на рисунке 3.5.

Рисунок 3.5 -Результат выполнения запроса №4

Запрос №5

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

В DatePicker’ах необходимо выбрать начальную и конечную дату периода.

Примечание: по умолчанию в DatePicker’ах автоматически выбраны дата первого ДТП и дата запуска приложения.

В DataGrid будет выведена информация об адресе ДТП, дате и времени, виновнике ДТП, и звании инспектора.

Текст запроса:

"SELECT DTP.Place AS 'Адрес ДТП', DTP.Date AS 'Дата и время ДТП',

Police. Title + ' ' + Police.P_Name AS 'Инспектор', P.Name AS 'Пострадавший', .I_Name AS 'Вид травмы' FROM Injury I

INNER JOIN (SELECT ID_Inj, COUNT(*) AS cnt

FROM Injury GROUP BY ID_Inj) t1 ON I.ID_Inj = t1.ID_InjJOIN Inj ON Inj.ID_Ing = I.ID_InjJOIN People P ON I.ID_People = P.ID_People JOIN DTP ON DTP.ID_Dtp = I.ID_Dtp JOIN Police ON Police.ID_Police = DTP.ID_Police DTP.Date BETWEEN @param1 AND @param2

ORDER BY t1.cnt DESC,P.Name,DTP.Date"

Результат выполнения запроса показан на рисунке 3.6.

Рисунок 3.6 -Результат выполнения запроса №5

Транзакция №1

После того, как пользователь, на главном окне, нажал кнопку «Добавить ДТП», перед ним появится новое окно, на котором расположены:

элемент управления DatePicker для выбора даты ДТП;

элементы управления с выпадающим списком ComboBox для выбора звания милиционера, вида травмы виновника (участника), имени виновника (участника) ДТП, гос. номера транспортного средства виновника (участника) ДТП;

элементы управления RadioButton для переключения между статусами Водитель и Пешеход;

текстовые поля TextBox для введения информации об участниках ДТП и транспортных средствах.

На рисунке 3.1 изображено главное окно приложения.

Рисунок 3.7 - Окно транзакции №1

Задание: внести сведения о новом ДТП.

В DatePicker’е необходимо выбрать дату ДТП, в TextBox’e ввести адрес ДТП. Из выпадающего списка «Инспектор» выбрать милиционера, выезжавшего на ДТП.

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

Примечание: по умолчанию в DatePicker’е автоматически выбрана дата запуска приложения. Все ComboBox’ы автоматически заполняются данными из БД.

При нажатии на кнопку «Добавить ДТП» в БД добавляется информация о новом ДТП. При нажатии на кнопку «Добавить участника» к существующему ДТП добавляется информация об участнике.

Транзакция №2

Задание: удалить сведения о ДТП, которые произошли ранее указанной даты.

В DatePicker’ах необходимо выбрать начальную и конечную дату периода удаления.

Примечание: по умолчанию в DatePicker’ах автоматически выбраны дата первого ДТП и дата запуска приложения.

При нажатии на кнопку «Удалить ДТП» выводится окно подтверждения (Рисунок 3.8)

Рисунок 3.8 - Окно подтверждения удаления ДТП

4.СПЕЦИАЛЬНАЯ ЧАСТЬ: WPF

Presentation Foundation (WPF) ― это система следующего поколения для построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем.

В основе WPF лежит векторная система отрисовки, не зависящая от разрешения и созданная с расчетом на возможности современного графического оборудования. WPF расширяет базовую систему полным набором функций разработки приложений, в том числе Язык XAML (Extensible Application Markup Language), элементами управления, привязкой данных, макетом, двухмерный- и трехмерный-графикой, анимацией, стилями, шаблонами, документами, мультимедиа, текстом и оформлением. WPF входит в состав Microsoft .NET Framework и позволяет создавать приложения, включающие другие элементы библиотеки классов .NET Framework.

.1Программирование с использованием WPF

существует в качестве подмножества типов .NET Framework, которые занимают большую часть в пространстве имен System.Windows.

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

.2Разметка и код программной части

В WPF дополнительно совершенствуется процесс программирования для разработки клиентских приложений Windows. Одним очевидным усовершенствованием является возможность разрабатывать приложения с помощью разметки и кода программной части, с которыми разработчики ASP.NET должны быть уже знакомы. Разметка Язык XAML (Extensible Application Markup Language) обычно используется для реализации внешнего вида приложения при реализации его поведения с помощью управляемых языков программирования (кода программной части). Это разделение внешнего вида и поведения имеет следующие преимущества:

Затраты на разработку и обслуживание снижаются, так как разметка определенного внешнего вида тесно не связана с кодом определенного поведения.

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

Для реализации и совместного использования разметки Язык XAML применяется множество средств конструирования, чтобы удовлетворить требованиям участников разработки приложений. Microsoft Expression Blend предназначается для конструкторов, в то время как Visual Studio 2013 ориентируется на разработчиков.

Глобализация и локализация для приложений WPF существенно упрощены

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

Приложения

.NET Framework, System.Windows, разметка и выделенный код составляют основу разработки приложений WPF. Кроме того, WPF предоставляет полный набор средств для создания удобных и многофункциональных элементов пользовательского интерфейса. Чтобы упаковать разработанные элементы и предоставить их пользователю в виде приложений, WPF предоставляет типы и службы, вместе называемые моделью приложения. Модель приложения поддерживает разработку как автономных, так и размещенных в браузере приложений.

Ввод и команды

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

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

Макет

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

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

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

Привязка данных

Большинство приложений создаются для предоставления пользователям средств просмотра и редактирования данных. В приложениях WPF работа по хранению и доступу к данным уже обеспечена такими технологиями, как Microsoft SQL Server и ADO.NET. После обращения к данным и загрузки данных в объекты, управляемые приложением, начинается основная тяжелая работа для приложений WPF. По существу, она включает в себя две вещи:

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

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

Чтобы упростить разработку приложений, WPF предоставляет механизм привязки данных для автоматического выполнения этих этапов. Основной единицей механизма привязки данных является класс Binding, назначение которого привязать элемент управления (цель привязки) к объекту данных (источник привязки). Это отношение показано на рисунке 4.1.

Рисунок 4.1 - Схема привязки данных

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

Графика, не зависящая от разрешения и устройства. Основной единицей измерения в графической системе WPF является аппаратно-независимый пиксель, который составляет 1/96 часть дюйма независимо от фактического разрешения экрана и предоставляет основу для создания изображения, независимого от разрешения и устройства. Каждый аппаратно-независимый пиксель автоматически масштабируется в соответствии с числом точек на дюйм в системе, в которой он отображается.

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

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

Аппаратное ускорение. Графическая система WPF использует преимущества графического оборудования, чтобы уменьшить использование ЦП.

Пользовательские элементы управления

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

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

Нужное поведение не поддерживается (или поддерживается частично) существующими реализациями WPF.

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

Модель пользовательского элемента управления. Пользовательский элемент управления наследуется от UserControl и состоит из одного или нескольких других элементов управления.

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

Модель элемента .NET Framework. Пользовательский элемент управления производится от FrameworkElement, когда его внешний вид определяется пользовательской логикой отрисовки (не шаблонами).

Также был создан инсталляционный пакет с помощью стандартных утилит Visual Studio 2013. В нем присутствует файл лицензионного соглашения и on-line загрузчик, который при необходимости скачивает необходимые библиотеки для нормальной работы приложения на конечном ПК. Также пользователю предоставляется возможность выбора конечного каталога для установки приложения.

Все этапы установки представлены на рисунках 4.1 - 4.6.

Рисунок 4.1 - Стартовое окно установщика

Рисунок 4.2 - Окно лицензионного соглашения

Рисунок 4.3 - Окно выбора папки для установки

Рисунок 4.4 - Окно подтверждения установки

Рисунок 4.6 - Окно завершения установки

. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ ПО РАБОТЕ С ПРИЛОЖЕНИЕМ

При запуске приложения на экране появляется главное окно, на котором расположены:

два поля для выбора начальной и конечной даты. По умолчанию заданы дата первого ДТП и дата запуска приложения;

выпадающий список «Звание» для выбора звания милиционера;

пять кнопок в правом верхнем углу для вывода информации из базы данных;

две кнопки в правом нижнем углу для добавления или удаления ДТП.

На рисунке 5.1 показано главное окно приложения.

Рисунок 5.1 - Главное окно приложения

Кнопка «Виновник пешеход» показывает полный список ДТП, возникших по вине пешеходов, за указанный период времени с полными сведениями о пешеходах.

Кнопка «Максимальное количество ДТП» показывает место, где произошло максимальное количество ДТП.

Кнопка «По званию милиционера» активируется только при выборе звания милиционера из выпадающего списка «Звание» и показывает полный список ДТП, на которые выезжали милиционеры с указанным званием за указанный период времени, с полными сведениями о ДТП.

Кнопка «Злостные водители» показывает список водителей, которые участвовали более чем в одном ДТП за указанный период времени, с полными сведениями об этих водителях.

Кнопка «Пострадавшие с травмами» показывает список пострадавших в ДТП за указанный период времени с полными сведениями об этих ДТП, упорядоченный по количеству травм определенного вида.

Кнопка «Добавить ДТП» активирует новое окно приложения, показанное на рисунке 5.2.

Рисунок 5.2 - Окно добавления ДТП

На окне добавления ДТП расположены:

поле для выбора даты ДТП;

выпадающие списки:

«Инспектор» для выбора милиционера, выезжавшего на ДТП;

«Травма» для выбора травмы виновника и участника ДТП;

«Имя виновника» для выбора имени виновника ДТП;

«Номер ТС» для выбора государственного номера транспортного средства виновника и участника ДТП;

«Имя участника» для выбора имени участника ДТП

две кнопки для добавления виновника и участников ДТП;

индикаторы для переключения между статусами Водитель, Пешеход и Пассажир;

текстовые поля:

«Имя виновника» («Имя участника») для ввода новых участников ДТП, которых нет в базе данных;

«Адрес проживания», «Номер паспорта», «Удостоверение» для ввода данных об участниках ДТП;

«Номер ТС» и «Марка» для ввода данных о транспортном средстве.

Добавление нового ДТП происходит в два этапа.

Добавление общих сведений и виновника ДТП

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

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

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

При нажатии на кнопку «Добавить ДТП» общая информация о ДТП и данные о виновнике заносятся в базу данных.

Добавление участников ДТП

Участники ДТП добавляются по одному. Заполнение соответствующих полей участника ДТП происходит так же как и у виновника.

На рисунке 5.3 изображено полностью заполненное окно добавления ДТП

Рисунок 5.3 - Заполненное окно добавления ДТП

ЗАКЛЮЧЕНИЕ

В приведенной работе было разработано полнофункциональное клиент - серверное приложение, реализующее прототип ИС для предметной области «ГАИ». В качестве архитектуры для разработанного приложения была выбрана трехуровневая архитектура MVVM. Данная архитектура является предпочтительней других, существующих на сегодняшний день, технологий проектирования приложений в системе WPF.

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

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

В специальной части описаны преимущества использования системы WPF.

СПИСОК ЛИТЕРАТУРЫ

архитектура база данные транспортный происшествие

Различные архитектурные решения [Электронный ресурс]. - 2010. - Режим доступа: http://www.intuit.ru/studies/courses/508/365/lecture/

Введение в системы управления базами данных. Глава 6. Нормальные формы отношений [Электронный ресурс]. - 2009. - Режим доступа: http://citforum.ru/database/dblearn/dblearn06.shtml