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

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

59

Реферат

ИНФОРМАЦИОННАЯ СИСТЕМА, ИНТЕРФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.

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

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

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

Abstract

KEY WORDS: INFORMATION SYSTEM, INTERFACE, REQUIREMENTS, LIFE-CYCLE MODEL, MODELING, DESIGN, IMPLEMENTATION, MODEL STRUCTURE, DATABASE, TESTING, PHYSICAL REPRESENTATIONS SYSTEM, LOGICAL PRESENTATION SYSTEM.

The degree project is executed on the theme "Development of an automated information system of accounting and analysis of the governing apparatus of public-private partnership "Forsyth Center".

The data sources were books, periodicals and electronic resources, which were used as the theoretical foundations of the issues addressed, and as practical guides for the project.

The project developed software for accounting and analysis of the governing apparatus.

Введение

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

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

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

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

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

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

реализовать базу данных и серверную часть информационной системы;

осуществить тестирование АИС;

провести оценку эффективности технологии разработки.

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

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

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

предоставление, сохранение отчетов голосования.

1. Разработка требований к программному обеспечению

Анализ существующих решений по автоматизации предметной области

В данном разделе я постарался рассмотреть внутреннее голосование по комитетам для членов ТК/ПК ИСО (Committee Internal Balloting - CIB), автоматизирующий в той или иной степени систему голосования.

Голосование CIB проходит по первым трем стадиям разработки международного стандарта ИСО. Доступ к голосованию пользователь получает в случае, если он зарегистрирован в Глобальной директории ИСО в качестве эксперта ГОСТ по интересующей его тематике с правом голосования. Обязательным является голосование в тех ТК/ПК ИСО, где ГОСТ Р. имеет статус P-member. Пользователь, зарегистрированный в ГД ИСО, получает уведомление о голосовании по электронной почте. Вход в систему электронного голосования CIB производиться путем авторизации в системе посредством ввода имени пользователя и пароль.

Рисунок 1.4 - Система электронного голосования CIB

Интерфейс электронной системы голосования CIB. представлен на рисунке 1. Перед пользователем системы отображается список всех документов, по которым в настоящее время проходит голосование. Если пользователь имеете право голосования только в определенных ТК/ПК ИСО, перед ним будут только те документы, которые касаются работы этих ТК/ПК ИСО. Так же в данной системе есть возможность просмотра документа, по которому в данный момент времени идет голосование, после чего пользователь принимает решение о непосредственном голосовании. Для голосования в системе представлено три варианта ответа:

«За».

«Против».

«Воздержаться».

Плюсы данной системы:

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

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

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

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

Проверяемость. Пользователь должен иметь возможность проверить правильно ли был учтён его голос;

Недостатками данной информационной системы является:

высокая стоимость системы;

наличие высокоскоростного подключения в интернет для режима постоянного доступа (on-line).

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

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

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

На диаграммах бизнес - вариантов использования представлены основные направления деятельности секретаря, председателя собрания и членов руководящего аппарата (рис. 1.1 - 1.3).

Рисунок 1.1 - Бизнес - варианты использования деятельности председателя

Рисунок 1.2 - Бизнес - варианты использования деятельности секретаря

Рисунок 1.3 - Бизнес - варианты использования деятельности членов руководящего аппарата

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

Проектирование автоматизированной информационной системы голосования будет основано на использовании объектно-ориентированного подхода с использованием Rational Rose Enterprise Edition (версия продукта покрывает весь спектр задач по проектированию, анализу и кодогенерации).

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

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

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

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

К основным достоинствам ООП относится:

сравнительная легкость, наглядность;

эффективность моделей;

использование методологии UML;

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

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

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

Сбор требований

Определение требований - это самый сложный и в то же время самый важный процесс во время разработки программно продукта. Определение требований может происходить на протяжении всего жизненного цикла продукта.[16]

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

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

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

Данный продукт должен обеспечивать:

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

непосредственное голосование по повестке дня;

вывод результата голосования;

хранение решений по заседаниям в базе данных;

вывод отчета по решениям заседаний на заданный период времени.

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

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

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

Спецификация требований

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

функциональные требования (Functionality)

требования удобства использования (Usability)

требования надежности (Reliability)

требования производительности (Performance)

требования возможности сопровождения (Supportability)

При этом в модели FURPS+ так же обозначены дополнительные условия, к которым относятся:

проектные ограничения;

требования управления системой;

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

физические требования;

юридические требования.

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

Таблица 1.1 - Категории описания требований

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

Таблица 1.2 - Функциональные требования

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

Анализ и моделирование требований

После того, как были определены и собраны требования для реализации программного модуля, спроектированные диаграммы бизнес-вариантов использования, представленные на рисунках 1.1 - 1.3, необходимо рассмотреть непосредственные требования, относящиеся к разрабатываемой АИС.

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

Рисунок 1.5 - Диаграмма вариантов-использования

Аттестация требований

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

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

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

Прототипы позволяют решать три основные задачи:

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

исследование альтернативных решений;

создание конечного продукта.

Перед началом создания прототипов создадим диаграмму состояний системы. Диаграмма используется для изучения взаимосвязей между основными элементами.[9,]

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

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

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

Далее разработаем диаграмму пользовательского интерфейса.

Рисунок 1.6 ? Диаграмма пользовательского интерфейса

Выводы

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

Проведен анализ бизнес-процессов деятельности руководящего аппарата, для которого разрабатывается АИС. Построены бизнес-варианты использования, описывающие основные направления деятельности сотрудников в целом и выявлены направления деятельности сотрудников руководящего аппарата ЧГП «Форсайт-центр».

Так же был проведен анализ требований к разрабатываемой АИС. Для определения требований был проведен опрос сотрудников руководящего аппарата ЧГП «Форсайт-центр» и выявлены направления деятельности руководящего аппарата. Результаты моделирования требований представлены в виде разработанных вариантов использования системы. Осуществлён процесс специфицирования требований. Итоговым шагом данного этапа стало выполнение аттестации требований посредством прототипирования. В результате проведенного анализа выявлено, что на первом этапе проектирования целесообразно, используя методологию проектирования предметной области, осуществить проектирование основных компонентов системы.

2. Проектирование информационной системы

Архитектурное проектирование

Основными программными архитектурами, реализуемыми в настоящее время, являются:

файл-серверная;

клиент-серверная;

многоуровневая.

Файл-сервер. Эта архитектура централизованных баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы централизованной базы данных. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных.[24] Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных. После завершения работы пользователи копируют файлы с обработанными данными обратно на сервер, откуда их могут взять и обработать другие пользователи. Такая организация ведения данных обладает рядом недостатков, например, при одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, так как необходимо дождаться, пока пользователь, работающий с данными, завершит работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями, внесенными другими пользователями.

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку данных на центральный сервер.[24] Кроме того, рассматриваемый подход позволяет избежать конфликтов изменений одних и тех же данных множеством пользователей, которые характерны для технологии файл-сервер. Технология клиент-сервер реализует согласованное изменение данных множеством клиентов, обеспечивая автоматическое соблюдение целостности данных. Эти и некоторые другие преимущества сделали технологию клиент-сервер очень популярной. К недостаткам этой технологии можно отнести высокие требования к производительности центрального сервера. Чем больше клиентов обращается к серверу, и чем больше объем обрабатываемых данных, тем более мощным должен быть центральный сервер.

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

Рисунок 2.1 ? Традиционное решение в архитектуре клиент-сервер

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

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

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

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

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

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

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

На рисунке 2.2 изображена диаграмма компонентов АИС.

Рисунок 2.2 ? Диаграмма компонентов информационной системы

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

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

Рисунок 2.3 ? Диаграмма размещения информационной системы

Модули, с одной стороны, являются сервером для клиентского приложения, обеспечивающего управление объектами предметной области, а с другой стороны, выступают как клиенты при взаимодействии с MS SQL Server. Для осуществления взаимодействия модулей с сервером БД используется модель доступа.NET-приложений к данным - ADO.NET, которая для доступа к источникам данных, использует провайдер OLE DB. Архитектура доступа к данным этих модулей представлена на рисунке 2.4.

Рисунок 2.4 - Универсальная архитектура доступа к данным в ado.net

Проектирование пользовательского интерфейса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вид данных с точки зрения каждого пользователя;

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

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

Процесс проектирования базы данных состоит трех основных фаз:

концептуального проектирования;

логического проектирования;

физического проектирования.

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

Концептуальная модель данных представляет собой набор ее сущностей и связей (отношений), другими словами, это доменная модель, которая содержит только сущности системы и взаимосвязи между ними.[1]

Сущность (entity) - это отдельный тип объекта (сотрудник, место или вещь, понятие или событие) организации, который должен быть представлен в базе данных. Отношением называется связь между элементами. (relationship). Иначе связь - это то, что объединяет несколько сущностей. На рисунке 2.5 изображена концептуальная модель данных разрабатываемой АИС.

Рисунок 2.5 - Концептуальная модель данных

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

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

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

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

Атрибутом (attribute) называется свойство, которое описывает некоторую характеристику описываемого объекта.[20] Класс (объект) может, иметь любое число атрибутов или не иметь их вовсе.

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

Рисунок 2.6 ? Логическая модель данных

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

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

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

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

На рисунке 2.7 изображена физическая модель данных, реализованная в MS SQL Server 2005 при помощи инструмента SQL Server Management Studio, входящий в пакет инструментов MS SQL Server 2005.

Рисунок 2.7 - Физическая модель данных

В качестве базы данных была выбрана СУБД Microsoft SQL Server 2005. Данный выбор был обусловлен наличием у этой версии СУБД развитых средств службы уведомлений и службы отчетности. Данные средства необходимы для реализации полного соответствия работы системы голосования и принципа осуществления данного бизнес-процесса руководящего аппарата частно-государственного партнерства «Форсайт центр». Кроме того, в настоящее время наиболее широко используемой является версия MS SQL Server 2005. В состав Microsoft SQL Server 2005 входят простые утилиты администрирования (Enterprise Manager), сервисы преобразования данных (Data Transformation Services), облегчающие перенос данных в SQL Server из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД).

Из особенностей так же можно выделить:

масштабируемость и надежность. SQL Server 2005 обеспечивает практически неограниченный рост объемов данных за счет увеличения надежности и масштабируемости системы, используя все преимущества мультипроцессорной обработки данных. SQL Server 2005 Enterprise Edition обеспечивает параллельность обработки данных;[30]

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

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

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

высокоуровневый язык программирования MS Visual C# 2008;

MS SQL Server 2005;

Rational Rose Enterprise Edition 2007;

ERWin Data Modeler 7.3.

Для разрабатываемой информационной системы выбрана платформа Microsoft Visual Studio 2008. В качестве языка реализации приложения выбран C#.

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

Основные возможности.NET следующие:

полные возможности взаимодействия с существующим кодом;

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

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

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

отсутствует сложность СОМ;

действительное упрощение процесса развертывания приложения.

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

Проектирование модулей (объектно-ориентированные модели)

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

Проектирование ИС предполагает решение следующих вопросов:

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

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

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

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

определение с учётом ограничений налагаемые на архитектуру компонентов проектируемой системы, построение диаграммы компонентов;

модель проектирования представляется в виде UML-диаграмм, схем, рисунков и описаний.

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

Рисунок 2.8 - Диаграмма состояний системы

Рисунок 2.9 - Диаграмма классов системы

Таблица 2.1 - Соответствие между сущностями, формами и таблицами в БД

Выводы

Во втором разделе проектирование автоматизированной системы учета и анализа деятельности руководящего аппарата ЧГП «Форсайт-центр». Разработана архитектурная модель проектирования и компонентная модель. Так же на данном этапе были построены модели логического и физического представления подсистемы. На основе данных моделей была разработана база данных подсистемы.

Описано проектирование модулей подсистемы, показано логическое представление основных компонентов системы как независимых *.exe файлов, реализующих функциональность основных понятий предметной области. Разработаны диаграммы классов для системы учета и анализа деятельности. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2008, так же в качестве СУБД было выбрано Microsoft SQL Server 2005. В качестве языка реализации приложения выбран высокоуровневый язык программирования C#.

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

Реализация приложения

Реализация программного обеспечения - это процесс перевода системной спецификации в работоспособную систему.[26]

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

высокоуровневый язык программирования MS Visual C# 2008;

MS SQL Server 2005.

Разработка набора элементов программного проекта реализовывалась в едином рабочем пространстве. На рисунке 3.1 показана система классов глобальных функций и интерфейсов АИС.

Рисунок 3.1 ? Рабочее пространство проекта подсистемы

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

входящий в состав Microsoft.NET Framework SDK v2.0. В данном проекте использовалось следующее пространственное имя для подключения к базе данных:

59

Загрузку данных из базы данных осуществляет следующая функция:

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

При отображении формы во время выполнения программы, этот класс будет использоваться как шаблон для отображения окна. Файлы С# имеют расширение «.cs». Код главной формы модуля информационной системы содержит в себе файл MainForm.cs (рисунок 3.2). Остальные фрагменты кода приложения приведены в приложении Г. Данная форма является главной, запускающей дочерние окна данного модуля. Класс реализации формы MainForm.Designer.cs изображен на рисунке 3.2.

Рисунок 3.2 ? Инициализация компонентов формы mainform.cs

Взаимодействие приложения с источниками данных

Взаимодействие приложения с источником данных осуществляется при помощи запросов языка SQL. SQL (Structured Query Language) является инструментом для выборки и обработки информации, содержащейся в базе данных. SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных.[20] Если пользователю необходимо получить информацию из базы данных, он запрашивает её у СУБД при помощи SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю. Процесс запрашивания данных и получения результата называется запросом к базе данных. SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляют пользователю:

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

выборка данных;

обработка данных;

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

управление доступом;

целостность данных.

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

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

уменьшение сетевого трафика;

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

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

автоматическая настройка параметра запроса;

обеспечение модульной структуры приложения;

совместное использование в нескольких приложениях;

авторизованный и единообразный доступ к объектам базы данных;

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

Рисунок 3.3 ? Инициализация соединения приложения с базой данных

Взаимодействие приложения с базой данных осуществляется через модель ADO.NET, обеспечивающего соединение с источником данных. В основе модели ADO.NET лежит простой набор классов, наиболее важным из них является DataSet - образ реляционной базы данных. Так же ADO.NET использует объект типа TableAdapter как мост между DataSet и источником данных. TableAdapter содержит метод Fill() для обновления данных из базы и заполнения DataSet. [29]

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

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

Следующим шагом является создание запроса, удовлетворяющего нашим условиям. Запрос создается по таблице «Agenda» (Повестка дня). Суть запроса состоит в том, что бы добавить в таблицу такие данные как повестка дня, председатель, место заседания и дату заседания. На рисунке 3.4 показан составленный запрос.

Рисунок 3.4 - Запрос на формирование плана заседаний

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

Тестирование приложения

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

Тестирование - это проверка работы программ с данными, подобным реальным, которые будут обрабатываться в процессе эксплуатации системы. Процесс тестирования программного обеспечения осуществляется на основе фактических или смоделированных входных данных (как стандартных, так и не стандартных) при определённых контролируемых условиях.[13]

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

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

тестирование дефектов обусловленных ошибками в программе (синтаксические ошибки, ошибки периода выполнения, логические ошибки);

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

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

Тестирование приложения проводилось с помощью стандартных инструментов предоставляемых Microsoft Visual Studio 2005.

Режим пошагового исполнения кода позволяет построчно анализировать программу для диагностики и исправления ошибок. Visual Studio 2005 предоставляет несколько вариантов пошагового исполнения:

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

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

Step Out исполняет текущую функцию до конца и останавливается (если возможно) на следующей строке функции, из которой была вызвана текущая процедура;

Run To Cursor позволяет установить курсор в некоторую строку и исполнить весь код до этой строки;

Set Next Statement (назначить следующий оператор) позволяет назначить следующий оператор для исполнения, при этом все строки до этого оператора будут пропущены.

Точки прерывания -- это строки кода, назначенные во время отладки, по достижении которых исполнение останавливается, а приложение переходит в режим пошагового исполнения. Для точек прерывания можно назначать дополнительные условия, определяющие обстоятельства, при которых эти точки активируются. Для управления точками прерывания предназначено окно Breakpoints, позволяющее создавать, отключать и удалять их [25,26,29].

Visual Studio 2005 предоставляет ряд инструментов для наблюдения за исполнением программы. Окна Locals, Autos и Watch позволяют отслеживать значения переменных программы во время ее исполнения; окно Command позволяет исполнять код и получать значения переменных и свойств. Имеются также дополнительные окна для наблюдения за самыми разными данными приложения.

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

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

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