ТРПО-лекции

Скачано с сайта http://ivc.clan.su

Базовый WUI-стиль (Web User Interface) использует визуальные или текстовые ги-41 перссылки для навигации в рамках приложения. В зависимости от структуры гиперссылок навигация приводит к отображению Web-страниц в иерархии приложения внутри одного GUI-окна (браузера). Браузер обеспечивает меню для Webприложения. К наиболее распространѐнным элементам WUI-интерфейса относятся баннеры (заголовки), навигационные панели и гиперссылки. Баннер представляет собой визуальный заголовок, отображаемый вверху Web-страницы. Навигационная панель – это список вариантов выбора гиперссылок, обеспечивающих доступ к информации. Гиперссылка представляет собой вариант выбора, который отображает следующую страницу информации или перемещает фокус отображения на другую область той же страницы.

2.1. Эволюция интерфейса человек-компьютер

Можно идентифицировать четыре качественно отличных друг от друга поколения:

1.В 50-е и в начале 60-х годов прошлого века компьютеры работали, в основном, в пакетном режиме, используя перфокарты для ввода и устройство построчной печати для вывода. Можно утверждать, что не было смысла говорить о пользовательском интерфейсе, так как не существовало самого понятия интерактивного пользователя в современном смысле этого слова.

2.C начала 60-х до начала 80-х годов ХХ века господствовал режим разделения времени на мейнфреймах и мини-компьютерах с использованием алфавитноцифровых дисплеев, когда пользователи взаимодействовали с компьютером путѐм ввода с клавиатуры команд с параметрами. Этот тип взаимодействия захватил и век персональных компьютеров с MS DOS и операционной системой Unix.

3.Ещѐ в 70-е годы ХХ века в научно-исследовательском центре Xerox PARC были созданы графические интерфейсы. Эти интерфейсы принято обозначать аббре-

виатурой WIMP (Windows – Icons – Menus – Pointing device), что отражает задей-

ствованные интерактивные элементы (окна, пиктограммы, меню) и позиционирующее устройство (обычно мышь). Именно интерфейсы этого типа, завоевавшие популярность вместе с Macintosh в 1984 году и позднее скопированные в MS Windows, доминируют по сегодняшний день.

4.Сейчас на повестке дня новые формы, которые иногда называют post-WIMP- интерфейсы. Они не используют меню, формы и панели инструментов. Вместо них при задании операций и операндов упор идет на обучающие примеры, жесты и распознавание речи. Соответствующие исследования начались в 90-х годах прошлого века, но пока ещѐ post-WIMP-интерфейсы не получили широкого распространения.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Главная задача проектирования интерфейса пользователя – создать описание для реальной реализации системы: специфицировать требуемые окна, их элементы и навигационные детали.

Процесс разработки интерфейса включает решение следующих задач:

1.Уточнение требований к ПС и его функциональных возможностей.

2.Изучение оборудования и настольных программ типичного пользователя (на-

сколько часто будет использоваться данное ПС: несколько раз в неделю или в час, какой объѐм работ должен выполнять пользователь).

3.Выбор элементов пользовательского интерфейса. Это итерационный процесс. Сначала проектируется интерфейс для реализации наиболее критичных функций ПС, и для него выбираются элементы.

4.Постоянное согласование предложенных решений с мнением пользователей. Важно знать, что из увиденного больше всего понравилось пользователям, и что они хотели бы получить ещѐ.

5.Учѐт мнения пользователей-новичков. Следует ориентироваться не на опытных пользователей, а на новичков. Важно обсуждать принятые решения с каждым пользователем приложения.

Авторами наиболее удачных интерфейсов являлись специалисты в области психологии, вычислительной техники и графики.

2.3. Модели пользовательского интерфейса

Возможны следующие способы моделирования интерфейса пользователя:

1.Использовать простое дерево, дающее полезную информацию о том, как организована навигация в пользовательском интерфейсе.

2.Представить интерфейс в виде диаграмм классов (рис. 2-1), разбивая окна на более мелкие части, используя обобщение и агрегацию. UML-диаграммы моделируют структуру интерфейса: вводимые данные и операции над ними, а также отношения между окнами интерфейса.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 2-1. Диа-

грамма классов интерфейса пользователя

3.Представить динамику взаимодействия между пользователем и системой, используя UML-диаграммы состояний для моделирования навигации по окнам (рис. 2-2). Из всех допустимых элементов диаграмм используются состояния и переходы.

Рис. 2-2. Диаграмма состояний интерфейса пользователя

Последний способ предполагает использование стереотипов видов деятельности (элементов управления окном) и стереотипов состояний (окон).

Виды деятельности (элемент управления окном) – Activity:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

2.4. Требования к пользовательскому интерфейсу

Среди множества важных требований существует их общий набор, который необходимо учитывать при проектировании интерфейса пользователя. Согласно этому набору интерфейс должен обеспечить:

−действия пользователя;

−настройку интерфейса;

−интерактивную среду (диалоги);

−прямые манипуляции;

−возврат, где это возможно, где невозможно – запрос подтверждения;

−подсказки, необходимые пользователю при использовании системы;

−соответствующее раскрытие возможностей;

−простое восстановление при ошибках.

Кроме того, пользовательский интерфейс должен:

−использовать метафоры, знакомые пользователю;

−являться внутренне непротиворечивым (одинаковые действия должны иметь одинаковый интерфейс);

−устранять возможные ошибки пользователя, где это возможно;

−сопровождать визуальными репликами действия пользователя.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Принципы служат разработчикам основанием для построения интерфейса.

2.5.1. Контроль на стороне пользователя

Основной смысл этого принципа в том, что пользователь инициирует действия ПС. Если в результате этого действия контроль переходит к приложению, то пользователь получает обратную связь (например, в виде индикатора состояния).

2.5.2. Обратная связь

Этот принцип дополняет первый. Для обратной связи необходимо встроить визуальные или аудио-подсказки для каждого инициируемого пользователем события. В большинстве случаев указатель в форме песочных часов или индикатор ожидания представляют достаточный уровень обратной связи, чтобы понять, что приложение что-то делает. Иногда может потребоваться вывод поясняющего сообщения.

2.5.3. Эстетичность и удобство

Эстетичность влияет на зрительное восприятие системы.

Удобство касается лѐгкости, простоты, эффективности, надѐжности и продуктивности в использовании интерфейса.

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

Необходимо избегать сложных структур представления информации на экране. В сложных приложениях простота интерфейса достигается:

1.С помощью подхода Разделяй и властвуй! за счѐт последовательного раскрытия информации таким образом, что она отображается только тогда, когда в ней возникает необходимость, и возможно, в разных окнах.

2.С помощью правила шести из области психологии: "Большинство людей за один раз могут запомнить не более шести понятий". Например, в одну линейку меню включать не более шести пунктов, каждый из которых содержит не более шести опций.

2.5.4. Согласованность

Принцип согласованности имеет два аспекта:

1.Соответствие информационной технологии пользователя. Интерфейс должен предоставлять пользователю привычную и понятную ему среду, содержать пункты меню, соответствующие функциям обработки данных и расположенные в естественной последовательности использования.

2.Соответствие существующим стандартам программирования. К существую-

щим относятся стандарты по расположению объектов на экране и последовательному использованию элементов интерфейса в рамках ПС. Это значит, что необходимо сохранять стандартизованное назначение графических объектов и

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

по возможности их месторасположение на экране. Элементы, общие для46 личных меню и диалогов, следует размещать в одном месте. Например, кнопки OK и Cancel должны всегда располагаться одинаково в разных диалоговых окнах.

2.5.5. Настройка

Настройка интерфейса – это задача приспособления ПС к требованиям различных пользователей.

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

Индивидуальный пользователь может настроить интерфейс под личные нужды. Например, изменить размеры колонки при просмотре строк с последующим сохранением этих изменений. При обращении к этому же диалогу в будущем изменѐнные данные учитываются.

2.5.6. Терпимость к ошибкам

Интерфейс должен разрешать пользователям экспериментировать и совершать ошибки, проявляя толерантность к ним. Этот принцип подразумевает многоуровневую систему отмены операций.

2.6. Правила разработки пользовательского интерфейса

Фундаментальное правило разработчика:

Пользователи интерфейса должны принимать участие во всех этапах его создания, начиная с выработки основной концепции.

Разработка интерфейса начинается после чѐткого определения функций системы. Существует четыре правила процесса разработки пользовательского интерфейса:

1.Понять назначение ПС во всех деталях. В процессе проектирования интерфейса необходимо спрашивать у пользователей о функциях, к которым они больше обращаются, выделяя те из них, которые используются чаще всего и определяют стандартный поток операций.

2.Создание интерфейса – это работа сбалансированной группы. Для удачного интерфейса требуется хорошая команда (или хотя бы участие консультантов по разработке интерфейсов и графическим средствам). В идеале в создании интерфейса должны принимать участие специалисты трѐх областей:

−аналитик, который выясняет мнение пользователей об основных элементах интерфейса и специфицирует их;

−проектировщик интерфейса;

−создатель графики.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

3.За создание проекта интерфейса должен отвечать один человек. Он может за-47 ниматься проверкой удобства интерфейса, созданием документации, обучением пользователей, но он не должен участвовать в реализации интерфейса.

4.Прототипирование и проверка интерфейса. Создание прототипа позволяет снизить затраты на реализацию проекта. Следует использовать итерационный цикл проектирования; включать тестирование интерфейса как часть всего процесса создания системы; учитывать замечания пользователей.

2.7. Критерии качества пользовательского интерфейса

Критерии качества пользовательского интерфейса обозначаются аббревиатурой

SAPCO (Simple – Aesthetic – Productive – Customizable – Other) и не зависят от стиля пользовательского интерфейса.

2.7.1. Простой – Simple

Хороший интерфейс не требует использования справочной системы, чтобы начать выполнять с еѐ помощью простые задачи конечных пользователей. Пользователь нуждается лишь в объяснении того, как достичь результата.

2.7.2. Эстетичный – Aesthetic

Хороший интерфейс широко использует графический дизайн и визуализацию.

2.7.3. Продуктивный – Productive

Хороший интерфейс избегает сложной иерархии окон и/или экранов, а также ненужных действий с мышью и клавиатурой (минимизирует усилия пользователя). Он соответствует решаемой задаче, снисходителен к пользователю и не наказывает его за небольшие ошибки.

2.7.4. Настраиваемый – Customizable

Интерфейс предоставляет выбор пользователю и обладает свойством приспособляемости. Он обеспечивает множественные представления, шрифты и цвет.

2.7.5. Другой – Other

Существует бесчисленное множество других критериев, большинство из которых – разновидности названных. Например, лѐгкость, эффективность, надѐжность и т.д. Главный критерий из других заключается в том, что интерфейс делает то, что от него ожидает пользователь.

3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Объектно-ориентированный подход (object-oriented approach) подразумевает разделение системы на компоненты с разной степенью детализации. В основе этой декомпозиции лежат объекты и классы. Классы связаны разнообразными отношениями и обмениваются сообщениями, вызывающие операции над объектами. Объектный подход к разработке систем полностью соответствует требованиям итератив-

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 48

ного и поступательного процесса разработки, в котором постепенно уточняется, изменяется и усовершенствуется единая модель для реализации системы, удовлетворяющей пользователя.

Преимущества объектно-ориентированного подхода:

1.Сложность принимает форму иерархии. Сложные ПС состоят из взаимозави-

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

2.Иерархические системы состоят из немногих типов подсистем, которые ком-

бинируются в различных сочетаниях.

3.Связи внутри компонентов обычно сильнее межкомпонентных, что позволяет относительно независимо разрабатывать каждый компонент.

4.Компоненты могут повторно использоваться в различных системах.

5.Любая работающая сложная система получается только как развитие работаю-

щей простой системы.

6.Выбор примитивных элементов, из которых строится ПС, относительно произволен и оставляется на усмотрение разработчиков.

7.Гибкая архитектура объектно-ориентированных систем относительно легко поддаѐтся модификации.

Несмотря на перечисленные достоинства, объектно-ориентированная парадигма (как способ создания высокоуровневых проектов) подвергается критике по следующим причинам, которые относят к еѐ недостаткам:

1.Усложнение методологии. Для успешного использования подхода требуется наличие определѐнного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение структурного подхода, когда декомпозиция ПС осуществляется не по классам, а по функциям.

2.Сложность реализации. Реализация на объектно-ориентированном языке программирования, как правило, приводит к построению требовательного к ресурсам приложения.

3.Высокая стоимость инструментальных средств по автоматизации процесса разработки.

3.1. Трѐхуровневая модель приложения

Большинство ПС разрабатываются на основе трѐхзвенного архитектурного стиля (Three-tiered Architecture), состоящего из трѐх базовых уровней:

1.Уровень представления (User Service).

2.Уровень логики приложения или бизнес-правила (Business Service).

3.Уровень управления данными (Data Service).

3.1.1. Уровень представления

Классы этого уровня содержат логику приложения, которая получает входные данные от внешнего источника, и предоставляет информацию внешнему источнику. В

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 49

большинстве случаев в качестве внешнего источника выступает пользователь, хотя это может быть также некоторое устройство автоматизированного ввода-вывода. При помощи классов уровня представления осуществляется навигация пользователя через приложение, и (как опция) контроль ограничений для вводимых данных.

3.1.2. Бизнес-правила

Классы уровня бизнес-правил содержат логику приложения, которая управляет функциями и процессами, выполняемыми ПС. Эти функции и процессы вызываются или объектами классов уровня представления (когда пользователь запрашивает сведения), или другими системными функциями. В общем, классы логики приложения выполняют манипулирование данными.

3.1.3. Уровень управления данными

Классы этого уровня содержат логику, которая по существу является интерфейсом с системой управления хранилищем данных. Например, с системой управления базами данных (СУБД), иерархической файловой системой, либо с другим источником данных типа внешней программной системы. Функции этого уровня вызываются объектами классов логики приложения, хотя в простых приложениях они могут вызываться непосредственно объектами классов уровня представления.

3.2. Распределѐнная вычислительная архитектура

Схема распределѐнной вычислительной архитектуры показана на рис. 3-1.

Рис. 3-1. Распреде-

лѐнная вычислительная архитектура

Свойства:

1.Может существовать любое количество компонентов каждого типа внутри одной программной системы.

2.Компоненты могут разделяться любым числом прикладных систем.

3.Каждый компонент разрабатывается с использованием оптимального для его структуры инструментального средства.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 50

4. Компоненты взаимодействуют друг с другом на основе абстрактного фейса, который скрывает основную функцию, выполняемую компонентом.

5.Компоненты физически могут размещаться на одной или более аппаратных системах.

6.Распределѐнная вычислительная инфраструктура должна обеспечивать размещение, защиту и услуги связи для компонентов приложения.

3.3. Пакеты классической модели

Пакеты классической модели ПС показаны на рис. 3-2.

Рис. 3-2. Пакеты классической модели

Пакет Human Interaction (HI) – Взаимодействие с человеком содержит классы,

обеспечивающие отображение, ввод и вывод данных.

Пакет Problem Domain (PD) – Проблемная область содержит логические про-

граммные абстракции, точно соответствующие моделируемой предметной области и нейтральные по отношению к реализации (независимые от реализации). Они знают или не знают совсем о классах других пакетов.

Пакет Data Management (DM) – Управление данными представляет классы, обеспечивающие интерфейс между классами предметной области и СУБД. Эти классы отвечают за доступ к хранимым данным и выполняют все необходимые операции над ними. Чаще всего они соответствуют классам проблемной области, которые нужно постоянно хранить во внешней памяти и искать.

Пакет System Interaction (SI) – Взаимодействие систем содержит классы, которые поддерживают интерфейс между классами предметной области и другими системами (внешними по отношению к данной системе) или устройствами.

Каждый класс ПС соответствует одному из пакетов (HI, PD, DM, SI), причѐм разделение классов на пакеты не означает их обязательного физического разделения.

Практическое применение этого шаблона для решения конкретных задач позволяет получить типовые решения типичных проблем в контексте решаемой задачи.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011