Алгоритм работы главного модуля можно кратко описать следующей последовательностью действий. При загрузке модуля ожидается выбор одной из альтернатив главного меню. В зависимости от выбранной альтернативы главного меню происходит активация соответствующей процедуры, и синтез необходимых дочерних форм. После этого вычислительный процесс ожидает задействования элементов управления, которые могут приводить к запуску различных программных процедур, входящих в состав проекта.
Рисунок 3.12 — Блок-схема главного модуля
Разрабатываемое приложение состоит из 5 форм, одна из которых является главной, остальные формы являются дочерними по отношению к ней.
Главная форма приложения содержит элементы управления — главное меню, с помощью которого и осуществляется работа всей системы, управление вычислительным процессом, организуется обмен данными и обеспечивается создание всех остальных форм приложения.
Главное меню приложения содержит альтернативы «файл», «Просмотр», «создать», «Поиск», «Отчеты». Альтернатива «информация» позволяет получить справочную информацию о каждой из таблиц базы данных, (рис.
3.13), а та же просмотреть записи всей базы данных в целом, для этого необходим выбор альтернативы «просмотр базы данных».
Рисунок 3.13 — Пункт главного меню «Информация»
Динамически создаваемая дочерняя форма AddSource, может использоваться не только для отображения связанных записей. Главное назначение формы AddSource это создание интерфейсов для добавления новых объектов (рис. 2.40).
Рисунок 3.14 — Дочерняя форма AddSource, динамически создаваемая для добавления информации о документах
Рисунок 3.15 — Дочерняя форма AddSource динамически создаваемая для добавления информации о резолюциях Рисунок 3.16 — Дочерняя форма AddSource динамически создаваемая для добавления информации об исполнителе Все алгоритмы отличаются разной степенью сложности информационного поиска и вычислительных процедур по обработке результатов такого поиска.
Дочерняя форма ParamPoisk динамически создается с одной стороны для организации запросов на различные виды сложного информационного динамического поиска по ключевым полям (рис.
2.44).
Рисунок 3.17 — Дочерняя форма ParamPoisk, динамически создаваемая для организации запроса на поиск исполнителя по фамилии
Рисунок 3.18 — Вывод результатов информационного поиска «Иванов»
3.4 Взаимодействие программных модулей, отладка и тестирование
Отладка (debugging) — это процесс устранения ошибок, осуществляемый после удачного выполнения теста. Как только при отладке получено эталонное значение, можно приступать к тестированию.
Процессы тестирования и отладки программного продукта не являются эквивалентными. Отладку можно описать как процесс, который производится после выполнения удачного тестового случая. Отладка — это процесс, состоящий из двух этапов. Он начинается на основе некоторого указания на наличие ошибки (например, выявленной в результате выполнения удачного контрольного примера) и переходит к определению точной сущности и местонахождению предполагаемой ошибки в рамках программы, а затем к исправлению этой ошибки.
Разработчик ПО отвечает за организацию верификации, системное тестирование возлагается на разработчика и руководителя работы.
В таблице 3.1 приведен график работ по тестированию подсистемы.
Таблица 3.1
График проведения работ по тестированию
№ Вид работы Продолжительность (дни) Сущность Работы Цель работы 1 Проверка трассируемости требований пользователя с требованиями к ПО. 2 Составление матрицы трассировки Проверить требования к ПО 2 Тестирование создания объектов;
1 Тестирование логики программы на правильность добавления и редактирования вопросов Проверка проектирования, реализации структуры БД вопросов при добавлении объекта 3 Тестирование установления связей между объектами;
3 Тестирование логики программы и информационной модели, создания БД и связей между таблицами Проверка проектирования, реализации структуры БД 4 Тестирование режима ввода данных;
1 Тестирование логики программы на правильность ввода данных в БД Проверка этапа проектирования, реализации структуры БД при вводе данных 5 Тестирование режима изменения данных; 2 Тестирование логики программы на изменение ввода данных в БД Проверка проектирования, реализации структуры БД при изменении данных 6 Тестирование клиентской части 8 Тестирование режимов получения отчетов, поиска, сортировки данных Проверка корректности работы программы 7 Интеграционное тестирование 7 Тестирование логики программы на установление связей между клиентской и серверной частями системы Проверка связи клиентской и серверной частей Всего 24
Ответственность разработчика состоит в устранении ошибок и помощи тестировщику. На тестировщика возлагается обязанность составления планов тестирования, прогона тестов, воспроизведения ошибок, составления отчета по результатам. В таблице 2.9 представлен перечень наборов входных данных для тестирования объектов базы данных и связей между ними.
Таблица 3.2
Процесс тестирования клиентской части
№ п/п Входные данные
(команды) Ожидаемый результат Назначение Смысл 1 Нажатие кнопки ‘Создать' Добавление записи в таблицу Проверка добавления данных в таблицу Нормаль работа подсистемы 2 Нажатие кнопки ‘Удалить' Удаление записи из таблицы Проверка удаления записи из таблицы Нормальная работа подсистемы 3 Нажатие кнопки ‘Добавить' на панели (не заполнено ключевое поле) Сообщение об ошибке Проверка правильности ввода записи Аномалия 4 Нажатие кнопки ‘Обновить' Сохранение базы данных Проверка правильности сохранения БД Нормальная работа подсистемы Объект тестирования:
клиентская часть подсистемы;
анализ выходных данных и выдача сообщений в случае невозможности ввода.
Таким образом, результирующая информация разрабатываемой автоматизированной системы позволяет полностью определить запросы и требования, предъявляемые к системе.
Заключение
В дипломной работе была спроектирована и разработана автоматизированная система документооборота.
В ходе выполнения работы был решен ряд задач среди которых в первую очередь необходимо выделить следующие;
— анализ современных средств автоматизации документооборота;
— анализ процессов в отечественном документообороте;
— анализ проблем в области автоматизации документооборота;
— формирование задач автоматизированной системы документооборота компании;
— выбор средств разработки автоматизированной программной системы документооборота компании;
— разработка информационного обеспечения системы;
— проектирование базы данных для функционирования автоматизированной системы;
— разработка математического и программного обеспечения функционирования системы;
— анализ документооборот компании;
— разработка предложений совершенствованию документооборота компании.
Анализ процессов отечественного документооборота, позволил выделить его основные принципы, а так же изучить основные тенденции этой отрасли, которая в последнее время тяготеет к использованию автоматизированных систем и компьютерного учета документов. В качестве исследования были проанализированы существующие системы автоматизированного документооборота. При анализе был сделан вывод о том, что сегодня российский рынок довольно насыщен программами автоматизации документооборота. Все программы обладают сходными характеристиками, однако и имеют ряд технологических особенностей.
Среди лидеров в отечественном документообороте были проанализированы следующие программные продукты: Directum, «ИНТАЛЕВ: Корпоративные документы и процессы», «ЕВФРАТ-Документооборот», Escom. doc, Optima — WorkFlow, «Гран-Док» и «Летограф». В результате анализа были сформированы основные функции, которые должны быть реализованы в современной системе документооборота, что позволило перейти непосредственно к разработке системы автоматизированного документооборота.
Для этого были сформированы функциональные задачи для реализации в автоматизированной системе документооборота и выбран инструмент для реализации. В качестве такого инструмента выбрана среда программирования Borland Development Studio 2006, а в качестве средства разработки базы данных Microsoft Access .
Основное достоинство Borland Development Studio 2006 состоит в предоставлении разработчику большого количества визуальных компонентов для разработки интерфейса. Для выбора инструментального средства разработки использовался методом вариантных обоснований.
Разработанная база данных для функционирования автоматизированной системы документооборота содержит 8 взаимосвязанных таблиц, которые находятся в третьей нормальной форме — «Документ», «Статус», «Корреспондент», «Исполнитель», «Отдел», «Вид документа», «Источник», «Резолюция».
В качестве выходной информации для рассматриваемой системы рассматриваются результаты информационного поиска, формируемые в информационной системе к которым могут быть отнесены
— результаты поиска документов по дате регистрации;
— результаты поиска документов по регистрационному номеру;
— результаты поиска данных исполнителя по фамилии;
— результаты поиска необработанных документов.
Указанные данные формируются динамически посредством выполнения запросов к разработанной базе данных.
Математическое обеспечение системы представлено в виде разработанного алгоритмического обеспечения, среди основных разработанных алгоритмов необходимо выделить:
— алгоритм добавления нового документа;
— обобщенный алгоритма функционирования системы
— обобщенного алгоритм информационного поиска Разработанное программное обеспечение содержит 3 основных программных модуля, среди которых целесообразно выделить Модуль работы с документами, модуль получения результирующей информации, Модуль получения справочной информации.
Для быстрой и полной адаптации пользователя к системе был разработан удобный дружественный интерфейс пользователя и подробное описание работы с системой в руководстве пользователя.
Для обеспечения надежной защиты информации предусмотрена система разграничения доступа к данным и функциям, авторизация вводимой и корректируемой информации, посредством подстановки и анализа данных.
В заключительном разделе работы проведена оценка экономической эффективности разработанного программного средства.
Таким образом, в работе проведено исследование предметной области, разработана структура базы данных, спроектированы SQL-запросы к базе данных, разработано алгоритмическое и программное обеспечение, спроектирован программный интерфейс системы, а так же проведено тестирование разработанной системы, оценена экономическая целесообразность внедрения системы.
Считаю, что созданная в дипломной работе автоматизированная система документооборота. полностью соответствует информационным требованиям предприятия и сможет поддерживать это соответствие в течение всего жизненного цикла системы.
В работе проведено исследование предметной области, разработана структура базы данных, спроектированы SQL-запросы к базе данных, разработано алгоритмическое и программное обеспечение, спроектирован программный интерфейс системы, а так же проведено тестирование разработанной системы.
Андон Ф. Язык запросов SQL / Ф. Андон, В. Резниченко. — СПб.: BHV, 2006. — 416 с.
Грабер, Мартин SQL. Справочное руководство; М.: Лори; Издание 2-е, 2001. — 354 c.
Грибер, М.
Введение
в SQL / М. Грибер, М., Лори, 1996. — 379 с.
Дайан А. и др. Маркетинг. М., Экономика, 1993.
Дейт, К.
Введение
в системы баз данных: пер. с англ. /К.Дж. Дейт. 8-е издание. — М.: Вильяме, 2006. — 1326 с.
Джеффри Д. Ульман, Дженнифер Уидом. Основы реляционных баз данных, Лори, М, 2006 г.
Джозеф Шмуллер. Освой самостоятельно UML за 24 часа. Второе издание. «Вильямс», Москва-Санкт-Петербург-Киев, 2002
Дискретная математика для программистов / Ф. А. Новиков — СПб: Питер. 2000. — 304 с.
Дубицкий В. В., Огородникова И. А., Перепеча И. Ф. и др. К концепции построения внутривузовской системы обеспечения качества образовательного процесса в ОмГУ.
// Университетское управление: практика и анализ. — 2003. — N 2(25). ;
С. 96−100.
Зрюмов Е. А. Базы данных для инженеров: учебное пособие / Е. А. Зрюмов, А.
Г. Зрюмова; Алт. гос. техн. ун-т им. И. И.
Ползунова. — Барнаул: Изд-во Алт
ГТУ, 2010. — 131 с.
Кевин, Кл. SQL: справочник: пер. с англ. / Кл. Кевин. 2-е издание. -М: Кудиц-Образ, 2006. — 832 с.
Колби, Дж. SQL для начинающих: пер. с англ. / Джон Колби, Пол Уилтон. — М: Вильяме, 2006. — 496 с.
Колдаев В. Д. Основы алгоритмизации программирования: Учебное пособие / Под ред. проф. Л. Г. Гагариной.
— М.: ИДФОРУМ.: ИНФРА-М. 2006. — 416 с Конноли Томас, Бегг Каролин. Базы данных.
Проектирование, реализация и сопровождение. Теория и практика. — М.: Вильямс, 2000. — 1111 с.
Культин Н.Б. Delphi 6: Программирование на Object Pascal. — М.: Бином, 2001. — 526 с.
Культин Н.Б. Delphi 7: Программирование на Object Pascal. — М.: Бином, 2003. — 535 с.
Гагарина Л.Г., Киселев Д.В.и др. Разработка и эксплуатация автоматизированных информационных систем: учеб.
пособие / под ред.
проф. Л. Г. Гагариной. — М: ИД"Форум": ИНФРА-М, 2007. — 384 с.
Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. «Вильямс», Москва-Санкт-Петербург-Киев, 2002
Макарова Н., Николайчук, Г. Титова Ю. Компьютерное делопроизводство. Учебный курс: Н— Москва, Питер, 2009 г.- 416 с.
Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. — М.: Диалог-Мифи, 2001. — 304 с.
Мартин Г. SQL. Бестселлер#1. Описание SQL92, SQL99 и SQLJ/ Г. Мартин. — М.: Лори, 2004. — 644 с.
Моисеенко С. И. SQL. Задачи и решения / С. И. Моисеенко. — СПб.: Питер, 2006. — 256 с.
Терри Кватрани. Rational Rose 2000 и UML. Визуальное моделирование. «ДМК», Москва, 2001
Федотова Д. Э. Технология разработки и отладки программ: Учебн. пособие / МИРЭА.
М., 1987.-80с.
Приложение
SELECT адресат. Наименование, адресат. Фамилия, адресат. Имя, адресат. Отчество, адресат. Телефон, адресат. email, адресат. Адрес
FROM адресат
WHERE (((адресат.Фамилия)=[Forms]![Поиск информации]![Поле20]));
SELECT Атрибут. регистрационный номер], Атрибут. дата регистрации], Атрибут.
содержание, Атрибут. исходящий номер], Состояние.
состояние, Состояние.
дата, Состояние.
местонахождение
FROM Состояние INNER JOIN (Атрибут INNER JOIN Документ ON Атрибут. код атрибута] = Документ. код атрибута]) ON Состояние. код состояния] = Документ. код состояния]
WHERE (((Атрибут. дата регистрации])=[Forms]![Поиск информации]![Поле11]));
SELECT Атрибут. регистрационный номер], Атрибут. дата регистрации], Атрибут.
содержание, Атрибут. исходящий номер], Состояние.
состояние, Состояние.
дата, Состояние.
местонахождение
FROM Состояние INNER JOIN (Атрибут INNER JOIN Документ ON Атрибут. код атрибута] = Документ. код атрибута]) ON Состояние. код состояния] = Документ. код состояния]
WHERE (((Атрибут. регистрационный номер])=[Forms]![Поиск информации]![Поле6]));
SELECT Исполнитель. Фамилия, Исполнитель. Имя, Исполнитель. Отчество, Исполнитель. Должность, Отдел.
название_отдела, Исполнитель. Телефон, Отдел.
размещение
FROM Отдел INNER JOIN Исполнитель ON Отдел.
код_отдела = Исполнитель. код отдела]
WHERE (((Исполнитель.Фамилия)=[Forms]![Поиск информации]![Поле15]));
FROM Zapas INNER JOIN Tovar ON Zapas. idZapas = Tovar. idZapas, Zakaz INNER JOIN (Pokup INNER JOIN Nakladnaya ON Pokup. idPokup = Nakladnaya. idPokup) ON Zakaz. idZakaz = Nakladnaya. IdZakaz;
SELECT Атрибут. регистрационный номер], Атрибут. дата регистрации], Атрибут.
содержание, Контроль. дата отработки], Состояние.
состояние, Состояние.
дата, Состояние.
местонахождение
FROM Контроль INNER JOIN (Состояние INNER JOIN (Атрибут INNER JOIN Документ ON Атрибут. код атрибута] = Документ.
код атрибута]) ON Состояние. код состояния] = Документ.
код состояния]) ON Контроль. код контроля] = Документ. код контроля]
WHERE (((Состояние. состояние])<>'исполнен'));
Проект
Главная форма приложения MainClients
childTemplate.pas
DbdDirectoryTemplate.pas
AddSource.pas
ParamPoisk.pas
