Выводы

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

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

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

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

На этапе тестирования ИС используется как локальное приложение.

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

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

Осуществить настройку Access на многопользовательский доступ, MS Access имеет такую функцию.

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

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

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

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

На сторону SQL - сервер приходится только одна функция - это хранение введённых данных.

Рисунок 2.1 - Представление информационной системы в архитектуре «клиент-серверная»

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

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

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

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

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

При проектировании прототипов пользовательского интерфейса была использована СУБД Access.

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

В состав любой СУБД входят языки двух типов:

- язык описания данных (с его помощью описываются типы данных, их структура и связи);

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

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

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

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

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

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

Прототип пользовательского интерфейса верхнего уровня можно посмотреть ниже на рисунке 2.2.

Рисунок 2.2 - прототип пользовательского интерфейса верхнего уровня

Прототип пользовательского интерфейса нижнего уровня можно посмотреть ниже на рисунке 2.3.

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

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

2.3.1 Концептуальное проектирование БД

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

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

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

Концептуальная модель данных представлена на рисунке 2.4.

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

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

2.3.2 Разработка логической модели данных

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

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

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

Рисунок 2.5 - Логическая модель

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

2.3.3 Разработка физической модели данных

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

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

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

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

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

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

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

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

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

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

- полное использование возможностей среды WINDOWS.

2. Наибольший опыт разработчика работы именно в этой среде.

3. Пожелание заказчика (в перспективе возможна доработка этого приложения силами других разработчиков).

Минимальными требования, предъявляемые 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/.

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

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

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

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

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

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

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

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

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

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