Выводы к разделу
В процессе разработки требований к программному обеспечению были решены следующие задачи:
Был проведен анализ наиболее популярных существующих решений по автоматизации предметной области.
Был проведен сбор требований, в процессе которого были выявлены основные функции разрабатываемой системы.
В процессе анализа требований был разработан комплекс моделей предметной области.
Выполняя спецификацию требований, были определены и описаны функции системы, а также основные требования к внешнему интерфейсу.
Во время аттестации требований были разработаны прототипы пользовательского интерфейса и построена диаграмма потоков пользовательского интерфейса.
Был проведен выбор методологии проектирования информационной системы.
2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Архитектурное проектирование
Архитектура системы представляет собой концептуальное видение структуры будущих функциональных процессов и технологий на системном уровне и во взаимосвязи системы и пользователя. Информационные системы могут очень значительно различаться по своим функциям, архитектуре, реализации.
Разработка архитектуры информационной системы - это процесс описания архитектур информационных систем в достаточно детальном представлении. Существует несколько видов программных архитектур, используемых в настоящее время, это файл-серверная архитектура, клиент-серверная и многоуровневая.
Архитектура клиент-сервер разделяет компоненты приложения и размещает их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.
Отличительная черта серверов БД - наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.
Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты управления данными размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными размещаются на сервере. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД - на сервере. Поскольку такая схема предъявляет наименьшие требования к серверу.
При внедрении модуля сбора данных взаимодействие между приложением и источником данных осуществлялось при помощи компонента меню «Система».
Компонент меню «Система» используется для настройки доступа к данным из различных систем управления базами данных. Например, при наличии программы, работающей с данными из базы данных SQL, компонент меню «Система» позволит использовать программу для доступа к данным в базе данных FoxPro. Компонент «Источник данных» используется для настройки приложений, чтобы обеспечить им доступ к данным из различных систем управления базами данных.
Для реализации программного модуля мною была выбрана технология Open DataBase Connectivity (открытая система связи с базами данных).
ODBC представляет собой набор динамических библиотек DLL, которые обслуживают подключение и работу с конкретным типом базы данных. При запросе на подключение к определенной, заранее описанной базе «активизируется» определенная DLL - драйвер этого типа БД.
Преимущества данного выбора в том, что приложения не привязаны к программному интерфейсу какого-то одного поставщика, SQL-запросы могут быть включены непосредственно в исходный код приложения либо генерироваться «на лету», приложения могут полностью игнорировать коммуникационные протоколы, используемые для непосредственного доступа к данным. Пи этом данные могут получаться или отсылаться в выбранном формате.
2.2 Проектирование пользовательского интерфейса
Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. При разработке информационной системы одной из главных задач разработки является создание простого интерфейса для понимания конечному пользователю. Но при этом интерфейс должен быть незагруженным, то есть не должно быть ничего лишнего. Именно с помощью интерфейса происходит «общение» конечного пользователя программного продукта с информационной системой.
Основу такого взаимодействия составляют диалоги формы. Под диалогом в данном случае понимают регламентированный обмен информацией между человеком и компьютером, осуществляемый в реальном масштабе времени и направленный на совместное решение конкретной задачи: обмен информацией и координация действий. Каждый диалог состоит из отдельных процессов ввода-вывода, которые физически обеспечивают связь пользователя и компьютера. Обмен информацией осуществляется передачей сообщений и управляющих сигналов.
По аналогии с процедурным и объектным подходом к программированию различают процедурно-ориентированный и объектно-ориентированный подходы к разработке интерфейсов.
Процедурно-ориентированные интерфейсы используют традиционную модель взаимодействия с пользователем, основанную на понятиях «процедура» и «операция». В рамках этой модели программное обеспечение предоставляет пользователю возможность выполнения некоторых действий, для которых пользователь определяет соответствующие данные и следствием выполнения которых является получение желаемых результатов.
При реализации разрабатываемой информационной системы использовалась реализация процедурно-ориентированные интерфейсы. Данный выбор обоснован простотой реализации системы, и выбором методологии проектирования. Графические пользовательские прототипы интерфейса были разработаны при определении требований к проектируемой системе и приведены в приложении Б.
После запуска приложения открывается главная форма, которая содержит основное меню, состоящее из пяти пунктов меню: Система, Расчет, Аналитика, Выход. Интерфейс-меню позволяет пользователю выбирать необходимые операции из специального списка, выводимого ему программой. Эти интерфейсы предполагают реализацию множества сценариев работы, последовательность действий в которых определяется пользователем.
2.3 Проектирование баз данных
База данных - это единое, хранение структур данных, которое затем используется одновременно многими пользователями из разных подразделений. Основным ресурсом для составления отчетности разрабатываемой системой будут являться данные сформированные главной программой «Продажа билетов».
Проектирование базы данных основано на информации, которая будет использоваться разрабатываемой программой. Необходимая для проектирования базы данных информация собрана посредством изучения документов, которые используются для сбора или представления информации. Перечень требуемых документов был определен на этапе сбора требований. Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований.
При проектировании БД важной задачей ставилось определение представления данных и связей между ними, необходимых для всех основных областей применения данного приложения. В процессе проектирования были созданы три уровня модели - концептуальный, логический и физический.
Концептуальный уровень модели отражает в себе сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Диаграмма сущность-связь может включать связи «многие ко многим» и не включать описание ключей. Концептуальная модель базы данных приведена на рисунке 2.1.
Рисунок 2.1 - Концептуальная модель базы данных
Доработка этой концептуальной модели с учетом атрибутов таблиц позволяет перейти непосредственно к логической модели БД. Логическая модель базы данных показана на рисунке 2.2
Рисунок 2.2 - Логическая модель базы данных
Физический уровень модели данных, напротив, зависит от конкретной системы управления базами данных, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация обо всех объектах базы данных. На физическом уровне модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах. Физическая модель базы данных показана на рисунке 2.3.
Рисунок 2.3 - Физическая модель базы данных
В процессе создания моделей баз данных были получены таблицы, отображающие необходимую информацию. Список таблиц разрабатываемого модуля для ОАО «Автовокзал»:
- анализ пассажиропотока (Analpass);
- анализ работы АТП (Atp_Anal)
- выручка за багаж (Bagaj_D)
- показатели работы рейса (Coef_CRT)
- срывы и незаходы автобусов (FailRejs)
- плановое задание по доходам (FuturDoh)
- перевозка пассажиров фактическая (LoadFact)
- периодичность рейсов (MinSched)
- положение по продажам (NegPass)
- справка о неприбытиях и опозданиях автобусов по АТП (NerpOATP)
- оперативные сведения (Oper_All)
- сведения о работе АТП по выполнению условий«Договора об организации и перевозки» (OrderAtp)
- расчет потребности кассовых ведомостей (OrderCnt)
- перевозка пассажиров дальнего следования (PassKmAV)
- доходы по месяцам от продаж (PlanDoh)
- анализ предварительной продажи билетов на формирующиеся рейсы (Pr_SalSv)
- отчет о предварительной продаже билетов на формирующиеся и транзитные рейсы (Pre_Sale)
- льготный проезд (Priv_All)
- сведения о предоставлении льготного проезда в автобусах по отдельным категориям лиц (Privileg)
- обслуживающее АТП (SoldTis1)
- сведения о продаже билетов, выручке и наполняемости автобусов (SoldTisk)
- станционное расписание движения автобусов (St_Sched)
- коэффициент повышения тарифов на перевозку пассажиров за месяцы (TarifRat)
2.4 Обоснование выбора платформы создания информационной системы
Согласно требованиям к разрабатываемой системе, а так же согласно требованиям стороны заказчика, для создания разрабатываемой информационной системы анализа продажи проездных билетов на примере ОАО «Автовокзал» был выбран Microsoft Visual FoxPro 9.0.
Первоначальное название FoxPro - FoxBase. Данный продукт разработка компании Fox Software. Начало разработки данного продукта было положено еще в 1984 году. С течением времени в 1992 году компания Fox Software объединилась с компанией Microsoft и новые версии продукта обрели ряд новых функций а так же приставку «Visual». Последняя версия оригинального FoxPro - версия 2.6 - работала под Mac OS, DOS, Windows и Unix. Уже в версии Visual FoxPro 3.0 список поддерживаемых платформ сократился до Mac OS и Windows, а в более поздних версиях -- уже только до Windows.
Текущая версия Visual FoxPro основана на Component Object Model (COM), и Microsoft утверждает, что .NET-версии продукта не будет. COM - это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт COM был разработан в 1993 году корпорацией Майкрософт как основа для развития технологии Object Linking and Embedding (OLE) - технология связывания и внедрения объектов в протокол.
Технология OLE уже позволяла создавать так называемые «составные документы». Например, в пакете Microsoft Office эта технология позволяла включать диаграммы Microsoft Excel в документы Microsoft Word. Стандарт же COM должен был унифицировать процесс создания, внедрения и связывания таких внедряемых объектов, а также стандартизировать разработку приложений, использующих внедряемые объекты.
Visual FoxPro это визуальная среда разработки систем управления реляционными базами данных, выпускаемая в настоящее время корпорацией Майкрософт. Последней версией продукта является Microsoft Visual FoxPro 9.0, данный продукт использует язык программирования FoxPro. Среда разработки версии 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 -- только в Windows XP, 2000, 2003. Среда исполнения версий 8.0 и 9.0 работает под любой версией Windows, начиная с 98.