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

Размещено на http://www.allbest.ru/

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

ОГЛАВЛЕНИЕ

автоматизация рабочее место оперативный учет

ВВЕДЕНИЕ

ГЛАВА 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Анализ источников и литературы

1.2 Анализ рынка

1.3 Задачи, функция и структура «Бюро регистрации несчастных случаев ГУВД»

1.3.1 Задачи БРНС

1.3.2 Функции БРНС

1.3.3 Структура БРНС ГУВД

1.4 Обоснование выбора и системный анализ с применением CASE-средств подлежащих автоматизации

1.5 Выявление и оценка информационных потоков и структуры информации

1.5.1 Информационные потоки

1.5.2 Информация

1.6 Структуризация и обоснование требований (заказчика) к автоматизации, постановка задачи

Выводы

ГЛАВА 2 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА «БРНС ГУВД»

2.1 Разработка и сопровождение основных этапов БД

2.2 Выбор модели данных

2.3 Разработка и описание концептуальной и логической моделей данных

2.3.1 Концептуальная модель данных

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

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

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

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

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

Выводы

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

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

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

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

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

Выводы

ЗАКЛЮЧЕНИЕ

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

Приложение 1

Приложение 2

Приложение 3

Приложение 4

ВВЕДЕНИЕ

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

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

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

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

Цель дипломного проекта - разработка автоматизированного рабочего места сотрудника оперативного учета Бюро регистрации несчастных случаев ГУВД Санкт-Петербурга и Ленинградской области.

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

Объект исследования - Бюро регистрации несчастных случаев.

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

· провести анализ предметной области;

· выполнить проектирование АРМ сотрудника оперативного учета;

· произвести разработку и тестирование АРМ сотрудника оперативного учета;

· разработать документацию по использованию АРМ сотрудника оперативного учета.

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

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

Во второй главе выполнено проектирование АРМ сотрудника оперативного учета. Разработаны и описаны концептуальная и логическая модель объекта автоматизации, обоснован выбор модели данных предметной области. Обосновано средство разработки АРМ. С использованием CASE-средств выполнено проектирование логики работы приложений, разработана документация и техническому проектированию АРМ, в соответствии с ГОСТ.

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

В работе 4 приложений, 57 рисунков, 1 таблица.

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

В работе над дипломным проектом автором использовались ГОСТ 34.601-90, 34.320-96, стандарт ISO/IEC 12207, работы российских ученых.

В работе В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина рассмотрены методы и средства проектирования информационных систем в сфере экономики, приведены примеры использования CASE - средств как программного инструмента поддержки проектирования информационных систем. Особое внимание в работе уделено таким вопросам, как методология проектирования предметной области, моделирование бизнес-процессов средствами BPwin, информационное обеспечение информационных систем, моделирование информационного обеспечения. [11].

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

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

ГЛАВА 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Анализ источников и литературы

В.Д. Ковалев и В.В. Хасамудинов в своей работе раскрыли сущность автоматизированного рабочего места (АРМ) как средства реализации новых информационных технологий в организационно-экономическом управлении, сформулированы задачи, решаемые специалистами на всех уровнях управления, определены базовые понятия и общие свойства АРМ[13].

И.П. Норенков в учебнике описал сведения по различным аспектам и видам обеспечения систем автоматизированного проектирования, необходимые квалифицированным пользователям САПР в различных областях техники. Значительное внимание уделено математическому обеспечению процедур анализа и синтеза проектных решений, построению локальных и корпоративных вычислительных сетей САПР, составу и функциям системных сред САПР. Освещены также активно развиваемые в последнее время методики концептуального проектирования сложных систем, положенные в основу CALS-технологий, а также вопросы интеграции САПР с автоматизированными системами управления и делопроизводства[15].

В работе В.А. Гвоздева особое внимание уделено основам знаний по алгоритмизации, технологии программирования, языкам программирования, а также системе объектно-ориентированного программирования MS Visual Basic. Во второй части книги, "Информационные технологии", излагаются вопросы компьютерной обработки текстовой, числовой, графической информации, основы баз данных и знаний, систем управления базами данных (СУБД), даются представление о локальных и глобальных компьютерных сетях и знания о средствах создания веб-документов. Третья часть книги, "Автоматизированные информационные системы", посвящена вопросам разработки и функционирования АИС. Рассматриваются вопросы необходимости автоматизации информационных потоков, состав и структура АИС, методы и стадии их разработки, обеспечивающая и функциональные части, типы АИС, тенденции развития информационных систем[8].

1.2 Анализ рынка

На сегодняшний день существует огромное количество АРМ. Приведем пример статистических программ:

АРМ "ОТ" 1.0 программное обеспечение инженера по охране труда. АРМ «ОТ» (автоматизированное рабочее место «охрана труда») предназначена для информационной поддержки деятельности инженера (специалиста) по охране труда, актуализация и анализа информации, касающейся вопросов охраны труда на предприятии. Стоимость программы 4900 руб.

Программа «ОТ» позволяет:

Вести учет персонала;

Вести учет медосмотров по охране труда;

Проводить анализ нарушений по охране труда;

Вести учет проверки знаний персонала, составлять графики проверки знаний персонала;

Автоматизировать процесс знаний персонала;

Вести учет травматизма, проводить анализ травматизма на предприятии;

Вести архив документов по охране труда;

Вести учет затрат в сфере охраны труда.

Программа АРМ «ОТ» может экспортировать различные отчеты, справки, графики в редакторы Word, Excel популярного пакета Microsoft Office.

Недостатки: Сложность работы, функциональная избыточность, сложный интерфейс.

Размер программного обеспечения 11981 кб.

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

Возможности программы:

· ввод информации о больных;

· первичный осмотр (используются шаблоны осмотров);

· назначения с распечаткой листа назначений (используются шаблоны назначений);

· запись дневников (используются шаблоны дневников);

· запись операций с предоперационным эпикризом и без (используются шаблоны операций);

· заполнение выписки (используются шаблоны выписок).

Недостатки: нет защиты данных (не поддерживает паролей). Размер программы 1000 Кб.

АРМ «C2000» предназначено для количественного учета заболеваемости в учреждениях санэпиднадзора всех уровней, проводящих регистрацию заболеваний.

Основные функциональные возможности:

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

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

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

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

Печать и экспорт в HTML. Текущую выборку событий можно непосредственно распечатать на принтере или экспортировать в HTML формат.

Возможность непостоянной работы программы. Возможна непостоянная работа программы за счет буфера событий пульта "C2000" (до 1023 событий), например, считывание событий за ночь в начале рабочего дня.

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

Недостаток АРМ «С2000» в том, что она позволяет сортировать события по помещениям или по фамилиям, тогда как необходимо в основном просмотр совместный (по помещениям с фамилиями).

Недостатки: нет возможности сводных отчетов.

Стоимость программы 4701 руб.

Таким образом, автоматизированное рабочее место по обработке информации совершенствует работу специалистов.

1.3 Задачи, функция и структура «Бюро регистрации несчастных случаев ГУВД»

Бюро регистрации несчастных случаев ГУВД по г. Санкт-
Петербургу и Ленинградской области (БРНС ГУВД по г. СПб и ЛО) является структурным подразделением Главного управления внутренних дел по г. Санкт- Петербургу и Ленинградской области и непосредственно подчиняется первому заместителю начальника ГУВД - начальнику криминальной милиции[1].

В своей деятельности БРНС ГУВД руководствуется[1]:

Конституцией Российской Федерации;

Общепризнанными принципами;

Нормами международного права;

Законами Российской Федерации;

Законами Санкт-Петербурга и Ленинградской области;

Положением о службе в органах внутренних дел РФ;

Положением о БРНС ГУВД;

Планами работы и приказами БРНС ГУВД;

Указами и распоряжениями Президента Российской Федерации;

Постановлениями и распоряжениями Правительства Российской Федерации;

Правительств Санкт-Петербурга и Ленинградской области;

Нормативными правовыми актами МВД России и ГУВД.

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

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

1.3.1 Задачи БРНС[2]

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

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

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

1.3.2 Функции БРНС[2]

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

2. Формирует и поддерживает в рабочем состоянии банки данных:

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

· трупов неизвестных граждан, невостребованных родственниками и захороненных за счет средств государства;

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

· лиц пострадавших в результате несчастных случаев;

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

4.Исполняет в пределах своей компетенции, отдельные поручения и запросы ОВД, прокуратуры, КГБ, суда.

5. Обеспечивает полноту регистрации объектов, подлежащих отражению в банках данных.

6. Изучает, обобщает, распространяет передовой опыт по всем направлениям деятельности БРНС. Обменивается информацией с БРНС стран СНГ.

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

Структура БРНС ГУВД представлена на рис. 1.1.

Рис. 1.1 Структура БРНС ГУВД

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

В стране ежегодно в розыске находятся свыше 120 тыс. без вести пропавших, и ежегодно объявляются в розыск еще свыше 70 тыс. человек. Находят каждый год более 65 тысяч - около 90% пропавших.

1.3.3 Структура БРНС ГУВД

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

Сведения можно получить по телефону в круглосуточном режиме, если с момента исчезновения лица не прошло 30 суток. Данную информацию можно получить как сотрудникам милиции, так и гражданам. Если с момента исчезновения лица прошло 30 суток, то необходимо обратиться в БРНС только письменно сотрудникам милиции.

В случае если срок прошел, родственники подают письменный запрос в отделение милиции. В письменном запросе должно быть описано: фамилия, имя, отчество (если оно есть), дата и место рождения, дата ухода, приметы человека, описание внешности, во что он был одет на момент ухода, где мог находиться территориально [5]. После принятия заявления оно регистрируется и оправляется в ГУВД, там сотрудники распределяют и отправляют это заявления при помощи почты России по подразделениям и по всем отделениям милиции г. Санкт-Петербурга, в том числе и в БРНС. Запрос (далее «входящий») поступающий в БРНС получает начальник подразделения, после отдается на регистрацию в канцелярию. Канцелярия совместно с заместителем начальника распределяет «входящие» по 4 сменам. Начальник смены и операторы этого подразделения расписываются за «входящие», которые ему были расписаны.

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

База регистрации лиц госпитализированных из общественных мест автотранспортом «Скорая помощь», а так же неизвестных больных и трупах (автоматическое обновление информации каждый час);

База о неизвестных трупах, обнаруженных на территории Ленинградской области и транспортной милиции (операторы вводят информацию по мере её поступления);

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

База о разыскиваемых пропавших без вести гражданах подразделениями КМ, СМОБ, ПВС в период с 01.07.1996 года (операторы дополняют или удаляют информацию по мере её поступления).

Электронная фото картотека неизвестных трупов, которые были доставлены в морг № 1 (Екатерининский пр. д.10) и морги больниц города. Данная база состоит из графического изображения трупа и текстовой информации.

Обязанности сотрудника оперативного учета БРНС:

Своевременное и качественное выполнение своих должностных обязанностей, указаний и распоряжений руководства БРНС;

Соблюдения суточного режима работы согласна графика;

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

Осуществление взаимодействия с Центральной станцией «Скорой помощи»;

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

Схема функционирования БРНС ГУВД представлена на рис. 1.2.



Рис. 1.2 Схема функционирования БРНС ГУВД

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

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

В настоящее время Бюро регистрации несчастных случаев ГУВД пользуется программой FLINT (Formal language of Interactive Talk) написанной на языке Clipper ver.5.01. Инструментальное средство FLINT представляет собой программный комплекс, по созданию Баз Данных (БД) и работы с ними. Его использование призвано облегчить проектирование на персональных совместимых ЭВМ АРМ, ориентированных на обработку документов анкетного вида с формированием БД по типу картотеки.

Широкое использование FLINT в различных сферах деятельности-медицине, торговле, различных охранных службах, и др. убедительно доказало его эффективность и привлекло на свою сторону десятки тысяч пользователей, далеко раздвинув границы распространения продукта (Россия, Казахстан, Узбекистан, Литва, Латвия, Белоруссия, Украина, Молдавия, и др.).

Информационная система FLINT ориентировано на работу с персональным компьютером типа IBM PC/XT/AT или им подобными микро-ЭВМ.[3]

Функции программы FLINT:

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

Запоминать значение документа, групп реквизитов внутри документа и вызывать запомненные реквизиты;

Работать со словарями непосредственно при вводе документа;

Переходить из одной формы ввода в другую непосредственно из текущего документа;

Осуществлять поиск для коррекции;

Удалять и чистить документы БД.

Проанализировав предметную область своей деятельности, и определив основные объекты учета, разработчик осуществляет постановку задачи (проектирование АРМ) - формирует все необходимые параметры, характеризующие автоматизируемые объекты:

Взаимосвязь между Объектами;

Адреса хранения информации;

Форма ввода/вывод данных;

Ключи поиска;

Виды статистической отчётности.

1.4 Обоснование выбора и системный анализ с применением CASE-средств подлежащих автоматизации

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

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

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

Обычно к CASE-средствам относятся любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО[6].

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE -средствами:

Vantage Team Builder;

Designer/2000;

Silverrun;

ERwin+BPwin;

S- Designor;

CASE Аналитик.

Рассмотрим подробнее каждое программное обеспечения:

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

Структура и функции

Vantage Team Builder обеспечивает выполнение следующих функций:

· проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

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

· генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

· программирование на языке C# со встроенным SQL;

Управление версиями и конфигурацией проекта;

Многопользовательский доступ к депозитарию проекта;

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

Экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE* Method) - структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС.

Структура и функции

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

На этапе проектирования разрабатывается подробная архитектура ИС, проектируется схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами ИС для анализа их взаимного влияния и контроля за изменениями.

На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей.

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

CASE Аналитик является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования. Его основные функции:

· построение и редактирование диаграмм потоков данных DFD;

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

· получение разнообразных отчетов по проекту.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. При этом из проекта, выполненного в CASE. Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель жизненного цикла[12]. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

Структура и функции

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность работы с моделями большой сложности: автоматическая пере нумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость источника позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

BPwin являются наиболее популярными Case-средствами.

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

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD)[12].

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

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

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

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

Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы -- движение объектов, хранение объектов, поставка и распространение объектов[12].

Третий информационный разрез -- последовательность выполняемых работ. Наличие в диаграммах DFD элементов для обозначения источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, -- методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

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

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

IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа[6].

1.5 Выявление и оценка информационных потоков и структуры информации

1.5.1 Информационные потоки

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

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

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

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

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

1.5.2 Информация

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

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

Рис. 1.3 Содержание термина "информация по поиску пропавших лиц"

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

1.6 Структуризация и обоснование требований (заказчика) к автоматизации, постановка задачи

В Бюро регистрации несчастных случаев ГУВД для поиска людей утратившую родственную связь используется написанная на Clipper ver.5.01 база данных FLINT. Недостатки программы FLINT являются:

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

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

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

4. Вид распечатываемых карточек не соответствовал виду стандартных документов.

Устранить вышеописанные недостатки и было целью дипломной работы. Более кратко требования к новой реализации АРМ можно обозначить так:

Разграничение прав доступа к информации.

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

Минимальная нагрузка на локальную вычислительную сеть.

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

Выводы

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

Основная задача Бюро регистрации несчастных случаев - регистрация несчастных случаев и поиск пропавших лиц по СПб и ЛО.

Анализ аналогов-ресурсов показал, что на сегодняшний день существует огромное количество АРМ. Но в каждом из них присутствуют такие недостатки как:

Сложность работы;

Функциональная избыточность;

Высокая стоимость;

Сложный интерфейс.

Рассмотрев и проанализировав CASE-средства, можно сделать вывод, что использование BPwin и ERwin совместно поможет правильно оценить стоящие задачи, предложить адекватное решение (анализ бизнес-процессов, BPwin) и разработать центральную часть любой информационной системы - базы данных - с использованием информации, полученной во время обследования предприятия (моделирование базы данных, ERwin). Эти инструменты сами по себе не являются решением проблемы, но их грамотное и своевременное использование поможет свести рутинный труд разработчика к минимуму, позволит ему сконцентрироваться на собственно разработке системы и снизит потери времени, которые обычно происходят при согласовании моделей со специалистами предметной области. Кроме того, использование этих инструментов дает возможность получить набор полностью документированных и согласованных моделей, что в значительной степени облегчит поддержку созданных систем в будущем, а также может быть повторно использовано при разработке других систем.

Задачи, подлежащие автоматизации: запрос по поиску пропавших лиц, поиску по возрасту, поиск по одежде, поиск по приметам, поиск по району, поиск по дате регистрации.

ГЛАВА 2 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА «БРНС ГУВД»

2.1 Разработка и сопровождение основных этапов БД

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

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

Этап анализа предметной области;

Этап проектирования БД;

Этап тестирования и сопровождения БД.

Современные платформа БД Microsoft SQL предназначена не только для хранения информации, но и способны задавать логику обработки информации.

Microsoft SQL (MS SQL) - это современное программное обеспечение, предназначенное для организации хранения и доступа к данным (информации) и является самым распространённым языком для работы с БД. Возможности MS SQL не ограничиваются выборкой данных из БД, в MS SQL поддерживаются разнообразные возможности для взаимодействия с БД, в том числе:

Определение структуры данных - определение конструкций, используемых при хранении данных;

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

Обработка данных - вставка, обновление и удаление информации;

Контроль доступа - возможность разрешение/запрета выборки, вставки, обновления и удаления данных на уровне отдельных пользователей;

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

2.2 Выбор модели данных

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

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

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

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

Классические модели данных:

Реляционная;

Иерархическая;

Сетевая.

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

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях.

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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

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

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

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

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

Реляционная модель данных была предложена Е.Ф. Коддом в 1970 году и получила к настоящему времени широкое распространение и популярность. В течении долгого времени реляционная подход рассматривался как удобный формальный аппарат анализа баз данных, не имеющий практических перспектив, так как его реализация требовала слишком больших машинных ресурсов. Только с появлением персональных ЭВМ реляционные и близкие к ним системы стали распространяться, практически не оставив места другим моделям.

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

Достоинство реляционной модели[20]:

Упрощение схемы данных для пользователя;

Улучшение логической и физической независимости;

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

Оптимизация доступа к БД;

Улучшение целостности и защиты данных;

Возможности различных применений;

Обеспечение методологического подхода.

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

После определения модели данных переходим к этапу логического моделирования.

2.3 Разработка и описание концептуальной и логической моделей данных

2.3.1 Концептуальная модель данных

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

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

К концептуальным моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к концептуальному уровню описания предметной области можно отнести следующие компоненты[10]:

· систему атрибутов и средств описания предметной области. Например, логические (автоматические) связи между показателями или лингвистические свойства языка (синонимию, синтаксис и т.д.), используемую для вербального представления объектов;

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

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

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

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