Разработка и проектирование информационной системы для салона мобильной связи при помощи Microsoft Access на языке программирования Visual Basic

Курсовая работа РГГУ

Дисциплина: Математические основы баз данных

Исполнитель: Нестеров В.П.

• Введение
• 1.Общая часть
• 1.1 Общие понятия реляционного похода к базам данных
• 1.1.1 Отсутствие кортежей-дубликатов
• 1.1.2 Отсутствие упорядоченности кортежей
• 1.1.3 Отсутствие упорядоченности атрибутов
• 1.1.4 Атомарность значений атрибутов
• 1.2 Реляционная модель данных
• 1.2.1 Общая характеристика
• 1.2.2 Целостность сущности и ссылок
• 2.Практическая часть
• 2.1 Анализ предметной области
• 2.2 Контекст системы
• 2.3 Деятельность объекта проектирования и взаимосвязь на втором уровне модели
• 2.4 Детализация бизнес-процессов
• 2.6 Техническое задание на создание системы
• 2.7 Концептуальная модель базы данных
• 2.8 Выбор программных средств для разработки и реализации системы
• 2.9 Интерфейс для работы пользователя с системой
• 2.10 Тестирование разработанной системы
• Заключение
• Список использованной литературы

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

В общем смысле термин база данных — это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области или разделе предметной области.

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

СУБД Access 2003 — один из компонентов широко распространенного семейства офисных приложений Microsoft Office 2003. Microsoft Access на сегодняшний день является одним из самых популярных настольных приложений для работы с базами данных. Это связано с тем, что Access обладает очень широким диапазоном средств для ввода, анализа и представления данных. Эти средства являются не только простыми и удобными, но и высокопродуктивными, что обеспечивает высокую скорость разработки приложений. Изначально Access обладала рядом уникальных возможностей, таких как умение сводить воедино информацию из самых разных источников (электронных таблиц, текстовых файлов, других баз данных), представление данных в удобном для пользователя виде с помощью таблиц, диаграмм и отчетов, интеграция с другими компонентами Microsoft Office. Совершенствуясь от версии к версии, Access стала инструментом, который может удовлетворить самые разные категории пользователей от новичка, которому нравится дружественный интерфейс системы, позволяющий ему справиться с его задачами, до профессионального разработчика, который имеет весь необходимый инструментарий для построения готового уникального решения для конкретного предприятия среднего бизнеса.

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

Основными задачами курсовой работы являются:

· Изучить принципы организации и построения БД.

· Анализ поставленной задачи в создании БД.

· Выбрать предметную область и спроектировать БД.

· Разработать БД в среде Fox PRO 8.0.

· Осуществить заполнение БД.

· Разработать запросы, отчеты, формы к БД.

· Оформление расчетно-пояснительной записки.

· Защита курсовой работы.

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

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

1) создавать и модифицировать таблицы, хранимые процедуры, представления данных;

2) добавлять созданные ранее таблицы;

3) определять для таблиц индексы;

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

1.Общая часть

1.1 Общие понятия реляционного похода к базам данных

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

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

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

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

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

Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений:

1.1.1 Отсутствие кортежей-дубликатов

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

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

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

1.1.2 Отсутствие упорядоченности кортежей

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

1.1.3 Отсутствие упорядоченности атрибутов

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

1.1.4 Атомарность значений атрибутов

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

Можно сказать, что здесь мы имеем бинарное отношение, значениями атрибута ОТДЕЛЫ которого являются отношения. Заметим, что исходное отношение СОТРУДНИКИ является нормализованным вариантом отношения ОТДЕЛЫ:

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

Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 320 и Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 310.

Если информация о сотрудниках представлена в виде отношения СОТРУДНИКИ, оба оператора будут выполняться одинаково (вставить кортеж в отношение СОТРУДНИКИ). Если же работать с ненормализованным отношением ОТДЕЛЫ, то первый оператор выразится в занесение кортежа, а второй — в добавление информации о Кузнецове в множественное значение атрибута ОТДЕЛ кортежа с первичным ключом 310.

1.2 Реляционная модель данных

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

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

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

1.2.1 Общая характеристика

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

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

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

1.2.2 Целостность сущности и ссылок

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

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ (ОТД_НОМЕР, ОТД_КОЛ) (первичный ключ — ОТД_НОМЕР) и СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ) (первичный ключ — СОТР_НОМЕР).

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

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

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

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

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

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

2. Практическая часть

2.1 Анализ предметной области

Автоматизации подлежит деятельность салона связи. Рассматривается деятельность салона с точки зрения руководителя салона. Будем считать, что основными функциями, выполняемыми салоном, являются: проведение рекламных акций и консультаций абонентов связи (настройки телефонов под конкретных операторов, подключение опций), продажа средств связи, подключение к различным операторам связи, прием платежей за услуги связи. Так как рассматриваем салон связи с точки зрения его руководителя, то следует учесть и внутренние процессы деятельности, такие как поступление продаваемых товаров на склад и составление отчетности в разные контролирующие органы. Исходя из этого, полагаем, что автоматизации будут подлежать такие области как учет товаров (средств связи, аксессуаров и комплектующих), поставщиков товаров, оформление и продажа sim-карт и их покупателей, расчет с покупателями. Важно, чтобы сотрудники правильно и своевременно выполняли свои обязанности, только в этом случае возможна успешная деятельность салона.

2.2 Контекст системы

Построим контекст системы (рис. 2.1)

Рис. 2.1 Взаимодействие моделируемого объекта

Контекстная функция, или функция, описывающая систему в целом — деятельность салона связи.

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

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

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

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

2.3 Деятельность объекта проектирования и взаимосвязь на втором уровне модели

информационный microsoft access visual basic

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

Рис. 2.3.1 Основные деятельности объекта и их взаимосвязи (IDEF0).

2.4 Детализация бизнес-процессов

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

Рис. 2.4.1. Декомпозиция деятельности «Консультации, реклама» (IDEF3)

Рис. 2.4.2. Декомпозиция деятельности «Продажи» (IDEF3)

Рис. 2.4.3. Декомпозиция деятельности «Прием платежей» (IDEF3)

Рис. 2.4.4. Декомпозиция деятельности «Прием и учет товаров на складе» (IDEF3)

Рис. 2.4.5. Декомпозиция деятельности «Составление отчетов» (IDEF3)

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

Рис. 2.4.7. Детализация процесса «Покупка sim-карты» деятельности «Продажи» (IDEF3)

Рис. 2.4.8. Детализация процесса «Внесение данных о покупателе и sim-карте» (DFD)

Рис. 2.4.9. Детализация процесса «Покупка телефона, комплектующих» деятельности «Продажи» (IDEF3)

Рис. 2.4.10. Детализация процесса «Выписка чека» деятельности «Продажи» (DFD)

Рис. 2.4.11. Детализация процесса «Выдача счета» деятельности «Прием платежей» (DFD)

Рис. 2.4.12. Детализация процесса «Внесение данных о товаре» деятельности «Прием и учет товаров на складе» (DFD)

2.6 Техническое задание на создание системы

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

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

2.7 Концептуальная модель базы данных

Основой для создания модели базы данных являются DFD-диаграммы, на которых отражены хранилища данных. Таким образом получаем следующую схему, разработанную в системе Microsoft Access (рис. 2.7.1):

Рис. 2.7.1 Модель базы данных

2.8 Выбор программных средств для разработки и реализации системы

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

Данная программа может работать в таких операционных системах как Windows XP и Windows Vista — поскольку выбранный язык программирования Visual Basic .NET работает на платформе любой из этих ОС.

Выбранная СУБД — Microsoft Office Access 2003. Она обеспечивает нормальное функционирование программы, а также необходимые скоростные характеристики обработки информации. В таблице 2.8.1 представлены параметры Access в сравнении с СУБД Visual FoxPro.

Сравнение Microsoft Office Access и Visual FoxPro.

Таблица 2.8.1

Таким образом, можно сказать, что Visual FoxPro отличается высокой скоростью, имеет встроенный объектно-ориентированный язык программирования с использованием xBase и SQL. Однако в отличие от Visual FoxPro, фактически превратившегося в средство разработки приложений, Access ориентирован в первую очередь на пользователей Microsoft Office, в том числе и не знакомых с программированием, а сейчас мало людей не знакомых с компанией Microsoft Office, то есть простота использования один из самых решающих факторов выбора этой СУБД.

Программа Visual Basic была специально разработана и идеально подходит для создания интерфейса пользователя, или проектирования «лицевой стороны» программы, а также для работы с имеющимися базами данных, в том числе Microsoft Access. Visual Basic .NET предусматривает технологию обработки баз данных, аналогичную используемой Microsoft Access. Это дает возможность создавать основные приложения для работы с базами данных с помощью всего нескольких десятков строк в тексте программы.

Для выбора характеристик компьютера необходимо учесть следующие моменты: время получения результатов запросов к базе данных допустимо в пределах нескольких секунд, то есть требования к скорости обработки данных невысоки; необходимо предусмотреть возможное развитие системы (увеличение объема базы данных, переход к новым версиям операционной системы и СУБД, включение системы в локальную вычислительную сеть и т. д.). Таким образом, технические требования следующие: процессор Pentium 233 МГц или выше, объем оперативной памяти 256 Мбайт или выше, емкость жесткого диска 16 Мбайт, монитор, клавиатура, мышь, принтер.

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

Таким образом, исходя из особенностей предметной области и учитывая совместимость выбранных программных средств и предпочтения разработчика, можно заключить, что Visual Basic.NET и СУБД MS Access являются оптимальными средствами разработки приложения.

2.9 Интерфейс для работы пользователя с системой

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

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

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

Эскизы форм приведены ниже на рис. 2.9.2 — 2.9.7.

Рис. 2.9.2 Внешний вид главной формы Рис. 2.9.3 Внешний вид формы «Sim-карты» из списков Аналогичен внешний вид форм «Продажи», «Счета», «Товары», «Партии товаров», «Покупатели», «Поставщики» и «Платежи» из меню «Списки».

Рис. 2.9.4 Внешний вид формы для приема платежей Рис. 2.9.5 Внешний вид формы «Склад»

Рис. 2.9.6 Внешний вид формы для регистрации продаж Рис. 2.9.7. Форма для регистрации «Sim-карт»

В форме «Склад» дополнительно можно открыть приложение MS Excel для ведения товарных накладных и учета карточек поставщиков (рис. 2.9.8, 2.9.9).

Рис. 2.9.8 Лист «Товарная накладная»

Рис. 2.9.9 Лист «Карточка поставщика»

В форме «Продажи» дополнительно можно открыть приложение MS Excel для ведения книги продаж и учета товарных чеков (рис. 2.9.10, 2.9.11).

Рис. 2.9.10 Лист «Книги продаж»

Рис. 2.9.11 Лист «Товарный чек»

В форме «Регистрация sim-карт» дополнительно можно открыть приложение MS Excel для ведения карточек покупателей и учета товарных чеков (рис. 2.9.12).

Рис. 2.9.12 Лист «Карточка клиента»

2.10 Тестирование разработанной системы

Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок. Процесс тестирования состоит из следующих этапов: 1) создание плана тестирования; 2) связывание плана с тестами; 3) пометка и выполнение тестов; 4) получение отчетов о тестировании и управление результатами.

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

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

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

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

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

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

1) наличие сообщений об ошибках, обмен сообщениями с пользователями по поводу производимых им действий;

2) корректность в выполнении таких действий как удаление, добавление и редактирование записей;

3) правильность составления отчетов;

4) визуальная проверка программного кода;

5) правильность и полнота информации при ее сохранении.

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

Заключение

В ходе выполнения курсовой работы спроектирована и разработана информационная система для заданного объекта проектирования — салона мобильной связи. Результат разработки — приложение, выполненное при помощи средств СУБД — Microsoft Access на языке программирования Visual Basic. NET.

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

Руководство пользователя:

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

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

3. Для внесения информации о наличии материалов на складе и поставщиках нужно выполнить команду Открыть/Склад и внести нужные данные. Аналогичные действия производятся для внесения данных о принятых платежах, произведенных продажах товаров и sim-карт. Для редактирования данных можно использовать команды «Удалить», «Сохранить», «Добавить». Для перемещения по таблице с данными можно использовать стрелки навигации, находящиеся на каждой форме.

4. Для закрытия форм со списками и форм для расчета нужно нажать кнопку «Закрыть», имеющуюся в каждой форме. При этом появится диалоговое окно с запросом о сохранении произведенных изменений в форме. Чтобы сохранить данные, нужно нажать на кнопку «Да», в противном случае — «Нет».

5. Для выхода из приложения нужно выполнить команду Выход и подтвердить намерение закрытия приложения.

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

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2009. — 352 с.: ил.

2. Голованов А. А. Конспекты лекций по дисциплине «Разработка и стандартизация программных средств и информационных технологий».

3. джеймс фокселл. Освой самостоятельно Visual Basic .NET за 24 часа.: Пер. с англ. — М.: Издательский дом «Вильяме», 2010. — 416 с.: ил. — Парал. тит. англ.

4. Билл Ивьен, Джейсон Берес. Visual Basic .NET. Библия пользователя: Пер. с англ. — М.: Издательский дом «Вильяме», 2010. — 1024 с.: ил. — Парал. тит. англ.

5. Visual Basic.NET/Трусов М.А. — М.: НТ Пресс, 2009. — 176 с.: ил. — (Просто о сложном).