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

Также в этом разделе будут представлены основные требования к системе:

1. режимы работы программы;
2. функции, выполняемые в каждом режиме;
3. принципы смены режимов и параметров;
4. структура входной информации и принцип её ввода;
5. принцип выходной информации, вид представления результатов: сообщения, таблицы, графики, файлы;
6. алгоритмы обработки информации.

 

Основными режимами работы разрабатываемой программы  являются :

• ввод информации;
• вывод информации;
• редактирование информации;
• удаление информации;
• поиск интересующей информации.

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

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

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

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

Таблица 4.1.1. Требования к функциональности

Параметр сценария	Возможное значение
Источник стимула	Пользователь, разработчик, администратор  БД
Стимул	Ввод/редактирование/вывод информации
Условия	Система в рабочем режиме
Артефакт	Информация, вводимая в специальную  форму/Информация, хранящаяся в таблицах БД
Реакция	Ввод : сохранение информации; Редактирование: вывод формы для редактирования, сохранение результата в БД; Вывод : вывод требуемых данных на экран.
Количественная мера реакции	Обработка запроса не более чем  за 0.005 сек

 

Требования реализуются модулем  изменения информации.

4.2.) Требования к надежности

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

Таблица 4.2.1. Требования к  надёжности

Параметр сценария	Возможное значение
Источник	Пользователь
Стимул	Некорректный ввод данных
Условия	Система в рабочем режиме
Артефакт	СУБД
Реакция	Проверка корректности вводимых данных. В случае неверного ввода переход  в режим с ухудшенными характеристиками (за счет уменьшения возможностей происходит нейтрализация неисправностей); система  должна обнаружить событие и выполнить  следующее действие: оповестить пользователя об ошибке и предложить пользователю диалоговое окно, в котором пользователь сможет выбрать одно из следующих  действий : изменить БД (одну из таблиц) или добавить значения по умолчанию.
Количественная мера реакции	Время на обнаружение и устранение ошибки ≈10-3 сек

 

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

  4.3.) Требования к производительности

Параметр сценария	Возможное значение
Источник	Внешний по отношению к системе (пользователи)
Стимул	Непериодическое инициирование 1500 транзакций в минуту
Условия	Система в рабочем режиме
Артефакт	Модуль просмотра данных
Реакция	Переход из нормального режима работы в перегруженный
Количественная мера реакции	Время на обработку транзакций не более 5 сек

 

Требования реализуются модулем  доступа к данным и модулем  кэширования.

4.4.) Требования к модифицируемости

Параметр сценария	Возможное значение
Источник	Разработчик
Стимул	Изменение существующих функций
Условия	Проектирование
Артефакт	Подсчёт зарплаты сотрудника с учётом процента от продаж
Реакция	Тестирование изменений
Количественная мера реакции	Время модификации не более 2 часов

 

 

 

Параметр сценария	Возможное значение
Источник	Разработчик
Стимул	Внесение изменения в пользовательский интерфейс
Условия	Тестирование
Артефакт	Пользовательский интерфейс
Реакция	Локализация изменений в модуле добавления данных
Количественная мера реакции	Время модификации не более 2 часов

 

Требования реализуются модулем  автоматического обновления данных в БД.

4.5.) Требования к безопасности

Параметр сценария	Возможное значение
Источник	Пользователь без прав доступа
Стимул	Попытка ввести/изменить данные
Условия	Оперативный/неоперативный режим, наличие подключения к сети
Артефакт	Данные, хранящиеся в системе
Реакция	Сообщение от системы о попытке  изменить данные пользователем без  прав доступа; занесение ip-адреса злоумышленника в таблицу; запрет на изменение данных с этого ip.
Количественная мера реакции	Время восстановления  не более 1 мин.

 

Требования реализуются модулем  доступа к данным и модулем  обновления данных в БД.

4.6. Требования к составу и параметрам технических средств

РС совместимый  компьютер (производительность не ниже Intеl х64  1.7 Ггц, 3 Гб оперативной памяти, 35гб свободного места на жестком диске SSD) с установленной операционной системой Windows Server 2008 R2.

4.7. Требования к информационной  и программной совместимости

Требуется установленная  система Windows Server 2008 R2 система должна поддерживать ввод/вывод русских букв. Веб-сервер IIS 7, и СУБД MSSQL. Данная БД имеет русский интерфейс, следовательно, операционная система должна поддержать русский язык. 

4.8. Требования к маркировке и  упаковке

Нет.

4.9. Требования к транспортированию  и хранению

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

4.10. Требования к программной документации

В состав документации входит пояснительная записка

4.11. Планирование тестирования

1. Какие компоненты ПО подлежат тестированию:

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

2. Основание для тестирования:

Ошибки  в структуре данных, ключах и связях.

3. Как часто стоит выполнять тестирование:

Тестирование  производится во время процесса разработки БД.

4. Кто выполняет тестирование:

Разработчик программного продукта.

5. Как выполняется тестирование:

Тестирование  проходит с учётом структуры БД и  её таблиц. Сначала при необходимости  проводится вставка некоторых первоначальных данных. Далее проверяется состояние  БД после выполнения каких-либо запросов (удаление, редактирование, вычисления параметров и т.д.). После этого  необходимо очистить БД и повторить  всё вышеперечисленное для каждого  теста.

6. Сколько длится тестирование:

Необходимо  написать тест для каждого столбца  всех таблиц (всего 50 столбцов) во время  разработки и после каждой модификации  БД.

Стадии  и этапы разработки

 

Номер этапа	Содержание этапа	Отчётные материалы	4 нед.	7 нед.	11 нед.	14 нед.
1	Исследовате-льская часть	17 листов формата А4 РПЗ
2	Техническое задание	4 листа формата А4 РПЗ
3	Конструктор-ская часть	14 листов формата А4 РПЗ
4	Технологи-ческая часть	3 листа формата А4 РПЗ

 

 

Конструкторская часть

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

Разработка  распределенной  информационной системы на основе паттерна проектирования Publisher/Broker/Subscriber.

Работу разрабатываемого приложения можно описать следующим  образом:

1. Подписчик формирует запрос и посылает его брокеру в виде объекта.
2. Брокер проверяет, разрешено ли подписчику делать запрос (проверяется также тип запроса)  и только в положительном случае формирует SQL-запрос к БД.
3. СУБД возвращает данные из БД.
4. Внесение измений в БД может осуществлять брокер.Причем у брокера есть функционал  CRUD (Create – Read – Update – Delete).
5. Паблишер отправляет данные брокеру в виде объекта, брокер добавляет данные в БД.

4.1. Выбор СУБД

БД – это  автоматизированное справочное бюро, предназначенное для хранения и  обработки больших объемов однородной информации. Основной функцией БД является выдача ответов на запросы пользователей (или клиентов БД). БД состоит из информационного  фонда (называемого также состоянием БД) и программы, управляющей этим фондом. Эта программа называется системой управления базами данных (или  СУБД). [2]

В данной работе в качестве СУБД была выбрана MSSQL.

СУБД MSSQL основывается на реляционной модели. Это значит, что данные хранятся в виде отношений (по-английски - relation, отсюда и название модели) или, проще говоря, таблиц. Эти таблицы делятся на базисные, в которых хранятся исходные данные и производные, которые получаются в результате работы СУБД. В частности, ответы на запросы пользователя также представляются в виде производных таблиц. По сути, работа СУБД заключается в переработке таблиц. [2]

В MSSQL в качестве языка запросов используется SQL.

SQL - сокращение от Structured Query Language (структурированный язык запросов). SQL создан для работы с реляционными базами данных. Он позволяет пользователям взаимодействовать с базами данных (просматривать, искать, добавлять и управлять данными). MSSQL соответствует спецификации ANSI 92 SQL. [3]

СУБД MSSQL широко распространена в глобальной сети Интернет. Большинство провайдеров интернет-услуг предоставляют сервисы MSSQL.

MSSQL подходит для решения большинства повседневных задач, поэтому нет необходимости использовать более сложные и узкоспециализированные СУБД [7].

По сравнению с MySQL MSSQL обладает более дружественным инструментом управления базами данных и разработки, таким как SQL Server Management Studio и средствами анализа данных. MSSQL удобен для быстрой разработки приложений работающих с данными. И так как среда разработки MS Visual Studio отлично работает в связке  c MSSQL, то для данной системы идеальным выбором будет использование SQL Server 2008 R2.

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