Web-сайт сибирского медицинского журнала

Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Томский государственный университет систем управления и радиоэлектроники» (ТУСУР) Кафедра автоматизации обработки информации (АОИ) Пояснительная записка к дипломному проекту

Web-сайт сибирского медицинского журнала

РЕФЕРАТ Дипломный проект 91 стр., 26 рис., 17 табл., 12 источника, 1 приложение.

WEB-САЙТ, СИБИРСКИЙ МЕДЕЦИНСКИЙ ЖУРНАЛ.

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

Цель работы — повышение цитируемости авторов статей «Сибирского медицинского журнала» и импакт-фактора журнала, продвижение журнала в Интернет-пространстве.

Результатом выполнения дипломного проекта стал Web-сайт «Сибирского медицинского журнала» .

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

Дипломный проект выполнен в текстовом редакторе MS Word 2000, Web-сайт разработан на языке PHP.

ABSTRACT

Diplomarbeit 91 p., 26 fig., 17 tables., 12 sources, 1 adj.

WEB-SITE, THE SIBIRIAN MEDICAL JOURNAL.

The object of research is activities in the field of electronic medical journals, ways to improve citation indexes.

The aim is improving the authors of articles citing «Siberian Medical Journal» and the journal impact factor, promoting the magazine in the Internet space.

The result of the graduation project was a Web-site «The Siberian medical journal»

The explanatory note contains a description of the subject area, the problem situation, solutions to the problem.

The degree project is executed in a text editor, MS Word 2000, the Web-site was developed in PHP.

• ВВЕДЕНИЕ
• 1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• 2. ПОСТАНОВКА ЗАДАЧИ И ПУТИ РЕШЕНИЯ
• 2.1 Описание проблемной ситуации
• 2.2 Пути решения проблемы
• 2.3 Постановка задачи
• 2.4 Обзор аналогов
• 2.5 Выбор средств реализации
• 3. ВЫЯВЛЕНИЕ И СБОР ТРЕБОВАНИЙ
• 3.1 Запросы заинтересованных сторон
• 3.2 Бизнес-правила
• 3.3 Функциональные требования
• 3.4 Нефункциональные требования
• 4. ПРОЕКТИРОВАНИЕ
• 4.1 Описание методологии RUP
• 4.2 Описание структуры сайта
• 4.3 Диаграмма прецедентов
• 4.4 Модель предметной области
• 4.5 Диаграмма последовательности
• 4.6 Диаграмма деятельности
• 4.7 Модель базы данных
• 5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
• 5.1 Сервер
• 5.2 Клиент
• 5.3 Обмен данными
• 5.4 Система управления сайтом
• 5.5 Описание разделов сайта
• 6. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА
• 6.1 Описание программного продукта
• 6.2 Определение технико-экономических показателей проекта прямым методом
• 6.3 Метод определения ТЭП проекта на основе размерности базы данных
• 6.4 Определение технико-экономических показателей методом функциональных точек
• 6.5 Определение договорной цены на создание программной системы
• 6.6 Резюме
• ЗАКЛЮЧЕНИЕ
• Список использованных источников
• ПРИЛОЖЕНИЕ
• медицинский журнал сайт прецедент

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

Кроме того, целесообразность создания сайта журнала, как инструмента аккумулирования и распространения знаний, может и должна быть обоснована экономически. Потребность в сайте «Сибирского медицинского журнала» возникла в результате изменений в законодательстве: в конце августа 2010 г. был издан Приказ Министерства здравоохранения и социального развития РФ № 738н «Об оценке результативности деятельности научных организаций, подведомственных Минздравсоцразвития России, выполняющих научно-исследовательские, опытно-конструкторские и технологические работы гражданского назначения». Согласно приказу планируется оценка научного потенциала. Один из основных критериев оценки — участие в организации индексирования библиометрических показателей Scopus. Scopus— библиографическая и реферативная база данных и инструмент для отслеживания цитируемости статей, опубликованных в научных изданиях. Индексирует 18 000 названий научных изданий по техническим, медицинским и гуманитарным наукам 5000 издателей. Результаты оценки библиометрических показателей влияют на финансирование научного учреждения. Чтобы повысить этот показатель для ФГБУ «НИИ кардиологии» СО РАМН, было принято решение создать сайт «Сибирского медицинского журнала» .

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

ФГБУ «НИИ кардиологии» СО РАМН занимает стабильную позицию среди лидеров федеральных медицинских учреждений, участвующих в оказании высокотехнологичной медицинской помощи гражданам РФ по профилю «сердечно-сосудистая хирургия» за счет ассигнований федерального бюджета.

Основные направления научной деятельности института:

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

· изучение эпидемиологии сердечно-сосудистых заболеваний и формирование инновационной стратегии их профилактики;

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

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

· В ФГБУ «НИИ кардиологии» СО РАМН проводятся интенсивные научные исследования практически по всем актуальным направлениям современной кардиологии.

· В рамках ФЗ № 217 ФГБУ «НИИ кардиологии» СО РАМН и Национальным исследовательским Томским государственным политехническим университетом создано первое совместное инновационное предприятие «Нанокор», которое будет работать в условиях Фонда «Сколково» .

ФГБУ «НИИ кардиологии» СО РАМН выпускает рецензируемый журнал «Сибирский медицинский журнал», который был основан в 1922 году. Это ежеквартальный рецензируемый научно-практический журнал, ориентирован на практических врачей всех специальностей, научных работников и студентов, а также на широкую читательскую аудиторию, проявляющую интерес к достижениям современной медицины. Содержит уникальные материалы и фотографии по истории медицины и здравоохранения Сибири и Дальнего Востока.

" Сибирский медицинский журнал" издавался в г. Томске с 1923 по 1931 гг. В 1996 году выпуск журнала был возрожден под издательством Российской академии медицинских наук Научно-исследовательский институт кардиологии Сибирского отделения Российской академии медицинских наук. В журнал входят следующие основные разделы:

· Клинические исследования;

· Лабораторные и экспериментальные исследования;

· Организация здравоохранения и общественное здравоохранение;

· Опыт регионов;

· В помощь практическому врачу;

· Обзоры и лекции;

· Рецензии и рефераты;

· Интеллектуальная собственность в медицине;

· История медицины.

· Главный редактор журнала: Р. С. Карпов, академик РАМН.

· Члены редакционной коллегии:

· Л. А. Агаркова, профессор;

· Ф. В. Алябьева, доцент;

· А. В. Врублевский, д.м.н.;

· Н. П. Гарганеева, профессор;

· В. В. Климов, профессор;

· М. А. Медведев, академик РАМН;

· Г. И. Мендрина, профессор;

· С. А. Некрылов, доцент;

· В. В. Поддубный, профессор;

· С. В. Попов, профессор;

· Р. Г. Соляник, профессор;

· Ф. Ф. Тетенев, профессор;

· И. А. Трубачева, д.м.н.;

· В. В. Удут, профессор.

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

2.1 Описание проблемной ситуации

В 2009 г., когда финансирование гражданского сектора науки достигло 127 миллиардов рублей, Президент поручил Правительству, а оно — Министерству образования и науки разработать методику, позволяющую оценить, уровень, качество и потенциал каждой научной организации. Исполняя поручение, Минобрнаки России предложило проект методики оценки эффективности научных организаций, позволяющей «одним метром» измерить все научные организации России и составить единую карту их результативности.

В конце августа 2010 г. был издан Приказ Министерства здравоохранения и социального развития РФ № 738н «Об оценке результативности деятельности научных организаций, подведомственных Минздравсоцразвития России, выполняющих научно-исследовательские, опытно-конструкторские и технологические работы гражданского назначения». Таким образом, от равномерного распределения бюджетных средств на НИР и НИОКР государство начало переходить к фокусной, грантовой поддержке наиболее сильных НИИ и научных коллективов. При этом в качестве индикаторов, используемых для категоризации и дифференциации объемов финансирования, стали использоваться публикационная активность и блок показателей коммерциализации результатов исследований.

Использование библиометрических показателей стало возможным благодаря созданию д-ром Ю. Гарфилдом в 1961 г. Института научной информации США, выпускающего с 1964 г. Указатель цитированной литературы — Science Citation Index. Мониторинг этих показателей проводится во всех промышленных странах мира. Целесообразность использования библиометрических показателей была в 2003 г. была подтверждена статистическим институтом ЮНЕСКО, который ввел в качестве параметров измерения научной деятельности следубщие библиометрические данные: количество публикаций, их цитируемость, количество поданных патентов.

Таким образом, чтобы упрочнить свое положение и финансовое обеспечение ФГБУ «НИИ кардиологии» СО РАМН необходимо повысить публикационную своих сотрудников.

2.2 Пути решения проблемы

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

2.3 Постановка задачи

Необходимо создать сайт «Сибирского медицинского журнала», который бы смог удовлетворить следующие потребности:

· повысить цитируемость статей сотрудников учреждения;

· повысить импакт-фактор издания;

· улучшить контроль за научной деятельностью сотрудников;

· повысить доступность материалов опубликованных в журнале;

· расширить читательскую аудиторию;

· повысить привлекательность журнала в научной среде;

· увеличить прибыль за счет новых способов рекламы;

· повысить рейтинг ФГБУ «НИИ кардиологии» СО РАМН среди научных учреждений РФ.

Сайт способен вывести журнал на новый уровень развития и эффективно решить проблему библиометрических показателей сотрудников ФГБУ «НИИ кардиологии» СО РАМН.

2.4 Обзор аналогов

Проанализируем функциональные возможности и интерфейс некоторых аналогов.

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

Таблица 2.1 — Сравнение по функциональным возможностям

2.5 Выбор средств реализации

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

СУБД

MySQL — это объектно-реляционная система управления базами данных (СУБД), которая имеет традиционные возможности коммерческих СУБД с расширениями, которые есть в СУБД нового поколения. MySQL — это свободное и полностью открытое программное обеспечение. MySQL базируется на языке SQL и поддерживает многие из возможностей стандарта SQL:2003 (ISO/IEC 9075).

Сильными сторонами MySQL считаются:

· поддержка БД практически неограниченного размера;

· мощные и надёжные механизмы транзакций и репликации;

· наследование;

· легкая расширяемость.

MySQL имеет большинство возможностей представленных в больших коммерческих СУБД, такие как: транзакции, подзапросы, триггеры, представления, ссылочной целостности вторичного ключа и разные блокировки.

Производительность MySQL сходна с другими коммерческими СУБД и с СУБД с открытым исходным кодом.

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

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

Сервер Apache

В качестве сервера приложений, выбран web-сервер Apache. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете. По статистике Netcraft, в августе 2007 года он установлен на 51% всех веб-серверов, в марте 2009 года — на 49%.

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

3. ВЫЯВЛЕНИЕ И СБОР ТРЕБОВАНИЙ

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

Этап сбора требований необходим для:

· обсуждения разработчиком системы и заказчиком проблемной ситуации и выявление возможностей системы;

· полного понимания системных требований разработчиком;

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

· определения пользовательского интерфейса системы.

Согласно рекомендациям RUP требования необходимо сгруппировать по категориям:

· функциональные возможности (functionality);

· практичность (usability);

· надежность (reliability);

· производительность (performance);

· возможность поддержки (supportability).

Требования практичности (usability) — требования такого типа описывают, как пользователи будут приспосабливаться к системе.

Требования надежности (reliability) — требования, которые определяют насколько приемлемым с точки зрения пользователя образом должна вести себя система.

Требования к производительности (performance) — требования, которые показывают все параметры производительности системы.

Требования к возможности поддержки (supportability) — требования, которые заключаются в способности легко модифицировать программное обеспечение с целью внесения изменений и исправлений.

3.1 Запросы заинтересованных сторон

Заинтересованные стороны — это все, на кого реализация новой системы или приложения может оказать материальное воздействие.

Сведения о заинтересованных сторонах:

· ФГБУ «НИИ кардиологии» СО РАМН — непосредственный заказчик и потребитель, представитель — руководитель отделения популяционной кардиологии с группой научно-медицинской информации, патентоведения и международных связей;

· ФГУ Центральный НИИ организации и информатизации здравоохранения — заинтересовано в повышении доступности и увеличении рейтинга российских научных исследований в области медицины, представитель — заведующий отделением коммуникационных технологий и общего программного обеспечения;

· Минздравсоцразвития РФ — заинтересовано в финансовой поддержке учреждений, занимающих ведущее место, в число сотрудников которых входят ученые с высокими библиометрическими показателями, представитель — заместитель департамента информатизации;

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

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

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

Таблица 3.1 — Запросы заинтересованных сторон

3.2 Бизнес-правила

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

Таблица 3.2 — Бизнес-правила проекта

3.3 Функциональные требования

Функциональные требования (functional requirements) определяют функциональность разрабатываемой системы, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна» .

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

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

Ниже приведена матрица атрибутов функциональных требований.

Таблица 3.3 — Матрица атрибутов функциональных требований

3.4 Нефункциональные требования

Требования практичности Требования к практичности системы следующие:

· система должна легко осваиваться пользователем в течение 7−10 минут;

· среднее время формирования заявки на опубликование в журнале должно составлять 5−10 минут.

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

· время обработки запроса должно занимать не более 5 сек.;

· количество пользователей, одновременно работающих с системой, неограниченно.

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

4. ПРОЕКТИРОВАНИЕ

4.1 Описание методологии RUP

В процессе разработки приложения учитывались рекомендации Rational Unified Process (RUP) — методологии разработки программного обеспечения от компании Rational Software.

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

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

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

Также RUP поддерживает объектно-ориентированную технологию. Некоторые из моделей являются объектно-ориентированными моделями, которые базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам — артефактам, используют унифицированный язык моделирования (UML) как общую систему обозначений.

На этапе анализа и проектирования использовались следующие программные продукты:

· IBM Rational Requisite Pro — инструмент сбора и управления требованиями;

· IBM Rational Rose — средство визуального моделирования бизнес процессов, и проектирования на языке UML;

· UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения.

4.2 Описание структуры сайта

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

Ниже представлена структура сайта:

· О журнале:

а) Из истории;

б) Положение о журнале;

в) Редакционная коллегия;

г) Редакционный совет;

д) Учредители;

е) Партнеры;

ж) Подписка;

· Редакция:

а) Редакционно-издательская группа;

б) Контакты;

· Авторам:

а) Условия публикации;

б) Правила оформления статей;

в) Образцы документов;

г) Реквизиты для оплаты публикаций;

д) Авторские права;

е) Наши авторы;

ж) Услуги;

з) Полезные ссылки;

· Рецензентам:

а) Положение об институте рецензентов;

б) Образец рецензии;

в) Предложение к сотрудничеству;

г) Анкета рецензента;

· Новости;

· Архив;

· Вопрос-ответ;

· Скачать свежий номер;

· Поиск;

· Обращение главного редактора;

· Личный кабинет пользователя.

Подробнее о структуре сайта в приложении А.

4.3 Диаграмма прецедентов

Диаграмма прецедентов (use case diagram) относится к концептуальному представлению системы, описывая назначение системы. Она разрабатывается для достижения следующих целей [8]:

· определить границы и контекст моделируемой системы;

· сформулировать требования к поведению системы;

· создать и зафиксировать исходное концептуальное представление системы с целью его последующей детализации в форме логических и физических моделей;

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

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

Рисунок 4.1 — Диаграмма прецедентов Каждый прецедент имеет краткое описание, кроме прецедента «Добавить статью», который имеет развернутое описание. Ниже представлены краткие описания прецедентов.

· «Добавить пользователя» — Администратор выбирает пункт меню «Добавить пользователя». Система открывает специальную форму. Администратор вводит требуемую информацию; Система ее верифицирует и регистрирует. Администратор нажимает кнопку добавить. Система создает нового пользователя; выдает сообщение о том, что новый пользователь успешно добавлен;

· «Удалить пользователя» — Администратор выбирает пункт меню «Управление пользователями». Система открывает специальную форму с таблицей, в которой собрана информация обо всех пользователях. Администратор в поле поиска вводит имя пользователя. Система осуществляет поиск по таблице, выводит совпадения. Администратор выбирает пользователя из результата поиска, нажимает кнопку удалить. Система запрашивает подтверждение удаления. Администратор подтверждает удаление. Система удаляет пользователя;

· «Изменить учетную запись пользователя» — Администратор выбирает пункт меню «Управление пользователями». Система открывает специальную форму с таблицей, в которой собрана информация обо всех пользователях. Администратор в поле поиска вводит имя пользователя. Система осуществляет поиск и выводит результат. Администратор выбирает пользователя из результата поиска, нажимает кнопку «Изменить». Система открывает специальную форму с информацией о пользователе. Администратор вносит изменения и нажимает кнопку «Сохранить». Система запрашивает подтверждение изменений. Администратор подтверждает. Система изменяет данные пользователя;

· «Опубликовать новости» — Администратор выбирает пункт меню «Добавить новость». Система открывает специальную форму. Администратор заполняет требуемые поля, прикрепляет изображение; нажимает кнопку добавить. Система загружает новость;

· «Искать по архиву журнала» — Пользователь выбирает пункт меню «Поиск». Система открывает форму поиска. Пользователь заполняет необходимые поля и нажимает кнопку «Найти». Система осуществляет поиск по заданным критериям; выводит результат поиска;

· «Просматривать тексты статей» — Пользователь выбирает пункт меню «Архив». Система переходит на страницу с временной шкалой. Пользователь выбирает год, номер журнала. Система выводит список заголовков статей и авторов соответственно. Пользователь нажимает на заголовок статьи. Система загружает полный текст статьи в формате pdf;

· «Просматривать новости» — Пользователь выбирает пункт меню «Новости». Система загружает необходимую страницу;

· «Посмотреть информацию о журнале» — Пользователь выбирает пункт меню «О журнале». Система переходит на соответствующую страницу;

· «Зарегистрироваться» — Пользователь нажимает кнопку «Зарегистрироваться». Система открывает специальную форму. Пользователь вводит требуемую информацию; Система ее верифицирует и регистрирует. Пользователь нажимает кнопку «Зарегистрироваться». Система создает нового пользователя;

· «Войти в систему» — Зарегистрированный пользователь нажимает кнопку «Вход». Система открывает специальную форму. Пользователь вводит e-mail и пароль; нажимает кнопку «Войти». Система проверяет введенные данные; загружает главную страницу;

· «Заполнить анкету рецензента» — Зарегистрированный пользователь выбирает пункт меню «Анкета рецензента». Система переходит на страницу с соответствующей формой. Зарегистрированный пользователь вводит требуемую информацию; Система верифицирует и регистрирует изменения. Пользователь нажимает кнопку «Отправить». Система регистрирует заявку;

· «Подать заявку на размещение статьи в журнале» — Зарегистрированный пользователь выбирает пункт меню «Подать заявку». Система загружает специальную форму. Зарегистрированный пользователь вводит требуемую информацию; прикрепляет свою статью, резюме, сопроводительное письмо. Система верифицирует и регистрирует изменения. Пользователь нажимает кнопку «Отправить». Система регистрирует заявку;

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

· «Профиль» — Зарегистрированный пользователь нажимает кнопку «Настроить аккаунт». Система загружает станицу с информацией об этом пользователе. Зарегистрированный пользователь вносит изменения. Система верифицирует и регистрирует изменения. Зарегистрированный пользователь нажимает кнопку «Сохранить». Система сохраняет изменения.

Спецификация прецедента «Добавить статью»

Краткое описание:

Администратор добавляет статью в БД системы.

Основной актер:

Администратор.

Заинтересованные стороны и их потребности:

· Автор. Увеличить число читателей статьи, повысить свой индекс цитируемости;

· Организация. Повысить свой рейтинг;

· Администратор. Актуализировать электронную версию журнала;

· Читатель. Бесплатно получить новый актуальный источник знаний.

Предусловия: Администратор идентифицирован и аутентифицирован.

Постусловия: Статья успешно сохранена в БД.

Потоки событий:

Основной поток (Основной успешный сценарий)

1) Администратор выбирает пункт меню «Добавить статью» .

2) Система открывает специальную форму.

3) Администратор вводит заголовок на русском языке.

4) Администратор вводит заголовок на английском языке.

5) Администратор вводит УДК.

6) Администратор выбирает автора из выпадающего списка.

7) Администратор выбирает дату выхода журнала с данной статьей из выпадающего календаря.

8) Администратор водит ключевое слово.

9) Система формирует список близких по лексическому значению ключевых слов.

10) Администратор выбирает из списка нужное ключевое слово.

11) Система добавляет ключевое слово к списку ключевых слов этой статьи.

12) Администратор выбирает категорию из выпадающего списка.

13) Администратор нажимает кнопку «Прикрепить аннотацию на русском языке» .

14) Система открывает диалоговое окно.

15) Администратор выбирает из каталога файл.

16) Система запоминает путь к выбранному файлу.

17) Администратор нажимает кнопку «Прикрепить аннотацию на английском языке» .

18) Система открывает диалоговое окно.

19) Администратор выбирает из каталога файл.

20) Система запоминает путь к выбранному файлу.

21) Администратор нажимает на кнопку «Прикрепить статью» .

22) Система открывает диалоговое окно.

23) Администратор выбирает из каталога файл.

24) Система запоминает путь к выбранному файлу.

25) Администратор нажимает кнопку «Добавить» .

26) Система загружает новую статью на сервер.

27) Система выдает сообщение об успешной загрузки статьи.

28) Система увеличивает рейтинг категории.

29) Система обновляет облако тегов.

Альтернативные потоки (Расширения):

*а. При каждом выходе системы из строя.

1) Система выдает сообщение об ошибке

2) Система возвращает Администратора на главную страницу

6a. Автора нет в списке.

1) Администратор нажимает на кнопку «+» .

2) Система отрывает форму добавления нового участника.

3) Администратор заполняет пустые поля.

4) Нажимает кнопку добавить.

5) Система проверяет правильность заполнения формы. Если форма заполнена некорректно возвращает пользователя на форму и выделяет красным необходимые для корректировки поля.

6) Система проверяет зарегистрирован ли уже такой автор. Если да, то система выдает сообщение.

7) Система создает нового участника.

9a. Ключевого слова нет в списке или список пуст.

1) Администратор нажимает кнопку «+» .

2) Система сохраняет новое ключевое слово.

12a.Категории нет в списке.

1) Администратор вводит в поле новое слово.

2) Администратор нажимает кнопку «+» .

3) Система создает новую категорию.

25a. Не все поля заполнены.

1) Система возвращает администратора на форму добавления.

2) Система выдает сообщение об ошибке.

3) Система выделяет поля, которые необходимо заполнить.

26а. Произошла ошибка при загрузке.

1) Система выдает сообщение об ошибке.

2) Система возвращает администратора на форму добавления.

4.4 Модель предметной области

Модель предметной области — визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.

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

Модель предметной области сайта представлена в виде диаграммы классов на рисунке 4.2.

Рисунок4.2 — Модель предметной области

4.5 Диаграмма последовательности

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

Рисунок 4.3 — Диаграмма последовательности для прецедента «Добавить статью»

Рисунок 4.4 — Диаграмма последовательности для прецедента «Добавить статью» (продолжение)

4.6 Диаграмма деятельности

В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. Отдельные элементарные вычисления, приводящие к некоторому результату, называют действием (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате осуществления деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения. На рисунке 4.5 представлена диаграмма деятельности да прецедента «Добавить статью» .

Рисунок 4.5 — Диаграмма деятельности для прецедента «Добавить статью»

4.7 Модель базы данных Логическая и физическая модели базы данных представлены на рисунках 4.6−4.7.

Рисунок 4.6 — Концептуальная модель базы данных Рисунок 4.7 — Физическая модель базы данных

5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

5.1 Сервер

В качестве сервера приложений, выбран web-сервер Apache. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете. По статистике Netcraft, в августе 2007 года он установлен на 51% всех веб-серверов, в марте 2009 года — на 49%.

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

5.2 Клиент

Клиенту для доступа к приложению необходимо иметь подключение к Интернету, Internet-браузер с предустановленным плагином для просмотра файлов формате *.pdf. Персональный компьютер: Intel Celeron 1,3 GHz, 256 Mb, HDD — 80 Gb.

5.3 Обмен данными

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

На рисунке 6.1 представлен общий принцип построения html-страницы. Пользователь посылает запрос на сервер. На стороне сервера запрос принимает программа web-сервера и анализирует запрос. На первом этапе выбирается информация из базы данных о странице, какой шаблон относится к данной странице, ее название, уровень вложенности, шаблон, из которого строится страница и т. д. Далее формируется запрос на получение информации о шаблоне странице, а точнее, из каких блоков он состоит. В обработанном запросе содержится информация о блоках и об их обработчиках. Если блоки состоят из шаблонов, то процесс повторяется. Далее выполняются обработчики шаблона, после их выполнения формируется страница. По завершении работы Apache передает сгенерированную страницу web-серверу, который отсылает ее обратно на машину клиента как результат обработки его запроса.

Рисунок 5.1 — Процесс построения html-страниц на сайте

5.4 Система управления сайтом

Для управления содержимым сайта использовано готовое интернет-решение «SEO CMS», которое:

· обеспечивает редактирование содержимого сайта;

· обеспечивает управление правами доступа к разделам сайта.

5.5 Описание разделов сайта

На рис. 6.2 представлена главная страница сайта «Сибирского медицинского журнала», которая содержит следующие функциональные элементы:

· навигационное меню по разделам сайта;

· блок «Поиск» ;

· блок «Авторизация» ;

· модуль «Линейка фотографий» ;

· графический элемент «Скачать свежий номер» ;

· блок «Рубрики» ;

· блок «Обращение главного редактора» ;

· блок «Карта сайта» .

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

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

Все номера журнала предоставляются в свободном доступе, и для того чтобы сохранить журнал в формате *.pdf на свой жесткий диск посетителю сайта достаточно нажать на графический элемент «Скачать свежий номер» .

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

Рисунок 5.2 — Главная страница сайта Для того чтобы подать заявку на публикацию в журнале посетителю сайта необходимо зарегистрироваться, заполнив специальную форму (рис. 5.3).

Рисунок 5.3 — Форма регистрации Раздел «О журнале»

Раздел «О журнале» состоит из шести информационных подразделов, заполняемых администратором сайта (рис 6.4):

· «Из истории» ;

· «Положение о журнале» ;

· «Редакционная коллегия» ;

· «Учредители» ;

· «Партнеры» ;

· «Подписка» .

Рисунок 5.4 — Подразделы раздела «О журнале»

Раздел «Авторам»

На сайте создан специальный раздел для размещения информации актуальной для авторов журнала (рис 6.5). Данный раздел включает восемь подразделов:

· «Условия публикации» ;

· «Правила оформления статей» ;

· «Образцы документов» ;

· «Реквизиты для оплаты публикаций» ;

· «Авторские права» ;

· «Наши авторы» ;

· «Услуги» ;

· «Полезные ссылки» .

Раздел «Редакция»

Чтобы получить информацию о редакционно-издательской группе, посетитель сайта может воспользоваться разделом «Редакция» (рис. 5.6)

Рисунок 5.5 — Подразделы раздела «Авторам»

Рисунок 5.6 — Подразделы раздела «Редакция»

Раздел «Новости»

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

Рисунок 5.7 — Раздел новости Раздел «Архив»

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

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

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

Согласно условиям поиска делается запрос в БД для выборки результатов поиска. Если запрос вернул пустое значение — результатов, удовлетворяющим условиям поиска не найдено — пользователю выдается сообщение, в противном случае — пользователю предоставляются результаты поиска.

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

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

Рисунок 5.8 — Форма поиска по архиву журнала Нажав на название статьи в результатах поиска, посетитель сайта переходит к странице статьи, которая включает в себя название статьи, аннотацию и список авторов (рис. 6.9). Кроме того, читали журнала имеют возможность выразить свое мнение, оставив комментарий.

Рисунок 5.9 — Страница статьи журнала Личный кабинет зарегистрированного пользователя

Для того чтобы войти в личный кабинет (рис. 6.10), посетитель сайта должен авторизоваться, т. е. в форме авторизации указать свой адрес электронный почты и пароль, после чего нажать кнопку «Войти». Скрипт проверяет: существует ли такая пара логин-пароль в таблице пользователей, если такой пользователь найден — то он авторизуется в системе, в противном случае система перенаправляет пользователя на страницу авторизации, где ему выдается информационное сообщение об ошибки авторизации.

Навигационное меню личного кабинета пользователя включает следующие пункты:

· «Мой профиль» (рис. 6.10);

· «Подать заявку» (рис. 6.11);

· «Мои заявки» ;

· «Выйти» .

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