Программное обеспечение системы управления и планирования работы сети таксофонов

Дипломный проект

на тему:

" Программное обеспечение системы управления и планирования работы сети таксофонов"

Москва 2010

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

По оценкам в число 200 крупнейших по капитализации компаний России вошло 50 телекоммуникационных компаний, 29 из которых вошли в число 30 наиболее привлекательных для инвестиций. В сочетании с большой емкостью телекоммуникационного рынка, в частности рынка таксофонных услуг, а также с его высокой доходностью (предоставление услуг таксофонной связи входит в число 10 наиболее прибыльных видов бизнеса) это свидетельствует о значительном потенциале развития в данной области.

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

На Всемирной конференции по развитию электросвязи, организованной Международным союзом электросвязи в Буэнос-Айресе в марте 1994 года, была выставлена концепция Глобальной инфраструктуры связи (ГИИ), которая заключается в объединении ресурсов информационных технологий и развитой инфраструктуры электросвязи в целях обеспечения взаимодействия всех пользователей для получения любого вида информации в реальном масштабе времени вне зависимости от расстояния и используемых технических средств.

Интеграция российской сети электросвязи в ГИИ и построение Взаимоувязанной Сети Связи (ВСС) России является национальной стратегической задачей, получившей отражение в ряде законодательных и нормативно-правовых актов, принятых в 2005;2007 годах. В частности, одним из стратегических направлений, определяемых документом является построение единой таксофонной сети России и интеграция ее в ВСС.

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

1. Исследовательская часть

1.1 Анализ проблем управления сетью таксофонов и синтез решения по его оптимизации

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

По количеству таксофонных аппаратов потенциал России также достаточно высок и сравним с потенциалами таких стран, как Франция и Германия:

Германия — 1 таксофон на 400 человек населения

Франция — 1 таксофон на 300 человек населения

Россия (в среднем) — 1 таксофон на 700 человек населения

Россия (крупные города) — 1 таксофон на 300−250 чел. населения

Москва (32 000 таксофонов) — 1 таксофон на 300 человек населения

Исследования Ленинградского отраслевого НИИ связи (ЛОНИИС) показали, что оптимальной плотностью размещения таксофонов на территории России является 2−3 таксофона на 1000 человек, или 1 таксофон на 500−300 человек. Таким образом, плотность таксофонов, особенно в крупных городах, уже приблизилась к намеченной цифре, но подавляющее большинство установленных таксофонов не соответствуют современным стандартам. В связи с этим увеличиваются требования, предъявляемые к охвату населения услугами таксофонной связи с качеству обслуживания.

В настоящее время (состояние на июль 2009 года) в России насчитывается:

около 190 000 таксофонов местной телефонной связи, около 25 000 таксофонов, предоставляющих междугороднюю связь и около 2500 таксофонов общего назначения.

К 2001 году планируется замена более 170 000 установленных на сегодня таксофонов (80%) и увеличение парка таксофонов на 40−110%. В этой связи возникают следующие проблемы:

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

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

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

топология сети таксофонов Оптимальное размещение таксофонов на территории района невозможно без тщательного анализа статистической информации.

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

Рассмотрим возможные пути решения возникающих проблем:

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

Недостатки (трудности) данного решения:

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

Необходимость разработки соответствующего программного обеспечения.

Преимущества:

Своевременное внесение изменений.

Сокращение времени на осуществление ввода данных.

Уменьшение численности обслуживающего персонала.

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

Недостатки:

Не все сбои в работе таксофона система самодиагностики может идентифицировать (например, обрыв линии).

Преимущества:

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

Защита от несанкционированного доступа — важный элемент надежности системы и качества обслуживания.

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

Преимущества:

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

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

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

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

Таким образом, проанализировав проблемы, непременно возникающие при увеличении количества таксофонов, и исследовав возможные пути их решения, приходим к выводу: управление сетью публичных таксофонов (в рамках района / города) из одного центра при помощи системы удаленного управления и контроля (ЦСК) — наиболее эффективное средство для эксплуатации и обслуживания парка таксофонов.

1.2 Состав выполняемых централизованной системой контроля функций

Хранение и обработка информации о состоянии таксофонов.

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

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

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

Предоставление оператору информации о состоянии таксофонов.

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

Формирование отчетной документации с различной периодичностью.

Статистический отчет.

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

городской звонок, междугородний звонок, международный звонок.

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

Диагностический отчет.

В отчет включается информация по отказам (неисправностям) и ремонтам:

количество отказов, код ремонта, количество ремонтов.

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

Фискальный отчет.

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

Отчетная документация формируется за период:

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

Защита информации от несанкционированного доступа средствами операционной системы и сервера базы данных (БД).

1.3 Аппаратные средства, операционные системы и инструментальные средства

Разработанное в данном дипломном проекте программное обеспечение должно работать на ЭВМ типа IBM PC с установленной операционной системой Windows.

Минимальные требования к серверу базы данных:

IBM PC-совместимый компьютер с процессором 389/33МГц с установленной операционной системой Windows 3.11;

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

Рекомендуемая конфигурация сервера базы данных:

IBM PC-совместимый компьютер с установленной операционной системой Windows NT 4. х;

32МБ оперативной памяти;

3МБ свободного дискового пространства для установки серверного программного обеспечения на системном диске и не менее 5МБ для файлов базы данных.

ЦСК может быть установлена на любом компьютере с установленной ОС Windows 3.11 или выше и имеющем соединение с сервером БД.

Исходные тексты программы написаны на языке SAL (Scaleable Application Language — расширяемый язык приложений) в интегрированной среде командной разработки Centura Team Developer.

Первая версия Centura (компания Gupta, позже переименованная в Centura Software Corporation) появилась в 80-х годах. Развиваясь одновременно с ОС Windows, в настоящее время Centura является мощным инструментом разработки крупных информационных систем с высокой скоростью обработки данных. Можно выделить следующие основные достоинства языка SAL:

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

Centura предоставляет средства доступа к различным серверам баз данных, при этом использует все возможности самых продвинутых серверов (например, ORACLE, SYBASE) и исправляет недостатки слабых БД (например, FoxPro).

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

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

Наличие поставляемой вместе со средствами разработки встроенной СУБД масштаба предприятия.

Все это позволяет сделать выбор в пользу языка SAL интегрированной среды командной разработки Centura (SQL Windows 32).

2. Разработка алгоритмов и программ. Аппаратно-программная структура системы

таксофон оптимизация программа управление

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

В соответствии с концепциями построения Взаимоувязанной Сети Связи и единой таксофонной сети России в системе, разрабатываемой НИИ «Научный Центр», реализована двухуровневая структура (см. рис. 2.1):

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

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

ЦСК является самостоятельным модулем (узлом), который:

входит в состав цифровой АТС в качестве расширения ЭВМ технической эксплуатации (служба ремонта) или подключается к существующим АТС городского типа по выделенным линиям при помощи модемной связи через концентратор «НЦ-1».

Терминалы подключаются к ЦСК опосредованно — по телефонным линиям (ТЛ) через коммутатор АТС. Связь ЦСК с АТС и другими участниками системы осуществляется по проводному каналу RS-232.

Структура программного комплекса Программный комплекс состоит из следующих частей (см. рис. 2.1):

модуля поддержки канала, серверного программного обеспечения, ПО централизованной системы контроля и управления (ЦСК).

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

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

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

Общая структура алгоритма

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

1. Определение прав доступа пользователя и соединение с базой данных — описывается группой блоков 2,3,4:

соединение с базой данных (блок 2);

определение прав доступа (блок 3);

формирование доступного меню (блок 4).

2. Выбор режима работы — эта группа состоит из:

блока собственно выбора режима (блок 5) и блоков перехода к выбранному режиму работы: просмотр данных (блок 6), пересылка данных (блок 7), изменение данных (блок 8), выход из системы (блок 9).

3. Просмотр данных — включает в себя следующие операции (блоки 11−16):

выбор режима просмотра (блок 11);

просмотр данных на экране, состоящий из:

подготовки формы (блок 12),

вывода данных на экран (блок 13);

вывод данных на печать, состоящий из:

выбор режима печати (блок 14),

подготовка данных (блок 15),

печать данных (блок 16).

4. Пересылка данных — осуществляется в следующей последовательности:

вначале происходит проверка правильности данных (блок 17),

если ошибок не обнаружено (блок 18), то устанавливается связь с модулем поддержки канала (блок 19), в противном случае происходит автоматический переход в режим изменения (см. п. 5) для корректировки передаваемой информации;

вызывается соответствующая команда модуля поддержки канала.

Рис. 2.2. Укрупненная структура алгоритма

5. Изменение данных — происходит следующим образом (блоки 21 — 25):

Сначала подготавливается форма ввода (блок 21),

после этого форма выводится на экран (блок 22);

затем пользователь изменяет данные (блок 23),

после чего проводится проверка данных на целостность (блок 24).

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

6. Выход из программы и окончание работы (блок 10).

Структура данных

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

Структура входных и выходных данных представлена на рисунке 2.3.

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

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

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

Рис. 2.3. Структура входных и выходных данных Таблицы, показанные на схеме параллелепипедами, являются журналами регистраций. В них фиксируются все изменения в управляемой системе таксофонов, заносятся учетные данные. На основе информации журналов система строит статистические, финансовые и другие отчеты. Структура журналов подробно показана в приложении ХХ.

Выходной информацией в данной системе являются:

Отчетная документация за различные периоды: стандартные (сутки, месяц, год) и задаваемые пользователем, а именно статистические отчеты, диагностические отчеты и финансовые отчеты Экранные формы.

Печатные формы.

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

Алгоритм определения прав доступа

Определение прав пользователя и соединение его с системой осуществляется в следующей последовательности (см. рис. 2.4):

Вывод окна диалога с пользователем.

Оператору предлагается либо ввести свое имя, пароль и название базы данных (блок 3) для получения доступа к системе и продолжения работы, либо выйти из системы (блоки 4, 19).

Ввод пользователем идентифицирующих его данных.

Для получения доступа к ЦСК и базе данных пользователю необходимо ввести следующую информацию:

имя базы данных (А),

имя пользователя (В),

пароль ©.

Проверка введенной информации и включение возможности соединения с базой данных (блоки 5−13).

Вначале проверяется полнота ввода (все ли данные введены: А, В и С) (блок 5). Если и А, и В, и С введены, то включается возможность соединения с БД (блок 6) и происходит переход к следующему этапу (п. 4). Затем определяется, какая информация была введена пользователем (блоки 7, 9, 11) и, если введена не вся необходимая информация, то введенные значения присваиваются соответствующим переменным (блоки 8, 10, 12) и происходит переход к п. 3, то есть к вводу недостающих данных.

Рис. 2.4. Алгоритм определения прав доступа Подтверждение соединения с базой данных.

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

Соединение с базой данных (блок 15) и проверка на ошибку (блок 16).

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

Вывод главного окна ЦСК (блок 18).

Алгоритм изменения данных

Изменение данных (см. рис. 2.5) включает в себя следующие функции:

Изменение существующей строки (группа блоков 2−6).

Режим внесения изменений включается при выборе непустой строки (блок 2), она редактируется (блок 3), затем введенная информация проверяется (блок 4) и, в случае ее успешного завершения (блок 5),

Отмена.

Для окончания редактирования (блок 12) в появившемся окне выбора режима (блок 7) выбирается строка «отмена» (блок 8).

Добавление новой записи (строки) — описывается блоками 9−12, 17−19.

Первоначально при выборе режима добавления (блок 9) проверяется, существует ли разбиение экрана (блок 10). Если нет, то экран делится на два окна (две части) (блок 11). Верхнее окно — уже существующие записи, а в нижнем окне создаются новые. Затем создается пустая строка (блок 12), в которую осуществляется ввод данных (блок 17).

Рис. 2.5. Алгоритм изменения данных Удаление строки — блоки 13−16.

Выбор режима удаления (блок 13) для строки означает ее стирание с экрана, если она новая (блок 15), и маркировку строки как удаляемой () в противном случае (блок 16).

Обновление данных (без сохранения внесенных изменений) — группа блоков 21, 40−42.

После проверки наличия разбиения экрана на два окна (блок 40) это разбиение удаляется (блок 41), если оно существует, и происходит вывод данных на экран из БД (блок 42).

Сохранение внесенных изменений.

При выборе этого режима (блок 20) производятся следующие действия:

После проверки на существование (блоки 22, 34) удаляются строки, маркированные как удаляемые, с экрана (блок 35) и соответствующие им записи из базы данных (блок 23); происходит проверка на ошибку (блок 24).

Сохраняются новые строки в базе данных и происходит проверка на ошибку (блоки 25−27).

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

Алгоритм просмотра данных на экране

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

Сначала проводится инициализация полей фильтров (блок 2) — это процесс восстановления введенных пользователем в последний сеанс работы с формой данных в поля, ограничивающие вывод информации в экранные формы. (Например, список сбоев таксофонов, произошедших за первый квартал 2010 года.)

В разделе CURRENT_USERSOFTWAREЦСК<�имя экранной формы> в строковых параметрах, имена которых совпадают с именами полей фильтров, значения которых устанавливаются, хранятся исходные данные. Доступ к ним осуществляется посредством функций API WINDOWS для работы с системным реестром. Значения параметров считываются непосредственно в заполняемые поля.

Потом происходит соединение курсора с базой данных (организация канала связи с базой данных) (блок 3). Курсор — это указатель на результирующий набор данных в БД. Все данные получаются из БД через курсоры, открываемые явно или неявно. Для начала работы с курсором необходимо сопоставить его с открытым сетевым соединением с базой данных. При этом на сервере выделяются ресурсы для работы с будущим результирующим набором данных, на клиенте создается указатель, ссылающийся на эти ресурсы через сетевое соединение.

Затем проводится проверка на ошибку (блок 4) — произошло ли соединение, если ошибка не обнаружена, то подготавливается текст запроса к базе данных (блок 6), в противном случае — выход из режима просмотра после вывода соответствующего сообщения об ошибке (блок 5). После успешного завершения проверки запроса (иначе — сообщение об ошибке (блок 9) и выход из режима) и подготовки курсора к исполнению запроса (блоки 7,8) на экран выводится пустая форма (блок 10) и заполняется данными (блок 11).

Алгоритм вывода данных на печать

Алгоритм вывода данных на печать приведен на рис. 2.7. Последовательность выполнения действий по организации канала связи с базой данных, подготовке текста запроса к БД, проведению соответствующих проверок с выводом сообщений об ошибках (блоки 1−9) аналогична алгоритму просмотра информации на экране дисплея (см. п. 2.6). После успешного завершения проверки запроса на экран выводится форма отчета (блок 10) для предварительного просмотра, затем — видимая часть отчета, заполненного данными, (блок 11). После ввода подтверждения о печати (блок 12) на принтер передается видимая на экране часть отчета (блок 13), затем — оставшиеся данные (блок 14), после этого происходит печать (блок 15).

Рис. 2.6. Алгоритм просмотра данных на экране

Структура меню

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

1. Централизованная система контроля

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

1.2. Список пользователей

1.3. Справочники

1.3.1. Список таксофонов

1.3.2. Коды стран

1.3.3. Коды городов

1.3.4. Типы неисправностей

1.3.5. Виды разговоров

1.3.6. Типы таксофонов

1.3.7. Модемы для таксофонов

1.3.8. Список серий таксофонных карт

1.3.9. Список номеров таксофонных карт

1.4. Справка

1.5. Параметры

2. Таксофон

2.1. Список таксофонов

2.2. Характеристика

2.2.1. Код города, страны

2.2.2. Тариф

2.2.2.1. Городской звонок

2.2.2.2. МГ звонок по рабочим дням

2.2.2.3. МГ звонок по праздничным дням

2.2.2.4. МН звонок по рабочим дням

2.2.2.5. МН звонок по праздничным дням

2.3. Параметры

2.3.1. Виды соединения

2.3.2. Виды разговоров

2.3.3. Максимальное количество цифр в номере

2.3.4. Максимальное время ответа

2.3.5. Бесплатные телефонные номера

2.3.6. Запрещенные номера таксофонных карт

2.3.7. Запрещенные серии таксофонных карт

2.3.8. Разрешенные серии таксофонных карт

3. Управление

3.1. Дата, время перехода на время

3.1.1. Зимнее

3.1.2. Летнее Рис. 2.7. Алгоритм вывода данных на печать

3.2. Дата праздничного дня

3.3. Дата, время ввода тарифов

3.3.1. Городского

3.3.2. Междугороднего

3.3.3. Международного

3.4. Основное время связи с ЦСК

3.5. Резервное время связи с ЦСК

4. Финансы

4.1. Ежедневный отчет

4.2. Отчетность

4.2.1. Ежемесячный отчет

4.2.2. Годовой отчет

5. Статистика

5.1. Ежедневный отчет

5.2. Отчетность

5.2.1. Ежемесячный отчет

5.2.2. Годовой отчет

6. Диагностика

6.1. Ежедневный отчет

6.2. Отчетность

6.2.1. Ежемесячный отчет

6.2.2. Годовой отчет

6.3. Список таксофонов

6.4. Состояние таксофонов

6.5. Истории событий

6.5.1. Отказы

6.5.2. Ремонты

6.5.3. Изменение характеристик

6.5.4. Изменение кодов городов

6.5.5. Изменение тарифов

6.5.6. Изменение параметров

6.5.7. Изменение бесплатных номеров

6.5.8. Изменение «белого списка» (разрешенные серии таксофонных карт)

6.5.9. Изменение «черного списка» (запрещенные серии таксофонных карт)

6.5.10. Прием счетчиков

6.6. Количество опознанных ДТК

6.6.1. Городские

6.6.2. Междугородние

6.6.3. Международные

6.6.4. Проверочные

6.6.5. Неиспользуемого типа

6.6.6. С нулевым содержанием

6.6.7. Из «черного списка»

6.7. Количество срабатываний защиты

6.7.1. От имитаторов

6.7.2. От параллельных подключений

7. Выход

3. Методика испытаний и результаты экспериментальной проверки

Методика испытаний программного обеспечения

Как показано в [5], процесс тестирования программ обычно включает:

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

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

тестирование программы с её исполнением в объектном коде и с разными уровнями детализации: детерминированное, стохастическое, и тестирование в реальном масштабе времени;

диагностику и локализацию причин отклонения результатов тестирования от заданных эталонных значений и правил;

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

реализацию корректировки программы, обеспечивающую соответствие программы заданному эталону.

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

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

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

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

Особенности задачи в приложении к тестированию программ.

Среда программирования Centura и язык программирования в ней SAL имеют ряд особенностей, влияющих на тестирование программ:

SAL является языком программирования высокого уровня, что увеличивает значимость статического (символьного) тестирования;

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

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

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

Особенности поставленной задачи.

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

надежность сервера базы данных и библиотек связи клиента — сервера;

надежность сетевого соединения;

надежность клиентской части.

Первые две компоненты являются стандартными, поэтому имеет смысл лишь проверка надежности третьей компоненты.

Тестирование надежности программного обеспечения.

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

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

высвобождение ненужных системных ресурсов, затребованных ранее;

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

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

В рамках проверки надежности клиентской части было проведено тестирование:

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

вызов формы, обновление данных, добавление новой строки, удаление строки, изменение данных.

Контроль правильности вводимых данных.

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

Ограничения целостности делятся на следующие типы:

Ограничения пустого значения.

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

Ограничения ссылочного ключа.

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

Ограничения уникальности.

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

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

Если на строку данной таблицы ссылаются другие строки, то запрещены операции удаления и изменения этой строки до тех пор, пока ссылающиеся строки не будут удалены либо изменены.

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

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

Функциональное тестирование.

После ввода централизованной системы управления в эксплуатацию все таблицы фиксируют свой размер, так как нет интенсивного ввода (изменения, удаления), кроме таблиц «Параметры таксофонов» и «Счетчики таксофонов».

Зависимость размера файлов БД от срока эксплуатации системы (обслуживание 3000 таксофонов).

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

Таблица «Параметры таксофонов» ежедневно вырастает на 3000 строк. В зависимости от данных в строке последняя занимает вместе со связанными структурами (индексы) от ХХ до ХХХ байт дискового пространства. Средний размер строки предположительно ХХХХ байт.

4. Технологическая часть

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

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

Согласно формулировке стандарта ISO 8402, под качеством понимается совокупность характеристик программного продукта, относящихся к его способности удовлетворять установленные и предполагаемые потребности клиентов. Основными параметрами качества считаются: функциональная полнота, соответствие требованиям законодательства стран СНГ, безопасность информации, простота эксплуатации, не требующая специальных знаний в области информационных технологий, эргономичность пользовательского интерфейса, минимизация затрат на эксплуатацию, развитие и модернизацию.

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

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

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

Этапы создания программного продукта.

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

Анализ осуществимости системы.

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

Планирование и анализ требований к ПО.

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

Проектирование изделия.

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

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

Кодирование.

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

Тестирование.

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

Опытная эксплуатация (внедрение).

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

Коммерческая реализация и функционирование (эксплуатация).

Разработчиком продукта на данной стадии проводится его обслуживание. Для программного обеспечения под обслуживанием понимается сопровождение системы (maintanance) и поддержка заказчиков (customer support).

Сопровождение системы, как правило, включает в себя:

обнаружение и анализ несоответствий в системе, вызывающих сбои в ее работе;

коррекцию программных ошибок;

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

функциональное расширение или улучшение производительности.

Согласно стандарту ISO 9000−3 все действия по сопровождению должны проводиться и контролироваться в соответствии с планом сопровождения, который заранее определяется и согласовывается поставщиком (разработчиком) и заказчиком.

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

Период разработки программного продукта начинается фазой проектирования изделия после успешного анализа требований к ПО и оканчивается фазой испытаний (после успешного завершения анализа результатов приемки ПО).

Проектирование программного продукта.

На сегодня соотношение времени, затраченного на проектирование, кодирование и тестирование составляет 40%, 20% и 40% соответственно.

Проектирование разбивается на несколько этапов:

Разработка технического задания (постановка задачи) и его анализ.

Составление проекта (создание макета) системы.

Алгоритмизация.

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

Итак, рассмотрим более подробно этапы создания программного продукта.

Постановка задачи.

На этапе формирования технического задания (ТЗ) определяются основные технические требования к программному продукту:

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

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

Разработке такого задания для крупных программных систем предшествует большая работа научно-исследовательского характера (фазы 1,2 жизненного цикла ПО).

Задание на разработку программы по форме и характеру должно быть аналогично техническому заданию (ТЗ) на разработку какого-либо технического продукта (см., например, ГОСТ 19.201−78 Единой системы программной документации).

Техническое задание полезно и в том случае, когда заказчик и исполнитель работают в одной и той же комнате или даже являются одним и тем же лицом. Наличие четкой письменной формулировки будет препятствовать подмене или отходу в процессе разработки программы от сформулированных в ТЗ требований в угоду каким-то другим побочным целям. Кроме того, письменно сформулированное задание делает возможным обсуждение, оценку и согласованную с заказчиками (пользователями) корректировку отдельных требований ТЗ в ходе разработки изделия, ТЗ препятствует проникновению в программу таких ошибок и противоречий, которые могут быть обнаружены только после разработки большей части программы или уже на стадии анализа полученных результатов. Чем более формализованным по характеру будет техническое задание, тем больше шансов, что разрабатываемая программа будет решать именно ту задачу, которую имел в виду заказчик.

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

Составление проекта.

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

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

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

предэскизное, эскизное, техническое

— по аналогии с инженерным проектированием.

Алгоритмизация.

На этот этап иногда смотрят как на вспомогательный, подготовительный к выполнению следующего этапа разработки ПО — программированию, или кодированию (см. п. 4.4.), на котором производится написание программы на выбранном языке программирования.

Введение

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

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