Разработка базы данных для оформления заявок клиентов телефонной сети на примере ФГУП «ЦАГИ»

 

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

События в формах или отчетах могут  запускать макросы или процедуры VBA [5]. Событие - любое изменение состояния  объекта Access, например открытие формы, закрытие формы, ввод новой строки в форму, изменение содержимого текущей записи или элемента управления. Для обработки события можно создать макрос или процедуру VBA, с помощью которых можно предусмотреть реакцию на любое действие пользователя, вплоть до нажатия определенных клавиш во время ввода данных. С помощью макросов и модулей можно изменять ход выполнения приложения; открывать, фильтровать и изменять данные в формах и отчетах; выполнять запросы и создавать новые таблицы. Используя VBA, можно создавать, модифицировать и удалять любой объект Access, обрабатывать данные по строкам и по столбцам или каким-либо другим способом. Можно также вызывать процедуры из библиотек динамической компоновки Windows, чтобы использовать в приложении не только встроенные в Access функции, но и возможности Windows.

Учитывая все вышесказанное, мы остановимся на СУБД Access для разработки нашего программного продукта.

2.1.4. Построение датологической модели

 

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

Датологическая модель строится в терминах базы данных. Так как в нашем случае используется СУБД ACCESS, то мы строим реляционную модель базы данных в реализации MS ACCESS.

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

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

Построенная датологическая модель БД, с учетом особенностей MS ACCESS, выглядит следующим образом:

 

Таблица «Список абонентов»

 

(Таблица 1)

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

Виды запросов:

1. Список абонентов по конкретному корпусу
2. Список телефонных номеров по группам
3. Список магистралей ГР по диапазонам

(Рис 1)

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

Нумерация телефонных номеров  в «ЦАГИ» четырехзначная. Номер телефона определяется в группу в зависимости  от первой цифры. Каждый корпус имеет  определенную магистраль ГР, но бывает так, что часть этих магистралей  распределяется на несколько корпусов, поэтому был создан запрос по диапазону  ГР.

 

(Таблица 2)

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

(Рис 2)

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

1. Конкретному корпусу
2. Конкретному диапазону телефонных номеров
3. По всем абонентам телефонной сети

(Таблица  3)

2.2. Общая структура организации работ по проектированию ПП

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

Задача, которую  предстоит решить программисту на ЭВМ, формулируется им самим или выдается ему в виде специального задания  на разработку программы [6]. Задание  содержит формулировку задачи, необходимые  характеристики разрабатываемой программы, требования к взаимодействию с ней. Выдаче такого задания для крупных  задач может предшествовать большая  работа научно-исследовательского характера.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.4. Программирование

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

 Основные  трудности и, следовательно, причины  ошибок на этом этапе заключаются,  во-первых, в необходимости знания  всех требований и ограничений  выбранного языка программирования  и, во-вторых, в необходимости постоянного внимания ко многим деталям языка, которые приходится учитывать в ходе написания программы. Если этап 3 был выполнен некачественно и алгоритм представлен недостаточно детально, то его доводку придется выполнять «на ходу», во время программирования. Это затруднит процесс программирования-перевода и поведет к возникновению дополнительных ошибок в программе. Чем более процесс программирования будет походить на перевод, чем более механическим будет такой перевод, тем более легким будет составление программы и тем меньше возникнет ошибок на этом этапе, самом щедром на ошибки.

После составления  программы проводится ее проверка для  обнаружения и исправления ошибок, внесенных на этом этапе. Если при  проверке обнаруживаются ошибки, допущенные на предыдущем этапе (3), то соответствующие  исправления вносятся и в алгоритм, поскольку к нему еще придется обращаться на следующих этапах, и  тексты алгоритма и программы  должны соответствовать друг другу.

2.2.5. Препарация

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

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

2.2.6.  Трансляция

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

2.2.7. Отладка

На этапе отладки  производится обнаружение с помощью  ЭВМ ошибок в программе и их исправление. Этап отладки можно  разделить на три подэтапа:

• Контроль правильности программы (КПП).
• Локализация ошибок  (ЛО).
• Исправление ошибок (ИО).

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