Программные средства информационной системы учета и анализа дорожнотранспортных происшествий
 Скачать 2.76 Mb.
|
|
Построение исходной концептуальной модели данных предметной области Концептуальное проектирование заключается в разработке концептуальной модели предметной области. Концептуальная модель представляет собой множество сущностей и связи между ними. Выделим типы сущностей предметной области, отношения между ними и их атрибуты. Полученные типы сущностей предметной области, отношения между ними и их атрибуты представлены в приложении Г. Построим концептуальную модель предметной области в нотации IDEF1X на основании выделенных сущностей и их связей (рисунок 4). Рисунок 4 – Концептуальная модель системы Построенная концептуальная модель системы соответствует нотации IDEF1X. 17 Анализ требований Требование можно определить, как «подробное описание того, что должно быть реализовано». Существует два основных типа требований: функциональные требования – какое поведение должна предлагать система; нефункциональные требования – особое свойство или ограничение, накладываемое на систему [10]. Функциональные требования Функциональные требования хорошо иллюстрирует диаграмма вариантов использования. Диаграмма вариантов использования для данной системы представлена на рисунке 5. Рисунок 5 – Диаграмма вариантов использования 18 Для наглядного представления поведения вариантов использования удобно применять диаграмму деятельности. Диаграмма деятельности для варианта «Зарегистрировать новое ДТП» представлена на рисунке 6. Рисунок 6 – Диаграмма деятельности для варианта «Зарегистрировать новое ДТП» Для рассмотрения взаимодействия между компонентами системы была спроектирована диаграмма последовательности для варианта «Зарегистрировать новое ДТП» (рисунок 7). 19 Рисунок 7 – Диаграмма последовательности для варианта «Зарегистрировать новое ДТП» На данной диаграмме последовательности (смотри рисунок 7) изображены 5 компонентов системы: пользователь, интерфейс пользователя, система, модель базы данных и СУБД. 20 1 Проектирование программных средств 3 Базовая архитектура системы Проектируемая информационная система имеет двухуровневую архитектуру клиент-сервер. Первый компонент представляет собой клиентское приложение на рабочих станциях пользователей. Второй компонент представляет собой сервер базы данных, который располагается на отдельной станции и хранит базу данных, содержащую информацию о транспортных средствах, водителях, дорожно-транспортных происшествиях. Пользователь регистрирует новое ДТП на своей рабочей станции в клиентском приложении. Клиентское приложение, в свою очередь, отправляет данные на сервер базы данных. Сервер базы данных сохраняет полученную информацию. 4 Логическая модель базы данных Логическая модель строится на основе концептуальной модели с учетом выбранной модели данных, но не учитывая особенности целевой СУБД. Устранение избыточности модели производится, как правило, за счет декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты. Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормальная форма – свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных [11]. Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, 21 то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ. Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме, и каждый не ключевой атрибут зависит от ее потенциального ключа. Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости не ключевых атрибутов от ключевых. Построим логическую модель базы данных в нотации IDEF1X при помощи case-средства ERwin Data Modeler. Логическая модель представлена на рисунке 8. card Код карты Код вида ДТП (FK) Дата Время Месторасположение Описание Дорожное покрытие Освещение member Код участника Код ТС (FK) Код водителя (FK) Код карты (FK) ФИО Дата рождения Номер паспорта Статус type_dtp Код вида ДТП Наименование ts Код ТС Регистрационный номер Дата выпуска Цвет кузова Код кузова Код типа ТС (FK) Код марки (FK) driver Код водителя ФИО Адрес Номер паспорта Дата рождения Номер ВУ Дата получения ВУ mark Код марки Наименование type_ts Код типа ТС Наименование Рисунок 8 – Логическая модель базы данных 22 Разработанная логическая модель базы данных не содержит транзитивных зависимостей. Таким образом можно сделать вывод, что модель соответствует третьей нормальной форме. 5 Пользовательский интерфейс клиентского приложения Исходя из диаграммы вариантов использования и этапа анализа требований был спроектирован простой и интуитивно понятный графический пользовательский интерфейс. На рисунке 9 представлен графический интерфейс главного окна приложения. 1 – кнопка открытия окна для регистрации нового ДТП; 2 – кнопка для удаления ранее зарегистрированного ДТП; 3 – кнопка открытия окна с информацией о ДТП; 4 – таблица, показывающая список зарегистрированных ДТП. Рисунок 9 – Графический интерфейс главного окна приложения Графический интерфейс окна регистрации нового ДТП представлен на рисунке 10. 23 1 – раскрывающийся список для выбора типа ДТП; 2 – элемент «Календарь» для выбора даты регистрации ДТП; 3 – текстовые поля для ввода информации о ДТП; 4 – кнопка для фиксации информации; 5 – кнопка для отмены регистрации. Рисунок 10 – Графический интерфейс окна регистрации нового ДТП Графический интерфейс окна редактирования участников ДТП представлен на рисунке 11. 24 1 – кнопка для открытия окна добавления водителя с ВУ; 2 – кнопка для открытия окна добавления водителя без ВУ; 3 – кнопка для открытия окна добавления пешехода; 4 – кнопка для удаления выбранного участника ДТП; 5 – таблица для отображения текущих участников ДТП; 6 – кнопка для завершения регистрации ДТП; 7 – кнопка для отмены текущей операции. Рисунок 11 – Графический интерфейс окна редактирование участников ДТП Графический интерфейс окна добавления водителя с ВУ представлен на рисунке 12. 25 1 – текстовое поле для указания паспорта участника; 2 – кнопка поиска водителя по указанному паспорту; 3 – таблица со списком водителей; 4 – таблица со списком ТС, имеющихся в базе на данный момент; 5 – текстовое поле для указания регистрационного номера ТС; 6 – кнопка поиска ТС по указанному регистрационному номеру; 7 – кнопка фиксации нового участника ДТП; 8 – текстовое поле для указания статуса участника ДТП; 9 – кнопка для отмены текущей операции. Рисунок 12 – Графический интерфейс окна добавления водителя с ВУ Графический интерфейс окна добавления водителя без ВУ представлен на рисунке 13. 26 1 – текстовое поле для указания регистрационного номера ТС; 2 – таблица со списком ТС; 3 – текстовое поле для указания ФИО участника; 4 – поле даты для указания даты рождения участника; 5 – текстовое поле для указания статуса участника; 6 – кнопка для подтверждения добавления участника в БД; 7 – кнопка для поиска ТС по указанному регистрационному номеру; 8 – числовое поле для указания номера паспорта участника; 9 – кнопка для отмены текущей операции. Рисунок 13 – Графический интерфейс окна добавления водителя без ВУ Графический интерфейс окна добавления пешехода представлен на рисунке 14. 27 1 – текстовое поле для указания ФИО пешехода; 2 – числовое поле для указания номера паспорта пешехода; 3 – поле даты для указания даты рождения пешехода; 4 – текстовое поле для указания статуса виновности пешехода; 5 – кнопка для подтверждения добавления; 6 – кнопка для отмены текущей операции. Рисунок 14 – Графический интерфейс окна добавления пешехода Спроектированный графический пользовательский интерфейс является простым, удобным и интуитивно понятным. 6 Проектирование программных средств В соответствии с моделью предметной области были спроектированы следующие классы, представленные на диаграмме классов (рисунок 15). 28 Рисунок 15 – Диаграмма классов 29 На диаграмме классов представлены 17 классов-сущностей. Краткое описание классов приведено ниже: GeneralForm – класс-форма, реализующая функцию просмотра списка карточек о дорожно-транспортных происшествиях. ShowCard – класс-форма, реализующая функцию подробного просмотра карточки ДТП. AddCard – класс-форма, реализующая функцию регистрации нового ДТП. Members – класс-форма, реализующая функцию просмотра участников ДТП. AddMember1 – класс-форма, реализующая функцию добавления водителя с ВУ. AddMember2 – класс-форма, реализующая функцию добавления водителя без ВУ. AddMember3 – класс-форма, реализующая функцию добавления пешехода. DataBaseEntities – класс, который описывает взаимосвязь с базой данной, а также функции и хранимые процедуры. Member, type_ts, driver, card, viewDriver, type_dtp, ts, viewCard, viewTs – классы технологии Entity Framework, которые описывают таблицы и представления базы данных. 7 Планирование разработки и оценка бюджета В ходе планирования проекта было выделено 16 задач. Список задач проекта, их виды, длительность и предшественники приведены в таблице 2. 30 Таблица 2 – Задачи проекта № Название Вид Задачи Предшественники Длительнос ть 1 Начало проекта Веха - - 2 Анализ предметной области Фаза - - 3 Просмотр рынка информационных систем Задача - 4 4 Сбор информации о существующих информационных системах Задача 3 6 5 Анализ требований Фаза - - 6 Анализ функциональных требований Задача 4 12 7 Анализ используемых технологий Задача 6 8 8 Проектирование Фаза - - 9 Проектирование базовой архитектуры Задача 6;7 4 10 Проектирование логической модели базы данных Задача 6 3 11 Проектирование интерфейса пользователя Задача 6;7 14 12 Проектирование программных средств Задача 7;11 16 13 Реализация Фаза - - 14 Реализация физической модели базы данных Задача 10 4 15 Реализация серверной части приложения Задача 14 5 16 Реализация клиентской части приложения Задача 9;11;12;14 22 17 Тестирование Фаза - - 18 Функциональное тестирование Задача 15;16 14 19 Модульное тестирование Задача 15;16 7 20 Завершение проекта Фаза - - 21 Оформление документации Задача 18;19 15 22 Конец проекта Веха - - В MS Project 2013 создадим проект с начальной датой 01.12.16. Занесем выше перечисленные задачи в созданный проект. Выделим необходимые ресурсы для выполнения каждой из задач данного проекта. Ресурсы и затраты представлены в таблице 3. 31 Таблица 3 – Ресурсы проекта Название ресурса Тип Затраты Затраты на исп. Таблица норм Станд. Ставка Ставка сверхур. Программист 1 Т А 20000 р./мес 200 р./ч - Программист 2 Т А 18000 р./мес 180 р./ч - Аналитик Т А 19000 р./мес 190 р./ч - Тестировщик Т А 16000 р./мес 160 р./ч - Компьютер М А 20000 р. - Принтер М А 5000 р. - Бумага М А 200 р. - Интернет З - Распределение ресурсов по задачам представлено в таблице 4. Таблица 4 – Распределение ресурсов по задачам Название Ресурс Единицы (затраты) Таблица норм затрат Начало проекта Компьютер 4 А Просмотр рынка информационных систем Аналитик, Интернет 100 А 250 Сбор информации о существующих информационных системах Аналитик, Интернет 100 А 350 Анализ функциональных требований Аналитик, Программист 1 100 100 А А Анализ используемых технологий Программист 1, Аналитик 100 30 А А Проектирование базовой архитектуры Программист 1 100 А Проектирование логической модели базы данных Программист 2 50 А Проектирование интерфейса пользователя Программист 2 50 А Проектирование программных средств Программист 1 100 А Реализация физической модели базы данных Программист 2 50 А Реализация серверной части приложения Программист 2 50 А Реализация клиентской части приложения Программист 1, Программист 2 100 100 А А Функциональное тестирование Тестировщик, Программист 1 50 100 А А Модульное тестирование Тестировщик, Программист 2 50 100 А А Оформление документации Программист 1, Тестировщик, Принтер, Бумага 100 100 1 1 А А А А 32 Занесем выше перечисленные ресурсы в проект. Результаты представлены на рисунке 16. Рисунок 16 – Ресурсы проекта Далее закрепим за задачами соответствующие ресурсы. После, MS Project 2013 предложит наглядную иллюстрацию календарного плана в виде диаграммы Ганта. Полученная диаграмма Ганта приведена на рисунке 17. Рисунок 17 – Диаграмма Ганта Сетевой график данного проекта представлен на рисунке 18. 33 Рисунок 18 – Сетевой график Графики загрузки трудовых ресурсов программиста 1, программиста 2, аналитика и тестировщика представлены на рисунках 19 – 22 соответственно. Рисунок 19 – График загрузки программиста 1 34 Как видно из графика загрузки, первый программист полностью загружен, за исключением выделенных выходных дней. Рисунок 20 – График загрузки программиста 2 Как видно из графика загрузки, второй программист загружен частично за счет полной загрузки первого программиста. 35 Рисунок 21 – График загрузки аналитика Как видно из графика загрузки, аналитик частично загружен только первом этапе проекта, так как он занимается непосредственно анализом. 36 Рисунок 22 – График загрузки тестировщика Как видно из графика загрузки, тестировщик загружен только на этапе тестирования, так как он занимается непосредственно тестированием ПО. Отчет по проекту представлен на рисунке 23. В отчете указана дата начала и окончания работ, длительность в днях, общие затраты, а также таблица затрат проекта. 37 Рисунок 23 – Сводка по проекту На рисунке 23 видно, что длительность выполнения проекта составила 118 дней, а его бюджет составил 168 352 рубля. 38 2 Реализация программных средств 8 Физическая модель базы данных Физическая модель строится на основе логической модели данных и учитывает особенности целевой СУБД. В качестве СУБД был выбран продукт MS SQL Server 2012. При помощи case-средства ERWin Data Modeler была разработана физическая модель, представленная на рисунке 24. card id_card id_type (FK) date_card time_card place info road light member id_member id_ts (FK) id_driver (FK) id_card (FK) fio_member date_r pasport_member status type_dtp id_type name_type ts id_ts regnum date_out colour numkuz id_type_ts (FK) id_mark (FK) driver id_driver fio_driver adress pasport_driver date_r num_vu date_vu mark id_mark name type_ts id_type_ts name_type Рисунок 24 – Физическая модель базы данных Сгенерированный скрипт DDL в ERWin Data Modeler (приложение Д) был выполнен в СУБД MS SQL Server 2012. 39 9 Серверная часть приложения В ходе разработки программных средств информационной системы учета дорожно-транспортных происшествий было принято решение описать логику приложения для работы с базой данных в серверной части приложения. Серверная часть представляет собой базу данных, которая включает в себя таблицы, представления, хранимые процедуры и триггеры. 9.1 Хранимые процедуры и представления На стороне серверной части приложения были реализованы представления и хранимые процедуры, представленные ниже. Для просмотра списка ДТП на главной странице приложения было реализовано представление списка карточек ДТП, представленное в листинге 1. Листинг 1 – Представление списка карточек ДТП SELECT a.id_card, b.name_type, a.date_card, a.time_card, a.place, a.road, a.light FROM dbo.card a INNER JOIN dbo.type_dtp b ON a.id_type=b.id_type Для просмотра информации о водителях было реализовано представление списка водителей, представленное в листинге 2. Листинг 2 – Представление списка водителей SELECT fio_driver, adress, pasport_driver, date_r, num_vu, date_vu FROM dbo.driver Для просмотра информации о ТС было реализовано представление списка ТС, представленное в листинге 3. Листинг 3 – Представление списка ТС SELECT b.name, c.name_type, a.regnum, a.date_out, a.colour, a.numkuz FROM dbo.ts a INNER JOIN dbo.mark b ON a.id_mark = b.id_mark INNER JOIN dbo.type_ts c ON a.id_type_ts = c.id_type_ts 40 Для проверки и фиксации информации в БД о новом ДТП была реализована хранимая процедура, представленное в листинге 4. Листинг 4 – Хранимая процедура добавления новой карточки ДТП Create Procedure [dbo].[AddNewCardHP] @type_name varchar(40),@date date, @time varchar(30),@place varchar(100),@road varchar(100), @light varchar(50),@info varchar(255), @id_card int OUTPUT AS BEGIN Declare @id_type int IF((@type_name is null)or(@date='')or(@time='')or(@place='')or(@road='')or(@light='' )or (@info is null)) return -1; ELSE BEGIN Select @id_type=id_type From type_dtp Where name_type=@type_name; Select @id_card=MAX(id_card)+1 From card; BEGIN TRANSACTION INSERT INTO card(id_card,id_type,date_card,time_card,place,road,light,info) VALUES (@id_card,@id_type,@date,@time,@place,@road,@light,@info); IF (@@ERROR<>0) Begin ROLLBACK TRANSACTION; SET @id_card = -1; end COMMIT TRANSACTION END END Для проверки и фиксации информации в БД о новом участнике ДТП была реализована хранимая процедура, представленное в листинге 5. Листинг 5 – Хранимая процедура добавления нового участника ДТП Create Procedure [dbo].[AddNewMemberHP] (@id_card int,@regnum varchar(100),@fio varchar(100),@date_r date,@pasport int,@status varchar(50)) AS BEGIN 41 Declare @id_member int, @id_ts int, @id_driver int IF((@id_card is null)or(@fio='')or(@pasport='')or(@pasport is null)or(@regnum is null)or(@regnum='')or(@status is null)or(@status='')) return -1; ELSE BEGIN Select @id_member=MAX(id_member)+1 From member; BEGIN TRANSACTION IF (@regnum='0') INSERT INTO member(id_member,id_card,fio_member,date_r,pasport_member,status) VALUES (@id_member,@id_card,@fio,@date_r,@pasport,@status); ELSE BEGIN Select @id_ts=id_ts From ts Where regnum=@regnum; Select @id_driver=id_driver From driver Where pasport_driver=@pasport; INSERT INTO member(id_member,id_card,id_ts,id_driver,fio_member,date_r,pasport _member,status) VALUES (@id_member,@id_card,@id_ts,@id_driver,@fio,@date_r,@pasport,@stat us); END IF (@@ERROR<>0) Begin ROLLBACK TRANSACTION; return -1; end COMMIT TRANSACTION END END |