Информационная система ГАИ

Оглавление

Введение 2

2. ЭТАП ПРОЕКТИРОВАНИЯ 14

Понятие интерфейса 16

Разработка  интерфейса программы  «Информационная  система ГАИ» 16

Заключение 20

 

     Введение

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

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

     Угон  либо исчезновение виновника ДТП  с места происшествия требует  оперативного вмешательства всех постов ГАИ и патрульных машин. Для информации о разыскиваемой машине ее данные (включая номера двигателя и кузова) извлекаются из базы зарегистрированных номеров и передаются по рации всем постам. Ведение статистики угонов, ее анализ и опубликование результатов в СМИ поможет снизить количество угонов, а хозяевам машин принять необходимые меры (самые угоняемые марки, самый популярный способ вскрытия, самые надежные сигнализации и т.п.).

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

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

 

     

     1. Этапы разработки программы «Информационная система ГАИ»

1.1 Техническое задание

     Современный мир информационных технологий трудно представить себе без возможности  обработки больших объёмов информации. Такие объёмы информации удобно обрабатывать с помощью баз данных. Практически  все системы в той или иной степени связаны с долговременным хранением и обработкой информации. Фактически, информация становится фактором, определяющим эффективность любой  сферы деятельности. Увеличились  информационные потоки и повысились требования к скорости обработки  данных. Большинство операций не может  быть выполнено вручную. Любые административные решения требуют более чёткой и точной оценки текущей ситуации и возможных перспектив её изменения.

     В данном курсовом проекте необходимо разработать «Информационную систему ГАИ». Она должна обеспечивать просмотр, обработку, ввод новых данных, поиск данных по определённому критерию. Целью создания данной базы данных является:

  1. повышение производительности работы;
  2. более надёжное хранение информации.

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

     Назначение  разработки

     Информационная  система ГАИ предназначена для выделения и учета номерных знаков на автотранспорт, учета и анализа ДТП (дорожно-транспортного происшествия), угона либо исчезновения виновника ДТП с места происшествия.

     Требования  к программе 

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

    • Регистрацию автотранспортных средств, при совершении сделки купли-продажи;

     Исходные  данные:

    • Перечень транспорта;
    • Номерные знаки на автотранспорт;
    • Данные владельца автотранспорта;
    • Справочник свободных номеров;.

     Результат:

    • Перечень и общее число владельцев, которым выделены номера либо с указанной серией, либо за указанный период;
    • Сведения о владельце автотранспортного средства по государственному номеру автомашины;
    • «Досье» на автомобиль по государственному номеру - номера двигателя, кузова, шасси, участвовал ли в ДТП, прошел ли техосмотр;
    • Список машин, отданных в розыск, будь то скрывшиеся с места ДТП или угнанные;

     Требования  к надежности

      1. Предусмотреть контроль вводимой информации.
      2. Обеспечить блокировку некорректных действий пользователя.
      3. Обеспечить ценность хранимой информации.

     Требования  к составу и параметрам технических  средств

     Минимальные требования к компьютеру и П.О:

     Windows 2000 XP Professional

     Servise Pack 1, 2

     Windows XP Home Edition

     Servise Pack 1, 2

     Windows Vista (32-64 разрядная), Windows Seven (32-64 разрядная)

     Pentium 3, 866 Гц, 512 Мб, не менее 800 Мб на жестком диске.

     Программная система должна включать справочную информацию.

     В состав сопровождающей документации необходимо включить:

     1. Руководство системного программиста.

     2. Руководство пользователя.

     3. Пояснительная записка.

     Технико-экономические  показатели.

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

     Стадии  и этапы разработки

  1. Постановка задачи.
  2. Анализ предметной области.
  3. Разработка алгоритма
  4. Разработка интерфейса.
  5. Кодирование.
  6. Тестирование.
  7. Оформление документации.
  8. Порядок контроля и приемки

 

     

1.2. Функциональную модель

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

     Функциональная  модель состоит из набора диаграмм - декомпозиций функции верхнего уровня. Далее  представлена IDEF0 для автоматизации регистрации транспортных средств.

     После чего переходим к декомпозиции.

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

     Принять заявление- рассмотреть заявление, внести в БД, проверить сведения из документов и выдать документы.

     Осмотреть ТС- контролировать подлинность номеров  и принять решение о регистрации  или отказе.

     Оформить  регистрационные документы - проверка документов и подписание документов. В свою очередь проверка документов делится на - проверить уплату пошлин. проверить сведения о ТС и владельце  и автоматически проверить регистрационные  действия.

     Выдать  документы и регистрационные  знаки не на что не делится.  
 

1.3. Диаграмма прецедентов

     После этого переходим к созданию диаграммы прецедентов или Use Case. Любые системы проектируются с учетом того, что в процессе работы они будут использоваться людьми или взаимодействовать с другими системами. Сущности, с которыми в процессе работы взаимодействует система называются "Актерами". Причем каждый "Актер" ожидает что система будет вести себя строго определенным предсказуемым образом . Актером может быть человек, система или подсистема. В моем случае актером является Гос.Инспектор. Прецедент - это описание отдельного аспекта поведения системы с точки зрения пользователя. В моем случае это "Заполнять заявление на регистрацию", "Заполнять заявление на осмотр", "Присвоить Гос.Номер", "Заполнить свидетельство о регистрации" и "Заполнить ПТС". Диаграмма прецедентов по сути демонстрирует сценарий поведения системы. Сценарий- это конкретная последовательность действий илюстрирующая поведение. Прецедент рождается из требований к системе. Однако прецеденты нам говорят только о том, что делает система в то время как сценарий подводит к мысли о том, как система это делает.

1.4. Типичный ход событий

           Типичный ход событий  – обеспечивает наглядное представление  общения с системой.

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

     Действия       Отклик  системы
             
             
             
             

1.5. Концептуальную модель

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

     методы.

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

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

     После этого в программном продукте Microsoft Visio создаем концептуальную модель классов с атрибутами. Здесь можно увидеть как классы связанны друг с другом, какие атрибуты являются ключевыми, какими связями связанны друг с другом. В моем курсовом проекте есть 3 вида связи- "один к одному", "один ко многому" и "включение". 

     Список  категорий концептуальных классов

     Категория концептуальных классов      Пример 
     1. Физ. лица , материальные объекты      Владелец  ТС, ТС
     2. Документы       Заявления на регистрацию и осмотр, Договор купли-продажи, Квитанция на оплату, ПТС, Страховка, Гос .номер.
     3. Роли людей      Полиция
     4. Правила и политики      Приказ, Законодательство РФ
     5. Контейнер для других объектов      БД  номеров, Картотека дел
     6. Абстрактное понятие      Счетчик

 
 

1.6. Диаграмма последовательностей

     Диаграмма последовательности – одна из диаграмм взаимодействия. На диаграмме последовательностей иллюстрируются события, инициированные в системе исполнителями.

     Сценарий присвоения гос.номера транспортному средству

     1. Гос. инспектор из таблицы всех номеров делает запрос на свободные номера

     2. Система обрабатывает запрос, и  выдает все имеющиеся свободные  номера.

     3. Гос.инспектор выбирает из таблицы номер и присваивает его ТС.

     4. База данных обрабатывает операцию  и сохраняет изменения.

     

     Сценарий Входа/выхода из системы:

     1. Гос.инспектор открывает ПО

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

     3. Гос.инспектор выбирает выход из системы.

     4. система выдает Фурму выхода  и ожидает реакции пользователя.

     5. Пользователь выбирает выход.

     6. программа закрывается. 

     

 

     

     2. ЭТАП ПРОЕКТИРОВАНИЯ

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

2.1. Системные операции

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

     Составление описаний:

     1. Определите системные операции  из диаграмм последовательностей.

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

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

     3. При описании постусловий используйте  следующие категории.

     ·  Создание и удаление экземпляра

     ·  Модификация атрибута

     ·  Формирование и разрыв ассоциации

           Предусловия (preconditions) – это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Выполнение этих условий не проверяется в рамках логики выполнения данной операции, а предполагается, что они истинны.

           Результаты, или постусловия (postconditions), описывают, какие условия должны выполняться в случае успешного завершения сценария. Эти результаты должны удовлетворять интересам всех заинтересованных лиц. Выделение постусловий - наиболее важная часть описания системных операций.

     Ниже  в таблице представлены описания системной операций.

     Таблица

     Описания системной операции

     Операция        
     Ссылки        
     Предусловия       
     Постусловия       
 

2.2. Описание прецедентов

           Реальный прецедент  описывает конкретное проектное  решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов.

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

     Описания  прецедента

     Таблица

     Название  прецедента       
     Исполнитель       
     Цель       
     Описание       
     Тип       
     Ссылки        

2.3. Разработка интерфейса программы

     Понятие интерфейса

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

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

      Разработка интерфейса программы «Информационная система ГАИ»

     При разработке интерфейса программы «Информационная  система ГАИ» были учтены следующие показатели:

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

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

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

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

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

 

     

2.4. Диаграмма кооперации

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

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

     

       

       

 
 

2.5. Диаграмма состояний

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

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

     Событие (event) – это значимое или заслуживающее внимания происшествие.

     Состояние (state) – условие, характеризующее объект в некоторый момент между двумя состояниями.

     Переход (transition) – это такое отношение между двумя состояниями, которые указывает на переход объекта из одного состояния в другое при выполнении некоторого события.

Диаграмма классов

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

 

 

Заключение

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

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

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

 

     Литература

  1. Технологии разработки программного обеспечения: Учебник / С. Орлов. – СПб.: Питер, 2002. – 464 с.
  2. Благодатских В. А. и др. Стандартизация разработки программных средств: Учеб. пособие / Благодатских В. А., Волнин В. А., Поскакалов К. Ф.; Под ред. Разумова О. С. – М.: Финансы и статистика, 2003. -288 с.
  3. Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. 352 с.
  4. Рудаков А.В., «Технология разработки программных продуктов», Москва 2005г.;
  5. Макарова Н. В.,«Информатика», Санкт-Петербург, Издательство «ПИТЕР», 2002 г.;
Информационная система ГАИ