56
- сбой в электроснабжении рабочей станции пользователей системы;
- сбой в электроснабжении обеспечения локальной сети (поломка сети);
- сбои программного обеспечения сервера [23, c.77].
Обеспечение информационное безопасности системы должно
удовлетворять следующим требованиям:
- Защита системы должна обеспечиваться комплексом программно-
технических средств и поддерживающих их организационных мер.
- Защита системы должна обеспечиваться на всех технологических
этапах обработки информации и во всех режимах функционирования, в том
числе при проведении ремонтных и регламентных работ.
Программно-технические средства защиты не должны существенно
ухудшать основные функциональные характеристики Системы (надежность,
быстродействие, возможность изменения конфигурации).
Защита от несанкционированного доступа должна быть организована в
приложении в форме авторизации пользователей и разграничении прав
доступа. Должен быть реализован разноуровневый доступ к информации в
рамках политики безопасности предприятия. Организационно-штатная
структура организации, в которой будет функционировать ИС, должна
включать, как минимум:
• Сотрудника обслуживания устройств, включая настройку ПО ИС.
• Сотрудника, который будет вести учет данных, и анализировать
информацию по результатам работы системы.
57
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Для построения модели данных используется инструмент – ERWin
(средство разработки структуры базы данных). Разработка модели базы
данных состоит из двух этапов: составление логической модели и создание
на ее основе физической модели. ERwin полностью поддерживает такой
процесс, он имеет два представления модели: логическое и физическое.
Таким образом, разработчик может строить логическую модель базы данных,
не задумываясь над деталями физической реализации, т. е. уделяя основное
внимание требованиям к информации и бизнес-процессам, которые будет
поддерживать будущая база данных.
Результатом построения концептуальной модели является диаграмма
сущностей, представленная на рисунке 2.1.
Рисунок 2.1 - Диаграмма сущностей
Описание логической модели данных лучше всего представить в виде
диаграммы «сущность-связь» (ER - диаграммы).
На рисунке 2.2 представлена ER-диаграмма данных.
Польз ователь
Товар
Категория
Продажа
СоставПродажи
58
Рисунок 2.2 - ER-диаграмма
Связи между сущностями неидентифицирующие, мощность 1 к n. Все
внешние ключи не входят в составной первичный ключ сущности.
Для обеспечения нормальной работы БД, устранения избыточности и
других аномалий необходимо произвести нормализацию БД и привести ее,
как минимум, к третьей нормальной форме.
Признаки принадлежности к нормальным формам:
Первая нормальная форма:
1. Все атрибуты должны быть атомарными.
Вторая нормальная форма:
1. Необходимо выполнение условий первой нормальной формы.
2. Каждый не ключевой атрибут должен функционально полно зависеть
от первичного ключа.
Третья нормальная форма:
3. Необходимо выполнение условий второй нормальной формы.
4. Каждый не ключевой атрибут должен нетранзитивно зависеть от
первичного ключа.
Проанализировав структуру отношений на предмет выполнения условий
нормальных форм, заключим, что все таблицы БД приведены к третьей
нормальной форме.
Пользователь
НомерПользователя
ФИО
Логин
Пароль
Почта
Права
Товар
НомерТовара
НомерКатегории (FK)
Наименование
Цена
Описание
Картинка
Категория
НомерКатегории
Категория
Продажа
НомерПродажи
НомерПользователя (FK)
ДатаПродажи
Тип
СоставПродажи
НомерСостава
НомерПродажи (FK)
НомерТовара (FK)
Количество
59
Диаграмма физической модели данных генерируется автоматически
программой Data Modeler (рис. 2.3).
Рисунок 2.3 - Физическая модель данных
Физическая модель содержит всю информацию, необходимую для
реализации конкретной базы данных. Была произведена генерация схемы
физической базы данных для модели предметной области в среде ERWin
путем выбора целевой СУБД MySQL. При этом сущности логической модели
становятся таблицами базы данных, а атрибуты – полями таблиц.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
В качестве входной информации используются следующие сведения:
1. Данные о товарных группах и товарах,
2. Данные о пользователях, указываются при регистрации,
3. Данные для авторизации в системе,
4. Выбор товаров покупателем при покупке,
5. Подтверждение покупки покупателем,
6. Подтверждение покупки администратором.
user
iduser: Number
fio: String
login: String
parol: String
mail: String
permission: String
merch
idmerch: Number
idcategory: Number (FK)
merch: String
price: Number
annotation: String
file: String
category
idcategory: Number
category: String
sale
idsale: Number
iduser: Number (FK)
kind: String
datesale: Datetime
detail
iddetail: Number
idsale: Number (FK)
idmerch: Number (FK)
countmerch: Number
60
2.2.3. Характеристика результатной информации
Выходными данными системы являются:
1. Каталог товаров для выбора покупателя,
2. Сформированная корзина покупателя с выбранными товарами,
3. Печатная форма с перечнем заказов в формате Excel-документа.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Диаграмма вариантов использования играет центральную роль в
моделировании поведения информационной системы или подсистемы. Она
отображает множество прецедентов, актеров, а так же и отношения между
ними. Этот вид диаграмм облегчают понимание системы, подсистемы или
класса, представляя взгляд со стороны на то, что данные элементы могут
использовать в соответствующем контексте.
Диаграмма вариантов использования приведена на рисунке 2.4.
На диаграмме вариантов использования представлены два актер –
Покупатель и Администратор, а также следующие прецеденты:
Работа со справочной информацией (Режим администратора):
o Добавить категорию;
o Добавить товар;
o Добавить пользователя;
Работа со справочной информацией (Режим покупателя):
o Выбор товара;
o Просмотр аннотации;
o Очистить корзину;
o Подтверждение покупки;
Регистрация;
61
Просмотр информации о магазине.
Покупатель
Подтверждение покупки
Покупка товара
*
*
Выбор товара
«
include
»
Работа со справочной информацией
Добавить товар
Администратор
«
include
»
*
*
*
*
Добавить категорию
«
include
»
*
*
Просмотр информации о магазине
Добавить пользователя
«
include
»
Регистрация
«
include
»
Просмотр аннотации
«
include
»
Очистить корзину
«
include
»
Рисунок 2.4 - Диаграмма вариантов использования
Диаграммы последовательности отражают взаимодействие
компонентов и объектов информационной системы. Диаграмма
последовательности — это упорядоченная по времени диаграмма
взаимодействия пользователя и системы, читать ее следует сверху вниз.
Диаграмма последовательностей приведена на рисунке 2.5.
62
Администратор Каталог товаров
магазин-Интернет
Добавить товар в каталог
Обновить каталог
Покупатель
Авторизация на сайте
Каталог товаров
Добавить товары в корзину
Ввести необходимое количество
Подсчитать стоимость заказа
Сохранить изменения
Добавить заказ в статусе "Корзина"
Подтвердить заказ
Добавить заказ в статусе "Заказ"
Уведомить менеджеров по продажам
Рисунок 2.5 - Диаграмма последовательностей
2.3.2. Характеристика базы данных
Для организации хранилища данных веб-приложения используется
СУБД MySQL. С помощью программного средства phpMyAdmin была
реализована база данных polygraphy (рис. 2.6).
Описание физической модели приведено в таблицах 2.1-2.5.
63
Рисунок 2.6 - Реализация базы данных в phpMyAdmin
Таблица 2.1
Структура таблицы user (Пользователь)
Таблица 2.2
Структура таблицы category (Категория)
Таблица 2.3
Структура таблицы merch (Товар)
Наименование
Содержание
Тип поля
Разме
р поля
Ключ
или
индекс
iduser
Идентификатор
пользователья
Int,
автоинкремент
11
PK
fio
Фамилия, имя, отчество
пользователя
varchar
80
login
Логин пользователя
varchar
80
parol
Пароль пользователя
varchar
80
mail
Электронная почта
пользователя
varchar
80
permission
Права пользователя:
покупатель или
администратор
varchar
80
Наименование
Содержание
Тип поля
Размер
поля
Ключ
или
индекс
idcategory
Идентификатор
категории
Int,
автоинкремент
11
PK
category
Категория товара
varchar
80
Наименование
Содержание
Тип поля
Размер
поля
Ключ
или
индекс
idmerch
Идентификатор товара
Int,
автоинкремент
11
PK
idcategory
Идентификатор
категории
Int
11
FK
merch
Наименование товара
varchar
80
64
Таблица 2.4
Структура таблицы sale (Продажа)
Таблица 2.5
Структура таблицы detail (Состав продажи)
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
В качестве модели доступа к данным выбрана модель удаленного
доступа. Предполагаемая организация архитектуры аппаратной платформы –
клиент-серверная, представленная на рисунке 2.6.
Сервер
СУБД
{ПО=MySQL}
Apache
{ПО=PHP}
Клиент
Пользователь
{ПО=Браузер}
Рисунок 2.6 - Диаграмма размещения
price
Цена товара
Int
11
annotation
Описание товара
varchar
500
file
Файл для фото товара
varchar
80
Наименование
Содержание
Тип поля
Размер
поля
Ключ
или
индекс
idsale
Идентификатор
продажи
Int,
автоинкремент
11
PK
iduser
Идентификатор
покупателя
Int
11
FK
datesale
Дата продажи
date
8
kind
Состояние продажи:
«корзина» или «Заказ»
varchar
80
Наименование
Содержание
Тип поля
Размер
поля
Ключ
или
индекс
iddetail
Идентификатор
детализации
Int,
автоинкремент
11
PK
idsale
Идентификатор
продажи
Int
11
FK
idmerch
Идентификатор товара
Int
11
FK
countmerch
Количество товара в
продаже
Int
11
65
Серверная часть состоит из:
а) сервер базы данных с установленной MySQL;
б) web-сервер Apache версии 1.3;
в) транслятор PHP версии 5.1.
Клиентская часть системы представлена браузером пользователя.
Логическая и физическая структура сайта приведена на рисунках 2.7,
2.8. На рисунке 2.7 изображены названия страниц приложения и их
назначение. На рис. 2.8 изображены имена файлов, которые выполняют
назначение с рисунка 2.7.
Рисунок 2.7 - Логическая структура сайта