Автоматизированная информационная система поверки приборов контроля окружающей среды Ставропольского КЦ по ГМОС

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

ОБРАЗОВАТЕЛЬНАЯ ОРГАНИЗАЦИЯ ВЫСШЕГО ОБРАЗОВАНИЯ (АССОЦИАЦИЯ)

«КИСЛОВОДСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ»

Факультет Инженерный

Кафедра Систем автоматического управления

Направление Управление в технических системах

К защите допустить:

Зав. кафедрой, д.т.н., профессор Гайдук А.Р.

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к выпускной квалификационной работе

На тему: «Автоматизированная информационная система поверки приборов контроля окружающей среды Ставропольского КЦ по ГМОС»

Руководитель работы: д.т.н., доцент _________ Титаренко С.П.

Консультанты:

по экономическому разделу ___________________к.э.н. Курданов М.Д.

по безопасности и экологичности системы __________Сербулова Т.Н.

Студент: Вербицкий Артур Валерьевич гр.241

Кисловодск 2017

Реферат

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

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

Рассмотрены вопросы безопасности и экологичности, а также выполнено технико-экономическое обоснование системы.

Содержание

1. Автоматизированная информационная система мониторинга

1.1 Исследование химической лаборатории учреждения «Северо-Кавказское управление по гидрометеорологии и мониторингу окружающей среды» как объекта автоматизации

1.2 Постановка задачи автоматизации химической лаборатории учреждения «Северо-Кавказское управление по гидрометеорологии и мониторингу окружающей среды» как объекта автоматизации

1.3 Выбор инструментальных средств проектирования информационной системы Ставропольского КЦ по МОС

1.4 Виды диаграмм

1.5 Разработка диаграмм проекта автоматизации химической лаборатории учреждения «Северо-Кавказское управление по гидрометеорологии и мониторингу окружающей среды»

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

2.1 Обоснование выбора СУБД для реализации автоматизированной системы

2.2 Структура таблиц базы данных системы

2.3 Структура базы данных информационной системы поверки

2.4 Тестовые данные информационной системы поверки приборов контроля окружающей среды

2.5 Описание запросов, реализуемых в информационной системе поверки к БД

2.6 Формы информационной системы поверки приборов контроля окружающей среды

2.7 Отчеты информационной системы поверки приборов контроля окружающей среды

3. Технико-экономическое обоснование системы

3.1 Технико-экономическое обоснование разработки программного обеспечения

3.2 Расчет затрат на разработку программного обеспечения

3.3 Стоимость внедрения программного обеспечения организацией

4. Безопасность и экологичность системы

4.1 Обеспечение безопасности при эксплуатации автоматизированной информационной системы поверки

4.2 Требования к освещению в помещениях вычислительных центров

4.3 Защита от статического электричества и электромагнитных излучений

4.4 Пожарная безопасность в помещениях

4.5 Первичная система тушения пожара в помещениях вычислительных центров

Список источников

Введение

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

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

Экологический контроль (ЭК)в целом - ??? проверка соблюдения всеми хозяйствующими субъектами и гражданами экологических требований по охране ОПС и обеспечению экологической безопасности общества.

Объектами ЭК являются: состояние ОПС, ее отдельных объектов, степень их изменения под влиянием хозяйственного развития; выполнение обязательных мер по охране ОПС и ее отдельных объектов; соблюдение природоохранительного законодательства.

Цель ЭК состоит в предупреждении и устранении правонарушений в области экологии и природопользования.

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

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

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

Выпускная квалификационная работа посвящена решению задачи поверки приборов контроля окружающей среды на примере деятельности химлаборатории Ставропольского краевого центра по гидрометеорологии и мониторингу окружающей среды Федерального Государственного Бюджетного Учреждения (ФГБУ) «Северо-Кавказское управление гидрометеослужбы”, в дальнейшем, сокращенно, химлаборатории Ставропольского КЦ по ГМОС.

1. Автоматизированная информационная система мониторинга

1.1 Исследование химической лаборатории учреждения «Северо-Кавказское управление по гидрометеорологии и мониторингу окружающей среды» как объекта автоматизации

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

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

Задачами АИС мониторинга являются: хранение и поиск режимной информации о состоянии окружающей среды; целенаправленная постоянная обработка и оценка информации; выполнение перманентных прогнозов развития и состояния окружающей среды; решение оптимизационных задач по экологическому управлению.

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

Рисунок 1.1 - Структура АИС мониторинга

Отсюда следует и сама структура АИС мониторинга которая состоит из четырёх взаимосвязанных основных блоков (рис. 1.1), каждый из которых направлен на решение одной из перечисленных выше задач.

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

Вторым блоком АИС является автоматизированная система обработки данных (АСОД). Эта система проводит целенаправленную обработку и оценку поступающей информации по мониторингу экосистем.

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

Четвёртый блок составляет автоматизированная система управления (АСУ), направленная на решение задач по управлению и разработке рекомендаций. Он также практически реализуется с помощью ГИСтехнологий.

Все четыре блока АИС связаны друг с другом и образуют единую функционирующую систему. Основным вопросом при организации АИС является её информационное, техническое и математическое обеспечение.

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

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

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

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

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

Особо важную для организации мониторинга группу программных средств представляют компьютерные ГИС. С их помощью осуществляется построение всевозможных картографических моделей, составляющих важнейшую часть мониторинга. Информация мониторинга заносится в базы данных, а затем в интерактивном режиме составляются цифровые модели карт и другие графические материалы (разрезы, трёхмерные диаграммы, график и т.п.). В России применение ГИС осуществляется на основе концепции «Единой информационной системы недропользования», утверждённой Роскомнедра в 1994 г.

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

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

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

1.2 Постановка задачи автоматизации химической лаборатории учреждения «Северо-Кавказское управление по гидрометеорологии и мониторингу окружающей среды» как объекта автоматизации

Выпускная квалификационная работа посвящена решению задачи поверки приборов контроля окружающей среды на примере деятельности химлаборатории Ставропольского краевого центра по гидрометеорологии и мониторингу окружающей среды Федерального Государственного Бюджетного Учреждения(ФГБУ) «Северо-Кавказское управление гидрометео службы”,в дальнейшем, сокращенно , химлаборатории Ставропольского КЦ по ГМОС.

Ставропольский КЦ по ГМОС был создан в 1977г. на базе Бюро погоды Ставропольской зональной гидрометобсерватории (СЗГМО). В 1978г. создана лаборатория химии воздуха, открыты посты наблюдения за загрязнением атмосферного воздуха в г.г. Ставрополе и Невинномысске. В 1988г. СЗГМО переименована в Ставропольский центр по гидрометеорологии, в 1992г. - в Ставропольский краевой центр по гидрометеорологии и мониторингу окружающей среды (СЦГМС), в 2005г. - в Государственное учреждение "Ставропольский краевой центр по гидрометеорологии и мониторингу окружающей среды".

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

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

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

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

-поверхностных вод,

-почвы,

-сельскохозяйственных культур,

-радиационной и химической обстановкой

Подготовка информационной продукции:

-метеорологических

-гидрологических

-агрометеорологических прогнозов

-обзоров

-бюллетеней

-справок

-отчетов о радиационном и химическом загрязнении окружающей среды

-выпуск, ежемесячников, ежегодников

Рисунок 1.2 - Организационная структура предприятия

Наблюдения за загрязнением атмосферы проводятся регулярно в пятигородах (г. Ставрополь, г. Невинномысск, г. Кисловодск, г. Пятигорск, г. Минеральные Воды) на 10 стационарных постах наблюдения (ПНЗ). Ставрополь -- 4 ПНЗ; Невинномысск - 3 ПНЗ; Кисловодск, Пятигорск, Минеральные Воды - 1 ПНЗ. В городах измеряются концентрации от 5 до 13 веществ (взвешенные вещества, диоксид серы, оксид углерода, диоксид и оксид азота, сероводород, фенол, формальдегид, сажа, фторид водорода, аммиак, бенз(а)пирен, тяжелые металлы). Отбор проб воздуха осуществляется ежедневно, кроме воскресенья, три раза в сутки (07; 13; 19 ч.).

Наблюдения в г. Ставрополе проводятся на 4 стационарных постах (ПНЗ). Стационарные посты подразделяются на "городские фоновые" в жилых районах (ПНЗ №4 - пр.Юности, 14; ПНЗ №6 - Ботанический сад), "промышленные" вблизи предприятий (ПНЗ №7 - р-н Цирка) и "авто" вблизи автомагистралей или в районах с интенсивным движением транспорта (ПНЗ №3 - район Центрального автовокзала).

В г. Кисловодске наблюдения проводятся на 1 ПНЗ - в селитебной зоне, в г. Пятигорске - в селитебной зоне и является "городским фоновым", в г. Минеральные Воды - в районе ГП "Кавминводыавиа". Стационарные посты наблюдения (ПНЗ) подразделяются на "городские фоновые" в жилых районах (пост 4), "промышленные" вблизи предприятий (пост 3) и "авто" вблизи автомагистралей или в районах с интенсивным движениям транспорта (пост 4), ведомственный пост расположен на плотине. Отбор проб воздуха на ведомственном ПНЗ осуществляется в ночное время суток (22; 01; 04 ч.).

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

Отборы проб воды проводятся на створах контроля Государственной сети наблюдения (ГСН)

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

Гидрохимические наблюдения за 32 вредными веществами на водных объектах (р. Кума - ст. Бекешевская; г. Зеленокумск; с. Владимировка; г. Минеральные Воды; р. Калаус - г. Светлоград; р. Подкумок г. Кисловодск, г. Пятигорск, г. Георгиевск) выполняются Невинномысской группой МЗОС.

Данная квалификационная работа посвящена автоматизации одной из многих функций Ставропольского КЦ по ГМОС - поверки приборов контроля окружающей среды в химлаборатории КЦ по ГМОС.

1.3 Выбор инструментальных средств проектирования информационной системы Ставропольского КЦ по ГМОС

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

При построении модели выделяются лишь существенные для конкретной задачи свойства системы и строится ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. В качестве такой "стандартной" технологии используется унифицированный язык моделирования (Unified Modeling Language, UML), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML-модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.

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

Представление информационных систем моделями UML связано с определением следующих базовых понятий

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

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

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

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

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

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

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

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

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

Виды диаграмм UML 1.5 определил двенадцать типов диаграмм, разделенных на три группы:

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

· пять представляют поведенческие аспекты системы;

· три представляют физические аспекты функционирования системы (диаграммы реализации).

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

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

· диаграмма прецедентов;

· диаграмма классов;

· диаграмма объектов;

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

· диаграмма взаимодействия;

· диаграмма состояний;

· диаграмма активности;

· диаграмма развертывания.

1.4 Разработка диаграмм проекта автоматизации химической лаборатории учреждения «Северо-Кавказское управление по гидрометео-рологии и мониторингу окружающей среды»

Диаграмма прецедентов (usecasediagram)

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

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

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

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

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

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

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

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

На рис. 1.3 изображена диаграмма использования, на которой изображены два эктора: Администратор и Диспетчер. Администратор занимается разграничением прав доступа, просмотром и внесением изменений в справочники и документы.



Рисунок 1.3 - диаграмма использования двух экторов: Администратор и Диспетчер

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

Подводя итоги, можно выделить такие цели создания диаграмм прецедентов:

· определение границы и контекста моделируемой предметной области на ранних этапах проектирования;

· формирование общих требований к поведению проектируемой системы;

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

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

Диаграмма сущность-связь информационной системы поверки приборов химлабораторииСтавропольского КЦ по ГМОС.

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

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

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



Рисунок 1.4 - Диаграмма «сущность связь» информационной системы поверки приборов химлаборатории Ставропольского КЦ по ГМОС

Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения типа «отец-сын» или производственные отношения типа «начальник-подчиненный». Другой тип связей задается отношениями «иметь в собственности» или «обладать свойством». Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи.

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

Информационной системы поверки содержит следующие сущности: «Диспетчер», и др. При этом в качестве связи используется участие Диспетчера в оформлении Прихода и Расхода поверяемых приборов. На данном рисунке буква "N" около связи означает тот факт, что Диспетчер фиксирует Приход и Выдачу множества поверяемых приборов. Цифра "1" на другом конце связи означает, что только один сотрудник выполняет эту работу.

Диаграмма классов (classdiagram)

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

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

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

Диаграмма иллюстрирует с помощью операции наследования или генерализации "генеалогическое древо".

На рис.1.5. представлена диаграмма классов информационной системы поверки.

Рисунок 1.5 - Диаграмма «Классов» информационной системы поверки приборов химлаборатории Ставропольского КЦ по ГМОС

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

Это означает, что объекты Расход и Приход являются авторизованными информацией о Диспетчере и Администраторе. Объект номенклатура находится в отношении агрегатирования с объектами Расход и Приход, которые является справочниками системы.

Диаграмма развертывания (Рис 1.6) определяет размещение аппаратуры системы.

Рисунок 1.6 - Диаграмма развертывания системы поверки

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

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

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

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

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

На рис.1.8 Представлена диаграмма последовательности информационной системы поверки приборов химлаборатории Ставропольского КЦ по ГМОС, которая показывает последовательность действий в системе от введения пароля диспетчера и до выдачи поверенного прибора заказчику. Детально перечислены все операции, которые присутствуют на этом пути.



Рисунок 1.7- Диаграмма последовательности действия администратора системы

Рисунок 1.8 - Диаграмма последовательностей (sequencediagram)

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

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

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

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

Диаграмма взаимодействия (кооперации, collaborationdiagram)

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

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

Диаграмма состояний (statechartdiagram)

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

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

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

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

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

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

Диаграмма активности (деятельности, activitydiagram)

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

Существует огромное количество определений этого понятия. Вот одно из них:

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

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

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

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

2.1 Обоснование выбора СУБД для реализации автоматизированной системы

В индустрии СУБД для персональных компьютеров отразились тенденции нормализации систем (Rightsizing). В последнее время в этой области происходили два встречных процесса: 1) разукрупнение серверов БД - появление новых версий серверов БД Informix, Oracle и т.д. сначала в варианте для рабочих групп, а потом облегченные версии для одиночных персональных компьютеров;(2) укрупнение СУБД для персональных компьютеров - новые "персональные" СУБД и связанные с ними инструментальные средства развивались в сторону "истинно реляционных" СУБД, т.е. серверов БД, приложений клиент-сервер и инструментальных средств программирования 4GL и быстрой разработки RAD.

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

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

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

· Встроенная поддержка языка структурированных запросов SQL (StandardQueryLanguage) закладывает возможность масштабирования создаваемых файл-серверных приложений до уровня приложений клиент-сервер.

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

· Использование объектно-ориентированного языка разработки приложений (по крайней мере в части диалога) позволяет широко использовать механизм наследования и тем самым использовать ранее произведенные программные компоненты.

· Поддержка компонентно-ориентированного программирования дает возможность расширения приложений за счет использования готовых внешних визуальных объектов типа VBX и OCX (ActiveX).

· "Истинно реляционная" база данных представляет собой объединенный набор файлов, содержащий таблицы, индексы и т.п., что облегчает сопровождение БД и приложений и является основой для поддержки целостности данных.

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

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

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

· Хранение в БД описания проекта создаваемого приложения является прообразом репозитория инструментальных средств быстрой разработки RAD и CASE-систем.

Рассмотрим подробнее несколько примеров сравнительно новых инструментальных средств: MS Access 2.0, VisualFoxPro.

Пакет MS Access

MicrosoftAccess - первая СУБД для персональных компьютеров, созданная для работы в среде Windows и несущая в себе многие черты новых инструментальных средств для разработки файл-серверных приложений. Эта система ориентирована как на конечных пользователей, так и на профессиональных программистов, облегчая и тем, и другим разработку и доступ к БД, быстрое создание информационных приложений с графическим интерфейсом. Система может работать в следующих версиях операционных систем Windows. Пакет MicrosoftAccess полностью поддерживает кириллицу, в частности, сортировку данных в соответствии с русским алфавитом. MicrosoftAccess является составной частью семейства программ MicrosoftOffice. Все семейство основано на IntelliSense - интеллектуальной технологии, которая "чувствует", что нужно пользователю, и дает требуемый результат, автоматически выполняя рутинные операции и упрощая сложные задачи. Например, наличие десятков мастеров (Wizards), помогает автоматизировать массу операций от создания форм до написания программ. От пользователя требуется ответить лишь на несколько простых вопросов. Ниже приводится перечень некоторых необходимых мастеров:

· мастер TableWizards;

· мастер CommandButtonWizards;

· мастер FormWizards;

· мастер ReportWizards;

· мастер MailMergeWizards.

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

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

Мастера FormWizards и ReportWizards используются при создании сложных форм и отчетов. Для создания более простых форм и отчетов можно использовать такие функции как Автоформа (AutoForm) и Автоотчет (AutoReport).

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

MS Word можно также использовать для непосредственной работы с данными в Microsoft Access. В MicrosoftA ccess имеются службы Графического конструктора связей (GraphicalSystemRelationshipsBuilder) и Графического запроса (Graphicalquery). Эти средства позволяют не только создать базу данных, но и наглядно сконструировать ее, что приближает Microsoft Access к CASE-средствам. Графический конструктор связей позволяет интуитивно конструировать базу данных, используя мышь для организации связи между таблицами, а функция Графического запроса упрощает создание даже очень сложных запросов - все что нужно, это мышью соединить поля, которые нужно включить в запрос. В MicrosoftAccess существуют функции и технологии, увеличивающие скорость и упрощающие использование конечных средств. К ним относятся:

· технология Rushmore;

· быстрая сортировка (QuickSort);

· средство наиболее часто выполняемых запросов (TopValuequeries).

Технология Rashmore ускоряет выполнение запросов в 100 раз по сравнению с версией 1.0 MicrosoftAccess. Быстрая сортировка мгновенно сортирует данные пользователя. Средство поддержки наиболее часто выполняемых запросов позволяет быстро выбрать наиболее важные для пользователя данные (например, 10 основных заказчиков, 15 основных адресатов и т.д.).

В MicrosoftAccess имеется ряд средств для совместного использования информации с другими приложениями. OfficeLinks с применением технологии OLE 2.0 позволяет передавать информацию из одной программы в другую. С помощью кнопок AnalyzeIt и PublishIt пользователь может перенести данные в Excel или Word для анализа, включения в отчет или слияния с другими данными для отправки почты. Наличие кнопки MailIt облегчает обмен информацией с другими членами рабочей группы - пользователь может послать информацию через MicrosoftMail или другую программу электронной почты.

MicrosoftAccess может работать с большинством форматов файлов (напрямую или через импорт/экспорт) - это позволяет пользователю максимально использовать имеющиеся наработки, поскольку MicrosoftAccess обеспечивает полную поддержку Btriеve, dBASE III PLUS и dBASE IV, MicrosoftFoxPro 2.x, Paradox, Miсrosoft SQL Server, SYBASE SQL Server. Кроме того, возможно использование драйверов ODBC для доступа к другим базам данных.

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

Конструктор Меню (MenuBuilder) предоставляет графический инструментарий для создания меню без программирования. Скорость разработки в MicrosoftAccess можно повысить с помощью двух отдельно поставляемых пакетов: MicrosoftAccessSolutionsPack и MicrosoftAccessDeveloper'sToolkit. MicrosoftAccessSolutionsPack содержит четыре готовых универсальных приложения для информационного обеспечения бизнеса:

· SalesManager - облегчает хранение, отслеживание и нахождение информации о контактах с заказчиками и деловых возможностях;

· AssetTracker - помогает при учете и управлении активами;

· RegistrationDesk - упрощает рутинную, но необходимую работу по регистрации событий;

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

MicrosoftAccessDeveloper'sToolkit содержит инструменты, необходимые для создания приложений для MicrosoftAccess, такие как компилятор справок, исполняемая версия MicrosoftAccess, MicrosoftGraph, SetupWizard, документацию и пример программ создания объектов, обеспечивающих доступ к данным, мастеров и кнопок управления OLE 2.0, справочник по MicrosoftAccess (MicrosoftAccessLanguageReference) и Руководство для опытного пользователя (AdvancedTopics).

Система VisualFoxPro

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

Начнем со средств построения интерфейса и новых терминов, которые приходится осваивать разработчикам. VisualFoxPro уже не стоит особняком от остальных продуктов Microsoft, как это было в версиях 2.х. Интерфейс самого продукта и приложений, которые разрабатываются на его основе, соответствуют стандартам, принятым в комплексе программных продуктов MicrosoftOffice и в средствах разработки, подобных VisualBasic. Более того, VisualFoxPro полностью интегрируется с остальными приложениями MicrosoftOffice с помощью OLE Automation. Программа, написанная на VisualFoxPro, сможет полноценно общаться с MicrosoftWord, MicrosoftExcel и любыми другими приложениями, поддерживающими OLE 2.0. Как и прежде, поддерживается динамический обмен данными DDE.

Использование механизма наследования классов позволяет создавать произвольное число модифицированных форм; при корректировке исходного класса все изменения будут отражены в формах, построенных на его основе. В качестве объекта может выступать любой элемент формы, и это дает неограниченные возможности по модификации форм из программы. Возможность сохранить часто употребляемую форму как класс и строить на ее основе другие формы снимает проблему с параметризацией для приведения интерфейса в соответствие с новыми требованиями. В составе формы-класса может быть любой стандартный элемент интерфейса (кнопки, поля вывода, независимые и зависимые переключатели); в определении класса можно использовать и так называемые "OLE customcontrols - OCX", что позволяют делать только самые развитые средства программирования в стиле С++. Для начинающих предусмотрены уже знакомые с версии 2.6 "Мастера", которые облегчат построение формы, отчета, таблицы и запроса.