Дипломная работа

Информационный Web-ресурс "Арт Сядзiба" с использованием технологии ASP.Net

Категория:

Дипломная работа

Дисциплина:

Веб-разработка

Город:

Беларусь, Минск

Учебное заведение:

БНТУ, ФИТР

Тег:

#ДИПЛОМ

Стоимость работы:

бесплатный

Оценка: 9
Объем страниц: 83
Год сдачи: 2019
Дата публикации: 07.05.2021

Фрагменты для ознакомления

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ.. 7

1 обзор состояния вопроса.. 8

1.1 Краткий обзор аналогов. 8

1.2 Предмет разработки в контексте AS-IS и TO-BE.. 9

1.2.1 Выбор методологии и инструментария для моделирования процессов. 9

1.2.2 Модель AS – IS. 9

1.2.3 Модель TO-BE.. 11

2 ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ.. 15

3 МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.. 17

3.1 Логическое моделирование предмета разработки. 17

3.1.1 Модель вариантов использования. 17

3.1.2 Действующие лица. 17

3.1.3 Варианты использования. 17

3.1.4 Диаграмма вариантов использования. 18

3.1.5 Описание вариантов использования. 19

3.1.6 Классы анализа. 20

3.1.7 Поведение предмета разработки. 21

3.1.8 Разработка сценариев и макетов экранных форм.. 22

3.2 Физическое моделирование предмета разработки. 27

3.2.1 Компоненты предмета разработки. 27

3.2.2 Развертывание предмета разработки. 28

4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.. 29

4.1 Инструменты разработки. 29

4.2 Схема архитектуры «Модель-Вид-Контроллер». 30

4.3 Структура базы данных. 33

4.4 Реализация представлений. 35

4.5 Реализация контроллеров. 36

4.6 Реализация моделей. 38

4.6.1 Объявление классов моделей. 38

4.6.2 Объявление интерфейсов сервисов взаимодействия с базой данных. 39

4.6.3 Реализация интерфейсов. 39

4.7 Использование технологии Ajax. 40

5 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ.. 41

5.1 Руководство по развертыванию.. 41

5.2 Руководство администратора. 45

5.3 Руководство пользователя. 48

6 ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.. 52

7  ОПРЕДЕЛЕНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.. 56

7.1 Определение единовременных затрат на создание программного обеспечения. 56

7.1.1 Определение трудоемкости разработки ПП.. 56

7.1.2 Определение себестоимости создания ПП.. 58

7.1.2.1 Определение затрат на заработную плату разработчика. 58

7.1.2.2 Определение стоимости машино-часа работы ЭВМ... 59

7.1.2.3 Определение затрат на отладку программы.. 62

7.1.3 Определение оптовой и отпускной цены ПП.. 63

7.2 Определение ожидаемого прироста прибыли в результате внедрения ПП.. 64

7.2.1 Определение годовых эксплуатационных расходов при ручном решении задачи. 64

7.2.2 Определение годовых текущих затрат, связанных с эксплуатацией ПП.. 65

7.2.3 Определение ожидаемого прироста прибыли в результате внедрения ПП.. 66

8 ОХРАНА ТРУДА.. 69

8.1 Производственная санитария, техника безопасности и пожарная профилактика. 69

8.1.1 Метеоусловия. 70

5.1.2 Вентиляция и отопление. 71

8.1.3 Освещение. 71

8.1.4 Шум.. 73

8.1.5 Электробезопасность. 74

8.1.6 Излучение. 74

8.1.7 Пожарная безопасность. 75

8.2 Организация рабочего места пользователя ПЭВМ... 76

ЗАКЛЮЧЕНИЕ.. 80

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ.. 81

ПРИЛОЖЕНИЕ А.. 83

ПРИЛОЖЕНИЕ Б. 85

ПРИЛОЖЕНИЕ В.. 87

ПРИЛОЖЕНИЕ Г. 88

 

ВВЕДЕНИЕ

 

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

Целью дипломного проекта является разработка сайта культурно-просветительской площадки «Арт Сядзіба». 

Об актуальности этой задачи красноречиво говорит популярность этой организации. Идея и новое место сразу получили широкую огласку в СМИ, публикации в наиболее актуальных интернет-изданиях tut.by, open.by, budzma.org, nn.by, 34mag.net, generation.by, tuzin.fm, naviny.org и др., интервью как для государственных (радио "Столица"), так и негосударственных радиостанций ("Еврорадио", "Радио Рация"). Созданные сообщества в социальных сетях объединяют уже несколько тысяч человек. За услугами к организации постоянно обращаются разнообразные инициативы, творческие объединения, музыкальные группы, творческие личности с конкретными предложениями проведения мероприятий.

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

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

Использование таких передовых средств разработки, как Visual studio 2010, .NET Framework, ASP.NET MVC позволяет упростить и максимально ускорить процесс разработки и, что не менее важно, — дальнейшее сопровождение и внедрение конечного продукта.

В свою очередь, система управления базами данных MS SQL SERVER 2008 также является передовым инструментом и позволяет эффективно хранить и обрабатывать данные большого объема. Данный инструмент представляет собой наиболее оптимальное соотношение масштабируемости, безопасности, гарантированности сохранности данных и быстродействия при приемлемой стоимости продукта.

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

Итогом работы должно стать Web-ресурс оптимизирующий работу организации по информированию и привлечению новых организаторов и посетителей.

 

1 Обзор состояния вопроса

 

1.1 Краткий обзор аналогов

 

На сегодняшний день существует ряд ресурсов освещающих на своих страницах культурную жизнь города. На этих страницах можно найти информацию о большинстве значимых грядущих событий. К ним относятся, например, сайт общественной кампании "Будзьма беларусамі!" budzma.org. Многие информационные ресурсы, такие как euroradio.fm, relax.by, tut.by посвящают отдельные разделы анонсированию интересных событий ближайшего будущего. Существуют даже сайты, полностью посвящённые ответу на вопрос «Куду сходить? Что посмотреть?» (afisha.360.by, minchane.by, antrakt.by и др.). В контесте данной работы их можно сравнить по следующим критериям: наличие актуальной афиши, публикация отчётов, возможность подписки на рассылку новой информации о мероприятих. Результат представлен в таблице 1.1.

Таблица 1.1 – анализ существующих тематических ресурсов

 

budzma.org

euroradio.fm

minchane.by

Афиша

+

+

+

Отчёты

+

+

_

Рассылка

+ (RSS)

_

_

Таким образом видим, что ни один из сравниваемых ресурсов не реализует всех задач, поставленных в дипломном проекте. Наиболее близок сайт budzma.org, но и он не поддерживает рассылку актуальной информации по e-mail.

К тому же существенным недостатком всех рассмотренных выше аналогов является то, что они дают лишь общую информацию и не дают возможности освятить жизнь конкретной организации, такой как «Арт Сядзіба» или ДК «Ля Мора». Подобные ресурсы не позволяют связаться с конкретными местами и людьми, провести своё мероприятие, что за частую бывает критично для молодых инициатив и организаторов. В дипломном проекте предусмотренно решение этих задач для конкретной организации «Арт Сядзіба».

 

 

1.2 Предмет разработки в контексте AS-IS и TO-BE

 

1.2.1 Выбор методологии и инструментария для моделирования процессов

 

Прежде чем пытаться выбрать существующую или создать собственную информационную систему, а затем внедрить ее, необходимо проанализировать, как работает система  в настоящее время. Для этого строится функциональная модель AS-IS (как есть). Анализ этой функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов. Детализация бизнес-процессов позволяет выявить недостатки системы даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов  [1]. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных/лучших путей выполнения работы и документирования того, как система будет функционировать в будущем. 

 

 

1.2.2 Модель AS – IS

 

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

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

Данный процесс можно декомпозировать на три отдельных процесса:

  1.  предложение нового мероприятия; 
  2.  формирование афиши;
  3.  распространение информации о мероприятии.

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

Диаграмма декомпозиции данного процесса представлена на рисунке 1.2. 

 

Рисунок 1.1 - Контекстная диаграмма работы существующего процесса  (AS-IS)

 

 

Рисунок 1.2 – Диаграмма декомпозиции работы существующего процесса

На рисунке 1.3 представлена диаграмма дерева узлов для модели AS – IS.

Рисунок 1.3 – Диаграмма дерева узлов модели AS – IS.

 

Далее представим модель работы разрабатываемого Web-приложения.

 

1.2.3 Модель TO-BE

 

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

Пользователю необходимо открыть окно браузера и зайти на сайт, на котором он может ввести информацию о предлагаемом им мероприятии. Администратор, в свою очередь, обрабатывает эту информацию и, руководствуясь планом-графиком, принимает решение о размещении его в афише. Также он может разослать информацию о новом мероприятии подписавшимся пользователям сайта. По прошествии мероприятия администратор может сформировать отчёт, в который будут включены ссылки на репортажи СМИ, а также собственные комментарии о нём.

Информация будет получаться путём заполнения соответствующих полей/отмечания галочек на страницах сайта.

 

Рисунок 1.4 – Общая схема процесса работы приложения (TO-BE)

 

Рисунок 1.5 – Диаграмма декомпозиции процесса работы приложения

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

Процесс работы приложения можно разбить на четыре основных процесса:

  1. предложение нового мероприятия;
  2. формирование афиши;
  3. рассылка информации о мероприятии;
  4. создание отчёта о прошедшем мероприятии.

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

Процесс формирования афиши состоит из обработки полученной информации и размещения её в афиши. Далее рассмотрим декомпозицию этого процесса, представленную ниже на рисунке 1.6.

Рисунок 1.6 – Диаграмма декомпозиции процесса «Формирование афиши»

 

Добавление данных производится на основании информации о новом и имеющихся мероприятиях и организаторах, согласно с планом-графиком работы.

Далее рассмотрим декомпозицию процесса «Рассылка информации о мероприятиях», представленную на рисунке 1.7.

Рисунок 1.7 – Диаграмма декомпозиции процесса «Рассылка информации о мероприятиях»

 

Процесс разбивается на три основных процесса:

  1. формирование списка адресов;
  2. формирование сообщения;
  3. рассылка сообщения подписчикам;

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

На рисунке 1.8 изображена диаграмма дерева узлов модели TO-BE. 

Полученная схема TO-BE является автоматизированным вариантом модели AS-IS.

 

Рисунок 1.8 – Диаграмма  дерева узлов модели TO-BE

 

 

2 ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ

Исходя из темы проекта и обзора состояния вопроса, можно сформулировать цель проектирования – разработать информационный Web-ресурс «Арт Сядзiба».

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

  1. пользователь;
  2. администратор.

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

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

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

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

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

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

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

В качестве уровня доступа к данным необходимо использовать СУБД Microsoft SQL Server 2008 или выше, которая обеспечивает централизованное структурированное хранение всех данных системы, гарантируя их целостность и непротиворечивость, а также предоставляя множество сервисов низкого уровня для: чтения данных из хранилища, сохранения данных, изменения их структуры и прочее. На этом уровне должна быть создана база данных, которая будет хранить все данные системы. Реализация команд выборки данных, контроль целостности и непротиворечивости данных должна осуществляться с помощью соответствующих хранимых процедур, триггеров и других объектов, предоставляемых сервером.

Уровень бизнес-логики будет разворачиваться на сервере приложений и представлять собой ядро системы. На этом уровне должна быть сосредоточена большая часть бизнес-логики системы:

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

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

Система должна быть разработана под семейство операционных систем Windows в интегрированной среде разработки Microsoft Visual Studio NET версии 5.0 и выше с использованием базовой технологии разработки современных Web-приложений и сервисов ASP.NET на базе Framework 2.0 и выше и языка программирования C#, а также технологии доступа к данным ADO.NET.

 

3 МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1 Логическое моделирование предмета разработки

 

3.1.1 Модель вариантов использования

 

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

Следовательно, диаграммы вариантов использования являются необходимым средством при анализе требований, планировании и управлении интерактивной разработкой. Работа с вариантами использования является одной из важнейших  на стадии уточнения [2].

 

3.1.2 Действующие лица

 

Укажем действующие лица:

  1. пользователь – использует приложение с целью получения интересующей информации;
  2. администратор – добавляет и редактирует информационное содержимое сайта.

 

3.1.3 Варианты использования

 

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

  1. аутентификация;
  2. просмотр/редактирование предложений;
  3. рассылка уведомлений;
  4. просмотр/редактирование афиши;
  5. просмотр/редактирование отчётов;
  6. создание предложения;
  7. подписка на уведомления.

 

3.1.4 Диаграмма вариантов использования

 

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

 

Рисунок 3.1 – Модель вариантов использования

 

3.1.5 Описание вариантов использования

 

Вначале рассмотрим вариант использования «Аутентификация»:

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

Далее рассмотрим вариант использования «Рассылка уведомлений»:

  1. назначение: рассылка подписанным пользователям информации о мероприятиях;
  2. основной поток событий: данный вариант использования начинает выполняться, когда Администратор нажимает кнопку «Пригласить»;
  3. предусловия: перед выполнением данного варианта пользователь должен войти в систему как «Администратор» и открыть страницу «Афиша»;
  4. постусловия: подписавшимся пользователям будут  разосланы письма с уведомлением о выбранном и ближайших мероприятиях. 

Следующим рассмотим вариант использования «Создание предложения»:

  1. назначение: данный вариант использования служит для создания предложения мероприятия пользователем;
  2. основной поток событий: вариант начинает выполняться при заполнении информации о мероприятии и нажатии кнопки «Сохранить»;
  3. альтернативный поток: введены некорректные данные, пользователь нажал «Отмена»;
  4. предусловия: должна быть открыта страница создания предложения;
  5. постусловия: добавление информации о предложенном мероприятии в базу. 

Затем рассмотрим вариант использования «Просмотр/редактирование предложений»:

  1. назначение: данный вариант использования служит для принятия либо отклонения предложений мероприятий;
  2. основной поток событий: данный вариант использования начинает выполняться, когда Администратор редактирует информацию о предложенном мероприятии и нажимает «Принять»; 
  3. альтернативный поток: введены некорректные данные, Администратор нажал «Отмена»;
  4. предусловия: перед выполнением данного варианта должна быть открыта страница предложения;
  5. постусловия: мероприятие добавлено в афишу.

3.1.6 Классы анализа

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

 

Таблица 3.1 – Глоссарий предметной области

Термин

Значение

ПользовательЛичность, которая пользуется системой в целях получения информации
АдминистраторЛичность, которая регулирует информацию на сайте
МероприятияСписок всех мероприятий
ОрганизаторыСписок всех организаторов мероприятий
ОтчётыСписок отчётов по мероприятиям
ПредложенияСписок предлагаемых пользователями мероприятий
ПодписчикиСписок подписавшихся пользователей
Форма аутентификацииФорма с полями для ввода логина и пароля
Формы создания/редактирования информацииФормы с полями для ввода данных о сущности
Результирующие формыФорма с информацией о результате выполнения операции 

 

Классы анализа сгруппируются по типам: граничные, управляющие, сущности. Согласно приведенному выше глоссарию, к первому типу можно отнести перечисленные формы; ко второму типу - личности; к третьему типу – используемые в каталогах сущности.

 

3.1.7 Поведение предмета разработки

Поведение системы, если ее трактовать как объект класса, может быть представлено в виде диаграммы деятельности. 

На ней рисунках 3.2-3.3 представлены диаграммы деятельности для администратора и пользователя соответственно. 

Рисунок 3.2 – Диаграмма деятельности «Администратор»
Рисунок 3.3 – Диаграмма деятельности «Пользователь»

 

3.1.8 Разработка сценариев и макетов экранных форм

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

Вначале рассмотрим прецедент «Аутентификация».

Диаграмма последовательности к прецеденту «Аутентификация» представлена на рисунке 3.4.

Рисунок 3.4 – Диаграмма последовательности к прецеденту «Аутентификация»

 

Диаграмма коопераций к этому прецеденту представлена на рисунке 3.5.

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

Рисунок 3.5 – Диаграмма коопераций к прецеденту «Аутентификация»

На основе приведенных выше диаграмм построим экранную форму страницы (рисунок 3.6).

 

Рисунок 3.6 – Экранная форма к прецеденту «Аутентификация»

 

Далее рассмотрим прецедент «Обработка предложения».

Диаграмма последовательности к прецеденту «Обработка предложения» представлена на рисунке 3.7. На нем отображена диаграмма последовательности действий, которая выполняется администратором при обработке поступивших предложений мероприятий.

Рисунок 3.7 – Диаграмма последовательности к прецеденту «Обработка предложений»

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

Диаграмма коопераций к этому прецеденту представлена на рисунке 3.8.

 

Рисунок 3.8 – Диаграмма коопераций к прецеденту «Обработка предложений»

 

На основе приведенных выше диаграмм построим экранную форму страницы (рисунок 3.9).

Рисунок 3.9 – Экранная форма к прецеденту «Обработка предложений»

 

 

3.1.9 Статическая модель предмета разработки

 

Статическая модель интерфейса приложения представлена на рисунке 3.10.

Пользователь производит действия через окно браузера. Страница разделена на шапку (Header), основную часть (Work panel) и подвал (Footer).

Рисунок 3.10 - Статическая модель интерфейса приложения

 

На рисунке 3.11 представлена диаграмма классов серверной части приложения

Рисунок 3.11 – Диаграмма классов серверной части приложения

 

На рисунке 3.11 стрелками обозначены отношения классов. Стрелка идёт от класса-наследника к базовому классу. 

Классы клиентской части представлены на рисунке 3.12.

 

Рисунок 3.12 – Диаграмма классов клиентской части приложения

 

Основная диаграмма классов в виде набора пакетов на рисунке 3.13.

 

Рисунок 3.13 - Основная диаграмма классов в виде набора пакетов

 

 

3.2 Физическое моделирование предмета разработки

 

3.2.1 Компоненты предмета разработки

 

Диаграммы компонентов  приведены ниже (рисунки 3.14 и 3.15).

- клиентская часть проекта (рисунок 3.14);

 

Рисунок 3.14 – Диаграмма компонентов клиентской части проекта

 

- серверная часть приложения (рисунок 3.15);

 

 

Рисунок 3.15 – Диаграмма компонентов серверной части проекта

 

 

3.2.2 Развертывание предмета разработки

 

Диаграмма развертывания приведена ниже (рисунок 3.16).

 

 

Рисунок 3.16 – Диаграмма развертывания проекта

 

4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

4.1 Инструменты разработки

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

Платформа ASP.NET MVC представляет собой альтернативу схеме веб-форм ASP.NET при создании веб-приложений. Платформа ASP.NET MVC является легковесной платформой отображения с широкими возможностями тестирования и, подобно приложениям на основе веб-форм, интегрирована с существующими функциями ASP.NET. Платформа MVC определяется в сборке System.Web.Mvc [4].

MicrosoftVisualStudio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии WindowsForms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых MicrosoftWindows, WindowsMobile, Windows CE, .NET Framework, .NET CompactFramework и MicrosoftSilverlight.

VisualStudio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. VisualStudio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например,Subversion и VisualSourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода напредметно-ориентированных языках программирования или инструментов для прочих аспектов цикла разработки программного обеспечения(например, клиент TeamExplorer для работы с TeamFoundationServer) [5].

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка [6].

HTML (от англ. HyperTextMarkupLanguage — «язык разметки гипертекста») — стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц создаются при помощи языка HTML (или XHTML). Язык HTML интерпретируется браузерами и отображается в виде документа в удобной для человека форме [7].

CSS (англ. CascadingStyleSheets — каскадные таблицы стилей) — формальный язык описания внешнего вида документа, написанного с использованием языка разметки.

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

 

 

4.2 Схема архитектуры «Модель-Вид-Контроллер»

MVC представляет собой стандартный шаблон разработки. Некоторые типы веб-приложений имеют преимущества при создании на платформе MVC. Для других может быть целесообразно использование традиционной схемы приложения ASP.NET, основанной на веб-формах и обратной передаче. В некоторых случаях возможно сочетание двух подходов: применение одной схемы не исключает использования другой. 

В состав платформы MVC входят следующие компоненты:

1)      Модели. Объекты моделей являются частями приложения, реализующими логику для домена данных приложения. Объекты моделей обычно получают и сохраняют состояние модели в базе данных.

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

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

В приложении MVC представления только отображают данные, а контроллер обрабатывает вводимые данные и отвечает на действия пользователя. 

Шаблон MVC позволяет создавать приложения, различные аспекты которых (логика ввода, бизнес-логика и логика интерфейса) разделены, но достаточно тесно взаимодействуют друг с другом. Эта схема указывает расположение каждого вида логики в приложении. Пользовательский интерфейс располагается в представлении. Логика ввода располагается в контроллере. Бизнес-логика находится в модели. Это разделение позволяет работать со сложными структурами при создании приложения, так как обеспечивает одновременную реализацию только одного аспекта. Связь между основными компонентами приложения MVC также облегчает параллельную разработку. 

Графическое изображение MVC приведено на рисунке 4.1.

 

Рисунок 4.1 – Графическое изображение MVC

Следует внимательно продумать вопрос о создании веб-приложения на основе платформы ASP.NET MVC или на основе модели веб-форм ASP.NET. Платформа MVC не заменяет собой модель веб-форм. Обе модели можно использовать для веб-приложений. (при наличии существующих приложений на основе веб-форм они будут продолжать работу в нормальном режиме). 

Платформа ASP.NET MVC имеет следующие преимущества:

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

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

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

4)      она обеспечивает расширенную поддержку разработки на основе тестирования;

5)      она хорошо подходит для веб-приложений, поддерживаемых крупными коллективами разработчиков, а также веб-разработчикам, которым необходим высокий уровень контроля над поведением приложения. 

Платформа ASP.NET MVC предоставляет следующие возможности:

1)      Разделение задач приложения (логика ввода, бизнес-логика и логика пользовательского интерфейса), широкое возможности тестирования и разработки на основе тестирования. Все основные контракты платформы MVC основаны на интерфейсе и подлежат тестированию с помощью макетов объекта, которые имитируют поведение реальных объектов приложения. Приложение можно подвергать модульному тестированию без запуска контроллеров в процессе ASP.NET, что ускоряет тестирование и делает его более гибким. Для тестирования возможно использование любой платформы модульного тестирования, совместимой с .NET Framework.

2)      Расширяемая и дополняемая платформа. Компоненты платформы ASP.NET MVC можно легко заменить или настроить. Разработчик может подключать собственный механизм представлений, политику маршрутизации URL-адресов, сериализацию параметров методов действий и другие компоненты. Платформа ASP.NET MVC также поддерживает использование моделей контейнера внедрения зависимости (DI) и инверсии элемента управления (IOC). Модель внедрения зависимости позволяет внедрять объекты в класс, а не ожидать создания объекта самим классом. Модель инверсии элемента управления указывает на то, что если один объект требует другой объект, то первые объекты должны получить второй объект из внешнего источника (например, из файла конфигурации). Это облегчает тестирование.

3)      Расширенная поддержка маршрутизации ASP.NET. Этот мощный компонент сопоставления URL-адресов позволяет создавать приложения с понятными URL-адресами, которые можно использовать в поиске. URL-адреса не должны содержать расширения имен файлов и предназначены для поддержки шаблонов именования URL-адресов, обеспечивающих адресацию, оптимизированную для поисковых систем (SEO) и для передачи репрезентативного состояния (REST).

4)      Поддержка использования разметки в существующих файлах страниц ASP.NET (ASPX), элементов управления (ASCX) и главных страниц (MASTER) как шаблонов представлений. Вместе с платформой ASP.NET MVC можно использовать существующие функции ASP.NET, например вложенные главные страницы, встроенные выражения (<%= %>), декларативные серверные элементы управления, шаблоны, привязку данных, локализацию и т. д.

5)      Поддержка существующих функций ASP.NET. ASP.NET MVC позволяет использовать такие функции, как проверка подлинности с помощью форм и Windows, проверка подлинности по URL-адресу, членство и роли, кэширование вывода и данных, управление состоянием сеанса и профиля, наблюдение за работоспособностью, система конфигурации и архитектура поставщика.

 

 

4.3 Структура базы данных

Схема структуры таблиц базы данных представлена в приложении.

Рассмотрим каждую из таблиц в отдельности. Таблица мероприятий представлена на рисунке 4.2.

Рисунок 4.2 – Таблица мероприятий

Таблица информации об организаторах представлена на рисунке 4.3.

 

Рисунок 4.3 – Таблица информации об организаторах

 

Таблица предложенных мероприятий представлена на рисунке 4.4.

Рисунок 4.4 – Таблица предложенных мероприятий

 

Таблица отчётов представлена на рисунке 4.5.

Рисунок 4.5 – Таблица отчётов

 

Таблица подписчиков представлена на рисунке 4.6

 

Рисунок 4.6 – Таблица подписчиков

 

4.4 Реализация представлений

 

Все реализованные представления можно разделить на: частичные и полные, типизированные и нетипизированные.

Полные представления представляют собой обычную веб-страницу (расширение .aspx), использующей некоторый шаблон. В данном приложении для всех страниц используется один общий шаблон Site.Master, который содержит в себе определение стандартных элементов html-документа (head, body и др). Полные представления просто встраивают свой html-код в определенные контейнера шаблона.

Частичные представления представляют собой пользовательские веб-контролы (элементы управления). Они могут быть вставлены в любой контейнер на родительской странице. В данном приложении частичные представления используются для отображения форм создания и редактирования с валидацией их полей посредством ajax-запроса (см. п. 3.4). В отличие от полных представлений, частичные представления не используют шаблон Site.Master.

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

Нетипизированные представления к модели не привязываются и соответственно лишены возможности прямого обращения к ее данным.

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

Для представлений в реализованном проекте предусмотрены четыре каталога в базовом каталоге Views. Сортировка выполнена согласно их назначению. Так в каталоге Account находятся представления связанные с механизмами аутентификации. Это следующие представления:

  1. ChangePassword – служит для смены пароля;
  2. ChangePasswordSuccess – информирует об успешной смене пароля;
  3. LogOn – страница авторизации;
  4. Register – страница регистрации.

В каталоге Admin находятся представления для работы администратора. Среди них:

  1. Index – главная страница администраторской части сайта;
  2. Accept – для обработки информации о предложенном мероприятии;
  3. Propose – для просмотра всех предложений;
  4. Reports – для просмотра отчётов;
  5. CreateReports – для создания нового отчёта;
  6. Organizator – для просмотра списка организаторов;
  7. Subscribe – для рассылки информации подписчикам.

В каталоге Home расположены представления для работы авторизованного пользователя. Это, например:

  1. Index – главная страница пользовательской части сайта;
  2. About – информация об организации;
  3. CreatePropose – создание нового предложения;
  4. Details – просмотр деталей о мероприятии;
  5. Subscribe – для подписки на рассылку.

В каталоге Shared размещается используемый общий шаблон Site.Master.

 

 

4.5 Реализация контроллеров 

 

Контроллер представляет собой класс, унаследованный от стандартного класса MVC Controller. 

Для каждого разработанного представления в соответствующем контроллере добавлен метод, в котором происходит формирование модели для представления (при необходимости) и собственно самого представления.

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

         http://{имя сайта}/{имя контроллера}/{имя метода}.

При этом, есть возможность сразу передать методы необходимые параметры, просто указав их в формате get-запроса:

         ?{имя параметра}={значение}&{имя параметра}={значение}

В приложении реализованы три контроллера. Диаграмма контроллера HomeController, предназначенного для работы в роли пользователя представлена на рис. 4.7.

Рисунок 4.7 – Диаграмма контроллера HomeController

Диаграмма контроллера для работы в роли администратора (AdminController) представлена на рисунке 4.8.

Рисунок 4.8 – Диаграмма контроллера AdminController

Диаграмма класса AccountController показана на рисунке 4.9.

Рисунок 4.9 – Диаграмма контроллера AccountController.

 

 

4.6 Реализация моделей

Реализация моделей была разделена на следующие составные части:

  1. объявление классов моделей;
  2. объявление интерфейсов сервисов взаимодействия с базой данных;
  3. реализация интерфейсов.

 

4.6.1 Объявление классов моделей

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

 

4.6.2 Объявление интерфейсов сервисов взаимодействия с базой данных

Интерфейс взаимодействия с БД представляет собой набор методов, необходимых для корректной работы.

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

 

 

4.6.3 Реализация интерфейсов

Реализация интерфейсов представляет собой класс-сервис, который производит непосредственное взаимодействие с базой данных, выполняет все действия, подразумеваемые в семантике объявления метода в интерфейсе.

Для взаимодействия с базой данных была использована платформа ADO.NET Entity Framework. 

Платформа Entity Framework позволяет разработчикам создавать приложения для доступа к данным, работающие с концептуальной моделью приложения, а не напрямую с реляционной схемой хранения. Цель состоит в уменьшении объема кода и снижении затрат на сопровождение приложений, ориентированных на обработку данных. Приложения Entity Framework предоставляют следующие преимущества: 

  1. приложения могут работать концептуальной моделью в терминах предметной области — в том числе с наследуемыми типами, сложными элементами и связями;
  2. приложения освобождаются от жестких зависимостей от конкретного ядра СУБД или схемы хранения;
  3. сопоставления между концептуальной моделью и схемой, специфичной для конкретного хранилища, могут меняться без изменения кода приложения;
  4. разработчики имеют возможность работать с согласованной моделью объектов приложения, которая может быть сопоставлена с различными схемами хранения, которые, возможно, реализованы в различных системах управления данными;
  5. несколько концептуальных моделей могут быть сопоставлены с единой схемой хранения;
  6. поддержка запросов LINQ обеспечивает проверку синтаксиса во время компиляции для запросов к концептуальной модели.

 

4.7 Использование технологии Ajax

AJAX — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате, при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся более быстрыми и удобными [9].

В данном проекте технология AJAX используется, например, на представлениях для создания и редактирования мероприятий для валидации их полей.

 <% Html.EnableClientValidation(); %> 

Правила валидация заданы в классе модели. 

 

5 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Данный раздел разделен на 3 части:

  1. руководство по развертыванию системы;
  2. руководство по использованию системы в качестве администратора;
  3. руководство по использованию в качестве пользователя.

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

Во второй части описана работа с системой с точки зрения администратора.

В третьей части описана работа с системой с точки зрения пользователя.

 

5.1 Руководство по развертыванию

Для развертывания сайта необходима программа Internet Information Service версии не ниже 6.0, а также одна из операционных систем семейства Windows, версии старше XP Professional.

Также должен быть установлен .NET Framework версии 4.0.

Для установки IIS необходимо сначала разрешить службы IIS. Для этого надо зайти в Панель управления => Пограммы => Включение или Отключение компонентов Windows и в окне поставить галочку напротив Службы IIS. Также можно раскрыть список Службы IIS и указать, какие конкретно службы должны быть установлены. Вид этого окна приведен на рисунке 5.1.

Рисунок 5.1 – Окно компонентыWindows

После выбора необходимых пунктов и нажатия клавиши OK система установит IIS и необходимые службы.

Если IIS был установлен после .NETFramework-a, необходимо воспользоваться утилитой aspnet_regiis для регистрации 4 версии фреймворка в IIS. Результат выполнения данной утилиты приведен на рисунке 5.2.

Рисунок 5.2 - Использование утилиты aspnet_regiis для регистрации .NET 4.0 в IIS

После того, как все необходимое ПО было установлено, следует запустить IIS. Сделать это можно, набрав в строке Выполнить команду IIS, или зайдя в Панель Управления, и выбрать следующие пункты:

Если используется Windows Vista или Windows Server 2008, выберите Система и ее обслуживание и затем выберите Администрирование.

Если используется Windows 7 или Windows Server 2008 R2, выберите Система и безопасность и затем выберите Администрирование.

В окне Администрирование дважды щелкните пункт Диспетчер служб IIS.

Далее в окне Подключения выбрать Папку «Сайты», нажать правой кнопкой и выбрать «Добавить сайт» [14]. Указать путь к проекту WebApplication, указать адрес и порт, на который будут обращаться к сайту. Последовательность действий при добавлении сайта приведена на рисунках 5.3 и 5.4.

Рисунок 5.3 -  Выбор пункта Добавить сайт
Рисунок 5.4 - Добавление сайта

При добавлении сайта он автоматически запускается IIS как скомпилированный под .NETv2.0. Если ваш проект был скомпилирован для более новой версии .NETFramework, необходимо в IIS открыть вкладку Пулы приложений и установить для вашего сайта необходимый фреймворк. Последовательность действий приведена на рисунках 5.5 и 5.6.

Рисунок 5.5 - Вкладка «Пулы приложений» в IIS
Рисунок 5.6 - Установка версии .NET для сайта в IIS

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

Рисунок 5.7 – Запуск сайта после развертывания

 

5.2 Руководство администратора

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

Рисунок 5.8 – Форма аутентификации

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

 

Рисунок 5.9 – Главное окно администратора

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

 

Рисунок 5.10 – Создание отчёта

 

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

 

Рисунок 5.11 – Форма предложений

При нажатии ссылки «Информация» администратор увидит контактную информацию администратора. При нажатии ссылки «Принять» данные о мероприятии добавляются в афишу. Ссылка «Удалить» ведёт к удалению предложения из базы без добавления в афишу.

На странице «Отчёты» можно просмотреть созданные отчёты. Администратору также доступны возможности редактирования и удаления отчётов (рис. 5.12).

Рисунок 5.12 – Страница «Отчёты» для администратора

 

Для выхода из системы необходимо нажать ссылку «Выйти» в шапке окна.

 

 

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

 

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

 

 

Рисунок 5.13 – Главное окно пользователя

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

 

 

Рисунок 5.14 – Окно «Детали»

 

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

 

 

Рисунок 5.15 – Результат подписки

 

Перейдя по ссылке «Предложить мероприятие» пользователь сможет ввести информацию о мероприятии, которое в последствии администратор сможет добавить в афишу. Окно для создания предложения представлено на рисунке 5.16.

 

 

Рисунок 5.16 – Окно создания предложения

 

На странице «Отчёты» пользователь может просмотреть публикации о прошедших мероприятиях в СМИ, а также комментарии организаторов. Вид страницы «Отчёты» представлено на рисунке 5.17.

 

 

Рисунок 5.17 – Страница «Отчёты»

На странице «О нас» пользователь может получить общую информацию об организации. Вид этой страницы представлен на рисунке 5.18.

 

 

Рисунок 5.18 – Страница «О нас»

 

Для выхода из системы необходимо нажать ссылку «Выйти».

 

6 ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Тестирование программного обеспечения в рамках дипломного проекта ограничено проведением функционального тестирования (критическое и углубленное).  Критическое тестирование – это процесс поиска ошибок в программе при стандартной ее работе.  Углубленное (расширенное) тестирование – это процесс поиска ошибок в программе в нестандартных, непредвиденных ситуациях. В качестве тестируемого компонента выбран  весь проект. Цель тестирования – убедиться, что вся функциональность программного обеспечения проекта работает правильно.

Для тестирования на различных платформах браузеров была разработана матрица конфигураций (таблица 6.1).

Таблица 6.1 – Матрица конфигураций

 

IE 6.0

IE 7.0

FireFox 3

Opera 9.64

Windows 7

+

+

+

+

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

 

Таблица 6.2 – Тестовые случаи для критического тестирования

Название

модуля/экрана

Описание тестового случая

Ожидаемые результаты

Тестовый случай пройден?

Да/Нет

Комментарии

1

Index.aspx

1. Запустить браузер

 2. Ввести в адресной строке адрес приложения

и нажать ввод

Загрузится первая страница приложения

да

 

2

Index.aspx

1. На главной странице после авторизации перейти по ссылке «Подписаться»

Переход на страницу с уведомлением. Текст ссылки изменится

да

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Продолжение таблицы 6.2

 

 

 

 

 

 

Название

модуля/экрана

Описание тестового случая

Ожидаемые результаты

Тестовый случай пройден?

Да/Нет

Комментарии

3

Index.aspx

1. Перейти по ссылке «Подробно».

Переход на страницу с деталями выбранного мероприятия

да

 

LogOn.aspx

1. На странице аутентификации ввести корректный логин и пароль.

2. Нажать кнопку «Войти»

Переход на главную страницу приложения

да

 

5

Index.aspx

1. Войти в приложение в роли администратора.

2. Под прошедшим мероприятием перейти по ссылке «Создать отчёт»

Загрузится страница добавления отчёта

Да

 

6

Propose.aspx

1. Войти в приложение в роли администратора

2. Перейти на страницу предложений

3. Нажать кнопку «Принять»

Данные о мероприятии добавлены в афишу

да

 

7

Propose.aspx

1. Войти в приложение в роли администратора

2. Перейти на страницу предложений

3. Нажать кнопку «Удалить»

Информация удалена без добавления в афишу

Да

 

8

Reports.aspx

1. Войти в приложение в роли администратора

2. Перейти на страницу «Отчёты»

3. Нажать ссылку «Удалить»

Отчёт удалён

Да

 

 

В проекте есть поля для ввода данных. Граничные и эквивалентные значения для этих полей однотипны. Таблица некоторых из них представлена ниже в таблице 6.3.

Таблица 6.3 – Перечень граничных и эквивалентных значений

 

Название поля

Формат данных 

Перечень граничных значений

Перечень эквивалентных значений

Логин[3,50] символом английского алфавита или цифр“вау”, “aetatrerteertwqw122…”(50 символов)“Dmitry”
Пароль[3,50] символом английского алфавита или цифр“вау”, “32k4liu3g2i3ug23d…”(50 символов)“12345”
Описание[4, 50] символов«Клип», «Презентация по..» (50 символов)«Лекция»
СтоимостьЦелое число0, 3276710000

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

Таблица 6.4 – Тестовые случаи для углубленного тестирования

Название

модуля/экрана

Описание тестового случая

Ожидаемые результаты

Тестовый случай пройден?

Да/Нет

Комментарии

1

LoginPage.aspx

1. Ввести данные несуществующего пользователя

Появится сообщение об ошибке

да

 

2

Create.aspx

1. Войти в приложение в роли администратора

2. Открыть страницу добавления мероприятия

3. Ввести данные и нажать «Назад»

Данные не сохранились

да

 

3

CreateReports.aspx

1. Войти в приложение в роли администратора

2. Открыть страницу добавления отчёта

3. Ввести некорректные данные

Получено уведомление об ошибке ввода

да

 

 

Продолжение таблицы 6.4

 

Название

модуля/экрана

Описание тестового случая

Ожидаемые результаты

Тестовый случай пройден?

Да/Нет

Комментарии

4

 CreatePropose.aspx

1. Войти в приложение в роли пользователя

2. Открыть страницу создания предложения

3. Не заполнить поле «Время»

4. Нажать «Предложить»

 

Получено сообщение о том, что поле обязательно для заполнения

да

 

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

Таблица 6.5 – Форма для перечня аппаратных средств

Роль

Аппаратная конфигурация

Программная конфигурация

1

web-сервер, рабочая станция

AMD E-300, 2048 Mb

ОС – Microsoft Windows 7, IIS 7, .Net Famework 4.0

Тестирование программного обеспечения позволило своевременно выявить ошибки и мелкие недочеты, избавиться от логических ошибок в программе, незаметных с первого взгляда и не распознаваемых компилятором. Оно позволило проверить соответствие разрабатываемого программного обеспечения поставленным задачам и предъявляемым требованиям.

Тестирование проводилось по мере разработки программного продукта. Все ошибки устранялись по мере их появления и обнаружения. 

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

Тестирование показало соответствие  программы заявленным в  постановке задачи требованиям. Все тестовые случаи пройдены без выявления проблем. Разработанное приложение может успешно применяться для решения поставленной задачи.

 

7  ОПРЕДЕЛЕНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

 

7.1 Определение единовременных затрат на создание программного обеспечения

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

Таблица 7.1 - Технико-экономические показатели проекта

Разработанное программное обеспечение к дипломному проекту на тему «Информационный Web-ресурс “Арт Сядзiба” с использованием технологии ASP.Net» обеспечивает получение годового экономического эффекта в сумме 12 246 541 руб. при отпускной цене программы 15 925 024 руб. Проект обеспечивает возврат инвестиций за 0,9 года. Продукт является рентабельным и конкурентоспособным.

 

8 ОХРАНА ТРУДА

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

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

 

 

8.1 Производственная санитария, техника безопасности и пожарная профилактика

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

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

К основным помещениям предъявляются особые требования. Площадь машинного зала соответствует площади, необходимой по техническим условиям для данного типа ЭВМ: площадь на одно рабочее место с ВДТ, ЭВМ и ПЭВМ для взрослых пользователей составляет не менее 6,0 м2, а объем не менее 20,0 м3 (СанПиН №9-131 РБ 2000) [12].

 

 

8.1.1 Метеоусловия

Самочувствие и работоспособность человека зависят от метеорологических условий производственной среды. ГОСТ 12.1.005-88, п. 1.4 [13], СанПиН № 9-80 РБ 98 [14] и  СанПиН 9-131 РБ 2000 [12] устанавливают следующие требования к микроклиматическим условиям, приведённые в таблице 8.1.

Таблица 8.1 - Параметры воздушной среды на рабочем месте

Период года

Категория работ

Температура воздуха, °С

Относительная влажность воздуха, %

Скорость движения воздуха, м/с,

не более

Холодный

легкая-1а

22-24

40-60

0,1

 

 

легкая-16

21-23

40-60

0,1

Теплый

легкая-1а

23-25

40-60

0,1

 

 

легкая-16

22-24

40-60

0,2

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

Работа с компьютером относится к категории 1а (к данной категории работ относят работы, производимые сидя и сопровождающиеся незначительным физическим напряжением, при которых расход энергии составляет до 120 ккал/ч, т.е. до 139 Вт).

Согласно ГОСТ 12.1.005-88 и СанПиН9-80 РБ 98 интенсивность теплового излучения работающих от нагретых поверхностей технологического оборудования, осветительных приборов, инсоляции на постоянных местах не превышает 35 Вт/м2 при облучении 50% поверхности тела и более [14].

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

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

 

 

8.1.2 Вентиляция и отопление

Воздух рабочей зоны производственного помещения должен соответствовать санитарно-гигиеническим требованиям по параметрам микроклимата, содержанию вредных веществ (газа, пара, аэрозоли) и частиц пыли, приведенным в ГОСТе 12.1.005-88 СББТ и Санитарных нормах, правилах и гигиенических нормативах «Перечень регламентированных в воздухе рабочей зоны вредных веществ» [15].

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

Параметры микроклимата поддерживаются в указанных пределах в холодное время за счет системы водяного отопления с нагревом воды до 100°С, в теплый - за счет кондиционирования, с параметрами отвечающими требованиям СНБ 4.02.01-03 [16].

 

 

8.1.3 Освещение

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

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

Согласно ТКП 45 - 2.04 - 153 - 2009 помещения для работы с видеотерминалами относят к I группе по задачам зрительной работы. Нормированный уровень освещенности для работы с ЭВМ - 400 лк, КЕО - 4% [17].

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

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

В случае если экран вычислительной техники обращен к оконному проему, предусматриваются специальные экранирующие устройства. Окна рекомендуется снабжать  светорассеивающими  шторами (р = 0,5 — 0,7), регулируемыми жалюзи или солнцезащитной пленкой с металлическим покрытием.

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

Для искусственного освещения помещений вычислительных центров предусмотрены люминесцентные лампы белого света (ЛБ) и темно-белого цвета (ЛТБ).

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

 

 

8.1.4 Шум

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

Основными источниками шума в помещениях, оборудованных ЭВМ, являются принтеры, множительная техника и оборудование для кондиционирования воздуха, в самих ЭВМ — вентиляторы систем охлаждения и трансформаторы.

Нормированные уровни шума согласно ГОСТ 12.1.003-83, СанПиН №131 РБ 2000 и санитарным нормам, правилам и гигиеническим нормативам Министерства здравоохранения Республики Беларусь. Нормы уровня шума приведены в таблице 8.2 и обеспечиваются путем использования малошумного оборудования, применением звукопоглощающих материалов для облицовки помещений, а также различных звукопоглощающих устройств (перегородки, кожухи и т. д.) [19].

 

Таблица 8.2 – Нормированные уровни шума

Категория нормы

шума

Уровни звукового давления, дБ, в октавных полосах

со среднегеометрическими частотами, Гц

Уровни звука и эквивалентные уровни звука, дБА

31.5

63

125

250

500

1000

2000

4000

8000

 

I

86

71

61

54

49

45

42

40

38

50

II

93

79

70

63

58

55

52

50

49

60

III

96

83

74

68

63

60

57

55

54

65

IV

103

91

83

77

73

70

68

66

64

75

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

 

 

8.1.5 Электробезопасность

Помещение вычислительного центра по степени опасности поражения электрическим током относится к помещениям без повышенной опасности.

Основные меры защиты от поражения током: 

  1. изоляция и недоступность токоведущих частей; 
  2. защитное заземление (R3 = 4 Ом ГОСТ 12.1.030 – 81 [23]). 

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

 

 

8.1.6 Излучение

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

Интенсивность инфракрасного и видимого излучения от экрана видеомонитора не превышает 0,1 Вт/м2 в видимом (400-760 нм) диапазоне, 0,05 Вт/м2 в ближнем ИК диапазоне (760-1050 нм), 4 Вт/м2 в дальнем (свыше 1050 нм) ИК диапазоне.

Интенсивность ультрафиолетового излучения от экрана видеомонитора не превышает 0,0001 Вт/м2 в диапазоне 280-315 нм и 0,1 Вт/м2 в диапазоне 315-400 нм. Излучение в диапазоне 200-280 нм не допускается [20].

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

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

Таблица 8.3 – Допустимые значения параметров неионизирующих электромагнитных излучений

Наименование параметра

Допустимые значения

Напряженность электромагнитного поля.  

Электрическая составляющая, не более:

         диапазон частот 5 Гц - 2 кГц

         диапазон частот 2 - 400кГц

 

 

25,0 В/м

2,5 В/м

Плотность магнитного потока, не более:       

         диапазон частот 5 Гц - 2 кГц 

         диапазон частот 2 - 400 кГц

 

250  нТл

25 нТл

Напряженность электростатического поля, не более

15кВ/м

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

 

 

8.1.7 Пожарная безопасность

По взрывопожарной и пожарной опасности помещения и здания относятся по ТКП 474-2013 к категории Д в зависимости от выполняемых в них технологических процессов, свойств применяемых веществ и материалов, а также условиями их обработки [24]. Здания для ВЦ и части зданий другого назначения, в которых предусмотрено размещение ЭВМ, относятся к 2 степени огнестойкости согласно ТКП 45-2.02-142-2011. 

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

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

Для ликвидации пожаров в начальной стадии применяются первичные средства пожаротушения: внутренние пожарные водопроводы, огнетушители типа ОВП-10, ОУ-2, асбестовые одеяла и др.

В здании ВЦ пожарные краны устанавливают в коридорах, на площадках лестничных клеток, у входа, т.е. в доступных и защитных местах. На каждые 100 квадратных метра пола производственных помещений требуется 1 -2 огнетушителя [25].

Эвакуация сотрудников вычислительного центра осуществляется по путям эвакуации через эвакуационные выходы. Количество и общая ширина эвакуационных выходов определяются в зависимости от максимального возможного числа эвакуирующихся через них людей и предельно допустимого расстояния от наиболее удаленного места возможного пребывания людей до ближайшего эвакуационного выхода согласно ТКП 45-2.02-22-2006 [26].

Таблица 8.4 - Примерные нормы первичных средств пожаротушения для вычислительного центра

Помещение

Площадь, м2

Углекислотные огнетушители ручные

Воздушно - пенные огнетушители

Вычислительный центр

100

1

1

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

 

 

8.2 Организация рабочего места пользователя ПЭВМ

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

При правильной организации рабочего места производительность труда инженера возрастает с 8 до 20 процентов. Согласно ГОСТ 12.2.032-78 конструкция рабочего места и взаимное расположение всех его элементов должно соответствовать антропометрическим, физическим и психологическим требованиям. Большое значение имеет также характер работы. В частности, при организации рабочего места инженера необходимо соблюсти следующие основные условия:

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

Главными элементами рабочего места инженера являются письменный стол и кресло. Основным рабочим положением является положение сидя. Рабочее место для выполнения работ в положении сидя организуется в соответствии с ГОСТ 12.2.032-78. Рабочая поза сидя вызывает минимальное утомление инженера.

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

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

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

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

Зоны досягаемости рук в горизонтальной плоскости:

  1. зона максимальной досягаемости;
  2. зона досягаемости пальцев при вытянутой руке;
  3. зона легкой досягаемости ладони;
  4. оптимальное пространство для грубой ручной работы;
  5. оптимальное пространство для тонкой ручной работы.

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

Параметры рабочего места выбираются в соответствии с антропометрическими характеристиками. При использовании этих данных в расчетах исходят из максимальных антропометрических характеристик (М+2).

При работе в положении сидя рекомендуются следующие параметры рабочего пространства: ширина не менее 700 мм; глубина не менее 400 мм; высота рабочей поверхности стола над полом 700-750 мм.

Оптимальными размерами стола являются: высота 710 мм; длина стола 1300 мм; ширина стола 650 мм. Поверхность для письма должна иметь не менее 40 мм в глубину и не менее 600 мм в ширину.

Под рабочей поверхностью должно быть предусмотрено пространство для ног: высота не менее 600 мм; ширина не менее 500 мм; глубина не менее 400 мм.

Важным элементом рабочего места инженера является кресло. Оно выполняется в соответствии с ГОСТ 21.889-76. При проектировании кресла исходят из того, что при любом рабочем положении инженера его поза должна быть физиологически правильно обоснованной, т.е. положение частей тела должно быть оптимальным. Для удовлетворения требований физиологии, вытекающих из анализа положения тела человека в положении сидя, конструкция рабочего сидения должна удовлетворять следующим основным требованиям: допускать возможность изменения положения тела, т.е. обеспечивать свободное перемещение корпуса и конечностей тела друг относительно друга; допускать регулирование высоты в зависимости от роста работающего человека (в пределах от 400 до 550 мм); иметь слегка вогнутую поверхность, иметь небольшой наклон назад.

Исходя из вышесказанного, приведем параметры стола инженера: высота стола 710 мм; длина стола 1300 мм; ширина стола 650 мм; глубина стола 400 мм.

Поверхность для письма: в глубину 40 мм; в ширину 600 мм.

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

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

 

ЗАКЛЮЧЕНИЕ

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

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

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

Приложение может полноправно считаться конкурентоспособным, так как обладает хорошими показателями быстродействия: поставленная задача решается в среднем за 33 секунд, в то время, как вручную для этого требуется 1,2 час. 

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

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

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

 

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

 

  1. Модели AS-IS и TO-BE BPWin [Электронный ресурс] – М.: 2009. – Режим доступа: http://www.cool4student.ru/node/3377 – Загл. с экрана.
  2. Rose для разработчиков и ради разработчиков 2 [Электронный ресурс]. – М.: 2000. – Режим доступа: http://citforum.ru/programming/application/rrose2.shtml. – Загл. с экрана.
  3. Трофимов, С. А. CASE-технологии: практическая работа в Rational Rose  /  С. А. Трофимов. – 2-е изд. – М.: 2002.
  4. Общие сведения о ASP.NET MVC [Электронный ресурс]. – М.: 2012. – Режим доступа: http://msdn.microsoft.com/ru-ru/library/dd381412(v=vs.108).aspx – Загл. с экрана.
  5. VisualStudio [Электронный ресурс]. – М.: 2012. – Режим доступа: http://ru.wikipedia.org/ wiki/Visual_Studio– Загл. с экрана.
  6. Microsoft_SQL_Server[Электронный ресурс]. – М.: 2011. – Режим доступа: http://ru. wikipedia.org/wiki/Microsoft_SQL_Server – Загл. с экрана.
  7. HTML[Электронный ресурс]. – М.: 2012. – Режим доступа: http://ru. wikipedia.org/wiki/HTML – Загл. с экрана.
  8. CSS [Электронный ресурс]. – М.: 2012. – Режим доступа: http://ru.wikipedia.org/wiki/CSS – Загл. с экрана.
  9. Технология ajax при создании сайтов [Электронный ресурс]. – Мн: 2010. – Режим доступа: http://abiatec.by/tech/ajax – Загл. с экрана.
  10. Инсталяция и развертывание[Электронный ресурс]. – М.: 2011. – Режим доступа: http://technet.microsoft.com/ru-ru/library/cc725762.aspx– Загл. с экрана.
  11. Mетодические указания по  определению экономической  эффективности разработки программного обеспечения / Куневич О.В. – Мн.: БНТУ, 2010.
  12. СанПиН 9-131 РБ 2000. Гигиенические требования к видеодисплейным терминалам, электронно-вычислительным машинам и организации работы. - Мн.: Министерство здравоохранения республики Беларусь, 2001.
  13. ГОСТ 12.0.003-74. ССБТ. Опасные и вредные производственные факторы. Классификация.
  14. СанПиН 9-80 РБ98. Гигиенические требования к микроклимату производственных помещений. – Мн., 1998.
  15. Санитарные нормы, правила и гигиенические нормативы «Перечень регламентированных в воздухе рабочей зоны вредных веществ». – Мн.: Министерство здравоохранения Республики Беларусь, 2009.
  16. СНБ 4.02.01-03. Отопление, вентиляция и кондиционирование воздуха.
  17. ТКП 45-2.04-153-2009. Естественное и искусственное освещение. – Мн.: Минстройархитектуры Республики Беларусь, 2010.
  18. СанПиН 2.2.4/2.1.8.10-33-2002. Производственная вибрация, вибрация в помещениях жилых и общественных зданий. – Мн.: Министерство здравоохранения Республики Беларусь, 2003.
  19. Санитарные нормы, правила и гигиенические нормативы «Шум на рабочих местах, в транспортных средствах, в помещениях жилых, общественных зданий и на территории жилой застройки» – Мн.: Министерство здравоохранения Республики Беларусь, 2011.
  20. СанПиН 2.2.4/2.1.8.9-36-2002. Электромагнитные излучения радиочастотного диапазона (ЭМИ РЧ).
  21. ТКП 181—2009 «Правила технической эксплуатации электроустановок потребителей».
  22. Межотраслевые правила по охране труда при работе в электроустановках, утв. Постановлением Министерства труда и социальной защиты Республики Беларусь и Министерства энергетики Республики Беларусь от 30.12.2008 г. № 205/59.
  23. ГОСТ 12.1.030-81. ССБТ. Электробезопасность. Защитное заземление, зануление.
  24. ТКП 474-2013. Категорирование помещений, зданий и наружных установок по взрывопожарной и пожарной опасности, утв. постановлением МЧС Республики Беларусь от 29.01.2013 №4.
  25. ТКП 45-3.02-90-2008. Производственные здания. Строительные нормы проектирования.
  26. ТКП 45-2.02-22-2006. Здания и сооружения. Эвакуационные пути и выходы. Правила проектирования.

ПРИЛОЖЕНИЕ А

 

Листинг модуля HomeController

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using KursWork.Models;
using System.Web.Security;

namespace KursWork.Controllers
{
            [HandleError]
            public class HomeController : Controller
            {
                        public ArtSiadzibaEntities db = new ArtSiadzibaEntities();

                        public ActionResult Index()
                        {
                                   var events = (from Мероприятия in db.Мероприятия
                                                                         where Мероприятия.Дата > DateTime.Today
                                                                         select Мероприятия).ToList();

                                   return View(events);
                        }

                        public ActionResult Subscribe()
                        {
                                   db.Subscribers.AddObject(new Subscribers { email = Membership.GetUser().Email });
                                    db.SaveChanges();
                                   var events = (from Subscribers in db.Subscribers
                                                                         select Subscribers.email).ToList();

                                   return View(events);
                        }

                        public ActionResult Unsubscribe()
                        {
                                   var list = db.Subscribers.ToList();
                                   db.Subscribers.DeleteObject(list.Find(item => item.email == Membership.GetUser().Email));
                                   db.SaveChanges();
                                   var events = (from Subscribers in db.Subscribers
                                                                         select Subscribers.email).ToList();

                                   return View(events);
                        }

                        public ActionResult Details(int id)
                        {
                                   var eventDetails = (from Мероприятия in db.Мероприятия
                                                                                  where Мероприятия.ID_мероприятия == id
                                                                                  select Мероприятия).First();

                                   return View(eventDetails);
                        }

                        public ActionResult About()
                        {
                                   return View();
                        }

                        public ActionResult Reports()
                        {
                                   var reports = (from Отчёты in db.Отчёты
                                                                          select Отчёты).ToList();

                                   return View(reports);
                        }

                        public ActionResult CreatePropose()
                        {
                                   Предложения newProp = new Предложения();
                                   return View(newProp);
                        }


                        [HttpPost]
                        public ActionResult CreatePropose(Предложения newProp)
                        {
                                   try
                                   {
                                               if (ModelState.IsValid)
                                               {
                                                           db.AddToПредложения(newProp);
                                                           db.SaveChanges();
                                                           return RedirectToAction("Index");
                                               }
                                   }
                                   catch (Exception ex)
                                   {
                                               ModelState.AddModelError("Введены некорректные данные", ex);
                                   }
                                   return View(newProp);
                        }
            }
}

ПРИЛОЖЕНИЕ Б

 

Листинг модуля Home/Index

 

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<IEnumerable<KursWork.Models.Мероприятия>>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
   Index
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Index</h2>

    <table>
        <tr>
            <th></th>
            <th>
                Дата
            </th>
            <th>
                Время
            </th>
            <th>
                Краткое описание
            </th>
            <th>
                Полное описание
            </th>
            <th>
                Стоимость
            </th>
            <th>
                ID организатора
            </th>
        </tr>

    <% foreach (var item in Model) { %>
   
        <tr>
            <td>
                <%: Html.ActionLink("Редактировать", "Edit", new { id=item.ID_мероприятия }) %> |
     <%: Html.ActionLink("Подробно", "Details", new { id=item.ID_мероприятия })%> |
     <%: Html.ActionLink("Удалить", "Delete", new { id=item.ID_мероприятия })%> |
                <%: item.Дата >= DateTime.Today ? Html.ActionLink("Пригласить", "Subscribe", new { id = item.ID_мероприятия }) : Html.ActionLink("Создать отчёт", "CreateReports", new { id = item.ID_мероприятия })%>
            </td>
            <td>
                <%: String.Format("{0:dd MMMM yyyy}", item.Дата) %>
            </td>
            <td>
                <%: String.Format("{0:hh\\:mm}", item.Время) %>
            </td>
            <td>
                <%: item.Краткое_описание %>
            </td>
            <td>
                <%: item.Полное_описание %>
            </td>
            <td>
                <%: item.Стоимость %>
            </td>
            <td>
                <%: item.ID_организатора %>
            </td>
        </tr>
   
    <% } %>

    </table>

    <p>
        <%: Html.ActionLink("Добавить новое", "Create") %>
        <%: Html.ActionLink("Просмотреть предложения (" + ViewData.Count + ")", "Propose") %>
    </p>

</asp:Content>

ПРИЛОЖЕНИЕ В

 

Листинг модели Мероприятия

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
using System.Web.Mvc;
using System.ComponentModel;
namespace KursWork.Models
{
    [MetadataType(typeof(EventMetadata))]
    public partial class Мероприятия
    {
       [Bind(Exclude="ID_мероприятия")]
        public class EventMetadata
        {
            [ScaffoldColumn(false)]
            public int ID_мероприятия { get; set; }
            [DisplayName("Краткое описание")]
            [Required(ErrorMessage="Краткое описание обязательно для заполнения")]
            [DisplayFormat(ConvertEmptyStringToNull=false)]
            [StringLength(50)]
            public string Краткое_описание { get; set; }
            [DisplayName("Полное описание")]
            [DisplayFormat(ConvertEmptyStringToNull = false)]
            public string Полное_описание { get; set; }
           [DisplayName("Стоимость")]
           [DisplayFormat(DataFormatString="{0:F2}", ApplyFormatInEditMode=true)]
            [Range(0, 200000, ErrorMessage="Стоимость не может быть отрицательной")]
            public decimal Стоимость { get; set; }
            [DisplayName("ID организатора")]
            [Required(ErrorMessage = "Укажите организатора")]
            public int ID_организатора { get; set; }
            [DisplayName("Дата мероприятия")]
            [Required(ErrorMessage = "Укажите дату")]
           [DisplayFormat(DataFormatString="{0:dd MMMM}", ApplyFormatInEditMode=true)]
            public DateTime Дата { get; set; }
            [DisplayName("Время мероприятия")]
            [Required(ErrorMessage = "Укажите время")]
            [DisplayFormat(DataFormatString = "{0:hh\\:mm}", ApplyFormatInEditMode = true)]
            public TimeSpan Время { get; set; }
        }
    }
}

ПРИЛОЖЕНИЕ Г

 

Опись листов графической части дипломного проекта

 

Лист 1 – Цели и задачи проекта.

Лист 2 – Главная контекстная диаграмма (модель AS-IS).

Лист 3 – Декомпозиция контекстной диаграммы AS-IS.

Лист 4 – Главная контекстная диаграмма (модель TO-BE).

Лист 5 – Декомпозиция контекстной диаграммы TO-BE.

Лист 6 – Диаграмма вариантов использования.

Лист 7 – Диаграмма деятельности «Администратор».

Лист 8 – Диаграмма деятельности «Пользователь».

Лист 9 – Диаграмма развертывания проекта.

Лист 10 – Главная страница сайта.

Лист 11 – Технико-экономические показатели проекта.

 

 

547