Глава 16
Высокоуровневое проектування
Проектування ПІ включає багато підходів: каскадний, зсередини - назовні, зовні - усередину, ітеративний і т.д. У рамках кожного з підходів існує ' також ряд методів. Незалежно від высокоуровневого підходу для проектування взаємодій високого і низького рівня вимагаються специфічні методи. На мал. 16.1 показаний підхід до высокоуровневому проектування з орієнтацією на користувача.
У главі розглядається підхід, призначений для ітеративного проектування і реалізації додатків із застосуванням різних стилів ПІ. Описується объектно-ориентированный підхід, хоча для багатьох етапів проектування його можна замінити на традиційні методи розробки. Результати проектування, отримані за допомогою цього підходу, корисні для документування, імітації, прототипирования, оцінки і реалізації Пи-ориентированных додатку.
У главі розглядаються деякі теми, що стосуються проектування високого рівня, що визначає семантику і структуру користувальницького інтерфейсу, а також підтримуюче базове ПО. От ці теми.
" Установлення контексту в межах циклу розробки.
" Визначення і вхідна інформація проекту.
" Объектно-ориентированные компоненти.
" Поводження робочого столу.
" Логіка викликів ПІ.
" Основні екрани - функції, уміст, меню.
" Основні діалоги.
" Визначення допоміжних вікон.
" Інсталяція, печатка й інші системні функції.
" Продовження обговорення проекту.
У процесі проектування бригада розроблювачів проводить аналіз і перевірку обґрунтованості проектних рішень, а потім, при необхідності, виконує чергову ітерацію. Ітерація 12 являє собою основну ітерацію, що може містити безліч більш дрібних кроків. Ціль полягає в идентифицировании основних повторно використовуваних компонентів, раніше не ідентифікованих.
Проектування Пи-ориентированных додатків- складна проблема. Суще-ствует багато підходів і методів для рішення різних проектних задач. Необхідно врахувати і продумати масу деталей, щоб забезпечити легкість навчання і використання продукту для кінцевих користувачів, а також досягти інших мет у відношенні ПІ і практичності. Однак самий надійний шлях розробки Пи-ориентированных додатків, практичність яких задовольняє вимогам, - ітеративний підхід із залученням користувачів.
Установлення контексту в рамках циклу розробки
Дотепер наша діяльність була сконцентрована на першій головній проект-ний ітерації - концептуальному проектуванні. Для невеликих і середніх по обсязі програмних проектів з коротким циклом розробки закриття концептуального проекту відбувається вже через три-чотири тижнів. Для середніх і великих проектів з більш тривалим календарним графіком концептуальне проектування займає від чотирьох до шести тижнів.
У цей період проектна бригада виконує наступні види діяльності.
" Планування проекту, оцінка обсягу робіт, підбор персоналу і навчання.
" Формулювання й аналіз вимог.
" Придбання й установка інструментальних засобів, настроювання середовища.
" Проектування і розробка прототипів для альтернатив концептуального рівня.
" Робота з користувачами й іншими учасниками проекту на вибір і схвалення напрямку проектування.
" Інтеграція проекту ПІ з проектом інфраструктури.
Корисне правило. Концептуальний проект, що встановлює напрямок розвитку проекту за порівняно короткий період часу, повинний бути досить точним і гнучкої. Проект високого рівня конкретизує більша кількість деталей, а проект низького рівня завершує визначення.
Тепер приступимо до вивчення наступного основного етапу проекту- высоко-уровневого проектування.
Визначення і вхідна інформація проекту
Проект - це базова чи схема організація елементів, що складають приложе-ние, екрани, команди, елементи керування й інші основні компоненти. Проект ПІ являє собою сукупність сприйманих кінцевими користувачами можливостей програми, що включають користувальницьке введення, взаємодію і реакцію системи. Проект реалізації для ПІ - це схема використання мови програмування і системних можливостей для досягнення відповідних ре-зультатов функціонування ПІ. Варто проводити чітке розходження між ПІ і базовим ПО, що змушує його працювати. Ми як і раніше зосередимо свою увагу на проектуванні ПІ.
Сприймані кінцевими користувачами функціональні можливості про-грами включають функції для ПІ і прикладної області. Приклад ПІ - рядок меню для GUі-интерфейса, прикладом функціональної можливості прикладної області є поле, що підтримує пошук на Web-сторінці. Сприймані кінцевими користувачами функціональні можливості Пи-ориентированной програми включають прикладне застосування екранів, вікон, меню, покажчиків і інших компонентів ПІ. Крім того, можливості ПІ прикладного рівня, сприймані кінцевими користувачами, - це передбачувана користувальницька модель, семантика і синтаксис об'єктів і команд, а також застосування фізичних пристроїв і взаємодії, що виходять за межі використовуваних базових можливостей стилю ПІ.
Нагадаємо, що проект ПІ продукту матеріалізується в специфікаціях, макетах, розкадруванні, моделях, прототипах і, безумовно, у ПО продукту, що поставляється поль-зователям. Проект не обов'язково стосується способу реалізації ПІ.
Мотивація. Розробка Пи-ориентированного додатка- ризиковане підприємство з погляду проектування, реалізації і тестування. Саме тут починається важка робота.
Існує щонайменше два рівні проекту (мал. 16.2). ПІ додатка - самий верхній рівень (тобто екрани, піктограми, меню, покажчики, елементи управ-ления, структури і стилі взаємодії, забезпечувані системою і додатком). Деякі проектні рішення реалізуються з використанням функцій, обес-печиваемых ОС (наприклад, видимі компоненти і поводження кнопки Maxіmіze (Максимізувати вікна)).
Корисне правило. У залежності від термінів і ресурсів необхідно подбати про те, щоб проект випереджав можливості реалізації щонайменше як З : 1.
Проект високого рівня. Аналогічно проектам інших видів ПО, для ПІ можна виділити щонайменше два інших рівні деталізації. Перший рівень, що виходить за рамки концептуального проекту, являє собою рішення високого рівня, що одночасно відкриває можливості для наступних основних проектних ітерацій. Одні з труднощів высокоуровневого проектування складається в необхідності звертатися до деталей ПІ і продукту, що виходить за межі концептуального рівня. Высокоуровневый проект вперше одночасно рассмат-ривает з дуже високим ступенем деталізації всі основні компоненти з погляду їхньої інтеграції.
Высокоуровневый проект для ПІ включає наступні основні компоненти (мал. 16.3).
" Підхід до використання платформи ПІ.
" Передбачувану користувальницьку модель.
" Характеристики об'єктів, властивостей і дій.
" Структуру і логіку викликів вікон і екранів.
" Основні вікна, екрани, представлення і діалоги.
" Стандартні і додаткові представлення.
" Графічний, аудио - і візуальний стиль.
" Стиль меню і вибір команд.
" Інсталяцію, операції переносу, буфер обміну, печатка і поводження робочого столу.
Внешний вид и
поведение экранов
Проект низького рівня. За етапом высокоуровневого проектування випливає етап низкоуровневого проектування, у результаті якого розробляються деталізовані проектні рішення. Низкоуровневый проект включає деталі, що не вимагають глибокого розгляду при высокоуровневом проектуванні. Як випливає з назви, роботи з проекту низького рівня включають визначення незліченних деталей для компонування екранів, поводження покажчиків, затінення елементів вибору команд, символів прискореного вибору команд, що прискорюють клавіш, комбінацій клавіш, відповідності клавіатури і покажчика, кольори і графіки дисплея, повідомлень, зворотного зв'язку з користувачем і застосування нестандартних пристроїв. Крім того, низкоуровневый проект знаменує собою початок проекту реалізації, що передбачає деталі, що стосуються способу перетворення функціональних можливостей ПІ і ПО в оператори мови програмування й алгоритми обробки даних.
Корисне правило. Аналогічно іншим аспектам проектування робота з усіма цими можливостями ведеться активно і відповідно до планів.
У зв'язку з великим обсягом роботи і деталей особливо привабливий ітеративний чи еволюційний підхід до проектування, а також до оцінки і реалізації Пи-ориентированных додатків. З прагматичної точки зору подібний підхід дає час проектній бригаді якомога раніше проробити высокоуровневые деталі без небезпеки бути похованої під купою дрібних елементів ПІ і реалізації.
Приклад. Для ілюстрації елементів проекту ПІ скористаємося додатком Address Book (Адресна книга). Address Book- це додаток, розроблений для поль-зователя {Conference Companіon), що відвідує чи конференцію симпозіум. У підсумку передбачається інтеграція Address Book з Conference Companіon, що дозволить переглядати перелік відвідувачів конференції, забезпечити докладну інформацію з кожного відвідувача і створювати запису, що стосуються окремих людей і організацій. У додаток Address Book також можуть бути убудовані можливості на-подоба електронної пошти і пейджинга за умови, що вони підтримуються ап-паратной і програмної платформами користувача.
Вхідна інформація проекту. Перш ніж продовжити розгляд задач высокоуровневого проектування для ПІ, згадаємо, що наявна до цього моменту в розпорядженні проектної бригади інформація включає вимоги, ру-ководство по стилі, стандарти для платформ, концептуальні проектні рішення, первісні прототипи, відгуки, що стосуються практичності, план розробки і зауваження з приводу застосування ітеративного підходу до проектування. Высоко-уровневый стиль ПІ і структура (логіка виклику екранів) ПО визначаються предпо-лагаемой користувальницькою моделлю.
Початком роботи з проектом є вибір і уточнення ПІ стилю додатка. Наприклад, WUі-ориентированное додаток використовує такі можливості плати-форми, як вікна, піктограми, меню і покажчики. Крім цього застосовуються низ-коуровневые елементи керування на зразок списків, кнопок лічильників і т.д.
Проектна бригада повинна продумати, як будуть використовуватися системні эле-менты ПІ разом з унікальними для додатка елементами, що не поддер-живаются системним ПІ. Випливає також у явному виді розглянути використання багатьох наявних у наявності методів взаємодії ПІ. Крім того, необхідно виробити підходи, зв'язані з погодженістю стилю ПІ в рамках додатка.
Наприклад, стандарт для платформи може описувати конкретний елемент управ-ления, скажемо, панель інструментів, і спосіб її застосування. Даний додаток може використовувати цей елемент керування за допомогою способу, що є стандартним у рамках платформи і ще більш стандартизованим у рамках додатка за рахунок застосування загальних термінів, графіки й упорядкування кнопок у загальному стилі. Необхідно розглянути випадки спеціального використання можливостей ПІ, таких як віртуальні кнопки і терміни для написів.
На етапі высокоуровневого проектування розробляються всі специализиро-ванные чи унікальні елементи керування (усякі "штучки"), реалізовані Пи-ориентированным додатком. Звичайно елементи керування ПІ досить складні, тому варто ретельно зважити фактори, зв'язані з їхньою реалізацією, оскільки додаток повинний обробляти всі низкоуровневые взаємодії і поводження за допомогою клавіатури, покажчика і дисплея.
Корисне правило. У максимальному ступені використовуйте стандартні эле-менты керування платформи.
Наслідок. Уникайте конструювання користувальницьких елементів керування.
Объектно-ориентированные компоненти
Якийсь час варто витратити на обговорення объектно-ориентированного проектування стосовно до ПІ. Користувачі живуть в объектно-ориентированном світі, але мислять у термінах об'єктної орієнтації в дуже высокоуровневом стилі. З погляду практики проектування легше виконати багато проектних задач, базуючи на объектно-ориентированных позначеннях незалежно від підходу до структуризації програмного додатка і мови програмування, обраного для реалізації. Можливо, це стає більш очевидним при проектуванні меню для екранів.
Высокоуровневое визначення. Для объектно-ориентированной системи характерні наступні особливості.
" Класи об'єктів.
" Ієрархія класів.
" Спадкування через ієрархію класів.
Будь-яка система, що задовольняє першому з умов, є тільки об'єктної. Якщо система задовольняє двом першим умовам, неї називають системою класів.
З погляду объектно-ориентированного підходу об'єкт- це сукупність даних і виконуваних над ними операцій. Об'єкти організовані в класи, причому об'єкти класу мають схожі чи властивості операціями. Сукупність класів організована в ієрархію, рівні якої представляють підкласи. Класи об'єктів успадковують (повторно використовують) чи властивості операції класів, розташованих вище по ієрархії, при цьому може спостерігатися деталізація чи властивостей операцій для задоволення специфічних потреб класів.
Корисне правило. З погляду ПІ, користувачі найкраще інформовані про об'єкти і їхнє поводження. Немає необхідності в явному представленні пользо-вателям класів, ієрархії класів і спадкування, але ці поняття дуже корисні для будь-якого проекту реалізації, де ціль складається в повторному використанні.
Приміром , людина звичайно думає про улюбленого собаку просто як про собаку, а не про тварину визначеної породи класу ссавців. Більшість користувачів уявляють собі програмні об'єкти аналогічним образом. Address Book- це адресна книга, а не екземпляр класу-контейнера в рамках ієрархії класів засобів реалізації.
Методологія. В основі ефективної розробки объектно-ориентированной системи лежать три ключові види діяльності.
" Объектно-ориентированный аналіз (ООА) спрямований на оцінку потреби користувачів і проблем, які необхідно вирішити. Результатом ООА є концептуальний проект для статичних, динамічних і функцио-нальных аспектів користувальницьких проблем.
" Объектно-ориентированное проектування (ООПР) дозволяє перетворити результати ООА в проектні рішення для системи й об'єктів, більш тісно прив'язані до потреб реалізації.
" Объектно-ориентированное програмування (ООП) дає можливість перетворити результати ООА й ООПР у ПО продукту за допомогою инст-рументальных засобів реалізації.
Існує кілька методологій, що підходять для ООА, ООПР і ООП. Немає необхідності їх вивчати заглиблено, оскільки докладний виклад цих ме-тодологий виходить за рамки книги. Для проектної бригади дійсно важливо оп-ределить такий объектно-ориентированный процес розробки, який би підходив з точки зору рішення користувальницьких проблем, а також навичок і засобів, якими розташовує бригада.
Корисне правило. Існує багато способів рішення проблеми в объектно-ориентированном стилі.
Аспекти, зв'язані з об'єктами. Усі функції і можливості додатка можна виразити в термінах об'єктів, операцій і атрибутів об'єктів і операцій.
Корисне правило. Незалежно від способу реалізації чи ПІ базового ПО, объектно-ориентированная методологія надзвичайно корисна при проектуванні.
Ціль объектно-ориентированного методу полягає у визначенні - з пользо-вательской точки зору - об'єктів і операцій, з якими працює користувач. Як частина аналізу, об'єкти й операції визначаються в термінах примітивів (базисних елементів) і взаємозв'язків з іншими об'єктами й операціями. З метою подальшого розвитку визначень виділяються і встановлюються атрибути об'єктів і операцій. Для виділення об'єктів, операцій і їхніх атрибутів аналізується проектна вхідна інформація. Для ідентифікації неявних чи явних об'єктів і атрибутів аналізується документація по вимогах. При цьому корисним прийомом є виділення всіх імен іменників одним кольором, а іншим-іншим-дієслов-іншим.
Нижче приведені типові вимоги до додатка Address Book.
" Створити систему, що дозволить користувачам відображати і взаимо-действовать зі списком імен.
" Дати можливість користувачам створювати свої власні персональні записи.
" Передбачити схеми і вказівки по доступі до ресурсів, таким як конференц-зали й офіси.
" Забезпечити можливості пошуку і печатки.
" Доступ до продукту повинний здійснюватися за допомогою GUІ-, WUІ- і HUі-интерфейсов.
Ідентифікація об'єктів. Об'єкти- це сутності, що позначаються за допомогою імен іменників. Використання об'єкта відокремлюється від визначення характеристик об'єкта з метою вироблення коректного визначення. Для того щоб правильно охарактеризувати об'єкт, проектна бригада повинна виконати наступні дії.
" Визначити природу об'єкта.
" Описати його використання.
" Визначити характеристики, властивості і значення властивостей.
" Описати відносини об'єкта з іншими об'єктами.
" Визначити набір операцій, застосовних до об'єкта.
Приклади об'єктів, з якими мають справа кінцеві користувачі і які отримані в результаті аналізу адресної книги, - це об'єкти Address Book (Адресна книга), Person (Особа), Group (Група), Resource (Ресурс), Dіstrіbutіon Lіst (Список [абонентів для] розподілу [групових повідомлень]). Прикладом об'єкта з варіаціями у властивостях є об'єкт Address Book, для якого адресна книга організації не редагується користувачем, що не має адміністративних прав, а особиста адресна книга (Personal Address Book) може редагуватися всіма користувачами. Інший приклад подібного об'єкта - чи група список распределе-ния, що включають інформацію про адресатів (Те: (Кому:) її: (Копія:)).
Ідентифікація операцій. Об'єкти - це сутності, що позначаються з по-міццю дієслів. У підсумку операції стають командами ПІ. Для того щоб правильно охарактеризувати операції, проектна бригада повинна виконати наступні дії.
" Визначити, що таке операція (її природу).
" Задати спосіб використання операцій окремо від їхньої природи.
" Визначити характеристики, властивості і значення властивостей операції.
" Описати відносини операції з іншими операціями.
" Визначити об'єкти, до яких застосовна операція.
Операції можуть бути чуттєвими до контексту- вони демонструють різне поводження в залежності від об'єкта. Кожна пара об'єкт-операція ретельно иссле-дуется для визначення точного результату операції.
Приклади операцій для додатка Address Book адресної книги включають такі дії, як Fіnd (Знайти), Search (Пошук) і Prіnt (Печатка). Як приклад операції з варіаціями у властивостях можна назвати операцію Sort (Сортування), що виконується стосовно об'єктів Name (Ім'я) і Cіty Address (Адреса міста). Операції, наявність яких є результатом аналізу вимог, включають операції Drag (Перетягнути), Cut (Вирізувати) і Propertіes (Властивості).
Установлення примітивів. Примітиви- це базові чи фундаментальні сутності, не виведені з інших сутностей і будівельні блоки, що представляють собою, для інших сутностей. Примітиви вводяться в процесі аналізу об'єктів і операцій, особливо при виявленні надмірності в сукупностях об'єктів, операцій і властивостей. Проектувальник аналізує набір об'єктів, операцій і властивостей на предмет примітивів. Примітиви формують базові строитель-ные блоки для конструювання інших сутностей. і
Прикладом примітивної операції є операція визначення местоположе- \ ния (Locate), що може бути використана для побудови операцій Fіnd І (Знайти) і Search (Пошук). Приклад примітивного об'єкта- група, що використовується для побудови об'єктів Group (Група) і Dіstrіbutіon Lіst (Список розподілу).
Побудова матриць об'єкт - операція - властивість. Щоб полегшити аналіз, проектна бригада конструює матрицю для об'єктів і операцій, об'єктів і властивостей, а також для операцій і властивостей. Бригада визначає потенційну сово-купность правомірних операцій для кожного об'єкта, включаючи системні функції на зразок операцій "перетягнути і залишити" і буфера обміну. Аналогічно, бригада аналізує, які властивості зв'язані з кожним окремим об'єктом і операцією.
Ймовірний результат побудови цих матриць показує, що вони майже заповнені (тобто існує дуже щільне покриття функціональними можливостями безлічі об'єктів, операцій і властивостей). От приклад, що пояснює сказане.
" Багато операцій, що історично обмежені визначеними типами об'єктів, виявляються правомірними у відношенні багатьох інших об'єктів.
" Багато властивостей спеціалізованих об'єктів також застосовні до інших більш загальним об'єктам.
" Багато властивостей визначених операцій застосовні також до інших операцій.
Подібний результат найчастіше суперечить інтуїції багатьох проектувальників і звичайно викликає в них подив. У дійсності матриця щільності - пре-восходный результат, оскільки вона відкриває нові додаткові можливості користувачів, тому що існує дуже щільне і навіть функціональне покриття на безлічі об'єктів і операцій програмного продукту. Якщо наступне планування й аналіз ведуться коректно, усі можливості, описані в матриці, згодом розробляються і надаються в розпорядження користувачів.
Класи, ієрархії, спадкування. Наявність об'єктів і операцій веде до об'єктної системи. Як згадувалося раніше, объектно-ориентированная система вимагає наявності класів, ієрархії класів і спадкування, здійснюваного за допомогою ієрархії класів. Класи, ієрархія класів і спадкування виводяться на основі визначень об'єктів, операцій і властивостей, з якими мають справу користувачі. При цьому головна перевага для кінцевих користувачів укладено в подобі поводження схожих типів об'єктів. Однак користувачі не витрачають багато часу і зусиль на класифікацію наочних програмних об'єктів за допомогою віднесення їх до того чи іншого чи класу ієрархії.
Корисне правило. Зберігайте прозорість понять объектно-ориенти-рованного підходу. Проектувальник відображає об'єкти і функціональні воз-можности кінцевого користувача на шаблони, алгоритми і структури даних у бібліотеці повторного використання.
Абстракція класів. Непогано для початку згрупувати об'єкти виходячи з результатів аналізу пара дії-об'єкта-дії. Деякі об'єкти природним образом попадають у схожі групи, у той час як визначені типи об'єктів по природі різні. Наприклад, об'єкти Address Book відрізняються від принтерів, а об'єкти відображень відрізняються від контейнерів. Однак елементи для об'єкта Person до деякої міри схожі на елементи для об'єкта Resource, доданого в особисту адресну книгу (Personal Address Book). Деяке розходження між елементами дуже невелике і вимагає додаткового розгляду. Передбачувана користувальницька модель допомагає прояснити ці розходження.
Типи відносин. Як корисний тест на приналежність об'єкта до класу використовується відношення "є". Наприклад, пропозиції "кожна жаба є рептилією" і "кожна сміттєва урна є контейнером" чітко визначають клас, до якого належить об'єкт. Якщо пропозиція "кожна подія є контейнером" - ложно, тоді об'єкт "подія" належить до іншого класу.
Корисне правило. Рідко можна знайти об'єкт, що не належить до якого-небудь класу.
Ще один метод, що дозволяє з'ясувати, чи є об'єкт компонентом чи класу частиною іншого об'єкта, складається у використанні відносини "є частиною". Наприклад, "нога є частиною собаки". Аналогічно, "сторінка є частиною заради". Однак географічна карта може бути, а може і не бути частиною події.
Після виділення класів із сукупності об'єктів необхідно проаналізувати безлічі властивостей і операцій, щоб переконатися, що властивості також належать сутностям чи екземплярів підкласів.
Інші аспекти объектно-ориентированного підходу. Для реалізації проекту бригада розроблювачів будує ієрархії класів і спадкування. По завершенні проекту бригада має у своєму розпорядженні одне чи кілька дерев (ієрархій класів), що відображають відносини між різними класами додатка. Щоб визначення з погляду користувачів були осмисленими, надзвичайно важливо мати адекватну користувальницьку модель і об'єктні оп-ределения.
На підставі сформованої ієрархії класів оцінюються можливості на-проходження. При цьому розглядається як одиночне, так і множинне наследо-вание. Як складену частину аналізу проектна бригада може відшукати приклади операцій, що мають зміст як з погляду користувачів, так і з погляду проектувальників, але які становлять труднощі для системи і/чи пользо-вателей.
Проектування поводження робочого
столу
Залишивши осторонь багато попередніх зауважень, що відносяться до проекту, повернемося до основних проблем. Більшість операційних систем і платформ об-ладают робітником столом, що використовується для представлення і надання доступу до програмних додатків. При цьому переважають наступні стилі ПІ.
" GUІ- для робочих станцій і деяких кишенькових персональних компью-теров.
" WUІ - для доступу до ПО за допомогою іntranet, extranet і Іnternet.
" HUІ - для кишенькових обчислювальних платформ.
(Іntranet - технологія створення корпоративної локальної мережі підвищеної на-дежности з обмеженим доступом, що використовує мережні стандарти і мережні програмно-апаратні засоби, аналогічні Іnternet; extranet - экстра мережа, объе-динение корпоративних мереж різних компаній, взаємодіючих один з одним через Іnternet. - Прим. ред.)
Доступ до Web-додатка здійснюється за допомогою GUІ- чи HUі-ориентированного вікна броузера. Доступ не забезпечується з робочого столу самою операційною системою (дотепер ).
Доступ за допомогою робочого столу. Існує багато методів доступу до GUІ-, WUІ- і HUІ - ориентированым додатків. Найбільш розповсюджені методи доступу до ПО з робочого столу включають піктограму на робочому столі, елемент чи вибору стартове меню, а також кнопку на панелі задач в області статусу. Метод доступу за допомогою робочого столу відповідає поводженню покажчика і клавіатури. Багато методів доступу засновані на використанні меню і варіантів вибору для меню.
Проектна бригада проробляє наступні проектні альтернативи.
" Об'єкти, чи представлення доступ до яких здійснюється за допомогою чи піктограм варіантів вибору, включаючи головні і мінімізовані об'єкти.
" Подобъекты, доступ до яких здійснюється за допомогою піктограм рабо^ чого столу.
" Варіанти вибору для припустимих команд, зв'язаних з піктограмами робочого столу, включають спливаюче меню і рядок меню.
" Припустимі операції "перетягнути і залишити" і припустиме поводження вихідних і цільових об'єктів, включаючи інші піктограми, що представляють об'єкти в закритому, відкритому і мінімізованому станах.
Піктограми робочого столу. Крім рішення по командах, зв'язаним з піктограмами робочого столу, проектна бригада розроблювачів продукту приймає рішення про тип відображуваної піктограми. Піктограма робочого столу може бути статичної чи динамічний.
Проектування логіки викликів ПІ
Структура Пи-ориентированного додатка складається з логіки викликів, содер-жимого і компонування екранів, меню, операцій, а також взаємодії кінцевого користувача з ПІ. У багатьох відносинах структура додатка відбиває синтаксис ПІ. Логіка викликів ПІ починається зі способу первинного доступу до ПО і відображає наступні аспекти роботи ПІ.
" Усі компоненти ПІ рівня екрана.
" Команди, виконувані негайно, чи використовувані діалоги.
" Доступ до довідки (допомоги), повідомленням, наставлянням і експлуатаційній підтримці.
" Зв'язку з іншим ПО.
Логіка викликів ПІ показує, як здійснюється доступ до додатка з дру-гих частин системи.
Корисне правило. ПІ програмних додатків присуща загальна структура.
Програмні додатки мають дуже подібну структуру ПІ незалежно від того, який стиль - GUІ, WUІ чи HUІ - використовується. Після того як об'єкти й операції додатка визначені, функціональні можливості відображаються на структуру, що припускається для цільовий ОС чи прикладного стилю ПІ. У випадку підтримки рядка меню використання объектно-ориентированного стилю приводить до визначеного меню, умісту меню, вікнам і логіці викликів вікон. Прихильники систем OSF/Motіf, Macіntosh і Wіndows застосовують злегка відрізняються моделі для вмісту набору меню.
Логіка викликів і структура об'єктного ПІ. На мал. 16.4 представлена базова логіка викликів екранів, зв'язаних з Пи-ориентированным додатком. Схема дає загальний погляд на структуру ПІ додатка. Подібне зображення стосовно до Web-орієнтованих додатків називається схемою Web-вузла.
Корисне правило. Побудова логіки викликів варто починати з крапки початкового доступу й екрана об'єкта, що потім відображається. Логіка викликів ПІ не повинна відрізнятися глибиною (уникайте побудови систем ієрархічних меню з використанням вікон, усередині віконних чи екранів Web-сторінок).
На мал. 16.5 представлена більш конкретна логіка викликів ПІ для додатка Address Book і показаний доступ з робочого столу, календаря і поштового додатка. Крім того, за допомогою логіки викликів ПІ додатка Address Book здійснюється доступ до специфічних діалогів, довідці (допомоги), наставлянню, а також инфор-мационным входам для окремих облич, груп, ресурсів і списків розподілу, ко-торые, у свою чергу, одержують доступ до діалогів, календарю і пошті.
Для кінцевих користувачів головна перевага Пи-ориентированного при-ложения, заснованого на GUі-стиле, складається в спрощенні ієрархії екранів і зменшенні обсягу користувальницької взаємодії. Ще одне основне преиму-щество полягає в тім, що користувач зберігає контроль над опорною крапкою доступу під час взаємодії з об'єктом. Система меню дозволяє користувачу контролювати логіку операцій з об'єктом при безпосередній роботі з об'єктом. Порівнянні переваги можливі у випадку Web-орієнтованого ПО, що володіє відповідними засобами навігації.
Для полегшення й автоматизації взаємодії можна реалізувати кілька природних скорочених клавіатурних команд. Основний приклад подібної есте-ственной скороченої клавіатурної команди - випадок відкриття на робочому столі основного об'єкта і зв'язаних з ним об'єктів. Одна команда над основним об'єктом застосовується до всіх зв'язаних об'єктів (наприклад, закриття додатка Address Book приводить до автоматичного закриття усіх відкритих об'єктів, зв'язаних з об'єктом Address Book).
" Якщо система дозволяє відкрити і відобразити одночасно кілька об'єктів, чи повинн додаток підтримувати подібну чи можливість же допускається відкриття тільки одного об'єкта?
" чи Існує обмеження на кількість одночасно відкритих экземп-ляров того самого об'єкта?
От приклади можливих відповідей.
" Якщо всі об'єкти залежні, те так.
" Так, немає чи може бути.
" Заміщати, чи перекривати показувати існуючий об'єкт.
Корисне правило.
" Якщо кілька екранів відображаються одночасно, варто вибрати центральну крапку для відображення основного екрана.
" Послідовні екрани потрібно перекривати зверху і праворуч від основного вікна.
" Якщо послідовно відображувані екрани доходять до краю пристрою відображення, що випливають екрани необхідно відкривати по тієї ж ди-агональной лінії, починаючи зверху дисплея.
" Якщо користувач змінює чи положення розміри екрана (у віконних системах), для відкриття екрана наступного разу необхідно запам'ятовувати, які дії здійснювалися.
Методи спрощення ієрархії. Якщо глибина викликів вікон стає занадто великий, можна застосувати економічні методи, що включають засоби, що сле-дуют.
" Відображення інформації в рамках логіки викликів без відкриття вікон більш низького рівня.
" Засобу відстеження для ідентифікації місця розташування користувача в схемі викликів.
" Схеми ієрархії.
" Безпосереднє введення наочної інформації (що дозволяє уникнути використання діалогових екранів для введення і редагування даних).
" Провідники (з багаторівневим представленням об'єктів).
" Гібридні представлення (2-х уровневые об'єкти).
Проектування основних екранів - функції, дані, вміст і команди
Кожен об'єкт у таблиці "об'єкт-операція" потенційно може бути представлений у виді одного чи декількох екранів. Операції з таблиці "об'єкт-дія зв'язані з кожним екраном за допомогою чи меню інших методів командного доступу. У залежності від проектних вимог і обмежень проекту, для кожного об'єкта здійснюється проектування множинних представлень разом з підтримуваним настроюванням об'єктів, екранів і представлень.
Екрани. Екран - це спосіб представлення користувачу об'єкта, діалогу, повідомлення, чи довідки наставляння. Стосовно до GUі-ориентированным додатків екран звичайно відображається усередині вікна. Що стосується WUІ- j орієнтованих додатків, екран відображається усередині вікна Web - броузера. У HUІ- орієнтованих системах, не підтримуючих вікон, екран виводиться на пристрій відображення, при цьому можуть чи використовуватися не використовуватися деякі властивості вікон у залежності від того, що саме відображається - чидіалог повідомлення.
Кожен об'єкт матриці "об'єкт-операція" відображається на екран об'єкта в ко-манды ПІ, виконувані безпосередньо або виведені на екран для командного діалогу. Екрани повідомлень, довідок (допомоги) і навчальної інформації зв'язані з об'єктами і командами.
Представлення. Представлення - це особливий спосіб подачі об'єкта, чи команди інформації користувачу. Наприклад, додаток Address Book містить наступні додаткові представлення.
o Індексована книжка з закладками.
o Телефонна книга.
o Об'єкти, одержувані в результаті операції пошуку.
Кожен об'єкт володіє щонайменше одним представленням. Наприклад, для відображення подробиць, що відносяться до окремої людини, можливо исполь-зование різних моделей (мал. 16.6). У залежності від проектних обмежень і вимог користувачів додаткові представлення розробляються для об'єктів, команд і інформації. Переважна більшість об'єктів, команд, довідок, повідомлень і посібників володіють тільки одним представленням.
При проектуванні представлення для об'єкта варто відштовхуватися від користувальницької моделі, що думається. Нижче описаний приклад подібного підходу.
" Якщо для об'єкта існує аналог у реальному світі, спочатку накидайте його як візуальний об'єкт, а потім у виді електронного об'єкта.
" Якщо для об'єкта не існує аналога в реальному світі, придумайте його візуальний еквівалент (як якби він існував у реальному чи світі був видрукуваний). Потім зробіть ескіз електронної версії.
" Розглянете удосконалене представлення, що може бути гібридним чи мати елементи автоматизації і розширення візуального чи електронного представлення.
" Додайте відповідні елементи оформлення вікна на зразок заголовка вікна, рядків меню, графіки і т.д.
Корисне правило.
" Намагайтеся придумати два-три виразні представлення.
" При проектуванні представлень застосовуйте шрифти, колір і графіку, використовувані в системі за замовчуванням, причому виходите з припущення, що користувачі стануть змінювати розмір шрифтів.
" Випливайте посібнику з проектуванню у відношенні компонування, кольори і графіки.
Функціональні можливості. Можливості додатка, що містяться у вимогах і концептуальному проекті, відображаються на высокоуровневый проект екрана. Ці можливості включають спосіб відображення опцій на елементи керування. Наприклад, доступ до таких характеристик, як кількість і типи адрес, можна організувати декількома методами. При цьому виникає необхідність йти на ділові, проектні й інші компроміси.
" Якщо потрібно більш трьох адрес одночасно, для екрана Person Detaіls (Детальна інформація із суб'єкта) необхідне застосування різних методів.
" Якщо для визначеної можливості необхідні велика розширюваність і відповідні ресурси маються в наявності, проект модифікується для адаптації до більшої кількості адрес.
підході до вимог.
Можливості ПІ. Необхідно прийняти різноманітні рішення, що стосуються можливостей ПІ, наприклад, такі як використання "нерухомості" екрана ("нерухомість" - простір на диску, що визначає доступну ємність екрана. - Прим. ред.), а також пристосованість екрана до переносу в інші середовища.
" чи Належна детальна інформація із суб'єкта заміщати екран адресної чи книги відображатися у виді спливаючого меню?
" чи Вимагаються засоби навігації типу "хлібних крихт" (див. прим. до глави 9)?
" чи Необхідна команда Search (Пошук) для поглиблення в деталі?
" Яким образом повинна відображатися інформація, якщо в користувача відсутні права на її редагування?
Дані. Розташування й організація інформації і даних на екрані повинні відповідати пріоритетам користувачів. Наприклад, у деяких задачах теле-фонный номер повинний знаходитися безпосередньо після імені, а для інших задач після імені потрібно розташовувати адреса. До питань, що стосується даних, відносяться типи даних, довжина, формати, діапазони даних і значення, прийняті за замовчуванням. Важливу роль грає вибір відповідних елементів керування для даних.
Графіка. До найбільш простих питань компонування екрана відносяться питання вирівнювання міток і полів, ширина полів, межполевое простір, а також використання звичайних і видільних шрифтів (курсив, розрядка і т.п.). Більш складні питання виникають при використанні кольору, зображень і інших гра-фических можливостей.
Команди. Після того як об'єктні екрани спроектовані, настає час проектувати меню й інші командні механізми доступу до об'єктів. Цю процедуру непогано почати з матриці "об'єкт-операція", що містить усі припустимі команди для об'єкта. Операції над об'єктом оцінюються з погляду їхніх можливих деталізованих властивостей, їхній реализуемости в рамках заданих обмежень, а також деталізованого поводження.
Командам привласнюються імена і вони відображаються в механізми доступу ПІ на подобу меню, панелей інструментів, посилань і командних кнопок. У залежності від складності команд і вимог до даних приймається рішення про тім, чи належні команди виконуватися чи негайно ж для них потрібно діалоговий екран. Негайно виконувані команди не вимагають діалогового екрана, але реалізують зв'язану з ними операцію відразу після їхнього вибору.
Корисне правило.
" Як назви команд використовуйте прості, зрозумілі кінцевим поль-зователям терміни.
" Якщо виконання команди вимагає діалогу для збору необхідних команді вхідних даних, помістите після імені команди многоточие.
" Обновите матрицю "об'єкт-операція" на основі уведених вами імен команд із указівкою, де це необхідно, многоточия.
Спливаючі меню. Після того як об'єктні екрани спроектовані, настає час проектувати меню для об'єктів. Цю процедуру непогано почати з матриці "об'єкт-операція". Операція для заданого об'єкта утворять команди, ис-пользуемые в чи меню інших засобах доступу, таких як командні кнопки, панелі чи інструментів посилання в навігаційних структурах. У багатьох середовищах для об'єктів і елементів керування спливаючі меню передбачені за замовчуванням. Якщо кількість команд виявляється достатнім для того, щоб помістити їх у меню, можна ввести для них користувальницькі спливаючі меню. Якщо ж кількість операцій невелика, краще використовувати для них альтернативні механізми командного доступу.
Корисне правило.
" Спливаюче меню доцільно ввести, якщо в ньому передбачається використання більш двох команд для об'єкта. У противному випадку звернетеся до командних чи кнопок іншим методам доступу.
" При виборі порядку команд для спливаючого меню випливайте стандартам відповідної платформи.
" При призначенні символів клавіш, що прискорюють, для імен команд придер-живайтесь стандартів відповідної платформи.
" Якщо для розміщення й організації великої кількості команд потрібно введення підменю, при його проектуванні варто передбачати тільки один подуровень.
" Деструктивні операції, зв'язані, наприклад, з видаленням об'єкта, варто поміщати в меню на останнім місці.
Рядок меню і выпадающие меню. Стиль ПІ для кожної ОС має проектну структуру для відображення команд у структуру меню деякого виду. Рядок меню - основний механізм для доступу до команд у GUі-ориентированных системах. Навіть стосовно до екрана, усередині якого відображаються різні види об'єктів, уміст рядка меню залишається незмінним. Меню не додаються і не віддаляються з метою формування динамічно змінюється меню-структури. Однак уміст меню може змінюватися для відображення команд, що підходять для обраного об'єкта усередині екрана.
Команди, що поміщаються в спливаючі меню для об'єктів, відображаються в рядок меню і її выпадающие меню. При розміщенні команд у меню доцільно випливати стандартам відповідної платформи.
Корисне правило.
" Рядок меню використовується при достатній кількості команд для її запол-нения. У противному випадку для забезпечення користувальницького доступу до команд досить панелі інструментів, командних кнопок і посилань.
" Меню повинне містити кілька команд. Якщо команда одна, неї варто помістити в іншому меню.
" При виборі порядку команд для выпадающего меню випливайте стандартам відповідної платформи.
" При призначенні символів клавіш, що прискорюють, для імен команд випливайте стандартам відповідної платформи.
" При призначенні комбінацій клавіш для імен команд випливайте стандартам відповідної платформи.
" Якщо для розміщення й організації великої кількості команд потрібно введення підменю, при його проектуванні варто передбачати тільки один подуровень.
Панелі інструментів. Панель інструментів- дуже наочний і швидкий механізм доступу до команд у GUі-ориентированных додатках, що являє собою чи меню набір командних кнопок. За замовчуванням під рядком меню відображається рядок графічної чи текстової інформації. Часто використовувані команди містяться в панель інструментів, а додатка з великою кількістю команд можуть володіти навіть декількома панелями інструментів, що відображаються одночасно. Порівнянні методи існують також для WUІ- і HUІ - стилів.
Корисне правило.
" Часто використовувані команди доцільно помістити в панель інструментів.
" Для представлення команд на кнопках панелі інструментів використовуйте графічні зображення і термінологію, прийняті для відповідної платформи.
" Використовуйте для кнопок панелі інструментів спливаючі підказки.
У эстетических цілях кількість кнопок на панелі інструментів повинне бути достатнім для заповнення всієї чи ширини висоти простору екрана, исполь-зуемого під панель інструментів. У противному випадку може бути досить ис-пользования командних кнопок.
Командні кнопки. Якщо кількість команд невелика, для забезпечення доступу до команд, як правило, досить використання командних кнопок. Ко-мандные кнопки відображають текстове, графічне чи ж текстове і графічне представлення для команд.
Корисне правило.
" Для представлення команд на командних кнопках використовуйте графіку і терміни, прийняті для відповідної платформи.
" Використовуйте для командних кнопок спливаючі підказки.
Посилання. Стосовно до Web-сторінок використання гіперпосилань анало-гично використанню командних кнопок. Посилання служать для відображення інших Web-сторінок, запуску інших броузеров чи діалогів броузеров, а також інших додатків.
Корисне правило.
" Для представлення посилань використовуйте колір і стилі, прийняті для соот-ветствующей платформи.
" Використовуйте для посилань спливаючі підказки.
" Відображайте можливості команд на посилання і/чи меню.
" Термінологія, зв'язана з посиланнями, описує результат їхнього використання.
Проектування основних діалогів
Команди в матриці "об'єкт-операція" утворять основу всіх діалогів. З погляду проекту високого рівня, ПІ для основних команд і діалогів включає можливості, зв'язані з найбільше часто використовуваним, підданим помилкам, складними, що відрізняються підвищеною уразливістю і високим ризиком операціями.
Діалоги. Діалог (чи діалогове вікно) відображається для команд, продовження виконання яких вимагає явного введення даних користувачем. Команда Fіnd (Знайти) відображає діалог для введення текстового рядка (мал. 16.7) і є прикладом команди, що вимагає явного введення даних користувачем до того, як продовжити її виконання, що має зміст. Діалог Fіnd вимагає, як мінімум, використання наступних елементів.
" Рядок заголовка для піктограми закриття вікна (X).
" Заголовок вікна для імені команди.
" Поле введення для завдання користувачем текстового рядка, що повинна бути локалізована усередині об'єкта.
" Мітку для полючи.
" Командні кнопки для запуску (Fіnd) чи скасування (Cancel) команди Fіnd.
У залежності від платформи ОС можуть існувати й інші проектні рішення, наприклад, що стосуються включення в діалог піктограми системного меню, пик-тограммы What's Thіs? (Що це таке?) і клавіші, що прискорює, для полючи введення і ко-мандных кнопок. Що стосується Web-середовища, проектні альтернативи містять чи рішення про відображення діалогу Fіnd як окремої Web-сторінки усередині вікна броузера, чи про запуск окремого діалогу аналогічно GUі-интерфейсу, чи використання загальної пошукової області стосовно до всіх сторінок.
Для забезпечення необхідного явного користувальницького введення даних вибираються відповідні елементи керування. Текстове поле введення підходить для одержання від користувача вхідного тексту довільного виду, у той час як вікно списку служить для одержання вхідних даних, що належать фіксованій безлічі варіантів.
Find
End
Cancel
Корисне правило.
" При конструюванні діалогу для команди випливайте стандартам соответст-вующей платформи.
" Елементи введення розміщаються в діалоговому вікні в порядку, при якому найбільш прості і часто використовувані елементи розташовуються першими.
" Більш складні і менш використовувані елементи додаються в діалогове вікно після пріоритетних елементів.
" Кожному елементу введення привласнюється мітка.
" Для кожного елемента уведення вибирається елемент керування.
" При необхідності в діалогове вікно додаються командні кнопки.
Клавіші, що прискорюють, привласнюються елементам керування для введення і команд-ным кнопкам у відповідності зі стандартами, прийнятими для платформи ОС, а також у залежності від проектних рішень, обраних проектною бригадою. Для належного розміщення елементів усередині діалогового вікна необхідно випливати інструкціям із проектування графіки.
Корисне правило. Після ідентифікації набору базових елементів управ-ления спробуйте визуализировать елементи введення таким чином, щоб прима-нитка методи безпосереднього маніпулювання.
Прикладом елемента керування для більш складного діалогу Fіnd може служити діалог для вибору області дії команди (наприклад, починаючи з позиції курсору до кінця документа, до початку чи документа документ у цілому). При цьому як опції для представлення варіанта вибору можуть виступати три варіанти тексту в простому списку, що випадає, чи набір незалежних перемикачів. Однак у ка-честве більш наочної альтернативи може використовуватися графічний атрибут, що показує напрямок пошуку і його область.
Для діалогів, що містять велику кількість полів, і призначених для збору користувальницької інформації, вимагаються більш складні екрани. Проектні альтернативи для подібних складних діалогів включають наступні рішення (при-веденные в порядку їхньої переваги).
" Діалог із кнопками з більш-менш великою кількістю варіантів вибору.
" Діалог у виді записної книжки.
" Кнопки для відображення додаткових діалогових екранів.
Корисне правило. По можливості варто уникати множинних діалогових екранів для виконання команди. Згадаєте проблеми, що виникали в зв'язку з занадто великою кількістю чи екранів кроків задачі.
Діалоги завдання властивостей. При наявності можливостей настроювання об'єктів доречна підтримка команди Propertіes (Властивості) для групування опцій. Як альтернативу можна спроектувати набір команд для настроювання властивостей ПО. Типові імена команд для настроювання конкретних властивостей- Optіons (Параметри) і Customіze (Настроювання).
Для настроювання властивостей служать інші стандартні команди для чи додатка пакета, що працюють на даній платформі ОС. Існують також засобу настроювання властивостей ПІ на зразок включення/відключення панелі інструментів, шрифтів, кольору, включення/відключення рядка меню і включення/відключення оформлення вікна.
Корисне правило.
" Можливості настроювання варто використовувати до вигоди кінцевих пользо-вателей, а не для того, щоб уникнути прийняття конкретних рішень.
" При проектуванні можливостей настроювання випливайте прийнятим для плати-форми стандартам і стереотипам.
Безпосереднє маніпулювання. До команд, що звичайно не представлені в матриці "об'єкта-операції", відносяться операції безпосереднього маніпулювання. Усередині об'єктні і межобъектные операції вимагають проектування і підтримки.
" Прикладом усередині об'єктної операції служить перетаскування піктограми, що представляє об'єкт Person (Особистість) додатка Address Book на пик-тограмму, що представляє групу (Group) у рамках адресної книги.
" Прикладом меж об'єктної операції можна назвати перетаскування пиктограм-мы, що представляє об'єкт Person з додатка Address Book на піктограму-календар (Calendar), що представляє розклад зустрічей із суб'єктом.
Інший основний приклад меж об'єктного безпосереднього маніпулювання - перетаскування об'єкта на робочий стіл. Подібна операція приводить до зацікавлених проектних питань (наприклад, чи можна об'єкти додатка Address Book пе-ретаскивать на робочий стіл і чи припустимо підтримувати їхнє існування окремо і незалежно від додатка Address Book).
За допомогою технології "drag and drop" ("перетягнути і залишити") виконуються дві такі основні операції, як Move (Перемістити) і Сміттю (Копіювати). При на-личии спеціальних операцій, підтримки яких вимагає додаток, вони можуть
оброблятися за допомогою комбінацій "покажчик-клавіатура", уже не використовуваних власним ПІ.
Корисне правило.
" Операції безпосереднього маніпулювання повинні бути природними і погодженими.
" Спочатку варто проектувати базові команди (наприклад, Move і Сміттю).
" Не слід вводити операції заради операцій.
Один з корисних прийомів проектування складається в створенні окремої таблиці операцій типу "перетягнути і залишити" (табл. 16.1) для ідентифікації об'єктів, що підлягають переміщенню (об'єкт-джерело), і об'єктів, у які здійснюється переміщення (цільовий об'єкт), а також припустимих операцій, наприклад, переміщення і копіювання. Потім визначається специфічна семантика операцій разом зі специфічною інформацією і форматами, що стосуються обміну об'єктними даними. Нижче приведений приклад подібної таблиці для адресної книги з вказівкою операцій, здійснюваних у рамках одного додатка і між додатками.
Корисне правило. Задайтеся питанням, як можна використовувати покажчик, 1 щоб уникнути роботи з клавіатурою?
Ці можливості включають застосування списків вибору, візуального представ-ления даних, бігунків і кнопок. Корисно звернутися до операцій виділення й авто заповнення. Наприклад, замість використання тільки полів для введення даних у діалозі Search, можна передбачити список припустимих пошукових, що випадає, значень. Уведення значень у полючи також допустимо для формування змішаного пошуку.
Корисне правило. Варто уникати більше чим одного переходу покажчик-клавіатура для кожного екрана.
Операції з буфером обміну. Після того як робота над безпосереднім маніпулюванням довершена, на черзі встає проектування операцій з буфером обміну й інших операцій передачі даних. Потенційно з тими самими структурами даних можна працювати за допомогою операцій безпосереднього ма-нипулирования і буфера обміну, особливо якщо це стосується команд Move і Сміттю. Дуже корисний метод - конструювання таблиці для операцій буфера обміну як доповнення таблиці операцій безпосереднього маніпулювання.
Для вихідних і цільових об'єктів потрібно виконання робіт із планування, проектуванню, реалізації і тестуванню. Нижче приведені деякі проектні питання.
" Якщо дані об'єкта розташовані на сервері, які дані повинні выби-раться спочатку?
" Якщо операція перетаскування довершена, те коли дані будуть доставлене і керування повернуте користувачу?
Корисне правило.
" Краще давати, чим одержувати.
" Існує широкий простір для інтерпретації при проектуванні; визначаючи семантику операцій буфера обміну, виявляйте розсудливість.
Зворотний зв'язок з користувачем. Зворотний зв'язок для користувача, по-зволяющая тримати його в курсі подій, що відбуваються, має важливе значення, але іноді її буває важко передбачити. Критичний зворотний зв'язок для користувачів включає час відгуку, підтвердження завершення команд і повідомлення, зв'язані з помилками.
Проектна бригада може зробити висновок про те, що зворотний зв'язок за часом від-кліка, імовірно, необхідна виходячи з аналізу структури ПІ для ПО. Звичайно скільки ключових операцій займають більше часу, чим очікувалося (наприклад, початкове завантаження ПО, відкриття ще одного екрана в рамках того самого при-ложения, а також обчислювальні операції і команди, що вимагають інтенсивної роботи з диском).
Варто врахувати, що для кожної чи команди навігації рівня екрана може по-вимагатися зворотний зв'язок за часом відгуку. У табл. 16.2 представлені короткий виклад типових цілей у відношенні часу відгуку для ПІ і механізмів об-ратного зв'язку, що підтримують цей час відгуку.
" Операції на рівні натискання чи клавіш керування покажчиком включають переміщення курсору і вибір покажчика. Очікується, що результат цих операцій негайний, тобто ніякої затримки не відчувається.
" Відображення покажчика у формі піскових годин досить для часто використовуваних і простих дій, що включають відображення діалогу для команди, прості і короткі команди, виконувані негайно, а також завершення операцій типу "перетягнути і залишити".
" При виконанні складних і довгих команд відображається покажчик у формі піскових годин, динамічне повідомлення на зразок "развевающейся" пик-тограммы чи інше анимированное повідомлення.
Наступна категорія зворотного зв'язку відноситься до ситуації, коли користувачу потрібно підтвердження успішного завершення операції, У цих випадках звичайно найбільш перспективним виявляється активний підхід по забезпеченню погодженої, ненав'язливої, показуваної на екрані і напоминающей запрошення для введення зворотного зв'язку.
Корисне правило.
" Для початку варто передбачити покажчик у формі піскових годин у тих місцях, де можливі затримки обчислювального процесу.
" Необхідно передбачити механізми зворотного зв'язку, що не вимагають утручання користувача для видалення цих механізмів, коли потреба в них вичерпана.
" Незалежно від швидкості обчислювального процесу необхідно предус-мотреть зворотний зв'язок у тих місцях, де користувачу потрібно подт-верждение успішності його завершення.
Допомога користувачу. Забезпечення ефективного вмісту для спливаючих підказок, довідок, повідомлень, рядка поточного стану, наставляння,
підтримки експлуатації і друкованих матеріалів - важка справа. Звичайно ця робота починається з запізненням, а матеріали не одержують належної оцінки у відношенні ефективності. У результаті користувачі одержують марну допомогу, услож-ненную підтримку експлуатації, суперечливі і плутані чи повідомлення бес-смысленное навчання.
Своєчасне виконання роботи в цій області - дійсно важка зада-ча для проектної бригади. Аналогічно проектуванню ПІ, під час розробки проекту високого рівня виробляється узагальнений погляд на цю проблему. У про-цессе высокоуровневого проектування приймаються далеко не всі рішення, ка-сающиеся допомоги користувачам, однак для кожного виду передбачуваної допомоги створюється ряд самих типових прикладів.
Корисне правило.
" При проектуванні ПІ випливайте інтуїції, під якою тут розуміється не більше і не менше як думка, висловлене користувачем.
" Якомога раніше надавайте в розпорядження користувачів проектні рішення, що стосуються організації допомоги, для їхньої спільної оцінки.
" У залежності від вимог до продукту проектна бригада повинна рас-сматривать користувальницьку допомогу як останній засіб для подолання проектних проблем, зв'язаних з ПІ.
" Під час реалізації користувальницька допомога піддається таким же усилен-ным іспитам, як і сам продукт.
Стандарти платформи. У процесі проектування ви повинні використовувати стандарти й інструкції, розроблені для додатка. Не забувайте дотримувати стандартів платформи, що не обмежені стилем додатка.
Інсталяція, печатка й інші системні функції
Робота проектувальника ніколи не закінчується. На етапі высокоуровневого проектування завжди їсти що додати в проект в інтересах користувачів.
Інсталяція. Аналогічно іншим можливостям ПО, проектування підходу до інсталяції ПО дуже важливо для успіху проекту. У процесі інсталяції здійснюється завантаження і конфігурація ПО і структур даних, необхідних для функціонування програмного додатка. Програмне забезпечення може встановлюватися з використанням дискет, компакт-дисків, локальної чи мережі іntranet/Іnternet.
Інсталяція - перше, з чим зіштовхується користувач у багатьох програмних продуктах - у більшій частині визначає характер відносини користувача до продукту. З установкою обновлених версій продукту користувачі зіштовхуються протягом тривалого періоду часу. Іноді користувачі де инсталлируют про-граммное додаток, тому основна вимога кінцевих користувачів до процесу інсталяції полягає в тому, щоб він був надзвичайно простий. Нижче приведений перелік вимог, які можна, мабуть, розглядати як загальні при-менительно до більшості продуктів.
" На початку процесу установки варто перевірити, чи виконуються необхідні умови інсталяції (для апаратного і програмного забезпечення).
" На початку процесу задавайте тільки істотні питання.
" Після завершення інсталяції ПО повинно бути встановлене і сконфигу-рировано для роботи.
Якщо інсталяція складна через характер самого додатка, можна скористатися спеціальними програмними засобами інсталяції разом з інсталяційної "майстер" - програмою. Складне ПО може зажадати проектування спеціальних інсталяційних екранів. Аналогічно іншим компонентам ПІ, інсталяційне ПО вимагає, щоб проектування носило ітеративний і модульний характер.
Важливу роль грає застосування методів оцінки практичності до инсталляцион-ному ПО.
Корисне правило. Починати проектування інсталяції випливає якомога раніше .
Печатка. Обсяг роботи, необхідної для створення ефективних і практичних засобів печатки, звичайно недооцінюються і ці дії починаються, як правило, порівняно пізно. Ефективні схеми печатки складні в такому ж ступені, як і ефективні схеми екранних відображень через велику кількість наявних на сьогоднішній день типів принтерів і драйверів печатки. Системні можливості печатки корисні, однак для досягнення відповідного результату вимагаються значні зусилля, зв'язані з вивченням проблем і ітеративним підходом до їхнього рішення. Крім того, ці роботи, як правило, досить стомлюючі.
Деякі ключові рішення, визначені у вимогах і проекті, зв'язані з рівнем бажаної точності відтворення екранних відображень при печатці (WYSІWYP - What You See Іs What You Prіnt - що бачиш на екрані, те й одержиш при печатці. Принцип побудови екранного редактора текстів.- Прим. ред.). Ціль проектної бригади складається у визначенні точності відтворення в системі "дисплей-печатка", кількості наданих видів і можливостей попереднього перегляду при печатці.
Корисне правило.
" До проектування схем печатки варто приступати одночасно з початком проектування екранів.
" Виконання цієї задачі варто доручити спеціально призначеному для цього розроблювачу.
" Випливає в максимальному ступені використовувати можливості платформи.
Використання звуку. По можливості відкладете цю роботу до етапу низ-коуровневого проектування. Починайте думати над нею, вивчайте способи застосування звукових можливостей і їхнього контролю з боку користувача.
Інші можливості системи. У залежності від особливостей робочого столу і середовища необхідно розглянути такі можливості, як Кошик (Recycle Bіn), електронна пошта, утиліти синхронізації й інші. Користувачі привчаються застосовувати функції, що незвичайні чи незнайомі стосовно до більшості платформ. Проблема вимагає енергійних зусиль, краще приступити до неї раніш, ніж пізніше.
Визначення іншої необхідної роботи з проектування.
У процесі высокоуровневого проектування не потрібно здійснювати дизайн всіх екранів. Однак необхідно, як мінімум, ідентифікувати всі екрани і команди. Проектна бригада повинна переконатися в тім, що структура ПІ коректнаі і всі не-обходжені елементи керування визначені. Коли основні екрани і команди визначені, можна побудувати каталог, що дозволить згрупувати проектні роботи, що залишилися. Ці роботи включають проектування екранів, графіки й ін-формаційної підтримки. При невеликому везінні і ґрунтовному підході до про-ектированию можна домогтися значної подібності процесів высокоуровневого і низкоуровневого проектування, а також повторного використання відповідних методів і проектних рішень.
Закриття высокоуровневого проекту. Перш ніж закривати высоко-уровневый проект, зверніть увагу на ряд моментів. Отже, аналогічно закінченню концептуального проекту, корисно здійснити наступні кроки.
" Провести ревізію проектних рішень із залученням усієї бригади і всіх зацікавлених учасників проекту.
" Продемонструвати, яким образом задовольняються вимоги.
" Переконатися, що проект включений у контур керування змінами і зміни визначені.
" Цілком обновити план у відношенні плану-графіка робіт, необхідних навичок і ресурсів. Продовжити дослідження областей потенційного ризику.
Компоненти постачання для проекту зберігаються, а для їх наступної детальної розробки робляться копії.
Продовження обговорення проекту
Частина 1. Менеджер проекту вбіг у ваш офіс у збудженому стані. Вище керівництво і фахівці з маркетингу тільки що повідомили йому про необ-ходимости підтримки нових кишенькових і планшетних пристроїв з перевагою GUі-ориентированной операційної системи. Вони зажадали провести брифінг, присвячений наслідкам такого кроку для плану-графіка і ресурсів проекту, а також можливим наслідкам прийняття подібного варіанта для ПІ. Менеджер проекту вимагає провести 30-хвилинний брифінг, що відбудеться на цьому тижні, можливо, у рамках регулярно планованих ревізій проектних рішень.
Частина 2. Лідер проекту попросив вас обновити план-графіка деталізованих робіт аж до закриття высокоуровневого проекту разом з высокоуровневой оцінкою для низкоуровневого проекту. Через двох тижнів ви повинні представити вищому керівництву обновлений каталог екранів, які необхідно спроектувати і розробити.
Перелік робіт, що вам має бути виконати, що випливає.
" Після відновлення плану-графіка необхідно провести роботу з высокоу-ровневому проектування для програмного проекту. Не забудьте застосувати результати оцінки практичності і висловити міркування по ітеративному проектуванню.
" Необхідно відобразити екрани і функції на вимоги для проекту, щоб переконатися в тім, що нічого не забуто й у той же час не робиться нічого зайвого.
" Обновите структуру додатка довідника по конференціях, а також ключові об'єкти і командні екрани для кожного з підтримуваних середовищ.
" Не забудьте розглянути питання інтеграції іншого ПО (наприклад, при-ложения Address Book і офісних програмних додатків, що, можна, маються на підтримуваних платформах).
" Надайте приклади всіх методів взаємодії (таких як клавіатура, покажчик, метод "перетягнути і залишити", буфер обміну, комбінації клавіш, користувальницький зворотний зв'язок, допомога користувачу).
" Розглянете питання про те, яку форму прототипирования варто застосувати на даному етапі, і почніть використовувати методи прототипирования до соот-ветствующим екранів кожного середовища реалізації.
" Виділите ключові питання практичності, до яких можна звернутися, щоб запланувати оцінки практичності.
" Складіть прогноз у відношенні можливих змін, що будуть потрібні в рамках наступної ітерації.
" Продовжуйте проводити перевірки за столом, евристичні перегляди, про-цедуры наскрізного контролю і застосовувати інші методи спільної розробки.
Через три тижні заплановане проведення попередньої ревізії высоко-уровневого проекту. Перегляди з користувачами і вищим керівництвом заплани-рованы через тиждень після попередньої ревізії. Подбайте про те, щоб представити высокоуровневый проект, що показує, як поводиться продукт стосовно до GUІ-, WUІ- і HUі-средам.