Размещено на http://www.allbest.ru/

Введение

Правительством Российской Федерации в августе 2009 г. утверждена «Стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года» [1] (далее Стратегия), а в январе 2015 г.федеральная целевая программа «Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы»[2] (далее Целевая программа). Одной из основных целей этих документов является создание условий, обеспечивающих возможность гражданам систематически заниматься физической культурой и спортом. К числу основных задач, требующих решения для достижения поставленной цели, относятся:

1) создание новой национальной системы физкультурно-спортивного воспитания населения;

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

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

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

Ростовский-на-Дону государственный экономический университет (РГЭУ (РИНХ)) традиционно значительное внимание в свой деятельности уделяет как массовому спорту среди студентов вуза, так и подготовке спортсменов высокого класса и спортивного резерва из числа своих студентов. Сайт университета[3] имеет достаточно информационно наполненный раздел, посвященный деятельности управления по физической культуре и спорту университета (управления ФКИС), который включает как информацию о деятельности кафедры физкультуры, так и о деятельности подразделений, непосредственно выполняющих рекомендации Стратегии: наличие спортивных клубов, баз активного отдыха.

Актуальность реализации дополнительных информационных сервисов по вопросам физической культуры и спорта для РГЭУ (РИНХ) связана с необходимостью оптимизации работы кафедры физкультуры и управления ФКИС.

Целью дипломного проекта является разработка информационных сервисов, обеспечивающих оптимизацию работы кафедры физкультуры и управления ФКИС.

Для достижения поставленной цели необходимо решить следующие задачи:

– провести обследование предметной области;

– построить модель предметной области «как есть» и выявить существующие недостатки;

– построить модель «как будет» и предложить рекомендации модернизации системы управления ФИКС на базе внедрения информационных сервисов;

– разработать базу данных (БД), обеспечивающую поддержку информационных сервисов;

– разработать сервисы;

– провести отладку системы;

– провести оценку эффективности принятых решений, и реализованных сервисов.



1. Описание предметной области

архитектура интерфейс надежность информатизация

1.1 Анализ российской законодательной базы по проблемам информатизации физкультурно-спортивного воспитания населения

Значительное внимание в российском законодательстве уделяется вопросам физкультурно-спортивного воспитания населения. Целый ряд документов связан с развитием законодательства по вопросам спорта [1-3]. Разработана стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года [1], в 2015 планировалось принятие федеральной целевой программы "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы" [2].

Ключевым законодательным актом РФ, определяющим политику государства в области физической культуры, стал федеральный закон (ФЗ) "О физической культуре и спорте в Российской Федерации" [3]. Одним из важнейших направлений работы закон называет формирование физической культуры студентов и молодежи, требования по организации физического воспитания и образования в образовательных учреждениях представлены в статье 28. Сюда входит как проведение обязательных занятий физической культурой и спортом в пределах основных образовательных программ, так и:

– проведение медицинского контроля организации физического воспитания;

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

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

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

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

Проблемы внедрения информационных технологий непосредственно на кафедрах физкультуры российских вузов практически не получили развития. Как указывается в работе [4]отсутствует даже общепринятая классификация информационных технологий в спорте. В данной работе предлагается классифицировать их по следующим показателям:

– классификация по функциям;

– классификация по методам;

– классификация по этапам учебно-тренировочного процесса;

– классификация по предлагаемым населению услугам;

– по видам подготовки в сфере физической культуры и спорта.

В работе Журавлева В.А. и Ананьин В.Г. [5] сделана попытка систематизировать использование информационных технологий в отрасли "Физическая культура и спорт" в целом. Этими направлениями являются: учебный процесс, спортивная тренировка, спортивные соревнования, оздоровительная физическая культура, спортивный менеджмент и регуляция кадрового потенциала отрасли.

Традиционно информационная поддержка кафедр физической культуры ВУЗами осуществляется путем представления информации об их деятельности в рамках сайта ВУЗа. Были рассмотрены информационные ресурсы кафедр физкультуры РГЭУ (РИНХ) [6], ДГТУ [7] и РостГМУ[8]. На основании материалов этих сайтов можно сказать, что ВУЗы в основном ограничиваются минимальными данными о профессорско-преподавательском составе кафедр, о спортивных секциях и клубах с предоставлением уставных документов этих подразделений.

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

1.2 Анализ предметной области

Проведем анализ необходимого программного обеспечения и информационных ресурсов на основе анализа деятельности кафедры физкультуры РГЭУ (РИНХ) и управления по физической культуре и спорту (УФК и С).

Анализ проводится на основе объектно-ориентированной методологии. Объектно-ориентированный анализ - это методология, при которой требования к системе формируются на основе понятий классов и объектов, выявленных в предметной области.

Главными достоинствами объектно-ориентированной методологии являются:

– возможность преодолеть ограничения, связанные со сложностью разрабатываемых систем;

– использование на стадии анализа моделей близких к реальности;

– возможность применения как при анализе и проектировании информационных систем, так и систем реального времени и аппаратно-программных комплексов;

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

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

– естественная работа с разнородной информацией, используемой в мультимедиа системах;

– создание более открытых систем;

– полное использование описательных возможностей объектно-ориентированных языков программирования.

В состав РГЭУ (РИНХ) кроме головного ВУЗа входят 8 филиалов и Таганрогском институт имени А. П. Чехова, а также финансово-экономический колледж.

В РГЭУ (РИНХ) создано УФК и С, организационная структура которого представлена на рис. 1.1 по материалам сайта РИНХ [3]. УФК и С подчинено первому проректору по учебной работе. Руководство управлением осуществляется начальником управления через коллегиальным орган - совет по спортивно-оздоровительной работе. Функциями УФК и С являются [9]:

– руководство спортивно-оздоровительной работой Университета;

– контроль работы кафедр физического воспитания, спорта и туризма(ФВ,СиТ) РГЭУ(РИНХ), финансового колледжа

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

– координация работы кабинета врачебно-спортивного контроля.

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



Рис. 1.1 - Организационная схема управления по УФК иС

Деятельность кафедр физического воспитания РГЭУ (РИНХ) строится на основе приказа Госкомвуза РФ от 26.06.1994 № 777 «Об организации процесса физического воспитания в высших учебных заведениях» [11]. На базе этого документа разработана объектная модель ролей кафедры физкультуры, представленная на рисунке 1.2.

Базовой сущностью модели является роль - Сотрудник каф. физкультуры. От него унаследованы роли: Преподаватель, Учебно-вспомогательный персонал, Зав. кафедрой. Роли описывающие деятельность сотрудников, ответственных по профилям работы кафедры, наследуют свойства роли Преподаватель. Это:

– Ответственный за научную и учебно-методическую работу;

– Ответственный по физическому воспитанию;

– Ответственный по виду спорта;

– Ответственный за массовую оздоровительную работу;

– Ответственный за учебную работу.

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



Рис. 1.2 - Модель сотрудников кафедры физкультуры

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

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

– проведение теоретических и практических учебных занятий со студентами в установленном объеме;

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

– руководство научной и научно-методической работой преподавателей кафедры;

– организацию работы по повышению квалификации преподавателей с отрывом и без отрыва от учебного процесса;

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

– составление расчетов и смет по штатному, финансовому и материальному обеспечению работы по физическому воспитанию;

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

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

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

– составление отчетов о работе кафедры;

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

Диаграмма вариантов использования для деятельности рольаЗав. кафедрой представлена на рисунке 1.3.

2. Преподавательский состав кафедры осуществляет:

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

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

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



Рис. 1.3 - Модель деятельности заведующего кафедрой физкультуры

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

– систематическую работу по повышению своего профессионального уровня;

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

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

– подготовку спортивных команд и повышение мастерства студентов-спортсменов, руководство ими в процессе спортивных соревнований;

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

– ежегодное составление индивидуальных планов и отчетов об их выполнении;

– другие виды работ, связанные с физическим воспитанием студентов.

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

Диаграмма вариантов использования деятельности роли Преподаватель представлена на рисунке 1.4.

Рис. 1.4 - Модель деятельности преподавателя кафедры физкультуры

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

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

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

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

– анализ качества и эффективности учебной работы, обобщение и внедрение передового опыта по совершенствованию учебно-воспитательного процесса;

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

– распределение почасового фонда, контроль за его расходованием;

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

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

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

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

– разработку и проведение мероприятий по предупреждению спортивного травматизма на учебных занятиях;

– составление отчета кафедры по разделу учебной работы.

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

4. Преподаватель, ответственный за научную и учебно-методическую работу (заместитель зав. кафедрой), проводит следующую работу:

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

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

– разработку и обоснование содержания и методики профессиональной прикладной физической подготовки студентов;

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

– организацию и проведение на кафедре научных конференций;

– обсуждение на кафедре новой учебно-теоретической литературы;

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

Рис. 1.5 - Модель деятельности ответственного за учебную работу

– контроль и оказание помощи в работе методического кабинета и научной лаборатории при кафедре;

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

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

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

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

– контроль за совершенствованием спортивного мастерства студентов-спортсменов высокой квалификации;

– планирование, организацию и проведение в вузе массовых оздоровительных и спортивных мероприятий среди студентов;

– проведение спортивных соревнований внутри вуза и руководство спортивными командами на внешних соревнованиях;

– развитие в вузе массового туризма, организацию и контроль за проведением туристских походов, слетов;

Рис. 1.6 - Модель деятельности ответственного за научную и учебно-методическую работу

– проведение анализа спортивной работы, обобщение и распространение в вузе передового опыта физкультурной и спортивной работы;

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

– составление отчета кафедры по разделу массовой оздоровительной, физкультурной и спортивной работы.

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

6. Преподаватели, ответственные за работу в учебных отделениях (по виду спорта и виду занятий), обеспечивают:

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

– контроль за успеваемостью студентов-спортсменов на факультетах;

– составление отчета о работе, проделанной по видам спорта (видам занятий).

Диаграмма вариантов использования деятельности роли Ответственный за виды спорта представлена на рисунке 1.8.

Рис. 1.7 - Модель деятельности ответственного за массовую оздоровительную работу

7. Преподаватель, ответственный за работу по физическому воспитанию на факультете (заместителя декана по физическому воспитанию), входит:

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

– контроль за качеством и эффективностью учебного процесса по физическому воспитанию на факультете;

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

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

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

– проведение на факультете работы по наглядной агитации и пропаганде физической культуры и спорта;

Рис. 1.8 - Модель деятельности ответственного за работу в учебных отделениях

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

– составление отчета о работе по физическому воспитанию на факультете.

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



Рис. 1.9 - Модель деятельности ответственного за работу по физическому воспитанию

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

Информационные технологии управления учебным процессом в РГЭУ (РИНХ) включают следующие: ИС «Контингент», подсистема «Успеваемость», программный комплекс электронного расписания занятий, подсистема «Электронная ведомость». Данные программные продукты не охватывают бизнес процессы, связанные с подсистемой Оздоровительной и массовой работы. Как показано выше, общевузовская система автоматизации не учитывает специфику функций кафедры физкультуры в части проведения тренировок и соревнований, как видов учебного процесса, а также учета физического состояния студентов в ходе обучения. На рисунке 1.10 представлена подсистема Учебная работа, обеспечивающая тематику кафедры. В результате выполнения дипломного проекта необходимо реализовать сервис «Учебный процесс кафедры физкультуры», обеспечивающий реализацию и внедрение данной подсистемы.



Рисунок 1.10 - Подсистемы деятельности кафедры физкультуры

1.3 Сбор и моделирование требований

Сбор требований - один из основных этапов анализа системы, обеспечивающий успешную реализацию проекта [12, 13]. Результатом проведения сбора требований служит техническое задание (ТЗ) на проект.

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

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

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

1.3.1 Описание использования системы

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

– Обеспечение учебно-тренировочного процесса;

– Контроль за проведением профессионально-прикладной физической подготовки;

– Контроль замедицинским обследованием студентов;

– Комплектование групп;

– Учет результатов медицинского освидетельствования студентов;

– Анализ динамики состояния здоровья, физического развития и физической подготовленности;

– Разработка комплексов упражнений;

– Контроль перемещений студентов.

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

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

Рисунок 1.11 - Диаграмма вариантов использования сервиса Учебная работа обеспечивающая тематику кафедры



Рисунок 1.12 - Диаграмма вариантов использования ролиСтудент

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

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



Рисунок 1.13 - Диаграмма вариантов использования подсистемы Администрирование

1.3.2 Определение терминов для описания требований

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

– Гость;

– Администратор;

– Преподаватель;

– Студент.

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

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

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

– Группа учебная,

– Группа по физкультуре.

Свойства перечисленных сущностей связаны перечнями:

– Специальность,

– Должность,

– Тип обучения.

1.3.3 Отображение рабочего процесса между пользователями и системой

Для отображения рабочего процесса между разными вариантами использования можно использовать диаграмму деятельности. На этой диаграмме отображается рабочий процесс выполнения деятельности. Так, например, представим диаграмму деятельности для выполнения прецедента «Назначить студента в группу», входящего в вариант использования показанный на рисунке 1.13, (см. рисунок 1.14). На данной диаграмме показаны потоки данных между действиями, в данном случае идентификаторы сущностей учебная и физкультурная группы, а также идентификатор сущности студент.

Рисунок 1.14 - Диаграмма деятельности прецедента «Назначить студента в группу»

1.4 Спецификация требований

В приложении А представлено техническое задание (ТЗ) на реализацию сервиса поддержки учебного и воспитательного процесса кафедры физкультуры.

Данное ТЗ разработано на основе предположения, что реализация сервиса будет происходить в несколько этапов. На первом этапе разрабатывается:

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

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

– карта сервиса,

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

Выводы

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

На базе объектно-ориентированного подхода проведен анализ предметной области деятельности кафедры ФК,СиТ РГЭУ (РИНХ). Выявлены основные требования к сервису поддержки работы кафедры. Определены основные подсистемы сервиса и выявлены его пользователи.

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



2. Проектирование и разработка сервиса учебного процесса кафедры физкультуры

2.1 Архитектура сервиса

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

– Представление преподавателя;

– Представление студента;

– Представление администратора.

Рисунок 2.1 - Концептуальная архитектура сервиса учебного процесса кафедры физкультуры

Современное Web-приложение основывается на технологии "клиент-сервер". Таким образом, его архитектура расширяется до трехуровневой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, а на промежуточном уровне размещаются Web-сервер и модули расширения сервера. Модуль расширения сервера выступает преобразователем протоколов между клиент-серверным приложением БД и Web-сервером. Структура приложения представлена на рисунке 2.2.



Рисунок 2.2 - Базовая архитектура трехуровневогоWeb-приложения

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

- Apache HTTP-сервер - кроссплатформенное ПО, поддерживаемое операционными системами Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS - 57,93% серверов;

- NginxHTTP-сервер -сервер, работающий на Unix-подобных операционных системах, с версии 0.7.52 появилась бинарная сборка под Microsoft Windows - 12,18%серверов;

- IIS (Internet Information Services) - набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT - 12,14%.

Для реализации сервиса учебного процесса кафедры физкультуры выбран сервер IIS 7.0с операционной системой WindowsServer 2008 R2.IIS 7.0 поставляется вместе с библиотекой .NET Framework.

Шаблоном архитектуры программного обеспечения выбрана технология MVC .Net. Данный паттерн обеспечивает разделение данных, логики и интерфейса (см. рис. 2.3):

– Model - часть приложения, содержащая в себе бизнес-логику, описывающую предметную область. Модель знает, как устроены данные и как с ними работать;

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

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

Рис. 2.3- Структура шаблона MVC

2.2 Проектирование интерфейса

Уровень представления Web-приложения критически важен при разработке системы и оказывает значительное влияние на степень принятия приложения пользователями. Уровень представления - это своего рода «парадная дверь» в приложение. Он обеспечивает выполнение бизнес-функций, представляемых приложением пользователям, а также визуальное представление информации, которой управляет приложение. Эффективность пользовательского интерфейса значительно влияет на успех приложения в целом [20].

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

Производительность - главное требованием к Web-приложению. Максимальное время выполнения операций не должно превышать 3-10 с.

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

2. Интерактивность и широкие возможности. Пользовательский интерфейс должен быть интерактивным и отзывчивым. Кроме того, уровень представления должен быть обогащенный в визуальном смысле, включая диаграммы, drag-and-drop компоненты, ползунки для изменения данных, интерфейс в виде панелей и т.п.

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

Для структуры макета сервиса Учебная работа кафедры ФВ,СиТбыла принята концепция «резинового» макета, который подразумевает информация будет занимать пространство, подстраиваясь под разрешение. Используется решение с адаптивным web-дизайном, когда определены основные разрешения (размеры экрана), под которые адаптируется контент.

Структура макета главной страницы сервиса для мониторов с большим разрешением, представлена на рисунке 2.4. Макет включает области заголовка (heder), навигации (sidebar), контента страницы (content) и нижнего колонтитула (footer). Для главной страницы введено понятие максимальной ширины в 1280 пикселов, что обусловлено удобством восприятия информации на больших мониторах. В этом случае информация не будет растягиваться так, что её неудобно будет читать.

Рисунок 2.4 - Структура макета главной страницы

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

Реализация структуры сайта приведена в листинге 2.1. При вёрстке сервиса использован блочный подход. Таблицы используются только для своей прямой роли - представление информации в виде таблицы.

Код HTML создаёт скелет страницы, её абстрактную модель при помощи тэгов (языка разметки HTML). При написании разметки прописываются классы и идентификаторы.



Рисунок 2.5 - Структура макета главной страницы для мобильных устройств

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

Листинг 2.1 показывает мастер-страницу _Layout.chtml. На вид это обычное представление за одним исключением - вызовов методов @RenderBody() и @RenderSection("featured", required: false). Эти два вызов является плейсхолдерами, на место которых другие представления, которые используют эту мастер-страницу, будут подставлять свое содержимое. И таким образом, мы можем легко установить для представлений веб-приложения единообразный стиль.



Листинг 2.1 - Реализация структуры проекта

2.3 Проектирование и разработка БД сервиса

При проектировании базы (БД) данных создаются два уровня модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире[19].

На рисунке 2.9 представлена концептуальная модель БД подсистемы администрирования сервиса. Ключевой сущностью модели является сущность Лицо, определяющая основные атрибуты пользователей системы различных категорий. С этой сущностью связаны справочники Паспорт и Пол (отношение один ко многим). Категории пользователей системы задаются сущностями Студент и Преподаватель, которые связаны с сущностью Лицо отношением один к одному. Сущность Студент связана с сущностями Специальность и Тип обучения отношением один ко многим. Отношение между сущностями Студент и Группа - многие ко многим. Это связано с тем, что одним из определяющих атрибутов сущности Группаявляется атрибут Курс, который для студента изменяется по времени обучения.

Представленные на рисунке 2.9 сущности UserProfile, webpages_Rolesи webpages_Membership определяют роль пользователя системы, справочник ролей (Гость, Студент, Преподаватель или Администратор) и параметры входа пользователя в систему. Данные сущности создаются автоматически при использовании шаблона приложения MVC в среде VisualStudio.

Рис. 2.9 - Концептуальная модель БД подсистемы администрирования

Разработка модели БД проводилась средствами MSVisualStudio2013 с использованием на модели ADO.NetEDM[22]. Данная модель - это модель "сущность-связь" - Entity Data Model (EDM), описанная Питером Ченом в 1976 году. Данная модель представляет собой набор основных понятий, которые описывают структуру данных независимо от формы хранения.

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

В следующем списке описаны средства, входящие в состав средств для работы с моделями EDM.

1. Конструктор моделей EDM ADO.NET (конструктор сущностей) позволяет с помощью визуальных средств создавать и изменять сущности, ассоциации, сопоставления и связи наследования. Конструктор сущностей также формирует код уровня объекта на языке C# или Visual Basic.

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

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

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

На основе концептуальной модели создана БД проекта, реализованная в MSSQLServer 2008 R2. Структура и связи таблиц представлены рисунке 2.10.



Рисунок 2.10 - Структура таблиц подсистемы администрирования

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

2.4 Структура проекта

Web-сервис разрабатывается в VisualStudio 2013, как проектSportEducation. Разработка проекта осуществлялась на основе мастера Веб-приложение ASP.NetMVC 4. На рисунке 2.11 представлена страница выбора данной категории проекта. На рисунке 2.12 представлен выбор шаблона проекта: Интернет-приложение на базе обработчика представлений Razorс созданием проекта разработки модульных тестов - SportEducation.Tests.

Полученная структура проекта представлена на рисунке 2.13.



Рис. 2.11. - Открытие шаблона создания проекта SportEducation

Рис. 2.12. - Открытие шаблона создания проекта SportEducation

Рис. 2.13. Структура проекта SportEducation

Данный проект, как и все проекты MVC содержит следующие папки: App_Data, Content, Controllers, Models, Scripts и Views.В дополнение к данным папкам сгенерированное веб-приложение MVC использует код в файле Global.asax для установки глобальных параметров маршрутизации URL-адресов по умолчанию, а также использует файл Web.config для настройки приложения.

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

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

Controllers -- папка для рекомендуемого расположенияконтроллеров. Имена контроллеров в платформе MVC должны оканчиваться на "Controller", например HomeController, LoginController или ProductController.

Models -- предназначена для классов, которые представляют модель приложения для веб-приложения MVC. Эта папка обычно содержит код, который определяет объекты и логику взаимодействия с хранилищем данных. Сами объекты модели обычно располагаются в отдельных библиотеках классов. Тем не менее, при создании нового приложения классы можно расположить в этой папке, чтобы переместить их в отдельные библиотеки на более поздней стадии разработки.

Scripts -- рекомендуемое расположение для файлов скриптов, поддерживающих приложение. Эта папка по умолчанию содержит файлы платформы ASP.NET Ajax и библиотеку jQuery.

Views -- рекомендуемое расположение для представлений. Представления используют файлы ViewPage (ASPX), ViewUserControl (ASCX) и ViewMasterPage (MASTER) в дополнение к остальным файлам, которые связаны с отображением представлений. Папка Views содержит папки для всех контроллеров. Название папки состоит из префикса имени контроллера. Например, если существует контроллер с именем HomeController, то в папке Views будет вложенная папка с именем Home. При загрузке представления платформой ASP.NET MVC в папке "Views\имя_контроллера" по умолчанию выполняется поиск файла ViewPage (ASPX), который имеет имя требуемого представления. По умолчанию в папке Views находится папка Shared, которая не соответствует ни одному контроллеру. Папка Shared используется для представлений, которые используются на нескольких контроллерах. Например, главную страницу веб-приложения можно поместить в папку Shared.

2.5 Клиентская часть

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

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

Как указывалось в подразделе 2.2 вызов плейсхолдера на MasterPage обеспечивает загрузку различных представлений и поддерживает единообразие стиля страниц Web-приложения. На рисунке 2.14 представлена структура файлов-представлений для контроллеров поддерживающих реализацию функционала Web-приложения, расположенных в папке Views.

На рисунке показаны файлы представления для контроллеров: AccountController, ПользователиController, а также содержимое папки Shared, содержащей компоновки и представления, не являющиеся специфичными для какого-либо контроллера. Представления контроллера Account Controller обеспечивают ввод, изменение логина, авторизацию и регистрацию пользователя. Представления контроллера Пользователи Controller обеспечивают создание, удаление пользователя, редактирование его свойств, просмотр списка пользователей.

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

Рис. 2.14. Структура файлов приложений проекта SportEducation

Рис. 2.15. Внешний вид страницы регистрации пользователя

2.6 Организация взаимодействия с БД

Как указывалось в разделе 2.3 взаимодействие с источником данных MVCприложения базируется на модели EDM. Модель EDM представляет набор основных понятий, которые описывают структуру данных независимо от формы хранения. Данные Web-сервиса хранятся на SQLServer.В результате такого подхода, форма хранения данных отделена от приложения и не влияет на его разработку. Это обеспечивается тем, что сущности и связи описывают структуру данных так, как она используется в приложении. Модель EDM использует три основных понятия для описания структуры данных:

– тип сущности;

– тип ассоциации;

– свойство.

Структура концептуальной модели передаётся при помощи доменного языка (DSL).Платформа ADO.NET Entity Framework использует язык DSL на основе XML, называемый языком CSDL, для определения концептуальных моделей. Файл метаданных концептуальной модели представлен в Приложении В.

Структура модели данных представлена на рисунке 2.16.

В проекте автоматически сгенерируется классe nterprise _order Entities1, который наследуется от класса Object Context, представляет сущности базы данных Sport Education, содержит свойства, моделирующие таблицы и связи между таблицами.

При создании модели данных в проекте автоматически сгенерирован конфигурационный файл Web.config, который содержит строку соединения с базой данных (см. листинг 2.2).

Листинг 2.2 - Код для строк соединения с базой данных



Рис. 2.16 Структура модели данных

2.7 Развертывание сервиса

Завершающим и критически важным шагом разработки веб-приложений является развертывание. Рассмотрим развертывание приложения SportEducation.

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

– на машине Windows Server с Internet Information Services (IIS), что предполагает локальное управление,

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

– в облачной инфраструктуре, обеспечивающей работу и масштабирование приложения.

Тестовая версия разработанного Web-сервиса была размещена на виртуальном сервере (VPS) компании InfoBox. WindowsVPSсервера данной компании располагаются в Амстердаме и Санкт-Петербурге, имеют архитектуру на быстрых SSD (сверхпроизводительных твердотельных накопителях), имеют минимальный ping до городов России и СНГ. На серверах устанавливается лицензионная ОС WindowsServer. НаVPSустановлена ОС WindowsServer 2012 r2, веб-сервер IIS 7.0, СУБД MSSQLServer 2008 r2.

Управление данным сервером осуществляется через удаленный рабочий стол.

Web-сервис публикуется на веб-сервере IIS. Вначале осуществляется конфигурирование веб-сервер. Для этого открывается средство администрирования IIS. Необходимо зайти в Панель управления, затем выбрать Администрирование->Диспетчер служб IIS. Откроется консоль управления IIS, представленная на рисунке 2.17.

Рис. 2.17. Консольуправления IIS

Вначале происходит настройка пула приложений. Для этого вызывается функция добавления пула приложений, как показано на рисунке 2.18. В окне добавления пула приложений указывается имя Web-приложения и версия среды .NetFrameWork. Для устанавливаемого Web-сервиса это .NetFrameWork версии 4.0.



Рис. 2.18. Добавление пула приложений

Следующим шагом является добавление сайта SportEducation, как показано на рисунке 2.19.

Рис. 2.19. Добавление нового Web-приложения

После введения параметров нового Web-приложения можно переходить к опубликованию приложения в VisualStudio. Для этого необходимо нажать правой кнопкой на название проекта и в появившемся меню выбрать Опубликовать, как показано на рисунке 2.20.

Рис. 2.20. Выбор меню Опубликовать



Открывается мастер публикации, который предложит пройти несколько этапов. Вначале выбираем профиль, как представлено на рисунке 2.21. Так как профиль новый, то определяем имя профиля. В нашем случае публикация осуществляется в локальной системе и, лишь, потом папка с опубликованными файлами переносится на удаленный сервер. Поэтом далее осуществляем выбор или создание папки для размещения файлов. На диске C:// создаём папку SportEducation (см. рис. 2.22).

На вкладке Подключение определяем тип подключения как файловую систему и указываем целевое назначение (см. рис. 2.23). На рисунке 2.24 показан последний шаг - это просмотр полученных файлов в созданной папке.

Рис. 2.21. Выбор профиля публикации

Рис. 2.22. Создание папки для размещения публикуемых файлов



Рис. 2.23. Определение типа размещения файлов

Рис. 2.24. Просмотр содержимого подключения

Папка с полученными файлами переносится на виртуальный сервер.

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

Выводы

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