Разработка автоматизированного рабочего места сотрудника оперативного учета бюро регистрации несчастных случаев по Санкт-Петербургу и Ленинградской области

Любой объект предметной области обладает свойствами, часть из которых выделяется как характеристические - значимые с точки зрения прикладной задачи. При этом, например, в процессе анализа обычно выделяются классы - совокупность объектов, обладающих одинаковым набором свойств, задаваемых в виде наборов атрибутов (значения атрибутов для объектов одного класса, естественно, могут различаться). Соответственно, на уровне представления предметной области (т.е. ее концептуальной модели) объекту, рассматриваемому как понятие (объект в сознании человека), соответствует понятие сущность; объекту как части материального мира (и существующему независимо от сознания человека) соответствует понятие экземпляр сущности; классу объектов соответствует понятие тип сущности.

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

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

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра.

Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности - сильной по отношению к ней.

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

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

Значения свойств могут быть постоянными - статистическими или динамическими, т.е. меняться со временем.

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

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

Связи. Кроме связи между объектом и его свойствами, концептуальная модель отражает связи между объектами разных классов. Связь определяется как «ассоциация, объединяющая несколько сущностей». Эта ассоциация всегда может существовать между разными сущностями или между сущностью и ею же самой (рекурсивная связь).

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

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

Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае - неполным (или необязательным).

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

Описание атрибутов сущностей

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

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

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения. Разработка логической модели данных в BPwin основывается на понятии сущностей и связей. Применительно к БД сущности представляют собой таблицы будущей БД, а связи определяют связи между создаваемыми сущностями (таблицами). Сущности наполняются атрибутами, которые соответствуют полям таблицы будущей БД. Далее указываются первичные и внешние ключи, и проводится нормализация БД, однако имеет средства, облегчающие нормализацию. После того, как БД нормализована, BPwin предоставляет возможность проверить нормальность БД[14].

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

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

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

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

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

Отсюда следует, что отношение находится во второй нормальной форме (2 НФ), если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от ключа.

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

2.4 Выбор среды СУБД

Система управления базами данных Microsoft Access является одним из самых популярных приложений в семействе настольных СУБД. Все версии Access имеют в своем арсенале средства, значительно упрощающие ввод и обработку данных, поиск данных и предоставление информации в виде таблиц, графиков и отчетов. Access позволяет использовать электронные таблицы и таблицы из других настольных и серверных баз данных для хранения информации, необходимой приложению. Присоединив внешние таблицы, пользователь Access будет работать с базами данных в этих таблицах так, как если бы это были таблицы Access. При этом и другие пользователи могут продолжать работать с этими данными в той среде, в которой они были созданы[7].

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

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

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

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

В таблицу «Розыск» входят полные данные о человеке, который находится в розыске. На рис. 2.1. представлена структура таблицы «Розыск».



Рис. 2.1 Структура таблицы «Розыск»

В таблице «Описание человека» описаны подробные данные разыскиваемого, а это: фамилия, имя, отчество, пол человека, волосы, рост, телосложение и приметы. На рис.2.2. представлена структура таблицы «Описание человека».

Рис. 2.2 Структура таблицы «Описание человека»

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



Рис. 2.3 Структура таблицы «Неизвестные»

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

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

В Бюро регистрации несчастных случаев поступает информация по электронной почте из отделений милиции, медицинских учреждений и ГУВД. Приведем пример информации поступающей в подразделения:

1. Розыск:

«Центральное РУВД

КУСП-1234/34

25.11.2010 г. уехал от друзей из г. Луга сын заявителя Иванчук Дмитрий Ярославович 12.12.1979 г.р., урож. Ленинграда, зарег. и прож. пр. Литейный д.43 кв. 82 и до настоящего времени местонахождение его неизвестно.

Приметы: на вид 34 года, ХТС, рост около 170 см., европейский тип лица волосы черные.

Особые приметы: татуировка.

Был одет: куртка синяя, сапоги черные. Другая одежда не известна.

Злоупотребляет спиртными напитками. Ранее уходил на 2-3 дня.

В настоящее время на связь не выходит.

Заявление на розыск поступило 03.12.2010 г. в 13-43 от гр. Иванчук Т.Н. 09.04.1939 г.р., урож. Ленинграда, прож. пр. Литейный д.43 кв.82, не работает.

Выезжали: отв. От рук-ва РУВД зам. Нач. ОГИБДД Мызников, 34 о/м Ермола, УР Волков, УУМ Гусев, ОРО Баранов, ЭКЦ Борисов»

2. Неизвестные:

2.1. «Фрунзенское РУВД

КУСП-2910/36

10.01.2009 г. в 16-13 часов зарегистрирован рапорт об обнаружении признаков преступления.

10.01.2009 следователями прокуратуры Шиманским на Колтушском шоссе д. 40 осмотрен труп без признаков насильственной смерти неизвестного мужчины, на вид 19 лет, ХТС, рост 169 см., волосы темно-русые, европейский тип лица.

Особые приметы: шрамы по всему телу.

Одежда: шуба коричневая, брюки черные, ботинки»

3. Госпитализация неизвестного человека:

«Колпинское УВД

КУСП-3011/40

29.11.2010 г. в 14-29 в 40 о/м поступило сообщение из 30 инфекционной больницы им. Боткина/ул. Миргородская д.3/. 29.11.2010г. в 12-32 с пр. Литейный д. 21 госпитализирован неизвестный мужчина № 22. Ст.17 маш. 2394, без признаков преступления.

Приметы неизвестного: на вид 34 года, ХТС, волосы черные, европейский тип лица, рост 170 см.

Одежда: куртка синяя, сапоги черные.

Приметы: татуировка (место не указано)»

2.5 Выбор средств проектирования

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относится и BPwin. Функциональные возможности инструментальных средств, структурного моделирования деловых процессов будут рассмотрены на примере case-средств BPwin.

AllFusion Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурса, а также визуализировать получаемые от этих действий результаты. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и её взаимодействия с внешней средой.

На рис. 2.4. представлена концептуальная диаграмма процесса работы БРНС ГУВД.

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



Рис. 2.4 Концептуальная диаграмма БРНС

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные-в виде стрелок. Стрелки могут быть нескольких типов: вход, выход, управление и механизм[18].

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

На рис. 2.5. представлена функциональная декомпозиция БРНС.



Рис. 2.5 Функциональная декомпозиция БРНС

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

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

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

Управления - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелка Управления рисуется как входящая в верхнюю грань работы. Законодательство и Должностные инструкции - управление для работы Бюро регистрации несчастных случаев ГУВД.

Механизм - ресурсы, которые выполняют работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. Оборудование и Сотрудники являются механизмом для работы БРНС ГУВД.

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

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

При проектировании структуры (логической модели) базы данных использовалось CASE-средство BPWin.

2.6 Проектирование базы данных

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

В базе данных сведения сохраняются в отдельных таблицах.

Таблица - основной объект для хранения информации в реляционной базе данных.

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

Выбрать название таблиц;

Выбрать название строкам и столбцам;

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

База данных может состоять из одной или нескольких таблиц. На рис. 2.7. и 2.8. (продолжение) представлена таблица «Розыск».

На рис. 2.9. изображена таблица «Описание человека». На рис. 2.10. представлена таблица «Неизвестные». На рис. 2.11. представлена таблица «Описание неизвестного».

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

На Рис. 2.12.-2.15 подробно представлены конструкторы запросов на выборку. Другие примеры конструктора запросов на выборку представлены на Рис. 2.16.-2.19. в Приложении 1.

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

На рис.2.20.-2.23. подробно представлены конструкторы отчеты. Другие примеры конструктора отчета представлены на Рис. 2.24.-2.27. в Приложении 2.

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



Рис. 2.7. Таблица «Розыск»

Рис. 2.8 Таблица «Розыск»



Рис. 2.9. Таблица «Описание человека».

Рис. 2.10 Таблица «Неизвестные»



Рис. 2.11 Таблица «Описание неизвестных»

Рис. 2.12 Конструктор запроса на выборку возраста

Рис. 2.13 Конструктор запроса на выборку пола человека



Рис. 2.14 Конструктор запроса на выборку номера больницы

Рис. 2.15 Конструктор запроса на выборку штанов

Рис. 2.20 Конструктор отчета по полу человека



Рис. 2.21 Конструктор отчета по району разыскиваемого человека

Рис. 2.22 Конструктор отчета по телосложению разыскиваемого человека

Рис. 2.23 Конструктор отчета по номеру больницы

Макросы представляют собой небольшие программы, с помощь которых обеспечивается реакция Access на такие события, как открытие формы, щелчок кнопки. Макрос состоит из одной или нескольких макрокоманд, которые выполняются либо последовательно, либо в порядке, заданном определенными условиями. Каждая макрокоманда имеет определенное имя и, возможно, один или несколько аргументов, которые задаются пользователем. На рис. 2.28 -2.31 представлены конструкторы макросов. Другие примеры конструктора макроса представлены на Рис. 2.32.-2.35. в Приложении 3.



Рис. 2.28 Конструктор макроса таблица «Неизвестные»

Рис. 2.29 Конструктор макроса отчета «Пол неиз.»

Рис. 2.30 Конструктор макроса «Закрыть БД»

Рис. 2.31 Конструктор макроса отчета «Поиск по фамилии»

Связь между таблицами Access позволяет установить правила взаимодействия между таблицами. (Рис. 2.36.)



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

2.7 UML-моделирование

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

Модель - это чертеж системы: в неё может входить как детальный план, так и более абстрактное представление системы.

UML это язык для:

Визуализировать систему;

Специфицировать систему;

Конструировать систему;

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

На рис. 2.37. представлена диаграмма прецедентов, описывающая исследуемое подмножество бизнес-процессов в целом.

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

Программная система функционирует под воздействием Actor (Актер). Актер в UML- человек, машина или программа, воздействующий на систему.

Выделим актера и варианты использования в рассмотренном ранее «БРНС». Анализ постановки задачи показывает наличие одного актера: «Оператора». Определимся с вариантом использования. Принятые проектные решения определяют дальнейший выбор архитектуры системы и существенно влияют на успех всего процесса разработки[17].

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

Регистрация данных;

Просмотр данных;

Выход документации на печать;

Ведение картотеки;

Оформление отчетов;

Обработка входящих звонков.

В сценарий «регистрация данных» входит:

Госпитализация;

База скорой помощи;

База захороненных;

База архива.

В сценарий «просмотр данных» входит:

Госпитализация;

База скорой помощи;

База захороненных;

База архива.



Рис. 2.37 Диаграмма прецедентов

Выводы

В этой главе выполнено проектирование АРМ сотрудника оперативного учета. Разработаны и описаны концептуальная и логическая модель объекта автоматизации.

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

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

Обоснован выбор модели данных предметной области. Обосновано средство разработки АРМ. С использованием CASE-средств выполнено проектирование логики работы приложений.

ГЛАВА 3 РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА «БРНС ГУВД»

3.1 Создание физической модели данных

ERwin имеет очень удобный пользовательский интерфейс, позволяющий представить БД в самых различных аспектах. Например, ERwin имеет такие средства визуализации как "хранимое представление" (stored display) и "предметная область" (subject area). Хранимые представления позволяют иметь несколько вариантов представления модели, в каждом из которых могут быть подчеркнуты определенные детали, которые вызвали бы перенасыщение модели, если бы они были помещены на одном представлении. Предметные области помогают вычленить из сложной и трудной для восприятия модели отдельные фрагменты, которые относятся лишь к определенной области, из числа тех, что охватывает информационная модель.

AllFusion Erwin Data Modeler (ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

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

Ключевые характеристики:

Синхронизация баз данных;

Автоматизированное создание структуры БД и обратное проектирование;

Публикация моделей;

Поддержка нотаций: IDEF1x, IE, Dimensional;

Документирование структур БД;

Перенос структур БД из одного типа СУБД в другой.

Окно Erwin содержит строку меню, в котором имеются режимы:

File;

Edit;

Server;

Report;

Option;

Help.

Два дополнительных меню не видны, когда Erwin инсталлируется впервые:

Display;

Editor.

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

ERwin, как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы Logic Works - RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые различные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования, т.к. это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.

ERwin тесно интегрирован с другими продуктами Logic Works. Словарь данных, созданный при анализе бизнес-процессов при помощи инструмента BPwin, может быть использован как основа для построения модели базы данных. Однако взаимосвязь между этими двумя инструментами двусторонняя, модели BPwin и ERwin можно постоянно поддерживать в согласованном состоянии. Интеграция этих двух продуктов очень важна с точки зрения их совместного использования при разработке программного обеспечения, т.к. отпадает необходимость в повторном выполнении действий и процесс создания словаря данных становится практически автоматическим.

3.2 Физическая реализация системы

В подразделении БРНС ГУВД работают сотрудники оперативного учета, которые вводят и обрабатывают информацию. Для удобства автоматизации создана база данных «БРНС ГУВД».

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



Рис. 3.1 Главное окно БД

В этом окне находятся главные кнопки для работы с этой программой:

База розыск;

База описание человека;

База неизвестных;

База описание неизвестных.

Для поиска пропавшего или поступившего человека, в БД созданы запросы.

Функции поиска:

Выбрать нужный запрос (по которому будет происходить поиск);

Заполнить поисковое поле;

Воспользоваться кнопкой «OK»;

Откроется окно результата поиска;

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

Запросы на выборку:

Поиск по дате рождения Рис. 3.1. (отчет поиска рис. 3.2.);



Рис. 3.1 Поиск по дате рождения

Рис. 3.2 Отчет по запросу

Поиск по фамилии Рис. 3.3. (отчет поиска рис. 3.4.);

Рис. 3.3 Поиск по фамилии

Рис. 3.4 Отчет по запросу

Поиск по верхней одежде Рис. 3.5. (отчет поиска рис. 3.6.);

Рис. 3.5 Поиск по верхней одежде



Рис. 3.6 Отчет по запросу

Поиск по кофте Рис. 3.7 (отчет поиска рис. 3.8.);

Рис. 3.7 Поиск по кофте

Рис. 3.8 Отчет поиска по кофте

Поиск по штанам Рис. 3.9. (отчет поиска рис. 3.10.);

Рис. 3.9 Поиск по штанам

Рис. 3.10 Отчет поиска по штанам

Поиск по обуви Рис. 3.11. (отчет поиска рис. 3.12.);



Рис. 3.11 Поиск по обуви

Рис. 3.12 Отчет поиска по обуви

Поиск по району Рис. 3.13. (отчет поиска рис. 3.14.);

Рис. 3.13 Поиск по району

Рис. 3.14 Отчет поиска по району

Поиск по полу Рис. 3.15. (отчет поиска рис. 3.16.);



Рис. 3.15 Поиск по полу

Рис. 3.16 Отчет поиска по полу

3.3 Структура пользовательской части АРМ

На рис. 3.17. представлена структура пользовательской части АРМ БРНС.

Функциональные возможности программы расположены на главной форме.



Рис. 3.17 Структура пользовательской части АРМ БРНС

3.4 Тестирование

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

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

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

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

Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.

Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).

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

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

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

Уровни тестирования:

Модульное тестирование (юнит-тестирование) -- тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

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

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

Альфа-тестирование -- имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

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

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

Этапы тестирования:

Вид тестирования	Стадия, этап	Объект	Критерий
Функциональное	Разработка	Система в целом	Соответствие функциональным требованиям ТЗ
Регрессионное	Разработка, сопровождение	Система в целом	Проверка качества внесения изменений
Нагрузочное	Разработка, сопровождение	Система в целом	Оценка статистических характеристик системы, соответствие ТЗ, ТТХ, подбор конфигурации оборудования
Стрессовое	Разработка, сопровождение	Система в целом	Корректность работы системы при предельных нагрузках

Проводя функциональное тестирование ПО, необходимо:

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

- проверить производительность системы и ее устойчивость;

- проверить, как работает система с входными данными;

- провести анализ использования основных системных ресурсов.

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

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

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

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

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

Рассмотрим тест на примере проверки модуля. «Ввод». Тест представлен на Таблица 3.1 в Приложении 4.

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

Выводы

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

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

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

ЗАКЛЮЧЕНИЕ

В ходе данного дипломного проекта были проанализированы: анализ предметной области, проектирование БД и реализация АРМ,

В анализе предметной области были рассмотрены: анализ аналогов на рынке, показал, что существует огромное количество АРМ, но в каждом из них существуют значительные недостатки; функции, задачи и структура подразделения БРНС ГУВД, проанализировав это, были сформулированы все необходимые параметры, характеризующие автоматизируемые объекты; проанализировав CASE-средства, был сделан выбор на BPwin, выявлены информационные потоки.

В проектирование дипломного проекта разработано АРМ сотрудника оперативного учета Бюро регистрации несчастных случаев ГУВД с использованием Microsoft Access.

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

Для реализации поставленной цели дипломного проекта был проведен анализ функциональных обязанностей сотрудника оперативного учета (оператора) подразделения БРНС ГУВД и осуществлена разработка физической структуры БД для БРНС.

Цели и поставленные задачи дипломного проекта выполнены.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ

1. Источники

1. Положение о деятельности Бюро регистрации несчастных случаев ГУВД

2. Приказ от 5 октября 2009 года N 1633. Об утверждении Положения о Бюро регистрации несчастных случаев ГУВД по г. Санкт-Петербургу и Ленинградской области

3. Программный комплекс FLINT-4 (руководство пользователя): М.,1995

4. Часть первая в ред. Федерального закона от 31.03.1999 N 68-ФЗ

5. Уголовно-процессуальный кодекс РФ (УПК РФ) от 18.12.2001 N 174-ФЗ

6. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создании»

7. ГОСТ 34.320-96 «Концепции и терминология для концептуальной схемы и информационной базы»

8. Стандарт ISO/IES 12207-99

2. Литература

9. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем-М.: Финансы и статистика,1998.-352 с.

10. Вильямс А.. Системное программирование в Windows 2000.-СПб.Питер,2001.-624 с.

11. Гвоздева В.А. Информатика, автоматизированные информационные технологии и системы-М.:Инфра,2007-320 с.

12. Грекул В.И. Проектирование информационных систем.-М: БИНОМ, 2008.-304 с.

13. Калянов Г.Н., Номенклатура CASE-средств и виды проектной деятельности//СУБД,1997.-320 с.

14. Ковалев В.Д., Хисамудинов В.В. Автоматизированное рабочее место экономиста-М.:Инфра,2010.-206 с.

15. Маклаков С.В. ERWin и BPWin. CASE-средства разработки информационных систем/ С.В. Маклаков.-М: ДИЛОГ МИФИ,2000.-256 с.

16. Норенков И.П. Основы автоматизированного проектирования-М: Изд-во МГТУ им. Н.Э.Баумана,2002.-336 с.

17. Осмоловский В.В. Теория анализа хозяйственной деятельности. - Мн.: Новое знание, 2005. - 358 с.

18. Саламатова М.А., Щербаков С.М. Моделирование деловых процессов в системе СИМ-UML (на примере торговой организации) // Системное управление. Выпуск 1(5),2009.- 160 с.

19. Титоренко Г.А. Автоматизированные информационные технологии в экономике.-М.:ЮНИТИ,2003.-400 с.

20. Хомоненко А.Д. Базы Данных: Учебник / А.Д. Хомоненко, В.М. Цыганков, В.М. Мальцев.-СПБ: КОРОНА принт 2004.-736 с.

Приложение 1

Конструктор запросов на выборку

Рис. 2.16 Возраст больше 45 лет

Конструктор запросов на выборку

Рис. 2.17 Дата поступления



Конструктор запросов на выборку

Рис. 2.18 Возраст меньше 40 лет

Приложение 2

Конструктор отчета

Рис. 2.24 Номер неизвестного

Рис. 2.25 Возраст по розыску

Рис. 2.26 Дата поступления

Приложение 3

Конструктор макросов

Рис. 2.32 Поиск по кофте

Рис. 2.33. Поиск по номеру

Рис. 2.34 Поиск по району



Рис. 2.35 Поиск по полу

Приложение 4

Таблица 3.1 Тест проверки модуля «Ввод»

	Действия	Ожидаемый результат
1	2	3
Возраст	Ввод не правильного возраста	Выводится сообщение «Выражение неверно введено или является слишком сложным для расчета»
Возраст	Ввод правильного возраста	Выдает правильное значение
Дата рождения	Ввод не правильной даты	Выводится сообщение «Выражение неверно введено или является слишком сложным для расчета»
Дата рождения	Ввод правильной даты	Выдает правильное значение

Размещено на Allbest.ru