Разработка подсистемы «Registration Of Weapons» для регистрации оружия в ОЛРР УВД по г. Ставрополю

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

Актуальность разработки информационной подсистемы для ОЛРР УВД по г. Ставрополю обусловлена тем, что процесс регистрации оружия занимает большие временные затраты.

Целью данного проекта является разработка подсистемы «RegistrationOfWeapons» для регистрации оружия в ОЛРР УВД по г. Ставрополю.

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

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

Во втором разделе описан процесс разработки подсистемы. Проектирование данного продукта осуществляется с помощью современной среды программирования Microsoft Visual Studio 2008 на языке программирования C# с использованием библиотек .Net Framework 4.0. Хранение информации осуществляется с помощью СУБД MS SQL. Использование данных технологий позволяет запускать несколько экземпляров созданного приложения и одновременного доступа к общей БД.

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

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

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

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

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ ОТДЕЛА ЛИЦЕНЗИОННО-РАЗРЕШИТЕЛЬНЫХ РАБОТ УПРАВЛЕНИЯ ВНУТРЕННИХ ДЕЛ ПО Г. СТАВРОПОЛЮ. ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

1.1 Результаты предпроектного обследования отдела лицензионноразрешительных работ управления внутренних дел по г. Ставрополю

1.1.1 Объекты и методы проведения предпроектного обследования

Основными объектами предпроектного обследования являются:

отдел лицензионно-разрешительных работ управления внутренних дел по г. Ставрополю;

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

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

Основными целями выполнения предпроектного обследования ОЛРР УВД по г. Ставрополю являются:

выявление основных параметров предметной области связанных с учетом и регистрацией оружия;

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

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

Характеристики метода проведения обследования ОЛРР УВД по г. Ставрополю приведены в таблице 1.1.

Таблица 1.1 — Методы организации проведения обследования

При выборе методов учитывались следующие критерии [1]:

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

временные, трудовые затраты на получение сведений об отделе.

Характеристика методов сбора материалов обследования, использованных в проекте, представлена в таблице 1.2.

Таблица 1.2 — Характеристика методов сбора материалов обследования

1.1.2 Программа проведения обследования

Программа обследования ОЛРР УВД по г. Ставрополю представлена в таблице 1.3. План-график выполнения работ на стадии сбора материалов обследования представлен в таблице 1.4.

Таблица 1.3 — Программа обследования

Таблица 1.4 — План-график выполнения работ на стадии сбора материалов обследования ОЛРР УВД по г. Ставрополю

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

1.1.3.1 Общая характеристика ОЛРР УВД по г. Ставрополю Полное фирменное наименование фирмы на русском языке: отдел лицензионно-разрешительных работ управления внутренних дел по г. Ставрополю. Сокращенное наименование фирмы: ОЛРР УВД по г. Ставрополю (далее по тексту Отдел).

Отдел лицензионно-разрешительных работ и контролю за частной детективной и охранной деятельностью является структурным подразделением милиции общественной безопасности УВД по г. Ставрополю. Отдел существует в целях организации и контроля за выполнением управления внутренних дел Законов РФ «Об оружии», «О частной детективной и охранной деятельности в РФ», законодательства РФ, приказа МВД РФ от 19.07.2006 года № 447 «Об утверждении Инструкции об организации работы по лицензированию и осуществлению органами внутренних дел контроля за частной детективной и охранной деятельностью на территорию Российской Федерации» и иных нормативных правовых актов МВД РФ, ГУВД СК в сфере оборота гражданского, служебного оружия, частной детективной и охранной деятельности.

Организационно-методическое руководство и контроль за деятельностью Отдела осуществляет ООЛРР ГУВД СК.

Реквизиты Отдела:

ИНН 2 635 130 373;

КПП 263 501 001;

р/счет 40 105 810 600 000 012 288 в ГРКЦ ГУ Банка России по Ставропольскому краю г. Ставрополя;

ОГРН 1 092 635 015 978;

л/с 03211w09500 в Отделение по г. Ставрополю УФК по Ставропольскому краю;

БИК 40 702 001;

юридический адрес: 355 035 г. Ставрополь, ул. Ленина, 421.

Основные виды деятельности Отдела:

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

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

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

контролирует соблюдение гражданами сроков перерегистрации оружия;

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

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

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

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

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

1.1.3.2 Организационная структура Отдела Структура и штаты отдела определяются с учетом установленной МВД России типовой схемы организационной структуры и утверждаются начальником УВД.

Структура управления организации представлена на рисунке 1.1.

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

ежедневно осуществляет практическое руководство служебной деятельностью ОЛРР;

организует и планирует деятельность ОЛРР, контролирует выполнение запланированных мероприятий, ведет аналитическую работу в подразделении;

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

контролирует накопление наблюдательных дел на объект разрешительной системы, постановку на учет детективных и охранных структур, предприятий с особыми уставными задачами, негосударственных образовательных учреждений, магазинов по торговле гражданским и служебным оружием (приказов МВД России № 288−99г., № 447−06г.);

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

ежеквартально обеспечивает и осуществляет контроль за проведением проверок деятельности частных предприятий и служб безопасности по соблюдению Закона РФ «О частной детективной и охранной деятельности в РФ» ;

исполняет иные обязанности, возложенные на него начальником МОБ УВД.

Начальнику отдела подчиняются — заместитель начальника по частной, охранной и детективной деятельности и начальник отделения по контролю за оборотом оружия Отдел имеет в своем составе 8 инспекторов по контролю за недопущением нарушений и соблюдением законодательства, регламентирующего оборот оружия и частной детективной и охранной деятельности.

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

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

Первоочередной задачей при проведении предпроектного обследования является проведение анализа структуры управления ОЛРР УВД по г. Ставрополю и, прежде всего его функциональной структуры.

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

производственную (лицензионно-разрешительную);

обеспечивающую;

управленческую.

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

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

Первоочередной задачей при проведении предпроектного обследования является проведение анализа структуры управления ОЛРР УВД по г. Ставрополю и, прежде всего его функциональной структуры.

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

производственную (лицензионно-разрешительную);

обеспечивающую;

управленческую.

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

Рисунок 1.1 — Схема организационной структуры управления ОЛРР УВД по г. Ставрополю Таблица 1.2 — Функциональные задачи и подзадачи отдела

Таблица 1.3 — Организационно-управленческая модель отдела Организационно-управленческая модель отдела представлена в виде таблицы-матрицы, в которой имеются следующие обозначения: Х — полное участие в процессе, / - частичное участие в процессе, 0 — ответственность за выполнение процесса.

1.1.3.4 Цели функционирования отдела Эффективным инструментом установления целей системы управления является метод «дерева целей», которое состоит из глобальной цели, целей и подцелей. При построении «дерева целей» его проектирование идет по методу «от общего к частному». Прекращение декомпозиции цели на более мелкие прекращается в тот момент, когда дальнейший процесс является нецелесообразным в рамках рассмотрения Главной цели. Правильно построенное дерево целей в дальнейшем легко может быть преобразовано в план-график или диаграмму Ганта.

Схема дерева целей представлена на рисунке 1.2. В таблице 1.4 приведены возможные средства и критерии достижения поставленных целей.

1.1.3.5 Документооборот отдела На сегодняшний день ни одно, даже самое автоматизированное, предприятие не обходится без документов, представленных в бумажном виде. Перечень наиболее распространенных документов в ОЛРР УВД по г. Ставрополю представлен в таблице 1.6

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

Рисунок 1.3 — Схема документооборота ОЛРР УВД по г. Ставрополю Рисунок 1.2 — Дерево целей ОЛРР УВД по г. Ставрополю Таблица 1.4 — Цели отдела и критерии их достижения

Таблица 1.6 — Документооборот ОЛРР УВД по г. Ставрополю

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

Системный блок Celeron D 2.66ГГц /512Мбайт /80Гбайт /FDD /CDRW /Video /Sound /Lan /ATX 250 Вт;

Системный блок Pentium 4 2.4 ГГц /512 Мбайт /320 Гбайт /DVD+CDRW /Video /Sound /Lan /ATX 400 Вт ;

Системный блок Core2Duo E6750 /2048 Мбайт /1 Тбайт +320 Гбайт /DVD+CDRW /Video GF8800GT /Sound /Lan /ATX 580 Вт ;

Системный блок Sempron™ Processor 3000+ /512 Мбайт /160 Гбайт /DVD+CDRW /Video /Sound /Lan /ATX 400 Вт;

Принтер Samsung SCX-4200;

Сканер Samsung SCX-4200.

В качестве программного обеспечения используется следующее:

операционная система — Windows XP;

Microsoft Office Enterprise 2007 (Select edition) Russia;

архиватор WINRAR v3,5;

антивирусные средства: ESET NOD32 Antivirus, Avast Free Antivirus и др. средства.

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

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

Таблица 1.7 — Проблемные ситуации

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

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

Анализ перечисленных проблемных ситуаций показывает, что для их разрешения невозможно использовать готовый программный продукт, так как на рынке лицензионного программного обеспечения отсутствуют программы позволяющие автоматизировать решение перечисленных задач. По этой причине необходимо разработать информационную подсистему, позволяющую автоматизировать учет регистрации оружия. По требованию заказчика (начальника ОЛРР УВД по г. Ставрополю) такую информационную подсистему необходимо реализовать в виде приложения баз данных на платформе Microsoft Windows.

Проведенное выше рассмотрение позволяет перейти к формулировке задач проектирования.

1.2 Формулировка задач проектирования

1.2.1 Общие сведения

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

Проведение данного вида работ осуществляется на основании заказа на выполнение дипломной работы. Согласно данному заказу ОЛРР УВД по г. Ставрополю поручает Северо-Кавказскому государственному техническому университету создание программно-технической продукции.

Заказчик поручает, а исполнитель принимает на себя работу по созданию подсистемы для ОЛРР УВД по г. Ставрополю.

Срок окончания работ по заказу 20 мая 2011 года.

1.2.2 Назначение, цели создания информационной подсистемы

Основной целью разработки подсистемы выступает повышение эффективности работы ОЛРР УВД по г. Ставрополю.

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

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

время обработки поступающей информации уменьшается до минимума;

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

снижается вероятность потери или утраты информации;

снижается вероятность ошибки на уровне ввода данных сотрудниками предприятия;

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

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

1.2.3 Характеристика объекта автоматизации

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

прием;

регистрация;

формирование и печать отчетов.

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

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

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

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

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

регистрация поступивших обращений;

просмотр информации в удобном и наглядном виде;

редактирование информации;

формирование и печать отчетов.

1.2.5 Состав и содержание работ по созданию подсистемы

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

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

разработка основных положений по новой системе;

разработка функциональной структуры и перечня задач;

разработка постановки решения задач для подсистемы;

разработка внемашинной и внутримашинной технологии решения каждой задачи;

уточнение состава периферийной техники;

уточнение состава аппаратной платформы проекта;

разработка плана мероприятий по подготовке к внедрению системы;

окончательное оформление проекта.

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

разработка программного обеспечения для каждой задачи подсистемы;

разработка технологических документов и инструкций;

разработка правовых инструкций;

оформление рабочего проекта.

Наиболее ответственной работой, выполняемой на этом этапе, являются «Кодирование и составление программной документации», в состав которой входят следующие компоненты:

описание программ;

спецификация программ;

тексты программ;

контрольные примеры;

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

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

Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09 — 82 «Система технологической документации. Термины и определения основных понятий», и составляет содержание технологического обеспечения информационной системы.

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

1.2.6 Порядок контроля приемки подсистемы

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

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

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

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

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

1.2.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие

Для ввода подсистемы в действие следует произвести следующие работы:

Установить следующее программное обеспечение:

Microsoft SQL Server 2005 R2 или выше;

NET Framework 4.0.

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

1.2.8 Требование к документированию

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

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

1. Документ «Основные положения по системе» .

2. Документ «Постановка задачи», который включает три составные части:

характеристику задачи;

описание выходной информации;

описание входной информации.

На этапе рабочего проектирования разрабатывается:

технологическая документация, включающая технологические и инструкционные карты;

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

правовые инструкции;

документ «Рабочий проект», в который входят перечисленные на этом этапе документы.

На этапе подготовки объекта к внедрению формируется «Программа проведения опытного внедрения» и издается «Приказ о начале опытного внедрения» .

На этапе «Сдача проекта в промышленную эксплуатацию» используют следующую совокупность документов:

договорная документация;

" Приказ на разработку информационной системы" ;

технико-экономическое обоснование и техническое задание;

" Приказ о начале промышленного внедрения" ;

" Программа проведения испытаний" ;

" Требования к научно-техническому уровню проекта системы" .

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

1.2.9 Источники разработки

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

Информационные материалы на отечественные и зарубежные системы-аналоги не использовались.

При проектировании базы данных, написании исходного кода информационной подсистемы использовалась специальная литература, в частности, по Microsoft SQL 2005 и Visual C#.

Кроме этого, в процессе проектирования применялись различные ГОСТы, например, ГОСТ 3.11.09 — 82 «Система технологической документации. Термины и определения основных понятий» .

Выводы

ОЛРР УВД по г. Ставрополю обладает линейно-функциональной структурой управления.

Определены цели и необходимые для их достижения подцели отдела.

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

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

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

В качестве научно-технической и практической ценности ожидаемых результатов работы выступает повышение экономической эффективности работы ОЛЛР УВД по г. Ставрополю.

2. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ «REGISTRATION OF WEAPONS»

2.1 Обоснование выбора среды разработки подсистемы

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

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

Разработка ведется на языке С#, с использованием технологии .NET Framework. C# - один из языков, предназначенных для написания приложений для архитектуры .NET. C# опирается на богатое наследие в области программирования и происходит от трех языков C, C++ и Java. Язык C# унаследовал синтаксис, ключевые слова и операторы от C, С# позволяет построить и усовершенствовать объектную модель определенную в C++, также как и Java C# поддерживает программирование распределенных систем, использует промежуточный код для достижения переносимости и предлагает средства динамического обнаружения ошибок, обеспечение безопасности и управляемого выполнения программ.

Использование данных технологий позволило получить ряд преимуществ:

Объектно-ориентированное программирование — .Net Fraemwork и C# полностью базируются на объектно-ориентированных принципах, что очень удобно при разработке сложных программ Дизайн — библиотека классов организована с очень понятным интерфейсом.

Независимость от языка — языки С#, J#, C++ обладают возможность взаимодействия, так как компилируются в общий язык — Intermedia Language.

Доступ к данным — компоненты ADO.NET предоставляют эффективный доступ к базам данным. Встроена поддержка XML.

Разделение кода — .Net заменил способ разделения кода между приложениями, введя концепцию сборки, заменившая .DLL

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

Благодаря программе DreamSpark, предоставляющей бесплатный для студентов и аспирантов доступ к полным лицензионным версиям инструментов для разработки и дизайна от компании Microsoft, стоимость разработки, в части использования средств разработки, была нулевой.

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

В качестве СУБД для базы данных разрабатываемой подсистемы была выбрана современная СУБД — SQL Server 2005 R2 Express Edition. Выбор данного средства обусловлен следующими сведениями об этой системе:

SQL Server 2005 направлен на то, чтобы сделать управление данными самонастраивающимся, самоорганизующимся и самообслуживающимся механизмом — для реализации этих возможностей были созданы технологии SQL Server Always On. Это позволит уменьшить до нуля время нахождения сервера в нерабочем состоянии.

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

Для повышения эффективности администрирования в SQL Server были включены библиотеки Declarative Management Framework, позволяющие распределять полномочия для баз данных или отдельных таблиц. Были улучшены методы компрессии данных. SQL Server Katmai поддерживает набор библиотек ADO.NET Entity Framework и средства оповещения, репликации и определения данных.

В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

Microsoft SQL Server Express является бесплатно распространяемой версией SQL Server. Данная версия имеет некоторые технические ограничения. Такие ограничения делают её непригодной для развертывания больших баз данных, но она вполне годится для ведения программных комплексов в масштабах небольшой компании. Содержит полноценную поддержку новых типов данных, в том числе XML-спецификации. Фактически, это полноценный MS SQL Server, включая все его компоненты программирования, поддержку национальных алфавитов и Unicode. Поэтому используется в приложениях, при проектировании или для самостоятельного изучения. Нет никаких препятствий для дальнейшего развёртывания накопленной базы данных на MS SQL Server неэкспрессной версии, стоимость разработки в части использования средств разработки была нулевой. Таким образом, используемые технологии позволяют достичь высоких результатов, не требуя никаких денежных вливаний ни на одной из стадий разработки, тестирования, внедрения и эксплуатации разрабатываемой подсистемы.

2.2 Создание логической и физической модели базы данных информационной подсистемы

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

Таблица 2.1 — Перечень сущностей

2.2.2 Определение атрибутов сущностей базы данных информационной подсистемы

Атрибут является характеристикой сущности, значимой для рассматриваемой предметной области. Рассмотренные выше сущности имеют следующие атрибуты, представленные в таблице 2.2.

Таблица 2.2 — Перечень атрибутов

2.2.3 Инфологическое проектирование базы данных

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

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

2.2.3.1 Определение связей между сущностями базы данных информационной подсистемы При построении инфологических моделей чаще всего используется язык ER-диаграмм (от англ. Entity-Relationship, т. е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации — помеченными ромбами или шестиугольниками, атрибуты — помеченными овалами, а связи между ними — ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово «много») и необходимое пояснение. Отношения M: N возникают между двумя таблицами в том случае, если:

одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

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

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

Инфологическая модель данных приведена на рисунке 2.1.

Рисунок 2.1 — Инфологическая модель данных Классификация связей приведена в таблице 2.3.

Таблица 2.2 — Классификация связей

2.2.3.2 Функциональные зависимости между атрибутами

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

Таблица 2.3 — Функциональные зависимости между атрибутами сущности «Owner»

Таблица 2.4 — Функциональные зависимости между атрибутами сущности «Weapons»

Таблица 2.5 — Функциональные зависимости между атрибутами сущности «Journal»

Таблица 2.6 — Функциональные зависимости между атрибутами сущности «ReferenceDocuments»

Таблица 2.7 — Функциональные зависимости между атрибутами сущности «Possession»

Таблица 2.8 — Функциональные зависимости между атрибутами сущности «TypeWeapons»

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

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

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

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

В таблице 2.12 представлены ключи, составленные для имеющихся сущностей.

Таблица 2.12 — Первичные ключи

2.2.4 Разработка даталогической модели Даталогическая модель является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой мы проектируем базу данных. Задача логического проектирования базы данных состоит в разработке ее «логической» структуры в соответствии с инфологической моделью предметной области. Решение этой задачи зависит от того, какую модель данных поддерживает выбранная СУБД. Выбранная СУБД поддерживает реляционную модель данных. В соответствии с реляционной моделью данных база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры. Столбцы таблицы называются атрибутами, строки — кортежами. Множество значений, которые может принимать атрибут, называется доменом. Тип сущности здесь интерпретируется отношением или таблицей. Экземпляр сущности интерпретируется кортежем, а атрибут интерпретируется столбцом таблицы. Опишем таблицы, указав для каждого поля таблицы размер поля и тип.

Таблица 2.13 — Состав таблицы «Owner»

Таблица 2.14 — Состав таблицы «Weapons»

Таблица 2.15 — Состав таблицы «Journal»

Таблица 2.16 — Состав таблицы «ReferenceDocuments»

Таблица 2.17 — Состав таблицы «Possession»

Таблица 2.18 — Состав таблицы «TypeWeapons»

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

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

Используя набор команд: «Файл > Создать > Проект > Приложение WindowsForms» создаем новый проект.

2.3.1 Разработка интерфейса формы с именем AddJournal

Для создания новой формы необходимо, открыв проект, выполнить следующий набор команд «Проект > Добавить форму Windows» .

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

dataGridView1 — таблица, в которой отображается записи о владельцах, добавляемые в журнал;

dataGridView2 — таблица, в которой отображается записи об оружии, добавляемые в журнал;

шесть элементов textBox — поля для ввода текста. В данном случае используются как строки поиска;

comboBox1 — поле с выпадающим списком. Используется для фильтрации видов документов;

comboBox2 — поле с выпадающим списком. Используется для фильтрации фамилий;

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

пять элементов label — текст для оформления формы.

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

Разрабатываемая форма примет вид, показанный на рисунке 2.2.

В общем итоге в приложении было разработано 11 форм.

2.3.2 Организация обмена данными

Language Integrated Query (LINQ) — проект Microsoft по добавлению синтаксиса языка запросов, напоминающего SQL, в языки программирования платформы .NET Framework. LINQ выпущен вместе с Visual Studio 2008 в конце ноября 2007 года.

LINQ представляет собой набор функций Visual Studio 2008, расширяющих мощные возможности запроса в синтаксисе языка C# и Visual Basic. LINQ представляет стандартные шаблоны для создания запросов и обновления данных; технология может быть расширена для поддержки потенциально любого типа хранилища данных. Visual Studio 2008 включает сборки поставщиков LINQ, позволяющие использовать LINQ с коллекциями платформы .NET Framework, базами данных SQL Server, наборами данных ADO.NET и XML-документами.

LINQ представляет собой набор расширений языка, поддерживающий формирование запросов данных способом, безопасным по типам. Запрашиваемые данные могут быть представлены в форме XML (запросы LINQ к XML), баз данных (ADO.NET с поддержкой LINQ, куда входят LINQ к SQL, LINQ к наборам данных и LINQ к экземплярам), объектов (LINQ к объектам) и т. д. Отображение реляционных данных на объектную модель всегда было одной из наиболее сложных проблем при построении объектно-ориентированных систем. В большинстве случаев, запросы к базе данных пишутся на языке SQL, а их результат конвертируется в объекты.

LINQ to SQL — простая, но достаточно мощная система объектно-реляционного отображения (ORM). По сравнению с традиционной технологией ADO.NET применение LINQ to SQL позволяет значительно упростить код, снизить вероятность ошибок и сократить время разработки проекта. Для начала необходимо добавить файл LINQ to SQL classes. Для этого выполним следующее Проект > Добавить компонент. После чего высветится окно, в котором нужно выбрать требуемый файл.

Затем в окне Server Explorer следует развернуть дерево базы данных RegistrationOfWeapons и перетащить нужные таблицы и хранимые процедуры в окно файла отображения на панель методов.

Выводы

В качестве среды разработки программного средства была выбрана среда Microsoft Visual Studio 2008. Она позволяет достичь высочайшей производительности приложений. Благодаря программе DreamSpark, доступ к полной лицензионной версии среды разработи бесплатен.