лекции. Лекции по дисциплине _Разработка программных модулей_. Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование 2 Содержание
 Скачать 0.77 Mb.
|
|
Тема 7 Разработка пользовательского интерфейса Правила разработки интерфейсов пользователя Правило 1: дать контроль пользователю Принципы, которые дают пользователю контроль над системой: 1)использовать режимы благоразумно; 2)предоставить пользователю возможность выбирать: работать либо мышью, либо клавиатурой, либо их комбинацией; 3)позволить пользователю сфокусировать внимание; 4)демонстрировать сообщения, которые помогут ему в работе; 5)создать условия для немедленных и обратимых действий, а также обратной связи; 6)обеспечить соответствующие пути и выходы; 7)приспосабливайте систему к пользователям с различным уровнем подготовки; 8)сделать пользовательский интерфейс более понятным; 9)дать пользователю возможность настраивать интерфейс по своему вкусу; 10)разрешить пользователю напрямую манипулировать объектами интерфейса; Правило 2: уменьшить нагрузку на пользователя 33 Основанная на знании того, как люди хранят и запоминают информацию, сила компьютерного интерфейса должна защитить память людей от излишней загруженности. Принципы, позволяющие снизить нагрузку на память пользователя: 1)не загружать кратковременную память; 2)полагаться на распознавание, а не на повторение; 3)представить визуальные заставки; 4)предусмотреть установки по умолчанию, команды Undo и Rendo; 5)предусмотреть "быстрые" пути; 6)активировать синтаксис действий с объектами; 7)использовать метафоры из реального мира; 8)применять раскрытие и объяснение понятий и действий; 9)увеличить визуальную ясность. Правило 3: сделать интерфейс совместимым Совместимость — ключевой аспект для использования интерфейса. Однако не следует во что бы то ни стало стремиться к ней. Одним из основных преимуществ последовательности является то, что пользователи могут перенести свои знания и навыки из старой программы, которой они пользовались раньше, в новую. Принципы создания совместимости интерфейса: 1)проектирование последовательного интерфейса; 2)общая совместимость всех программ; 3)сохранение результатов взаимодействия; 4)эстетическая привлекательность и цельность; 5)поощрение изучения; Требования к интерфейсу Основные требования к пользовательскому интерфейсу: функциональность (соответствие задачам пользователя); соответствие технологии; 34 понятность и логичность; обеспечение высокой скорости работы пользователя; обеспечение защиты от человеческих ошибок; быстрое обучение пользователя; субъективное удовлетворение пользователя. На основе общих требований к пользовательскому интерфейсу сформирована система требований к его элементам управления. Требования к названию (тексту) элементов управления: название элемента должно отражать его функцию; названия элементов должны быть краткими, но понятными пользователю; наиболее значимое слово должно стоять в названии элемента первым; для названия элемента, запускающего действие, целесообразно использовать глагол в форме инфинитива; если элемент меню служит для запуска окна с продолжением диалога, то в конце его названия следует ставить многоточие; пиктограммами следует снабжать только самые важные элементы меню Требования к расположению элементов управления: элементы меню следует группировать; группы следует разделять разделительными полосками либо «визуальными паузами»; часто используемые элементы целесообразно располагать в левой верхней части экрана, редко используемые - в правой нижней части; терминационные кнопки (т.е. командные кнопки, управляющие окном, например, «Ок», «Отмена», «Применить», «Закрыть») должны быть расположены либо внизу окна, либо в правой его части (т.е. в той части окна, которая сканируется взглядом в последнюю очередь); хорошо, если диалоговое окно читается, как текст: один элемент управления однозначно преобразовывается во фрагмент предложения, а единая группа элементов - в целое предложение. Требования к оформлению чекбоксов и радиокнопок: не следует нарушать сложившуюся традицию: чекбоксы выглядят как квадраты, а радиокнопки - как кружки; и чекбоксы, и радиокнопки 35 желательно расставлять по вертикали, поскольку это значительно ускоряет поиск нужного элемента; радиокнопки всегда должны находиться в рамке группировки, а для чекбоксов это необязательно; в группе радиокнопок как минимум одна радиокнопка должна быть проставлена по умолчанию; каждая подпись чекбокса и радиокнопки должна однозначно показывать эффектот выбора соответствующего элемента; поскольку радиокнопки и чекбоксы не вызывают немедленного действия, формулировать подписи к ним лучше всего в форме существительных, хотя возможно использование глаголов; подписи к стоящим параллельно кнопкам лучше стараться делать примерно одинаковой длины; все подписи лучше делать позитивными (т.е. не содержащими отрицания); не следует повторять в подписях одни и те же слова, меняя только окончания подписей (например, «Показывать пробелы» и «Показывать табуляции») - лучше перенести повторяющееся слово в рамку группировки; если подпись не помещается в одну строку, то индикатор кнопки (кружок или квадрат) следует выравнивать по первой строке подписи; подписи к чекбоксам и радиокнопкам должны быть нажимабельными (это связано с тем, что для быстроты и точности работы пользователю нужны большие кнопки); при необходимости заблокировать элемент чекбокса или радиокнопки, желательно визуально ослаблять не только индикатор кнопки (квадрат или круг), но и подпись к нему. Анализ интерфейса Анализ сложности интерфейса — это метод оценки юзабилити конкретной задачи или набора задач, который не требует непосредственного участия пользователя и даёт количественные результаты. Какие параметры нужно оценить 1. Изменения контекста: движение пользователя внутри продукта для завершения шага. Пример: незначительное изменение контекста при переносе пользователя на новую страницу 36 2. Помощь в навигации: предоставляется поддержка для начала и завершения шага. Пример: текст о том, как начать работу, поможет узнать основные возможности продукта 3. Входные параметры: информация, которую пользователь должен уточнить для завершения шага. Пример: пользователю нужно выбрать параметры с помощью кнопок 4. Обратная связь системы: реакция системы на действия пользователя во время выполнения шага. Пример: журнал уведомлений в режиме реального времени отражает шаги, предпринятые пользователем 5. Обратная связь об ошибках: реакция системы на типичные ошибки пользователя. Пример: это сообщение об ошибке рассказывает пользователю, почему шаг не удался, но не даёт рекомендаций по устранению проблемы 6. Новые понятия: информация, которую пользователь должен понять для конкретного шага. Пример: модальное окно предоставляет обзор функций, но если нажать на ссылку для получения дополнительной информации, это выведет пользователя из продукта Универсальных рекомендаций в анализе интерфейсов вообще не бывает. Именно поэтому UX-аудит не сводится к составлению документа. Самое главное в задачах анализа сложившегося интерфейса — это предметное обсуждение результатов с теми, кто в силах что-то изменить. С владельцами продукта, разработчиками и другими специалистами. И вся квалификация эксперта сосредоточена именно в этом разговоре, а не в подготовительных материалах к нему. Основные возможные проблемы: Непонятные элементы и сложная процедура решения базовых задач пользователя Плохо работает поиск и фильтрация товаров Непонятное описание характеристик и некорректное изображение товара Фотографии товара не дают представления о внешнем виде товара. Непонятные условия акций, спецпредложений, товаров в подарок 37 Непонятные формулировки и условия акций. Неправильный подбор сопутствующих товаров и неудобное для пользователя размещение на сайте Сопутствующие товары размещены перед характеристиками, и пользователь их проматывает, не посмотрев. Тема 8 Архитектурные шаблоны в проектировании Назначение и виды паттернов Паттерн проектирования — это часто встречающееся решение определённой проблемы при проектировании архитектуры программ. В отличие от готовых функций или библиотек, паттерн нельзя просто взять и скопировать в программу. Паттерн представляет собой не какой-то конкретный код, а общую концепцию решения той или иной проблемы, которую нужно будет ещё подстроить под нужды вашей программы. Паттерны часто путают с алгоритмами, ведь оба понятия описывают типовые решения каких-то известных проблем. Но если алгоритм — это чёткий набор действий, то паттерн — это высокоуровневое описание решения, реализация которого может отличаться в двух разных программах. Если привести аналогии, то алгоритм — это кулинарный рецепт с чёткими шагами, а паттерн — инженерный чертёж, на котором нарисовано решение, но не конкретные шаги его реализации. Описания паттернов обычно очень формальны и чаще всего состоят из таких пунктов: проблема, которую решает паттерн; мотивации к решению проблемы способом, который предлагает паттерн; структуры классов, составляющих решение; примера на одном из языков программирования; особенностей реализации в различных контекстах; 38 связей с другими паттернами. Такой формализм в описании позволил создать обширный каталог паттернов, проверив каждый из них на состоятельность. Самые низкоуровневые и простые паттерны — идиомы. Они не универсальны, поскольку применимы только в рамках одного языка программирования. Самые универсальные — архитектурные паттерны, которые можно реализовать практически на любом языке. Они нужны для проектирования всей программы, а не отдельных её элементов. Кроме того, паттерны отличаются и предназначением: Порождающие паттерны беспокоятся о гибком создании объектов без внесения в программу лишних зависимостей. Структурные паттерны показывают различные способы построения связей между объектами. Поведенческие паттерны заботятся об эффективной коммуникации между объектами. Порождающие паттерны Abstract Factory, Builder, Factory method Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов. Паттерн Фабричный метод предлагает создавать объекты не напрямую, используя оператор new, а через вызов особого фабричного метода. Объекты всё равно будут создаваться при помощи new, но делать это будет фабричный метод. Чтобы эта система заработала, все возвращаемые объекты должны иметь общий интерфейс. Подклассы смогут производить объекты различных классов, следующих одному и тому же интерфейсу. Пока все продукты реализуют общий интерфейс, их объекты можно взаимозаменять в клиентском коде. Для клиента фабричного метода нет разницы между этими 39 объектами, так как он будет трактовать их как некий абстрактный Транспорт. Для него будет важно, чтобы объект имел метод доставить, а как конкретно он работает — не важно. Абстрактная фабрика — это порождающий паттерн проектирования, который позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов. Для начала паттерн Абстрактная фабрика предлагает выделить общие интерфейсы для отдельных продуктов, составляющих семейства. Так, все вариации кресел получат общий интерфейс Кресло, все диваны реализуют интерфейс Диван и так далее. Все вариации одного и того же объекта должны жить в одной иерархии классов. Далее вы создаёте абстрактную фабрику — общий интерфейс, который содержит методы создания всех продуктов семейства (например, создатьКресло, создатьДиван и создатьСтолик). Клиентский код должен работать как с фабриками, так и с продуктами только через их общие интерфейсы. Это позволит подавать в ваши классы любой тип фабрики и производить любые продукты, ничего не ломая. Для клиентского кода должно быть безразлично, с какой фабрикой работать. Строитель — это порождающий паттерн проектирования, который позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов. Паттерн Строитель предлагает вынести конструирование объекта за пределы его собственного класса, поручив это дело отдельным объектам, называемым строителями. Строитель позволяет создавать сложные объекты пошагово. Промежуточный результат всегда остаётся защищён. Паттерн предлагает разбить процесс конструирования объекта на отдельные шаги (например, построитьСтены, вставитьДвери и другие). Чтобы создать объект, вам нужно поочерёдно 40 вызывать методы строителя. Причём не нужно запускать все шаги, а только те, что нужны для производства объекта определённой конфигурации. Порождающие паттерны: Prototype, Singleton Прототип — это порождающий паттерн проектирования, который позволяет копировать объекты, не вдаваясь в подробности их реализации. Паттерн Прототип поручает создание копий самим копируемым объектам. Он вводит общий интерфейс для всех объектов, поддерживающих клонирование. Это позволяет копировать объекты, не привязываясь к их конкретным классам. Обычно такой интерфейс имеет всего один метод clone. Реализация этого метода в разных классах очень схожа. Метод создаёт новый объект текущего класса и копирует в него значения всех полей собственного объекта. Так получится скопировать даже приватные поля, так как большинство языков программирования разрешает доступ к приватным полям любого объекта текущего класса. Объект, который копируют, называется прототипом (откуда и название паттерна). Когда объекты программы содержат сотни полей и тысячи возможных конфигураций, прототипы могут служить своеобразной альтернативой созданию подклассов. Одиночка — это порождающий паттерн проектирования, который гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Одиночка решает сразу две проблемы, нарушая принцип единственной ответственности класса. o Гарантирует наличие единственного экземпляра класса. o Глобальный доступ к одному объекту Все реализации одиночки сводятся к тому, чтобы скрыть конструктор по умолчанию и создать публичный статический метод, который и будет контролировать жизненный цикл объекта-одиночки. 41 Если у вас есть доступ к классу одиночки, значит, будет доступ и к этому статическому методу. Из какой точки кода вы бы его ни вызвали, он всегда будет отдавать один и тот же объект. Структурные паттерны: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy Адаптер — это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе. Вы можете создать адаптер. Это объект-переводчик, который трансформирует интерфейс или данные одного объекта в такой вид, чтобы он стал понятен другому объекту. При этом адаптер оборачивает один из объектов, так что другой объект даже не знает о наличии первого. Например, вы можете обернуть объект, работающий в метрах, адаптером, который бы конвертировал данные в футы. Адаптеры могут не только переводить данные из одного формата в другой, но и помогать объектам с разными интерфейсами работать сообща. Мост — это структурный паттерн проектирования, который разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга. Паттерн Мост предлагает заменить наследование агрегацией или композицией. Для этого нужно выделить одну из таких «плоскостей» в отдельную иерархию и ссылаться на объект этой иерархии, вместо хранения его состояния и поведения внутри одного класса. Компоновщик — это структурный паттерн проектирования, который позволяет сгруппировать множество объектов в древовидную структуру, а затем работать с ней так, как будто это единичный объект. Декоратор — это структурный паттерн проектирования, который позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки». 42 Наследование — это первое, что приходит в голову многим программистам, когда нужно расширить какое-то существующее поведение. Но механизм наследования имеет несколько досадных проблем. Одним из способов обойти эти проблемы является замена наследования агрегацией либо композицией. Это когда один объект содержит ссылку на другой и делегирует ему работу, вместо того чтобы самому наследовать его поведение. Как раз на этом принципе построен паттерн Декоратор. Фасад — это структурный паттерн проектирования, который предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку. Фасад — это простой интерфейс для работы со сложной подсистемой, содержащей множество классов. Фасад может иметь урезанный интерфейс, не имеющий 100% функциональности, которой можно достичь, используя сложную подсистему напрямую. Фасад полезен, если вы используете какую- то сложную библиотеку со множеством подвижных частей, но вам нужна только часть её возможностей. Легковес — это структурный паттерн проектирования, который позволяет вместить бóльшее количество объектов в отведённую оперативную память. Легковес экономит память, разделяя общее состояние объектов между собой, вместо хранения одинаковых данных в каждом объекте. Паттерн Легковес предлагает не хранить в классе внешнее состояние, а передавать его в те или иные методы через параметры. Таким образом, одни и те же объекты можно будет повторно использовать в различных контекстах. Но главное — понадобится гораздо меньше объектов, ведь теперь они будут отличаться только внутренним состоянием, а оно имеет не так много вариаций. Заместитель — это структурный паттерн проектирования, который позволяет подставлять вместо реальных объектов специальные объекты-заменители. Эти объекты перехватывают вызовы к оригинальному объекту, позволяя сделать что-то до или после передачи вызова оригиналу. 43 Поведенческие паттерны: Iterator, Observer, State, Strategy, Visitor, Template method Итератор — это поведенческий паттерн проектирования, который даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления. Наблюдатель — это поведенческий паттерн проектирования, который создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах. Состояние — это поведенческий паттерн проектирования, который позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта. Стратегия — это поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы. Паттерн Стратегия предлагает определить семейство схожих алгоритмов, которые часто изменяются или расширяются, и вынести их в собственные классы, называемые стратегиями. Вместо того, чтобы изначальный класс сам выполнял тот или иной алгоритм, он будет играть роль контекста, ссылаясь на одну из стратегий и делегируя ей выполнение работы. Чтобы сменить алгоритм, вам будет достаточно подставить в контекст другой объект-стратегию. Важно, чтобы все стратегии имели общий интерфейс. Используя этот интерфейс, контекст будет независимым от конкретных классов стратегий. С другой стороны, вы сможете изменять и добавлять новые виды алгоритмов, не трогая код контекста. Посетитель — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться. Паттерн Посетитель предлагает разместить новое поведение в отдельном классе, вместо того чтобы множить его сразу в нескольких классах. Объекты, с 44 которыми должно было быть связано поведение, не будут выполнять его самостоятельно. Вместо этого вы будете передавать эти объекты в методы посетителя. Шаблонный метод — это поведенческий паттерн проектирования, который определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.Паттерн Шаблонный метод предлагает разбить алгоритм на последовательность шагов, описать эти шаги в отдельных методах и вызывать их в одном шаблонном методе друг за другом. Это позволит подклассам переопределять некоторые шаги алгоритма, оставляя без изменений его структуру и остальные шаги, которые для этого подкласса не так важны. Поведенческие паттерны: Chain of Responsibility, Memento, Command, Mediator Цепочка обязанностей — это поведенческий паттерн проектирования, который позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи. Снимок — это поведенческий паттерн проектирования, который позволяет сохранять и восстанавливать прошлые состояния объектов, не раскрывая подробностей их реализации. Паттерн Снимок поручает создание копии состояния объекта самому объекту, который этим состоянием владеет. Вместо того, чтобы делать снимок «извне», наш редактор сам сделает копию своих полей, ведь ему доступны все поля, даже приватные. Паттерн предлагает держать копию состояния в специальном объекте-снимке с ограниченным интерфейсом, позволяющим, например, узнать дату изготовления или название снимка. Но, с другой стороны, снимок должен быть открыт для своего создателя, позволяя прочесть и восстановить его внутреннее состояние. 45 Посредник — это поведенческий паттерн проектирования, который позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник. Паттерн Посредник заставляет объекты общаться не напрямую друг с другом, а через отдельный объект-посредник, который знает, кому нужно перенаправить тот или иной запрос. Благодаря этому, компоненты системы будут зависеть только от посредника, а не от десятков других компонентов. Команда — это поведенческий паттерн проектирования, который превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, логировать их, а также поддерживать отмену операций. Хорошие программы обычно структурированы в виде слоёв. Самый распространённый пример — слои пользовательского интерфейса и бизнес-логики. Первый всего лишь рисует красивую картинку для пользователя. Но когда нужно сделать что-то важное, интерфейс «просит» слой бизнес-логики заняться этим. В реальности это выглядит так: один из объектов интерфейса напрямую вызывает метод одного из объектов бизнес-логики, передавая в него какие-то параметры. Паттерн Команда предлагает больше не отправлять такие вызовы напрямую. Вместо этого каждый вызов, отличающийся от других, следует завернуть в собственный класс с единственным методом, который и будет осуществлять вызов. Такие объекты называют командами. К объекту интерфейса можно будет привязать объект команды, который знает, кому и в каком виде следует отправлять запросы. Когда объект интерфейса будет готов передать запрос, он вызовет метод команды, а та — позаботится обо всём остальном. |