Создание веб-ресурса дистанционного образования

Автор работы: Пользователь скрыл имя, 16 Марта 2012 в 12:16, дипломная работа

Описание

У вступі розглядається мета, предмет і об'єкт дослідження. В першому розділі проводиться змістовний аналіз процесу дистанційного навчання в цілому та особливості обмну текстовими повідомленнями, як складової частини системи дистанційного навчання.
У другому розділі приводяться результати проектування сховища даних.
В третьому розділі представлені результати реалізації програмного модулю обміну текстовими повідомленнями на основі WEB-технологій для системи дистанційного навчання.

Работа состоит из  1 файл

Пояснительная записка.doc

— 1.90 Мб (Скачать документ)

На даний час вже існує багато систем управління дистанційним навчанням, які використовують різноманітні технології та мови програмування додатків. Порівняльний аналіз основних систем наведено в додатку А.

На кафедрі математичного та програмного забезпечення АСУ ХУПС ведеться розробка інформаційно-освітнього середовища «Діалог» (рис.1.5) яке на даний час дозволяє проводити:

1. Розробки дистанційних курсів для навчання .

2. Розробки тестових завдань для контролю знань, тих хто навчається.

3. Автоматизованого контролю знань, тих хто навчається в середовищі.

4. Формування електронної бібліотеки.

5. Підтримки основних ресурсів навчання (журнал, статистика навчання).

Однак не існує можливості проводити семінарські заняття, дискусії та консультації. Дискусія – це навчальне заняття, під час якого відбувається вирішення проблеми, попередньо визначеної викладачем, шляхом обговорення її студентами між собою та з викладачем. Семінар і дискусія проводяться у синхронному режимі (в реальному часі) з використанням телекомунікаційної мережі та програми обміну текстовими повідомленнями, якої в системі «ДІАЛОГ» поки не існує.

21

 



Рисунок 1.5 – Модульна структура системи, яка реалізує ІОС

 

21

 



1.4. Аналіз програм обміну текстовими повідомленнями

Існує три різновида програмної реалізації чатов:

а) HTTP або веб-чати. Такий чат виглядає як звичайна веб-сторінка, де можна прочитати останні кілька десятків фраз, написаних учасниками чата, або обробляється клієнтом, що успадковують можливості браузера. Сторінка чата автоматично регулярно обновляється.

б) програми-Чати для спілкування в локальних мережах (наприклад, Vypress Chat, Intranet Chat) . Часто мають можливість передачі файлів, звуку й відео.

в) спеціалізовані програми для голосових і інших видів чата.

По застосуванню чати діляться на:

      all2all (всі до всіх) групова комунікація;

      p2p (людина до людини) персональні комунікації – особисте спілкування;

      b2b (бізнес до бізнесу) ділові – робота в групах;

      b2c (бізнес до кліентів) споживчі – підтримка клієнтів компанії на корпоративному сайті.

HTTP – мережний протокол прикладного рівня передачі даних у вигляді текстових повідомлень. Основою протоколу HTTP є технологія «клієнт-сервер», тобто передбачається існування споживачів (клієнтів), які ініціюють з'єднання й надсилають запит, і постачальників (серверів), які очікують з'єднання для одержання запиту, роблять необхідні дії й повертають назад повідомлення з результатом.

Протокол HTTP у цей час повсюдне використовується у Всесвітній павутині для одержання інформації з веб-сайтів. В 2006 році в Північній Америці частка HTTP трафіка перевищила частку P2P мереж і склала 46%, з яких майже половина – це передача потокового відео й звуку.

Основним об'єктом маніпуляції в HTTP є ресурс, на який указує URL (посилання) у запиті клієнта. Звичайно такими ресурсами є файли, що зберігаються на сервері, але найчастіше це можуть бути логічні об'єкти або щось абстрактне. Особливістю протоколу HTTP є можливість указати в запиті й відповіді спосіб вистави того самого ресурсу по різних параметрах: формат, кодування, мова і т.д. Саме завдяки можливості вказівки способу кодування повідомлення клієнт і сервер можуть обмінюватися двійковими даними хоча даний протокол є текстовим.

Переваги HTTP:

Простота. Протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але й примітивні сервери.

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

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

Недоліки HTTP:

Великий розмір пакетів. Використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на встаткування при формуванні, обробці й передачі повідомлень. Для рішення даної проблеми до протоколу вбудовані засоби для забезпечення кэширування на стороні клієнта. Нормативними документами по протоколу передбачена наявність проксі серверів, які дозволяють одержати клієнтові документ із найбільш близького до нього сервера. Так само до протоколу було впроваджене дельта-кодування щоб клієнтові передавався не весь документ, а тільки його змінена частина.

Відсутність «навігації». Хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засобу навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів як у протоколі FTP. Передбачалося що кінцевий користувач уже знає URL необхідного йому документа, захитавши який він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально й зручно для людини, але важко коли коштують завдання автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить повністю на плечах розроблювачів додатків, що використовують даний протокол.

Для аналізу були обрані програми обміну текстовими повідомленнями:

1. Chat Mail.ru (рис. 1.6).

2. Skype (рис. 1.7).

3. Chat Харків (рис. 1.8).

4. Чат Bizarre.ua (рис. 1.9).

Рисунок 1.6 – Chat Mail.ru

Рисунок 1.7 – Skype

 

Рисунок 1.8 – Chat Харків

Рисунок 1.9 – Чат Bizarre.ua

 

В результаті аналізу були виявлені типові характеристики чатів:

      з'єднання із сервером постійні, без оновлення вікна повідомлень;

      з'єднання із браузером може тривати цілодобово;

      потреби пам'яті: 1 користувач - 3Мб, 100 користувачів - 5Мб (на всіх!);

      вбудований захист від флуда на з'єднання та веб-сервера;

      пріват (повідомлення, видимі тільки обраному користувачеві);

      додаткова істотна економія трафіка (передача по мережі тільки тексту фраз користувачів, а не повний HTML код);

      більша частина роботи з обрахування шаблонів сторінок перекладена із сервера на користувацький браузер, для прискорення роботи;

      реєстрація користувачів (можна вибрати обов'язкову або не обов'язкову реєстрацію), непробивний захист від реєстрації схожих ніков;

      зміна реєстраційної анкети, зміна пароля, видалення свого логіна;

      адміністратори можуть міняти анкети користувачів, видаляти, міняти пароль, дивитися пароль (залежно від рівня доступу). Перевірка доступу при редагуванні адміністратором інших адміністраторів;

      захист від довгих слів/фраз та їх передача без розривів пробілами;

      підсвічування URL у фразах, що вводяться;

      заміна посмішок у фразах на смайликі у вигляді картинок;

      вставка смайликів, готових фраз, цікавих символів;

      кожне поле анкети має безліч параметрів для захисту від уведення некоректної інформації користувачами;

      контекстне меню по правій кнопці миші на ніках у вікні повідомлень, для швидкої вставки ніка в поле введення, включення прівата, відправлення жартів або видалення із чата;

      чат не вимагає включених cookies (5% людей cookies відключають);

      виділення повідомлень чата від інших людей, які містять ваш нік, щоб не пропустити звернені до вас репліки;

      виділення власних фраз у загальному потоці повідомлень;

      вибір кольору повідомлень, кольору фону повідомлень, кольору ніка, кольори фону ніка, розмір шрифту повідомлення, розмір шрифту повідомлення, жирність шрифту ніка, жирність шрифту повідомлення. Право міняти ці параметри мають лише ті, кому це дозволить адміністратор;

      настроювання рівнів безпеки для домашнього доступу в Інтернет або підключення у випадкових місцях - у гостях, у кафе. Політика швидкого входу без уведення пароля, тривале збереження пароля, час життя сесії, захист від підміни IP адреси, захист від крадіжки сесій. Сесію неможливо передати через чат - захист від користувачів;

      топік - текстова або HTML новина, яка видна всім відвідувачам чата при вході. Кожні 1,5 години (значення змінюється) новина повторно виводиться всім відвідувачам, які вже там сидять. Текст топіка міняється по команді в чаті /topic ваша новина або з адміністраторської кімнати;

      адміністраторська частина для установки банов (заборона входу). Масові або точні бани. Рівні доступів адміністраторів від 100 (початківець адміністратор) до 1000 (власник чата);

      повний опис усіх прав утримується в конфігурації чата, де можна змінити доступ до окремих команд і властивостям;

      адміністраторська кімната чата містить докладну статистику про роботу чат сервера (трафік, навантаження, з'єднання і т.д.), кнопки для старту/зупинення чат сервера, сторінку зміни основних настроювань чата;

      захист від занадто швидкого посилання великого за обсягом тексту в декількох повідомленнях та повторів однієї й тієї ж фрази (або схожих);

      транслітерація повідомлень: автоматичний переклад takogo texta на російську мову;

      додавання термінової новини у вікно з повідомленнями;

      супроводження повідомлень звуковим сигналом;

      гостьовий вхід та пошта чата;

      набір спеціальних швидких команд;

      перегляд повідомлень користувача за визначений період часу.


2. ПРОЕКТУВАННЯ БАЗИ ДАНИХ

2.1 Алгоритми створення та обміну текстовими повідомленнями

В процесі використання програми обміну текстовими повідомленнями (рис. 2.1)приймають участь: методист – особа, яка має право створювати кімнати, викладача –  особа, яка має право настроювати кімнати та слухач – той, що навчається згідно алгоритму на рис. 2.2.

 

 

 

 

Рисунок 2.1 – Участь в роботі кімнати чату

Рисунок 2.2 – Алгоритм дій слухача

Методист та викладач виконують дії зображені на рис. 2.3.

Рисунок 2.3 – Алгоритм створення (зміни) кімнати

2.2 Концептуальне проектування з розробкою ER- діаграм

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

Фаза концептуального проектування бази даних починається із створення концептуальної моделі даних, повністю незалежної від будь-яких деталей реалізації. До останніх відносяться: вибраний тип СУБД, склад програм додатків, мова програмування, конкретна обчислювальна платформа і будь-які інші фізичні особливості реалізації.

Збір інформації для моделювання даних

Перед тим, як розробляти діаграму сутності-зв'язку, необхідно зібрати інформацію про можливу сутність проблемної сфери і, можливо, їх атрибутах. Для цього існує багато способів, як формальних, так і неформальних. Відзначимо деякі з них:

1) простий неформальний спосіб - розглянути опис проблемної сфери (можливо, одержаний в процесі проведення співбесіди із замовником) і виділити в ньому іменники і дієслова. Іменники будуть кандидатами по сутності, дієслова - кандидатами в зв'язку. Природно, таке правило є дуже приблизним і кожна одержана таким чином сутність-кандидат повинна перевірятися в умовах колективу аналітиків.

2) одержати список сутності на основі формального опису бізнес - процесів системи, тобто діаграми процесів (business process diagram) бізнесу або діаграми потоків даних (data flow diagram, DFD).

Побудова діаграм бізнес-процесів на початковому етапі проектування повинна служити для виділення сутності в проблемній сфері. Використання таких засобів, як Embarcadero Studio 7_1, знімає ряд проблем (наприклад, із стійкими угодами про імена сутності).

3) одержати інформацію про сутність з діаграм варіантів використання (use case diagrams), побудованих для даної системи. Він дозволяє розглядати систему з погляду різних сценаріїв її використання різними категоріями користувачів і інших систем, що взаємодіють з нею. Варіанти використання в значній мірі можуть замінити діаграми процесів бізнесу і потоків даних.

4) використовувати такі джерела інформації про сутність і атрибути, як:

                  складні структури даних проблемної сфери;

                  правила бізнесу;

                  каталог даних,

і виділяти з них сутність (з одночасним визначенням зв'язків між ними).

Складні структури даних проблемної сфери - це (ненормалізовані) структури даних, з які грають ту або іншу роль в проблемній сфері .Словник або каталог даних - це база мета-даних, в яку заносяться всі знайдені на етапі збору інформації складні структури даних, вже знайдена сутність, атрибути (можливо, без сутності) і зв'язки. При моделюванні досліджується цей каталог у пошуках сутності, атрибутів і зв'язків для моделі.

Информация о работе Создание веб-ресурса дистанционного образования