Файл: ТРПО-лекции.pdf

Скачано с сайта 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