Разработка информационной системы Система управления конференцией

Содержание
Введение
1 Архитектура системы конференции
1.1 Диаграмма прецедентов
1.2 Структура базы данных MySQL
1.3 Entity Relationship Model
2 Разработка системы конференции
2.1 Генерация сборника
2.2 Назначение рецензента
2.3 Модуль Учитель
2.4 Умный Поиск
3 Использованные технологии
3.1 Язык программирования Java
3.2 MVC
3.3 Stripes
3.4 jаvascript
3.5 jQuery
3.6 iText
3.7 CSS
3.8 Hibernate
3.9 Веб-сервер Apache Tomcat
4 Экономическая часть
4.1 Трудовые ресурсы, используемые в работе
4.2 Оборудование, используемое на работе
4.3 Программное обеспечение, используемое на работе
4.4 Сроки реализации проекта
4.5 Затраты на разработку системы
4.6 Расчет фонда оплаты труда
4.7 Расчет затрат по социальному налогу
4.8 Расчет амортизационных отчислений
4.9 Расчет затрат на электроэнергию и накладных расходов
4.10 Цена реализации
5 Безопасность жизнедеятельность
5.1 Характеристика условий труда программиста
5.2 Окраска и коэффициенты отражения
5.3 Параметры микроклимата
5.4 Шум и вибрация
5.5 Электромагнитное и ионизирующее излучения
5.6 Расчет освещенности и уровня шума
Заключение
Список использованной литературы
Приложение
Архитектура системы конференции
1.1 Диаграмма прецеденто
Диаграмма прецедентов в UML — диаграмма, отражающая отношения
между клиентом и прецедентами и являющаяся составной частью модели
прецедентов, позволяющей описать систему на концептуальном уровне.

Прецедент —

возможность моделируемой системы (часть её

функциональности), благодаря которой пользователь может получить
конкретный, измеримый и нужный ему результат. Прецедент соответствует
отдельному сервису системы, определяет один из вариантов её использования
и описывает типичный способ взаимодействия пользователя с си стемой.
Варианты использования обычно применяются для спецификации внешних
требований к системе [1].
Основное назначение диаграммы — описание функциональности и
поведения, позволяющее заказчику, конечному пользователю
и разработчику совместно обсуждать проектируемую или
существующую систему.
Из Рисунка 1.1 видно, что клиент имеет прямую связь и имеет
отношение к прецеденту заказ продукта.
Рисунок 1.1 – Пример диаграммы прецедентов
Рисунок 1.2 – Структура модели

В нашем проекте мы имеем закупщиков. Это: администратор
конференции/соревнования (administrator), участник конференции/соревнован
ия (participant), учитель (teacher), и рецензент работ, докладов, и статей
(reviewer). В системе 5 прецедентов:
- подача работы и статьи (order submission);
- генерация сборника (generate proceeding);
- создать конференцию/соревнование (conference/competition);
- рецензия статьи (review submission);
- загрузка работы и научных исследований (place article).
Теперь рассмотрим подробнее каждый прецедент и дадим полное
описание:
а) создать конференцию/соревнование
в системе администратор

конференции можно создать новую конференцию, семинар или соревнование.
После регистрации конференций в системе он управляет эту конференцию,
добавляет дополнительную информацию, обновляет данные или удаляет
существующую информацию. К тому же, он видит всех участников
конференций и делает рассылку новостей всем участникам;
б) одной стороны участник тоже играет роль в этом прецеденте. Как
только администратор создаст конференцию в системе, он может
зарегистрироваться в эту конференцию и подать заявку на участие;
в) после регистрации в конференции и семинаров участники подают
свои работы и статьи. У каждой конференции свои правила для работ и
докладов. После администратор и модератор мероприятия проверяют
загруженные работы по своим правилам, и подтверждают подачу, либо
отклоняют
г) рецензия статьи в конференциях, где участвуют тысячи участников и
работы, комитету трудно оценивать работу вручную. Исследуется применение
методов машинного обучения для решения этой задачи, а именно, учитывая
информацию некоторых конференциях и свои задания, мы будем выполнять
эффективную оценку параметров и использовать этот модель для вывода
задания в ряде других конференций. Учитывая конференцию с участием M
рецензентов и N представленных документов, мы хотели бы выделить
каждому рецензенту один доклад для оценки, такой, чтоб каждый рецензент
адекватно давал отзывы. В этом прецеденте мы имеем двух актеров –
рецензента и администратора;
д) генерация сборника является одним из важных функции системы.
Ручная генерация сборников требует много времени. Ты должен собрать все
работы участников и копировать их всех в один файл. Это трудная задача для
модератора. Итак, с помощью этой функций мы уменьшили нагрузку и
сделали генерацию сборника легкой. Эта функция была разработана с
помощью библиотеки iText, которая используется для работы с PDF файлами.
ж) загрузка работы и научных исследований это система управления
конференциями хранит информацию об учителей. У них есть своя отдельная
страница, где они могут управлять ею. Также, они могут загружать
документы, статьи, и свои работы.

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

MySQL - свободная реляционная система управления базами данных.
Корпорация Oracle осуществляет разработку и поддержку MySQL, которая
получила права на торговую марку вместе с поглощённой Sun Microsystems.
Ранее Sun Microsystems приобрела шведскую компанию MySQL AB . Продукт
распространяется как под GNU General Public License , так и под собственной
коммерческой лицензией.
Существует несколько типов моделей баз данных. Иерархические и
сетевые крайне не удобны в работе. Тогда как реляционные получили
широкое признание. Реляционная база данных впервые появилась на свет в
1969 году и бесспорно стала сегодня наиболее широко используемой моделью
базы данных в системах управления базами данных. Эдгар Ф. Кодд
официально представил свою новую реляционную модель в эпохальной
работе, озаглавленной « A Relational Model of Data for Large Shared Databanks -
реляционная модель данных для больших совместно используемых банков
данных». В основу своей новой модели он положил два раздела математики:
теорию множеств и исчисление предикатов первого порядка. Само
наименование новой модели происходит от термина «отношение»,
заимствованного из теории множеств. С момента появления реляционная
модель является основой программных продуктов для баз данных, известных
как система управления реляционными базами данных. Выпускаемы различными поставщиками, они спустя несколько лет получили признание в
различных отраслях и организациях и используются в средах различного типа.
В 70 -х годах мэйнфреймы использовали такие программы, как System R
компании IBM и INGRES , разработанную в Калифорнийском университете в
Беркли. В 80 - 8 годы СУРБД для мэйнфреймов получили развитие таких
программных продуктах, как Oracle одноименной компании и DB2 компании
IBM. Бурное развитие персональных компьютеров в середине 80 -х вызвало
появление таких программ, как dBase от Ashton Tate, Paradox от Ansa Software
и R:BASE от Microrim. Когда в начале 90 -х годов стала очевидной
потребностью в совместном использовании данных персональными
компьютерами, родилась клиент - серверная вычислительная модель вместе с
идеей централизованно расположенных общих данных, которыми было бы
легко управлять и обеспечивать из безопасность. Эта концепция дала начало
таким продуктам, как Oracle 8i и Microsoft SQL Server 7.
Приблизительно с 1996 года были приложены более согласованные
усилия к обеспечению доступности баз данных в Интернете. Поставщики
программного обеспечения серьезно отнеслись к этим усилиям и теперь
предлагают продукты «с расширенной поддержкой Web », такие как Cold
Fusion от Allaire, Sybase Enterprise Application Studio от Sybase и Visual
InterDev от Microsoft.
В соответствии с реляционной моделью данные в реляционной базе
данных сохраняются в отношениях, или связях, которые воспринимаются
пользователем как таблицы. Каждое отношение состоит из кортежей (записей)
и атрибутов (полей).
Таблицы являются основными структурами в базе данных. Каждая
таблица описывает отдельный предмет. Логический порядок записей и полей
в таблице совершенно не имеет значения. Каждая таблица содержит хот я бы
одно поле (называемое первичным ключом), которое однозначно
идентифицирует каждую из записей.
Поле является атомарной структурой в базе данных, и оно представляет
собой характеристику предмета таблицы, к которой оно относится. Поля
реально используются для хранения данных. Данные из этих полей можно
затем извлекать и представлять как информацию почти в любой вообразимой
форме. Качество информации получаемой из таблицы прямо
пропорционально времени посвященному обеспечению структурной
целостности и целостности данных в самих полях. Совершенно невозможно
недооценить важность полей.
Каждое поле в базе данных, спроектированной надлежащим образом,
содержит одно и только одно значение, а имя поле идентифицирует тип
хранимого в нем значения. Это само по себе делает ввод данных в поле
интуитивным. Если поля имеют такие имена, как FirstName, LastName, City,
State и ZipCode , то не нужно гадать, значения какого типа заносятся в каждое
поле. Также облегчается процесс сортировки данных по состоянию или поиск
какого - либо с фамилией Hernandez.
Запись представляет собой уникальный экземпляр предмета таблицы.
Она составляется из полного набора полей в таблице независимо от того,
содержат ли эти поля какие - либо значения или нет. Вследствие способа
определения таблицы каждая запись идентифицируется в базе данных
уникальным значением в поле первичного ключа этой записи.

1.3 Entity Relationship Model

Entity Relationship Model (русс . Модель сущность - связь, ERM) —
модель данных, позволяющая описывать концептуальные схемы предметной
области.
ER-модель используется при высокоуровневом
(концептуальном) проектировании баз данных. С её помощью можно
выделить ключевые сущности и обозначить связи, которые могут
устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-
модели в конкретную схему базы данных на основе выбранной модели
данных (реляционной, объектной, сетевой и др.).
ER-модель представляет собой формальную конструкцию, которая сама
по себе не предписывает никаких графических средств её визуализации. В
качестве стандартной графической нотации, с помощью которой можно
визуализировать ER-модель, была предложена диаграмма сущность-связь
(ER-диаграмма) (англ. entity-relationship diagram, ERD).
Модель «сущность -связь» была предложена в 1976 году Питером Пин -

Шен Ченом (англ. Peter

Pin-Shen

Chen), американским профессором
компьютерных наук в университете штата Луизиана [3].
Множества сущностей изображаются в виде прямоугольников,
множества отношений изображаются в виде ромбов. Если сущность участвует
в отношении, они связаны линией. Если отношение не является обязательным,
то линия пунктирная. Атрибуты изображаются в виде овалов и связываются
линией с одним отношением или с одной сущностью [3].
Данная нотация была предложена Гордоном Эверестом (англ. Gordon
Everest) под названием Inverted Arrow («перевёрнутая стрелка»), однако
сейчас чаще называемая Crow's Foot («воронья лапка») или Fork («вилка») [4].
Согласно данной нотации, сущность изображается в виде
прямоугольника, содержащем её имя, выражаемое существительным. Имя
сущности должно быть уникальным в рамках одной модели. При этом, имя
сущности — это имя типа, а не конкретного экземпляра данного типа.
Экземпляром сущности называется конкретный представитель данной
сущности.
Связь изображается линией, которая связывает две сущности,
участвующие в отношении. Степень конца связи указывается графически,
множественность связи изображается в виде «вилки» на конце связи.
Модальность связи так же изображается графически — необязательностьсвязи помечается кружком на конце связи. Именование обычно выражается
одним глаголом в изъявительном наклонении настоящего времени: «Имеет»,
«Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в
себя». Наименование может быть одно для всей связи или два для каждого из
концов связи. Во втором случае, название левого конца связи указывается над
линией связи, а правого – под линией. Каждое из названий располагаются
рядом с сущностью, к которой оно относится.
Атрибуты сущности записываются внутри прямоугольника,
изображающего сущность и выражаются существительным в единственном
числе (возможно, с уточняющими словами). Среди атрибутов выделяется
ключ сущности — не избыточный набор атрибутов, значения которых в
совокупности являются уникальными для каждого экземпляра сущности.....