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

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

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

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

Проектування інтерфейсу користувача

Перш ніж приступати до реалізації форми (або звіту), важливо ретельно спроектувати її (або його) макет. Можна дати деякі корисні рекомендації зі створення макетів будь-яких форм і звітів (Shneіdermann, 1992). Зокрема , подібний макет повинний включати:

- змістовна назва;

- ясні і зрозумілі інструкції;

- логічно обґрунтовані угруповання і послідовності полів;

- візуально привабливий вид вікна форми або полючи звіту;

- легко пізнавані назви полів;

- погоджену термінологію і скорочення;

- погоджене використання квітів;

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

- зручні засоби переміщення курсору;

- засобу виправлення окремих помилкових символів і цілих полів;

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

- особливе виділення необов'язкових для введення полів;

- засобу висновку пояснювальних повідомлень з описом полів;

- засобу висновку повідомлення про закінчення заповнення форми.

Змістовна назва

Інформація в назві повинна ясно і недвозначно ідентифікувати призначення звіту або форми.

Ясні і зрозумілі інструкції

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

Логічно обґрунтовані угруповання і послідовності полів.

Логічно зв'язані поля в звіті або формі варто розташовувати разом, при чому їхня послідовність повинна бути логічно обґрунтованої і погодженої.

Візуально привабливий вид вікна форми або полючи звіту.

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

Легко пізнавані назви полів.

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

Погоджена термінологія і скорочення.

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

Погоджене використання квітів.

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

Візуальне виділення простору і границь полів уведення даних.

Користувач повинний бути візуально проінформований про загальний простір доступному для введення даних у кожнім з полів. Це дозволить йому ще до введення даних вибрати для них найбільш підходящу форму представлення.

Зручні засоби переміщення курсору.

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

Засобу виправлення окремих помилкових символів і цілих полів.

Користувач повинний легко визначати, які саме операції доступні йому для виправлення помилки, допущеної при введенні даних. Для цієї мети звичайно користуються найпростіші механізми, подібні до натискання клавіші <Backspace> повторному введенню поверх помилкових символів.

Засобу висновку повідомлень про помилки при введенні неприпустимих значень

При введенні в поле неправильних даних програма повинна виводити повідомлення про помилку. Це повідомлення повинне інформувати користувача про допущену помилку і вказати діапазон припустимих значень.

Особливе виділення необов'язкових для введення полів

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

Засобу висновку пояснювальних повідомлень з описом полів

Коли користувач поміщає курсор миші в чергове поле, то в деякому стандартному місці (наприклад, у рядку стану даного вікна) варто вивести інформацію про це поле.

Засобу висновку повідомлення про закінчення заповнення форми

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

Програмний код для реалізації чату наведений в додатку Д.

ВИСНОВКИ

Дистанційне навчання як цілеспрямований, організований, інтерактивний процес розвивається у специфічній дидактичній системі: мета, зміст, методи, засоби, об’єкт та суб’єкт навчання, інформаційно-освітня підсистема; організаційні форми навчання, учбово-матеріальна підсистема, фінансово-економічна підсистема, нормативно-правова підсистема, ідентифікаційно-контрольна і маркетингова.

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

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

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

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

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

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

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

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

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

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

Варіант організації чату запропоновано в роботі. В роботі також визначені рекомендації щодо проектування подібних програм.

Перелік використаних джерел

1.     Концепція розвитку дистанційної освіти в Україні. - Київ, 2001.- 2 с.

2.     Положення про дистанційне навчання. Затверджене Наказом Міністерства освіти і науки України № 40 від 21.01.2004.

3.     Шварц Ю.С. Возможности дистанционного обучения в военном образовании // Вестник Военной Академии Республики Беларусь. – 2004. - № 2(3). - http://rezult.at.tut.by.

4.     Концепція створення системи дистанційного навчання у Збройних Силах України. - Львів, 2004. – 12 с.

5.     Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное      пособие. – М.: ФОРУМ: ИНФРА – М, 2003 г.

6.     Карпова Т. С. Базы данных: модели разработка, реализация. Учебник для техн. специальностей вузов: СПБ Питер, 2002 г.

7.     Петров В. Н. Информационные системы: СПб и др. Питер, 2002 г.

8.     Гарсиа-Молина, Гектор, Ульман и др. Системы баз данных. Полный курс. Пер. с англ. – М.: Издательский дом “Вильямс”, 2004. — 1088 с.

9.     Конноли Томас. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.:  Пер. с англ.: Уч. пос. – М.: Издательский дом "Вильямс", 2000. – 1120 с.

10. К. Дж. Дейт. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом "Вильямс", 1999. – 848 с.

11. ДСТУ 2874-94. Бази даних. Терміни та визначення. — Київ: Держстандарт України, 1995. — 32 с.

12. Ребекка Райордан. Основы реляционных баз данных.: Пер. с англ.-М.: Издательско-торговый дом «Русская Редакция», 2001.-384с.

13.   Обзор программных продуктов для Дистанционного Корпоративного обучения. Отчет. - //www.cnews.ru/reviews/reviews/index.shtml?190177#reg.

14. Alexander Maedche. Ontology Learning for the Semantic Web // The Kluwer International Series in Engineering and Computer Science. - Volume 665.

54

Додаток А.

Таблиця А.1.

Порівняльний аналіз систем управління дистанційним навчанням

Таблиця А.2.

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