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

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

1

МИНОБРНАУКИ РОССИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

"САМАРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ"

Факультет автоматики и информационных технологий

Кафедра "Вычислительная техника"

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

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

Самара 2013



Реферат

Пояснительная записка содержит 82 страницы, 30 иллюстраций, 2 таблицы и 1 приложение. Графический материал выполнен на 7 листах формата A1.

Ключевые слова: информационная система, базы данных, СУБД, плагин.

Целью данного дипломного проекта является разработка информационной системы бурового предприятия. Программа реализована на языке C#, в качестве СУБД используется Microsoft Windows SQL Server 2008 Express.

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



• Введение
• 1. Анализ предметной области
• 1.1 Классификация информационных систем
• 1.2 Средства разработки
• 2. Реализация информационной системы
• 2.1 Общая архитектура информационной системы
• 2.2 Диаграмма прецендентов
• 2.3 Разработка графического интерфейса пользователя
• 2.4 Компоненты системы
• 2.5 Разработка диаграмм классов
• 2.6 Выбор СУБД
• 2.7 Разработка базы данных
• 2.7.1 Разработка хранимых процедур
• 2.7.2 Проектирование отчётов
• 2.7.3 Разработка скриптов
• 2.8 Разработка диаграммы развёртывания
• 3. Расчёт экономических показателей
• 3.1 Затраты на разработку
• 3.2 Оценка издержек
• 3.2.1 Постоянные затраты
• 3.2.2 Переменные затраты
• 3.3 Определение результатов применения проекта
• 3.4 Определение окупаемости проекта
• 4. Охрана труда
• 4.1 Опасные и вредные производственные факторы
• 4.2 Обеспечение нормальной работоспособности при работе с ПО
• Заключение
• Список использованных источников
• Приложение


Введение

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

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

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

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

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

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



1. Анализ предметной области

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

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

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

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

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

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

В качестве второго примера рассмотрим информационную систему предприятий нефтепродуктообеспечения Сибинтек.

Эта система позволяет:

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

Р и с у н о к 1 - Выбор расписания в ИС ЮРГУЭС

- организовать информационное взаимодействие с системами управления АЗК;

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

- организовать мониторинг данных об аварийных ситуациях на АЗК и работах по их устранению, обеспечение эффективного взаимодействия с сервис-провайдерами;

- вводить паспорта объектов НПО;

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

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

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



Р и с у н о к 2 - Форма "Остатки"

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

Р и с у н о к 3 - Диаграмма реализации НП



Р и с у н о к 4 - График выполнения плана

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

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

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

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

1.1 Классификация информационных систем

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

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

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

- стратегического уровня;

- управленческого уровня;

- уровня знаний;

- эксплуатационного уровня.

Информационные системы первого типа предназначены для руководства высшего уровня. Основная задача таких систем - помощь при осуществлении прогнозирования развития организации на несколько лет вперёд.

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

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

Р и с у н о к 5 - Информация о скважинах в WellOnline

Рисунок 6 - Соотнесение типов ИС и персонала



Третий тип систем необходим для документооборота на предприятии.

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

Так же информационные системы классифицируются по архитектуре:

- настольные (локальные ИС);

- распределённые.

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

Р и с у н о к 7 - Типы информационных систем и поддерживаемые ими решения



Классифицируются ИС так же и по уровню автоматизации:

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

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

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

Классификация информационных систем по охватываемым задачам:

- персональная - предназначена для решения задач конкретного человека;

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

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

1.2 Средства разработки

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

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

Следуя этим критериям, мной был выбран язык C# и как среда разработки - Visual Studio 2010, имеющая удобный интерфейс взаимодействия с СУБД. Так, Visual Studio имеет удобный редактор кода с подсветкой синтаксиса и поддержкой технологии IntelliSense, позволяющей тратить меньше времени на написания длинных имён переменных, дописывает название функции при вводе начальных букв. Кроме прямого назначения IntelliSense используется для доступа к документации и для устранения неоднозначности в именах переменных, функций и методов, используя рефлексию. Так же эта среда разработки включает встроенный дизайнер схем баз данных и компоненту для подключения к различным СУБД, изображённый на рисунке 8.

Visual Studio и язык C# обеспечивают полную поддержку технологии .Net Framework. Так уже имеется огромное количество стандартных библиотек, входящих в .Net для работы с базами данных. Например, C-Sharp был выбран благодаря поддержке такой удобной технологии как LINQ - Language Integrated Query, позволяющей использовать запросы, синтаксически близкий к SQL при обращении к данным как внутри приложения, так и к СУБД. Библиотека LINQ включает в себя инструмент SQLMetal, который позволяет автоматически генерировать классы непосредственно из поддерживаемых .NET Framework баз данных, что дает возможность очень быстро и просто интегрировать в код сущности базы данных.

информационный интерфейс затрата скрипт



Р и с у н о к 8 - Дизайнер схемы базы данных и компонента Server Explorer



2. Реализация информационной системы

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

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

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

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

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

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



2.1 Общая архитектура информационной системы

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

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

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

- настольная архитектура (рисунок 9);

- распределённая архитектура (рисунок 10).

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

Р и с у н о к 9 - Настольная архитектура приложения



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

Р и с у н о к 10 - Многозвенная архитектура с сервером приложений в качестве посредника

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

Преимущества системы:

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

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

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

- позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.;

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

Недостатки:

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

- поддержка работы данной системы требует отдельного специалиста -- системного администратора;

- высокая стоимость оборудования.

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

Разработка локальных хранилищ и базы данных на сервере это фактически отдельный этап проектирования системы, но в то же время их разработка является частью проектирования общей архитектуры. Так что следует упомянуть и эту часть информационной системы. Так, в качестве СУБД используется Microsoft SQL Server Express - бесплатная версия системы управления реляционными базами данных Microsoft SQL Server. Основным языком запросов этой СУБД является Transact-SQL, который является реализацией стандарта ANSI/ISO по структурированному языку запросов.

Р и с у н о к 11 - Архитектура ИС

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

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

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

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

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

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

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

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

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

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

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

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

- обобщение - моделирует соответствующую общность ролей.

Так как информационная система состоит из клиентского и серверного приложения, то для каждого была составлена своя диаграмма. На рисунках 12 и 13 представлены диаграммы USE CASE для клиентского и серверного приложений информационной системы.

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

2.3 Разработка графического интерфейса пользователя

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

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

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

Р и с у н о к 12 - диаграмма прецедентов для серверного приложения



Р и с у н о к 13 - диаграмма прецедентов для клиента

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

Основной идеей, использовавшейся при создании интерфейса пользователя, была концепция DWIM. DWIM (Do What I Mean) в переводе с английского означает - делай то, что я имею ввиду, то есть подразумевает максимально простые для понимания метафоры, использующиеся при визуализации элементов управления. В пример следования этому принципу можно привести всем знакомую иконку дискеты (рисунок 15), которую зачастую используют на элементе интерфейса отвечающего за сохранение текущего состояния документа. Так, в информационной системы были использованы соответствующие пиктограммы для обозначения действия, которое произойдёт при использовании выбранного элемента интерфейса.

Основными критериями при разработке данного графического интерфейса пользователя были:

- устранение отвлекающих и ненужных элементов из интерфейса;

- обеспечение обратной связи с пользователем;

- избегание ошибок и обеспечение простоты их обработки.

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



Р и с у н о к 14 - Форма "Древо скважин"

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

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

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



2.4 Компоненты системы

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

Р и с у н о к 15 - Пример использования интуитивно понятных иконок для элементов графического интерфейса пользователя



Р и с у н о к 16 - Редактор форм Visual Studio 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными концепциями ООП являются:

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

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

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

Полиморфизм -- это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

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

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

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

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

Рассмотрим реализацию некоторых функций серверного приложения. Так взаимодействие с базой данных осуществляется через объект DataSet, предоставляющий элементы структуры базы данных в виде объектов DataTable и DataRow. Процесс работы с данными в DataSet'e можно разбить на несколько этапов:

- создание объекта DataSet и заполнение каждого объекта DataTable данными из источника с помощью класса DataAdapter;

- изменение данных в каком либо объекте DataTable;

- вызов метода GetChanges для создания второго класса DataSet, отображающего только изменения данных;

- вызов метода Update класса DataAdapter путем передачи второго класса DataSet в качестве аргумента;

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

- вызов метода AcceptChanges для класса DataSet. В противном случае можно вызвать метод RejectChanges, чтобы отменить изменения.

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



Р и с у н о к 17 - Взаимодействие классов

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

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

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

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

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

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

Интерфейс IPlugIn описывает все необходимые свойства и функции необходимые для работы с данными. Схема использования интерфейса изображена на рисунке 18.

Р и с у н о к 18 - Схема реализации расширений

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

2.5 Разработка диаграмм классов

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

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

Такие диаграммы включают в себя несколько элементов, таких как:

- класс;

- отношения между классами.

Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Каждый класс имеет своё уникальное имя в данном пространстве имён, так же на диаграмме указываются атрибуты данного класса и его методы. Методы могут указываться с указанием входных и выходных параметров, а так же уровнем доступа к данному методу. Пример взаимодействия методов внутри класса представлен на рисунке 19.

Отношения между классами делятся на:

- ассоциации;

- наследование;

- зависимость.

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

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

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

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

Р и с у н о к 19 - Пример взаимодействия методов внутри класса

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



2.6 Выбор СУБД

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

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

Выбранная СУБД должна отвечать ряду критериев, которые можно было бы объединить в несколько групп:

- моделирование данных;

- особенности архитектуры и функциональные возможности;

- контроль работы системы;

- особенности разработки приложений;

- производительность;

- надежность;

- требования к рабочей среде;

- смешанные критерии.



Р и с у н о к 20 - Внутренне устройство класса WorkWithData

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



Р и с у н о к 21 - Диаграмма взаимодействий класса WorkWithData

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

Контроль работы системы - возможность ограничения потребляемых СУБД ресурсов.

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

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

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

К смешанным критериям можно отнести наличие качественной и доступной документации, локализацию как документации, так и СУБД.

Всем этим критериям полностью соответствует система управления реляционными базами данных, разработанная корпорацией Microsoft - Microsoft SQL Server. Эта СУБД так же имеет бесплатную Express версию, полностью удовлетворяющую приведённым запросам. Так как помимо разработки СУБД корпорация Microsoft является так же автором операционных систем Windows и средств разработки под них, было бы естественно предположить полную поддержку системой управления базами данных необходимой операционной системы, а так же наличия полного набора средств разработки. Помимо прочего данная СУБД обладает общедоступной библиотекой описаний тех или иных возможностей полностью переведённой на русский язык.



2.7 Разработка базы данных

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

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

Основными этапами разработки любой базы данных являются:

- концептуальное (инфологическое) проектирование;

- логическое (даталогическое) проектирование;

- физическое проектирование;

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



Р и с у н о к 22 - Таблица Equipments

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

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

Р и с у н о к 23 - Схема внутреннего представления данных клиентского приложения



Физическое проектирование - это создание схемы базы данных уже под конкретную выбранную СУБД. Такое проектирование учитывает все возможные ограничения, задаваемые СУБД, так например, некоторые системы управления базами данных налагают определённые ограничения на наименование объектов или их типизацию. Так же следует учитывать специфику выбранной СУБД на физическом уровне. Например, это определение критериев управления дисковой памятью, методов доступа к данным. Схемы баз данных, разработанных для MS SQL Server 2008 Express представлены на рисунках 24 и 25.

2.7.1 Разработка хранимых процедур

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