Содержание к диссертации
Введение
Глава 1. Архитектура систем управления обучением 11
1Л Обзор систем дистанционного обучения (СДО) 11
І Л Л История появления и развития СДО 11
1.1.2 Обзор современных СДО 14
1.L3 Сравнение СДО 17
1.2 Инструментальные средства проектирования программного обеспечения 19
1.2Л Определение программной архитектуры 19
1.2.2 Средства описания программной архитектуры 20
1.2.2.1 Архитектурные стили 21
1.2.2.2 Формальные методы моделирования 21
1.2.2.3 Языки описания архитектуры 22
1.2.2.4 Среде гва визуального моделирования 23
1.2.3 Унифицированный Язык Моделирования UML 25
1.2.3 Л Виды диаграмм UML 26
1.2.3.2 Диаграмма классов 27
1.2.3.3 Диаграмма вариантов использования 28
1.2.3.4 Диаграмма активностей 28
1.2.3.5 Дишрамма последовательности 29
1.2.3.6 Диаграмма размещения 30
1.2.37 Преимущества использования UML 30
1.3 Многоуровневая архитектура кл ист-серверных приложений 32
1.3.1 Урокни абстракции приложения 32
1.3.2 Тины клиент-серверных приложений 33
1.3.3 Технологии реализации логических уровней 35
Глава 2. Решение практических задач с помощью шаблонов проектирования 39
2.1 Задача построения модели данных 42
2Л.1 Шаблон Data Access Object 42
2,1.2 Шаблон Transfer Object 44
2.1.3 Шаблон Generic Attributes Access 45
2.1.4 Шаблон Abstract Factory 46
2Л.5 Реализация модели данных 48
2.L5.1 Класс первичного ключа Id 48
2.1.5.2 Класс Model 50
2.1.5.3 Класс DalaStructure 53
2.1.5.4 Класс Field 54
2.L5.5 Класс Details - значение объекта 57
2Л.5.6 Класс DetailsList-коллекция деталей 60
2.1,57 Класс Validator и DefauhValidator 60
2.1.5.8 Класс Factory 60
2Л.5.9 Класс SQLFactory для работы с базой данных 6J
2Л.5Л0 Пример создания модели 63
2.2 Задача автоматизации выполнения операций 65
2,2Л Шаблон Command 65
2.2.2 Реализация операций , 66
2.2.3 Контроль над выполнением операций в системе безопасности 70
2.3 Задача представления данных, независимого от клиентской платформы 71
2.3Л Шаблон Model View Controller 71
2,3.2 Реализация с помощью технологии Maverick 72
2.4 Задача представления больших .массивов данных 73
2.4Л Метод асинхронного представления данных 74
2.4.2 Реализация с помощью технологий AJAX 75
Глава 3, Логическая модель системы дистанционного обучения 77
ЗЛ Назначение 77
3.2 Функциональные блоки 80
33 Платформа Competentum 81
3.3 1 Цели создания платформы 81
3.3.2 Архитектура платформы 82
3.3.3 Преимущества платформы 84
3.3.4 Связь с платформы с системой Competentum.Instructor 86
3.4 Объеоная модель системы 88
3.4.1 Структура задания , 88
3.4 Л Л Класс AbstraclQucslion 90
3.4.1,2 Выбор варианта ответа. Класс Choice 91
3.4.1.3 Сортировка. Класс Sorting 93
3.4Л .4 Ввод строки. Класс StringAnswer 94
3.4Л.5 Ввод числа. Класс ValueAnswer 94
ЗА 1,6 Свободный ответ. Класс FreeAnswcr 96
3.4Л.7 Ответ к заданию. Класс Answer 96
3,4Л,8 Оценка задания. Класс Grade 97
ЗА 1,9 Структура вопроса в БД. Класс QueslionDefinitionModel 98
3.4.2 Представление заданий в формате XML 98
ЗАЗ Реализация методов SCORM 2004 99
3.4.4 Метод реляционного храпения XML-документов 103
3.5 Автоматизация тестирования на основе шаблонов тестов 104
3.5Л Области определения и экземпляров 105
3.5.2 Шаблон теста. Класс TestDefmitionModel 106
3.5.3 Экземпляр теста. Класс TestAssignmentModel 110
3.6 Модель организационной структуры 112
Глава 4. Автоматизация образовательных процессов 115
4Л Создание и изменение учебного документа. Контроль версий 115
4.2 Создание задания 119
4.3 Создание и назначение теста 119
4.4 Прохождение теста 121
Глава 5. Техническая реализация приложения 123
5Л Аппаратная структура системы 123
5.2 Нагрузочное тестирование 125
5.3 Внедрения результатов работы 128
5.3.1 Мр.Доорз Хоум Декор Инк 129
5.3.2 Новокузнецкий металлургический комбинат 130
5.3.3 ООО Физикой 131
5.3.4 Международный институт менеджмента ЛИНК 131
53.5 Награды продукта Compctentum. Instructor 132
Заключение 133
Список использованных источников
- Инструментальные средства проектирования программного обеспечения
- Шаблон Generic Attributes Access
- Цели создания платформы
- Создание и назначение теста
Введение к работе
В современном мире, когда динамично развиваются технологии, каждый день появляются новые изделия и изобретения, все большее значение имеют знания и информация. Знания представляют важнейшую ценность как для отдельно взятого человека, так и для крупной организации. Чтобы не отставать от конкурентов компании необходимо постоянно развиваться, получать и анализировать новую информацию, адаптироваться к ситуации на рынке, В деятельность компании приходится вносить изменения: применять новые методы работы, внедрять эффективные современные технологии, выпускать новые продукты. Все эти изменения требуют изучения новой информации, постоянного повышения квалификации персонала, обучения его новым технологиям и методам работы, обращению со сложными современными инструментами. У каждого успешного предприятия есть свои уникальные особенности» которые создают ему конкурентные преимущества и позволяют ему быть востребованным. Эти особенности могут заключаться в организации процесса производства, работы с клиентами, применяемыми методами, и инструмент амн. В процессе работы организация годами накапливает ценнейший опыт, развивает и улучшает базу знаний, которые необходимо сохранить и использовать в будущем. Компании необходимо обучить сотрудников работать по своим правилам и методикам, использовать накопленную информацию, чтобы обеспечить максимально эффективную функциональность. Многие организации работают со сложным техническим оборудованием, специфическими программами, которые требуют специальных знаний. Иногда ошибка оператора может привести к серьезным последствиям, поставить под угрозу безопасность людей или принести компании существенные материальные убытки. При поступлении на работу компании необходимо обучить сотрудника всем необходимым навыкам и регулярно контролировать их уровень.
В связи с этим различные организации обращают все большее внимание на квалификацию персонала и ищут способы эффективного обучения своих сотрудников. Подготовка персонала - это длительный и дорогостоящий процесс, во время которого у обучаемого формируются необходимые знания и умения. Трудности в организации обучения сотрудников связаны с необходимостью овладевать большими объемами информации за короткий промежуток времени, а также необходимостью контроля качества обучения, знаний и умений при одновременном стремлении к снижению продолжительности и уменьшению затрат на организацию и проведение обучения,
Существуют разные способы обучения, имеющие свои особенности, преимущества и недостатки. Классическая очная форма обучения предусматривает занятия іруїшьі студентов с преподавателем. Для корпоративного обучения такая форма не всегда является удобной, поскольку предполагает физическое присутствие всех учащихся в одном месте и в одно время. Обучаемые сотрудники могут находиться в разных городах, работать в разные смены. Исторически заменой очной формы обучения служили другие способы построения учебного процесса, предусматривающие ограниченный прямой контакт между преподавателем и учащимися, например, заочное или вечернее образование. Такие формы обучения оставляют больше свободы учащемуся, однако являются менее эффективными, ч1о связано с нерегулярным и недостаточным объемом общения учащегося с преподавателем.
Сегодня широкое распространение получает дистанционная электронная форма обучения, во многом заменяющая заочную. Дистанционное обучение подразумевает получение знаний без очного посещения занятий, с помощью современных информационно-образовательных технологии и систем телекоммуникации, таких как электронная почта, Интернет. Дистанционное обучение можно использовать кале в академическом образовании, так и для корпоративного обучения, повышения квалификации и переподготовки специалистов. Учитывая территориальные особенности России и возрастающие потребности качественного образования в регионах, дистанционное обучение быстро развивается и занимает прочное место на рынке образовательных услуг. Использование современных компьютерных технологий открывает широкие возможности для обучения. Компьютер обеспечиваем удобный и быстрый дост\п к огромному количеству информации. С помощью современных компьютеров можно визуально продемонстрировать природные явления, моделировать сложное техническое оборудование. Использование технологий позволяет преподавателю применять инструменты, которые сложно реализовать физически.
Другим существенным преимуществом электронного обучения является автоматизация учебного процесса. Авшмаїизация процессов обучения и проверки знаний позволяет избавиться от большого количества бумажных документов, повышает прозрачность учебного центра, облегчает координацию действий, выполняемых преподавателями, учащимися, административными сотрудниками. Автоматизация позволяет выполнять работы и процесс в целом наиболее эффективнььм с точки зрения времени способом. Для большинства организаций, особенно коммерческих, решающими факторами при планировании обучении являются сроки и экономическая выгода. Дистанционное обучение позволяет существенно снизить затраты на повышение квалификации и
позволяет вести обучение быстро, предоставляя при этом большую свободу для управления временем, В последнее время организации все чаїне выбирают дистанционную форму для корпоративного обучения и повышения квапификаиии своих сотрудников. В связи с этим неуклонно растет интерес к системам дистанционного обучения.
В настоящее время разработано множество различных систем, предназначенных для автоматизации обучения- Системы дистанционного обучения отличаются функциональностью, производительностью, надежностью и безопасностью, удобством использования и множеством других факторов. Несмотря на наличие большого количества систем, направление автоматизации обучения бурно развивается. Разрабатываются новые системы, реализующие все большие функциональные требования и использующие новые научные и технологические достижения.
Решаемые проблемы
Организации, внедряющие систему дистанционного обучения, ставят перед ней разные задачи и имеют различные приоритеты. Для крупных компаний с большим количеством сотрудников важна надежность и производительность, для организаций, работающих с конфиденциальной информацией - безопасность, для географически распределенных компаний - удобная и надежная работа через Интернет с минимальной наїрузкой на сеть. Многие характеристики программного приложения зависят от технологической базы и принципов его построения, В связи с этим актуальна проблема выбора технологий и проектирования системы так, чтобы она наиболее эффективно реінала поставленные перед пей задачи.
Не существует универсальной системы:, удовлетворяющей всем требованиям. Вместе с этим, направление дистанционного обучения динамично развивается, и к системам представляются новые требования. Чтобы избежать устаревания, программный комплекс должен постоянно развиваться. Одной из основных трудностей на протяжении всей истории развития индустрии разработки программного обеспечения было неуклонное нарастание сложности создаваемых систем. Сложность систем приводит к трудоемкости их поддержки и развития, повышает вероятность неправильного построения, недостаточной или дублирующей функциональности. При разработке приложения важно построение удобной и непротиворечивой архитектурной модели, обеспечивающей возможности удобной поддержки и развития.
Целью дайной работы является исследование проблем и методов построения систем дистанционного обучения; исследование и решение задач проектирования системы;
построение и описание модели учебных объектов и процессов: разработка системы управления корпоративным обучением, удовлетворяющей современным требованиям; разработка эффективных методов развития системы. В работе поставлены и решены следующие задачи:
Анализ и описание с помощью средств UML архитектурной модели системы дистанционного обучения, предоставляющей возможности для расширения функциональности и развития системы.
Разработка на основе шаблонов проектирования технологий для решения ряда задач построения системы, таких как: построение модели данных, автоматизации и контроль выполнения операций, абстрагирование логики представления информации от технической платформы, динамическое представление больших массивов данных.
Разработка логической структуры образовательных сущностей, таких как задания различных типов и тесты. Разработка формата их представления на основе языка XML и механизма трансформации объектов системы в этот формат.
Разработка технологии автоматизации тестирования учащихся, основанной на использовании шаблонов тестов.
Формирование предложений по выбору технической (аппаратной) реализации систем дистанционного обучения.
Обзор публикаций
В течение последнего десятилетия появилось большое количество научных работ, посвященных проблемам проектирования сложных программных комплексов. Огромный вклад в развитие современных методов и средств проектирования программной архитектуры внесли американские ученые Гради Буч, Джеймс Рамбо и Ивар Якобсон, Г, Буч, главный исследователь корпорации Rational Software, с недавнего времени являющейся частью корпорации IBM, признан всем международным научным сообществом благодаря его основополагающим работам в области сбъектно-ориептироваппых методов и приложений. Он автор многих научных работ, посвященных объектно-ориентир о ванн ом у проектированию и разработке программных комплексов. [1] Г. Буч и его партеры являются авторами множества методик проекти роданид программных приложений и огромное количество публикаций на эту тему, В 1994 году они собрали и организовали набор методов проектирования и раїработали на их основе язык объектно-ориентированного моделирования UML. [2, 3]
Г, Буч также является одним из основоположников теории шаблонов проектирования. Работы, посвященные шаблонам проектирования, были впервые предложены около десяти лет назад, В настоящее время шаблоны проектирования - чрезвычайно актуальная тема в области разработки программного обеспечения. Работы в этом направлении ведутся множеством ученых и разработчиков по всему миру, [4]
Одними из самых важных работ в направлении исследования шаблонов проектирования являются труды Флойда Маринсску, посвященные применению шаблонов с использованием технологии EJB. Особое внимание в данных работах уделено методам проектирования логики доступа к данным. [5]
В связи с широким распространением дистанционного обучения возникли актуальные проблемы построения эффективных программных комплексов для автоматизации образовательной деятельности. Бьш проведен ряд открытых исследований и изучены возможности применения общих методов проектирования сложных систем в области образования. Один из наиболее интересных открытых проектов в этой области является Sakai, [6] Изначально исследованиями и разработкой в рамках проекта занималась группа ученых из ряда американских университетов, включающих Массачусетский Технологический Институт, Стэнфордский Университет, Университет Мичигана. Большой вклад в развитие методов моделирования учебных объектов внесли ученые из американской группы Advanced Distributed Learning (ADL), разработавшие международный стандарт SCORM, основанный па языке XML. [8] Данный стандарт содержит требования к организации учебного материала и всей системы дистанционного обучения, SCORM позволяет обеспечить совместимость компонентов и возможность их многократного использования в различных системах. Первая версия стандарта была предложена ь 2003 году. Через год вышла наиболее широко используемая сегодня версия SCOHM 2004.
Содержание работы
Работа состоит из пяти глав.
В главе 1 приводится обзор современных систем управления обучением, история их появления и развития. Подробно рассмотрен ряд наиболее известных российских и зарубежных систем, проведен анализ особенности их построения, преимуществ и недостатков- Рассматривается понятие архитектуры программных комплексов, способы описания архитектуры и проектирования программного обеспечения. Производится анализ и сравнение технических средств моделирования сложных систем и исследуется
целесообразность их применения в той или иной области, Подробно рассматривается язык
UML и его основные диаграммы, используемые в настоящей работе. Рассматриваются
различные методы построения приложений «клиент-сервер». Подробно описывается
многоуровневая архитектурная модель информационных систем и решение проблем
абстракции данных в райках этой модели.
Инструментальные средства проектирования программного обеспечения
Концепция программной архитектуры как отдельной дисциплины зародилась в начале 90х годов. Архитектура позиционировалась как связующее звено между технологиями и процессами. Под программной архитектурой подразумевают структуру и принципы взаимодействия компонентов программной системы, разработку и анализ ее свойств. Например, общая производительность и совместимость продуктов определяются преимущественно на основе оценки программной архитектуры.
Хотя не существует единственного общепринятого строгого определения программной архитектуры, известны ряд «классических» определений. Так, в трудах Г\ Буча, Дж. Рамбо и И. Якобсона программная архитектура определяется следующим образом. [16] Архитектура является набором ключевых решений об организации системы программного обеспечения, выборе структурных элементов и их взаимосвязей, из которых составляется система, наряду с их поведением, указываемым во вшімодействиях этих элементов, составе этих структурных и поведенческих элементов в прогрессивно увеличивающихся подсистемах, и архитектурном стиле, который управляет этой организацией - этими элементами и их интерфейсами, их взаимодействием и их структурой.
Разработка архитектуры является неотъемлемой частью проектирования программного продукта. Она задает базовую спецификацию приложения па высоком уровне и общую стратегию его построения. Далее в процессе разработки в рамках определенной архитектуры прикладные задачи приложения могут быть реализованы различными способами на усмотрение разработчика.
Поскольку программная архитектура охватывает широкий комплекс проблем, связанных с проектированием программного обеспечения, удобно классифицировать и структурировать архитектурные задачи и использовать более узкие элементы архитектуры. Эш проблема была подробно исследована в конце 90х годов. [17] Выделяются следующие основные направления программной архитектуры: Логическая структура, описывающая компоненты, составляющие систему, связи между этими компонентами; Конфигурация и стиль системы; Семантические правила и ограничения; Функциональная логика, решаемые задачи.
Исходя из этих направлений, строятся модели, описывающие архитектуру системы в том или ином сечении, совокупность которых дает полное представление о программной архитектуре продукта, На практике используются следующие перспективы программного продукта, определяемые в рамках архитектуры:
Логические модели задают объектную структуру приложения. Их основная цель -описание логических связей между компонентами приложения, которые объединяют их в единую систему. Логические модели часто используются для описания отдельных прикладных областей и классов задач. Они строятся на основе анализа предметной области и являются средствами передачи информации между архитектором и экспертами предметной области.
Процессные модели представляют ортогон&шшй взгляд на программную архитектуру. Они концентрируются на построении принципов динамического поведения системы: описывают события, активности и процедуры, выполняемые на отдельных фазах процессов» участвующие в них объекты и их динамическое взаимодействие. Процессные модели описывают изменения, происходящие во время исполнения приложения, потоки данных и работ, правила документооборота. В качестве элементов модели выступают процессы или потоки управления,
Фшическис модели задают правила отображения элементов программного средства на аппаратное обеспечение. Как правило, в рамках данной модели осуществляется распределение процессов по объединенным в сеть вычислительным уїлам, Одной из основных трудностей па протяжении всей истории развития индустрии разработки программного обеспечения было неуклонное нарастание сложности создаваемых систем. Сложность систем приводит к трудоемкости их поддержки и развития, повышает вероятность неправильного построения, недостаточной или дублирующей функциональности. Такая проблема возникает при отсутствии прозрачности системы.
Проблема может быть решена с помощью построения актуальной и попятной архитектурной модели системы. Архитектура задает правила построения и развития системы и повышает ее прозрачность и непротиворечивость. В начале проектирования системы необходимо выбрать средства моделирования и описания программной архитектуры. [20]
Опыт разработки программных средств независимыми разработчиками привел к появлению множества стратегий и методик решения тех или иных задач. Со временем наиболее успешные и востребованные методы преобразовались в такие архитектурные решения, как шаблоны проектирования, эталонные модели и архитектурные стили. [18] Под архитектурным стилем понимается совокупность стратегий реализации следующих элементов: множество типов компонентов (например, хранилище данных, процесс, процедура): топология, определяющая взаимосвязи между компонентами во время исполнения; множество семантических ограничений; мпожество соединителей.
Для некоторых предметных областей имеются готовые архитектурные стили в виде платформ, например, J2EE, .NET, Symbian/Serics 60 и Websphere. Стандарты обмена данными на уровне приложений, такие как XML и SOAP, оказали па них значительное влияние. Программное обеспечение с открытым кодом также сильно влияет на архитектурную практику.
Шаблон Generic Attributes Access
Использование комбинации шаблонов Data Access Object и Transfer Object - один из наиболее распространенных способов решения задачи передачи крупных объемов данных. Однако он имеет ряд существенных недостатков. Основной из них - сложность реализации и поддержки, обусловленная необходимостью корректной обработки транзакций и синхронизацией объектов.
Другая проблема - недостаточная масштабируемость. Объект ТО эффективен дія небольших по размеру компонентов. Если же компонент моделирует сложный объект с большим количеством атрибутов (например, пакет акций с сотнями атрибутов), реализация его в виде EJB потребует написания множества методов дли обработки атрибутов, что выльется в весьма трудоемкую задачу.
Шаблон Generic Attributes Access предполагает решение той же задачи с использованием контейнера HashMap. Доступ к атрибутам бизнес-объекта абстрагируется при помощи общего иігтерфейса Attribute Access, который использует структуру HashMap для передачи атрибутов в бизнес-объект и обратно в форме ключ-значение. [33]
Шаблон проектирования Abstract Factory (Абстрактная Фабрика) предоставляет средства инкапсуляции семейства объектов, имеющих общие свойства. При этом клиентская часть приложения создает реализации абстрактной фабрики и использует общие интерфейсы для порождения экземпляров объектов, принадлежащих семейству, При таком подходе клиенту не важно, какие объекты порождаются внутренними фабриками, поскольку он использусг только общие итгтерфейсы их наследников. Таким образом, шаблон отделяет способ реализации множества объектов от декларации их общих свойств. [5] При разработке программного обеспечения, в фабрике реализуется код: исполняемый при создании экземпляров порождаемых объектов. Цель шаблона - изолировать создание объектов от их использования. Фабрика определяет тип создаваемого объекта, но возвращает лишь абстрактный указатель на объект. Это позволяет реализовывать новые объекты без необходимости внесения изменений в код, используемый базовым классом. Использование шаблона делает взаимозаменяемыми объекты одного семейства, не требуя при этом внесения изменения в код. Минусом метода ЯЙЛЯСТСЯ избы і очная сложность при изначальном написании кода, которая компенсируется при создании большого количества схожих объектов. Поэтому шаблон целесообразно использовать в системах с большим количеством объектов.
Поскольку фабрика нозврашает указатель на абстрактный класс, код клиента, вызвавшего фабрику объекта, пе содержит информации о тине конкретного порождаемого объекта. Однако inn конкретного объекта, как и конкретной наследуемой фабрики, может быть получен, например, из конфигурационного файла Получается, что клиент избанлен от необходимости указывать тип объекта, поскольку он уже указан в другом месте. В частности зш означает:
Код клиента работает исключительно с абстрактным классом. Он не имеет какой бы то ни было информации о конкретном типе, и ему не требуется включать декларации классов либо файлы с заголовками для конкретных типов. Хотя в действительности фабрикой создаются объекты конкретных типов, клиентский код обращается к ним не напрямую, а через их абстрактный интерфейс. Добавление нового конкретного объекта выполняется путем указания в коде клиента на использование другой фабрики. Такое изменение, как правило, затрагивает одну строку в коде клиента. (При этом объект нового тика создается при помощи другой фабрики, которая, однако, возвращает указатель на тот же самый абстрактный тип, изолируя тем самым код клиента от изменения.) Такой подаод существенно облегчает задачу добавления новых типов объектов. При отсутствии абстрактной фабрики пришлось бы вносить изменения непосредственно в код клиента, что потребовало бы изменять все места кода, в которых создается данный объект- Помимо этого пришлось бы контролировать, что перед каждым таким вызовом была сделана декларация типа объекта. В случае, когда объекты-фабрики в единственном глобальном компоненте, к которому обращается клиентский код, изменения правил создания объектов затрагивают только этот компонент.
Цели создания платформы
Эффективное управление компанией немыслимо без применения информационных технологий- Локальные задачи информатизапии можно решить использованием стандартного программного обеспечения, которое широко представлено на рынке и ориентировано, например, на автоматизацию бухгалтерского учеіа, складской деятельности, управление персоналом. Часто эти программы, созданные различными производителями, являясь закопченными цельными решениями, не способны напрямую взаимодействовать друг с другом.
С другой стороны, деятельность любого предприятия, так или иначе, представляет собой множество взаимодействующих процессов, в которые вовлечены и бухгалтерия, и склад, и другие службы. Эффективность управления напрямую зависит от способности системы представить каждый бизнес процесс как единое целое, давая возможность руководству отслеживать и контролировать как отдельные этапы процесса, так и весь процесс целиком, Чтобы обеспечить такую функциональность необходимо связать вес участки локальной автоматизации в единое информационное пространство предприятия. Современный руководитель должен иметь возможность не только оперативно нолучаіь информацию о состоянии дел в подразделении, но и оказывать управляющее воздействия» где бы он ни находился в данный момент времени. Это значит, что система должна предоставлять пользователям защищенный удаленный доступ, а лучше всего обеспечивать возможность использования в качестве клиента Web браузер. Эффективная система управления должна охватывать удаленные офисы и филиалы, в том числе и тс, которые не обладают постоянным каналом доступа к центральному офису. Чтобы объединить все подразделения в рамках одной информационной системы и тем самым обеспечить консолидацию данных, работу с едиными процессами и оперативность в управлении, необходимо в тех удаленных подразделениях, у которых нет возможности поддерживать постоянную связь с центральным офисом, установить локальную версию системы, которая будет синхронизировать данные с центральной системой по определенному расписанию.
С целью решения описанных проблем, была разработана универсальная модульная платформа для построения единого общекорпоративного информационного проарапства и автоматизации процессов организации. Предлагаемые на базе этой платформы решения выполнены в 3-х урозпевой архитектуре «клиент-сервер», масштабируемы, расширяемы, способны тесно интегрироваться с уже существующими программными комплексами автоматизации, поддерживают управление процессами и позволяют использовать Web-браузер в качестве клиента.
Платформа Competcntum построена па базе технологии J2EH (Java 2 Enterprise Edition) [43] - наиболее современной технологии построения корпоративных систем, обобщающей опыт ведущих разрабоачиков корпоративных систем. Стандарт J2EE это устойчивая, гибкая платформа, созданная в результате сотрудничеет ва лидеров инд\ етрии программного обеспечения для решений масштаба предприятия. Серверная часті- системы реализована по трехуровневой схеме, т,е, слой данных отделен от слоя логики и уровня репрезентации данных. сохранение в ftase джнШк Ф&глтески каждешу жлпйсу-шшш в ежггшс сотжтетну т шблшш в йт ;щжш. Xp&mummt дшшык можег бить рвдігю&шп с падощыо гшбпй СУБД йоящтлшшшш гршпгжцш, }\ікіуп к б е д&ншх осутз стн стся тгрія шмоти технологии JDBC Уровень (жчжгс-.югаш раш-пует базовые действия, ирежш.ущие в системе. Этот уршда тлАщч баз) ДЛЯ ОІШШЇШМ тиштяскоіо \юы жкт ирштштя. Как лрїшд:ш, щжл й о&с сЙеїЧ ш ш ішт зи иир л лшдую шершню шл мйжлыо уршшя ІШШЬІХ Па ровне бтясс- ютжи &ЕЄІН . ЇЇ пустея технология І-J В [36], ЇШПОТНЯСШ т сіфікрг приложен ий.
Урошіь реіштаїшв определяет інтерфейс приложения. На ШШ уріШІС жті&жя прЕшшш и форма ДОСШШІ шформаїши кожчпощ шльлттелю, первичная шраГзогка обратной связи. Серверный уровень представления использует такие технологии как Java Server Pages [44] и JavaServJet [45]. При создании JSP страниц активно применяется стандартная библиотека тэгов JSTL. Уровень представления со стороны клиента реализован в платформе простым веб-интерфейсом, просматриваемым и обычном Интернет-браузере, [46]
Создание и назначение теста
Для реализации организационной структуры предприятия в ядре платформы Compelentum предусмотрена абстрактная модель данных UnitModel, которая определяет элемент организационной структуре. Фактически, наследниками этой модели могут быть любые другие объекты, в рамках которых возможны задания ролей. Такими объектами могут быть объекты присущие организационной структуре, такие как организация, департамент, группа, отдел. Также, ими могут быть такие прикладные объекты, как факультет, курс, учебная группа. И хотя курс не является частью организационной структуры, в его рамках возможно задание ролей. Наследование его от UnitModel обеспечит стандартную работу с ролевой моделью. На рис. в качестве примера показаны два наследника модели UnitModel - Organization Mo del (организация) и DcalcrModcl (подразделение), Б классе UnitModel есть атрибут parentunit, который хранит ссылку на родительский элемент, либо null и случае отсутствия такового. Таким образом, возможно задание иерархии этих объекты , в том числе и задание структуры организации. Другая модель, относящаяся к ролевой модели и находящаяся в ядре Compctentum, называется UserModeL Эта модель данных хранит информацию о пользователях системы. Эта простая модель хранит такие данные о пользователе, как логин в систему, пароль: е-mail, а также личные данные. В ядре дополнительно предусмотрена система «прозрачной?) аутентификации в доменах Active Directory, для того чтобы пользователь не вводил пароль и для обеспечения большей безопасности. Так как от системы к системе могут потребоваться различные дополнительные поля о пользователях системы, такие как телефон, адрес и т.д., то модель UserModcl также является абстрактной и разработчик должен определить обязательного наследника этого класса- Например, па рис, показан наследник EduUserModel, вводящий дополнительный атрибут phone (телефон). Роли в системе хранятся в объектах модели RoleModel Роль содержит такие атрибуты, как название (name), а также название модели данных (model), в которой может существовать данная роль. Например, роли менеджера в проекте и в организации являются, по сути, разными ролями, хотя и носят одно название «Менеджер». Также, система должна понимать, что некоторые роли неприменимы к определенным объектам. Например, роль вахтер вряд ли применима к проекту, по применима к организации. Необходимо отметить, что поле model может быть пустым. Такие роли называются глобальными, и они относятся к целой системе, а не к конкретному подразделению Примером может служить роль «администратор системы».
Создание, редактирование и удаление объектов этих трех типов (ролей, пользователей и подразделений) производится через стандартный интерфейс администратора и других привилегированных пользователей системы. Этот интерфейс располагается также D платформе, так как такая функциональность является базовой для многих систем. Для хранения информации о назначенных ролях используются две модели данных: UserRole для храпения информации о глобальных ролях и UnitUscrModel для хранения информации о назначенной роли в рамках определенного департамента. На Рис. 37 приведена диаграмма классов и показано» каким образом эти модели соотносятся с остальными. Фактически, эти модели служат для формирования связен между моделями пользователей, подразделений и ролей вида «многие ко многим». Интерфейс для назначения и редактирования ролей также входит в платформу. [46]
В Системе существует блок, Б котором содержится учебный материал по ведущимся курсам. Учащиеся могут использовать учебный материал для обучения и подготовки к тестам. Учебные материалы сі руппироваиы по разделам. Каждый раздел содержит теми -папки, в которых непосредственно находятся документы. Темы могут быть вложенными. Преподаватель может наполнять систему учебными материалами двумя способами. Он может создавать свои документы в формате XML при помощи встроенного визуального редактора либо загружать ІІ систему внешние документы ъ произвольном формате. Внешние документы открываются при помощи соответствующего приложения на компьютере пользователя (Word, Excel, Acrobat Reader и TJT).
При входе в раздел отображается структура учебника - список разделок и тем. Пользователь может войти в тему, нажав на название. Внутри каждой темы отображается список документов. Преподаватель может создать новый документ, редактировать или удалить существующие.
Документы XML открываются в рабочем окне системы. При создании или редактировании таких документов открывается форма, содержащая название и текст документа. Текст должен быть введен в формате XML. После внесения изменений документ нужно сохранить.
В системе реа.тизоваЕш поддержка версий документов и разграничение доступа для создания документов. Для каждого пользователя с ролью Преподаватель дополнительно определяется полномочие па выполнение операции Утверждает учебные материалы, определяющее возможность прямой публикации созданных пользователем документов. В случае если преподаватель имеет право публиковать материалы, документ сохраняется автоматически. Если же такого права нет, документ будет направлен на утверждение другому преподавателю, имеющему соответствующие полномочия. После проверки документ может быть утвержден, что приведет к публикации его в системе, или отвергнут. На Рис. 39 приведена диаграмма деятельности процесса создания учебного документа.
