Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

Данный дипломный проект содержит 86 листов текста диплома, 18 рисунков, 4 таблицы, 5 приложений, 39 источников литературы.

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

Темой дипломного проекта является «Информационная система учета призывников в администрации (на примере администрации с. Казинка)».

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

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

СОДЕРЖАНИЕ

• Введение
• 1. Разработка требований к программному обеспечению
• 1.1 Анализ существующих решений по автоматизации предметной области
• 1.3 Сбор требований
• 1.4 Спецификация требований
• 1.5 Аттестация требований
• 1.6 Выбор методологии проектирования информационной системы
• 2. Проектирование информационной системы
• 2.1 Архитектурное проектирование
• 2.2 Проектирование интерфейса информационной системы
• 2.3 Проектирование баз данных
• 2.4 Обоснование выбора платформы создания информационной системы
• 2.5 Проектирование модулей (объектно-ориентированные модели)
• 3. Реализация и аттестация информационной системы
• 3.1 Реализация приложения
• 3.2 Взаимодействие приложения с источниками данных
• 3.3 Тестирование приложения
• 3.4 Методика развертывания приложения
• 4. Управление информационным проектом
• 4.1 Выбор жизненного цикла разработки ПО
• 4.2 Определение цели и области действия программного проекта
• 4.3 Создание структуры пооперационного перечня работ
• 4.4 Идентификация задач и действий
• 4.5 Оценка размера и возможности повторного использования
• 4.6 Оценка длительности и стоимости разработки проекта
• 4.7 Распределение ресурсов проекта
• 4.8 Оценка экономической эффективности проекта
• ЗАКЛЮЧЕНИЕ
• Список литературы
• ПРИЛОЖЕНИЕ А - Спецификация требований к программному обеспечению
• ПРИЛОЖЕНИЕ Б - Прототиты пользовательского интерфейса
• ПРИЛОЖЕНИЕ В - Атрибуты управляющих таблиц проектируемой ИС
• ПРИЛОЖЕНИЕ Г - Выбор модели жизненного цикла
• ПРИЛОЖЕНИЕ Д - Диаграмма Гантта
• ВВЕДЕНИЕ

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

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

Далее описывается значимость ИС для данной сферы деятельности. Основные решаемые задачи.

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

Программа должна обеспечивать:

ѕ работу с входными данными (полная информация о лице подлежащему призыву на обязательную воинскую службу);

ѕ получение выходных документов (структурированная информация содержащая вcе необходимые сведения о военнообязанных лицах);

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

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

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

ѕ провести анализ бизнес-процессов воинского учета;

ѕ исследовать информационные потоки, возникающие в системе;

ѕ разработать концептуальную и логическую модели данных;

ѕ разработать программное обеспечение для АРМ воинского учета;

ѕ провести оценку экономической эффективности информационной системы.

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

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

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

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

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

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

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

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

ѕ Федеральный закон от 26 февраля 1997 года № 31-ФЗ "О мобилизационной подготовке и мобилизации в Российской Федерации";

ѕ Постановление Правительства РФ от 25 декабря 1998 года № 1541 "Об утверждении положения о воинском учете".

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

ѕ Данные для постановки на учет в военкомате;

ѕ Численность граждан запаса (формы №6 и 11/МУ);

ѕ Список граждан, подлежащих постановке на воинский учет;

ѕ Список принятых и уволенных военнообязанных;

ѕ Список юношей 15-16 лет;

ѕ Список для первоначальной постановки юношей на воинский учет;

ѕ Список принятых и уволенных призывников

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

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

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

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

К еще одной информационной системе на которую стоит обратить внимание, можно отнести программный продукт ООО Научно-производственного центра «КОСМОС-2», Автоматизированная информационная система (АИС) Сельского Административного образования (САО) сокращенно (АИС САО) [2]. Система служит для автоматизации хозяйственной деятельности, похозяйственной книги, операций, выполняемых работниками муниципальных сельских администраций:

ѕ ведение похозяйственного учета (в объеме книги похозяйственного учета)

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

ѕ учет земельных участков и объектов недвижимости на территории, прав жителей на эти объекты,

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

ѕ подготовка данных для заполнения форм статистической отчетности, делопроизводство в Администрации,

ѕ оформление и печать справок, выписок, постановлений,

ѕ регистрации пребывания граждан с подготовкой пакета документов,

ѕ воинский учет с подготовкой пакета документов (повестки, акты, анкета).

Система имеет многоуровневую структуру, объединяя 9 Автоматизированных Рабочих Мест (АРМ), в число которых входит АРМ «Данные о жителях»

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

ѕ Подготовка и печать произвольных списков жителей. Как частный случай - подготовка списка призывников.

ѕ Получать данные о собственности как отдельных персоналий, так и всей семьи (т.е. для членов хозяйства как для сельских подворий, так и для подворий МКД).

ѕ Подготовка списков юбиляров.

ѕ Учет и оформление документов по регистрации граждан.

В том числе:

ѕ Учет и оформление документов по воинскому учету.

К недостатками данной системы можно отнести:

ѕ Относительно высокая стоимость продукта;

ѕ Наличие специалиста для конфигурирования системы.

К последней информационной системе, которая будет рассмотрена в данном дипломном проекте, относится программный продукт ЗАО ИВЦ ИНСОФТ «Система Персонального Учета Населения» (СПУН). Система Персонального Учета Населения создана с целью формирования информационной базы для реализации процедур регистрации в рамках решаемых различными ведомствами задач Российской Федерации. В рамках данной системы имеется конфигурация для регистрация граждан, имеющих статус военнообязанных. Система обладает необходимым набором средств для учета и оформление документов по воинскому учету[3].

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

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

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

Анализ предметной области необходимо проводить для:

ѕ Определения функциональной направленности предприятия;

ѕ Определения перечня структурных звеньев предприятия.

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

Организационная структура сельской администрации представлена на рис. 1.1:

Рисунок 1.1 - Организационная структура администрации

Ниже перечислены функции подразделений администрации:

ѕ бухгалтерия - начисление заработной платы, расчет платежами между организациями, ведение отчетности по налогам и сборам.

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

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

ѕ отдел общего назначения - паспортный режим, прописка, выписка и т.д.

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

Основными функциональными задачами отдела воинского учета являются:

ѕ Постановка граждан на первоначальный воинский учет;

ѕ Снятие с учета по причине смены места жительства;

ѕ Снятие с учета по достижении возраста 50 лет;

ѕ Ведение реестра граждан, подлежащих призыву;

Моделирование бизнес процессов отдела воинского учета проведено с использованием CASE-средства RanionalRose [5,6]. Разработанная диаграмма бизнес-вариантов использования представлена на рис. 1.2. Она отображает перечисленные выше функциональные задачи отдела и показывает основные бизнес-актеров данного процесса.

Рисунок 1.2 - Диаграмма бизнес-вариантов использования отдела воинского учета.

После завершения изучения предметной области следует перейти к процессу определения требований.

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

В данном проекте для сбора требований была выбрана методика «Интервьюирование» которая рассматривает следующие этапы:

1. Разрабатываются вопросы

2. Производится выбор опрашиваемых пользователей.

3. Планируются контакты.

4. Проводится интервью.

5. Завершается встреча.

6. Определяются последующие действия.

А так же определены функциональные, системные требования и требования к интерфейсу системы:

В процессе формирования требований принимали участие следующие лица:

ѕ Глава администрации;

ѕ Инспектор ВУС (Военно-учетного стола отдела воинского учета);

ѕ Специалист первой категории администрации.

На рисунке 1.3 представлена диаграмма вариантов использования ИС [5], представляющая процессы, происходящие в ИС отдела воинского учета.

Рисунок 1.3 - Диаграмма вариантов использования ИС отдела воинского учета.

Определение корректных требований -- ответственный этап программного проекта. Формат проекта должен соответствовать требованиям к ПО, собранным командой разработчиков или одним разработчиком, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - Software Requirements Specification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний. Аттестация -- это оценка качества работы менеджеров проекта. Она определяет степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые используются в качестве критериев при аттестации [7].

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

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

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

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

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

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

В SRS документе рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании можно производить расширение завершенного продукта.

Спецификация требований к реализуемому программному обеспечению представлена в ПРИЛОЖЕНИИ А.

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

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

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

Прототип основного меню данного модуля представлен на рисунке 1.4.

Рисунок 1.4 - Схема основного меню программы

Интерфейс этого модуля должен обеспечить следующие возможности пользователя:

ѕ Создание новой записи о гражданине.

ѕ Загрузки данных из базы данных «Призывник» и действия с данными;

ѕ Загрузки данных из базы данных «Запасник» и действия с данными;

ѕ Загрузки данных из базы данных «Снятые с учета» и действия с данными;

ѕ Загрузки данных из базы данных «Служащие в армии» и действия с данными;

ѕ Загрузки данных из базы данных «Непригодные к службе» и действия с данными.

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

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

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

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

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

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

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

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

Архитектуры информационной системы требуется соблюдение следующих условий:

ѕ соответствие с миссией организации;

ѕ определенность в требованиях;

ѕ направленность в разработке;

ѕ возможность к адаптации;

ѕ необходимость гибкости.

Соблюдение всех этих условий позволяет разработать архитектуру информационной системы организации более совершенной и эффективной [15,17].

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

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

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

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

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

1. Многопользовательская работа с локальными таблицами на файл-сервере. В этом случае система Контур Стандарт и файл OLAP-приложения размещаются на клиентском компьютере, а таблицы исходных данных на файл-сервере. Это удобно, когда одни и те же исходные данные используются для выполнения различных видов анализа разными пользователями. Например, учетные данные, выгруженные из OLTP-системы в dbf-файл, анализируют бухгалтер и руководитель, причем каждый из них работает со своим аналитическим приложением.

2. Многопользовательская работа с OLAP-приложениями и исходными данными в виде локальных таблиц на файл-сервере. Тогда на компьютере пользователя устанавливается только Контур Стандарт с OLAP-машиной. Такая архитектура обеспечивает работу группы пользователей (например, бухгалтерии) с одним и тем же аналитическим приложением. Доступ пользователей группы к файлу OLAP-приложения регламентируется средствами операционной системы [4].

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

ѕ набор серверов, предоставляющих информацию или другие услуги программам, которые обращаются к ним;

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

ѕ сеть, которая обеспечивает взаимодействие между клиентами и серверами

На рисунке 2.1 представлена схема клиент-серверной архитектуры.

Рисунок 2.1 - клиент-серверная архитектура.

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

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

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

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

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

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

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

Архитектура приложения, разделяющая пользовательские и прикладные сервисы и сервисы данных. Другое название - трехуровневая архитектура, однако термин «многоуровневая» корректнее, поскольку он предполагает, что при логическом проектировании может возникнуть более трех уровней сервисов. МНОГОУРОВНЕВАЯ АРХИТЕКТУРА ПРИЛОЖЕНИЯ (multi-tiered architecture), способ организации взаимодействия программ или компонентов программы. Как правило, Многоуровневая архитектура приложения используется в распределенных приложениях, компонеты которых выполняются на разных компьютерах. Частным случаем Многоуровневая архитектура приложения является архитектура клиент-сервер. В последнее время в информационных системах получила распространение архитектура, в которой распределенное приложение состоит из компонентов трех уровней:

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

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

ѕ компонент, реализующий интерфейс с пользователем, исполняется на рабочей станции [4].

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

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

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

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

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

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

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

Диаграмма компонентов системы представлена на рисунке 2.2.

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

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

Диаграмма размещения представлена ниже на рисунке 2.3.

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

Разработка пользовательского интерфейса включает те же основные этапы, что и разработка программного обеспечения:

1. Определение типа интерфейса и общих требований к нему.

2. Определение сценариев использования.

3. Определение пользовательской модели интерфейса.

4. Программирование и тестирование программных интерфейсов.

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

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

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

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

Пользовательский интерфейс проектируемой информационной системы имеет следующую структуру: после запуска приложения открывается главная форма, которая содержит основное меню, состоящее из 3-ти пунктов меню: Файл, Данные, Помощь. Прототип пользовательского интерфейса ПРИЛОЖЕНИИ Б.

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

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

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

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

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

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

База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам [14,16].

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

Реализация логической модели начинается с определения концептуальной модели, определяющей основные сущности, сохраняемые в виде таблиц реляционной базы данных. ПРИЛОЖЕНИЕ В.

На рисунке 2.4 пример концептуальной модели, на базе анализа сущностей

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

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

На рисунке 2.5 пример логической модели, на базе анализа сущностей

Рисунок 2.5 - Логическая модель данных ИС.

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

Физической СУБД для ИС отдела воинского учета выбрана СУБД Microsoft SQL Server 2005 . Этот выбор осуществлен потому, что приложение будет функционировать на нескольких рабочих станциях используя базу данных одновременно по локальной сети. Также следует отметить, что СУБД MS SQL Server положительно зарекомендовала себя в процессе эксплуатации.

СУБД MS SQL Server компании Microsoft начала разрабатываться в 1988 и изначально предназначалась для платформы OS/2 [19,20]. Последующие версии этого сервера баз данных предназначались для платформы Windows NT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускаются и не выпускались.

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

Клиентские приложения для Microsoft SQL Server и MSDE можно создавать как с помощью средств разработки Microsoft - Visual Basic, Visual C++, С#, Access и Visual FoxPro, так и с помощью средств разработки других производителей. Для этой цели имеются ODBC-драйвер и OLE DB-провайдер, а также содержащий их набор библиотек Microsoft Data Access Components (MDAC), позволяющий использовать в средствах разработки объекты ActiveX Data Objects (ADO) - COM-объекты для доступа к данным. MDAC является составной частью Windows XP, а для пользователей других Windows-платформ доступен отдельно на Web-сайте Microsoft.

В отличие от Oracle, Microsoft не производит средств разработки, использующих тот же самый язык программирования, что и язык для создания кода триггеров и хранимых процедур, однако производит средства отладки серверного кода (например, SQL Server Debugger входит в состав Visual Basic и Visual C++).

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

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

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

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

Рисунок 2.6 - Схема физической модели данных для ИС отдела воинского учета

В настоящее время обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули. Примером могут служить все современные пакеты для разработчиков - Borland Delphi, ,Microsoft Visual Studio 2005 и т.д.

Чтобы средства разработки и технологии отвечали требованиям разработчиков, в корпорации Майкрософт была создана совершенно новая модель программирования для доступа к данным, основанная на .NET Framework. Построение на основе .NET Framework гарантирует единообразие доступа к данным: компоненты используют систему общих типов, общие шаблоны разработки и соглашения о пространствах имен [24,25].

В .NET Framework поддерживается прямая и обратная совместимость. В контексте .NET Framework обратная совместимость означает, что любое приложение, созданное в .NET Framework более ранней версии, будет выполняться и в более поздней версии[29]. Прямая совместимость означает возможность выполнения приложения, созданного в более поздней версии .NET Framework SDK v 2.0, в .NET Framework более ранней версии.

Классы ADO.NET были разработаны для поддержки возможностей новой модели программирования: интеграции с XML, единого представления данных с возможностью комбинирования данных из различных источников, а также средств оптимизации взаимодействия с базой данных, представленных в .NET Framework [29].

Структура ADO.NET создана для решения задач современной модели разработки приложений. В то же время модель программирования по возможности приближена к ADO, что упрощает переход разработчиков ADO к новой среде. ADO.NET является неотъемлемой частью .NET Framework, оставаясь понятной программистам ADO [28].

.NET представляет собой совершенно новый способ создания распределенных настольных и встроенных приложений. Для типов .NET не нужны ни фабрики классов, ни поддержка IUnknown, ни регистрация в системном реестре. Эти основные элементы СОМ не скрыты - их просто больше нет.

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

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

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

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

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

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

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

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

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

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

Microsoft Visual Studio 2005 продолжает поддерживать технологии Microsoft .NET Framework уже в версии Microsoft .NET Framework SDK v2.0, которые предоставляют общеязыковую среду выполнения и унифицированные классы программирования. Также в Visual Studio включена библиотека MSDN, содержащая документацию по данным инструментам разработки.

Платформа Microsoft.NET для отображения данных на компьютере конечного пользователя и его интерактивного взаимодействия с системой. предоставляет класс System.Windows.Forms.Form и большое разнообразие классов элементов управления, дочерних от класса Control. Функциональность уровня представления во многом определяется составом элементов управления, входящих в коллекцию Controls для конкретной формы [29].

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

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

Бизнес-логика описывается набором методов, реализующих бизнес-транзакцию. Для платформы Microsoft.NET это типовое решение сценарий транзакций использует прямой доступ к базе данных и базируется на использовании объектов классов DataCommand и DataReader технологии ADO.NET, а так же используя bindingSource, TableAdapter, DataSet . Класс, реализующий сценарий транзакций, обеспечивает прямой доступ к источнику данных и необходимую функциональность бизнес-логики. Для данного типового решения все обязанности по реализации бизнес-логики возлагаются на методы сценария транзакций.

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

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

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

Уточнение модели анализа путём построения диаграмм взаимодействий и детализации диаграммы классов [33-35]. Внесение необходимых изменений и поправок в имеющуюся модель анализа, если необходимо.

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

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

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

Рисунок 2.7 - Диаграммы Состояний (Statechart) Информационной системы

Рисунок 2.8 - Диаграммы Компонентов (Component) Информационной системы

Выводы к разделу

Во втором разделе рассмотрены архитектурное проектирование информационной системы, определяется пользовательский интерфейс системы. Проводится проектирование баз данных. Выбирается база данных которая будет удовлетворять требованиям разрабатываемой информационной системы. Определяются таблицы и тип хранимых данных в них. Определяется структура базы данных. Выбирается платформа для создания информационной системы. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

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

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

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

Здесь представлен код отображения данных на форме из таблиц «Гражданин» и «Паспортные данные». За пересылку новых данных в базу, которые были введены на форме, отвечает функция, краткий код которой представлен ниже:

Код показывает, как происходит запись только в одну таблицу «Гражданин», но помимо таблицы «Гражданин» существует еще ряд таблиц, в которые происходит запись новых данных, но они здесь не рассматриваются.

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

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

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