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

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

 

Рисунок 2.6 – Физическая модель

 

На рисунке 2.7 ниже отображена схема данных БД.

 

Рисунок 2.7 - Схема данных

 

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

 

В качестве операционной среды при реализации АИС будет использоваться операционная оболочка Microsoft Windows XP, так как это наиболее распространенная и приспособленная для пользователя среда, с дружественным пользовательским интерфейсом. Операционная среда Microsoft Windows XP является многозадачной, высокопроизводительной. Это интегрированная среда, которая обеспечивает эффективный обмен текстовой, графической и видеоинформацией между отдельными программами.

В качестве системы разработки будет использоваться среда MS Access 2003, SQL-server. Выбор данной среды обусловлен следующими причинами:

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

• визуальная среда разработки;

• полное использование возможностей среды WINDOWS.
• Наибольший опыт разработчика работы именно в этой среде.
• Пожелание заказчика (в перспективе возможна доработка этого приложения силами других разработчиков).

Минимальными требования, предъявляемые MS Access 2003 к ПК – это Intel-совместимая платформа ПК, процессор от Intel Pentium 3 и выше, ОЗУ 256 MB, OS MS XP.

Исполняемый файл БД «АТП.mdb» во время работы может менять свой размер даже в том случае, если данные не изменялись. Это обусловлено внутренней организацией и логикой работы MS Access. Увеличение размера файла может быть вызвано тем, что СУБД может создавать временные объекты (таблицы, запросы) внутри собственно БД и исполняемых модулей, а также кэшировать результаты запросов к данным.

 

2.5 Проектирование модулей

 

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

Программные модули системы:

• модуль «ввода данных»;
• модуль «редактирования ввода данных»;
• модуль «справочники»;
• модуль «редактирования справочников»;
• модуль «пароль»;
• модуль «администрирование»;
• модуль «просмотра отчетов»
• CloseForm.

Модуль «CloseForm» позволяет при закрытии формы главного меню закрывать его в оригинальном виде.

 

Выводы по главе

 

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

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

 

 

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

 

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

 

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

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

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

 

Рисунок 3.1 – Окно входа в ИС

 

Ниже представлена форма разработанного приложения, отображающая кнопки, поля, вводимые данные. При разработке пользовательского интерфейса, было создано меню в виде кнопочной формы. Ниже изображен разработанный интерфейс главной формы (рисунок 3.2), программный код VBA (приложение Б, рисунок Б.1). В главной форме расположены основные кнопки для работы с ИС, которые представляют собой переходы на формы справочников, ввода данных, отчетов, администрирования.

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

Рисунок 3.2 - Главная форма

 

Рисунок 3.3 - Форма справочники

 

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

 

Рисунок 3.4 - Форма авторизации

 

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

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

 

Рисунок 3.4 - Форма ввода данных

 

На следующем рисунке 3.5 представлена форма для просмотра отчетности по сходам автомашин парка предприятия.

 

Рисунок 3.5 – форма просмотра отчетности по автомашинам

 

На рисунке 3.6 представлена форма для ввода, редактирования данных по ремонту единицы подвижного состава по выбранному наряду («Листок учета»).

Рисунок 3.6 – форма «Листок учета»

 

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

 

Рисунок 3.7 – форма создания отчетов

 

На следующем рисунке 3.8 изображено окно на вход формы защиты БД.

 

Рисунок 3.8 – форма защиты БД.

 

Формы нормативно-справочной информации изображены на рисунках Е.1-Е.5 в приложении Е. Выходные документы изображены на рисунках Д.1-Д.13 в приложении Д.

 

3.2 Взаимодействие  приложения с источниками данных (технология доступа к данным, sql-запросы, хранимые процедуры)

 

Для того чтобы пользователь ИС мог использовать информацию хранящуюся в базе данных СУБД Microsoft SQL Server 2003, необходимо выбрать и реализовать технологию доступа к базе данных. Основной технологией доступа к данным, выступают sql-запросы (приложение Г, рисунки Г.1-Г.15). На рисунке 3.9 показан sql-запрос, отображающий существующие на выбранную дату наряды автопарка на форме.

 

Рисунок 3.9 – Пример sql-запроса

 

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

 

Рисунок 3.10 – Пример sql-запроса

 

Хранимые данные записаны в таблицах среды разработки ИС.

Таблица «Механик ОТК» хранит информацию, которая включает в себя: ИД гаражного номера, время выезда, заезда автомашины, ее гаражный номер, дату выписки и закрытия ремонта, а также причины схода, все данные таблицы являются реквизитами автомашин при обследовании, рисунок 3.11.

 

Рисунок 3.11 – Таблица «Механик ОТК»

 

Таблица «Лист учета» изображенная на рисунке 3.12 хранит информацию о количестве начисленных технических обслуживаний по всем гаражным номерам.

 

Рисунок 3.12 – Таблица «Лист учета»

 

Остальные таблицы с данными ИС в приложении Г, рисунках Г.16-Г.21.

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

 

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

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

Контроль - попытка найти ошибки в тестовой, или моделируемой среде;

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

Аттестация - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

Отладка не является разновидностью тестирования. Хотя «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.

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

ГОСТ Р28195-89 Оценка качества программных средств.

ISO/IEC 9126: 1991 Information Technology Software Product Quality Characteristics.

Стандарты разработки ПО ESA PSS-05-0-1991.

Тестирование ИС осуществлялась на основе тестового примера методом черного ящика (приложение К). Тестирование методом «Черного ящика» предполагает обработку системы как «непрозрачного объекта», таким образом, знание внутренней структуры в явном виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. Синонимами понятия метода «Черного ящика» являются: поведенческое тестирование, функциональное тестирование, метод непрозрачного ящика, метод закрытого ящика. При тестировании программного обеспечения методом «Черного ящика» тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов ему неизвестно. Тестировщик никогда не проверяет программный код и не нуждается в дополнительном знании программы кроме как в ее техническом описании. Были заданы тестируемые функции комплекса, желаемые результаты и результаты после тестирования /28/.

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

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

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

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

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

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

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

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

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

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

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

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