1. Специфікація інтернет-програми

Головні відмінності між традиційними і інтернет-програмами:

• Навігація

Інтернет-програми зазвичай мають гнучкішу навігаційну модель, що може бути незрозумілим при неправильній реалізації взаємодій.

• Досвід користувача

Будь-яке припущення про майбутніх користувачів може бути помилковим.

• Масштабованість

Розрахувати робоче навантаження інтернет-систем практично неможливо. Будь-яке нове успішне застосування може збільшити використання інтернету за короткий проміжок часу.

• Часті зміни

Функціональність інтернет-програм, як і даних систем, підлягає частішим змінам, ніж у випадку з традиційними програмами.

• Інтерфейс користувача

Сучасні технології дають менше можливостей створення інтерфейсу користувача, ніж старіші.

Типи інтернет-програм

Є два головні типи інтернет-програм:

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

• Програми з функціональними особливостями. Приклади таких програм є інтернет-шоппінг або браузери. Програма повинна мати вбудовану в модель бізнес-логіку.

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

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

2. Методи розробки інтернет-програм

Перші інтернет-програми були розроблені без урахування їх специфічних особливостей. Їх часто не підтримувала відповідна система підтримки. Багато інтернет-програм було розроблено шляхом модифікації існуючих програм. Великий попит на інтернет-програми дав поштовх розвитку нових методів їх будівництва.

Кожен з представників методів будівництва інтернет-програм містить в собі п'ять стадій: збір вимог, концептуальна модель, навігаційна модель, інтерфейс користувача і реалізація. Але не всі вони завжди присутні в моделі.

3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)

Цей метод складається з чотирьох етапів. У деяких з них використовується UML.

Формулювання вимог

Формулювання вимог - перший етап будівництва системи. Вимоги потрібно представити у формі способів використання або сценаріїв. Вони повинні бути перевірені користувачем. На цій стадії використовується форма запису UML.

Абстрактна модель

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

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

Мал. 8.4.1. Клас із змінним типом атрибуту.

Клас, представлений на мал. 8.4.1., містить атрибут з можливістю розширення - властивість може бути або фотографією (за замовчанням, що позначене плюсом), або відео. У кожному екземплярі за замовчанням тип атрибуту, теж за замовчанням. Решта типів стосується опцій.

Приклад абстрактної діаграми класів:

Мал. 8.4.2. Приклад абстрактної діаграми класів.

Навігаційна модель

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

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

Мал. 8.4.3. Навігаційна діаграма класу.

Ми перенесли деякі дані з класу "персона" в клас "інтерв'ю" і "газета". Клас "персона" не використовується в діаграмі.

Грунтуючись на навігаційній діаграмі класів будується навігаційна контекстна діаграма.

Вона складається з таких компонентів:

• Вузли - представляють логічні "вікна" або можливості розширення;

• Зв'язки - представляють асоціації концептуальної моделі і пов'язують її з іншими навігаційними класами;

• Індекси - представляють індекси елементів;

• Гайд-тури - послідовності елементів.

Нижче зображена навігаційна контекстна діаграма:

Мал. 8.4.4. Приклад навігаційної контекстної діаграми.

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

Чорний квадрат вказує на присутність індексу; порожній квадрат вказує, що індексу не існує. Пунктирна лінія між контекстами вказує, що навігація від одного контексту до іншого неможлива. Інакше вона можлива. Стрілки показують напрям переходу.

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

Абстрактна модель інтерфейсу користувача

Інтерфейс користувача в ООГМР описаний з використанням абстрактних видів даних (Abstract Data Views, ADV). Вони представляють будову інтерфейсу, що не має зв’язку з його реалізацією.

Вони дозволяють визначити наступне:

• Структуру інтерфейсу користувача, використовуючи агрегацію і наслідування як механізми абстракції;

• Схему елементів інтерфейсу;

• Відносини елементів інтерфейсу до навігаційних об'єктів;

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

Мал. 8.4.5. Приклад простого АВД.

Мал. 8.4.5. показує простий варіант інтерфейсу, що використовується для проглядання газетних статей з використанням ООГМР.