|
Программное средство
|
Категория
|
ФО1
|
ФО2
|
ФО3
|
|
|
ФП1.1
|
ФП1.2
|
ФП1.3
|
ФП2.1
|
ФП2.2
|
ФП2.3
|
ФП3.1
|
ФП3.2
|
|
MS Excel
|
Общего назнач.
|
|
\
|
x
|
x
|
|
|
|
|
|
Adobe acrobat
reader
|
Общего назнач.
|
\
|
|
|
|
|
|
|
|
|
ОС
|
Системное
|
/
|
/
|
/
|
|
|
|
|
|
Веб-браузеры
|
Общего назнач.
|
/
|
|
|
/
|
|
|
|
|
|
TecDoc
|
Специализ
|
x
|
/
|
|
|
|
|
|
|
|
Microcat
|
Специализ
|
x
|
/
|
|
|
|
|
|
|
В таблице использованы следующие обозначения:
– × - основное использование в процессе,
решение основных задач;
– \ - частичное использование, вспомогательное
использование,
– / -
обеспечение работы других средств
1.3.4 Локальная сеть предприятия
На
фирме ИП не используется постоянная локальная сеть. Вместо этого в случае
необходимости используется временное соединение между компьютерами на основе
использовании технологии беспроводных сетей Wi-Fi с
методом доступа типа точка-точка (Ad-hoc). Сети типа Ad-hoc относятся к классу
беспроводных динамических самоорганизующихся сетей - децентрализованных
беспроводных сетей
<#"516549.files/image005.gif">
Рисунок 1.5 - Схема документооборота предприятия
1.3.8 Проблемные ситуации и способы их решения
Проблемная ситуация возникает всякий раз, когда имеет место расхождение
между желаемым и реальным состоянием системы (процесса, объекта).
Выявление и формулировка проблемной ситуации является одним из наиболее
сложных и ответственных этапов процесса предпроектного обследования
предприятия. Четкая формулировка имеющейся проблемной ситуации является
наиболее важной ступенью в решении самой проблемы.
В реальных условиях предприятие имеет множество проблем. Необходимо
выделить основные, первичные проблемы. Устранение первичных проблем всегда
содействует устранению многих второстепенных, вторичных проблем.
Выявленные проблемы, присущие обследованному ИП, представлены в таблице
1.11.
Таблица 1.11 - Проблемные ситуации в деятельности ИП
|
Наименование проблемной
ситуации
|
Средства решения
|
|
1. Сложности в подборе
необходимого товара для клиента
|
Предоставление клиентам
экспертной системы поддержки принятия решений
|
|
2. Слабо выраженные
средства популяризации предприятия
|
Повышение эффективности
маркетинговой компании, поиск дополнительных средств рекламы предприятия
|
|
3. Неудобные средства учета
товара
|
Автоматизация учета
товарно-денежных операций
|
|
4. Трудности при работе
продавцов с прайс-листом
|
Формализация каталога
товаров
|
|
5. Излишне массивный
аппарат управления фирмой
|
Реорганизация
управленческого аппарата, сокращение сотрудников с перераспределением их
обязанностей
|
|
6. Низкая скорость
оперативной обработки заказов
|
Добавление возможности
заблаговременного оформления предварительного заказа
|
|
7. Низкая скорость расчета
с клиентами
|
Автоматизация выписки
товарных чеков
|
|
8. Низкая осведомленность
клиентов о характере деятельности предприятия и ассортименте товара
|
Публикация списка товара и
таблиц его применимости к автомобилям в удобной форме каталога с открытым
доступом
|
1.3.9 Выбор проблемной ситуации для решения
Для решения ряда проблем, представленных в таблице 1.11, а именно 2, 4, 6
и 8, возможна реализация единой подсистемы для работы с клиентами. Такая
многопользовательская информационная подсистема сможет одновременно решать ряд
задач:
– поможет информировать клиентов о деятельности фирмы и продаваемом
товаре;
– предоставит покупателям средства оформления заказов;
– облегчит работу с товаром продавцов и клиентов посредством
внедрения формализованного каталога;
– позволит более эффективно вести учет товара, планировать закупки
с учетом спроса.
Обозначенная выше подсистема должна быть реализована в виде
многопользовательского веб-приложения с возможностью подбора товара и его
удаленного заказа. Подключение систем безналичного расчета не
предусматривается.
Веб-приложение должно быть размещено на удаленном сервере для оебспечения
постоянного доступа к нему.
Важнейшим компонентом подсистемы является наиболее удобный для клиента
специализированный каталог автомобильных комплектующих построенный таким
образом, чтобы максимально полно представить информацию о реализуемом товаре и
его применимости к автомобилям.
Кроме того на одной из страниц веб-приложения должна присутствовать
новостная лента, отражающая наиболее значимые изменения в работе, или в
ассортименте товара, а также должна быть зафиксированы контактные данные
предпринимателя.
Управление заказами не предусматривается. Вместо этого клиент может
только оставить заказ для последующей его ручной обработки сотрудником ИП.
Ввиду специфики предметной области клиент может не быть до конца уверен в своих
потребностях, а следовательно, должна быть предусмотрена возможность для
клиента выразить свои пожелания в простой словесной форме, или в виде списка
товара из каталога.
Обслуживание веб-приложения должно проводиться квалифицированным
персоналом. Приоритетной задачей является снижение затрат на запуск и
содержание подсистемы.
Проведенное выше рассмотрение предъявляемых заказчиком требований и
пожеланий позволяет перейти к этапу формулировки задач проектирования.
1.4 Формулировка задач проектирования
1.4.1 Общие сведения о проекте
ИП Ворончихина НП поручает СевКавГТУ в лице студента группы ИС-061
Ворончихина О.А. спроектировать, реализовать и внедрить информационную
подсистему управления запасами автомобильных комплектующих и автоматизации
учета заявок покупателей (в дальнейшем информационная подсистема «Заказ»).
Работы по проектированию информационной подсистемы выполняются
инициативно без оплаты на основании заказа на дипломное проектирование от
14.03.2011 г.
1.4.2 Назначение, цели создания информационной
подсистемы
Назначение информационной системы - реализация процессов продажи и учета
товара.
Основной целью разрабатываемой подсистемы является привлечение новых
клиентов за счет предоставления дополнительного сервиса и информации на новой
для предпринимателя рекламной площадке - в сети Интернет, что в дальнейшем
должно привести к увеличению прибыли в относительном эквиваленте.
Кроме того внедрение формализованного каталога должно упростить,
ускорить, а также повысить точность процесса подбора товара не только клиентам,
но и сотрудникам ИП.
Региональные конкурирующие фирмы аналогичной специализации на данное
время не имеют каталогов сопоставимого уровня и внедрение подсистемы должно
выгодно представлять предпринимателя в выгодном свете.
1.4.3 Характеристика объекта автоматизации
Автоматизации подвергается в первую очередь деятельность отдела продаж,
однако составляющая управления запасами затрагивает и выполнение задач закупки
и хранения товара.
Система является удаленной многопользовательской и будет размещена на
виртуальном сервере хостинговой компании, которая берет на себя функции
поддержания технической работоспособности серверов приложений и баз данных, а
также особенности взаимодействия с внешней средой.
1.4.4 Требования к подсистеме
Подсистема должна быть реализована в виде многопользовательского web-сайта с возможностью подбора товара
и его удаленного заказа полноценно представляющего предпринимателя в сети
Интернет.
Требования к функциональным особенностям веб-приложения изложены выше в
подразделе 1.3.9.
Требования, предъявляемые к веб-приложению в целом:
1. Глубина содержания. Объемом имеющейся информации, степень ее
детализации и ценность должны сводиться к максимуму.
2. Простота навигации. Важно обеспечить посетителям возможность без
труда двигаться от раздела к разделу, легко возвращаться назад или получить
справку.
. Стабильность информационных ресурсов. Определяется постоянством
представленной информации. Пользователи должны быть уверены, что найдут
интересующие их сведения, при любых технических и структурных реорганизациях.
. Оперативность обновления информации. Обеспечивает постоянное
поддержание сайта в актуальном состоянии. Список товара в каталоге должен
объективно отражать состояние и характеристики товара, находящегося в наличии у
предпринимателя, или временно отсутствующего.
. Доступность для пользователей. Веб-приложение должно быть
технически доступно максимальное количество времени в году при сохранении
минимальных затрат на обеспечение этого требования. Также оформление и дизайн
приложения должны способствовать облегчению восприятия информации, что повышает
ее доступность. Техническая сторона реализации приложения должна
предусматривать минимизацию трафика между клиентом и сервером, а также между
сервером приложений и баз данных на стороне сервера.
. Эстетическая привлекательность и единство дизайна всех разделов.
Естественным требованием является единообразный стиль оформления всего
веб-приложения. Цветовая схема информационной подсистемы должна быть удобна для
восприятия пользователем.
1.4.5 Состав и содержание работ по созданию подсистемы
Учитывая принадлежность подсистемы к классу многопользовательских
веб-приложений этапы разработки аналогичны этапам разработки веб-сайтов. Разработку
веб-приложения можно разделить на несколько этапов проектирования:
1. Сбор требований. По результатам проведения обследования, уточнения
требований заказчика формируется техническое задание.
2. Анализ результатов. Определяется целевая аудитория приложения,
технологии исполнения, функциональные возможности и особенности их реализации.
. Проектирование. Создание шаблона приложения: модели навигации и
логической структуры построения.
. Дизайн и верстка. Определение цветовой гаммы, изобразительных
средств, размещения элементов управления для достижения максимальной
функциональности при сохранении эстетической привлекательности веб-приложения.
. Программирование. Техническая реализация определенных ранее
функций веб-приложения.
. Наполнение информационной составляющей содержимым (контентом).
Ввиду специфики приложения контент представляет собой наиболее актуальные
новости предпринимателя и подсказки по использованию подсистемы «Заказ» (где
это необходимо). Наполнение базы данных не входит в обязанности исполнителя.
. Тестирование и отладка. Проведение тестирования сайта по
принципу «черного ящика», предварительный показ заказчику, уточнение деталей с
последующим внесением корректив в работу веб-приложения, или его дизайн.
. Сдача готового проекта. Публикация веб-приложения в сети
Интернет, сдача отчетности, подписание нормативных документов.
1.4.6 Порядок контроля приемки подсистемы
Перед вводом подсистемы в эксплуатацию она должна быть полноценно
протестирована на локальном компьютере по принципу «черного ящика», то есть
должна быть проверена каждая заявленная функциональная возможность при
допустимых наборах входных данных, а также корректное поведение веб-приложения
при любых допустимых (законных) действиях пользователя при условии
невмешательства в исходный код.
После проведения тестирования и внедрению подсистемы в эксплуатацию
заказчик подписывает акт о внедрении результатов проектирования.
1.4.7 Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу подсистемы в действие
Файлы сайта и базы данных должны быть заархивированы, после чего
скопированы в файловое хранилище хостинговой компании. После этого в описание
источников данных web-сайта должны
быть внесены коррективы, учитывающие удаленное размещение базы данных и самого
веб-приложения.
Доступ к web-сайту должен
осуществляется через купленное доменное имя, зарегистрированное с помощью
продавца доменных имен в каталоге интернет-ресурсов DNS-серверов.
Ответственному сотруднику ИП должны быть разъяснены условия поддержания
веб-приложения в работоспособном состоянии, а информационного наполнения - в
актуальном состоянии. Сотруднику, обслуживающему приложение должны быть
предоставлены средства для такого обслуживания, будь то сервисы хостинговой
компании, или самого функционального наполнения сайта (панели администратора).
1.4.8 Требования к документированию
В составе технорабочего проекта разрабатывается документация по
общесистемным решениям, организационному, техническому, информационному и
программному обеспечению, а также проектно-сметная документация.
Кроме того заказчику предоставляется полная инструкция пользователя и
администратора подсистемы.
1.4.9 Источники разработки
По результатам предпроектного обследования торговой деятельности
предпринимателя совместно с последним сформулированы общие требования к
разрабатываемому веб-приложению и функциональным возможностям, предоставляемым
им, в виде технического задания, основные положения которого изложены в п.п.
1.4.4, при этом технологии и детали реализации подсистемы оставлены на
усмотрение исполнителя в условиях минимизации затрат на разработку и
поддержание подсистемы.
Выводы
1. Проведено обследование деятельности предпринимателя и составляющих
ее процессов, функциональной структуры в разрезе решаемых задач, организации
управленческого аппарата, цели фирмы и средства их достижения, а также
техническое и программное обеспечение рабочего процесса. По результатам
обследования фирмы проведен анализ распределения обязанностей исполнителей в
проекции на решаемые функциональные задачи, а также степень участия программных
средств в деятельности фирмы. Анализ выявил недостатки в системе продаж.
2. При анализе проблемных ситуаций возникающих в работе фирмы было
решено реализовать и внедрить информационную подсистему, решающую ряд задач,
основным назначением которой будет усовершенствование деятельности отдела
продаж, заключающееся в предоставлении аппарата подбора комплектующих и системы
приема заявок от покупателей.
. В соответствии с требованиями к функциональным особенностям
требуемой информационной подсистемы и пожеланиями заказчика решено
реализовывать её в виде многопользовательского серверного приложения,
построенного на основе технологии ASP.NET.
2. Реализация информационной подсистемы «Заказ»
2.1 Обоснование выбора технологии и среды разработки информационной
подсистемы
2.1.1 Обоснование выбора технологии разработки
Заказчиком поставлена задача организовать многопользовательский доступ к
информационной подсистеме для удовлетворения потребностей любого количества
клиентов и соответствующего снижения нагрузки на сотрудников формы. Для решения
поставленной задачи решено реализовать подсистему в форме веб-приложения
функционирующего на сервере хостинговой компании.
Разрабатывать веб-приложение было решено с использованием .NET технологий, предлагаемых корпорацией
Microsoft для разработки современных серверных
приложений: ASP.NET в сочетании с ADO.NET
[2].
ASP.NET - богатейшая среда разработки и
развертывания веб-ресурсов. Выбор данной технологии обуславливается её
преимуществами перед конкурирующими технологиями:
– имеет преимущество в скорости по сравнению с другими технологиями,
основанными на скриптах;
– наличие master-страниц для задания шаблонов оформления страниц;
– расширяемая модель серверных элементов управления;
– расширенная событийная модель;
– возможность разделения визуальной части и бизнес-логики;
– возможность кэширования данных, используемых на странице;
– расширяемая модель обработки запросов.
В
свою очередь технология несвязного доступа к данным ADO.NET
является основной моделью доступа к данным <#"516549.files/image006.gif">
Рисунок 2.1 - Инфологическая модель базы данных
Абсолютно все связи между сущностями БД реализуют отношение
один-ко-многим (1:М). Спецификация связей отражена в таблице 2.1.
Таблица 2.1 - Спецификация отношений между сущностями
|
Отно-шение
|
Родительская сущность
|
Дочерняя Сущность
|
Описание отношения
|
|
1
|
Категория
|
Деталь
|
В одну категорию может
входить множество деталей
|
|
2
|
Деталь
|
Применимость
|
Каждая деталь может быть
применима к множеству автомобилей
|
|
3
|
Автомобиль
|
Применимость
|
К каждому автомобилю
применимо множество деталей
|
|
4
|
Модель кузова
|
Автомобиль
|
С одним и тем же кузовом
может выпускаться множество автомобилей
|
|
5
|
Двигатель
|
Автомобиль
|
Один и тот же двигатель
может устанавливаться на множество автомобилей
|
|
6
|
Деталь
|
Запчасти заказа
|
Одна и та же деталь может
фигурировать во множестве заказов
|
|
7
|
Заказ
|
Запчасти заказа
|
К одному заказу может
относиться множество запчастей
|
|
8
|
Произ-водитель
|
Деталь
|
Один и тот же производитель
может выпускать множество деталей
|
|
9
|
Деталь
|
Фотография детали
|
Одна и та же деталь может
быть отражена на множестве схем, рисунков
|
Во избежание возникновения аномалий вставки, удаления и модификации
данных отношения базы данных формализованы до третьей нормальной формы, что
является достаточной степенью нормализации для рассматриваемой предметной
области:
1. Все атрибуты атомарны и все строки различны. Принимая во внимание
специфику предметной области атрибут «дополнительная информация» сущности
«заказ» не может быть корректно разбит на более атомарные, поскольку не каждый
клиент сможет до такой степени формализовать и сформулировать свои потребности.
2. Все атрибуты, не входящие в состав первичного ключа,
функционально полностью зависят от первичного ключа.
. Любой неключевой атрибут функционально полностью зависит только
от первичного ключа.
2.2.3 Определение ключевых атрибутов сущностей БД
Для поддержания ссылочной целостности данных набор атрибутов сущностей
должен быть определен как первичные и внешние ключи [7].
В соответствии с инфологической моделью для сущностей БД определен
следующий набор атрибутов (таблица 2.2).
Таблица 2.2 - Ключевые атрибуты сущностей
|
Сущность
|
Тип ключа
|
Ключевые атрибуты сущности
|
|
Категория
|
Первичный
|
Код категории
|
|
Деталь
|
Первичный
|
Код детали
|
|
Внешний
|
Код производителя
|
|
|
Код категории
|
|
Применимость
|
Первичный
|
Код применимости
|
|
Внешний
|
Код деталь
|
|
|
Код автомобиля
|
|
Автомобиль
|
Первичный
|
Код автомобиля
|
|
Внешний
|
Код модели кузова
|
|
|
Код двигателя
|
|
Модель кузова
|
Первичный
|
Код модели кузова
|
|
Двигатель
|
Первичный
|
Код двигателя
|
|
Производитель
|
Первичный
|
Код производителя
|
|
Фото детали
|
Первичный
|
Код фото
|
|
Внешний
|
Код детали
|
|
Заказ
|
Первичный
|
Код заказа
|
|
Запчасти заказа
|
Составной первичный
|
Код заказа
|
|
|
Код детали
|
2.2.4 Даталогическая модель БД
Даталогическая модель базы данных образуется проецированием абстрактных
сущностей на физическую основу построения реляционной базы данных. При этом
сущности представляются в виде двумерных таблиц, а атрибуты сущностей в виде
полей таблиц.
Тогда сущность «Деталь» будет представлена в виде таблицы «spare_part» (таблица 2.3).
Таблица 2.3 - Физическое представление сущности «Деталь»
|
Поле данных
|
Тип данных
|
Допустимость неопределенных
значений
|
|
part_id
|
varchar(30)
|
Нет
|
|
catalogue_number
|
varchar(30)
|
Нет
|
|
title
|
varchar(100)
|
Нет
|
|
description
|
ntext
|
Да
|
|
manufacturer
|
varchar(10)
|
Нет
|
|
category
|
varchar(10)
|
Нет
|
|
quantity_office
|
int
|
Да
|
|
quantity_storage
|
int
|
Да
|
|
price
|
money
|
Да
|
Сущность «Категория» будет представлена в виде таблицы «categories» (таблица 2.4).
Таблица 2.4 - Физическое представление сущности «Категория»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
category_id
|
varchar(10)
|
Нет
|
|
description
|
varchar(50)
|
Нет
|
|
parent_id
|
varchar(10)
|
Да
|
Сущность «Применимость» будет представлена в виде таблицы «application» (таблица 2.5).
Таблица 2.5 - Физическое представление сущности «Применимость»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
app_id
|
bigint
|
Нет
|
|
car_id
|
varchar(20)
|
Нет
|
|
part_id
|
varchar(30)
|
Нет
|
Сущность «Автомобиль» будет представлена в виде таблицы «car» (таблица 2.6).
Таблица 2.6 - Физическое представление сущности «Автомобиль»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
car_id
|
varchar(20)
|
Нет
|
|
model
|
varchar(50)
|
Нет
|
|
engine
|
varchar(20)
|
Нет
|
Сущность «Модель кузова» будет представлена в виде таблицы «model» (таблица 2.7).
Таблица 2.7 - Физическое представление сущности «Модель кузова»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
model_id
|
varchar(50)
|
Нет
|
|
start_date
|
datetime
|
Нет
|
|
end_date
|
datetime
|
Да
|
|
photo
|
varchar(200)
|
Да
|
Сущность «Двигатель» будет представлена в виде таблицы «engine» (таблица 2.8).
Таблица 2.8 - Физическое представление сущности «Двигатель»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
engine_id
|
varchar(20)
|
Нет
|
|
short_name
|
varchar(20)
|
Да
|
|
capacity
|
float
|
Да
|
|
type
|
varchar(10)
|
Да
|
|
fuel
|
varchar(10)
|
Да
|
|
cilinders
|
int
|
Да
|
|
turbo
|
bit
|
Да
|
|
valves
|
int
|
Да
|
|
HP
|
int
|
Да
|
Сущность «Производитель» будет представлена в виде таблицы «manufacturer» (таблица 2.9).
Таблица 2.9 - Физическое представление сущности «Производитель»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
manuf_id
|
varchar(10)
|
Нет
|
|
name
|
varchar(50)
|
Нет
|
|
country
|
varchar(30)
|
Да
|
|
description
|
ntext
|
Да
|
|
logo
|
varchar(200)
|
Да
|
|
company_site
|
varchar(50)
|
Да
|
Сущность «Фото детали» будет представлена в виде таблицы «sp_photos» (таблица 2.10).
Таблица 2.10 - Физическое представление сущности «Фото детали»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
photo_id
|
varchar(10)
|
Нет
|
|
spare_part
|
varchar(30)
|
Нет
|
|
photo_path
|
varchar(200)
|
Нет
|
Сущность «Заказ» будет представлена в виде таблицы «reserve» (таблица 2.11).
Таблица 2.11 - Физическое представление сущности «Заказ»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
varchar(100)
|
Нет
|
|
reserve_date
|
datetime
|
Нет
|
|
contact_info
|
varchar(200)
|
Да
|
|
contact_phone
|
varchar(15)
|
Да
|
|
accepted
|
bit
|
Нет
|
|
sended
|
bit
|
Нет
|
Сущность «Запчасти заказа» будет представлена в виде таблицы «reserve_parts» (таблица 2.12).
Таблица 2.12 - Физическое представление сущности «Запчасти заказа»
|
Поле данныхТип
данныхДопустимость неопределенных значений
|
|
|
|
reserve_id
|
varchar(100)
|
Нет
|
|
part_id
|
varchar(30)
|
Нет
|
|
quantity
|
int
|
Нет
|
Даталогическая модель отражена в виде схемы физической ER-модели БД и
вынесена в приложение А.
2.3 Разработка программной части информационной подсистемы
2.3.1 Реализация взаимодействия между сервером приложений и сервером
баз данных
Доступ к данным из приложения осуществляется за счет использования
технологии ADO.NET, при этом база данных может быть физически удалена от
приложения и размещена на другом сервере. Подключение к базе данных описывается
в конфигурационном файле веб-приложения и описывает адрес сервера баз данных в
сети, название базы данных на сервере, имя роли, используемое для подключения и
пароль. Данные сведения предоставляются хостингом при оформлении договора.
Механизм загрузки данных реализован таким образом, чтобы минимизировать
время открытого соединения с базой данных и объем передаваемых данных. В ходе
проектирования было решено отказаться от использования стандартных классов DataSet и TableAdapter ввиду того что в большинстве случаев
на определенной странице приложения используются лишь некоторые из таблиц БД.
Соответственно нет смысла хранить на каждой странице приложения коллекции
таблиц БД. Отказавшись от такого подхода можно увеличить быстродействие и
сократить объем страниц, повысив при этом трудоемкость разработки [8].
Также для минимизации трафика между базой данных и приложением все
запросы, выполнение которых возможно на стороне базы данных выполняются на ней.
Например, запросы с использованием соединений таблиц могут быть реализованы
двумя способами:
1. Загрузка массивов данных на сторону сервера приложений и реализация
логики создания временных структур данных посредством алгоритмов приложения.
2. Отправка на сервер базы данных готовых SQL-запросов, выполнение которых будет вестись на стороне
сервера баз данных, а приложение получит в ответ набор кортежей, являющихся
результатом выполнения запроса.
В разработанном приложении во всех случаях реализуется второй подход. Его
использование возможно только при функционировании на стороне сервера баз
данных СУБД, обрабатывающей запросы приложения и неприменимо при использовании
лишь файла баз данных.
Работа с данными осуществляется с использованием следующих классов:
– SqlConnection. Используется для открытия безопасного подключения к
базе данных;
– SqlCommand. Используется для отправления управляющих инструкций
для СУБД в форме SQL-запросов;
– SqlDataReader. Используется для потокового чтения данных из базы;
– DataTable. Используется для хранения табличных структур данных на
стороне приложения.
Общее представление алгоритмов выборки и модификации данных отражено на
рисунке 2.2. Различие алгоритмов лишь в том, что для алгоритмов выборки в
приложение направляется поток данных - результатов выборки, а для управляющих
команд только подтверждение их выполнения [9].
При этом выполнения всех операций с удаленными данными осуществляется в
пределах инструкции try..catch для повышения стабильности работы
приложения и корректной обработки возникающих ошибок. К примеру временная
недоступность базы данных из-за неполадок в канале связи не вызовет крах
приложения.
Рисунок 2.2 - Обобщенный алгоритм обмена данными СУБД
Как видно из алгоритма соединение с базой данных остается открытым только
на время обмена данными, количество которых минимизирована за счет перенесения
максимума возможной обработки данных на сторону сервера БД.
При одновременной работе множества распределенных клиентов с приложением
возможны конфликтные ситуации в обработке запросов к базе данных. Благодаря
внутреннему механизму блокировок SQL Server такие
конфликты урегулируются автоматически за счет временного ограничения доступа к
модифицируемым данным.
2.3.2 Реализация клиент-серверного взаимодействия
Вся бизнес-логика приложения сосредоточена в серверном коде и «тонкий»
клиент получает готовые html-страницы
с активными элементами управления. Благодаря такому подходу веб-приложению
безразличны детали реализации клиентских приложений (браузеров) [10].
Следует также отметить, что при любых действиях клиента, вызывающих
необходимость обновить данные, страницы приложения заново формируются и
загружаются с сервера и во избежание повторного выполнения запросов к базе
данных результаты их выполнения сохраняются в переменной состояния ViewState, что влечет за собой увеличение
общего объема страниц, но снижает нагрузку на базу данных. При этом для
размещения структур данных в контейнере ViewState они должны удовлетворять требованию
- должен существовать алгоритм, позволяющий представить данные в форме
текстовой строки. Объекты классов DataTable являются сериализуемыми, то есть такой алгоритм существует.
Состояние элементов управления также сохраняется в ViewState, реализуемого в виде hidden-полей серверной формы приложения.
При выполнении пользователей каких-либо манипуляций изменяющих элементы
управления (к примеру, выбор пунктов в выпадающих меню) их состояние будет
сохранено и восстановлена при повторной загрузке страницы.
На рисунке 2.3 можно заметить заполнение контейнера ViewState данными приложения, которые не будут
заново запрошены до тех пор, пока не изменятся потребности клиента.
Рисунок 2.3 - Просмотр кода страницы приложения в браузере
2.3.3 Разработка страниц ориентированных на клиентов
Из десяти страниц приложения шесть являются клиент-ориентированными: default.aspx, catalog.aspx, order.aspx, about.aspx, manufacturer.aspx, showpdf.aspx.
Все они являются контентными для базового MasterPage и реализуют функционал приложения,
направленный на обеспечение функционирования системы приема заявок и
популяризацию фирмы.
Особенностью всех клиент-ориентированных страниц является забота о защите
приложения от непреднамеренной и преднамеренной порчи, или кражи информации. В
рамках такой политики была реализована защита от SQL-инъекций посредством замены всех запросов к базе
данных на параметризованные. Такой подход лишает механизм выполнения запросов
некоторой гибкости, но не позволит злоумышленнику внедрить вредоносный код в
запрос [11].
Разработка каталога комплектующих. Каталог призван предоставить клиентам
возможность в свободном режиме ознакомиться с полным списком товара,
предлагаемого предпринимателем. Все функциональные особенности его реализации
направлены на повышение эффективности такого ознакомления.
Ключевым управляющим элементом каталога является полнофункциональное
дерево категорий. Запасные части сгруппированы в дерево категорий, динамически
выстраиваемое в виде элемента TreeView на основе данных таблицы categories, в
которой хранятся узлы дерева
с указанием родительских узлов. Построение древа реализуется функцией
BuildTree(DataTable ToBuild), которая также обеспечивает корректное именование
узлов, отображающее пользователю понятные названия категорий, сохраняя значения
кодов категорий. Таким образом, после построения дерева таблица его образующая
удаляется при перезагрузке страницы и уже не запрашивается из базы, что
существенно сокращает последующее время загрузок страницы при активной работе,
в то время как состояние элемента управления сохраняется в переменной состояния
ViewState [12].
При работе с деревом необходимо позволить клиентам выбирать как дочерние
узлы, так и родительские, чтобы сузить или наоборот расширить область поиска.
При выборе узла приближенного к корню осуществляется рекурсивный обход всех
дочерних узлов и загружаются детали соответствующие каждой из подкатегорий до
тех пор, пока не будет заполнена вся родительская категория.
Еще одной важной задачей являлось создание активного списка товара
принадлежащего выбранной категории. Поскольку элемент управления GridView напрямую не поддерживает обработку
нажатий на строки таблицы и не вызывает отправку страницы на сервер было решено
переопределять все строки таблицы при их создании. Для этого был перегружен
обработчик события OnRowDataBound,
добавляющий на строки таблицы Java-скрипты,
исполняемые на стороне клиента. С их помощью стало возможным отслеживание
кликов по строчкам таблицы и изменение стиля при наведения курсора на ячейки
без использования специальных управляющих кнопок в дополнительных столбцах GridView. При выборе какой-либо позиции
управление передается серверу с указанием позиции. Активная таблица товаров
отражена на рисунке 2.4.
Рисунок 2.4 - Управляемая скриптами таблица товара
В функциональное назначение каталога также входит начальное создание
корзины покупателя, если она еще не создана и добавление товаров в нее. Данная
система необходима для учета заявок незарегистрированных пользователей,
поскольку приложение работает без регистрации пользователей
Разработка страницы оформления заказа. Данная страница инкапсулирует в
себе логику оформления заказов и реализует функции модификации списка товаров,
а также деталей заказа. Кроме того на нее возложены функции проверки
корректности составления заказа перед изменением статуса продвижения на
«отправленный».
Для слежения за активными корзинами пользователя страница использует
контейнер cookie браузера. Посредством этого
механизма на сторону клиентской программы внедряется информации об
идентификаторе созданного заказа, чтобы возобновлять работу с ним, если
пользователь покинул сайт, а также чтобы отслеживать новых пользователей.
Для предоставления потенциальным клиентам инструментария редактирования
товаров заказа потребовалось также переопределять набор строк табличного
элемента управления. Ячейки столбца, содержащего количество товара,
потребовалось динамически заменять во время компиляции страницы на текстовые
поля TextBox с серверными идентификаторами для
последующего обхода при изменении количества оформляемого на продажу товара.
Аналогичным способом добавлен столбец кнопок, предназначенных для удаления
товаром из корзины. Преимуществом такого подхода является полная независимость
от коллекции столбцов таблицы, подключаемой в GridView. Управляемый список товаров в
корзине представлен на рисунке 2.5.
Рисунок 2.5 - Список товара с интегрированными элементами управления
2.3.4 Разработка страниц, организующих управление содержимым сайта
Данная группа страниц предназначения для использования администратором
сайта и не обладает механизмами защиты от порчи содержимого кроме запроса прав
доступа на просмотр и редактирование контента приложения. В противовес этому
повышается гибкость выполнения запросов и появляется возможность написания
универсальных методов обработки данных.
Регулирование доступа к содержимому возложено на вложенный MasterPage, автоматически сохраняющий свое
состояние на время работы с страницами администратора. Система доступа
построена таким образом, что у веб-приложения используется одна запись
администратора, пароль к которой хранится в таблице серверных переменных и даже
подделав, или подменив запрос злоумышленнику не удастся получить пароль
администратора. Защищенный паролем контент не высылается в браузер клиента до
тех пор, пока не будет активирован [13].
Для обеспечения непрерывной работы предусмотрена переменная, регулирующая
продолжительность работы без запроса пароля в пределах сессии.
2.3.5 Разработка модуля подготовки отчетов
Модуль подготовки отчетов используется для формирования документов в
формате PDF с использованием свободно
распространяемой библиотеки iTextSharp.dll. Данное расширение предоставляет
программисту наборы структур данных, механизмов их заполнения и вывода в
документы. Необходимые описания классов, методов и структур данных находятся в
заголовочных файлах iTextSharp.text; iTextSharp.text.pdf;
iTextSharp.text.html.simpleparser.
Сам модуль базируется на странице showpdf.aspx,
однако эта страница никогда демонстрируется пользователю. Вместо этого на
страницу методом открытого GET-запроса
передается код заказа, который необходимо вывести в документ.
При загрузке страницы этот параметр анализируется, из базы данных
подгружается необходимая информация и выводится в документ в два этапа:
1. Выводится описательная информация, прилагаемая к заказу.
2. Выводится табличная часть документа, отражающая список товаров
по заказу.
После этого документ сохраняется на сервере с именем заказа и
отображается в браузере. Минусом данного подхода является то, что зная номер
заказа любой посетитель сайта может получить отчет о ходе выполнения заказа и
вообще всю информацию о нем. Для именования заказов используется метод
статичного класса Guid.NewGuid(), создающий уникальный ключ, вероятность
случайного совпадения которого ничтожна мала. Однако, подсмотрев или перехватив
во время работы чужой номер заказа злоумышленник сможет им управлять (как
владелец заказа, но не более того), что в целом снижает защищенность системы.
Особенностью использования библиотеки iTextSharp.dll является отсутствие поддержки кириллических шрифтов.
Для решения этой проблемы потребовалось импортировать на сервер в диспетчер
шрифтов готовый файл шрифта Arial
со встроенными расширениями для кириллических начертаний. После этого шрифт
определен как базовый для вывода на дисплей и в документ.
2.3.6 Верстка и дизайн страниц веб-приложения
Верстка страниц веб-приложения абсолютно везде является табличной, причем
сами таблицы являются серверными элементами <asp:Table runat=«server»> и исполняются на сервере. Такой
подход имеет как минусы так и плюсы. Из минусов - невозможность проектирования
страниц в режиме дизайнера. Вся верстка и дизайн велись в режиме редактирования
html-разметки. Однако из плюсов -
возможность обращения к макетной сетке как к северному элементу и вытекающие
отсюда последствия: событийно-управляемые изменения дизайна и компоновки.
Шаблон сайта построен таким образом, чтобы размещать весь контент на
вертикальной панели шириной 1024 пикселя, размеры которой останутся неизменными
независимо от разрешения монитора пользователя. Такой подход делает сайт плохо
масштабируемым и не позволяет использовать плюсы больших мониторов, однако
верстка остается стабильной в любой ситуации и отображение страниц всегда будет
предсказуемым.
Учитывая, что у предпринимателя нет своего фирменного стиля, было решено
использовать фирменные цвета компании Ford: оттенки синего с легким фиолетовым оттенком (основной цвет гаммы
#333366). Такая цветовая гамма должна подсказывать клиентам узкую
направленность деятельности предпринимателя и как следствие высокий
профессионализм в отрасли.
Так заголовки панелей получили в качестве фона равномерную заливку в
оттенках синего, а основные информационные поля и плоскости остались нейтрально
белыми, дабы не затруднять восприятие важной информации.
Единообразие верстки и оформления во многом обеспечивается использованием
шаблона оформления, описанного в основном MasterPage файле. В соответствии с выбранной
разметкой шаблон представляет собой шапку, панель навигации, поле для контента
и подвал (рисунок 2.6). Все страницы приложения загружаются как страницы
содержимого в описанный выше шаблон. И даже страницы управления контентом,
использующие свой собственный AdminMasterPage тоже разворачиваются во внешнем шаблоне (рисунок 2.7).
Рисунок 2.6 - Шаблон оформления страниц, определенный в MasterPage.master
Рисунок 2.7 - Шаблон оформления страниц управления контентом
Объявление стилей оформления элементов страниц преимущественно
осуществлено во внешнем .CSS
файле, что облегчает их модификацию.
Выводы
1. Определен набор сущностей с присущими им атрибутами, позволяющий
полноценно описать предметную область.
2. Проецированием абстрактных сущностей на физическую основу
организации реляционной базы данных получен нормализованный набор таблиц БД и
организован обмен информацией между веб-приложением и базой данных на основе
использования технологии ADO.NET.
. При программировании приложения использованы приемы, позволяющие
сократить объем трафика между базой данных и приложением, а также сокращающие
число запросов от клиента к базе данных.
. Разработан дизайн и макет страниц, гарантирующий корректную
верстку и размещение элементов управления независимо от настроек отображения на
стороне клиента.
. Подсистема удовлетворяет всем требованиям, предъявляемым к ней
заказчиком, и решает все задачи, предусмотренные техническим заданием на
проектирование.
3. Техническое и программное обеспечение
3.1 Общие сведения об информационной подсистеме
Наименование разработанного веб-приложения: «Информационная
подсистема учета заявок покупателей на автомобильные комплектующие для
индивидуального предпринимателя Ворончихина Н. П., г. Ставрополь».
Краткое обозначение веб-приложения в информационной
системе предпринимателя: «Заказ».
На этапе разработки подсистемы использовалось
программное обеспечение, указанное в таблице 3.1.
информационный база поток подсистема
Таблица 3.1 - Программное обеспечение, используемое в
процессе разработки информационной подсистемы
|
Класс ПО
|
Название ПО
|
Целевое использование ПО
|
|
Среда разработки
|
Microsoft Visual
Studio 2010: Express
|
– Редактор программного
кода; – компиляция; – отладка.
|
|
СУБД
|
Microsoft SQL
Server 2008: Express Edition
|
Создание и ведение баз
данных
|
|
Графический редактор
|
Adobe Photoshop
CS4
|
Подготовка элементов
графического оформления
|
|
Веб-браузер
|
Google Chrome ver. 11.0.696.71
|
Тестирование
|
|
Microsoft IE 8.0
|
|
|
Microsoft IE 6.0
|
|
|
FTP-менеджер
|
FileZilla Client
|
|
|
|
|
|
|
|